什么是云原生(Cloud Native)
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.
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.
直接翻译过来就是：
云原生技术使得企业可以在现在的公有云，私有云或者混合云这样的动态环境中构建和运行可伸缩的应用。这种方式典型的特征就是容器，服务网格，微服务，不可变基础设施和声明式API。
这些技术可以使得应用变得松耦合，有弹性，可管理并可观测。配合稳定的自动化，工程师们可以用最小的代价频繁的，可预测的对应用做一些影响重大的改动。
现在的应用越来越负责，产品对创新方面的需求越来越高。云原生主要关注速度和敏捷。业务系统越来越聚焦于如何更快的适应市场的需求，更快的创新。
如下图所示，云原生的速度和敏捷取决于很多因素。最重要的几个因素如下图所示：
| Cloud Infrastructure |
云基础设施 |
重度使用PaaS的思想，所有的云基础设施资源都被看成一次性可以随意使用的资源(通过自动化的方式实现) |
| Microservice |
微服务 | |
| Modern Design |
先进的设计 | 云原生下的系统架构和传统的系统架构有哪些区别：业界推荐的是要遵守12条法则。（详见下文） |
| Containers |
容器 | |
| Backing Services |
后端服务 | |
| Automation |
自动化 |
云原生架构的12原则
业界公认的云原生架构需要遵守的12条原则:
| 1 |
Code Base | 独立代码库 |
每个微服务有自己独立的代码库，有版本控制，并且可以被部署到多个不同的环境。 |
| 2 |
Dependencies | 依赖隔离 |
每个微服务隔离和打包自己的依赖；保证故障时不会影响整个系统。 |
| 3 |
Configurations | 配置外化 |
配置信息不在保存在应用内部，而是放在独立的配置中心。这样可以保证配置信息的稳定，并且应用和配置信息解耦，便于部署。 |
| 4 |
Backing Services | 后端数据服务资源化 |
所有的数据服务(数据库/缓存/消息队列)以资源的方式通过URL暴露出去。做到资源和应用解耦。 |
| 5 |
Build, Release, Run | 软件生命周期管理 |
每个发布，从打包，发布到运行都是独立的，能够支持发布和回滚。这个功能可以通过CI/CD来实现。 |
| 6 |
Processes |
进程隔离 |
每个微服务运行在自己其他服务隔离单独的进程中。状态信息都外化到后端数据服务中。 |
| 7 |
Port Binding | 端口绑定 |
没给微服务都需要把功能暴露在特定的端口上。 |
| 8 |
Concurrency | 并发 |
服务支持水平扩展。 |
| 9 |
Disposability | 随意处理性 |
服务实例应该可以随意处置。Docker和K8S可以满足这个要求。 |
| 10 |
Dev/Prod Parity |
Dev/Prod环境一致性 |
尽量保证开发和生产环境的一致性。通过Docker可以满足这个要求。 |
| 11 |
Logging | 日志即事件流 |
把微服务产生的日志当作事件流，分析这些事件流，对他们进行聚合和加工。可用于数据挖掘，监控分析等。 |
| 12 |
Admin Processes | 管理过程 |
Backing Services
云原生的应用依赖很多的后端服务。常见的Backing Service如下图所示：