最近在考虑从云原生角度去做一些架构维度的改造。但之前关注的在于平地而起的理想态云原生方案，基于存量架构来说就比较复杂了，比如如何衔接现有系统存量能力，低成本接入，同时还可以吃到技术升级的红利。

非常多的人在讨论云原生，那什么是云原生？解决什么问题？

上云的目的是利用云平台的优势，比如按需分配、弹性伸缩都是云原生的关注点，但应用程序并不能轻松的上云。所以想要应用程序可以利用云平台的优势，就需要对应用系统进行云原生改造。

那么什么是云原生？

Pivotal给出的云原生应用的几个特征可以参考，符合12因素应用、面向微服务架构、自服务敏捷架构、基于API协作及抗脆弱性。

其实云原生是一个思想集合，云原生技术包括技术维度、应用管理维度、企业管理维度等。

- 技术维度：微服务、敏捷基础设施

- 应用管理维度：DevOps、持续交付

- 企业管理维度：康威定律

更细化的架构维度特质包括：

1. 模块化应用

2. 可观测性

3. 可部署性

4. 可测试性

5. 可处理性

6. 可替换性

归纳下来即，DevOps、持续交付、微服务、容器化。

那CNCF对云原生定义是什么呢？

包含三个方面：

1. 应用容器化

2. 面向微服务架构

3. 应用支持容器的编排调度

由于CNCF是以K8s为底座的，所以其关于云原生定义的概念主要围绕于上云，即：通过云原生实现各组织在公有云、私有云、混合云等新动态环境下，构建可扩展的弹性应用，涉及到容器、服务网格、微服务、不可变基础设施、声明式API。

通过以上技术可以构建更具容错性、易于管理、便于观察的松耦合系统。

容器

说不太好是容器推进了云原生，还是云原生推进了容器发展。起码以目前看，容器是云原生下最关键的技术，有了Docker，整个云原生才找到了正确的打开方式。

Docker背后代表了基于镜像的动态交付，依赖于新型的应用打包、分发、运行机制。将容器镜像将应用运行时环境、代码、依赖库、工具、资源文件等打包成一种操作系统无关的变更软件包。实现了buid once、run anywhere。

微服务

在微服务架构下，每个服务实例是独立可部署的组件，对外以API暴露能力，通过微服务实现了云原生下面的应用模块化要求，进而实现了服务之间的松耦合。

每个服务都可以独立开发、测试、验证、部署。

服务网格

服务网格主要提供的是服务之间通信的通信基础设施，保障了服务之间通信的可靠性传递。

做好服务网格的标准：

1. 应用程序通信的中间层

2. 轻量级网络代理

3. 应用程序无感知

4. 解耦应用程序的重试、超时、监控、追踪、服务发现

服务网格一般通过一组轻量级网络代理实现，这些代理和应用程序一起部署，建设对应用系统入侵。将传统服务通信相关的治理能力和基础的网络通信放在一起，真正和业务逻辑解耦开，简单理解就是将网络访问、限流、熔断、监控和TCP/IP放在一起。

目前的服务网格实现的功能越来越多，包括服务发现、负载均衡、故障恢复、指标收集、监控告警等研发与运维需求，借助于Mesh方案可以实现，如AB测试、金丝雀发布、限流、访问控制、端到端认证等。

不可变基础设施

我觉得这个是理念上的改变，一个工作负载的承担（容器、虚拟机）一旦部署之后不再进行修改。当需要更新、修复或修改时，只是将新的、经过验证的工作负载替换掉就得即可。

不可变基础设施主要体现在系统稳定性方面，传统的应用程序一旦部署到用户特定服务器上之后，服务器系统是会不断变化的，比如操作系统升级或在上面安装新应用，这样在其负载之上的应用稳定性就受到了挑战。

而一旦定义了不可变基础设施，就避免了类似的问题，因为他不存在了变化的问题了。

声明式API

与声明式API对应的是命令式API。命令式API提供给用户怎么做，声明式API是给用户提供了做什么的能力，简单理解，前者是确定性rest api，后者是dsl。

其背后体现的是API背后能力的扩展性与弹性。

技术之外的事情

云原生除了对应用系统做了技术维度优化之外，还在流程与组织维度做了优化。它解放了开发和运维，让研发与运维的工作变得简单。云原生还关注于规模，让分布式系统具备了水平扩展能力，同时具备了故障之后的快速恢复能力。