云原生架构白皮书GA-v20 7-21 (it-ebooks) (Z-Library)

白皮书 The Cloud-native Architecture White Paper by Alibaba Cloud 生于云 长于云 爆发于云 企业数字化转型最短路径 云 原 生 架 构 The Cloud-native architecture w hitebook by alibaba cloud

编写说明 顾问组成员 定义贡献者（征集活动优选） 编写组成员（按目录排序） 编写单位：阿里云计算有限公司 阿里云 蒋江伟 贾扬清 丁宇 蚂蚁集团 何征宇 陈启涛、莫哈韦、郑富林、王炜、杨树宇、李皓伟 阿里云 李小平 易立 司徒放 杨浩然 李响 罗毅 张磊 李艳林 张瓅玶 赵燕标 赵林 谢纯良 邱戈川 员海滨 崔飞飞 张勇 付宇轩 许晓斌 雷卷 特步 王海能

3 1 2 5 6 7 3 4 3 5 7 9 13 45 45 46 47 47 48 48 49 50 53 55 57 60 63 67 68 15 18 23 27 31 33 38 40 41 41 42 42 43 44 CONTENT The Cloud-native Architecture White Paper by Alibaba Cloud 云原生架构 为什么需要云原生架构？ 云原生架构的定义 主要云原生技术 阿里巴巴云原生架构设计 阿里云云原生产品介绍 云原生架构实践案例 云原生架构未来发展趋势 序 云原生架构定义 云原生架构原则 主要架构模式 典型的云原生架构反模式 容器技术 云原生微服务 Serverless 开放应用模型 （OAM） Service Mesh 技术 DevOps 云原生中间件 ACNA（Alibaba Cloud Native Architecting）架构设计方法 企业战略视角 业务发展视角 组织能力视角 云原生技术架构视角 架构持续演进闭环 云原生架构成熟度模型 云原生产品家族 容器产品家族 微服务产品家族 Serverless 产品家族 Service Mesh 产品家族 消息产品家族 云原生数据库产品家族 云原生数仓产品家族 案例一： 申通快递核心业务系统云原生化上云 案例 案例二： 完美日记电商业务案例 案例三： 特步业务中台案例 （零售、公共云） 案例四： 中国联通号卡业务云化案例 （传统业 务，专有云） 案例五：Timing App 的 Serverless 实践案例 容器技术发展趋势 基于云原生的新一代应用编程界面 Serverless 发展趋势

回顾过去十年，数字化转型将科技创新与 商业元素不断融合、重构，重新定义了新业态 下的增长极。商业正在从大工业时代的固化范 式进化成面向创新型商业组织与新商业物种的 崭新模式。随着数字化转型在中国各行业广泛 深入，不管是行业巨头，还是中小微企业都不 得不面对数字化变革带来的未知机遇与挑战。 数字化转型的十年，也是云计算高速发展 的十年，这期间新技术不断演进、优秀开源项 目大量涌现，云原生领域进入“火箭式”发展 阶段。通过树立技术标准与构建开发者生态， 开源将云计算实施逐渐标准化，大幅降低了开 发者对于云平台的学习成本与接入成本。这都 让开发者更加聚焦于业务本身并借助云原生技 术与产品实现更多业务创新，有效提升企业增 长效率，爆发出前所未有的生产力与创造力。 可以说，当云计算重构整个IT产业的同时， 也赋予了企业崭新的增长机遇。正如集装箱的 出现加速了贸易全球化进程，以容器为代表的 云原生技术作为云计算的服务新界面加速云计 算普及的同时，也在推动着整个商业世界飞速 演进。上云成为企业持续发展的必然选择，全 面使用开源技术、云服务构建软件服务的时代 已经到来。作为云时代释放技术红利的新方式， 云原生技术在通过方法论、工具集和最佳实践 重塑整个软件技术栈和生命周期，云原生架构 序 The Cloud-native Architecture White Paper by Alibaba Cloud 对云计算服务方式与互联网架构进行整体性升 级，深刻改变着整个商业世界的 IT 根基。 虽然云原生概念的产生由来已久，但对于 云原生的定义、云原生架构的理解却众说纷纭。 到底什么是云原生？容器就代表云原生吗？云 原生时代互联网分布式架构如何发展？云原生 与开源、云计算有什么关系？开发者和企业为 什么一定要选择云原生架构？面对这些问题， 每个人都有着不同回答。鉴于此，阿里云结合 自身云原生开源、云原生技术、云原生产品、 云原生架构以及企业客户上云实践经验，给出 了自己的答案，并通过这本白皮书与社会分享 自己的思考与总结，旨在帮助越来越多的企业 顺利找到数字化转型最短路径。 未来十年，云计算将无处不在，像水电煤 一样成为数字经济时代的基础设施，云原生让 云计算变得标准、开放、简单高效、触手可及。 如何更好地拥抱云计算、拥抱云原生架构、用 技术加速创新，将成为企业数字化转型升级成 功的关键。 云计算的下一站，就是云原生； IT 架构的下一站，就是云原生架构 ; 希望所有的开发者、架构师和技术决策者 们，共同定义、共同迎接云原生时代。

