中国移动云能力中心王超应邀参加由中国信通院主办的2021可信云大会，并在云原生分论坛发表了以《移动云云空间的云原生转型实践分享》为主题的演讲，以下是精彩内容分享。

1 定义云原生

数字世界再一次加速，我们已经从云化时代发展到了云原生时代。似乎整个行业都在讨论云原生，包括分布式系统、微服务、容器化、无服务器计算以及其他新兴技术和架构的作用，但 IT 从业人员和决策者仍然对云原生的真正含义以及利用云原生技术可达到的最终目标存有困惑。自从Paul Fremantle在2010年首次提出Cloud Native概念后，许多组织和专家都尝试定义云原生：

Paul Fremantle （2010年）

他认为，应用程序当前可能无法充分利用云环境，需要考虑一些技术属性，中间件和应用才能在云环境中良好运行（更好的利用资源、更快的配置、更好的治理），成为“Cloud Native”，此时云原生可以认为是一种云上应用构建理念。这些核心技术属性包括：分布式、弹性、多租户、自助服务、精细计量和计费、增量部署和测试。

Matt Stine（2015年）

Matt Stine在《Migrating to Cloud-Native Application Architectures》一书中表示，在单体应用向云原生迁移的过程中，需要从组织架构、技术和文化等多个方面共同变革。同时为云原生提出了一组最佳实践：十二因子、微服务、敏捷基础设施、基于API的协作、反脆弱性。

CNCF（2015年）

云原生计算基金会（CNCF）成立，将云原生定义为：容器化封装、自动化管理、面向微服务。

Matt Stine（2017年）

Matt Stine在一次媒体小组讨论中表示，云原生架构具有以下六个属性：模块化（通过微服务）、可观察性、可部署性、可测试性、可处理性、可替换性。

CNCF（2018年）

云原生计算基金会（CNCF）重新定义云原生为：云原生技术有助于各组织在公有云、私有云和混合云等现代、动态环境中，构建和运行可弹性扩展的应用。代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。

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

综上我们可知，云原生的定义一直在不断变化和演进中，但始终有一个核心的目标：“以应用为中心，实现价值用云”，让我们的应用系统和IT架构完全基于云原生，让我们的业务系统生于云、长于云。

2 企业数字化进程的启示

让我们再回顾一下，企业数字化的三个阶段以及它们的特点：

阶段1：前云时代

软件开发：使用瀑布模型，完整的软件一般需要数年时间才能完成开发交付，并且在进行新功能发布或者其他增量时，花费的时间较久。开发、QA和运维是不同的团队，协作不多。

基础设施：一开始直接使用物理硬件，后随着服务器虚拟化的兴起，可以使用性能更强大的物理服务器来部署虚拟服务器。

运维：运维任务通常手工完成，限制了系统可运维的规模。经过一段时间的发展，技术人员开始尝试使用配置管理工具，以减少维护基础设施带来的工作量和复杂度。

阶段2：云化时代

软件开发：技术人员开始使用敏捷开发模型和DevOps体系，以替代瀑布模型，这使得可以更快、更高质量地完成软件开发及交付。

基础设施：云将运行应用程序所需的资源和依赖作为即开即用的服务提供。应用构建者将云作为一种新型IT基础设施，使得他们可以专注于核心业务部分而无需关心底层基础架构。

运维：云上运维和管理的自动化程度进一步提升，包括开通、配置、扩容和自我恢复。

阶段3：云原生时代

软件开发：单体应用程序逐渐被微服务、服务网格和无状态计算等新技术改变，结合云原生产品，开始真正充分利用云的关键特性。

基础设施：云通过平台提供多种服务支撑。应用构建者通常采用多云或混合云方法，将应用程序和服务部署在最能发挥价值的地方。

运维：基于分布式构建的应用系统，开始使用全新的部署方法：容器和弹性调度平台，这些在基础设施中增加的抽象，能够使运维人员以新的方式观察和处理系统健康状态及性能表现。

在云化时代，企业将IT系统搬迁上云，业务应用都部署和运行在云上，消除传统硬件的束缚，实现了敏捷化的资源编排能力。通过池化资源，一定程度上解决了部署、运维方面的难题，但传统应用在架构、交付、部署形式等方面并没有充分体现对云关键属性的应用，无法发挥云的正真价值。

