《2023阿里云原生架构白皮书.docx》由会员分享，可在线阅读，更多相关《2023阿里云原生架构白皮书.docx（73页珍藏版）》请在三一办公上搜索。
1、企业数字化转型最短路径CONTENTThe Cloud-native Architecture White Paper by Alibaba Cloud云原生架构3序1为什么需要云原生架构？5阿里云云原生产品介绍2云原生架构的定义57.913典型的石原生架构反模式45云原生产品家族45容器产品家族46-：G:j;47,js产品家族4748消息产品家族4849云原少数仓产品家族3主要云原生技术15容器技术18云原生微服务23Serverless27开放应用模型（OAV）31ServiceMcsh技术33DcvOps3S云原生中间件6云原生架构实践案例50案例r中通快递核心业务系统z原1：化/案例
2、S3案例完美日记电商业务案例55案例特步业务中介案例（零售、公Jie57案例四：中国联通号卡业务云化案例（传统业务，专有云）6。案例五：TinIingA叩的SerVerIeSS实践案例4阿里巴巴云原生架构设计40ACNA（AlibabaCloudNativeArchitecting）架构设计方法41企业战略视角41业务发展视角42组织能力视角42公原生技术架构视角43架构持续演进闭环44云原生架构成熟度模型云原生架构未来发展趋势63容器技术发展趋势67基于云原生的新代应用编程界面68Serverless发展趋势序tiveArchitecturebyAlibabaCloud回顾过去十年，数字化转
3、型将科技创新IJ对云计算服务方式与互联网架构进行整体性升商业元素不断融合、重构，重新定义了新业态级，深刻改变着整个商业世界的IT根基。f的增长极。商业正在从大工业时代的固化范式进化成面向创新型商业组织与新商业物种的崭新模式。随着数字化转型在中国各行业广泛深入，不管是行业巨头，还是中小微企业都不得不面对数字化变革带来的未知机遇。挑战,虽然云原生概念的产生由来已久，但对于云原生的定义、云原生架构的理解却众说纷纭。到底什么是公原生？容器就代表云原生吗？A原生时代互联网分布式架构如何发展？云原生开源、云计算有什么关系？开发者和企业为数字化转型的十年，也是云计算高速发展什么一定要选择云原生架构？面对这些
4、问题,的十年，这期间新技术不断演进、优秀开源项每个人都有着不同回答鉴于此，阿里云结合目大量涌现，云原生领域进入火箭式发展自身云原生开源、云原生技术、云原生产品、阶段.通过树立技术标准与构建开发者生态,云原生架构以及企业客户上云实践经验，给出开源将云计算实施逐渐标准化，大幅降低了开了自己的答案，并通过这本白皮书与社会分享发者对于云平台的学习成本与接入成本。这都自己的思考与总结，旨在帮助越来越多的企业让开发者更加聚焦于业务本身并借助幺原生技顺利找到数字化转型最短路径。术与产品实现更多业务创新，有效提升企业增长效率，爆发出前所未有的生产力与创造力。未来十年，云计算将无处不在，像水电煤样成为数字经济时
5、代的基础设施，云原生让可以说，当云计算重构整个IT产业的同时,云计算变得标准、开放、简单高效、触F可及。也赋予了企业崭新的增长机遇。正如集装箱的如何更好地拥抱云计算、拥抱云原生架构、用出现加速了贸易全球化进程，以容器为代表的技术加速创新，将成为企业数字化转型升级成云原生技术作为云计算的服务新界面加速云计功的关键.算普及的同时，也在推动着整个商业世界t速演进.上公成为企业持续发展的必然选择，全云计算的下站，就是云原生;面使用开源技术、云服务构建软件服务的时代IT架构的下一站，就是云原生架构；己经到来。作为云时代释放技术红利的新方式,云原生技术在通过方法论、工具集和最佳实践重塑整个软件技术栈和生命
6、周期.云原生架构希望所有的开发者、架构师和技术决策者们，共同定义、共同迎接云原生时代.计算机软件技术架构进化有两大主要驱动因素，一个是底层硬件升级，另一个是顶层业务发展诉求。正如伴随着x86硬件体系的成熟，很多应用不再使用昂贵、臃肿的大中型机，转而选择价格更为低廉的以x86为主的硬件体系，也由此诞生了包括CORBA,EJB、RPC在内的各类分布式架构：后由于互联网业务飞速发展，人们发现传统K）E架构已经不能满足海量业务规模的并发要求，于是又诞生了阿里巴巴DUbbo&RocketMQ、SpringCloud这样的互联网架构体系。云计算从工业化应用到如今，已走过十五个年头，然而大量应用使用云的方式
7、仍停滞在传统IDC时代：虚拟机代替了原来的物理机：使用文件保存应用数据，大量自带的二方技术组件，没有经过架构改造（如微服务改造）的应用上云，传统的应用打包与发布方式等等。对于如何使用这些技术，没有绝对的对与错，只是在云的时代不能充分利用云的强大能力，不能从云技术中获得更高的可用性与可扩展能力，也不能利用云提升发布和运维的效率，是件非常遗憾的事情。回顾近年来商业世界的发展趋势，数字化转型的出现使得企业中越来越多的业务演变成数字化业务，数字化对于业务渠道、竞争格局、用户体验等诸多方面都带来更加严苛的要求，这就要求技术具备更快的迭代速度，业务推出速度从按周提升到按小时，每月上线业务量从几十/月提升到
8、几百/天”.大量数字化业务重构了企业的业务流水线，企业要求这些业务不能有不可接受的业务中断，否则会对客户体验以及营收可能造成巨大影响.对于企业的ClO或者IT主管而言，原来企业内部IT建设以烟筒模式比较多，每个部门甚至每个应用都相对独立，如何管理与分配资源成了难题。大家都基r最底层IDC设施独自向上构建，都需要单独分配硬件资源，这就造成资源被大量占用且难以被共享。但是上云之后，由于云厂商提供了统，的IaaS能力和云服务，大幅提升了企业IaaS层的复用程度，CIO蹄IT主管自然而然想到IaaS以上层的系统也需要被统一，使资源、产品可被不断复用，从而育缚进一步降低企业运营成本。所有这些问题都指向一
9、个共同点，那就是云的时代需要新的技术架构，来帮助企业应用能够更好地利用云计算优势，充分释放云计算的技术红利，让业务更敏捷、成本更低的同时又可伸缩性更灵活，而这些正好就是云原生架构专注解决的技术点.2云原生架构的定义今天云原生的定义有众多版本，云原生架构的理解也不尽相同，阿里将根据自身的云原生技术、产品和上云实践，给出自己的理解。1!云原生架构定义从技术的角度，云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、可观测性、灰度等），使业务不再有非功能性业务中断困扰的同时，具备轻量
10、、敏捷、高度自动化的特点。开发人员MfJ运维人员云原生架构与传统架构的对比上图展示了在代码中通常包括三部分：业务代码、三方软件、处理非功能特性的代码.其中“业务代码”指实现业务逻辑的代码；三方软件是业务代码中依赖的所有三方库，包括业务库和基础库；“处理非功能性的代码”指实现高可用、安全、可观测性等非功能性能力的代码三部分中只有业务代码是核心，是对业务真正带来价值的，另外两个部分都只算附属物，但随着软件规模的增大、业务模块规模变大、部署环境增多、分布式复杂性增强，使得今天的软件构建变得越来越复杂，对开发人员的技能要求也越来越高。云原生架构相比较传统架构进了一大步，从业务代码中剥离了大量非功能性特
11、性（不会是所有，比如易用性还不能剥离）到IaaS和PaaS中，从而减少业务代码开发人员的技术关注范围，通过云厂商的专业性提升应用的非功能性能力。此外，具备云原生架构的应用可以最大程度利用云服务和提升软件交付能力，进步加快软件开发：0代码结构发生巨大变化云原生架构产生的最大影响就是让开发人员的编程模型发生了巨大变化。今天大部分的编程语言中，都有文件、网络、线程等元素，这些元素为充分利用单机资源带来好处的同时，也提升了分布式编程的复杂性；因此大量框架、产品涌现，来解决分布式环境中的网络调用问题、高可用问题、CPU争用问题、分布式存储问题在云的环境中，比如如何获取存储”变成了若干服务，包括对象存储服
12、务、块存储服务和没有随机访问的文件存储服务。云不仅改变了开发人员获得这些存储能力的界面，还在于云产品在这些OPenAPl或者开源SDK背后把分布式场景中的高可用挑战、自动扩缩容挑战、安全挑战、运维升级挑战等都处理了，应用的开发人员就不用在其代码中处理节点宕机前如何把本地保存的内容同步到远端的问题，也不用处理当业务峰值到来时如何对存储节点进行扩容的问题，而应用的运维人员不用在发现zeroday安全问题时紧急对三方存储软件进行升级云把三方软硬件的能力升级成了服务，开发人员的开发复杂度和运维人员的运维工作量都得到极大降低。显然，如果这样的云服务用得越多，那么开发和运维人员的负担就越少，企业在非核心业
13、务实现上从必须的负担变成了可控支出。在一些开发能力强的公司中，对这些三方软硬件能力的处理往往是交给应用框架（或者说公司内自己的中间件）来做的；在云的时代云厂商提供了更具SLA的服务，使得所有软件公司都可以由此获益。这些使得业务代码的开发人员技能栈中，不再需耍掌握文件及其分布式处理技术，不再需耍掌握各种复杂的网络技术简化让业务开发变得更敏捷、更快速！Pno-Ueqeq-Aq A s4*Jna=-cUJV 学口 eupnoo非功能性特性的大量委托任何应用都提供两类特性，功能性特性和非功能性特性。功能性特性是真正为业务带来价值的代码，比如如何建立客户资料、如何处理订单、如何支付等等：即使是一些通用的
14、业务功能特性，比如组织管理、业务字典管理、搜索等等也是紧贴业务需求的。非功能性特性是没有给业务带来直接业务价值，但通常又是必不可少的特性，比如高可用能力、容灾能力、安全特性、可运维性、易用性、2测试性、灰度发布能力等等。不能说云计算解决了所有非功能性问题，但确实大量非功能性特性，特别是分布式环境下复杂非功能性问题，被云产品处理掉了.以大家最头疼的高可用为例，云产品在多个层面为应用提供了解决方案：虚机：当虚机检测到底层硬件异常时，白动帮助应用做热迁移，迁移后的应用不需重新启动而仍然具备对外服务的能力，应用对整个迁移过程都不会有任何感知；容器：有时应用所在的物理机是正常的，只是应用自身的问题（比如
15、bug、资源耗尽等）而无法正常对外提供服务.容器通过监控检查探测到进程状态异常，从而实施异常节点的下线、新节点上线和生产流量的切换等操作，整个过程自动完成而无需运维人员干预；云服务：如果应用把有状态部分都交给了云服务（如缓存、数据库、对象存储等），加上全局对象的持有小型化或具备从磁盘快速重建能力，由于云服务本身是具备极强的高可用能力，那么应用本身会变成更薄的无状态应用，因为高可用故障带来的业务中断会降至分钟级：如果应用是N-M的对等架构架构模式，那么结合LoadBalancer产品可获得几乎无损的高可用能力！高度自动化的软件交付软件一旦开发完成，需要在公司内外部各类环境中部署和交付，以将软件价
16、值交给最终客户。软件交付的困难在于开发环境到生产环境的差异（公司环境到客户环境之间的差异）以及软件交付和运维人员的技能差异，填补这些差异的是一大堆安装手册、运维手册和培训文档。容器以一种标准的方式对软件打包，容器及相关技术则帮助屏蔽不同环境之间的差异，进而基于容器做标准化的软件交付。对自动化交付而言，还需要一种能峥描述不同环境的工具，让软件能够理解目标环境、交付内容、配置清单并通过代码去识别目标环境的差异，根据交付内容以“面向终态”的方式完成软件的安装、配置、运行和变更.基于云原生的自动化软件交付相比较当前的人工软件交付是一个巨大的进步。以微服务为例，应用微服务化以后，往往被部署到成千上万个节
17、点上，如果系统不具备高度的自动化能力，任何一次新业务的上线，都会带来极大的工作量挑战，严重时还会导致业务变更超过上线窗口而不可用。云原生架构原则电云原生架构本身作为一种架构，也有若干架构原则作为应用架构的核心架构控制面，通过遵从这些架构原则可以让技术主管和架构师在做技术选择时不会出现大的偏差。Q服务化原则当代码规模超出小团队的合作范围时，就有必要进行服务化拆分了，包括拆分为微服务架构、小服务（MiniService）架构，通过服务化架构把不同生命周期的模块分离出来，分别进行业务迭代，避免迭代频繁模块被慢速模块拖慢，从而加快整体的进度和稳定性。同时服务化架构以面向接U编程，服务内部的功能高度内聚
18、，模块间通过公共功能模块的提取增加软件的复用程度。分布式环境下的限流降级、熔断隔仓、灰度、反压、零信任安全等，本质上都是基于服务流量（而非网络流量）的控制策略，所以云原生架构强调使用服务化的目的还在于从架构层面抽象化业务模块之间的关系，标准化服务流量的传输，从而帮助业务模块进行基于服务流量的策略控制和治理，不管这些服务是基于什么语言开发的。弹性原则大部分系统部署上线需要根据业务量的估算，准备一定规模的机器，从提出采购申请，到供应商洽谈、机器部署上电、软件部署、性能压测，往往需要好几个月甚至一年的周期；而这期间如果业务发生变化了，重新调整也非常困难。弹性则是指系统的部署规模可以随着业务量的变化自
19、动伸缩，无须根据事先的容量规划准备固定的硬件和软件资源-好的弹性能力不仅缩短了从采购到上线的时间，让企业不用操心额外软硬件资源的成本支出（闲置成本），降低了企业的IT成本，更关键的是当业务规模面临海量突发性扩张的时候，不再因为平时软硬件资源储备不足而“说不，保障了企业收益。O可观测原则PnoP 4 Hed z$ 3wvef-e30-u x今天大部分企业的软件规模都在不断增长，原来单机可以对应用做完所有调试，但在分布式环境下需要对多个主机上的信息做关联，才可能回答清楚服务为什么宕机、哪些服务违反了其定义的SL0、目前的故障影响哪些用户、最近这次变更对哪些服务指标带来了影响等等，这些都要求系统具备
20、更强的可观测能力。可观测性与监控、业务探活、APM等系统提供的能力不同，前者是在云这样的分布式系统中，主动通过日志、链路跟踪和度量等手段，让一次APP点击背后的多次服务调用的耗时、返回值和参数都清晰可见，甚至可以下钻到每次三方软件调用、SQL请求、节点拓扑、网络响应等，这样的能力可以使运维、开发和业务人员实时掌握软件运行情况，并结合多个维度的数据指标，获得前所未有的关联分析能力，不断对业务健康度和用户体验进行数字化衡量和持续优化。0韧性原则当业务上线后，最不能接受的就是业务不可用，让用户无法正常使用软件，影响体验和收入。韧性代表了当软件所依赖的软硬件组件出现各种异常时，软件表现出来的抵御能力，
21、这些异常通常包括硬件故障、硬件资源瓶颈（如CPU:网卡带宽耗尽）、业务流量超出软件设计能力、影响机房工作的故障和灾难、软件bug、黑客攻击等对业务不可用带来致命影响的因素。韧性从多个维度诠释了软件持续提供业务服务的能力，核心目标是提升软件的MTBF（MeanTmoBetweenFailure,平均无故障时间）.从架构设计上，韧性包括服务异步化能力、重试/限流，降级熔断/反压、主从模式、集群模式、AZ内的高可用、单元化、跨region容灾、异地多活容灾等.O所有过程自动化原则技术往往是把双刃剑，容器、微服务、DeVoPs、大量第三方组件的使用，在降低分布式复杂性和提升迭代速度的同时，因为整体增大
22、了软件技术栈的复杂度和组件规模，所以不可避免地带来了软件交付的复杂性，如果这里控制不当，应用就无法体会到云原生技术的优势。通过IaC（InfrastructureasCode）、GitpsOAM（OpenApplicationModel）、Kubernetesoperator和大量自动化交付工具在CI/CD流水线中的实践，一方面标准化企业内部的软件交付过程，另一方面在标准化的基础上进行自动化，通过配置数据自描述和面向终态的交付过程，让自动化工具理解交付目标和环境差异，实现整个软件交付和运维的自动化。0零信任原则零信任安全针对传统边界安全架构思想进行了重新评估和审视，并对安全架构思路给出了新建议
23、.其核心思想是，默认情况下不应该信任网络内部和外部的任何人/设备/系统，需要基于认证和授权重构访问控制的信任基础，诸如IP地址、主机、地理位置、所处网络等均不能作为可信的凭证。零信任对访问控制进行了范式上的颠覆，引导安全体系架构从网络中心化走向身份中心化，其本质诉求是以身份为中心进行访问控制。零信任第一个核心问题就是Identity.赋予不同的Entity不同的Identity,解决是谁在什么环境下访问某个具体的资源的问题。在研发、测试和运维微服务场景下，Identity及其相关策略不仅是安全的基础，更是众多（资源，服务，环境）隔离机制的基础：在员工访问企业内部应用的场景下，Identity及
24、其相关策略提供了灵活的机制来提供随时随地的接入服务。0架构持续演进原则今天技术和业务的演进速度非常快，很少有一开始就清晰定义了架构并在整个软件生命周期里面都适用，相反往往还需要对架构进行一定范围内的重构，因此云原生架构本身也应该和必须是一个具备持续演进能力的架构，而不是一个封闭式架构。除了增量迭代、目标选取等因素外，还需要考虑组织（例如架构控制委员会）层面的架构治理和风险控制，特别是在业务高速迭代情况下的架构、业务、实现平衡关系。云原生架构对广新建应用而言的架构控制策略相对容易选择（通常是选择弹性、敏捷、成本的维度），但对于存量应用向云原生架构迁移，则需要从架构上考虑遗留应用的迁出成本/风险和
25、到云上的迁入成本/风险，以及技术上通过微服务/应用网关、应用集成、适配器、服务网格、数据迁移、在线灰度等应用和流量进行细颗粒度控制。主要架构模式明云原生架构有非常多的架构模式，这里选取-些对应用收益更大的主要架构模式进行讨论。0服务化架构模式服务化架构是云时代构建云原生应用的标准架构模式，要求以应用模块为颗粒度划分一个软件，以接口契约（例如IDD定义彼此业务关系，以标准协议（HTTP、gRPC等）确保彼此的互联互通，结合DDD（领域模型驱动）、TDD（测试驱动开发）、容器化部署提升每个接口的代码质量和迭代速度。服务化架构的典型模式是微服务和小服务（MiniService）模式，其中小服务可以看
26、做是一组关系非常密切的服务的组合，这组服务会共享数据，小服务模式通常适用于非常大型的软件系统，避免接口的颗粒度太细而导致过多的调用损耗（特别是服务间调用和数据一致性处理）和治理复杂度.通过服务化架构，把代码模块关系和部署关系进行分离，每个接口可以部署不同数量的实例，单独扩缩容，从而使得整体的部署更经济。此外，由于在进程级实现了模块的分离，每个接D都可以单独升级，从而提升了整体的迭代效率。但也需要注意，服务拆分导致要维护的模块数量增多，如果缺乏服务的自动化能力和治理能力，会让模块管理和组织技能不匹配，反而导致开发和运维效率的降低。Mesh化架构模式p90p eqeq-Aq Jvded 3JmE-
27、xvA=?U-PnO-U WMesh化架构是把中间件框架（比如RPC.缓存、异步消息等）从业务进程中分离，让中间件SDK与业务代码进一步解耦，从而使得中间件升级对业务进程没有影响，甚至迁移到另外一个平台的中间件也对业务透明。分面后在业务进程中只保留很薄的Client部分，Client通常很少变化，只负责与Mesh进程通讯，原来需要在SDK中处理的流量控制、安全等逻辑由MeSh进程完成。整个架构如下图所示。容器/主机容器主机业务进程SDK协议业务进程SDK协议/标准协议Mesh进程（流量:控制、安全策略、微隔离）网络I新协议、加密、染色券网络传统架构Mesh化架构实施Mesh化架构后，大量分布式
28、架构模式（熔断、限流、降级、重试、反压、隔仓）都由Mesh进程完成，即使在业务代码的制品中并没有使用这些三方软件包；同时获得更好的安全性（比如零信任架构能力）、按流量进行动态环境隔离、基于流量做冒烟/同归测试等。Serverless模式和大部分计算模式不同，Serverless将部署这个动作从运维中收走，使开发者不用关心应从架构抽象上看，当业务流用在哪里运行，更不用关心装什么OS、怎么配置网络、需要多少CPU量到来/业务事件发生时，云会启动或调度一个已启动的业务进程进行处理，处理完成后云自动会关闭/调度业务进程，等待下一次触发，也就是把应用的整个运行时都委托给云。今天Serverless还没有
29、达到任何类型的应用都适用的地步，因此架构决策者需要关心应用类型是否适合于Serverless运算。如果应用是有状态的，云在进行调度时可能导致上下文丢失，毕竟Serverless的调度不会帮助应用做状态同步；如果应用是长时间后台运行的密集型计算任务，会得不到太多Serverless的优势；如果应用涉及到频繁的外部IO（网络或者存储，以及服务间调用），也因为繁重的1.0负担、时延大而不适合。Serverless非常适合于事件驱动的数据计算任务、计算时间短的请求/响应应用、没有复杂相互调用的长周期任务。存储计尊分离模式分布式环境中的CAP困难主要是针时有状态应用，因为无状态应用不存在C（一致性）这个
30、维度,因此可以获得很好的A（UJ用性）和P（分区容错性），因而获得更好的弹性。在云环境中，推荐把各PnCO2- JXEd c 3Jn3t UJJV BAneU-PnO-Uwx类暂态数据（如session）、结构化和非结构化持久数据都采用云服务来保存，从而实现存储计算分离。但仍然有一些状态如果保存到远端缓存，会造成交易性能的明显下降，比如交易会话数据太大、需要不断根据上下文重新获取等，则可以考虑通过采用EVentLog+快照（或CheCkPoint）的方式，实现重启后快速增量恢复服务，减少不可用对业务的影响时长。0分布式事务模式微服务模式提倡每个服务使用私有的数据源，而不是像单体这样共享数据源，
31、但往往大颗粒度的业务需要访问多个微服务，必然带来分布式事芬问题，否则数据就会出现不一致。架构师需要根据不同的场景选择合适的分布式事务模式。传统采用XA模式，虽然具备很强的一致性，但是性能差；基于消息的最终-致性（BASE）通常有很高的性能.但是通用性有限，且消息端只能成功而不能触发消息生产端的事务回滚；TCC模式完全由应用层来控制事务，事务隔离性可控，也可以做到比较高效；但是对业务的侵入性非常强，设计开发维护等成本很高：SG模式与TCC模式的优缺点类似但没有try这个阶段，而足每个正向事务都对应一个补偿事务，也足开发维护成本高；开源项目SEATA的AT模式非常高性能且无代码开发工作量，且可以自
32、动执行回滚操作，同时也存在一些使用场景限制.0可观测架构可观测架构包括Logging、Tracing,Metrics三个方面，其中LOgging提供多个级别（verbose/debug/warning/error/fatal）的详细信息跟踪，由应用开发者主动提供；TraCing提供一个请求从前端到后端的完整调用链路跟踪，对于分布式场景尤其有用；Metrics则提供对系统量化的多维度度量。架构决策者需要选择合适的、支持可观测的开源框架（比如OpenTracing、OpenTelemetry）,并规范上下文的可观测数据规范（例如方法名、用户信息.、地理位置、请求参数等），规划这些可观测数据在哪些服
33、务和技术组件中传播，利用日志和tracing信息中的spanid/traceid,确保进行分布式链路分析时有足稣的信息进行快速关联分析。由于建立可观测性的主要目标是对服务SLO（ServiceLevelObjective）进行度量，从而优化SLA,因此架构设计上需要为各个组件定义清晰的SLO,包括并发度、耗时、可用时长、容量等。事件驱动架构事件驱动架构(EDA,EventDrivenArchitecture)本质上是一种应用/组件间的集成架构模式,典型的事件驱动架构如下图:事件和传统的消息不同，事件具有schema,所以可以校验event的有效性，同时EDA具备QoS保障机制，也能修对事件处理
34、失败进行响应。事件驱动架构不仅用于(微)服务解耦，还可应用于下面的场景中：增强服务韧性：由于服务间是异步集成的，也就是下游的任何处理失败共至宕机都不会被上游感知，自然也就不会对上游带来影响；CQRS(CommandQueryResponsibiIitySegregation)：把对服务状态ft影响的命令用事件来发起，而对服务状态没有影响的查询才使用同步调用的APl接口：结合EDA中的EventSourcinR可以用于维护数据变更的一致性，当需要Ift新构建服务状态时，把EDA中的事件重新播放”一遍即可；数据变化通知：在服务架构下，往往一个服务中的数据发生变化，另外的服务会感兴趣，比如用户订单完
35、成后，积分服务、信用服务等都需要得到事件通知并更新用户积分和信用等级；构建开放式接口：在EDA卜，事件的提供者并不用关心有哪些订阅者，不像服务调用的场景一一数据的产生者需要知道数据的消费者在哪里并调用它，因此保持了接口的开放性：事件流处理：应用于大量事件流(而非离散事件)的数据分析场景，典型应用是基丁Kafka的口志处理：基于事件触发的响应：在bT时代大量传感器产生的数据，不会像人机交互一样需要等待处理结果的返Pl,天然适合用EDA来构建数据处理应用。E典型的云原生架构反模式M技术往往像一把双刃剑，阿里在自己和帮助客户做云原生架构演进的时候，会充分考虑根据不同的场景选择不同的技术，下面是我们总
36、结的一些典型云原生架构反模式。O庞大的单体应用庞大单体应用的最大问题在于缺乏依赖隔离，包括代码耦介带来的责任不清、模块间接口缺乏治理而带来变更影响扩散、不同模块间的开发进度和发布时间要求难以协调、-个子模块不稳定导致整个应用都变慢、扩容时只能整体扩容而不能对达到瓶颈的模块单独扩容因此当业务模块可能存在多人开发的时候，就需要考虑通过服务化进行一定的拆分，梳理聚合根，通过业务关系确定主要的服务模块以及这些模块的边界、清晰定义模块之间的接口，并让组织关系和架构关系匹配0阿里巴巴在淘宝业务快速发展阶段，就遇到过上百人维护一个核心单体应用，造成了源码冲突、多团队间协同代价高的严重问题。为了支掠不断增长的
37、流量，该应用需要不断增加机器，很快后端数据库连接很快就到达了上限。在还没有微服务概念的2008年，阿里巴巴决定进行服务化架构拆分，当时思路就是微服务架构，第一个服务从用户中心开始建设，后续交易、类目、店铺、商品、评价中心等服务陆续从单体中独立出来，服务之间通过远程调用通信，每个中心由独立团队专门维护，从而解决了研发协同问题，以及按规模持续水平扩展的问题。单体应用硬拆”为微服务服务的拆分需要适度，过分服务化拆分反而会导致新架构与组织能力的不匹配，让架构升级得不到技术红利，典型的例子包括：小规模软件的服务拆分：软件规模不大，团队人数也少，但是为了微服务而微服务，强行把耦合度高、代码量少的模块进行服
38、务化拆分，一次性的发布需要拆分为多个模块分开发布和维护：数据依赖:服务虽然拆分为多个，但是这些服务的数据是紧密耦合的，于是让这些服务共享数据库，导致数据的变化往往被扇出到多个服务中，造成服务间数据依赖:性能降低：当耦合性很强的模块被拆分为多个微服务后，原来的本地调用变成了分布式调用，从而让响应时问变大了上千倍，导致整个服务健路性能急剧卜.降。O缺乏自动化能力的微服务PnoP 4 Hed z$ 3wvef-e30-u x软件架构中非常重要的一个维度就是处理软件复杂度问题，一旦问题规模提升了很多，那就必须重新考虑与之适应的新方案。在很多软件组织中，开发、测试和运维的工作单位都是以进程为单位，比如把
39、整个用户管理作为一个单独的模块进行打包、发布和运行：而进行了微服务拆分后，这个用户管理模块可能被分为用户信息管理、基本信息管理、积分管理、订单管理等多个模块，由于仍然是每个模块分别打包、发布和运行，开发、测试和运维人员的人均负责模块数就直线上升，造成了人均工作量增大，也就增加了软件的开发成本。实际上，当软件规模进-步变大后，自动化能力的缺失还会带来更大的危害。由于接口增多会带来测试用例的增加，更多的软件模块排队等待测试和发布，如果缺乏自动化会造成软件发布时间变长，在多环境发布或异地发布时更是需要专家来处理环境差异带来的影响同时更多的进程运行于一个环境中，缺乏自动化的人工运维容易给环境带来不可重
40、现的影响，而旦发生人为运维错误又不容易快速止血”，造成了故障处理时间变长，以及使得日常运维操作都需要专家才能完成.所有这些问题导致软件交付时间变长、风险提升以及运维成本的增加.3主要云原生技术1容器技术%O容器技术背景与价值容器作为标准化软件单元，它将应用及其所有依赖项打包，使应用不再受环境限制，在不同计算环境间快速、可靠地运行。传统、虚拟化及容器部署模式比较Container Deployment虽然2008年LinUX就提供了Cgroups资源管理机制、LinUXNatnespace视图隔离方案，让应用得以运行在独立沙箱环境中，避免相互间冲突与影响；但直到Docker容器引擎的开源，才很大
41、程度上降低了容器技术的使用复杂性，加速了容器技术普及。DoCker容器基于操作系统虚拟化技术，共享操作系统内核、轻量、没有资源损耗、秒级启动，极大提升了系统的应用部署密度和弹性。更重要的是，Docker提出了创新的应用打包规范Docker镜像，解耦了应用与运行环境，使应用可以在不同计算环境间一致、可靠地运行。借助容器技术呈现了一个优雅的抽象场景：让开发所需要的灵活性、开放性和运维所关注的标准化、自动化达成杆I对平律.容器镜像迅速成为了应用分发的工业标准。随后开源的Kubernetes,凭借优秀的开放性、可扩展性以及活跃开发者社区，在容器编排之战中脱颖而出，成为分布式资源调度和自动化运维的事实标
42、准。Kubcrnetes屏蔽了IaaS层基础架构的差异并凭借优良的可移柄性，帮助应用-致地运行在包括数据中心、云、边缘计算在内的不同环境.企业可以通过Kubernetes,结合自身业务特征来设计自身云架构，从而更好支持多云/混合云，免去被厂商锁定的顾虑。伴随着容器技术逐步标准化，进一步促进了容器生态的分工和协同。基于Kubernetes,生态社区开始构建上层的业务抽象，比如服务网格ISU0、机器学习平台Kubeflow,无服务器应用框架KnatiVe等。在过去儿年，容器技术获得了越发广泛的应用的同时，三个核心价值最受用户关注：械捷容器技术提升企业IT架构敏捷性的同时，止业务迭代更加迅捷，为创新
43、探索提供了坚实的技术保障。比如疫情期问，教育、视频、公共健康等行业的在线化霜求突现爆发性高速增长，很多企业通过容器技术适时把握了突如其来的业务快速增长机遇。据统计，使用容器技术可以获得310倍交付效率提升，这意味着企业可以更快速的迭代产品，更低成本进行业务试错。，弹性在互联网时代，企业IT系统经常需耍面对促销活动、突发事件等各种预期内外的爆发性流量增长.通过容器技术，企业可以充分发挥云计算弹性优势，降低运维成本。一般而言，借助容器技术，企业可以通过部署密度提升和弹性降低50%的计算成本。以在线教育行业为例，面对疫情之下指数级增长的流量，教育信息化应用工具提供商希沃Seewo利用阿里云容器服务A
44、CK和弹性容器实例ECI大大满足了快速扩容的迫切需求，为数十万名老师提供了良好的在线授课环境，帮助百万学生进行在线学习。可移柩性容器已经成为应用分发和交付的标准技术，将应用与底层运行环境进行解耦：KUberneteS成为资源调度和编排的标准，屏蔽了底层架构差异性，帮助应用平滑运行在不同基础设施上.CNCF云原生计算基金会推出了Kubernetes一致性认证，进一步保障了不同K8s实现的兼容性，这也让企业愿意采用容器技术来构建云时代应用基础设施。容器编排PnOD 2e-S23Q-OKubernetes已经成为容器编排的事实标准，被广泛用于自动部署，扩展和管理容器化应用。Kubernetes提供了
45、分布式应用管理的核心能力：资源调度：根据应用请求的资源量CPU、Memory,或者GPU等设备资源，在集群中选择合适的节点来运行应用：应用部署与管理：支持应用的自动发布与应用的回滚，以及与应用相关的配置的管理；也可以自动化存储卷的编排，让存储卷与容器应用的生命周期相关联；自动修复：KUbernCySE以会监测这个奥群中所有的宿主机，7宿主机或者OS出现故障，节点健康检查会自动进行应用迁移：K8s也支持应用的自愈，极大简化了运维管理的复杂性：服务发现与负载均衡：通过Servce资源出现各种应用服务，结合DNS和多种负载均衡机制，支持容器化应用之间的相互通信；弹性伸缩：K8s可以监测业务上所承担的
46、负载，如果这个业务本身的CPU利用率过高，或者响应时间过长，它可以对这个业务进行自动扩容。Kubcrnetes的控制平面包含四个主要的组件：APIServer,Controller-,Scheduler以及etcd如下图所小：Node 1PodsContainer Runt imekubeletSystomServicesNode 2PodsCloudProviderNe two rd EdgContainerRuntimekubelotSystemServicesKubernetes在容器编排中行儿个关键设计理念：声明式API：开发者可以关注于应用自身，而非系统执行细节。比如Deployment（无状态应用）、StatefuISet（有状态应用）、Job（任务类应用）等不同资源类型，提供了对不同类型工作负载的抽象；对Kubernetes实现而言，基于声明式API的hlevel-triggered*实现比“edge-triggered”方式可以提供更加健壮的分布式系统实现。*可扩展性架构：所有K8s组件都是基于一致的、开放的API实现和交互：三方开发者也可通过CRD（CustomResourceDefinition）/Operator等方法提供领域相关的扩展实现，极大提升/K8s的能力。