5 为什么需要云原生架构？ 发展背景 计算机软件技术架构进化有两大主要驱动因素，一个是底层硬件升级，另一个是顶层业务发展诉求。 正如伴随着 x86 硬件体系的成熟，很多应用不再使用昂贵、臃肿的大中型机，转而选择价格更为低廉的 以 x86 为主的硬件体系，也由此诞生了包括 CORBA、EJB、RPC 在内的各类分布式架构；后由于互 联网业务飞速发展，人们发现传统 IOE 架构已经不能满足海量业务规模的并发要求，于是又诞生了阿里 巴巴 Dubbo & RocketMQ、Spring Cloud 这样的互联网架构体系。 云计算从工业化应用到如今，已走过十五个年头，然而大量应用使用云的方式仍停滞在传统 IDC 时代： 虚拟机代替了原来的物理机：使用文件保存应用数据，大量自带的三方技术组件，没有经过架构改造（如 微服务改造）的应用上云，传统的应用打包与发布方式等等。对于如何使用这些技术，没有绝对的对与错， 只是在云的时代不能充分利用云的强大能力，不能从云技术中获得更高的可用性与可扩展能力，也不能 利用云提升发布和运维的效率，是一件非常遗憾的事情。 回顾近年来商业世界的发展趋势，数字化转型的出现使得企业中越来越多的业务演变成数字化业务， 数字化对于业务渠道、竞争格局、用户体验等诸多方面都带来更加严苛的要求，这就要求技术具备更快 的迭代速度，业务推出速度从按周提升到按小时，每月上线业务量从“几十 / 月”提升到“几百 / 天”。 大量数字化业务重构了企业的业务流水线，企业要求这些业务不能有不可接受的业务中断，否则会对客 户体验以及营收可能造成巨大影响。 对于企业的 CIO 或者 IT 主管而言，原来企业内部 IT 建设以“烟筒”模式比较多，每个部门甚至每 个应用都相对独立，如何管理与分配资源成了难题。大家都基于最底层 IDC 设施独自向上构建，都需要 单独分配硬件资源，这就造成资源被大量占用且难以被共享。但是上云之后，由于云厂商提供了统一的 IaaS 能力和云服务，大幅提升了企业 IaaS 层的复用程度，CIO 或者 IT 主管自然而然想到 IaaS 以上层 的系统也需要被统一，使资源、产品可被不断复用，从而能够进一步降低企业运营成本。 所有这些问题都指向一个共同点，那就是云的时代需要新的技术架构，来帮助企业应用能够更好地利 用云计算优势，充分释放云计算的技术红利，让业务更敏捷、成本更低的同时又可伸缩性更灵活，而这 些正好就是云原生架构专注解决的技术点。 1

6 今天云原生的定义有众多版本，云原生架构的理解也不尽相同，阿里将根据自身的云原生技术、产品 和上云实践，给出自己的理解。 从技术的角度，云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的 非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、 可观测性、灰度等），使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。 上图展示了在代码中通常包括三部分：业务代码、三方软件、处理非功能特性的代码。其中“业务代 码”指实现业务逻辑的代码；“三方软件”是业务代码中依赖的所有三方库，包括业务库和基础库；“处 理非功能性的代码”指实现高可用、安全、可观测性等非功能性能力的代码。 三部分中只有业务代码是核心，是对业务真正带来价值的，另外两个部分都只算附属物，但随着软件 规模的增大、业务模块规模变大、部署环境增多、分布式复杂性增强，使得今天的软件构建变得越来越复杂， 云原生架构的定义 2 云原生架构定义1 开发人员 运维人员 代码 传统架构 云原生架构 非功能性能力 基础设施运维 业务运维 业务代码编写 三方软件使用 代码 非功能性能力 IaaS 业务运维 PaaS 业务代码编写 三方软件调用 云原生架构与传统架构的对比

7 Th e Cl ou d- na tiv e A rc hi te ct ur e W hi te P ap er b y A lib ab a Cl ou d 对开发人员的技能要求也越来越高。云原生架构相比较传统架构进了一大步，从业务代码中剥离了大量 非功能性特性（不会是所有，比如易用性还不能剥离）到 IaaS 和 PaaS 中，从而减少业务代码开发人 员的技术关注范围，通过云厂商的专业性提升应用的非功能性能力。 此外，具备云原生架构的应用可以最大程度利用云服务和提升软件交付能力，进一步加快软件开发： 云原生架构产生的最大影响就是让开发人员的编程模型发生了巨大变化。今天大部分的编程语言中， 都有文件、网络、线程等元素，这些元素为充分利用单机资源带来好处的同时，也提升了分布式编程的 复杂性；因此大量框架、产品涌现，来解决分布式环境中的网络调用问题、高可用问题、CPU 争用问题、 分布式存储问题 …… 在云的环境中，比如“如何获取存储”变成了若干服务，包括对象存储服务、块存储服务和没有随机 访问的文件存储服务。云不仅改变了开发人员获得这些存储能力的界面，还在于云产品在这些 OpenAPI 或者开源 SDK 背后把分布式场景中的高可用挑战、自动扩缩容挑战、安全挑战、运维升级挑战等都处理 了，应用的开发人员就不用在其代码中处理节点宕机前如何把本地保存的内容同步到远端的问题，也不 用处理当业务峰值到来时如何对存储节点进行扩容的问题，而应用的运维人员不用在发现 zero day 安全 问题时紧急对三方存储软件进行升级 …… 云把三方软硬件的能力升级成了服务，开发人员的开发复杂度和运维人员的运维工作量都得到极大降 低。显然，如果这样的云服务用得越多，那么开发和运维人员的负担就越少，企业在非核心业务实现上 从必须的负担变成了可控支出。在一些开发能力强的公司中，对这些三方软硬件能力的处理往往是交给 应用框架（或者说公司内自己的中间件）来做的；在云的时代云厂商提供了更具 SLA 的服务，使得所有 软件公司都可以由此获益。 这些使得业务代码的开发人员技能栈中，不再需要掌握文件及其分布式处理技术，不再需要掌握各种 复杂的网络技术 …… 简化让业务开发变得更敏捷、更快速！ 任何应用都提供两类特性，功能性特性和非功能性特性。功能性特性是真正为业务带来价值的代码， 比如如何建立客户资料、如何处理订单、如何支付等等；即使是一些通用的业务功能特性，比如组织管理、 业务字典管理、搜索等等也是紧贴业务需求的。非功能性特性是没有给业务带来直接业务价值，但通常 又是必不可少的特性，比如高可用能力、容灾能力、安全特性、可运维性、易用性、可测试性、灰度发 布能力等等。 1 2 代码结构发生巨大变化 非功能性特性的大量委托

