背景

云原生时代下，我们看到云原生微服务作为核心的技术一直保持着 20%左右的高速增长，微服务技术也渗透到各行各业。在云原生微服务技术逐渐趋于成熟的今天，我们以阿里集团微服务发展与阿里云微服务产品发展的历史为镜子再一次展望微服务发展的趋势。

阿里集团微服务发展历史

服务框架就像铁路的铁轨一样，是互通的基础，只有解决了服务框架的互通，才有可能完成更高层的业务互通，所以用相同的标准统一，合二为一并共建新一代的服务框架是必然趋势。

Dubbo3 是Dubbo2 与 HSF 融合而来，是阿里经济体面向内部业务、商业化、开源的唯一标准服务框架。

Dubbo 和 HSF 在阿里集团的实践

Dubbo 则在 2011 年开源后，迅速成为业界广受欢迎的微服务框架产品，在国内外均有着广泛应用。Dubbo 项目诞生于 2008 年，起初只在一个阿里内部的系统使用；2011 年，阿里 B2B 决定将整个项目开源，仅用了一年时间就收获了来自不同行业的大批用户；2014 年，由于内部团队调整，Dubbo 暂停更新；2017 年 9 月，Dubbo 3 重启开源，在 2019 年 5 月由 Apache 孵化毕业，成为第二个由阿里巴巴捐献至 Apache 毕业的项目。

HSF 在阿里巴巴使用更多，承接了内部从单体应用到微服务的架构演进，支撑了阿里历年双十一的平稳运行；自 2008 年 5 月发布第一个版本 1.1 后，经历数年迭代，HSF 从一个基础的 RPC 框架逐渐演变成为日支撑十万亿级别调用的易于扩展的微服务框架。内部场景中，用户既可以选择少量配置轻松接入微服务体系，获取高性能的稳定服务调用。也可以按照自身业务需求，对 HSF 进行扩展，获取整条链路的能力增强。

HSF 一统天下

对于集团内的需求而言，稳定和性能是核心，因此，当时选型了在电商这种高并发场景久经考验的 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框架而导致的不少问题。原有部门或公司的技术栈如何更快地融入到现有技术体系是一个绕不开的问题。
一个典型的例子就是 2019 年加入阿里巴巴的考拉。考拉之前一直使用 Dubbo 作为微服务框架，基于 Dubbo 构建了大规模的微服务应用，迁移的成本高，风险也大。需要集团和考拉的基础架构部门耗费较长的时间进行迁移前调研、方案设计，确保基本可行后再开始改动。从分批灰度上线，再到最终全量上线。这种换血式的改动不仅需要耗费大量人力，时间跨度也很长，会影响到业务的发展和稳定性。
同时由于历史原因，集团内部始终存在着一定数量的 Dubbo 用户。为了更好的服务这部分用户，HSF 框架对 Dubbo 进行了协议层和 API 层的兼容。但这种兼容仅限于互通，随着 Dubbo 开源社区的多年发展，这种基础的兼容在容灾、性能和可迭代性方面，都有着较大的劣势，同时很难对齐 Dubbo 的服务治理体系。在稳定性方面也存在风险，更无法享受到集团技术发展和 Dubbo 社区演进的技术红利。

随着云计算的不断发展和云原生理念的广泛传播，下一代微服务也带来了其他的挑战和机遇，微服务的发展有着以下趋势：

1. K8s 成为资源调度的事实标准，Service Mesh 从提出到发展至今已经逐渐被越来越多用户所接受。屏蔽底层基础设施成为软件架构的一个核心演进目标，无论是阿里巴巴还是其他企业用户，所面临的问题都已经从是否上云变为如何平滑稳定地低成本迁移上云。
2. 由于上云路径的多样以及由现有架构迁移至云原生架构的过渡态存在，部署应用的设施灵活异变，云上的微服务也呈现出多元化的趋势。跨语言、跨厂商、跨环境的调用必然会催生基于开放标准的统一协议和框架，以满足互通需求。
3. 端上对后台服务的访问呈爆炸性的趋势增长，应用的规模和整个微服务体系的规模都随之增长。