随着企业数字化进程不断推进，对云的理解和应用也更加深入，应用构建者们意识到仅仅简单地将IT系统搬迁上云，往往无法真正享受云带来的最大价值，需要由现在的ON CLOUD进阶到IN CLOUD，同时使用云提供的新生能力与既有能力有机协同，基于云原生的技术、架构和服务来构建企业应用，充分利用云的优势来助力企业应用和业务发展，将企业的数字化建设、业务智能升级带入新阶段。

3 云原生应用的概念和特点

对应用来说，云原生是一个形容词，体现的是应用为云而生的需求：应用需要做什么样的设计才能正真实现价值用云，这背后是一套“以应用为中心” 的技术体系和方法论，用于指导构建和运行云上应用。换句话说，云原生强调的IN CLOUD，并不是指应用所在的位置，而是指应用构建和运行的方式。

在云原生的语义下，“以应用为中心”并不等于重应用、轻平台，相反是平台上探、复杂性下沉，云平台通过云服务和产品，接管应用构建过程中更多的标准功能和非功能性特性，减轻乃至消除了应用对存储、计算、网络等资源的关注和依赖，云平台通过标准产品提供技术及业务能力，使应用能专注在业务需求实现上。

3.1 云原生应用

云原生应用是传统应用的再进一步，是为云而设计的应用程序，基于云构建，依赖云上服务和能力，最大化运用云的潜能，发挥云的价值，旨在充分利用云计算模型以提升速度、灵活性和质量，同时降低部署风险。云原生应用的立意并不关注应用程序在哪里运行，而是关注应用程序如何构建、部署和管理。

云原生应用自身基于云原生技术（微服务、容器化、CICD等），完成设计与构建，同时通过与云平台提供的相关可靠产品及能力（容器服务、安全产品、中间件等）充分整合，尽可能的剥离非功能性特性及逻辑（韧性/容错、可观测性、安全、连续性、一致性），让云接管，从而轻量化应用。

3.1.1 云原生应用特点

敏捷：应用迭代周期更短，能快速应对外部变化，用最少的试错来达到最终目标。

弹性/可扩展：应用可随业务流量自动扩缩容，具备较高的业务抗性。同时，具备对现有基础设施的横向、纵向扩展能力。

分布式：应用遵循低耦合的分布式模式，各个节点可以部署在不同的网络/地域中。

3.1.2 云原生应用的开发和传统应用开发之间的差异

云原生应用更加关注上市速度，所以应用开发需要更多敏捷、服务化开发及持续交付的方法。通过供跨开发团队和交付团队的DevOps协作、更加模块化的架构以及灵活可扩展的基础设施提供支撑，让云原生应用支持多种环境，具备良好的可移植性。

对应用来说，简单的转向微服务架构并不能带来企业数字业务所需的服务质量和交付频率，同样的，仅采用支持敏捷开发或IT自动化的工具不会提高云原生应用的构建速度。想要成功构建良好的云原生应用，需要的是实践、技术、流程和思维方式的有机结合。

云原生应用开发有两个互补的部分：云上应用服务或中间件，可以加速云原生应用的开发；云上基础设施服务或容器平台，可以加速云原生应用的交付和部署。

3.1.3 云原生应用开发及交付的四项原则

·基于服务化的架构

服务化架构，例如微服务，提倡构建模块化、松散耦合的业务服务。微服务的优势可以提升应用的构建速度而不会增加过多的复杂性，带来良好的独立性和业务敏捷性。

·基于API的通信交互

多个服务之间通过轻量、技术栈无关的API暴露和交互，能降低部署、扩展和维护的复杂性和开销。

·基于容器的基础设施

云原生应用使用容器在不同环境和基础设施（包括公有云、私有云和混合云）之间实现真正的应用可移植性。容器技术能在单个操作系统中为多个应用服务划分计算资源，并确保应用服务之间的安全与隔离。使用Kubernetes等容器编排平台，实现一定的业务抗性和弹性。

·DevOps流程

DevOps原则侧重于与交付团队（包括开发、QA、安全和  运维团队）协作构建，共同交付应用程序。同时，使用DevOps自动化功能，支持定期增量和持续交付，并引入灰度发布、蓝绿发布等来保持一定的业务连续性。