8 The Cloud-native Architecture White Paper 不能说云计算解决了所有非功能性问题，但确实大量非功能性特性，特别是分布式环境下复杂非功能 性问题，被云产品处理掉了。以大家最头疼的高可用为例，云产品在多个层面为应用提供了解决方案： 虚机：当虚机检测到底层硬件异常时，自动帮助应用做热迁移，迁移后的应用不需重新启动而仍然具 备对外服务的能力，应用对整个迁移过程都不会有任何感知； 容器：有时应用所在的物理机是正常的，只是应用自身的问题（比如 bug、资源耗尽等）而无法正常 对外提供服务。容器通过监控检查探测到进程状态异常，从而实施异常节点的下线、新节点上线和生产 流量的切换等操作，整个过程自动完成而无需运维人员干预； 云服务：如果应用把“有状态”部分都交给了云服务（如缓存、数据库、对象存储等），加上全局对 象的持有小型化或具备从磁盘快速重建能力，由于云服务本身是具备极强的高可用能力，那么应用本身 会变成更薄的“无状态”应用，因为高可用故障带来的业务中断会降至分钟级；如果应用是 N-M 的对等 架构架构模式，那么结合 Load Balancer 产品可获得几乎无损的高可用能力！ 软件一旦开发完成，需要在公司内外部各类环境中部署和交付，以将软件价值交给最终客户。软件交 付的困难在于开发环境到生产环境的差异（公司环境到客户环境之间的差异）以及软件交付和运维人员 的技能差异，填补这些差异的是一大堆安装手册、运维手册和培训文档。容器以一种标准的方式对软件 打包，容器及相关技术则帮助屏蔽不同环境之间的差异，进而基于容器做标准化的软件交付。 对自动化交付而言，还需要一种能够描述不同环境的工具，让软件能够“理解”目标环境、交付内容、 配置清单并通过代码去识别目标环境的差异，根据交付内容以“面向终态”的方式完成软件的安装、配置、 运行和变更。 基于云原生的自动化软件交付相比较当前的人工软件交付是一个巨大的进步。以微服务为例，应用微 服务化以后，往往被部署到成千上万个节点上，如果系统不具备高度的自动化能力，任何一次新业务的 上线，都会带来极大的工作量挑战，严重时还会导致业务变更超过上线窗口而不可用。 云原生架构本身作为一种架构，也有若干架构原则作为应用架构的核心架构控制面，通过遵从这些架 构原则可以让技术主管和架构师在做技术选择时不会出现大的偏差。 3 高度自动化的软件交付 云原生架构原则2

9 Th e Cl ou d- na tiv e A rc hi te ct ur e W hi te P ap er b y A lib ab a Cl ou d 当代码规模超出小团队的合作范围时，就有必要进行服务化拆分了，包括拆分为微服务架构、小服务 （Mini Service）架构，通过服务化架构把不同生命周期的模块分离出来，分别进行业务迭代，避免迭 代频繁模块被慢速模块拖慢，从而加快整体的进度和稳定性。同时服务化架构以面向接口编程，服务内 部的功能高度内聚，模块间通过公共功能模块的提取增加软件的复用程度。 分布式环境下的限流降级、熔断隔仓、灰度、反压、零信任安全等，本质上都是基于服务流量（而非 网络流量）的控制策略，所以云原生架构强调使用服务化的目的还在于从架构层面抽象化业务模块之间 的关系，标准化服务流量的传输，从而帮助业务模块进行基于服务流量的策略控制和治理，不管这些服 务是基于什么语言开发的。 大部分系统部署上线需要根据业务量的估算，准备一定规模的机器，从提出采购申请，到供应商洽谈、 机器部署上电、软件部署、性能压测，往往需要好几个月甚至一年的周期；而这期间如果业务发生变化了， 重新调整也非常困难。弹性则是指系统的部署规模可以随着业务量的变化自动伸缩，无须根据事先的容 量规划准备固定的硬件和软件资源。好的弹性能力不仅缩短了从采购到上线的时间，让企业不用操心额 外软硬件资源的成本支出（闲置成本），降低了企业的 IT 成本，更关键的是当业务规模面临海量突发性 扩张的时候，不再因为平时软硬件资源储备不足而“说不”，保障了企业收益。 今天大部分企业的软件规模都在不断增长，原来单机可以对应用做完所有调试，但在分布式环境下需 要对多个主机上的信息做关联，才可能回答清楚服务为什么宕机、哪些服务违反了其定义的 SLO、目前 的故障影响哪些用户、最近这次变更对哪些服务指标带来了影响等等，这些都要求系统具备更强的可观 测能力。可观测性与监控、业务探活、APM 等系统提供的能力不同，前者是在云这样的分布式系统中， 主动通过日志、链路跟踪和度量等手段，让一次 APP 点击背后的多次服务调用的耗时、返回值和参数都 清晰可见，甚至可以下钻到每次三方软件调用、SQL 请求、节点拓扑、网络响应等，这样的能力可以使 运维、开发和业务人员实时掌握软件运行情况，并结合多个维度的数据指标，获得前所未有的关联分析 能力，不断对业务健康度和用户体验进行数字化衡量和持续优化。 1 2 3 服务化原则 弹性原则 可观测原则 当业务上线后，最不能接受的就是业务不可用，让用户无法正常使用软件，影响体验和收入。韧性代 表了当软件所依赖的软硬件组件出现各种异常时，软件表现出来的抵御能力，这些异常通常包括硬件故障、 4 韧性原则

