Cloud Native,中文翻译为云原生,是由 Matt Stine 提出的一种软件开发模型。
Cloud Native 作为一种软件开发模型,又由多种概念和技术集合而成,比如微服务,DevOps,CI/CD,容器技术,云计算。
相较于传统的软件开发模型,如瀑布模型和敏捷开发模型,Cloud Native 的显著优点是快速交付的能力。这一改变与市场环境息息相关,在20世纪90年代时,软件的交付周期还以年或月为单位,按部就班的瀑布模型仍有用武之地。随着科技发展越来越快,在移动互联 时代,手机中的app迭代周期有时候就短短几天,大型互联 公司更是宣称能在一天内实现几百次部署,更快速的软件开发模式,比如 Cloud Native,正是在这样的环境下催生的。
Cloud Native 也可以看作是一类软件的特征,企业需要一个平台来自动话构建和运维 Cloud Native 应用,在这平台的构建过程中集成了 DevOps、持续交付、容器和微服务等技术。
CNCF 对 Cloud Native 的定义
CNCF()由 Linux 基金会在 2015 年筹建,致力于是云原生计算更具有普遍性和可持续性。
CNCF 对云计算的定义更加苛刻:
Cloud Native 是基于可以容器化的开源软件,构造灵活调度、资源利用率高、类微服务架构的软件,是软件具备敏捷性和可维护性。
Cloud Native 软件 vs. 传统软件
Cloud Native 软件 | 传统软件 | |
---|---|---|
基础设施 | 公有云或私有云 | IDC机房 |
软件升级 | 支持在线实时更新 | 需要停机更新 |
资源弹性 | 按需取用,弹性伸缩 | 无法弹性伸缩 |
停机时间 | 存在资源池,节点出问题时具备自动恢复能力 | 可以增加容灾节点,需要手动切换 |
资源耦合度 | 络,存储和数据库都可以替换 | 与 络,存储,数据库硬编码,有改动就会出错 |
实践 Cloud Native 需要哪些准备
运维团队
运维团队需要从通过脚本监控服务器状态的刀耕火种阶段迁移到以持续交付的流程改善和自动化上,要逐渐熟悉今天发布,明天就开始运维的日子。
确定优先级
业务和研发部门要共同讨论哪些现有组件要先转化为 Cloud Native 的模式,是存储设备,监控系统,还是团队文化定好优先级的同时,还要考虑实施这些改变的投入产出比。
拥抱新的开发范式
开发人员在编写代码时就要考虑软件需要具备哪些要素,比如遵从 12 因素原则,将灵活配置、无状态、高并发、日志可追溯等特性结合到开发过程中。
搭建平台
一个自动化的、覆盖持续交付各个阶段的运维平台,可以根据实际需要,集成各种需要的开源工具。
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!