这是一篇知识帖：终于能明白云原生技术的概念和可落地的应用分享

随着云计算的发展和普及，云原生概念的热度也越来越高，到底什么是云原生？和我们日常工作有什么关系？本文是向大家介绍云原生技术的概念和要点，帮助大家快速了解和学习云原生，，便于大家了解工作的定位，为各系统迭代优化提供方向和思路。

---

01. 什么是云原生

云原生是一种软件开发方法，它充分利用了云计算，使用开源软件技术栈将应用程序部署为微服务。通常，云原生应用程序构建为在Docker容器中运行的一组微服务，在Kubernetes中编排，并使用DevOps和Git Ops工作流进行管理和部署。使用Docker容器的优点是能够将执行所需的所有软件及环境配置打包到一个可执行包中。容器在虚拟化环境中运行，从而将包含的应用程序与其环境隔离。

——维基百科“Cloud Native”

Pivotal公司的Matt Stine于2013年首次提出云原生（CloudNative）的概念；2015年，云原生刚推广时，Matt Stine在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征：12因素、微服务、自敏捷架构、基于API协作、扛脆弱性；到了2017年，Matt Stine在接受InfoQ采访时又改了口风，将云原生架构归纳为模块化、可观察、可部署、可测试、可替换、可处理6特质；而Pivotal最新官网对云原生概括为4个要点：DevOps+持续交付+微服务+容器

2015年云原生计算基金会（CNCF）成立，CNCF掺和进来后，最初把云原生定义为包括：容器化封装+自动化管理+面向微服务；到了2018年，CNCF又更新了云原生的定义，把服务网格(Service Mesh)和声明式API给加了进来。

总而言之，符合云原生架构的应用程序应该是：采用开源堆栈（K8S+Docker）进行容器化，基于微服务架构提高灵活性和可维护性，借助敏捷方法、DevOps支持持续迭代和运维自动化，利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。

企业IT架构经历了单体架构、分布式架构和云计算架构3个阶段的技术演进。

企业应用上云，也经历了从云托管到云原生的架构演进过程。

上云初始阶段，多数企业仅仅是把应用从传统的IDC机房搬迁到云上的虚拟机，这是云托管模式，或者叫作基础设施即服务（Infrastructure as a Service，IaaS）上云。

云原生阶段，从架构设计、开发方式到部署维护的整个软件生命周期管理，都要基于云的特点进行重构，从而构建“原生为云”而设计的应用，这样才能在云上以最优的架构、最佳的模式运行，并充分利用和发挥云平台的弹性以及分布式优势。

---

02. 云原生设计原则

1．去中心化原则：

微服务化，去掉SOA的企业服务总线（ESB），仅保留服务注册中心；

2．松耦合原则：

实现的松耦合、时间的松耦合、位置的松耦合、版本的松耦合；

3．面向失败设计原则：

容错处理、高可用性、无单点故障；

4．无状态化原则：

具有可扩展性、自动弹性伸缩；

5．不变性原则：

容器化、自动化安装部署；

6．自动化驱动原则：

DevOps、CI、CD、自动化测试、全方位监控。

---

03. 云原生应用十二要素

一个优雅的互联网应用，在设计过程中，需要遵循的一些基本原则和云原生有异曲同工之处。十二要素由Heroku创始人Adam Wiggins首次提出并开源，由众多经验丰富的开发者共同完善。这综合了他们关于SaaS应用几乎所有的经验和智慧，是开发此类应用的理想实践标准和方法论指导。

1．基准代码，一份基准代码（codebase），多份部署（deploy）

在类似于SVN等集中式版本控制系统中，“基准代码”是指控制系统中的代码仓库；而在Git等分布式版本控制系统中，“基准代码”则是指最上游的代码仓库。

2．依赖，显式声明依赖关系（dependency）

十二要素规则下的应用程序不会隐式依赖系统级的类库，它一定通过“依赖清单”确切地声明所有依赖项。此外，在运行过程中，通过“依赖隔离”工具来确保程序不会调用系统中存在但清单中未声明的依赖项。这一做法会统一应用到生产环境和开发环境中，比如通过合适的工具（Maven、Bundler、NPM），应用可以很清晰地对部署环境公开和隔离依赖，而不是模糊地对部署环境产生依赖。无论用什么工具，依赖声明和依赖隔离都必须一起使用，否则无法满足十二要素原则。

3．配置，在环境中存储配置

通常，应用的配置在不同部署环境（预发布环境、生产环境、开发环境等）会有很大差异，这其中包括如下内容。

（1）数据库、Memcached，以及其他后端服务的配置。

（2）第三方服务的证书。

（3）每份部署特有的配置，如域名以及所依赖的外部服务地址等。

有些应用在代码中使用常量保存配置，这与十二要素所要求的代码和配置严格分离显然大相径庭。配置文件在各部署间存在巨大差异，代码却完全一致。判断一个应用是否正确地将配置排除在代码之外，一个简单的方法是看该应用的基准代码是否可以立刻开源，而不用担心会暴露任何敏感的信息。

十二要素推荐将应用的配置存储于环境变量（env vars、env）中。

在云环境中，无论是统一的配置中心，还是分布式的配置中心，都有很好的实践方式，比如Nacos通过命名空间实现不同环境的配置隔离，以及Docker的环境变量使用。

在十二要素应用中，环境变量的粒度要足够小，且相对独立。

4．后端服务，把后端服务（backing service）当作附加资源

后端服务是指程序运行所需的通过网络调用的各种服务，如数据库、消息队列、简单邮件传输协议（Simple Mail Transfer Protocal，SMTP）邮件服务，以及缓存等。

十二要素应用不会区别对待本地或第三方服务。

每个不同的后端服务是一份资源。

部署可以按需加载或卸载资源。

5．构建、发布、运行，严格分离构建和运行

将基准代码转化为一份部署（非开发环境）需要经过以下3个阶段。