10 The Cloud-native Architecture White Paper 技术往往是把“双刃剑”，容器、微服务、DevOps、大量第三方组件的使用，在降低分布式复杂性 和提升迭代速度的同时，因为整体增大了软件技术栈的复杂度和组件规模，所以不可避免地带来了软件 交付的复杂性，如果这里控制不当，应用就无法体会到云原生技术的优势。通过 IaC（Infrastructure as Code）、GitOps、OAM（Open Application Model）、Kubernetes operator 和大量自动化交付工 具在 CI/CD 流水线中的实践，一方面标准化企业内部的软件交付过程，另一方面在标准化的基础上进行 自动化，通过配置数据自描述和面向终态的交付过程，让自动化工具理解交付目标和环境差异，实现整 个软件交付和运维的自动化。 零信任安全针对传统边界安全架构思想进行了重新评估和审视，并对安全架构思路给出了新建议。其 核心思想是，默认情况下不应该信任网络内部和外部的任何人 / 设备 / 系统，需要基于认证和授权重构访 问控制的信任基础，诸如 IP 地址、主机、地理位置、所处网络等均不能作为可信的凭证。零信任对访问 控制进行了范式上的颠覆，引导安全体系架构从“网络中心化”走向“身份中心化”，其本质诉求是以 身份为中心进行访问控制。 零信任第一个核心问题就是 Identity，赋予不同的 Entity 不同的 Identity，解决是谁在什么环境下访 问某个具体的资源的问题。在研发、测试和运维微服务场景下，Identity 及其相关策略不仅是安全的基础， 更是众多（资源，服务，环境）隔离机制的基础；在员工访问企业内部应用的场景下，Identity 及其相关 策略提供了灵活的机制来提供随时随地的接入服务。 今天技术和业务的演进速度非常快，很少有一开始就清晰定义了架构并在整个软件生命周期里面都适 用，相反往往还需要对架构进行一定范围内的重构，因此云原生架构本身也应该和必须是一个具备持续 演进能力的架构，而不是一个封闭式架构。除了增量迭代、目标选取等因素外，还需要考虑组织（例如 架构控制委员会）层面的架构治理和风险控制，特别是在业务高速迭代情况下的架构、业务、实现平衡 6 7 零信任原则 架构持续演进原则 硬件资源瓶颈（如 CPU/ 网卡带宽耗尽）、业务流量超出软件设计能力、影响机房工作的故障和灾难、 软件 bug、黑客攻击等对业务不可用带来致命影响的因素。 韧性从多个维度诠释了软件持续提供业务服务的能力，核心目标是提升软件的 MTBF（Mean Time Between Failure，平均无故障时间）。从架构设计上，韧性包括服务异步化能力、重试 / 限流 / 降级 / 熔断 / 反压、主从模式、集群模式、AZ 内的高可用、单元化、跨 region 容灾、异地多活容灾等。 5 所有过程自动化原则

11 Th e Cl ou d- na tiv e A rc hi te ct ur e W hi te P ap er b y A lib ab a Cl ou d 服务化架构是云时代构建云原生应用的标准架构模式，要求以应用模块为颗粒度划分一个软件，以接 口契约（例如 IDL）定义彼此业务关系，以标准协议（HTTP、gRPC 等）确保彼此的互联互通，结合 DDD（领域模型驱动）、TDD（测试驱动开发）、容器化部署提升每个接口的代码质量和迭代速度。服 务化架构的典型模式是微服务和小服务（Mini Service）模式，其中小服务可以看做是一组关系非常密切 的服务的组合，这组服务会共享数据，小服务模式通常适用于非常大型的软件系统，避免接口的颗粒度 太细而导致过多的调用损耗（特别是服务间调用和数据一致性处理）和治理复杂度。 通过服务化架构，把代码模块关系和部署关系进行分离，每个接口可以部署不同数量的实例，单独扩 缩容，从而使得整体的部署更经济。此外，由于在进程级实现了模块的分离，每个接口都可以单独升级， 从而提升了整体的迭代效率。但也需要注意，服务拆分导致要维护的模块数量增多，如果缺乏服务的自 动化能力和治理能力，会让模块管理和组织技能不匹配，反而导致开发和运维效率的降低。 关系。云原生架构对于新建应用而言的架构控制策略相对容易选择（通常是选择弹性、敏捷、成本的维度）， 但对于存量应用向云原生架构迁移，则需要从架构上考虑遗留应用的迁出成本 / 风险和到云上的迁入成本 / 风险，以及技术上通过微服务 / 应用网关、应用集成、适配器、服务网格、数据迁移、在线灰度等应用 和流量进行细颗粒度控制。 Mesh 化架构是把中间件框架（比如 RPC、缓存、异步消息等）从业务进程中分离，让中间件 SDK 与业务代码进一步解耦，从而使得中间件升级对业务进程没有影响，甚至迁移到另外一个平台的中间件 也对业务透明。分离后在业务进程中只保留很“薄”的 Client 部分，Client 通常很少变化，只负责与 Mesh 进程通讯，原来需要在 SDK 中处理的流量控制、安全等逻辑由 Mesh 进程完成。整个架构如下 图所示。 1 2 服务化架构模式 Mesh 化架构模式 云原生架构有非常多的架构模式，这里选取一些对应用收益更大的主要架构模式进行讨论。 主要架构模式3

