Dubbo 3.0 前瞻：重塑 Spring Cloud 服务治理

作者 | 小马哥

导读：Dubbo 社区策划了【Dubbo 云原生之路】系列文章，和大家一起回顾 Apache Dubbo 产品和社区的发展，并展望未来发展。系列文章主要涵盖 Dubbo 技术解读、社区运营、应用案例解析三大部分。本文为系列第 3 篇。

前言

在 Java 微服务生态中，Spring Cloud 成为了开发人员的首选技术栈，然而随着实践的深入和运用规模的扩大，大家逐渐意识到 Spring Cloud 的局限性。

在服务治理方面，相较于Dubbo 而言，Spring Cloud 并不成熟。遗憾的是，Dubbo 往往被部分开发者片面地视作服务治理的 RPC 框架，而非微服务基础设施。即使是那些有意将 Spring Cloud 迁移至 Dubbo 的小伙伴，当面对其中迁移和改造的成本时，难免望而却步。

庆幸的是，Dubbo 3.0 的到来将给这一局面带来重要变革，未来 Dubbo Spring Cloud 将无缝对接 Dubbo 3.0 ，作为Spring Cloud Alibaba 的最核心组件，完全地拥抱 Spring Cloud 技术栈，不但无缝地整合 Spring Cloud 注册中心，包括Nacos、Eureka、Zookeeper 以及Consul，而且完全地兼容Spring Cloud Open Feign以及 @LoadBalanced RestTemplate，本文将讨论 Dubbo Spring Cloud 对 Spring Cloud 技术栈所带来的革命性变化，由于 Spring Cloud 技术栈涵盖的特性众多，因此本文讨论的范围仅限于服务治理部分。

本文作为 Dubbo 3.0 的前瞻，将着重讲解当前版本的 Dubbo Spring Cloud 实现，Dubbo Spring Cloud 得以实现的一个重要基础即是我们前瞻之一提到的应用级服务发现。

应用级服务发现是 Dubbo 3.0 规划中的重要一环，是 Dubbo 与云原生基础设施打通、实现大规模微服务集群的基石。其实 Dubbo 社区早在 2.7.5 版本开始便探索了应用级服务发现，尝试去优化 Dubbo 的服务发现模型，因此 Dubbo Spring Cloud 是基于 Dubbo Spring Boot 2.7.x（从 2.7.0 开始，Dubbo Spring Boot 与 Dubbo 在版本上保持一致）和 Spring Cloud 2.x 开发，而本文也将基于 2.7.x 的这个先期版本展开讲解。

无论开发人员是 Dubbo 用户还是 Spring Cloud 用户，都能轻松地驾驭 Dubbo Spring Cloud，并以接近“零”成本的代价使应用向上迁移。Dubbo Spring Cloud 致力于简化 Cloud Native 开发成本，提高研发效能以及提升应用性能等目的。

版本支持

由于 Spring 官方宣布 Spring Cloud Edgware(下文简称为 “E” 版) 将在 2019 年 8 月 1 日后停止维护 13，因此，目前 Dubbo Spring Cloud 发布版本并未对 “E” 版提供支持，仅为 “F” 版 和 “G” 版开发，同时也建议和鼓励 Spring Cloud 用户更新至 “F” 版 或 “G” 版。

同时，Dubbo Spring Cloud 基于 Apache Dubbo Spring Boot 2.7.x 开发（最低 Java 版本为 1.8），提供完整的 Dubbo 注解驱动、外部化配置以及 Production-Ready 的特性，点击查看详情。

以下表格将说明 Dubbo Spring Cloud 版本关系映射关系：

功能特性

由于 Dubbo Spring Cloud 构建在原生的 Spring Cloud 之上，其服务治理方面的能力可认为是 Spring Cloud Plus，不仅完全覆盖Spring Cloud 原生特性，而且提供更为稳定和成熟的实现，特性比对如下表所示：

高亮特性

1）Dubbo 使用 Spring Cloud 服务注册与发现

Dubbo Spring Cloud 基于 Spring Cloud Commons 抽象实现 Dubbo 服务注册与发现，应用只需增添外部化配置属性“dubbo.registry.address = spring-cloud://localhost，就能轻松地桥接到所有原生 Spring Cloud 注册中心，包括：- Nacos – Eureka – Zookeeper – Consul。

注：Dubbo Spring Cloud 将在下个版本支持 Spring Cloud 注册中心与 Dubbo 注册中心并存，提供双注册机制，实现无缝迁移。

2）Dubbo 作为 Spring Cloud 服务调用

默认情况，Spring Cloud Open Feign 以及@LoadBalancedRestTemplate 作为 Spring Cloud 的两种服务调用方式。Dubbo Spring Cloud 为其提供了第三种选择，即 Dubbo 服务将作为 Spring Cloud 服务调用的同等公民出现，应用可通过 Apache Dubbo 注解 @Service 和 @Reference 暴露和引用 Dubbo 服务，实现服务间多种协议的通讯。同时，也可以利用 Dubbo 泛化接口轻松实现服务网关。

3）Dubbo 服务自省

Dubbo Spring Cloud 引入了全新的服务治理特性 – 服务自省（Service Introspection），其设计目的在于最大化减轻注册中心负载，去 Dubbo 注册元信息中心化。假设一个 Spring Cloud 应用引入 Dubbo Spring Boot Starter，并暴露 N 个 Dubbo 服务，以Dubbo Nacos 注册中心为例，当前应用将注册 N+1 个 Nacos 应用，除 Spring Cloud 应用本身之前，其余 N 个应用均来自于 Dubbo 服务，当 N 越大时，注册中心负载越重。

