阿里云技术白皮书_对阿里重磅发布的云原生架构白皮书的初步解读

今天准备整理和分享下阿里云发布的云原生架构白皮书。在今年7月份，由阿里云20+位云原生技术专家共同编撰的《云原生架构白皮书》正式对外发布。据官方介绍，本书涵盖了云原生架构的产生缘由、阿里云对于云原生架构的定义、目前行业领先的云原生技术、阿里巴巴的云原生架构设计、云原生架构的实践案例、云原生架构未来发展趋势等内容。

下载地址：

https://developer.aliyun.com/topic/cn-architecture-paper

阿里云以自身实践与服务百万付费用户的丰富实践经验为基础。从云原生架构定义出发，构建基于实际业务场景的完整云原生架构体系。为企业CTO/CIO提供战略参考，为广大研发工程师提供业务洞察，助力云上客户建立最具业务价值的云原生架构。

整个白皮书分了7个部分的内容，准备一次对每个部分内容做个说明。

为什么需要云原生架构

对于企业的 CIO 而言，原来企业内部 IT 建设以“烟筒”模式比较多，每个部门甚至每个应用都相对独立，如何管理与分配资源成了难题。大家都基于最底层 IDC 设施独自向上构建，都需要单独分配硬件资源，这就造成资源被大量占用且难以被共享。

但是上云之后，由于云厂商提供了统一的IaaS 能力和云服务，大幅提升了企业 IaaS 层的复用程度，CIO 或者 IT 主管自然而然想到 IaaS 以上层的系统也需要被统一，使资源、产品可被不断复用，从而能够进一步降低企业运营成本。

所有这些问题都指向一个共同点，那就是云的时代需要新的技术架构，来帮助企业应用能够更好地利用云计算优势，充分释放云计算的技术红利，让业务更敏捷、成本更低的同时又可伸缩性更灵活，而这些正好就是云原生架构专注解决的技术点。

具体内容解读：

对于云计算技术发展这么多年，可以看到类似阿里，华为，腾讯等各大公有云服务厂商推出的IaaS云资源池，提供弹性计算和弹性存储能力已经被大部分企业所接受。即很多企业已经从自建IDC数据中心，转变为直接使用公有云提供的弹性计算和存储服务能力。

而当前企业面临数字化转型，面临更加激烈竞争的市场环境，对企业本身的业务敏捷响应能力要求也更加急迫。那么在这种背景下自然带来新的问题，就是企业的IT系统如何能够更加快速敏捷的响应业务需求，能够实现高效率的从设计开发到云端环境的自动化交付能力，能够在保证最低成本投入情况下实现IT应用已有的高可用性和弹性扩展能力。

当你在单纯的使用IaaS资源池的时候，你开发的IT系统的技术平台，架构，开发过程方法等云服务商都不需要关心，但是到了敏捷高效的云端交付阶段，那么实际对企业自动的IT应用架构，开发过程方法等都会提出更高的要求和需求。

当然，企业在整个应用交付过程中，也存在明确的需求如下：

• 敏捷性的需求：如何更加高效，快捷的进行应用集成交付
• 技术人员需求：企业IT团队人员应该更加关注业务功能实现而非技术底层
• 可运维需求：IT系统应该可运维，同时方便后续敏捷变更迭代
• 成本需求：在最低成本投入的情况下保证高可用性和高安全性

而以上就是需要云原生架构的关键原因，至于云原生架构里面提到的微服务，DevOps，容器云，持续集成和交付等都是为了上述目标达成而努力。

再次重申我原来的一个观点，即云原生架构的推出，核心目标就是方便企业能够更加高效敏捷的使用云平台各类服务能力，同时实现企业IT应用快速向云端持续交付。

云原生架构定义

对于Cloud Native翻译为云原生，是Matt Stine提出的一个概念，它是一个思想的集合，包括DevOps、持续交付(Continuous Delivery)、微服务(MicroServices)、敏捷基础设施(Agile Infrastructure)、康威定律(Conways Law)等，以及根据商业能力对公司进行重组。Cloud Native既包含技术(微服务，敏捷基础设施)，也包含管理(DevOps，持续交付，康威定律，重组等)。

因此云原生是一系列Cloud技术、企业管理方法的集合。在一般用法中，“云原生”是一种构建和运行应用程序的方法，它利用了云计算交付模型的优势。“云原生”是关于如何创建和部署应用程序，和位置无关。 这意味着应用程序位于云中，而不是传统数据中心。

在白皮书里面，阿里从技术角度给出了云原生架构的一个定义如下：