12 The Cloud-native Architecture White Paper 实施 Mesh 化架构后，大量分布式架构模式（熔断、限流、降级、重试、反压、隔仓……）都由 Mesh 进程完成，即使在业务代码的制品中并没有使用这些三方软件包；同时获得更好的安全性（比如 零信任架构能力）、按流量进行动态环境隔离、基于流量做冒烟 / 回归测试等。 和大部分计算模式不同，Serverless 将“部署”这个动作从运维中“收走”，使开发者不用关心应 用在哪里运行，更不用关心装什么 OS、怎么配置网络、需要多少 CPU …… 从架构抽象上看，当业务 流量到来 / 业务事件发生时，云会启动或调度一个已启动的业务进程进行处理，处理完成后云自动会关闭 / 调度业务进程，等待下一次触发，也就是把应用的整个运行时都委托给云。 今天 Serverless 还没有达到任何类型的应用都适用的地步，因此架构决策者需要关心应用类型 是否适合于 Serverless 运算。如果应用是有状态的，云在进行调度时可能导致上下文丢失，毕竟 Serverless 的调度不会帮助应用做状态同步；如果应用是长时间后台运行的密集型计算任务，会得不到 太多 Serverless 的优势；如果应用涉及到频繁的外部 I/O（网络或者存储，以及服务间调用），也因为 繁重的 I/O 负担、时延大而不适合。Serverless 非常适合于事件驱动的数据计算任务、计算时间短的请 求 / 响应应用、没有复杂相互调用的长周期任务。 分布式环境中的 CAP 困难主要是针对有状态应用，因为无状态应用不存在 C（一致性）这个维度， 因此可以获得很好的 A（可用性）和 P（分区容错性），因而获得更好的弹性。在云环境中，推荐把各 3 4 Serverless 模式 存储计算分离模式 传统架构 业务代码 业务进程 容器/主机 SDK协议 RPC SDK Redis SDK MQ SDK DB SDK 网络 Mesh 化架构 业务代码 Mesh 进程 （流量控制、安全策略、微隔离……） 业务进程 容器/主机 新协议、加密、染色…… SDK协议/标准协议 RPC SDK Redis SDK MQ SDK DB SDK 网络

13 Th e Cl ou d- na tiv e A rc hi te ct ur e W hi te P ap er b y A lib ab a Cl ou d 可观测架构包括 Logging、Tracing、Metrics 三个方面，其中 Logging 提供多个级别（verbose/ debug/warning/error/fatal）的详细信息跟踪，由应用开发者主动提供；Tracing 提供一个请求从前端 到后端的完整调用链路跟踪，对于分布式场景尤其有用；Metrics 则提供对系统量化的多维度度量。 架构决策者需要选择合适的、支持可观测的开源框架（比如 OpenTracing、OpenTelemetry）， 并规范上下文的可观测数据规范（例如方法名、用户信息、地理位置、请求参数等），规划这些可观测 数据在哪些服务和技术组件中传播，利用日志和 tracing 信息中的 span id/trace id，确保进行分布式链 路分析时有足够的信息进行快速关联分析。 由于建立可观测性的主要目标是对服务 SLO（Service Level Objective）进行度量，从而优化 SLA，因此架构设计上需要为各个组件定义清晰的 SLO，包括并发度、耗时、可用时长、容量等。 6 可观测架构 微服务模式提倡每个服务使用私有的数据源，而不是像单体这样共享数据源，但往往大颗粒度的业务 需要访问多个微服务，必然带来分布式事务问题，否则数据就会出现不一致。架构师需要根据不同的场 景选择合适的分布式事务模式。 5 分布式事务模式 传统采用 XA 模式，虽然具备很强的一致性，但是性能差； 基于消息的最终一致性（BASE）通常有很高的性能，但是通用性有限，且消息端只能成功而不能触发消息 生产端的事务回滚； TCC 模式完全由应用层来控制事务，事务隔离性可控，也可以做到比较高效；但是对业务的侵入性非常强， 设计开发维护等成本很高； SAGA 模式与 TCC 模式的优缺点类似但没有 try 这个阶段，而是每个正向事务都对应一个补偿事务，也是 开发维护成本高； 开源项目 SEATA 的 AT 模式非常高性能且无代码开发工作量，且可以自动执行回滚操作，同时也存在一些 使用场景限制。 类暂态数据（如 session）、结构化和非结构化持久数据都采用云服务来保存，从而实现存储计算分离。 但仍然有一些状态如果保存到远端缓存，会造成交易性能的明显下降，比如交易会话数据太大、需要不 断根据上下文重新获取等，则可以考虑通过采用 Event Log + 快照（或 Check Point）的方式，实现重 启后快速增量恢复服务，减少不可用对业务的影响时长。 7 事件驱动架构

