“云原生”的应用价值及关键属性解读

“云原生”是云计算中很重要的一个概念，不过对“云原生”的认识和解读各有侧重。我们觉得云原生围绕的是“云原生应用”这个核心，微服务、容器、DevOps 等是实现云原生的工具和方法论，它们并不等价。澄清概念、厘清认知，是推动“云原生应用”落地实践的基础。

初次听到“云原生（Could Native）”的时候也是一头雾水，对云原生的十二要素也是不理解。随着项目的推进，对云计算理解的越来越多，也有了一些自己的体会，再次看云原生的概念的时候，有了新的认知。也总是看到很多人讨论云原生，有人说云原生是构建和运行应用程序的方法；有人说云原生是一套技术体系和方法论；有人说云原生应用；有人说云原生架构；也有人说云原生就是是持续交付、微服务、容器、DevOps 等等不一而足。不能说是错的，也不能说对，不同的人所说的根本不在一个频道上。我们一向强调从整体上、全面的看待问题，不要有选择的只看一点。我们觉得很多人都或多或少的忽略了云原生的核心实质：Native。

一、 云原生（Cloud Native）

云原生概念到底是什么？

我们觉得对于新技术首先最重要的就是弄清楚它的概念和适用场景。先看 Native 在英语中的意思：天然的、天生的、本国的、土著的。Cloud Native 就是天生的云，就是天生就具备云的基因，适合云环境。就像美国人的 native language 是 English 一样，不是说美国人改变了国籍加入了其他国家的国籍，其 native language 就变了，native 是一辈子都不会变的。

其核心是云原生应用，范围包括云原生应用生命周期过程的理论、工具和方法。云原生十二因素是判断是否是云原生的基本原则，也是实现云原生应用的基本理论指导（虽然这些因素并不完全准确）。至于持续交付、容器、微服务、DevOps 是实现云原生应用或服务的方法、工具框架和环境支持。不是采用所谓的微服务、容器技术、DevOps 就是云原生了，那只不过是一种实现方式而已。没有它们，换其他工具方法同样可以实现云原生。即便有了它们，用了它们也不一定就是云原生。

二、 云原生所应具备的特性

首先要明白云原生要具备云的天然基因，天生就是云的一部分。云原生不是为云而生，而是天生就是云，生而是云，所以它具有云的特性：通过网络访问、远端部署执行、可扩展弹性伸缩、共享、按需使用自助服务、高可用、可远程监控计费审计、标准化交付与位置无关等。

云原生十二因素中，基准代码是为共享；依赖、配置、后端服务、管理进程是自治自主服务范畴；构建、发布、运行以及端口绑定是标准化交付与位置无关范畴；端口绑定也是远程访问范畴；进程、并发是扩展弹性要求；易处理是高可用要求；日志是监控计费审计需求，作为事件流则是云应用与位置无关要求。

云原生十二因素虽然提出了云原生应用的大部分特性，但并没有明确云原生到底是什么？讨论云原生的时候到底该讨论什么？

三、 讨论云原生该关注什么？

我们在讨论云原生的时候到底该关注什么？是架构？体系？或是方法？

我们觉得讨论云原生最重要的是讨论云原生应用。这是所有讨论云原生的核心。云原生架构是云原生应用的架构，云原生方法论是实现云原生应用的方法论，云原生程序就是云原生应用，云原生体系就是构建、发布、运行云原生应用的理论、方法、工具、环境、流程、文化等等。最终目的是为了业务应用。云原生要素中第一条就是“一份基准代码，多份部署”，也已明确了是云原生应用。

应用可以是天生具备云基因，适合部署于云环境，或者通过改造之后适合云计算环境，但改造的应用不是云原生应用，因为它不是天然的云应用。云原生应用也不是为了迁云，传统应用改造为云应用才是为了迁云。这是我们在讨论云原生的时候需要厘清楚的概念，不能混为一谈。概念不清就会越谈越乱，越谈越糊涂。

四、 云原生应用

云原生应用，就是天生具备云计算基因，以云计算的思想构建并适用于云计算环境的应用。它应该具备我们提到的特性：可以通过网络访问、远端部署执行、可扩展弹性伸缩、共享、按需使用自主服务、高可用、可远程监控计费审计、标准化交付与位置无关等。有人说轻量、无状态是不是云原生的特征？我们并不认为是。轻量、无状态是容器的特征，容器非常适合部署微服务应用，但微服务应用并不一定是云原生应用。

应用云原生思想，可以采用微服务架构、容器、DevOps 等技术构建轻量、无状态的云原生应用，使应用具备云端部署、可远程访问、弹性、共享、按需自助服务、高可用、与位置无关等特征，使之天生就具备云的基因，适合云环境部署运行。云原生十二因素更多的也是从构建云原生应用的角度讨论的。

（一） 弹性