从技术的角度，云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性(如弹性、韧性、安全、可观测性、灰度等)，使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。

简单来说，云原生架构解决的一个核心问题就是IT系统和应用的开发只需要关注业务功能需求实现，而对于其它的IT基础设施，技术平台，消息缓存等各类技术服务等和业务无关的东西都不需要关心，而应该由云平台来提供。其次，云平台提供一种方便应用开发和集成的工具和平台，来实现持续集成和交付。

从上图可以看到增加了PaaS层内容，对于狭义的PaaS平台更多的是实现中间件应用资源池，实现应用自动化部署和资源动态扩展能力，即我们常说的APaaS内容，但是到了云原生的PaaS需要进一步实现。

• 数据库资源池能力，即数据库即服务
• 各类技术服务能力，类似消息，缓存，通知，日志等
• 持续集成能力，即我们说的DevOps过程支撑能力

各类和业务无关的技术服务都应该由云平台来提供，即业务代码的开发人员技能栈中，不再需要掌握文件及其分布式处理技术，不再需要掌握各种复杂的网络技，通过这种简化让业务开发变得更敏捷、更快速。

软件一旦开发完成，需要在公司内外部各类环境中部署和交付，以将软件价值交给最终客户。基于云原生的自动化软件交付相比较当前的人工软件交付是一个巨大的进步。以微服务为例，应用微服务化以后，往往被部署到成千上万个节点上，如果系统不具备高度的自动化能力，任何一次新业务的上线，都会带来极大的工作量挑战，严重时还会导致业务变更超过上线窗口而不可用。

云原生架构原则

书里面转了谈了云原生架构的原则，在这里我们可以简单总结下。

即云原生架构的原则就是应该方便企业IT应用持续，高效敏捷，高可用，低成本的向云端环境交付。要实现这个特点，我们可以看到。

• 持续交付：涉及到微服务化，DevOps和容器云能力
• 高可用性：既涉及到应用本书的高可用性设计，也涉及云平台的高可靠和安全
• 低成本：云平台具备弹性扩展能力，按需使用

主要架构模式

服务化架构是云时代构建云原生应用的标准架构模式，要求以应用模块为颗粒度划分一个软件，以接口契约(例如 IDL)定义彼此业务关系，以标准协议(HTTP、gRPC 等)确保彼此的互联互通，结合DDD(领域模型驱动)、TDD(测试驱动开发)、容器化部署提升每个接口的代码质量和迭代速度。服务化架构的典型模式是微服务和小服务(Mini Service)模式。

其次就是ServiceMesh服务网格，Mesh 化架构是把中间件框架(比如 RPC、缓存、异步消息等)从业务进程中分离，让中间件 SDK与业务代码进一步解耦，从而使得中间件升级对业务进程没有影响，甚至迁移到另外一个平台的中间件也对业务透明。

也就是我们常说的通过Mesh化实现在彻底去中心化的方式下完成微服务治理工作。

ServerLess无服务器化则是云原生的一个终极期望目标，虽然短期难以实现。但是在无服务器化下，IT应用和软件的开发才能够彻底不关心数据库和应用中间件，不关心技术平台和开发框架，而只需要关心具体核心业务功能的代码实现，关心服务究竟如何组合和组装。

反模式-单体应用硬拆微服务

在反模式部分这点需要特别拿出来强调，即我们在IT应用建设或传统应用微服务化改造过程中经常犯错的地方，就是不考虑业务逻辑复杂性和底层数据的耦合性，硬拆分为粒度太细的太多微服务，导致后续的集成和管理工作量剧增。

在书里面提到三个典型例子如下：

小规模软件的服务拆分：软件规模不大，团队人数也少，但是为了微服务而微服务，强行把耦合度高、代码量少的模块进行服务化拆分，一次性的发布需要拆分为多个模块分开发布和维护；

数据依赖：服务虽然拆分为多个，但是这些服务的数据是紧密耦合的，于是让这些服务共享数据库，导致数据的变化往往被删除到多个服务中，造成服务间数据依赖；

性能降低：当耦合性很强的模块被拆分为多个微服务后，原来的本地调用变成了分布式调用，从而让响应时间变大了上千倍，导致整个服务链路性能急剧下降。

在我们进行系统微服务化的时候务必不要犯类似的错误。

云原生主要技术

对于云原生的主要技术，实际上在我前面多篇文章里面都有谈到。简单来说就是容器和容器编排技术，微服务，DevOps，ServiceMesh服务网格，Serverless几个关键点。

下面还是基于书里面的顺序脉络，多以上几个关键技术点展开说明下：

