简介： Dubbo 3.0 是在云原生背景下诞生的，使用 Dubbo 构建的微服务遵循云原生思想，能更好的复用底层云原生基础设施、贴合云原生微服务架构。

Dubbo3.0 介绍

作者 | 十眠

自从 Apache Dubbo 在 2011 年开源以来，经过多年一众大规模互联网、IT 公司的实践积累了大量经验，Dubbo 凭着对 Java 用户友好、功能丰富、治理能力强等优点在过去取得了很大的认可，成为国内外流行主流的 RPC 框架之一。

但随着云原生时代的到来，对以 Apache Dubbo、Spring Cloud 等为代表的 Java 微服务治理体系提出了新的要求，包括期望应用可以更快的启动、应用通信的协议穿透性可以更高、能够对多语言的支持更加友好等。比如 Spring 在今年也推出了其基于 GraalVM 的 Spring Native Beta 解决方案，拥有毫秒级启动的能力、更高的处理性能等。

这样的背景对下一代 Apache Dubbo 提出了两大要求：

1、要保留已有开箱即用和落地实践背景下带来的好处，这也是众多开发者所期望的；

2、尽可能地遵循云原生思想，能更好的复用底层云原生基础设施、贴合云原生微服务架构。

Dubbo 3.0 是在云原生背景下诞生的，使用 Dubbo 构建的微服务遵循云原生思想，能更好的复用底层云原生基础设施、贴合云原生微服务架构。这体现在：

服务支持部署在容器、Kubernetes 平台，服务生命周期可实现与平台调度周期对齐；
支持经典 Service Mesh 微服务架构，引入了 Proxyless Mesh 架构，进一步简化 Mesh 的落地与迁移成本，提供更灵活的选择；
作为桥接层，支持与 SpringCloud、gRPC 等异构微服务体系的互调互通。

在云原生大背景下，Apache Dubbo 3.0 选择全面拥抱云原生，对 Dubbo 架构升级，提出了全新的服务发现模型、下一代 RPC 协议和云原生基础设施适配等。

Dubbo3.0 商业版

下面我先介绍阿里云上微服务治理相关的三款云产品：EDAS、MSE、SAE。

EDAS

阿里云 aPaaS 产品，一站式部署发布平台，同时它是一艘航母，具备微服务治理、监控、压测、限流降级等一系列能力，同时它也是一个 AIOps 平台。

EDAS 3.0 作为分布式架构、数字化转型上云的首选在线业务应用托管平台，在微服务治理、应用发布变更以及智能运维等多个维度为用户应用提供智能化、自动化的解决方案。

"在 PaaS 层面，我们始终拥抱开源技术，并保持和社区版本兼容的时效性；在企业特性上，例如服务治理、应用监控等方面，我们提供一个稳定成熟的产品，来降低企业构建互联网化应用的门槛，例如企业级应用服务 EDAS 3.0 就是这样一个典型的产品"。

——阿里巴巴合伙人、阿里云智能基础产品事业部高级研究员蒋江伟

MSE

微服务引擎（Micro Service Engine，简称 MSE）是一个面向业界主流开源微服务生态的一站式微服务平台，帮助微服务用户更稳定、更便捷、更低成本的使用开源微服务技术构建微服务体系。提供注册中心、配置中心全托管（兼容 Nacos/ZooKeeper/Eureka）、网关（兼容 Zuul/Kong/Spring Cloud Gateway）和无侵入的开源增强服务治理能力。

SAE

Serverless 应用引擎（简称 SAE）是首款面向应用的 Serverless PaaS，提供成本更优、效率更高的一站式应用托管方案。支持 Spring Cloud/Dubbo/HSF 应用零改造上云，提供监控诊断、自动构建镜像、Java 全链路加速、多发布策略、秒级自动弹性等能力，支持 Jenkins/云效/插件等部署应用，还能通过 Docker 镜像部署任何语言的应用。