4 云原生应用构建实践

4.1 转向微服务

云原生应用的特点包括分布式和敏捷，这就要求将单体应用拆分为多个服务（分布式系统），而使用微服务架构是将应用程序拆分为较小服务的可靠方法，它有以下优势：

·可扩展/解耦

扩展单个服务，而不是应用整体，且服务可部署在任意网络节点

·互不干扰的技术栈

相互独立，远程通信，按需选型

·易于开发

服务小且独立，研发过程更可控，适合小兵团组合作战

·易于交付

每次更改涉及特定服务而不是整体，以较小的增量开发来满足单次交付需求

微服务的概念自2011年首次提出起，就展现出了比SOA更加优越的特性，在各类方法论和支撑技术加持下，微服务架构的分布式系统易于具备敏捷性、弹性、可扩展等方面的优势，深度契合云上应用的要求，那么如何设计一个良好的微服务架构系统呢，可以从以下几个方面考虑：

⑴ 服务设计原则

·无状态计算

服务节点不持有状态，支持微服务在运行中，随时按需弹性扩缩容。这也是分布式架构的关键点之一，将无状态的计算与有状态的数据分开，微服务计算节点只负责状态数据的分发与处理，而有状态数据的存储则依赖后端的各类中间件中。

·围绕业务、先粗后细

微服务架构的分布式系统要求我们的系统拆分成一个个独立且松散耦合的服务进程，要为每个服务划分好明确的边界，通常围绕业务，以界限上下文关联和聚合形成服务，而不是通过技术属性。在系统设计早期，可以将上下文界定的较粗，以较粗的粒度形成微服务，在后续的规划、设计与运行中，对服务有了更多认识后，再调整界定粒度，进一步拆分或者合并。

·容错与自我保护

微服务架构带来的问题之一就是复杂的服务依赖，并且随着时间推移，每个服务都可能依赖更多的服务，在调用链的某些服务不可用时，可能会因为调用堆积引起雪崩效应，无限的影响上游服务，需要有良好的机制（例如引入断路器），识别依赖服务的健康状态，并在发生问题时保护自身。

·幂等性、一致性

这是分布式系统永恒的话题之一，由于微服务众多，众多的服务请求都在网络中发生，当发生网络抖动、重复请求等异常情况时，服务需要具备良好的幂等设计来避免请求被重复处理。此外，在微服务架构的系统中，状态在多个服务之间流转，需要一致性来确保业务得到正确的处理，这就涉及到强一致性和最终一致性在系统中应用。

·向前和向后兼容

微服务的优势之一就是各个服务可以独立演进和迭代，而服务间复杂的依赖关系显而易见就带来了各个微服务版本兼容的问题，向后兼容要求服务自身迭代不能影响其他服务对自己身依赖和调用，实现多版并存，向前兼容要求服务自身能够接受并消化其他服务的迭代，保持系统稳定。

⑵ 系统设计原则

·服务自治

单个微服务就是单个独立的自治实体，体现在技术选型自由、部署自由、研发语言自由等方面，同时能够自治业务逻辑和数据，需要从上到下（接入层、业务层、数据层等）全面的独立，服务暴露出API（Application Programming Interface，应用编程接口），服务间通过API进行通信和调用。

·分层依赖

微服务整体架构设计需要分层，例如划分出核心服务层、公共服务层、基础服务层等，定义好服务的上下游关系落到具体的分层，并约定依赖方向，做好分层依赖，避免产生循环依赖导致系统整体耦合性上升。

·高效服务通信

微服务架构中的各个微服务之间通常通过远程通信实现调用，通信的实现方式直接影响了服务间调用的效率和成功率，这就需要考虑技术选型，例如选择具备多路复用、双向流通信、二进制传输等特性的新型传输协议和组件。

·适当异步消息传递

当在多个微服务上下文中传递消息时，各自微服务不同的部署规模和处理能力带来了服务间可能的调用堆积，可以使用适当的异步消息传递机制（请求响应异步、事件驱动异步、消息队列异步），减少系统整体耦合度、提升处理性能。

·面向运维