14 The Cloud-native Architecture White Paper 增强服务韧性：由于服务间是异步集成的，也就是下游的任何处理失败甚至宕机都不会被上游感知，自然也 就不会对上游带来影响； CQRS（Command Query Responsibility Segregation）：把对服务状态有影响的命令用事件来发起， 而对服务状态没有影响的查询才使用同步调用的 API 接口；结合 EDA 中的 Event Sourcing 可以用于维护 数据变更的一致性，当需要重新构建服务状态时，把 EDA 中的事件重新“播放”一遍即可； 数据变化通知：在服务架构下，往往一个服务中的数据发生变化，另外的服务会感兴趣，比如用户订单 完成后，积分服务、信用服务等都需要得到事件通知并更新用户积分和信用等级； 构建开放式接口：在 EDA 下，事件的提供者并不用关心有哪些订阅者，不像服务调用的场景 —— 数据的产 生者需要知道数据的消费者在哪里并调用它，因此保持了接口的开放性； 事件流处理：应用于大量事件流（而非离散事件）的数据分析场景，典型应用是基于 Kafka 的日志处理； 基于事件触发的响应：在 IoT 时代大量传感器产生的数据，不会像人机交互一样需要等待处理结果的返回， 天然适合用 EDA 来构建数据处理应用。 典型的云原生架构反模式4 技术往往像一把双刃剑，阿里在自己和帮助客户做云原生架构演进的时候，会充分考虑根据不同的场 景选择不同的技术，下面是我们总结的一些典型云原生架构反模式。 庞大单体应用的最大问题在于缺乏依赖隔离，包括代码耦合带来的责任不清、模块间接口缺乏治理而 带来变更影响扩散、不同模块间的开发进度和发布时间要求难以协调、一个子模块不稳定导致整个应用 都变慢、扩容时只能整体扩容而不能对达到瓶颈的模块单独扩容…… 因此当业务模块可能存在多人开发 1 庞大的单体应用 事件和传统的消息不同，事件具有 schema，所以可以校验 event 的有效性，同时 EDA 具备 QoS 保障机制，也能够对事件处理失败进行响应。事件驱动架构不仅用于（微）服务解耦，还可应用于下面 的场景中： E E E E E E Event Producer Topic Event Consumer Subscribe 事件驱动架构（EDA，Event Driven Architecture）本质上是一种应用 / 组件间的集成架构模式， 典型的事件驱动架构如下图：

15 Th e Cl ou d- na tiv e A rc hi te ct ur e W hi te P ap er b y A lib ab a Cl ou d 服务的拆分需要适度，过分服务化拆分反而会导致新架构与组织能力的不匹配，让架构升级得不到技 术红利，典型的例子包括： 软件架构中非常重要的一个维度就是处理软件复杂度问题，一旦问题规模提升了很多，那就必须重新 考虑与之适应的新方案。在很多软件组织中，开发、测试和运维的工作单位都是以进程为单位，比如把 整个用户管理作为一个单独的模块进行打包、发布和运行；而进行了微服务拆分后，这个用户管理模块 可能被分为用户信息管理、基本信息管理、积分管理、订单管理等多个模块，由于仍然是每个模块分别 打包、发布和运行，开发、测试和运维人员的人均负责模块数就直线上升，造成了人均工作量增大，也 就增加了软件的开发成本。 实际上，当软件规模进一步变大后，自动化能力的缺失还会带来更大的危害。由于接口增多会带来测 试用例的增加，更多的软件模块排队等待测试和发布，如果缺乏自动化会造成软件发布时间变长，在多 环境发布或异地发布时更是需要专家来处理环境差异带来的影响。同时更多的进程运行于一个环境中， 缺乏自动化的人工运维容易给环境带来不可重现的影响，而一旦发生人为运维错误又不容易“快速止血”， 造成了故障处理时间变长，以及使得日常运维操作都需要专家才能完成。所有这些问题导致软件交付时 间变长、风险提升以及运维成本的增加。 2 3 单体应用“硬拆”为微服务 缺乏自动化能力的微服务 小规模软件的服务拆分：软件规模不大，团队人数也少，但是为了微服务而微服务，强行把耦合度高、代码 量少的模块进行服务化拆分，一次性的发布需要拆分为多个模块分开发布和维护； 数据依赖：服务虽然拆分为多个，但是这些服务的数据是紧密耦合的，于是让这些服务共享数据库，导致数 据的变化往往被扇出到多个服务中，造成服务间数据依赖； 性能降低：当耦合性很强的模块被拆分为多个微服务后，原来的本地调用变成了分布式调用，从而让响应时 间变大了上千倍，导致整个服务链路性能急剧下降。 的时候，就需要考虑通过服务化进行一定的拆分，梳理聚合根，通过业务关系确定主要的服务模块以及 这些模块的边界、清晰定义模块之间的接口，并让组织关系和架构关系匹配。 阿里巴巴在淘宝业务快速发展阶段，就遇到过上百人维护一个核心单体应用，造成了源码冲突、多团 队间协同代价高的严重问题。为了支撑不断增长的流量，该应用需要不断增加机器，很快后端数据库连 接很快就到达了上限。在还没有“微服务”概念的 2008 年，阿里巴巴决定进行服务化架构拆分，当时 思路就是微服务架构，第一个服务从用户中心开始建设，后续交易、类目、店铺、商品、评价中心等服 务陆续从单体中独立出来，服务之间通过远程调用通信，每个中心由独立团队专门维护，从而解决了研 发协同问题，以及按规模持续水平扩展的问题。

16 容器作为标准化软件单元，它将应用及其所有依赖项打包，使应用不再受环境限制，在不同计算环境 间快速、可靠地运行。 虽然 2008 年 Linux 就提供了 Cgroups 资源管理机制、Linux Namespace 视图隔离方案，让应 用得以运行在独立沙箱环境中，避免相互间冲突与影响；但直到 Docker 容器引擎的开源，才很大程度 上降低了容器技术的使用复杂性，加速了容器技术普及。Docker 容器基于操作系统虚拟化技术，共享操 作系统内核、轻量、没有资源损耗、秒级启动，极大提升了系统的应用部署密度和弹性。更重要的是， Docker 提出了创新的应用打包规范 —— Docker 镜像，解耦了应用与运行环境，使应用可以在不同计 算环境间一致、可靠地运行。借助容器技术呈现了一个优雅的抽象场景：让开发所需要的灵活性、开放 性和运维所关注的标准化、自动化达成相对平衡。容器镜像迅速成为了应用分发的工业标准。 传统、虚拟化及容器部署模式比较 容器技术1 APP Bin / Library Operating System Hypervisor Operating System Hardware APP APP APP Operating System Hardware Virtual Machine Virtual Machine Operating System Bin / Library APP APP APP APP APP APP Bin / Library Bin / Library Bin / Library Container Runtime Operating System Hardware Container Container Container 1 容器技术背景与价值 Traditional Deployment Virtualized Deployment Container Deployment 主要云原生技术 3