容器技术

容器作为标准化软件单元，它将应用及其所有依赖项打包，使应用不再受环境限制，在不同计算环境间快速、可靠地运行。

如上图，容器技术大家都比较清楚了，简单来说和传统虚拟机技术最大区别就是共享操作系统内核，但是又能够通过类似沙箱机制实现资源和进程隔离。由于共享操作系统内核，因此整体整体更加轻量，性能更好，而且资源损耗也最少。

容器编排

一谈到容器，一定会谈到Kubernetes，对于Kubernetes已经成为容器编排的事实标准，被广泛用于自动部署，扩展和管理容器化应用。Kubernetes 提供了分布式应用管理的核心能力，其中就包括了动态资源调度，应用自动化部署和托管，集群心跳监测和自动修复，服务发现和负载均衡，集群弹性伸缩等。

也就是我们常说的PaaS平台中的应用托管和资源动态调度，实际上都需要通过Kubernetes来实现，因此Kubernetes可以理解为容器阶段的核心PaaS应用组件。Kubernetes 的控制平面包含四个主要的组件：API Server、Controller、Scheduler 以及 etcd，具体如下图所示：

微服务

微服务模式将后端单体应用拆分为松耦合的多个子应用，每个子应用负责一组子功能。这些子应用称为“微服务”，多个“微服务”共同形成了一个物理独立但逻辑完整的分布式微服务体系。这些微服务相对独立，通过解耦研发、测试与部署流程，提高整体迭代效率。

此外，微服务模式通过分布式架构将应用水平扩展和冗余部署，从根本上解决了单体应用在拓展性和稳定性上存在的先天架构缺陷。但也要注意到微服务模型也面临着分布式系统的典型挑战：如何高效调用远程方法、如何实现可靠的系统容量预估、如何建立负载均衡体系、如何面向松耦合系统进行集成测试、如何面向大规模复杂关联应用的部署与运维。

书里面提到了微服务架构的发展演进模式，在这里总结如下：

• 第一代：只实现了单体应用的微服务化拆分
• 第二代：增加了服务注册和发现中心，实现集成的API接口治理能力
• 第三代：ServiceMesh服务网格
• 第四代：Serverless无服务器化架构

如上图，实际上从服务网格发展到无服务器化重要有两点。其一是容器层下沉为FaaS服务统一提供能力，其二就是原来微服务进一步拆分为微逻辑或代码片段，不再有开发技术框架概念。

主要微服务技术

Apache Dubbo 作为源自阿里巴巴的一款开源高性能 RPC 框架，特性包括基于透明接口的 RPC、智能负载均衡、自动服务注册和发现、可扩展性高、运行时流量路由与可视化的服务治理。经过数年发展已是国内使用最广泛的微服务框架并构建了强大的生态体系。

为了巩固 Dubbo 生态的整体竞争力，2018 年阿里巴巴陆续开源了 Spring-Cloud Alibaba( 分布式应用框架 )、Nacos( 注册中心 & 配置中心 )、Sentinel( 流控防护 )、Seata( 分布式事务 )、Chaosblade( 故障注入 )，以便让用户享受阿里巴巴十年沉淀的微服务体系，获得简单易用、高性能、高可用等核心能力。Dubbo 在 v3 中发展 Service Mesh，目前 Dubbo 协议已经被 Envoy 支持，数据层选址、负载均衡和服务治理方面的工作还在继续，控制层目前在继续丰富 Istio/Pilot-discovery 中。

Serverless无服务器化

Serverless是一种构建和管理基于微服务架构的完整流程，允许你在服务部署级别而不是服务器部署级别来管理你的应用部署。它与传统架构的不同之处在于，完全由第三方管理，由事件触发，存在于无状态(Stateless)、暂存(可能只存在于一次调用的过程中)计算容器内。

我在前面一篇文章里面谈到过，在Servverless架构下可以看到没有复杂的开发框架，也没有重的中间件容器，只有一个个新粒度的微服务API，微功能的实现，这些实现也不存在传统的打包和部署动作。也就是说整个软件的开发过程实现完全的面向服务化，你可以使用第三方已有的服务，你开发完成的微功能也是服务，你呈现给用户的是多个服务的串联和组装。

在这种场景下没有任何的中间件资源需要你去关心和维护，类似传统模式下我们可能需要关心和运维我们的数据库，关心和运维我们的Tomcat容器服务器，我们有复杂的编译构建，打包部署动作，而这些在无服务器架构模式下都没有了。体现出现的是函数或事件，而函数本身也是服务。

