阿里云：微服务治理技术白皮书_379页_19mb.pdf

Microservices Governance Technology电子书中涉及的部分服务治理技术和最佳实践，已经通过 OpenSergo 对外进行开源，该项目由阿里云、bilibili、字节跳动、Apache Dubbo/dubbogo 社区、Nacos 社区、Spring Cloud Alibaba 社区共同维护，相关微服务治理技术已被来自各行各业的数千家企业所采用，特别鸣谢上海三菱电梯、来电科技、Saleforce 中国为此书撰写推荐序，欢迎更多企业加入，共建服务治理开放社区。阿里云开发者“藏经阁” 海量电子手册免费下载Microservices Governance Technology 阿云研究员，云原应平台负责 - 丁宇（叔同）在阿巴巴微服务架构 10 余年的演进历程中，服务部署量不断扩，已经迈百万节点规模，如此庞的微服务体系必须要通过服务治理进精细化管控，提升线上业务稳定性。阿集团的服务治理框架从到有，经历了服务框架提供治理 SDK、轻量级隔离容器 Pandora 、侵式的 Java Agent 以及针对异构微服务的 Service Mesh 等架构迭代历程，这个过程中沉淀了丰富的服务治理能，涵盖了开发、测试、线上运维、可等多个。这本技术书系统化的阐述了服务治理的演进路线以及落地最佳实践，相信对企业开发者和架构师在采纳微服务架构时能有所帮助。 阿云资深技术专家，云原中间件负责 - 胡伟琪（慕）阿巴巴作为国内微服务的先者，有着丰富的实践经验和技术积累，近年阿巴巴中间件团队推三位体的技术战略，把内部业务持、云产品、开源进了技术和架构的统，并开源了系列优秀的项，包括 Apache Dubbo，Apache RocketMQ、Nacos、SpringCloud Alibaba、Seata 等，为量企业进微服务化架构升级提供了助。本书是阿巴巴中间件团队在微服务领域的又作，详尽介绍了阿巴巴针对规模微服务场景下，进效治理的案和思想，推荐前有计划或已经完成了微服务改造、对微服务领域技术有兴趣的技术阅读。 阿云资深技术专家，云原 Serverless 及可观测产品线负责 - 司徒放（姬）在微服务架构已经其道的今天，为什么我们要谈微服务治理？就像斯洛需求模型所述，类的需求是理、安全、社交、尊重和我成就的逐步实现。类似的，企业实施微服务架构的过程也遵循着同样的道理。微服务架构，第阶段要解决服务间的发现问题和相互通信问题，这是微服务框架所覆盖的基本功能。第阶段要解决微服务应的交付和规模化运维问题，这些是容器和 K8s 所擅的领域。第三阶段随着微服务架构复杂化，分布式场景下排查和诊断效率急剧下降开始成为开发者主要痛点，因此催了分布式链路跟踪和可观测性技术。正所谓“乱极必治”，微服务架构是把双刃剑，规模之下掩盖的问题很多，从开发联调到发布上线，从流量防护到故障恢复再到容灾，如果不引恰当的治理段，很可能会积重难返、万劫不复。因此微服务治理是微服务演进的第四个必然阶段，微服务治理得到重视是恰逢其时。推荐序 Alibaba Cloud Microservices Governance Technology阿巴巴从 2008 年开始践微服务，阿中间件团队也路伴随着过了上述个阶段，是微服务架构发展的亲历者。这本书来中间件团队对微服务最有经验的那个之，也是阿微服务开源 Dubbo、Spring Cloud Alibaba、Nacos 等项的主要创作者。他们结合了阿身的微服务实践，以及中间件上云之后服务外部企业客户的第案例，我认为本书论从内容的丰富度，还是经验的普适性来看，都是国内最有参考价值的份微服务架构材料。将本书诚挚推荐给每个希望在企业 内应微服务架构的架构师、以及对微服务有兴趣的爱好者阅读。 阿里云高级技术专家，云原生解决方案负责人 - 邱戈川（了哥）软件技术的发展，从单体的应用，逐渐演进到分布式应用， 特别是微服务理念的兴起，让大规模、高并发、低延迟的分布式应用成为可能。但是微服务架构不是银弹， 其维护的复杂度，以及管理、治理的难度超过以往的任何系统架构。而阿里巴巴/阿里云中间件团队是这个领域的先行者，通过多年的阿里巴巴内部演进与支持，以及与大量的阿里云外部客户的共同努力，沉淀出在业界领先的微服务领域特别是服务治理上的一套方法论以及最佳实践。这本白皮书，正是微服务治理方法论以及最佳实践的归纳与总结，可以帮助大家在微服务架构设计与管理上提供很好的借鉴与参考。特别是其独特的类似 Mesh 的理念在容器下结合 Java Agent 模式，很好的解决了 Java 领域提供无侵入式增强治理能力如限流降级、全链路灰度、可观测性增强等问题，同时又巧妙的规避了升级、版本不一致等等维护的代价。如果你正好采用微服务架构来完善自己的应用体系，这个白皮书绝对值能帮助你完善你的架构设计，为你的业务稳定运行提供技术架构保障，强烈推荐！ 上海三菱电梯，系统开发总监 - 谢璟云原时代，软件架构，软件框架都经历速的发展。从最早期 Eureka，到前国内以 Nacos为的微服务态，阿巴巴为此作出了卓越贡献。在和阿云和阿巴巴合作过程中，深深感受到阿云的技术氛围和底蕴，通过侵的 Java Agent ，全代码零侵，提供了缝切换阿微服务治理技术案。阿云的服务治理的模型，依托阿云坚实的底座，结合阿云云上资源，使得我们能够快速融阿云服务治理，形成统，标准，最佳的微服务治理案。微服务治理技术，思想，解决案，最佳实践都在本书有详细的阐述，是值得每个技术员认真品读的好书。Microservices Governance Technology 来电科技 CTO - 罗昌明来电科技拥有百万级的物联网终端，中后台微服务化后拥有数百个微服务组件，管理这些微服务是个极其复杂的工程。阿里云 MSE 微服务治理技术帮助来电无侵入地实现了服务预热、无损上下线、全链路灰度等微服务治理能力，大大提升了服务的稳定性。如果你正准备深入微服务治理相关知识或者遇到相同问题，那么这本书正好可以提供深入学习的机会。 Salesforce 中国，技术总监 - 叶文帅随着业务的发展和团队扩大，微服务架构成为了许多大规模开发团队的不二选择。在微服务架构发展的过程中，我们经历了从传统分布式微服务框架治理到云原生微服务治理的演变。伴随着服务数量的增多以及对服务稳定性要求的提高，社区上和公有云上都诞生了许多优秀的微服务治理工具。阿里云中间件团队针对开发者们在微服务开发中遇到的痛点，结合阿里云生态，在本书讲述了云原生下微服务治理架构的设计以及微服务治理的最佳实践。相信这本白皮书能给企业中微服务架构师，以及对微服务架构有兴趣的开发者带来帮助。Microservices Governance Technology第章：综述 11.1 业务发展离不开微服务治理保驾护航 11.2 微服务治理在云原场景下的挑战 71.3 微服务治理的发展趋势 111.4 微服务治理的区分 18第章：微服务治理技术原理介绍 212.1 微服务治理技术概述 212.2 通过 SDK 式进微服务治理 232.3 通过 Java Agent 式进微服务治理 252.4 通过 Service Mesh 来进微服务治理 28第三章：微服务治理在云原场景下的解决案 333.1 线上发布稳定性解决案 333.2 微服务全链路灰度解决案 433.3 微服务可观测增强解决案 563.4 微服务应配置解决案 693.5 微服务限流降级解决案 763.6 微服务开发测试提效解决案 853.7 微服务敏捷开发解决案 903.8 微服务缝迁移上云解决案 953.9 线上故障紧急诊断、排查与恢复 1033.10 微服务注册发现可解决案 1133.11 微服务应安全解决案 1183.12 异构微服务互通解决案 1223.13 微服务 Serverless PaaS 解决方案 125CONTENT Alibaba Cloud Microservices Governance TechnologyMicroservices Governance Technology128129146165183199221245262272277289306319330339339346357363368第四章：基于MSE的微服务治理最佳实践4.1 线上发布稳定性解决案最佳实践4.2 全链路灰度最佳实践4.2.1 Ingress-nginx 全链路灰度4.2.2 Zuul 和 Spring Cloud Gateway 全链路灰度4.2.3 MSE 云原关全链路灰度4.2.4 全链路灰度之 RocketMQ 灰度4.2.5 使Jenkins CI/CD 实现丝雀发布4.3 微服务应配置最佳实践4.4 微服务限流降级最佳实践4.5 微服务开发测试提效最佳实践4.6 微服务敏捷开发最佳实践4.7 微服务缝迁移上云实践4.8 如何快速构建服务发现的可能4.9 如何在 Serverless 模式下快速使用服务治理能力第五章：微服务治理客户案例5.1 物流行业：菜 Cpaas 平台微服务治理实践5.2 互联网行业：来电科技微服务治理实践5.3 机器智能行业：云小蜜 Dubbo3 微服务治理实践5.4 游戏行业：广州小迈微服务治理实践第六章：总结与展望总结与展望 368作者按照姓名拼音升序排序作者Microservices Governance TechnologyAlibaba Cloud 白壮丽 - 竹达曹玲微 - 陌微曹茵茵 - 蔓铃陈飞 - 麒汀陈涛 - 毕衫陈昕 - 捌哥范扬 - 扬少鲁严波 - 卜比泮圣伟 - 十眠饶子昊 - 铖朴苏宇 - 流士汤长征唐慧芬 - 黛忻王桐 - 瑾涵肖京 - 亦盏叶辰超 - 楚寰张海彬 - 古琦张乎兴 - 望陶张伟 - 柑橘张哲 - 溪岳赵俊阳 - 墨昀赵奕豪 - 宿何方剑 - 洛夜徐靖峰 - 岛风Microservices Governance Technology 1第章：综述1.1 业务发展离不开微服务治理保驾护航微服务开发不简单随着微服务技术的发展，微服务(MicroServices) 的概念早已深，也越来越多的公司开始使微服务架构来开发业务应。如果采得当，微服务架构可以带来常的优势。微服务架构的最好处是它可以提升开发效率和系统整体的稳定性： 开发和部署相对简单：单个微服务的功能可以更快地更改，因为可以独部署，影响范围更，启动和调试单个微服务的时间成本相于单体应也减少。 横向扩展简单：根据业务的峰低周期快速的横向扩展常简单，因为单个微服务通常很，可以随着系统整体负载的变化更快地启动和停。 架构升级灵活：单个微服务的内部架构可以迅速升级，因为微服务之间松散耦合的，只向定义好的通讯接进编程。这使开发团队能够基于身的技术背景和偏好灵活选择，不会直接影响其他应程序、服务或团队。 更好的容错性：微服务之间可以实现更好的故障隔离，单个服务内的内存泄露等故障不容易影响其他服务，相单体应个组件故障会拖垮整个系统。但是微服务在实施过程中，也很容易遇到些难点。如果微服务治理得不恰当，反有可能适得其反，不仅不能享受到微服务架构带来的好处，反会因为微服务带来的系统复杂性，造成开发、运维部署的复杂度增加，进影响开发迭代的速度，甚影响系统的整体稳定性。2我们总结了些微服务开发实施过程中常的问题： 服务之间使远程调进通讯，这进程内的直接调复杂很多。由于通讯链路的复杂性，可能会出现很多不确定的问题，会出现远程调不可或者延迟较的情况，开发员需要能够处理这些偶发问题，避免影响业务。 随着业务的发展，微服务之间的拓扑图开始变得复杂，排查问题变得困难，搭建完整的开发测试环境成本也越来越。 当功能涉及到多个微服务模块时，迭代时需要谨慎地协调多个开发团队的迭代排期，才能保证迭代能够按时交付，达到敏捷开发的效果。Microservices Governance Technology个微服务成功落地的典型案例观察了阿云众多客户之后，我们总结抽象了个微服务成功落地的典型案例，叙述了某公司是如何借助于微服务架构的红利，实现了业务快速增的。案例详细说明了在业务发展的不同阶段，该公司在微服务实施过程遇到的问题，也描述了如何通过微服务治理来解决这些问题，从享受到了微服务带来的开发效率和业务稳定性提升的红利，进促进业务快速发展。业务孵化期初创公司在刚起步时，虽然业务量较、业务模式较简单，但是为了在后续的快速发展中能够快速迭代，同时公司的才储备也满微服务开发的条件，于是在初创期就选择了使微服务架构进业务开发。在技术选型，如果公司创始员是技术出身，那么会较倾向于使擅的微服务框架，如创始是 Dubbo 的 contributor ，或者是 Spring Cloud 社区的咖或者 SpringCloud Alibaba 的 contributor，又或者是 Service Mesh 社区的咖，那么般都会选所擅的微服务框架类型。还有种选择是选市上最流的微服务框架，如 Java 体系，会选择 SpringCloud 和 Dubbo。这样的话，在前的招聘市场上也容易招聘到熟悉相关领域的，从初学者到专家级的候选都能很容易招聘到。选定了技术选型后，基于开源的框架，很容易就能开发好最初的业务应系统，跑通业务流程。这阶段组件也很简单。简单的两三个应，户系统、业务系统、持系统，再加上注册中31.因为代码本身逻辑出错导致业务异常：这时可以通过 SLS 查询志，结合 ARMS 分析错误堆栈找到根因，修改完代码后，重新发布来修复问题。2.遇到性能瓶颈：则直接扩容操作，如平扩容应，或者升级数据库。3.发布新版本影响到户：因为户数和请求数都不算多，很容易就可以找到业务低峰期，在业务低峰期进发布。4.如何确保新版本的正确性，因为业务场景不复杂，内部测试就能覆盖所有的场景，测试通过就可以直接上线。那如何识别身的业务是否处于这个阶段呢？有系列典型的特征：应不超过 4 个，应节点总数不超过 10 个，最峰时候的 QPS 不超过 10。业务快速发展期在活过初创期之后，公司的业务很受户和市场的欢迎，注册的户越来越多，户使的时和功能点也越来越多，活数越来越，甚市场中还出现了其他竞争者开始抄袭公司的业务，一些巨头还亲下场参与竞争。公司业务发展得常顺利，这也意味着系统进了快速发展时期。Microservices Governance Technology 、数据库、缓存，就可以开发完全部的应 。对于 个 产级别的系统来说，在将整套系统部署上线之前，还需要建设监控报警系统。监控报警系统能够帮助我们实时监控机器和应 的状态。我们可以配置预设的报警规则，在出现机器资源不 ，业务出现异常报错时这些情况时主动报警，提醒我们尽快处理系统中的 险和异常。保留问题的现场，并帮助我们快速地定位和排查问题也同样重要，阿 云应 实时监控服务 ARMS 和 志服务 SLS 能够在这些场景提供很 的帮助。采 ARMS + SLS 完成监控报警系统建设之后，将业务系统部署上线，完成第 次成功上线，业务开始正常运 起来了。但是业务的开发和运营从来都不是 帆 顺的，在这个过程中，肯定也会遇到很多问题，我们先总结 下这个阶段常 的问题及应对 案：4市场发展很迅速，注册户数、活这些数据也是节节攀升，所有统计报表的数字都是向好。但是带来的挑战也越来越，这个时期也是最危险的时期：在业务快速发展中，既要保证好已有业务的稳定性，要快速地迭代新功能，还要克服团队招聘节奏跟不上业务发展的问题。这个阶段典型的特征是应个数在 5 到 50 个，QPS 在 10 到 1000。这个时期经常会遇到的问题概括起来就是两个：稳定性问题和开发效率问题。稳定性的问题：户数多起来之后，系统的稳定性就显得较重要，论是户在某段时间遇到异常报错增多，还是某个功能点持续性地报错，再到系统有段时间完全不可，这些都会影响产品在户中的碑，最后这种完全不可的场景，甚还可能成为微博等社交络上的舆论热点。开发效率的问题：随着户的增多，相应的需求也越来越多，业务场景也越来越复杂，在这个时候测试可不是内部测试就能覆盖所有的场景，需要加在测试上的投。虽然功能需求越来越多，但是迭代的速度却要求越来越快，因为市场中已经出现了竞争者，如果他们抄得快，新功能也上得快，业务有可能会竞争不过，特别是当巨头亲下场的时候，更需要跑得更快，开发节奏要快，测试节奏要快，发版节奏也要快。那么如何去解决这两个场景的痛点呢，这时候可以要借助微服务治理的能来解决。1.开发测试提效Microservices Governance Technologya.【开发环境隔离】传统的多套开发环境，需要使多套的物理环境，才能实现多套环境各独互不扰，但是多套物理环境的隔离的机器成本是很的，基本上不能接受。但通过全链路灰度这种逻辑隔离的式实现开发环境隔离，可以在不增加成本的情况下增加多套开发测试环境，助你实现敏捷开发。b.【动化回归测试】动化回归测试功能，可以将多个测试例串联成测试例集，将上条测试的返回值作为下跳测试参，串联成具体的业务场景并沉淀到动化回归测试中，在每次的发版之前都跑次动化回归来验证功能的正确性，这样就可以节省测试的成本。更进步，还可以通过流量录制回放功能，将线上的真实流量录制下来，并沉淀成动化回归例集，在测试环境进流量回放，更进步地提升测试 case 的覆盖率。5c.【服务契约】功能越来越多，迭代越来越快，API 越来越复杂，团队之间沟通的效率越来越低，API 档严重过期。如果能动成服务契约，可以有效地避免档腐化造成的开发效率低下的问题。使上三点之后，可以在低成本的条件下持多套开发测试环境，实现动化回归测试，实现开发节奏和测试节奏的提效。2.安全发布a.【损下线】损下线问题的根本原因是开源的微服务体系没有确保应提供者节点在停服务前确保已经通知到所有消费者不再调，也法确保在处理完所有请求之后再停应。所以新发版的应，即使业务代码没有任何问题，也可能在发布过程影响户的体验。b.【损上线】损上线问题出现的原因是因为在某些场景下服务提供者，需要经过段时间才能正常地接收流量的请求并成功返回。同时在 K8s 场景下，还需要和 K8s 中的 readiness 、滚动发布等命周期紧密结合，才能确保应发布过程中能不出现业务报错。c.【全链路灰度】新功能上线之后，可以通过灰度规则控制哪些户可以使。这样可以先选择让内部户使，测试新功能的正确性。当内部户验证通过后，再渐渐地扩灰度范围，确保每个功能都经过充分验证后再全量开放给客户，屏蔽掉发布新功能的险。且当出现问题时，可以通过修改灰度规则来实现快速回滚，做到新版本发版时乎险。使以上点之后，可以确保新版本的发布不出问题，且可以做到天在流量场景下也轻松发布，在实现天轻松发布之后，天就可以发布多次，提升发布时候的稳定性和发版的效率。3.屏蔽偶发异常导致的险a.【离群实例摘除】对于这些偶发的异常问题，离群摘除功能可以智能判断应中的服务提供者某个出现了问题，智能地在段时间内屏蔽掉这个服务提供者，保证业务的正常，等这个服务提供者恢复过来之后再进调。可以在应节点出现偶发异常时，智能屏蔽掉此节点，以免影响业务，等此节点恢复后再继续提供服务，从屏蔽偶发异常导致的险。据统计数据显示，有将近 90%的线上故障是由于发版过程中出现的，剩下的 10% 左右的线上Microservices Governance Technology6问题，可能是由于些偶然的原因导致的。如偶然的络故障、机器 I/O 出现问题、或者是某台机器负载过等。在解决了发布时候的稳定性问题和偶发异常导致的险后，基本能够确保线上业务不会出现灾难性的问题。在业务快速发展的死存亡期，您需要借助于这些微服务治理能，才能确保业务能够快稳地增，度过这段死存亡期，成为这个领域的重要玩家。业务成熟期当业务进成熟期之后，业务的开发进了新的阶段，这时候，虽然快速发展过程中的问题仍旧存在，但是会因为业务量上来之后，遇到新的问题。低成本创新：虽然发展不像原来那么迅速，但是业务创新探索的诉求仍旧存在，由于业务规模的扩，创新的成本也在增加。这个时候不仅是需要快速开发迭代，更的需求是尽可能的成本进创新探索测试，有时候还需要使上 AB 测试的段进实验较。容灾多活：由于业务规模已经很了，治理中的稳定性的诉求更加强烈，且随着业务范围的扩，应也开始在多个地域、多个云产品中进部署。同城容灾、异地多活这类需求也开始出现。问题定位：出现任何问题都必须彻查。虽然出现问题时，业务恢复仍旧排查第位，但是业务恢复之后的问题根因定位也是不能少的，因为如果不彻查，难免后续出现同样的问题。险预案：紧急预案、险预防也变得常重要，需要提前做好业务的保护和降级的埋点演练，在遇到绝多数可预问题可以紧急修复，出现不可控问题时，可以通过预案段执预案，确保整体业务的可控性。从这个典型的案例中，我们可以看到，微服务的成功落地和业务的快速发展，离不开微服务治理的持。在业务发展的不同阶段，会遇到不同的微服务问题，需要借助于治理的能，为业务的快稳发展保驾护航。Microservices Governance Technology71.2 微服务治理在云原场景下的挑战企业上云的四个阶段随着云原时代的到来，越来越多的应在云上，在云上，且随着越来越多的企业开始上云，云原也是企业落地微服务的最佳伴侣。我们分析了阿云典型客户的实践经历，业务上云通常划分为 4 个阶段：云上部署、云原部署、微服务化、服务治理。Microservices Governance Technology云上部署这阶段我们解决的问题，如何把传统业务，原来是跑在建 IDC 机房的业务，能够原封不动的迁移到云上。通常云商提供了丰富的计算，存储，络等资源可供选择，以虚拟化技术，神裸属服务为代表的硬件可以满企业客户上云搬迁的丰富需求，这阶段关注的焦点是资源，对于业务并任何的改造，只需要从本地原样搬迁到云上即可。云原部署云原是释放云计算价值的最短路径，以容器技术为代表，云原提供了强的调度，弹性等能，极的降低了上云的成本。这阶段我们关注的标主要是业务进云原化改造，随着 Kubernetes 作为容器编排市场的事实标准，我们需要把业务从原来的的虚拟机部署式改造成容器化式，部署并运在 K8s 之上，最限度享受到云原带来的技术红利。这阶段核关注标以容器为核。8Microservices Governance Technology微服务化当我们的业务规模逐步扩，传统单体应很难进步撑业务的发展，业务的迭代速度已经法满业务的增，此时我们就需要进微服务化的改造，降低业务的耦合度，提升开发迭代的效率，让开发更加敏捷。这阶段我们聚焦以应为核。服务治理当微服务的规模也越来越的时候，如果对微服务不加以规范和整治，很容易出现问题。例如，每个微服务都有独的团队来维护，他们之间如果依赖没有整理清楚，可能会出现架构上循环依赖等问题。从我们的数据观察来看，当微服务的节点数超过数个的情况下，我们通常就需要引服务治理，通常需要关注的是开发，测试，线上运维，安全等多考虑，这阶段我们聚焦以业务为核，核标是进步提开发效率，提线上业务的稳定性。微服务治理在云原下的挑战随着企业微服务化进程的逐渐深，微服务的云原化逐步进深区，在这个微服务深化的过程中，我们逐步会临系列的挑战，总的，我们将这些挑战分为三个的层，他们分别是效率，稳定和成本。我们进微服务化，本身的使命是让业务的迭代更加效，但当我们的微服务数量逐步增多，链路越来越，如果不进进步的治理，那么引发的效率问题可能会于微服务架构本身带来的架构红利。在上章节中我们提到过在微服务实施的不同阶段，遇到的问题也不尽相同。前阿巴巴内部的微服务节点数量是在百万级别，在这个过程我们也积累的常多的治理经验。9在效率上临的挑战在效率需要追求的标是，在开发，线上运维，SDK 升级等更加效。 在开发阶段，我们需要考虑的是，业务应上云之后，如何让本地开发的应，很好的部署云上的业务进联调？通常我们的微服务不可能在本地完整的部署整套系统，所以本地开发的应只是整个微服务链路的部分，这包括我们的流量需要能够轻松的从云上，引导到本地，便于我们做开发调试，或者我们在本地能够很便的调云上部署的微服务进联调。这在微服务上云之后，变的原来在身机房进开发联调更加困难。 在线上运维，我们通常需要频繁的对微服务进变更，这些变更通常就会引发系列的问题，例如在天峰期做发布，通常都会导致业务流量出现损失，我们的研发员不得不选择在晚上业务低峰期做变更，这降低了研发员的幸福指数，因为他们不得不临熬夜加班的困境。如果能在天流量峰期也能进流量损的变更，那么这对于研发员来说将是提升研发效率的事情。 微服务框架通常会引服务治理的逻辑，这些逻辑通常会以 SDK 的式被业务代码所依赖，这些逻辑的变更和升级，都需要每个微服务业务通过修改代码的式来实现，这样的变更造成了常的升级成本。以阿巴巴为例，阿内部个中间件 SDK 的升级，如果要在整个集团铺开，通常需要消耗的时间以年为单位进统计，这也会消耗每个微服务应的研发，测试等庞的资源，效率常低下，如果能够以侵的式实现中间件 SDK的升级，那么将会是件常效的事情。Microservices Governance Technology 进云原体系之后，以 K8s 为主的云原体系强调集群之间的灵活调度型，以 POD 为单位任意的调度资源，在被调度后 POD 的 IP 也将相应的发变化，传统的服务治理体系，10通常以 IP 为维度进治理策略的配置，例如名单策略等，但是当进云原场景后，这些传统的治理策略都会临失效的问题，因为 POD 旦被重新调度，原来的治理策略都将不再使，如何能让服务治理体系更加适应云原体系，也是我们要临的挑战。Microservices Governance Technology在稳定上临的挑战稳定于切，在微服务上云之后，业务可是我们必须要解决的问题，因此通常会在同个地域的多个可区内进部署，在多可区部署的情况下，跨可区的延时就是不可忽视的问题，我们需要思考的是业务流量需要能够尽量在同个可区内进流转，同时也需要考虑的是如果个可区出现问题，业务流量能够尽可能快的流转到正常的可区，这就对我们的微服务框架的路由能提出了挑战。当然，我们的业务不仅需要在同个地域保证可，也需要考虑个地域出问题的时候，保证业务的可，这时我们就需要考虑业务实现同城双活，甚是异地多活，这对我们来说也是挑战。第三，微服务之间的调也需要更加的安全可信，近期层出不穷的安全漏洞，定程度上也反应出当前上云阶段在安全便暴露出的问题还是常多，每次安全漏洞出现之后，中间件 SDK的升级也是困扰业务多年的问题；同时，些敏感的数据，即使在数据库层做了常多的权限管控，由于微服务被授予了数据访问的较权限，如果微服务的调被恶意攻击，也可能会造成敏感数据的泄露。微服务之间的调需要更加可靠可信。在成本上临的挑战先，在成本，业务上云遇到的最大问题就是如何最低成本的把业务迁移上云，对于个在线业务，如果要进停机迁移，那么迁移的成本会显得常，对于客户的体验也会收到影响，要在不中断业务的情况下，实现平滑迁移上云，还是有常的挑战的。其次，当我们在业务临极速增的流量时，迫切的需要快速的弹性，补充更多的资源以承载业务的峰，当我们进业务低峰的时候，希望能够缩容量，节省资源，因此云产品提供的快速灵活的弹性机制，是微服务上云之后项急需的能。11HSF 在阿巴巴使更多，承接了内部从单体应到微服务的架构演进，撑了阿历年双的平稳运； 2008 年 5 发布第个版本 1.1 后，经历数年迭代，HSF 从个基础的RPC 框架逐渐演变成为撑万亿级别调的易于扩展的微服务框架。内部场景中，户既可以选择少量配置轻松接微服务体系，获取性能的稳定服务调。也可以按照身业务需求对 HSF 进扩展，获取整条链路的能增强。Microservices Governance Technology1.3 微服务治理的发展趋势背景云原时代下，我们看到云原微服务作为核的技术直保持着 20%左右的速增，微服务技术也渗透到各各业。在云原微服务技术逐渐趋于成熟的今天，我们以阿集团微服务发展与阿云微服务产品发展的历史为镜再次展望微服务发展的趋势。阿集团微服务发展历史服务框架就像铁路的铁轨样，是互通的基础，只有解决了服务框架的互通，才有可能完成更层的业务互通，所以相同的标准统，合为并共建新代的服务框架是必然趋势。Dubbo3 是 Dubbo2 与 HSF 融合来，是阿里巴巴集团向内部业务、商业化、开源的唯标准服务框架。Dubbo 和 HSF 在阿集团的实践Dubbo 则在 2011 年开源后，迅速成为业界受欢迎的微服务框架产品，在国内外均有着泛应。Dubbo 项诞于 2008 年，起初只在个阿内部的系统使；2011 年，阿B2B 决定将整个项开源，仅了年时间就收获了来不同业的批户；2014 年，由于内部团队调整，Dubbo 暂停更新；2017 年 9 ，Dubbo 重启开源，在 2019 年 5 由Apache 孵化毕业，成为第个由阿巴巴捐献 Apache 毕业的项。12HSF 统天下对于集团内的需求，稳定和性能是核，因此，当时选型了在电商这种并发场景久经考验的 HSF 做为新代服务框架核。随后，HSF 推出了 2.0 的版本，并针对 HSF 之前版本的主要问题进重构改造，降低了维护成本，进步提了稳定性和性能。HSF2.0 解决了通讯协议持不透明，序列化协议持不透明等框架扩展性问题。基于 HSF2.0 的 Java 版本，集团内也演进出了 CPP/NodeJs/PHP 等多语的客户端。由于 HSF 还兼容了 Dubbo 的协议，原有的 Dubbo 户可以平滑地迁移到新版本上，所以 HSF 推出后很快就在集团全铺开，部署的 server 数量达到数万，基本完成了阿巴巴内部微服务框架的统，并经历了多年双零点流量洪峰的验证。Pandora 与 HSF 搭档HSF 的顺利落地离不开其丰富的周边态，服务注册中、配置中、限流降级、流量调度、功能开关、分布式事务、预案平台这些都是 HSF 的好伙伴，除了起完成基本的微服务调功能之外，也在多次的双中进保驾护航。这么多的组件，他们的 SDK 之间的升级和依赖管理是个很难规避的问题。如果没有进很好的管理，就可能出现两种组件之间的三依赖互相冲突的情况。也有可能出现某些组件需要特定的版本组合才能正确使，这些对于开发者来说，分辨起来是个不的成本。如果某个版本的组件出现危 bug，需要推动全量升级，这些开发、构建、发布的成本，更是难以预估。为了解决这些问题，Pandora 孕育。Pandora 是个轻量级的隔离容器，它来隔离Webapp 和中间件的依赖，也来隔离中间件之间的依赖。Pandora 会在运时通过类隔离的式，将各个中间件之间的三依赖隔离开来，有效地避免了三依赖互相冲突的情况。同时，Pandora 还会在运时导出中间件的类，来替换 SDK 中所引的中间件类，这样就可以实现运时的中间件版本和开发时的中间件版本分离。应升级 SDK 只需升级 Pandora 容器即可，只有在版本升级时才需要修改 BOM 和重新打包。三位体战略下服务框架与服务治理的最终选择 Dubbo3随着业务的发展，阿集团也因为同时存在 HSF 与 Dubbo 框架导致的不少问题。原有部或公司的技术栈如何更快地融到现有技术体系是个绕不开的问题。Microservices Governance Technology13个典型的例就是 2019 年加阿巴巴的考拉。考拉之前直使 Dubbo 作为微服务框架，基于 Dubbo 构建了规模的微服务应，迁移的成本，险也。需要集团和考拉的基础架构部耗费较的时间进迁移前调研、案设计，确保基本可后再开始改动。从分批灰度上线，再到最终全量上线。这种换式的改动不仅需要耗费量，时间跨度也很，会影响到业务的发展和稳定性。同时由于历史原因，集团内部始终存在着定数量的 Dubbo 户。为了更好的服务这部分户，HSF 框架对 Dubbo 进了协议层和 API 层的兼容。但这种兼容仅限于互通，随着Dubbo 开源社区的多年发展，这种基础的兼容在容灾、性能和可迭代性，都有着较的劣势，同时很难对 Dubbo 的服务治理体系。在稳定性也存在险，更法享受到集团技术发展和 Dubbo 社区演进的技术红利。随着云计算的不断发展和云原理念的泛传播，下代微服务也带来了其他的挑战和机遇，微服务的发展有着以下趋势：1.K8s 成为资源调度的事实标准，Service Mesh 从提出到发展今已经逐渐被越来越多户所接受。屏蔽底层基础设施成为软件架构的个核演进标，论是阿巴巴还是其他企业户，所临的问题都已经从是否上云变为如何平滑稳定地低成本迁移上云。2.由于上云路径的多样以及由现有架构迁移云原架构的过渡态存在，部署应的设施灵活异变，云上的微服务也呈现出多元化的趋势。跨语、跨商、跨环境的调必然会催基于开放标准的统协议和框架，以满互通需求。3.端上对后台服务的访问呈爆炸性的趋势增，应的规模和整个微服务体系的规模都随之增。这些趋势也给 HSF 和 Dubbo 带来了新的挑战。产这些问题的根本原因是闭源的 HSF 法直接于云上户和外部其他户，开源产品对闭源产品的挑战会随着开源和云的不断发展愈演愈烈。越早解决这个问题，阿巴巴和外部企业户的云原迁移成本越低，产的价值也就越。因此，HSF 和 Dubbo 的融合是势所趋。为了能更好的服务内外户，也为了两个框架更好发展，Dubbo3 和以 Dubbo3 为内核适配集团内基础架构态的 HSF3 应运。Microservices Governance Technology14阿云微服务产品发展历史我们站在现在开始回顾的时候，惊奇地发现阿云微服务产品的发展历程跟阿集团微服务发展的历史也是常的相似，或许跟我们最开始创新的源泉来于阿集团的实践是分不开的。HSF+Pandora 时代阿云上最早输出微服务治理的产品是 EDAS，定位于分布式应服务站式解决案，最初主推的微服务案是 HSF + Pandora 的式，直接将阿内部已经经过双验证的性能框架在云上输出，同时还输出了 HSF 周边的态组件，如注册中、配置管理、链路跟踪、限流降级等，在经推出之后，常受正在数字化转型的企业欢迎，服务了常多的政府服务、事业单位、银客户以及新零售转型的头部企业，也取得了不错的成绩。随着业务的深，我们的客户除了头部政企、数字化转型的团队，也越来越多的互联客户开始使我们的产品。微服务框架是基础组件，部分公司在早期选型或业务发展到定规模的时候都需要确定使某个框架。个稳定效的研框架通常需要较时间的迭代来打磨优化。所以部分公司初期都会倾向于使开源组件。对当时阿云微服务产品，这就带来了个问题：内部使的是 HSF 框架，云上的户部分都是使的开源 Dubbo 框架，两种框架在协议、内部模块抽象、编程接和功能持上都存在差异。客户在上云的时候，不得不对的业务代码进改造，开发和迁移成本常。另外，由于代码不开源，对于许多户，整个服务框架对于他们来说是个盒的组件，排查问题是个常头疼的问题，户会担稳定性得不到保证，也担被云商技术绑定。我们发现这并不是个很好的产品化向，调研之后发现客户多数的微服务框架都会选择开源的 Dubbo/Spring Cloud，于是阿云也选择了拥抱开源的式，主推 Dubbo 与 SpringCloud 框架。拥抱开源，侵持Dubbo与SpringCloud对于微服务框架来说，由于关联到客户的业务代码，要做商业化还是有常的挑战的。即使是已经在微服务治理能上持了开源的 Spring Cloud 和 Dubbo，但是户使起来却不是Microservices Governance Technology15那么容易。先，迁移成本上来说，希望把降低迁移成本为 0。个已经运起来的微服务业务，都会有建的注册中，如果要上云还需要把的注册中迁移到 MSE 注册中上。这个过程需要户对代码做改造才，般来说会采双注册的案，通过实现在两个注册中同时注册和订阅的案，来实现新应可以互相调，做到平滑迁移上云。但是我们发现推动客户做代码改造，包括 SDK 的升级是件常难的事情，很多客户的Dubbo 版本还停留在 4-5 年的版本，不仅需要研发、测试、运维都来关注，