17 随后开源的 Kubernetes，凭借优秀的开放性、可扩展性以及活跃开发者社区，在容器编排之战中脱颖而出，成 为分布式资源调度和自动化运维的事实标准。Kubernetes 屏蔽了 IaaS 层基础架构的差异并凭借优良的可移植性， 帮助应用一致地运行在包括数据中心、云、边缘计算在内的不同环境。企业可以通过 Kubernetes，结合自身业务特 征来设计自身云架构，从而更好支持多云 / 混合云，免去被厂商锁定的顾虑。伴随着容器技术逐步标准化，进一步促 进了容器生态的分工和协同。基于 Kubernetes，生态社区开始构建上层的业务抽象，比如服务网格 Istio、机器学 习平台 Kubeflow、无服务器应用框架 Knative 等。 在过去几年，容器技术获得了越发广泛的应用的同时，三个核心价值最受用户关注： • 敏捷 • 弹性 •可移植性 容器技术提升企业 IT 架构敏捷性的同时，让业务迭代更加迅捷，为创新探索提供了坚实的技术保障。比如 疫情期间，教育、视频、公共健康等行业的在线化需求突现爆发性高速增长，很多企业通过容器技术适时把握了 突如其来的业务快速增长机遇。据统计，使用容器技术可以获得 3~10 倍交付效率提升，这意味着企业可以更快 速的迭代产品，更低成本进行业务试错。 在互联网时代，企业 IT 系统经常需要面对促销活动、突发事件等各种预期内外的爆发性流量增长。通过容 器技术，企业可以充分发挥云计算弹性优势，降低运维成本。一般而言，借助容器技术，企业可以通过部署密度 提升和弹性降低 50% 的计算成本。以在线教育行业为例，面对疫情之下指数级增长的流量，教育信息化应用工 具提供商希沃 Seewo 利用阿里云容器服务 ACK 和弹性容器实例 ECI 大大满足了快速扩容的迫切需求，为数 十万名老师提供了良好的在线授课环境，帮助百万学生进行在线学习。 容器已经成为应用分发和交付的标准技术，将应用与底层运行环境进行解耦；Kubernetes 成为资源调度 和编排的标准，屏蔽了底层架构差异性，帮助应用平滑运行在不同基础设施上。CNCF 云原生计算基金会推出 了 Kubernetes 一致性认证，进一步保障了不同 K8s 实现的兼容性，这也让企业愿意采用容器技术来构建云时 代应用基础设施。 Kubernetes 已经成为容器编排的事实标准，被广泛用于自动部署，扩展和管理容器化应用。Kubernetes 提 供了分布式应用管理的核心能力： 2 容器编排 资源调度：根据应用请求的资源量 CPU、Memory，或者 GPU 等设备资源，在集群中选择合适的节点来运 行应用； 应用部署与管理：支持应用的自动发布与应用的回滚，以及与应用相关的配置的管理；也可以自动化存储卷 的编排，让存储卷与容器应用的生命周期相关联； Th e Cl ou d- na tiv e A rc hi te ct ur e W hi te P ap er b y A lib ab a Cl ou d

18 Kubernetes 的控制平面包含四个主要的组件：API Server、Controller、Scheduler 以及 etcd。如 下图所示： Container Runtime Cloud Provider Netword Edge End Users Pods System Services Node 1 Ctrl Plane - 1,2...n kubelet etcd controller manager kube API server scheduler Container Runtime Pods System Services Node 2 kubelet Load Balancer kubectl 自动修复：Kubernetes 可以会监测这个集群中所有的宿主机，当宿主机或者 OS 出现故障，节点健康检查 会自动进行应用迁移；K8s 也支持应用的自愈，极大简化了运维管理的复杂性； 服务发现与负载均衡：通过 Service 资源出现各种应用服务，结合 DNS 和多种负载均衡机制，支持容器化 应用之间的相互通信； 弹性伸缩：K8s 可以监测业务上所承担的负载，如果这个业务本身的 CPU 利用率过高，或者响应时间过长， 它可以对这个业务进行自动扩容。 声明式 API：开发者可以关注于应用自身，而非系统执行细节。比如 Deployment（无状态应用）、 StatefulSet（有状态应用）、Job（任务类应用）等不同资源类型，提供了对不同类型工作负载的抽象；对 Kubernetes 实现而言，基于声明式 API 的 “level-triggered” 实现比 “edge-triggered” 方式可以提 供更加健壮的分布式系统实现。 可扩展性架构：所有 K8s 组件都是基于一致的、开放的 API 实现和交互；三方开发者也可通过 CRD（Custom Resource Definition）/Operator 等方法提供领域相关的扩展实现，极大提升了 K8s 的能力。 Kubernetes 在容器编排中有几个关键设计理念： The Cloud-native Architecture White Paper

