在 Dubbo3.0 上服务治理的实践

做者 | 十眠

Dubbo3.0 介绍

​

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

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

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

一、要保留已有开箱即用和落地实践背景下带来的好处，这也是众多开发者所指望的；
二、尽量地遵循云原生思想，能更好的复用底层云原生基础设施、贴合云原生微服务架构。
​

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 就是这样一个典型的产品”。
​

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

了解更多详情：
https://www.aliyun.com/product/edas
​

• MSE

​

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

了解更多详情：
https://www.aliyun.com/product/aliware/mse
​

• SAE

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

了解更多详情：
https://www.aliyun.com/product/sae
​

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

一、完整的服务契约详情

​

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

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

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

​

固然，若是应用自己已经接入了 Swagger，咱们也可以作到很好的兼容支持。最后咱们能够简单地看一下服务契约的效果，已经同时支持了 Spring Cloud 和 Dubbo 应用。
​

• 能够详细的查看应用注册了哪些服务，以及这些服务的消费者有哪些；

​

• 能够详细地查看应用提供的全部微服务方法；

​

• 能够详细地查看应用提供的全部方法的返回值、参数的详情；

​

• 服务测试、服务降级、服务鉴权这些功能，可以直接获取服务契约的数据以便后续的治理规则配置。

​

二、全链路流量控制

 

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

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

 

咱们首先经过新建项目环境，给每一个项目环境都有惟一的一个项目标签。当流量带上这个项目标签后会路由到该项目环境，不然会去主干环境。项目环境隔离带来的好处是每一个开发人员均可以有本身的项目环境，防止开发者们开发过程当中的互相影响。
​
 

如何实现全链路灰度？

​

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

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

​

**可是若是没有全链路流量控制的这套机制，各类开发/灰度/生产环境都要进行逻辑或者物理隔离，这就须要部署N套整套的微服务架构，成本很是高。**​
​

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

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

咱们只需在 EDAS 控制台建立以下全链路流量控制规则：
​

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

三、标签路由

 

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

能够设置各个标签的流量比例：

​

也能够点击流量规则设置各个标签的内容流量规则：
​

若是有全链路诉求。上述 “是否透传” 开关能够用来透传标签。
​
 

四、开箱即用的服务测试

​

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

​

五、离群实例摘除

​

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

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

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

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

咱们只须要选择框架类型与应用，而后配置容许的错误率下限便可。

六、服务鉴权

 

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

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

以下图所示，MSE 用户能够对本身的服务进行权限管理，这里以 Dubbo 为例，下图中配置代表，应用 cartservice 发布的 com.alibabacloud.hipstershop.CartService 服务的 addItemToCart 的方法，只容许 frontend 这个应用调用。
​

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

七、服务 Mock

​

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

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

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

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

在开发的过程当中，相信咱们你们都到过，下游依赖方开发进度比较慢，致使本身的开发进度被 block 的状况，在使用 微服务治理 Mock 功能以后，能够经过固定地 Mock 某个返回值，从而使得开发的过程不须要依赖于下游依赖方的进度，同时还能够灵活地在控制台变动 Mock 的规则，从而达到快速开发的目的。
​

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

八、服务监控

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

• 应用详情
  ​

​

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

​

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

​

• 应用数据的统计分析
  ​

• 应用的调用拓扑分析

​

九、小结

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

不仅是 Dubbo3.0

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

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

​

Pod 的生命周期与服务调度息息相关。
（https://kubernetes.io/zh/docs/concepts/workloads/pods/pod-lifecycle/）
​

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

其实仅仅是作健康检查其实不够：由于出现上述场景的缘由可能有不少：
​

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

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

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

Readiness 检查

​

MSE 会提供一个 Readiness 接口，该接口会在微服务启动彻底就绪后，返回的 status 会成为 200，不然返回 503。

Liveness 检查

​

MSE 会提供一个 Liveness 接口，该接口在判断微服务就绪后且服务状态为健康，返回的 status 会成为 200，不然返回 503 。
咱们只需将相关配置配置在K8s提供的接口上便可。
​
 

二、无损上下线

​

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

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

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

三、服务并行注册订阅

​

Dubbo 默认服务注册/订阅行为是串行执行，当您的 Dubbo 应用中服务数过多，该流程会变得很长，影响应用启动时长，存在必定的稳定性风险；为了应用能够更快的启动，MSE 会经过无侵入的方式加强你的微服务框架，只需加一个开关，就能开启服务并行注册与订阅，大大减小应用启动时长。
​
 

总结

​

Apache Dubbo 3.0.0 是捐给 Apache 后的一个里程碑版本，表明着 Apache Dubbo 全面拥抱云原生的一个节点。
​

EDAS/MSE/SAE 服务治理能力也在随着云原生微服务的发展以及 Dubbo 的演进而不断丰富，随着客户大规模上云后，一些云原生场景下微服务的痛点也不断浮出水面，咱们致力于无侵入的微服务治理加强，在解决客户痛点的过程当中保证云上客户的业务永远在线，使得云原生微服务的架构升级更加 easy 。
​

​

﹀
﹀
﹀
​

8月5日下午 15:00-16:00
​

来直播间围观 《Dubbo 3.0 服务治理最佳实践》如何快速具有完整的服务治理能力

想探讨更多相关内容，欢迎钉钉搜索群号：34754806 ​