这些趋势也给 HSF 和 Dubbo 带来了新的挑战。产生这些问题的根本原因是闭源的 HSF 无法直接用于广大云上用户和外部其他用户，而开源产品对闭源产品的挑战会随着开源和云的不断发展愈演愈烈。越早解决这个问题，阿里巴巴和外部企业用户的云原生迁移成本越低，产生的价值也就越大。
因此，HSF 和 Dubbo 的融合是大势所趋。为了能更好的服务内外用户，也为了两个框架更好发展，Dubbo3 和以 Dubbo3 为内核适配集团内基础架构生态的 HSF3 应运而生。

阿里云微服务产品发展历史

我们站在现在开始回顾的时候，惊奇地发现阿里云微服务产品的发展历程跟阿里集团微服务发展的历史也是非常的相似，或许跟我们最开始创新的源泉来自于阿里集团的实践是分不开的。

HSF + Pandora 时代

阿里云上最早输出微服务治理的产品是 EDAS，定位于分布式应用服务一站式解决方案，最初主推的微服务方案是 HSF + Pandora 的方式，直接将阿里内部已经经过双十一验证的高性能框架在云上输出，同时还输出了 HSF 周边的生态组件，如注册中心、配置管理、链路跟踪、限流降级 等，在一经推出之后，非常受正在数字化转型的企业欢迎，服务了非常多的政府服务、事业单位、银行客户 以及新零售转型的头部企业，也取得了不错的成绩。
随着业务的深入，我们的客户除了头部政企、数字化转型的团队，也越来越多的互联网客户开始使用我们的产品。微服务框架是基础组件，大部分公司在早期选型或业务发展到一定规模的时候都需要确定使用某一个框架。而一个稳定高效的自研框架通常需要较长时间的迭代来打磨优化。所以大部分公司初期都会倾向于使用开源组件。
对当时阿里云微服务产品而言，这就带来了一个问题：内部使用的是 HSF 框架，而云上的用户大部分都是使用的开源 Dubbo 框架，两种框架在协议、内部模块抽象、编程接口和功能支持上都存在差异。客户在上云的时候，不得不对自己的业务代码进行改造，开发和迁移成本非常大。另外，由于代码不开源，对于许多用户而言，整个服务框架对于他们来说是一个黑盒的组件，排查问题是一个非常头疼的问题，用户会担心稳定性得不到保证，也担心被云厂商技术绑定。
我们发现这并不是一个很好的产品化方向，调研之后发现客户大多数的微服务框架都会选择开源的 Dubbo/Spring Cloud，于是阿里云也选择了拥抱开源的方式，主推Dubbo与Spring Cloud框架。

拥抱开源，无侵入支持Dubbo与Spring Cloud

对于微服务框架来说，由于关联到客户的业务代码，要做商业化还是有非常大的挑战的。即使是已经在微服务治理能力上支持了开源的 Spring Cloud 和 Dubbo，但是用户使用起来却不是那么容易。
首先，迁移成本上来说，希望把降低迁移成本为0。一个已经运行起来的微服务业务，都会有自建的注册中心，如果要上云还需要把自己的注册中心迁移到 MSE 注册中心上。这个过程需要用户对代码做改造才行，一般来说会采用双注册的方案，通过实现在两个注册中心同时注册和订阅的方案，来实现新老应用可以互相调用，做到平滑迁移上云。
但是我们发现推动客户做代码改造，包括 SDK 的升级是一件非常难的事情，很多客户的 Dubbo 版本还停留在 4-5 年的版本，不仅需要研发、测试、运维都来关注，还需要排期支持，这个动作会耗费大量的人力资源，同时面临许多稳定性的挑战，光是这一步就会阻挡住绝大多数的的客户。
为了解决客户 SDK 升级的问题，我们在想，能不能不要迁移注册中心呢，最好是代码一行也不用改，部署到云上来，就能完整地使用我们的微服务治理能力。在调研了多方技术实现后，我们开始基于 Java Agent 字节码增强的技术来开发微服务治理的能力，帮助用户不改一行代码使用云产品，真正做到了迁移和使用的成本为0。同时，由于不修改任何代码，客户也可以做到随时可上可下，没有绑定，比较放心的上云产品。