19 可移植性：K8s 通过一系列抽象如 Loadbalance Service （负载均衡服务）、CNI（容器网络接口）、CSI（容 器存储接口），帮助业务应用可以屏蔽底层基础设施的实现差异，实现容器灵活迁移的设计目标。 云原生微服务2 1 2 微服务发展背景 微服务设计约束 过去开发一个后端应用最为直接的方式就是通过单一后端应用提供并集成所有的服务，即单体模式。随着 业务发展与需求不断增加，单体应用功能愈发复杂，参与开发的工程师规模可能由最初几个人发展到十几人， 应用迭代效率由于集中式研发、测试、发布、沟通模式而显著下滑。为了解决由单体应用模型衍生的过度集中 式项目迭代流程，微服务模式应运而生。 微服务模式将后端单体应用拆分为松耦合的多个子应用，每个子应用负责一组子功能。这些子应用称为“微 服务”，多个“微服务”共同形成了一个物理独立但逻辑完整的分布式微服务体系。这些微服务相对独立，通 过解耦研发、测试与部署流程，提高整体迭代效率。此外，微服务模式通过分布式架构将应用水平扩展和冗余 部署，从根本上解决了单体应用在拓展性和稳定性上存在的先天架构缺陷。但也要注意到微服务模型也面临着 分布式系统的典型挑战：如何高效调用远程方法、如何实现可靠的系统容量预估、如何建立负载均衡体系、如 何面向松耦合系统进行集成测试、如何面向大规模复杂关联应用的部署与运维…… 在云原生时代，云原生微服务体系将充分利用云资源的高可用和安全体系，让应用获得更有保障的弹性、 可用性与安全性。应用构建在云所提供的基础设施与基础服务之上，充分利用云服务所带来的便捷性、稳定性， 降低应用架构的复杂度。云原生的微服务体系也将帮助应用架构全面升级，让应用天然具有更好的可观测性、 可控制性、可容错性等特性。 相较于单体应用，微服务架构的架构转变，在提升开发、部署等环节灵活性的同时，也提升了在运维、监 控环节的复杂性。在结合实践总结后，我们认为设计一个优秀的微服务系统应遵循以下设计约束： Th e Cl ou d- na tiv e A rc hi te ct ur e W hi te P ap er b y A lib ab a Cl ou d 微服务个体约束 一个设计良好的微服务应用，所完成的功能在业务域划分上应是相互独立的。与单体应用强行绑定语言和技术栈 相比，这样做的好处是不同业务域有不同的技术选择权，比如推荐系统采用 Python 实现效率可能比 Java 要高效得 多。从组织上来说，微服务对应的团队更小，开发效率也更高。“一个微服务团队一顿能吃掉两张披萨饼”、“一个 微服务应用应当能至少两周完成一次迭代”，都是对如何正确划分微服务在业务域边界的隐喻和标准。总结来说，微 服务的“微”并不是为了微而微，而是按照问题域对单体应用做合理拆分。

20 微服务与微服务之间的横向关系 微服务与数据层之间的纵向约束 进一步，微服务也应具备正交分解特性，在职责划分上专注于特定业务并将之做好，即 SOLID 原则中单一职责 原则（SRP, Single Responsibility Principle）。如果当一个微服务修改或者发布时，不应该影响到同一系统里另 一个微服务的业务交互。 在合理划分好微服务间的边界后，主要从微服务的可发现性和可交互性处理服务间的横向关系。 微服务的可发现性是指当服务 A 发布和扩缩容的时候，依赖服务 A 的服务 B 如何在不重新发布的前提下，如何 能够自动感知到服务 A 的变化？这里需要引入第三方服务注册中心来满足服务的可发现性；特别是对于大规模微服 务集群，服务注册中心的推送和扩展能力尤为关键。 微服务的可交互性是指服务 A 采用什么样的方式可以调用服务 B。由于服务自治的约束，服务之间的调用需 要采用与语言无关的远程调用协议，比如 REST 协议很好的满足了 “与语言无关”和“标准化”两个重要因素， 但在高性能场景下，基于 IDL 的二进制协议可能是更好的选择。另外，目前业界大部分微服务实践往往没有达到 HATEOAS 启发式的 REST 调用，服务与服务之间需要通过事先约定接口来完成调用。为了进一步实现服务与服 务之间的解耦，微服务体系中需要有一个独立的元数据中心来存储服务的元数据信息，服务通过查询该中心来理解发 起调用的细节。 伴随着服务链路的不断变长，整个微服务系统也就变得越来越脆弱，因此面向失败设计的原则在微服务体系中就 显得尤为重要。对于微服务应用个体，限流、熔断、隔仓、负载均衡等增强服务韧性的机制成为了标配。为进一步提 升系统吞吐能力、充分利用好机器资源，可以通协程、Rx 模型、异步调用、反压等手段来实现。 在微服务领域，提倡数据存储隔离（DSS, Data Storage Segregation）原则，即数据是微服务的私有资产， 对于该数据的访问都必须通过当前微服务提供的 API 来访问。如若不然，则造成数据层产生耦合，违背了高内聚低 耦合的原则。同时，出于性能考虑，通常采取读写分离（CQRS）手段。 同样的，由于容器调度对底层设施稳定性的不可预知影响，微服务的设计应当尽量遵循无状态设计原则，这意味 着上层应用与底层基础设施的解耦，微服务可以自由在不同容器间被调度。对于有数据存取（即有状态）的微服务而 言，通常使用计算与存储分离方式，将数据下沉到分布式存储，通过这个方式做到一定程度的无状态化。 The Cloud-native Architecture White Paper 全局视角下的微服务分布式约束 从微服务系统设计一开始，就需要考虑以下因素： 高效运维整个系统，从技术上要准备全自动化的 CI/CD 流水线满足对开发效率的诉求，并在这个基础上支持 蓝绿、金丝雀等不同发布策略，以满足对业务发布稳定性的诉求。 面对复杂系统，全链路、实时和多维度的可观测能力成为标配。为了及时、有效地防范各类运维风险，需要 从微服务体系多种事件源汇聚并分析相关数据，然后在中心化的监控系统中进行多维度展现。伴随着微服务 拆分的持续，故障发现时效性和根因精确性始终是开发运维人员的核心诉求。