以上三款云产品所有的服务治理能力开箱即用，支持近五年来市面上所有开源 Dubbo、Spring Cloud 框架，包括 Dubbo 3.0；以下的所有能力无需修改一行代码与配置，您只需将您的 Dubbo 3.0 的应用接入 EDAS/MSE/SAE ，都是开箱即用的能力。

1、完整的服务契约详情

在治理的过程中，服务契约是所有功能的原材料。在进行测试验证其可用性的时候，需要知道服务提供的方法，并根据方法参数自动填充模板，进而进行测试；在配置流量规则时候，需要能知道方法的参数，从而根据流量特征来进行流量规则配置；在进行服务降级、服务鉴权等配置的时候，需要根据方法的具体名称和参数类型，来给不同的方法在不同的参数或者返回值的时候进行不同的降级/鉴权策略。

开源的 Swagger 已经做得比较不错了，但是 MSE 的服务契约更加简单高效。开源的 Swagger 只需要引入依赖，并在编码的时候配置好 @API 注解，然后启动一个 Swagger 的 Server 端就能看到详情，美中不足的是没有适配 Dubbo。

考虑到要让用户不修改任何代码配置就能使用，且老旧版本的应用代码和镜像也得支持。因为如果需要开发的话，会因为侵入性比较大会影响迭代效率，我们还是选择了 Agent 方案，这样可以做到无需修改任何代码和配置，只需要将应用接入 One Agent，就可以在 MSE 控制台看到微服务的详情。

当然，如果应用本身已经接入了 Swagger，我们也能够做到很好的兼容支持。最后我们可以简单地看一下服务契约的效果，已经同时支持了 Spring Cloud 和 Dubbo 应用。

可以详细的查看应用注册了哪些服务，以及这些服务的消费者有哪些；
可以详细地查看应用提供的所有微服务方法；
可以详细地查看应用提供的所有方法的返回值、参数的详情；
服务测试、服务降级、服务鉴权这些功能，能够直接获取服务契约的数据以便后续的治理规则配置。

2、全链路流量控制

在微服务场景下，想让流量精确命中到整个链路上的某一个应用的灰度版本，想要控制流量在整条链路上完整且精确地按照预期流转，目前开源并没有提供这样的能力。但是我们常会碰到以下的场景，导致我们不得不去面对全链路流量控制的这个诉求。

如何做到项目/测试环境隔离？

我们首先通过新建项目环境，给每个项目环境都有唯一的一个项目标签。当流量带上这个项目标签后会路由到该项目环境，否则会去主干环境。项目环境隔离带来的好处是每个开发人员都可以有自己的项目环境，防止开发者们开发过程中的互相影响。

如何实现全链路灰度？

我们首先划分出灰度的机器，然后对线上所有应用部署灰度版本，灰度流量全部进入灰度版本，正常流量进入生产版本。灰度版本只针对灰度流量验证，有效减少风险。当我们要灰度发布 N 个应用，需要做到灰度流量在这 N 个应用的灰度版本之间路由。

下面这张图很好地说明使用流量控制让我们的开发同学在开发环境 1 和开发环境 2 各自部署各自的应用，可以实现环境隔离与全链路灰度的能力。

但是如果没有全链路流量控制的这套机制，各种开发/灰度/生产环境都要进行逻辑或者物理隔离，这就需要部署N套整套的微服务架构，成本非常高。

可以看到上图的基于全链路流量控制的方案才是更加合理的部署方案设计，我们提供了开箱即用全链路流量控制的能力，下面以电商架构中的下单场景为例介绍全链路流控功能。

客户下单后流量从入口应用（或者微服务网关）进来，调用交易中心，交易中心再调用商品中心，商品中心调用下游的库存中心。交易中心和商品中心各有两个新版本（1和2）在运行，需要对这两个新版本进行灰度验证。此时在入口应用（或者微服务网关）上期望将满足特定流控规则的请求流量路由到新版本，其余流量全部路由到线上（正式）版本。

我们只需在 EDAS 控制台创建如下全链路流量控制规则：

同时我们还提供了流量控制的监控大盘，可以实时查看各个应用的 qps 指标，来确认流量走向是否符合预期。