微服务架构下产生了繁多的独立服务实例，为系统运行期的运维带来了一定的复杂性，所以要把运维复杂性考虑到系统的设计阶段，由内而外的实现可观测性、可部署性及可运维性。

在这个过程中，我们要清楚的意识到“微”不是目的，“敏捷”才是我们的最终目标，要依托微服务的理念，将应用程序打造成一个业务敏捷、技术敏捷的云原生应用。

4.2 应用容器化

应用微服务化之后为集成和交付带来了挑战，而容器和微服务就像豆浆油条一样天生一对，是当下流行的开发实践，可将应用程序转换成可移植、可扩展、高效且易于管理的较小服务集合。

容器是一种轻量级的虚拟化技术，能够在单一主机上提供多个隔离的操作系统环境 ，通过一系列的namespace进行进程隔离，每个容器都有唯一的可写文件系统和资源配额。容器技术分为运行时和编排两层，运行时负责容器的计算、存储、网络等，编排层负责容器集群的调度、服务发现和资源管理。

中国云原生用户调研报告（2020）中调查数据显示，60%以上的用户已在生产环境中应用容器技术。43%的用户已将容器技术用于核心生产业务，19%的用户已将容器技术用于非核心生产环境。仅10%的用户未考虑使用容器技术。同时，容器运行时多元化发展趋势已经显现，但Docker仍是现阶段最主要的选择。83%的用户容器运行时技术选用Docker，9%的用户选用 Containerd。此外，Kubernetes延续在容器编排技术领域的优势地位，63%的用户容器运行时技术选用Kubernetes，17%的用户选用Docker Swarm。

容器技术能为使用者能带来以下优势：

·更快的初始化和执行

·更细的隔离与服务共存

·更轻松的编排管理

·更便捷的制品交付

在实际的研发过程中，常常有以下几种诉求：

·在研发生命周期中，分别部署到不同的环境

·业务服务快速启动/拆除/扩缩容

·业务服务实例混部

·只关心应用运行，而不关心在哪里运行

以上两者可以发现，容器技术的优势可以匹配研发过程中的诉求，容器可以帮助解耦应用和基础设施，提高业务敏捷性，是实现“以应用为中心”架构的重要支撑。通过云、容器、微服务三者协同工作，将应用的开发和交付提升到传统方法和技术无法达到的新高度，大大增加了应用生命周期的敏捷性和可靠性。

通常，云上的容器服务能提供高性能可伸缩的容器应用管理服务，容器化应用的生命周期管理可以提供多种应用发布方式。容器服务简化了容器管理集群的搭建工作，整合了调度、配置、存储、网络等，打造云端最佳 容器运行环境。使用容器技术，用户可以将微服务及其所需的所有配 置、依赖关系和环境变量打包成容器镜像，轻松移植到全新的服务器 节点上，而无需重新配置环境，这使得容器成为部署单个微服务的最理想工具。

4.3、持续交付流水线

应用微服务化与容器化之后，还是会面临“更快且频繁交付”和“系统稳定且可靠”之间的矛盾。而持续交付（Continuous delivery）是一种软件工程方法，旨在以更快的速度和更高的频率来构建、测试和发布软件。可以使生产中的应用程序进行更多增量更新，该方法有助于降低成本、耗时和交付变更的风险。使用者可通过完整的工具链，深度集成代码仓库、制品仓库、项目管理、自动化测试等类别中的主流工具，快速实践。

由上图可以看到，持续交付是持续集成模型基础上的延伸，使研发周期自动化更进一步，能够快速发布到演示或UAT环境、以及执行自动化的系统集成测试。

4.3.1 实践原则

在建设持续交付流水线的过程中，可以遵循以下策略：

⑴ 版本控制与分支策略

·可审核、可重复

每一次的版本构建都是可审核且可重复的，能够利用版本控制策略回溯，以应对流水线中可能出现的失败。

·包含整个交付物（代码、数据库、配置）

版本控制不能仅仅包含代码，也要包含变更涉及的所有内容，避免遗漏，产生不一致。

·频繁的分支合并

尽早、频繁的合并分支，有利于发现最新的修改，能够及时处理冲突。

⑵ 持续交付流水线

·合适的工具

