阿里云云原生架构白皮书
应用介绍
2、仓产品家族主要云原生技术6 云原生架构实践案例15容器技术18云原生微服务23Serverless27开放应用模型 （OAM）31Service Mesh 技术33DevOps38云原生中间件50案例一： 申通快递核心业务系统云原生化上云案例53案例二： 完美日记电商业务案例55案例三： 特步业务中台案例 （零售、公共云）57案例四： 中国联通号卡业务云化案例 （传统业务，专有云）60案例五：Timing App 的 Serverless 实践案例阿里巴巴云原生架构设计7 云原生架构未来发展趋势40ACNA（Alibaba Cloud Native63容器技术发展趋势Architecting）
3、架构设计 *** 67基于云原生的新一代应用编程界面41企业战略视角68Serverless 发展趋势41业务发展视角42组织能力视角42云原生技术架构视角43架构持续演进闭环44云原生架构成熟度模型3 序The Cloud-native Architecture White Paper by Alibaba Cloud回顾过去十年，数字化转型将科技创新与商业元素不断融合、重构，重新定义了新业态下的增长极。商业正在从大工业时代的固化范式进化成面向创新型商业组织与新商业物种的崭新模式。随着数字化转型在中国各行业广泛深入，不管是行业巨头，还是中小微企业都不得不面对数字化变革带来的未知机遇与挑战。数字化转
4、型的十年，也是云计算高速发展的十年，这期间新技术不断演进、优秀开源项目大量涌现，云原生领域进入“火箭式”发展阶段。通过树立技术标准与构建开发者生态， 开源将云计算实施逐渐标准化，大幅降低了开发者对于云平台的学习成本与接入成本。这都让开发者更加聚焦于业务本身并借助云原生技术与产品实现更多业务创新，有效提升企业增长效率，爆发出前所未有的生产力与创造力。可以说，当云计算重构整个IT 产业的同时， 也赋予了企业崭新的增长机遇。正如集装箱的出现加速了贸易全球化进程，以容器为代表的云原生技术作为云计算的服务新界面加速云计算普及的同时，也在推动着整个商业世界飞速演进。上云成为企业持续发展的必然选择，全面使用
5、开源技术、云服务构建软件服务的时代已经到来。作为云时代释放技术红利的新方式， 云原生技术在通过 *** 论、工具集和更佳实践重塑整个软件技术栈和生命周期，云原生架构对云计算服务方式与互联网架构进行整体性升级，深刻改变着整个商业世界的 IT 根基。虽然云原生概念的产生由来已久，但对于云原生的定义、云原生架构的理解却众说纷纭。到底什么是云原生？容器就代表云原生吗？云原生时代互联网分布式架构如何发展？云原生与开源、云计算有什么关系？开发者和企业为什么一定要选择云原生架构？面对这些问题， 每个人都有着不同回答。鉴于此，阿里云结合自身云原生开源、云原生技术、云原生产品、云原生架构以及企业客户上云实践经验，给出
6、了自己的答案，并通过这本白皮书与社会分享自己的思考与总结，旨在帮助越来越多的企业顺利找到数字化转型最短路径。如何更好地拥抱云计算、拥抱云原生架构、用技术加速创新，将成为企业数字化转型升级成功的关键。云计算的下一站，就是云原生；IT 架构的下一站，就是云原生架构 ;希望所有的开发者、架构师和技术决策者们，共同定义、共同迎接云原生时代。未来十年，云计算将无处不在，像水电煤一样成为数字经济时代的基础设施，云原生让云计算变得标准、开放、简单高效、触手可及。1 为什么需要云原生架构？ 发展背景计算机软件技术架构进化有两大主要驱动因素，一个是底层硬件升级，另一个是顶层业务发展诉求。正如伴随着 x86 硬件
7、体系的成熟，很多应用不再使用昂贵、臃肿的大中型机，转而选择价格更为低廉的以 x86 为主的硬件体系，也由此诞生了包括 CORBA、EJB、RPC 在内的各类分布式架构；后由于互联网业务飞速发展，人们发现传统 IOE 架构已经不能满足海量业务规模的并发要求，于是又诞生了阿里巴巴 Dubbo & RocketMQ、Spring Cloud 这样的互联网架构体系。云计算从工业化应用到如今，已走过十五个年头，然而大量应用使用云的方式仍停滞在传统 IDC 时代： 虚拟机代替了原来的物理机：使用文件保存应用数据，大量自带的三方技术组件，没有经过架构改造（如微服务改造）的应用上云，传统的应用打包与发布方式等
8、等。对于如何使用这些技术，没有绝对的对与错， 只是在云的时代不能充分利用云的强大能力，不能从云技术中获得更高的可用性与可扩展能力，也不能利用云提升发布和运维的效率，是一件非常遗憾的事情。回顾近年来商业世界的发展趋势，数字化转型的出现使得企业中越来越多的业务演变成数字化业务， 数字化对于业务渠道、竞争格局、用户体验等诸多方面都带来更加严苛的要求，这就要求技术具备更快的迭代速度，业务推出速度从按周提升到按小时，每月上线业务量从“几十 / 月”提升到“几百 / 天”。大量数字化业务重构了企业的业务流水线，企业要求这些业务不能有不可接受的业务中断，否则会对客户体验以及营收可能造成巨大影响。对于企业的
9、CIO 或者 IT 主管而言，原来企业内部 IT 建设以“烟筒”模式比较多，每个部门甚至每个应用都相对独立，如何管理与分配资源成了难题。大家都基于更底层 IDC 设施独自向上构建，都需要单独分配硬件资源，这就造成资源被大量占用且难以被共享。但是上云之后，由于云厂商提供了统一的IaaS 能力和云服务，大幅提升了企业 IaaS 层的复用程度，CIO 或者 IT 主管自然而然想到 IaaS 以上层的系统也需要被统一，使资源、产品可被不断复用，从而能够进一步降低企业运营成本。所有这些问题都指向一个共同点，那就是云的时代需要新的技术架构，来帮助企业应用能够更好地利用云计算优势，充分释放云计算的技术红利，
10、让业务更敏捷、成本更低的同时又可伸缩性更灵活，而这些正好就是云原生架构专注解决的技术点。52云原生架构的定义今天云原生的定义有众多版本，云原生架构的理解也不尽相同，阿里将根据自身的云原生技术、产品和上云实践，给出自己的理解。 1云原生架构定义从技术的角度，云原生架构是基于云原生技术的一组架构原则和设计模式的 *** ，旨在将云应用中的非业务代码部分进行更大化的剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、可观测性、灰度等），使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。传统架构云原生架构代码代码基础设施运维开发人员业务代码编写三方软件使用三方软件调
11、用业务代码编写非功能性能力非功能性能力运维人员IaaS业务运维PaaS业务运维云原生架构与传统架构的对比上图展示了在代码中通常包括三部分：业务代码、三方软件、处理非功能特性的代码。其中“业务代码”指实现业务逻辑的代码；“三方软件”是业务代码中依赖的所有三方库，包括业务库和基础库；“处理非功能性的代码”指实现高可用、安全、可观测性等非功能性能力的代码。三部分中只有业务代码是核心，是对业务真正带来价值的，另外两个部分都只算附属物，但随着软件规模的增大、业务模块规模变大、部署环境增多、分布式复杂性增强，使得今天的软件构建变得越来越复杂，6 PAGE 7对开发人员的技能要求也越来越高。云原生架构相比较
12、传统架构进了一大步，从业务代码中剥离了大量非功能性特性（不会是所有，比如易用性还不能剥离）到 IaaS 和 PaaS 中，从而减少业务代码开发人员的技术关注范围，通过云厂商的专业性提升应用的非功能性能力。此外，具备云原生架构的应用可以更大程度利用云服务和提升软件交付能力，进一步加快软件开发：1代码结构发生巨大变化云原生架构产生的更大影响就是让开发人员的编程模型发生了巨大变化。今天大部分的编程语言中， 都有文件、 *** 、线程等元素，这些元素为充分利用单机资源带来好处的同时，也提升了分布式编程的复杂性；因此大量框架、产品涌现，来解决分布式环境中的 *** 调用问题、高可用问题、CPU 争用问题、分布式存储
13、问题 在云的环境中，比如“如何获取存储”变成了若干服务，包括对象存储服务、块存储服务和没有随机访问的文件存储服务。云不仅改变了开发人员获得这些存储能力的界面，还在于云产品在这些 OpenAPI或者开源 SDK 背后把分布式场景中的高可用挑战、自动扩缩容挑战、安全挑战、运维升级挑战等都处理了，应用的开发人员就不用在其代码中处理节点宕机前如何把本地保存的内容同步到远端的问题，也不用处理当业务峰值到来时如何对存储节点进行扩容的问题，而应用的运维人员不用在发现 zero day 安全问题时紧急对三方存储软件进行升级 云把三方软硬件的能力升级成了服务，开发人员的开发复杂度和运维人员的运维工作量都得到极大
14、降低。显然，如果这样的云服务用得越多，那么开发和运维人员的负担就越少，企业在非核心业务实现上从必须的负担变成了可控支出。在一些开发能力强的公司中，对这些三方软硬件能力的处理往往是交给应用框架（或者说公司内自己的中间件）来做的；在云的时代云厂商提供了更具 SLA 的服务，使得所有软件公司都可以由此获益。这些使得业务代码的开发人员技能栈中，不再需要掌握文件及其分布式处理技术，不再需要掌握各种复杂的 *** 技术 简化让业务开发变得更敏捷、更快速！2The Cloud-native Architecture White Paper by Alibaba Cloud非功能性特性的大量委托任何应用都提供两类特
15、性，功能性特性和非功能性特性。功能性特性是真正为业务带来价值的代码， 比如如何建立客户资料、如何处理订单、如何支付等等；即使是一些通用的业务功能特性，比如组织管理、业务字典管理、搜索等等也是紧贴业务需求的。非功能性特性是没有给业务带来直接业务价值，但通常又是必不可少的特性，比如高可用能力、容灾能力、安全特性、可运维性、易用性、可测试性、灰度发布能力等等。 PAGE 8The Cloud-native Architecture White Paper不能说云计算解决了所有非功能性问题，但确实大量非功能性特性，特别是分布式环境下复杂非功能性问题，被云产品处理掉了。以大家最头疼的高可用为例，云产品在
16、多个层面为应用提供了解决方案：虚机：当虚机检测到底层硬件异常时，自动帮助应用做热迁移，迁移后的应用不需重新启动而仍然具备对外服务的能力，应用对整个迁移过程都不会有任何感知；容器：有时应用所在的物理机是正常的，只是应用自身的问题（比如 bug、资源耗尽等）而无法正常对外提供服务。容器通过监控检查探测到进程状态异常，从而实施异常节点的下线、新节点上线和生产流量的切换等操作，整个过程自动完成而无需运维人员干预；云服务：如果应用把“有状态”部分都交给了云服务（如缓存、数据库、对象存储等），加上全局对象的持有小型化或具备从磁盘快速重建能力，由于云服务本身是具备极强的高可用能力，那么应用本身会变成更薄的“
17、无状态”应用，因为高可用故障带来的业务中断会降至分钟级；如果应用是 N-M 的对等架构架构模式，那么结合 Load Balancer 产品可获得几乎无损的高可用能力！3高度自动化的软件交付软件一旦开发完成，需要在公司内外部各类环境中部署和交付，以将软件价值交给最终客户。软件交付的困难在于开发环境到生产环境的差异（公司环境到客户环境之间的差异）以及软件交付和运维人员的技能差异，填补这些差异的是一大堆安装手册、运维手册和培训文档。容器以一种标准的方式对软件打包，容器及相关技术则帮助屏蔽不同环境之间的差异，进而基于容器做标准化的软件交付。对自动化交付而言，还需要一种能够描述不同环境的工具，让软件能够
18、“理解”目标环境、交付内容、配置清单并通过代码去识别目标环境的差异，根据交付内容以“面向终态”的方式完成软件的安装、配置、运行和变更。基于云原生的自动化软件交付相比较当前的人工软件交付是一个巨大的进步。以微服务为例，应用微服务化以后，往往被部署到成千上万个节点上，如果系统不具备高度的自动化能力，任何一次新业务的上线，都会带来极大的工作量挑战，严重时还会导致业务变更超过上线云原生架构原则云原生架构本身作为一种架构，也有若干架构原则作为应用架构的核心架构控制面，通过遵从这些架构原则可以让技术主管和架构师在做技术选择时不会出现大的偏差。 PAGE 91服务化原则当代码规模超出小团队
19、的合作范围时，就有必要进行服务化拆分了，包括拆分为微服务架构、小服务（Mini Service）架构，通过服务化架构把不同生命周期的模块分离出来，分别进行业务迭代，避免迭代频繁模块被慢速模块拖慢，从而加快整体的进度和稳定性。同时服务化架构以面向接口编程，服务内部的功能高度内聚，模块间通过公共功能模块的提取增加软件的复用程度。分布式环境下的限流降级、熔断隔仓、灰度、反压、零信任安全等，本质上都是基于服务流量（而非 *** 流量）的控制策略，所以云原生架构强调使用服务化的目的还在于从架构层面抽象化业务模块之间的关系，标准化服务流量的传输，从而帮助业务模块进行基于服务流量的策略控制和治理，不管这些服务是基
20、于什么语言开发的。2弹性原则大部分系统部署上线需要根据业务量的估算，准备一定规模的机器，从提出采购申请，到供应商洽谈、机器部署上电、软件部署、性能压测，往往需要好几个月甚至一年的周期；而这期间如果业务发生变化了， 重新调整也非常困难。弹性则是指系统的部署规模可以随着业务量的变化自动伸缩，无须根据事先的容量规划准备固定的硬件和软件资源。好的弹性能力不仅缩短了从采购到上线的时间，让企业不用操心额外软硬件资源的成本支出（闲置成本），降低了企业的 IT 成本，更关键的是当业务规模面临海量突发性扩张的时候，不再因为平时软硬件资源储备不足而“说不”，保障了企业收益。3可观测原则The Cloud-nati
21、ve Architecture White Paper by Alibaba Cloud今天大部分企业的软件规模都在不断增长，原来单机可以对应用做完所有调试，但在分布式环境下需要对多个主机上的信息做关联，才可能回答清楚服务为什么宕机、哪些服务违反了其定义的 SLO、目前的故障影响哪些用户、最近这次变更对哪些服务指标带来了影响等等，这些都要求系统具备更强的可观测能力。可观测性与监控、业务探活、APM 等系统提供的能力不同，前者是在云这样的分布式系统中， 主动通过日志、链路跟踪和度量等手段，让一次 APP 点击背后的多次服务调用的耗时、返回值和参数都清晰可见，甚至可以下钻到每次三方软件调用、SQL
22、 请求、节点拓扑、 *** 响应等，这样的能力可以使运维、开发和业务人员实时掌握软件运行情况，并结合多个维度的数据指标，获得前所未有的关联分析能力，不断对业务健康度和用户体验进行数字化衡量和持续优化。4韧性原则当业务上线后，最不能接受的就是业务不可用，让用户无法正常使用软件，影响体验和收入。韧性代表了当软件所依赖的软硬件组件出现各种异常时，软件表现出来的抵御能力，这些异常通常包括硬件故障、 PAGE 10The Cloud-native Architecture White Paper硬件资源瓶颈（如 CPU/ 网卡带宽耗尽）、业务流量超出软件设计能力、影响机房工作的故障和灾难、软件 bug、黑客攻
23、击等对业务不可用带来致命影响的因素。韧性从多个维度诠释了软件持续提供业务服务的能力，核心目标是提升软件的 MTBF（Mean Time Between Failure，平均无故障时间）。从架构设计上，韧性包括服务异步化能力、重试 / 限流 / 降级 /熔断 / 反压、主从模式、集群模式、AZ 内的高可用、单元化、跨 region 容灾、异地多活容灾等。5所有过程自动化原则技术往往是把“双刃剑”，容器、微服务、DevOps、大量第三方组件的使用，在降低分布式复杂性和提升迭代速度的同时，因为整体增大了软件技术栈的复杂度和组件规模，所以不可避免地带来了软件交付的复杂性，如果这里控制不当，应用就无法体
24、会到云原生技术的优势。通过 IaC（Infrastructure as Code）、GitOps、OAM（Open Application Model）、Kubernetes operator 和大量自动化交付工具在 CI/CD 流水线中的实践，一方面标准化企业内部的软件交付过程，另一方面在标准化的基础上进行自动化，通过配置数据自描述和面向终态的交付过程，让自动化工具理解交付目标和环境差异，实现整个软件交付和运维的自动化。6零信任原则零信任安全针对传统边界安全架构思想进行了重新评估和审视，并对安全架构思路给出了新建议。其核心思想是，默认情况下不应该信任 *** 内部和外部的任何人 / 设备 / 系统
25、，需要基于认证和授权重构访问控制的信任基础，诸如 IP 地址、主机、地理位置、所处 *** 等均不能作为可信的凭证。零信任对访问控制进行了范式上的颠覆，引导安全体系架构从“ *** 中心化”走向“身份中心化”，其本质诉求是以身份为中心进行访问控制。零信任之一个核心问题就是 Identity，赋予不同的 Entity 不同的 Identity，解决是谁在什么环境下访问某个具体的资源的问题。在研发、测试和运维微服务场景下，Identity 及其相关策略不仅是安全的基础， 更是众多（资源，服务，环境）隔离机制的基础；在员工访问企业内部应用的场景下，Identity 及其相关策略提供了灵活的机制来提供随时随地的接
26、入服务。7架构持续演进原则今天技术和业务的演进速度非常快，很少有一开始就清晰定义了架构并在整个软件生命周期里面都适用，相反往往还需要对架构进行一定范围内的重构，因此云原生架构本身也应该和必须是一个具备持续演进能力的架构，而不是一个封闭式架构。除了增量迭代、目标选取等因素外，还需要考虑组织（例如架构控制委员会）层面的架构治理和风险控制，特别是在业务高速迭代情况下的架构、业务、实现平衡 PAGE 11关系。云原生架构对于新建应用而言的架构控制策略相对容易选择（通常是选择弹性、敏捷、成本的维度）， 但对于存量应用向云原生架构迁移，则需要从架构上考虑遗留应用的迁出成本 / 风险和到云上的迁入成本/ 风
27、险，以及技术上通过微服务 / 应用网关、应用集成、适配器、服务网格、数据迁移、在线灰度等应用和流量进行细颗粒度控制。 3主要架构模式云原生架构有非常多的架构模式，这里选取一些对应用收益更大的主要架构模式进行讨论。1服务化架构模式服务化架构是云时代构建云原生应用的标准架构模式，要求以应用模块为颗粒度划分一个软件，以接口契约（例如 IDL）定义彼此业务关系，以标准协议（HTTP、gRPC 等）确保彼此的互联互通，结合 DDD（领域模型驱动）、TDD（测试驱动开发）、容器化部署提升每个接口的代码质量和迭代速度。服务化架构的典型模式是微服务和小服务（Mini Service）模式，其中小服务可以看做是
28、一组关系非常密切的服务的组合，这组服务会共享数据，小服务模式通常适用于非常大型的软件系统，避免接口的颗粒度太细而导致过多的调用损耗（特别是服务间调用和数据一致性处理）和治理复杂度。通过服务化架构，把代码模块关系和部署关系进行分离，每个接口可以部署不同数量的实例，单独扩缩容，从而使得整体的部署更经济。此外，由于在进程级实现了模块的分离，每个接口都可以单独升级， 从而提升了整体的迭代效率。但也需要注意，服务拆分导致要维护的模块数量增多，如果缺乏服务的自动化能力和治理能力，会让模块管理和组织技能不匹配，反而导致开发和运维效率的降低。2Mesh 化架构模式The Cloud-native Archit
29、ecture White Paper by Alibaba CloudMesh 化架构是把中间件框架（比如 RPC、缓存、异步消息等）从业务进程中分离，让中间件 SDK 与业务代码进一步解耦，从而使得中间件升级对业务进程没有影响，甚至迁移到另外一个平台的中间件也对业务透明。分离后在业务进程中只保留很“薄”的 Client 部分，Client 通常很少变化，只负责与 Mesh 进程通讯，原来需要在 SDK 中处理的流量控制、安全等逻辑由 Mesh 进程完成。整个架构如下图所示。 PAGE 12The Cloud-native Architecture White Paper容器/主机SDK协议网
30、络业务进程业务代码RPCRedisMQDB SDKSDKSDKSDK新协议、加密、染色 *** 业务进程SDK协议/标准协议Mesh 进程（流量控制、安全策略、微隔离）业务代码RPCRedisMQDB SDKSDKSDKSDK容器/主机传统架构Mesh 化架构实施 Mesh 化架构后，大量分布式架构模式（熔断、限流、降级、重试、反压、隔仓）都由Mesh 进程完成，即使在业务代码的制品中并没有使用这些三方软件包；同时获得更好的安全性（比如零信任架构能力）、按流量进行动态环境隔离、基于流量做冒烟 / 回归测试等。3Serverless 模式和大部分计算模式不同，Serverless 将“部署”这个动作
31、从运维中“收走”，使开发者不用关心应用在哪里运行，更不用关心装什么 OS、怎么配置 *** 、需要多少 CPU 从架构抽象上看，当业务流量到来 / 业务事件发生时，云会启动或调度一个已启动的业务进程进行处理，处理完成后云自动会关闭/ 调度业务进程，等待下一次触发，也就是把应用的整个运行时都委托给云。今天 Serverless 还没有达到任何类型的应用都适用的地步，因此架构决策者需要关心应用类型是否适合于 Serverless 运算。如果应用是有状态的，云在进行调度时可能导致上下文丢失，毕竟 Serverless 的调度不会帮助应用做状态同步；如果应用是长时间后台运行的密集型计算任务，会得不到太多 S
32、erverless 的优势；如果应用涉及到频繁的外部 I/O（ *** 或者存储，以及服务间调用），也因为繁重的 I/O 负担、时延大而不适合。Serverless 非常适合于事件驱动的数据计算任务、计算时间短的请求 / 响应应用、没有复杂相互调用的长周期任务。4存储计算分离模式分布式环境中的 CAP 困难主要是针对有状态应用，因为无状态应用不存在 C（一致性）这个维度， 因此可以获得很好的 A（可用性）和 P（分区容错性），因而获得更好的弹性。在云环境中，推荐把各 PAGE 13类暂态数据（如session）、结构化和非结构化持久数据都采用云服务来保存，从而实现存储计算分离。但仍然有一些状态如果保
33、存到远端缓存，会造成交易性能的明显下降，比如交易会话数据太大、需要不断根据上下文重新获取等，则可以考虑通过采用 Event Log + 快照（或 Check Point）的方式，实现重启后快速增量恢复服务，减少不可用对业务的影响时长。5分布式事务模式微服务模式提倡每个服务使用私有的数据源，而不是像单体这样共享数据源，但往往大颗粒度的业务需要访问多个微服务，必然带来分布式事务问题，否则数据就会出现不一致。架构师需要根据不同的场景选择合适的分布式事务模式。传统采用 XA 模式，虽然具备很强的一致性，但是性能差；基于消息的最终一致性（BASE）通常有很高的性能，但是通用性有限，且消息端只能成功而不能
34、触发消息 生产端的事务回滚；TCC 模式完全由应用层来控制事务，事务隔离性可控，也可以做到比较高效；但是对业务的侵入性非常强， 设计开发维护等成本很高；SAGA 模式与 TCC 模式的优缺点类似但没有 try 这个阶段，而是每个正向事务都对应一个补偿事务，也是开发维护成本高；开源项目 SEATA 的 AT 模式非常高性能且无代码开发工作量，且可以自动执行回滚操作，同时也存在一些使用场景限制。6可观测架构可观测架构包括 Logging、Tracing、Metrics 三个方面，其中 Logging 提供多个级别（verbose/ debug/warning/error/fatal）的详细信息跟踪
35、，由应用开发者主动提供；Tracing 提供一个请求从前端到后端的完整调用链路跟踪，对于分布式场景尤其有用；Metrics 则提供对系统量化的多维度度量。The Cloud-native Architecture White Paper by Alibaba Cloud架构决策者需要选择合适的、支持可观测的开源框架（比如 OpenTracing、OpenTelemetry）， 并规范上下文的可观测数据规范（例如 *** 名、用户信息、地理位置、请求参数等），规划这些可观测数据在哪些服务和技术组件中传播，利用日志和 tracing 信息中的 span id/trace id，确保进行分布式链路分析时有
37、息不同，事件具有 schema，所以可以校验 event 的有效性，同时 EDA 具备 QoS保障机制，也能够对事件处理失败进行响应。事件驱动架构不仅用于（微）服务解耦，还可应用于下面的场景中：增强服务韧性：由于服务间是异步集成的，也就是下游的任何处理失败甚至宕机都不会被上游感知，自然也就不会对上游带来影响；CQRS（Command Query Responsibility Segregation）：把对服务状态有影响的命令用事件来发起， 而对服务状态没有影响的查询才使用同步调用的 API 接口；结合 EDA 中的 Event Sourcing 可以用于维护数据变更的一致性，当需要重新构建服务
38、状态时，把 EDA 中的事件重新“播放”一遍即可；数据变化通知：在服务架构下，往往一个服务中的数据发生变化，另外的服务会感兴趣，比如用户订单完成后，积分服务、信用服务等都需要得到事件通知并更新用户积分和信用等级；构建开放式接口：在 EDA 下，事件的提供者并不用关心有哪些订阅者，不像服务调用的场景 数据的产生者需要知道数据的消费者在哪里并调用它，因此保持了接口的开放性；事件流处理：应用于大量事件流（而非离散事件）的数据分析场景，典型应用是基于 Kafka 的日志处理；基于事件触发的响应：在 IoT 时代大量传感器产生的数据，不会像人机交互一样需要等待处理结果的返回，天然适合用 EDA 来构建数
39、据处理应用。 4典型的云原生架构反模式技术往往像一把双刃剑，阿里在自己和帮助客户做云原生架构演进的时候，会充分考虑根据不同的场景选择不同的技术，下面是我们总结的一些典型云原生架构反模式。1庞大的单体应用庞大单体应用的更大问题在于缺乏依赖隔离，包括代码耦合带来的责任不清、模块间接口缺乏治理而带来变更影响扩散、不同模块间的开发进度和发布时间要求难以协调、一个子模块不稳定导致整个应用都变慢、扩容时只能整体扩容而不能对达到瓶颈的模块单独扩容 因此当业务模块可能存在多人开发 PAGE 15的时候，就需要考虑通过服务化进行一定的拆分，梳理聚合根，通过业务关系确定主要的服务模块以及这些模块的边界、清晰定义模
40、块之间的接口，并让组织关系和架构关系匹配。阿里巴巴在 *** 业务快速发展阶段，就遇到过上百人维护一个核心单体应用，造成了源码冲突、多团队间协同代价高的严重问题。为了支撑不断增长的流量，该应用需要不断增加机器，很快后端数据库连接很快就到达了上限。在还没有“微服务”概念的 2008 年，阿里巴巴决定进行服务化架构拆分，当时思路就是微服务架构，之一个服务从用户中心开始建设，后续交易、类目、店铺、商品、评价中心等服务陆续从单体中独立出来，服务之间通过远程调用通信，每个中心由独立团队专门维护，从而解决了研发协同问题，以及按规模持续水平扩展的问题。2单体应用“硬拆”为微服务服务的拆分需要适度，过分服务化拆分反
41、而会导致新架构与组织能力的不匹配，让架构升级得不到技术红利，典型的例子包括：小规模软件的服务拆分：软件规模不大，团队人数也少，但是为了微服务而微服务，强行把耦合度高、代码量少的模块进行服务化拆分，一次性的发布需要拆分为多个模块分开发布和维护；数据依赖：服务虽然拆分为多个，但是这些服务的数据是紧密耦合的，于是让这些服务共享数据库，导致数据的变化往往被扇出到多个服务中，造成服务间数据依赖；性能降低：当耦合性很强的模块被拆分为多个微服务后，原来的本地调用变成了分布式调用，从而让响应时间变大了上千倍，导致整个服务链路性能急剧下降。3缺乏自动化能力的微服务The Cloud-native Archite
42、cture White Paper by Alibaba Cloud软件架构中非常重要的一个维度就是处理软件复杂度问题，一旦问题规模提升了很多，那就必须重新考虑与之适应的新方案。在很多软件组织中，开发、测试和运维的工作单位都是以进程为单位，比如把整个用户管理作为一个单独的模块进行打包、发布和运行；而进行了微服务拆分后，这个用户管理模块可能被分为用户信息管理、基本信息管理、积分管理、订单管理等多个模块，由于仍然是每个模块分别打包、发布和运行，开发、测试和运维人员的人均负责模块数就直线上升，造成了人均工作量增大，也就增加了软件的开发成本。实际上，当软件规模进一步变大后，自动化能力的缺失还会带来更大
43、的危害。由于接口增多会带来测试用例的增加，更多的软件模块排队等待测试和发布，如果缺乏自动化会造成软件发布时间变长，在多环境发布或异地发布时更是需要专家来处理环境差异带来的影响。同时更多的进程运行于一个环境中， 缺乏自动化的人工运维容易给环境带来不可重现的影响，而一旦发生人为运维错误又不容易“快速止血”， 造成了故障处理时间变长，以及使得日常运维操作都需要专家才能完成。所有这些问题导致软件交付时间变长、风险提升以及运维成本的增加。3主要云原生技术 1容器技术1容器技术背景与价值Operating SystemOperating SystemBin / LibraryBin / Library容器
45、Virtualized DeploymentContainer Deployment传统、虚拟化及容器部署模式比较虽然 2008 年 Linux 就提供了 Cgroups 资源管理机制、Linux Namespace 视图隔离方案，让应用得以运行在独立沙箱环境中，避免相互间冲突与影响；但直到 Docker 容器引擎的开源，才很大程度上降低了容器技术的使用复杂性，加速了容器技术普及。Docker 容器基于操作系统虚拟化技术，共享操作系统内核、轻量、没有资源损耗、秒级启动，极大提升了系统的应用部署密度和弹性。更重要的是， Docker 提出了创新的应用打包规范 Docker 镜像，解耦了应用与运行
46、环境，使应用可以在不同计算环境间一致、可靠地运行。借助容器技术呈现了一个优雅的抽象场景：让开发所需要的灵活性、开放性和运维所关注的标准化、自动化达成相对平衡。容器镜像迅速成为了应用分发的工业标准。16 PAGE 17随后开源的 Kubernetes，凭借优秀的开放性、可扩展性以及活跃开发者社区，在容器编排之战中脱颖而出，成为分布式资源调度和自动化运维的事实标准。Kubernetes 屏蔽了 IaaS 层基础架构的差异并凭借优良的可移植性，帮助应用一致地运行在包括数据中心、云、边缘计算在内的不同环境。企业可以通过 Kubernetes，结合自身业务特征来设计自身云架构，从而更好支持多云 / 混合
47、云，免去被厂商锁定的顾虑。伴随着容器技术逐步标准化，进一步促进了容器生态的分工和协同。基于 Kubernetes，生态社区开始构建上层的业务抽象，比如服务网格 Istio、机器学习平台 Kubeflow、无服务器应用框架Knative 等。在过去几年，容器技术获得了越发广泛的应用的同时，三个核心价值最受用户关注：敏捷容器技术提升企业 IT 架构敏捷性的同时，让业务迭代更加迅捷，为创新探索提供了坚实的技术保障。比如疫情期间，教育、视频、公共健康等行业的在线化需求突现爆发性高速增长，很多企业通过容器技术适时把握了突如其来的业务快速增长机遇。据统计，使用容器技术可以获得 310 倍交付效率提升，这意
48、味着企业可以更快速的迭代产品，更低成本进行业务试错。弹性在互联网时代，企业 IT 系统经常需要面对促销活动、突发事件等各种预期内外的爆发性流量增长。通过容器技术，企业可以充分发挥云计算弹性优势，降低运维成本。一般而言，借助容器技术，企业可以通过部署密度提升和弹性降低 50% 的计算成本。以在线教育行业为例，面对疫情之下指数级增长的流量，教育信息化应用工具提供商希沃 Seewo 利用阿里云容器服务 ACK 和弹性容器实例 ECI 大大满足了快速扩容的迫切需求，为数十万名老师提供了良好的在线授课环境，帮助百万学生进行在线学习。可移植性容器已经成为应用分发和交付的标准技术，将应用与底层运行环境进行解
49、耦；Kubernetes 成为资源调度和编排的标准，屏蔽了底层架构差异性，帮助应用平滑运行在不同基础设施上。CNCF 云原生计算基金会推出了 Kubernetes 一致性认证，进一步保障了不同 K8s 实现的兼容性，这也让企业愿意采用容器技术来构建云时代应用基础设施。2容器编排The Cloud-native Architecture White Paper by Alibaba CloudKubernetes 已经成为容器编排的事实标准，被广泛用于自动部署，扩展和管理容器化应用。Kubernetes 提供了分布式应用管理的核心能力：资源调度：根据应用请求的资源量 CPU、Memory，或者
50、GPU 等设备资源，在集群中选择合适的节点来运行应用；应用部署与管理：支持应用的自动发布与应用的回滚，以及与应用相关的配置的管理；也可以自动化存储卷的编排，让存储卷与容器应用的生命周期相关联； PAGE 18The Cloud-native Architecture White Paper自动修复：Kubernetes 可以会监测这个集群中所有的宿主机，当宿主机或者 OS 出现故障，节点健康检查会自动进行应用迁移；K8s 也支持应用的自愈，极大简化了运维管理的复杂性；服务发现与负载均衡：通过 Service 资源出现各种应用服务，结合 DNS 和多种负载均衡机制，支持容器化应用之间的相互通信；
53、、开放的 API 实现和交互；三方开发者也可通过 CRD（Custom Resource Definition）/Operator 等 *** 提供领域相关的扩展实现，极大提升了 K8s 的能力。 PAGE 19可移植性：K8s 通过一系列抽象如 Loadbalance Service（负载均衡服务）、CNI（容器 *** 接口）、CSI（容器存储接口），帮助业务应用可以屏蔽底层基础设施的实现差异，实现容器灵活迁移的设计目标。 2云原生微服务1微服务发展背景过去开发一个后端应用最为直接的方式就是通过单一后端应用提供并集成所有的服务，即单体模式。随着业务发展与需求不断增加，单体应用功能愈发复杂，参与开发的工
54、程师规模可能由最初几个人发展到十几人， 应用迭代效率由于集中式研发、测试、发布、沟通模式而显著下滑。为了解决由单体应用模型衍生的过度集中式项目迭代流程，微服务模式应运而生。微服务模式将后端单体应用拆分为松耦合的多个子应用，每个子应用负责一组子功能。这些子应用称为“微服务”，多个“微服务”共同形成了一个物理独立但逻辑完整的分布式微服务体系。这些微服务相对独立，通过解耦研发、测试与部署流程，提高整体迭代效率。此外，微服务模式通过分布式架构将应用水平扩展和冗余部署，从根本上解决了单体应用在拓展性和稳定性上存在的先天架构缺陷。但也要注意到微服务模型也面临着分布式系统的典型挑战：如何高效调用远程 *** 、如
55、何实现可靠的系统容量预估、如何建立负载均衡体系、如何面向松耦合系统进行集成测试、如何面向大规模复杂关联应用的部署与运维在云原生时代，云原生微服务体系将充分利用云资源的高可用和安全体系，让应用获得更有保障的弹性、可用性与安全性。应用构建在云所提供的基础设施与基础服务之上，充分利用云服务所带来的便捷性、稳定性， 降低应用架构的复杂度。云原生的微服务体系也将帮助应用架构全面升级，让应用天然具有更好的可观测性、可控制性、可容错性等特性。2微服务设计约束相较于单体应用，微服务架构的架构转变，在提升开发、部署等环节灵活性的同时，也提升了在运维、监控环节的复杂性。在结合实践总结后，我们认为设计一个优秀的微服
56、务系统应遵循以下设计约束：The Cloud-native Architecture White Paper by Alibaba Cloud微服务个体约束一个设计良好的微服务应用，所完成的功能在业务域划分上应是相互独立的。与单体应用强行绑定语言和技术栈相比，这样做的好处是不同业务域有不同的技术选择权，比如推荐系统采用 Python 实现效率可能比 Java 要高效得多。从组织上来说，微服务对应的团队更小，开发效率也更高。“一个微服务团队一顿能吃掉两张披萨饼”、“一个微服务应用应当能至少两周完成一次迭代”，都是对如何正确划分微服务在业务域边界的隐喻和标准。总结来说，微服务的“微”并不是为了微而
57、微，而是按照问题域对单体应用做合理拆分。 PAGE 21The Cloud-native Architecture White Paper进一步，微服务也应具备正交分解特性，在职责划分上专注于特定业务并将之做好，即 SOLID 原则中单一职责原则（SRP, Single Responsibility Principle）。如果当一个微服务修改或者发布时，不应该影响到同一系统里另一个微服务的业务交互。微服务与微服务之间的横向关系在合理划分好微服务间的边界后，主要从微服务的可发现性和可交互性处理服务间的横向关系。微服务的可发现性是指当服务 A 发布和扩缩容的时候，依赖服务 A 的服务 B 如何在不
58、重新发布的前提下，如何能够自动感知到服务 A 的变化？这里需要引入第三方服务注册中心来满足服务的可发现性；特别是对于大规模微服务集群，服务注册中心的推送和扩展能力尤为关键。微服务的可交互性是指服务 A 采用什么样的方式可以调用服务 B。由于服务自治的约束，服务之间的调用需要采用与语言无关的远程调用协议，比如 REST 协议很好的满足了 “与语言无关”和“标准化”两个重要因素， 但在高性能场景下，基于 IDL 的二进制协议可能是更好的选择。另外，目前业界大部分微服务实践往往没有达到 HATEOAS 启发式的 REST 调用，服务与服务之间需要通过事先约定接口来完成调用。为了进一步实现服务与服务之
59、间的解耦，微服务体系中需要有一个独立的元数据中心来存储服务的元数据信息，服务通过查询该中心来理解发起调用的细节。伴随着服务链路的不断变长，整个微服务系统也就变得越来越脆弱，因此面向失败设计的原则在微服务体系中就显得尤为重要。对于微服务应用个体，限流、熔断、隔仓、负载均衡等增强服务韧性的机制成为了标配。为进一步提升系统吞吐能力、充分利用好机器资源，可以通协程、Rx 模型、异步调用、反压等手段来实现。微服务与数据层之间的纵向约束在微服务领域，提倡数据存储隔离（DSS, Data Storage Segregation）原则，即数据是微服务的私有资产， 对于该数据的访问都必须通过当前微服务提供的 A
60、PI 来访问。如若不然，则造成数据层产生耦合，违背了高内聚低耦合的原则。同时，出于性能考虑，通常采取读写分离（CQRS）手段。同样的，由于容器调度对底层设施稳定性的不可预知影响，微服务的设计应当尽量遵循无状态设计原则，这意味着上层应用与底层基础设施的解耦，微服务可以自由在不同容器间被调度。对于有数据存取（即有状态）的微服务而言，通常使用计算与存储分离方式，将数据下沉到分布式存储，通过这个方式做到一定程度的无状态化。全局视角下的微服务分布式约束从微服务系统设计一开始，就需要考虑以下因素：高效运维整个系统，从技术上要准备全自动化的 CI/CD 流水线满足对开发效率的诉求，并在这个基础上支持蓝绿、金
61、丝雀等不同发布策略，以满足对业务发布稳定性的诉求。面对复杂系统，全链路、实时和多维度的可观测能力成为标配。为了及时、有效地防范各类运维风险，需要从微服务体系多种事件源汇聚并分析相关数据，然后在中心化的监控系统中进行多维度展现。伴随着微服务拆分的持续，故障发现时效性和根因精确性始终是开发运维人员的核心诉求。 PAGE 21The Cloud-native Architecture White Paper by Alibaba Cloud3云原生微服务典型架构自从微服务架构理念在 2011 年提出以来，典型的架构模式按出现的先后顺序大致分为四代。Service BService ABusiness
66、被称之为第四代微服务架构。在这个架构中，微服务进一步由一个应用简化为微逻辑（Micrologic），从而对边车模式提出了更高诉求，更多可复用的分布式能力从应用中剥离，被下沉到边车中，例如：状态管理、资源绑定、链路追踪、事务管理、安全等等。同时，在开发侧开始提倡面向 localhost 编程的理念，提供标准 API 屏蔽掉底层资源、服务、基础设施的差异，进一步降低微服务开发难度。这个也就是目前业界提出的多运行时微服务架构（Muti-Runtime Microservices）。 PAGE 234主要微服务技术Apache Dubbo 作为源自阿里巴巴的一款开源高性能 RPC 框架，特性包括基于透明接口的 RPC、智能负载均衡、自动服务注册和发现、可扩展性高、运行时流量路由与可视化的服务治理。经过数年发展已是国内使用最广泛的微服务框架并构建了强大的生态体系。为了巩固 Dubbo 生态的整体竞争力，2018 年阿里巴巴陆续开源了 Spring- Cloud Alibaba( 分布式应用框架 )、Nacos( 注册中心 & 配置中心 )、Sentinel( 流控防护 )、Seata( 分布式事
1. 本站所有资源如无特殊说明，都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
2. 本站的文档不包含任何第三方提供的附件图纸等，如果需要附件，请联系上传者。文件的所有权益归上传用户所有。
5. 人人文库网仅提供信息存储空间，仅对用户上传内容的表现方式做保护处理，对用户上传分享的文档内容本身不做任何修改或编辑，并不能对任何下载内容负责。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
