定义
以下是CNCF对云原生的重新定义(中英对照):
Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.
这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段,云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。
The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone.
云原生计算基金会(CNCF)致力于培育和维护一个厂商中立的开源生态系统,来推广云原生技术。我们通过将最前沿的模式民主化,让这些创新为大众所用。
参考:CNCF Cloud Native Definition v1.0
什么不是云原生
1:云原生不等于在公有云上运行。
光是租用服务器并不会使您的基础设施云原生化。管理 IaaS 的流程与运维物理数据中心没什么两样,将现有架构迁移到云上也未必能获得回报。
2:云原生不是在容器中运行应用程序。
最先推出云原生基础设施时,几乎所有应用程序部署在虚拟机中,而不是在容器中。改变应用程序的打包方式并不意味着就会增加自治系统的可扩展性和优势。即使应用程序是通过 CI/CD 渠道自动构建和部署的,也不意味着您就可以从增强 API 驱动部署的基础设施中受益。
3:云原生不是微服务或基础设施即代码。
微服务意味着更快的开发周期和更小的独特功能,但是单片应用程序可以具有相同的功能,使其能够通过软件有效管理,并且还可以从云原生基础设施中受益。
4:配置管理工具不是云原生的基础设施。
配置管理工具一次自动化一台服务器,并依靠人员将服务器提供的功能绑定在一起。这将人类定位为基础设施规模的潜在瓶颈。这些工具也不会使构建完整系统所需的云基础设施(例如存储和网络)的额外部分自动化。
尽管配置管理工具为操作系统的资源(例如软件包管理器)提供了一些抽象,但它们并没有抽象出足够的底层操作系统来轻松管理它。如果一位工程师想要管理系统中的每个软件包和文件,这将是一个非常艰苦的过程,并且对于每个配置变体都是独一无二的。同样,定义不存在或不正确的资源的配置管理仅消耗系统资源并且不能提供任何价值。
虽然配置管理工具可以帮助自动化部分基础设施,但它们无法更好地管理应用程序。我们将在后面的章节中通过查看部署,管理,测试和操作基础架构的流程,探讨云原生基础设施的不同之处,但首先,我们将了解哪些应用程序是成功的以及应该何时与原生基础设施一起使用。
云原生的设计理念
云原生系统的设计理念如下:
- 面向分布式设计(Distribution):容器、微服务、API 驱动的开发;
- 面向配置设计(Configuration):一个镜像,多个环境配置;
- 面向韧性设计(Resistancy):故障容忍和自愈;
- 面向弹性设计(Elasticity):弹性扩展和对环境变化(负载)做出响应;
- 面向交付设计(Delivery):自动拉起,缩短交付时间;
- 面向性能设计(Performance):响应式,并发和资源高效利用;
- 面向自动化设计(Automation):自动化的 DevOps;
- 面向诊断性设计(Diagnosability):集群级别的日志、metric 和追踪;
- 面向安全性设计(Security):安全端点、API Gateway、端到端加密;
以上的设计理念很多都是继承自分布式应用的设计理念。虽然有如此多的理念但是我们仍然无法辨认什么样的设施才是云原生基础设施,不过可以先用排除法,我将解释什么不是云原生基础设施。
云原生应用程序
就像云改变了业务和基础设施之间的关系一样,云原生应用程序也改变了应用程序和基础设施之间的关系。我们需要了解与传统应用程序相比,云本身有什么不同,因此我们需要了解它们与基础设施的新关系。
云原生应用程序被设计为在平台上运行,并设计用于弹性,敏捷性,可操作性和可观察性。弹性包含失败而不是试图阻止它们;它利用了在平台上运行的动态特性。敏捷性允许快速部署和快速迭代。可操作性从应用程序内部控制应用程序生命周期,而不是依赖外部进程和监视器。可观察性提供信息来回答有关应用程序状态的问题
微服务
微服务解决的是我们软件开发中一直追求的低耦合+高内聚,记得有一次我们系统的接口出了问题,结果影响了用户的前台操作,于是黎叔拍案而起,灵魂发问:“为啥这两个会互相影响?!”
微服务可以解决这个问题,微服务的本质是把一块大饼分成若干块低耦合的小饼,比如一块小饼专门负责接收外部的数据,一块小饼专门负责响应前台的操作,小饼可以进一步拆分,比如负责接收外部数据的小饼可以继续分成多块负责接收不同类型数据的小饼,这样每个小饼出问题了,其它小饼还能正常对外提供服务。
DevOps
DevOps的意思就是开发和运维不再是分开的两个团队,而是你中有我,我中有你的一个团队。我们现在开发和运维已经是一个团队了,但是运维方面的知识和经验还需要持续提高。
持续交付
持续交付的意思就是在不影响用户使用服务的前提下频繁把新功能发布给用户使用,要做到这点非常非常难。我们现在两周一个版本,每次上线之后都会给不同的用户造成不同程度的影响。
容器化
容器化的好处在于运维的时候不需要再关心每个服务所使用的技术栈了,每个服务都被无差别地封装在容器里,可以被无差别地管理和维护,现在比较流行的工具是docker和k8s。
所以你也可以简单地把云原生理解为:云原生 = 微服务 + DevOps + 持续交付 + 容器化