采用合适的工具构建自己的流水线，考虑学习成本、维护、效果等多方面的因素。

·数据驱动

通过每一次自动化动作的指标量化数据，来驱动流水线向前或向后推进。

·控制与改进

通过每一次构建的动作效果与反馈，不断改进流水线，添加自动化动作或者更新技术工具。

⑶ 更多的自动化

·检测、构建、测试

在流水线中引入更多的自动化动作，尽量减少手工参与，可以覆盖检测、构建、测试等多个环节。

·覆盖整个交付物

自动化的动作不仅要覆盖代码，也要包含全部交付物，例如脚本、SQL、配置等，避免遗漏。

·重复的体力劳动

如果在流水线上有重复的人工体力劳动，都建议尝试将其纳入自动化动作。

⑷ 良好的反馈机制

·全周期反馈

反馈机制要包含整个持续交付周期，对每一次动作都要有所响应，避免遗漏。

·快速反馈

在持续交付中，流水线要能够在构建时快速给出结果，避免团队等待而降低敏捷性。

·团队积极响应反馈

团队成员需要建立起迅速响应流水线反馈的文化，及时修改问题，提升效率，降低风险。

4.3.2 持续交付流水线样例

一个典型的用于生产的持续交付流水线如上图，充分融合了技术、流程与团队，通过自动化动作与持续反馈机制，不断发现交付物中的问题并予以修正，能够大大降低部署到生产环境的风险。

持续交付并不要求最终交付物自动化部署到生产环境，在持续交付的语义下，生产环境部署变更是两阶段完成的，第一阶段采用持续交付给出稳定的交付物，实现制品晋级并分发到发布制品库，通过上线审核后，再通过发布管理平台或其他方式部署到生产环境。

4.4、与云融合

从使用效用方面看，云原生极大的释放了云的红利，云原生充分继承了云的设计思想，应用会更多基于云上进行本土应用开发，即云原生应用更加适合云的架构，而云计算也为云原生应用提供较好的基础支撑。云计算的发展已进入成熟期，云原生作为新型基础设施支撑数字化转型的重要支撑技术，逐渐在人工智能、大数据、边缘计算、5G等新兴领域崭露头角，成为驱动数字基础设施的强大引擎。

对使用者来说，使用云上提供的服务或产品，有助于剥离非功能性需求，敏捷化研发过程，实现提质降本增效。以移动云为例，目前规划提供了多线条的产品线来支撑快速、高效的构建云原生应用。

云原生开发者服务

包括微服务治理引擎、DevOps工具链、应用开放平台等，为开发者提供端到端的协同服务和研发工具，降低数字化技术使用门槛，提高资源的复合利用率，提升协作和交付效率。

云原生中间件产品线

包括消息队列、数据库、大数据、AI能力等，提供优势云数能力及各类云上中间件，能将功能从应用中剥离，在运行时为应用动态赋能。

云原生计算产品线

包括容器服务、Serverless等，封装异构基础设施提供负载支撑，有效解决异构环境部署一致性问题，促进了资源的标准化。

5 结语

云上应用的共性需求促进了云上服务及产品的演进，云上服务及产品的繁荣也进一步促进了云上应用构建和运行形式的更新，这是一个双向价值促进的过程。对应用本身来说，除了围绕云原生代表技术来设计与构建之外，还要与云提供的各类服务及产品深度整合，根植于云，随云而动--“to be Cloud Native”。

让我们再回看Paul Fremantle在10多年前提到的未来：

strongly believe that it is only once a system really implements these attributes that it starts to give the full benefits of running in a cloud. And the benefits of "Cloud-Native" systems are immense: better utilization of resources, faster provisioning, better governance.

如今，未来已来。

作者简介：

王超，中国移动云能力中心SaaS产品部技术专家组成员，曾负责能力开放平台、服务治理平台、移动云云网盘等产品及项目的研发工作，架构设计及研发管理经验丰富，在互联网大型业务系统的规划、设计与调优方面有深入研究。

参考文献

[1] 《云原生2.0白皮书》  -  中国信通院.

[2] 《mi-path-to-cloud-native-apps》  -   redhat.

[3] 《云计算发展白皮书2020》 - 中国信通院.

[4] 《云原生发展白皮书2020》 - 中国信通院.