对于商业化中微服务框架的选择，我们选择的态度一直是拥抱开源。并在开源微服务框架的基础上提供差异化的服务治理能力，传统开源微服务框架在 k8s 上的问题在上云的过程中逐步暴露出来。通过一系列和客户的交流，我们总结出了客户的云原生下进行微服务治理的几大痛点，主要包括微服务发布过程中的无损上下线，标签路由，服务鉴权，离群实例摘除，全链路灰度等等，我们通过 Java Agent 技术实现了在用户不改代码的情况下，解决了上述问题，通过客户交流，收集需求，落到产品，给客户 demo 验证这个模式跑通了正向的循环，功能不断丰富中。除了Java Agent，对于多语言的场景我们使用Service Mesh、WASM等技术，同样支持客户无需修改一行代码，就具备于Java应用一致的服务治理能力与体验。

云原生下微服务治理发展趋势

随着云原生技术的不断发展，微服务治理也仍旧在快速的发展和变革中。

我们亲身经历了阿里集团的微服务的发展与选择，也参与了阿里云微服务产品的发展。我们观察到微服务技术的主要3个趋势：后端服务 BaaS 化；服务治理下沉，业务透明化；部署形态混合云化。

下面将分别分析这几个趋势

后端服务 BaaS 化

BaaS，即 Backend as a service的简称，微服务架构下，微服务应用通常会依赖多个后端服务，典型的如数据库，缓存，消息队列等等，过去我们搭建一个微服务体系通常使用开源软件自行搭建这些后端的依赖，但是维护这些后端组件需要大量的人力资源和成本，一旦出问题风险非常大。随着业务的云原生上云，我们发现越来越多的云产商通过云服务的形式，提供这些后端依赖的托管服务，免去了业务开发人工运维这些软件的烦恼。由此使得企业越来越聚焦在自己的业务应用上，而更少的去关注底层的中间件依赖。过去我们从 数据库开始，再到消息队列，缓存，几乎所有的云产商都提供了托管的服务供选择，然而随着微服务化进一步深入，我们认为微服务的注册中心，配置中心，微服务网关，服务治理中心，分布式事务等也逐步由云产商提供，通过标准服务的形式，企业上云之后可以灵活的选择，并且没有厂商的锁定。

服务治理下沉，业务透明化

随着 Service Mesh 技术概念的兴起，结合阿里巴巴内部架构演进的实践，我们发现，服务治理技术将逐步的和业务解耦，对业务更加的透明，无论是以 sidecar 为首的 service mesh，还是 Java Agent 为主的新兴治理技术，他们解决的核心问题，就是让业务摆脱对服务治理能力的依赖，让基础设施的迭代可以脱离业务发展独立进行。同时，微服务各个语言之间通常会有不同的框架，这些跨语言的微服务框架将形成统一的服务治理控制面，进一步降低客户选择的成本，一个基于开源微服务框架实现的微服务系统，将能够不改一行代码，能够部署到云上，享受云厂商提供的 BaaS 服务。

部署形态混合云化

第三个趋势是企业上云部署形态不再会选择单一云产商，无论是从避免厂商锁定，还是从稳定性来讲都会考虑跨多个云厂商提供服务，因此云产商提供的服务会趋向于标准化，否则企业很有可能选择开源自建来避免厂商的锁定；同时，企业上云也非一蹴而就，通常大量的业务仍部署在自建 IDC 的业务，新兴业务逐步上云。如何针对跨多云，跨自建机房和云上等多种部署形态，对业务进行统一的管理，也是摆在企业面前的难题。未来的云服务，应该是可以提供跨多个云统一纳管，并且一致体验的云服务。

总结

随着云计算的迅速发展，微服务将无处不在。云原生微服务治理的标准也在逐渐成型。相信在不远的将来，我们观察到的三个趋势：后端服务 BaaS 化；服务治理下沉，业务透明化；部署形态混合云化。会逐渐成为云原生下微服务治理的标准，也相信标准的形成会进一步助力云原生微服务治理的蓬勃发展，实现无数云上企业的业务永远在线。