3、标签路由

EDAS/MSE 服务治理提供了标签路由的流量控制能力。每个 pod/ecs 都可以打上标签，标签被识别后会在控制台上展示，然后我们可以对标签设置比例和内容规则。

可以设置各个标签的流量比例：

8.5.png

也可以点击流量规则设置各个标签的内容流量规则：

如果有全链路诉求。上述 "是否透传" 开关可以用来透传标签。

4、开箱即用的服务测试

服务测试即为用户提供一个云上私网 Postman ，让用户能够轻松调用自己的服务。用户无需感知云上复杂的网络拓扑结构，无需关系服务的协议，无需自建测试工具，只需要通过控制台即可实现服务调用。支持 Dubbo 3.0 框架，以及 Dubbo 3.0 主流的 Triple 协议。

5、离群实例摘除

在微服务架构中，当服务提供者的应用实例出现异常时，服务消费者无法及时感知，会影响服务的正常调用，进而影响消费者的服务性能甚至可用性。

在上图的示例场景中，系统包含 4 个应用，A、B、C 和 D，其中应用 A 会分别调用应用 B、C 和 D。当应用 B、C 或 D 的某些实例异常时（如图中应用 B、C 和 D 标识的各有 1个和 2 个异常实例），如果应用 A 无法感知，会导致部分调用失败；如果业务代码写的不够优雅，有可能影响应用 A 的性能甚至整个系统的可用性。

在这里，主要介绍一下离群实例摘除。那什么是离群实例，在微服务集群中出现间歇性的单机抖动（ load 极高、 CPU 短时无法响应、线程池满等），由于这些个别节点的抖动会导致整体集群的服务质量下降。这种情况在云上时常出现，特别是对于一些大客户来说，这种能力极为重要。为了提高业务的稳定性，我们需要一种自动化的方案当出现离群实例时，可以自动将其摘除，同时当其恢复健康后，又需要将其放回集群继续提供服务。

一句话总结：提供了业务单点异常自愈能力。

我们只需要选择框架类型与应用，然后配置允许的错误率下限即可。

6、服务鉴权

相比于开源的 Dubbo 3.0，MSE 提供了开箱即用的服务鉴权能力，保护你的敏感业务，可以做到精准地控制服务调用的权限。

当我们的业务发展后，我们的服务还会遇到权限控制的需求：比如优惠券部门的某个应用，同时包含了优惠券查询接口和优惠券发放接口，对于优惠券查询接口来说，默认公司内部的所有应用都有权限调用的；但优惠券发放接口只有客服和运营部门的某些应用才有权限调用。

如下图所示，MSE 用户可以对自己的服务进行权限管理，这里以 Dubbo 为例，下图中配置表明，应用 cartservice 发布的 com.alibabacloud.hipstershop.CartService 服务的 addItemToCart 的方法，只允许 frontend 这个应用调用。

精准的权限管理，可以让你更好地管理微服务调用的权限，保证业务的合规性，保障数据的安全。

7、服务 Mock

相比于开源 Dubbo 3.0 服务 Mock 能力，MSE 提供的是开箱即用的完整解决方案。

当您遇到业务高峰期，发现下游的服务提供者遇到性能瓶颈，甚至影响业务时。您可以通过服务 Mock 实现服务降级，对部分的服务消费者进行降级操作，让不重要的业务方不进行真实地调用，直接返回 Mock 的结果，将宝贵的下游服务提供者资源保留给重要的业务调用方使用，从而提升整体服务的稳定性。

开源已有的 Sentinel、Hystrix 等开源的熔断降级，主要是对不稳定的弱依赖服务调用进行熔断降级，暂时切断不稳定调用，避免局部不稳定因素导致整体的雪崩。熔断降级作为保护自身的手段，通常在服务消费端进行配置。

服务降级功能既支持在服务调用报错时候进行降级，同时也支持在服务调用正常时也开启，这样可以很好地保护服务提供者，将有限的资源更多地分配给关键的服务消费者。

