云原生-代表技术

云原生（cloud native)的代表技术

英文版

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.

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.

中文版

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。

今天着重就其中的”云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API“详细描述我的认知

代表技术一：容器化

容器化，本身并不是特别先进的技术，至少不是最近今年的新兴技术，最近其突然火爆的原因与云的充分发展有关，与google的大力推广有关，也与目前容器的分层设计逐层依赖有关。
随着k8s的容器编排技术成为业界的逐流，容器化已经不止是containerd这样的容器引擎+docker这样的容器描述技术，容器编排已经包含在容器化这个概念之中。
而k8s对容器本身的抽象还是比较复杂的

1. 其对多语言的支持特别好，都放在docker内部来管理
2. 一个容器一个进程的最佳管理方式（虽然现实中不一定做到），可以将应用的状态管理转换为容器的管理，统一抽象应用的生命周期
3. liveness、readiness的抽象，让优雅上下线成为一个标配。
4. 真正的让大量的运维工作抽象为文本，让机器自己处理异常问题（配合声明式API）
5. 非常优秀的CRD设计，扩展成为一种自然而然的方式

代表技术二：服务网格

个人不认为服务网格和云原生有必然联系，有点反潮流。
目前服务网格最大的问题是牺牲性能来满足，架构-低耦合、功能上的诉求。后续数据面板与控制面板之间的边界需要重新划分，以在性能和架构、功能 之间达到一个平衡。

代表技术三：微服务

微服务 是分治思想在软件架构领域的落地方法。将一个复杂的问题，分解为多个小范围的简单问题来处理
这个过程中需要用到RPC，而针对RPC又引申出微服务治理，基于微服务治理又有很多的实践--灰度发布、蓝绿发布、金丝雀发布、故障演练（delay or abort）

代表技术四：不可变基础设施

不可变基础设施，可以理解为对生产环境的基础设施不允许进行运维层面的修改。
所有对其的修改都是通过修改有版本管理的源代码（有点类似于gitops的概念，一般是修改dockfile）来完成。

代表技术五：声明式API

声明式API对我来说才是最颠覆以前认知的一个东西
在最初的时候比如有一个负载均衡后面挂5个无状态的vm，当其中一台vm宕机的时候，以前我们会收到一个告警，运维或者是devops决定是否立刻重启这台机器，或者申请新的vm来替换它（在底层资源做的比较好的时候是可以做到类似于云的状态的或者直接用云服务）。而在云原生领域里当编排框架发现应用的状态与声明的终态不一致时，会优先用集群的资源去进行恢复终态，当无法达成终态时才会去执行告警等操作。节省了大量的运维成本。