在本书里面，阿里也给出了一个对比表格如下：

可以看到Servverless架构粒度更加细，更加轻量高效，弹性效率也更高，而且按量计费的模式也更加灵活。对于书里面也给出了Servverless架构的一些适用场景，如下：

• 小程序 /Web/Mobile/API 后端服务
• 大规模批处理任务
• 基于事件驱动架构的在线应用和离线数据处理

所以可以看到当前Servverless架构和应用还是具有很大的局限性，对于企业传统IT应用的开发并不适合采用Servverless架构进行。

ServiceMesh服务网格

Service Mesh 是分布式应用在微服务软件架构之上发展起来的新技术，旨在将那些微服务间的连接、安全、流量控制和可观测等通用功能下沉为平台基础设施，实现应用与平台基础设施的解耦。这个解耦意味着开发者无需关注微服务相关治理问题而聚焦于业务逻辑本身，提升应用开发效率并加速业务探索和创新。

换句话说，因为大量非功能性从业务进程剥离到另外进程中，Service Mesh 以无侵入的方式实现了应用轻量化，下图展示了 Service Mesh 的典型架构。

对于ServiceMesh服务网格，可以很方便的和K8s和容器技术进行集成，在镜像制作阶段自动下发边车代理。因此服务网格我始终任务是在云原生架构和解决方案下，解决微服务治理问题的关键技术，必将得到更加广泛的应用。

DevOps持续集成和交付

对于DevOps我在前面很多文章都谈到过，要特别注意的就是DevOps不仅仅是一系列开源的技术和工具的融合，更加重要的是一种持续集成的思维和敏捷的文化。

文化、自动化、度量和共享四个方面相辅相成，独立而又相互联系，所以要落实 DevOps 时，要统一考虑。通过 CAMS 也认识到，CI/CD 仅仅是实现 DevOps 中很小的一部分。DevOps 不仅仅是一组工具，更重要是代表了一种文化，一种心智。

对于DevOps详细内容可以参考我前面文章：

阿里云原生架构设计方法

在该书里面，阿里还给出了一个云原生的4+1架构设计模型ACNA。

ACNA 是一个 「4+1」 的架构设计流程，「4」 代表架构设计的关键视角，包括企业战略视角、业务发展视角、组织能力视角和云原生技术架构视角；「1」 表示云原生架构的架构持续演进闭环。4 个架构视角和一个闭环的关系如下图。

ACNA 除了是一个架构设计方法，也包含了对云原生架构的评估体系、成熟度衡量体系、行业应用最佳实践、技术和产品体系、架构原则、实施指导等。

ACNA将云原生化分割成服务化能力(Service)、弹性能力(Elasticity)、无服务器化程度(Serverless)、可观测行(Observability)、韧性能力(Resilience)、自动化水平(Automation)六个不同维度(SESORA)，每个评估维度设立ASNA-1至ASNA-4 四个不同等级并依次计作0至3分，同时设立零级、基础级、发展级、成熟级四个不同成熟等级。

云原生架构成熟度模型的提出，对企业云原生化现状、能力和发展路径不清晰等问题, 给出评估与优化方向，帮助企业走上数字化转型“最短路径”。

对于这个成熟度模型，我们再做下初步的分析如下：

对于自动化能力，在二级就需要具备基于容器的CI/CD能力，到了三级和四级只是更加的自动化和智能化。可以看到DevOps是整原生的一个基础。

对于可观测性而言，在二级就需要在资源池和日志监控的基础上具备完整的APM应用性能监控能力，而到了三级更加强调在一个大规模，分布式的软硬件环境下的链路监控能力和性能度量分析，问题诊断能力，以实现持续的性能优化。

对于无服务化程度这个维度很有意义，即我们希望的就是一些底层资源和基础设施都应该服务化，其中最难的就是我们常说的数据库资源的服务化，即表格里面说的有状态存储的服务化和云化，到了三级阶段这点就必须实现了。

弹性计算和扩展，二级还可以是半自动或半闭环，但是到了三级希望就是全部自动化和闭环，而这个跟数据库本身的服务化关系紧密，如果数据库没有服务化就很难完全做到全自动扩展。

对于服务化能力在二级你只需要具备基础的微服务治理能力即可，但是到了三级必须实现全面的服务化并建立服务治理管控体系，到了四级即更加强调基于ServiceMesh服务网格的思路来构建分布式，去中心化的微服务治理管控体系。

---

注：对于阿里云原生产品介绍，云原生案例，云原生趋势分析三个部分的内容，准备后续再单独开一篇文章来进行说明。