在开发的过程中，相信我们大家都到过，下游依赖方开发进度比较慢，导致自己的开发进度被 block 的情况，在使用微服务治理 Mock 功能之后，可以通过固定地 Mock 某个返回值，从而使得开发的过程不需要依赖于下游依赖方的进度，同时还可以灵活地在控制台变更 Mock 的规则，从而达到快速开发的目的。

如下图所示，当应用接入 MSE 之后，就可以在控制台中通过如下方式来提供服务 Mock 的功能。

8、服务监控

对于Dubbo应用线上监控以及诊断能力是必不可少的能力，我们提供了以下完整且开箱即用的应用监控能力，可以让应用的运维变得轻松高效。

应用详情

应用依赖服务以及应用实例/状态码统计

应用的系统信息与慢调用次数监控

应用数据的统计分析

应用的调用拓扑分析

小结

EDAS/MSE/SAE 服务治理中心是商业化版的 Dubbo Admin，但不止于此，我们通过无侵入方式增强市面上 Dubbo/Spring Cloud 等框架的全部版本，提供了一站式完整的微服务治理能力的解决方案。

不只是 Dubbo3.0

同时，EDAS/MSE/SAE 服务治理也将 Dubbo 3.0 一些优秀的设计以及能力通过无侵入服务治理能力普惠到 Dubbo 2.x 以及 Spring Cloud 框架。

1、微服务与K8s生命周期对齐

如果微服务没有实现其接口，当部署架构 K8s 化，在应用的缩容、扩容、重启、新版本发布这些过程中，会出现影响业务的错误，所以要配置好微服务在 K8s 环境下的健康检查。

其实仅仅是做健康检查其实不够：因为出现上述场景的原因可能有很多：

1、应用的下线过程中：应用提供者正常收到 kill 信号，提供者处理完在途请求再停止，注册中心感知提供者下线，消费者收到下线通知，消费者刷新调用列表等等这些过程中，都可能出现错误和延迟。

2、应用上线过程中也可能出问题：服务还未注册订阅完成Pod的健康检查已经就绪，Dubbo 还没准备好大流量就进来了，数据库/Redis 建立连接导致初次请求失败，JVM 类加载出现锁导致启动缓慢，健康检查写的有问题导致滚动发布过程中没有一个健康的节点等等。

上述的阶段，都有可能出现问题，这些问题都是需要解决和保证的。这个可以通过开源的方式一个个去解决，比如调整注册中心的配置，调整连接池的配置，调整镜像打包文件，自己写代码实现在途请求处理完的逻辑等等。也可以选择使用 MSE 方案，不需要修改代码，只需要接入 MSE 即可，只需要接入一次，接入过程在 5 分钟之内。

Readiness 检查

MSE 会提供一个 Readiness 接口，该接口会在微服务启动完全就绪后，返回的 status 会成为 200，否则返回 503。

Liveness 检查

MSE 会提供一个 Liveness 接口，该接口在判断微服务就绪后且服务状态为健康，返回的 status 会成为 200，否则返回 503 。

我们只需将相关配置配置在K8s提供的接口上即可。

2、无损上下线

若您的应用没有具备无损下线的能力，您的任何应用在发布的过程中会造成短暂的服务不可用，短时间内业务监控会出现大量 io 异常报错。如果您的业务没做好事务，那么还会引起数据不一致的问题，您需要紧急手动订正错误数据。每次发布，您需要发告示停机发布，否则您的用户会出现一段时间服务不可用，会对用户产品体验造成影响。

对于任何一个线上应用，如何在服务更新部署过程中保证业务无感知是开发者必须要解决的问题，即从应用停止到重启恢复服务这个阶段不能影响正常的业务请求，目前开源的框架均不能很好地解决这个问题。

当您的应用接入MSE/EDAS/SAE 后，将通过无侵入的方式自动增强 Dubbo 和 Spring Cloud 流量的无损下线能力。微服务治理中心将无损下线的能力整合在 K8S 的生命周期中，对 ACK 集群中的应用进行部署、回滚、缩容等操作时，会自动实现无损下线的效果。