弹性是云计算的重要特征，理论上不受资源限制，可以无限占用资源（当然需要按使用量付费）。容器之所以和云原生扯上关系，因为弹性也是容器的重要特征，采用容器很重要的是其弹性能力。弹性包括弹性使用资源和服务实例弹性扩展能力。在单实例扩展资源达到瓶颈，则配合负载均衡机制实现容器实例的弹性扩展。我们谈论云原生应用弹性，应该包括应用使用资源的弹性和应用实例弹性扩展的弹性。

（二） 共享

云计算分三种类型：IaaS、PaaS、SaaS，这就涉及三个层级的共享：资源共享、平台共享、应用共享。云原生应用是 SaaS 层服务，部署于 IaaS 或 PaaS 层。应用有一份基准代码，多份部署，也是共享，是从应用开发角度考虑，但不是云应用共享意义。

云应用可以对所有人开放，大家共享云应用提供的服务。云应用需要部署在云计算平台上，使用云计算资源，这就实现了平台共享和资源共享。

（三） 自治

云应用部署与位置无关，你不知道它会被部署到什么位置，底层对用户透明。所以云原生应用的依赖包、配置文件、后端服务等就需要和应用一起同生共死，成为一个整体，实现自管理自治理。

微服务的设计也遵循自治原则，和云原生应用非常相似。这可能也是把它们放一起讨论的原因。因此我们在用微服务实现云原生应用的时候，自治是一个重要的判断标准。这是分布式中心的好处，自成一体。就像人，每个人都是一个分布式中心，具备自我管理的能力。

（四） 交付标准化，与位置无关

云应用构建可以在本地或者云端，运行一定在云端，那就要按照一定的标准交付，比如容器镜像，使交付标准化。标准交付就可以在云端任何支持标准的位置部署，或者根本不需要知道被部署到了什么位置运行，和环境无关。就像 Java 曾经宣称的那样: Write Once, Run Anywhere，实现 Build Once, Run Anywhere。

容器的一个好处是应用运行工具标准化，所有的应用都以标准化镜像的方式交付，在标准化的容器里运行。容器可以运行在任何地方，或者也无需知道它运行在哪里，只需要提交镜像发布运行就可以了。

（五） 高可用性

多实例部署、弹性、自治等特性是高可用的保证。采用容器有时候并不能保证应用的稳定性，但可以是敏捷启停、多实例高可用的。如果需要稳定的高可用机制，容器可能不是最好的选择。

（六） 可监控审计

用户对应用的访问调用，应用的运行情况状态，不管通过日志或者接口能实时获取到这些信息，用于计量计费、监控和后期审计等。比如可以根据负载流量实现弹性伸缩。

（七） 按需访问自助服务

云应用部署在云端，根据客户自己的需求，通过网络访问，自助使用服务，不需要联系云应用管理人员。通常会有个云应用服务目录，每个应用服务都有使用说明，通过服务目录可以找到适合自己满足自身需求的应用。

（八） 可配置

云应用往往依赖配置中心，实现不同环境应用的部署运行。比如开发、测试和生产环境，一些参数的配置可能是不一样的。很多时候又不方便把所有的配置文件都和应用打包在一起，所以可以通过配置中心来统一管理应用配置文件，甚至可以实现运行时参数更新。

配置中心更多的是从应用运维的角度来考虑的。从自治角度来说，它并不是必须的。但是也是很重要的载体，就像人有大脑存储，但依然需要借助纸笔记忆一样。

（九） 敏捷

敏捷不管从应用开发部署角度或者运维运营角度，都是需要的。但我们觉得它不是云原生应用的关键特性。敏捷通常和轻量、微服务组件化相关，小了，轻了相对就敏捷多了。很多时候敏捷和架构相关，不只是技术架构，也和组织架构相关。敏捷更多的是流程、管理或体验的需求。

五、 微服务、容器和 DevOps 构建云原生应用

容器轻量、弹性；微服务小而专使开发、测试、更新效率提高，实现了敏捷；DevOps 持续集成、持续部署、持续发布、持续监控、持续反馈、持续改进而形成应用生命周期管理的闭环。容器的轻量特性非常适合运行微服务化应用。微服务架构使应用设计架构思想发生了改变。采用小而专的微服务完成某一特定的业务单元工作；通过微服务的组合或编排而成一个业务应用，完成特定的业务流程；业务流程可以按需编排，实时部署；镜像使交付标准化，容器使运维调度标准化，镜像仓库使分发部署标准化。标准化使持续集成、部署、发布流程简化，服务编排使应用研发实现敏捷化，DevOps 持续监控、反馈、改进使响应变化敏捷化。可以及时反映市场业务需求的变化和要求。

也因此容器、微服务和 DevOps 会被放在一起来共同构建轻量、无状态的云原生应用。

六、 应用改造和迁移

应用通过改造使其具备云原生的特性（重生），部署于云环境，可以简单的把它看到云原生应用。但是如果不做改造直接迁移到云环境，并不能成为云原生应用，即便具备云的某些特性，比如 ESB 服务，并不是云原生应用。

在考虑应用迁移时，需要考虑应用是否具备云原生应用的特性，如果不具备通常需要考虑改造，以使其能够具备云计算的优势。（文章来自 twt 企业 IT 社区 ，鸣谢）