因此，Dubbo Spring Cloud 应用对注册中心的负载相当于传统 Dubbo 的 N 分之一，在不增加基础设施投入的前提下，理论上，使其集群规模扩大 N 倍。当然，未来的 Dubbo 也将提供服务自省的能力。

4）Dubbo 迁移 Spring Cloud 服务调用

尽管 Dubbo Spring Cloud 完全地保留了原生 Spring Cloud 服务调用特性，但是 Dubbo 服务治理的能力是 Spring Cloud Open Feign 所不及的，如高性能、高可用以及负载均衡稳定性等方面。因此，建议开发人员将 Spring Cloud Open Feign 或者 @LoadBalancedRestTemplate 迁移为 Dubbo 服务。

考虑到迁移过程并非一蹴而就，因此，Dubbo Spring Cloud 提供了方案，即 @DubboTransported 注解。该注解能够帮助服务消费端的 Spring Cloud Open Feign 接口以及 @LoadBalanced RestTemplate Bean 底层走 Dubbo 调用（可切换 Dubbo 支持的协议），而服务提供方则只需在原有 @RestController 类上追加 Dubbo @Servce 注解（需要抽取接口）即可，换言之，在不调整 Feign 接口以及 RestTemplate URL 的前提下，实现无缝迁移。如果迁移时间充分的话，建议使用 Dubbo 服务重构系统中的原生 Spring Cloud 服务的定义。

简单示例

开发 Dubbo Spring Cloud 应用的方法与传统 Dubbo 或 Spring Cloud 应用类似，按照以下步骤就能完整地实现Dubbo 服务提供方和消费方的应用，完整的示例代码请访问一下资源：

• Dubbo 服务提供方应用
• Dubbo 服务消费方应用

1. 定义 Dubbo 服务接口

Dubbo 服务接口是服务提供方与消费方的远程通讯契约，通常由普通的 Java 接口（interface）来声明，如EchoService 接口：

public interface EchoService {


    String echo(String message);
}

为了确保契约的一致性，推荐的做法是将 Dubbo 服务接口打包在第二方或者第三方的 artifact（jar）中，如以上接口就存放在 artifact spring-cloud-dubbo-sample-api 之中。

对于服务提供方而言，不仅通过依赖 artifact 的形式引入 Dubbo 服务接口，而且需要将其实现。对应的服务消费端，同样地需要依赖该 artifact，并以接口调用的方式执行远程方法。接下来进一步讨论怎样实现 Dubbo 服务提供方和消费方。

2. 实现 Dubbo 服务提供方

1）初始化 spring-cloud-dubbo-server-sample Maven 工程

首先，创建 artifactId 名为 spring-cloud-dubbo-server-sample 的 Maven 工程，并在其 pom.xml 文件中增添 Dubbo Spring Cloud 必要的依赖：

    
    
        org.springframework.cloud
        spring-cloud-dubbo-sample-api
        ${project.version}
    


    
    
        org.springframework.boot
        spring-boot-actuator
    


    
    
        org.springframework.cloud
        spring-cloud-starter-dubbo
    


    
    
        org.springframework.cloud
        spring-cloud-starter-alibaba-nacos-discovery
    
 该值在 Dubbo Spring Cloud 加持下被视作 dubbo.application.name，因此，无需再显示地配置 dubbo.application.name；
spring.cloud.nacos.discovery: Nacos 服务发现与注册配置，其中子属性 server-addr 指定 Nacos 服务器主机和端口。




以上完整的 YAML 配置文件，请参考 spring-cloud-dubbo-server-samplebootstrap.yaml 文件。
完成以上步骤后，还需编写一个 Dubbo Spring Cloud 引导类。
4）引导 Dubbo Spring Cloud 服务提供方应用
Dubbo Spring Cloud 引导类与普通 Spring Cloud 应用并无差别，如下所示：
 @EnableDiscoveryClient @EnableAutoConfiguration public class DubboSpringCloudServerBootstrap {
public static void main(String[] args) {
    SpringApplication.run(DubboSpringCloudServerBootstrap.class);
}
}
在引导 DubboSpringCloudServerBootstrap 之前，请提前启动 Nacos 服务器。当 DubboSpringCloudServerBootstrap 启动后，将应用 spring-cloud-dubbo-server-sample 将出现在 Nacos 控制台界面。
当 Dubbo 服务提供方启动后，下一步实现一个 Dubbo 服务消费方。
3. 实现 Dubbo 服务消费方
由于 Java 服务就 EchoService、服务提供方应用 spring-cloud-dubbo-server-sample 以及 Nacos 服务器均已准备完毕。Dubbo 服务消费方只需初始化服务消费方 Maven 工程 spring-cloud-dubbo-client-sample 以及消费 Dubbo 服务。
1）初始化 spring-cloud-dubbo-client-sample Maven 工程
与服务提供方 Maven 工程类，需添加相关 Maven 依赖：

            org.springframework.cloud

            spring-cloud-alibaba-dependencies

            2.2.1.RELEASE

            pom

            import
        org.springframework.cloud

        spring-cloud-dubbo-sample-api

        ${project.version}
        org.springframework.boot

        spring-boot-starter-web
        org.springframework.boot

        spring-boot-actuator
        org.springframework.cloud

        spring-cloud-starter-dubbo
        org.springframework.cloud

        spring-cloud-starter-alibaba-nacos-discovery