SpringCloudAlibaba整合Dubbo
Spring Cloud是一套较为完整的架构方案，而Dubbo只是服务治理与RPC实现方案。
Dubbo的注册中心采用了ZooKeeper，而Spring Cloud体系中的注册中心并不支持ZooKeeper。直到Spring Cloud Alibaba的出现，才得以解决这样的问题，Spring Cloud Alibaba中的Nacos来作为服务注册中心，并且在此之下可以如传统的Spring Cloud应用一样地使用Ribbon或Feign来实现服务消费，并提供了Spring Cloud Alibaba下额外支持的RPC方案：Dubbo
构建服务接口
public interface HelloService {
String hello(String name);
}
构建服务接口提供方
（1）创建一个Spring Boot项目，在pom.xml中引入第一步中构建的API包以及Spring Cloud Alibaba对Nacos和Dubbo的依赖
<dependency> <groupId>top.onething</groupId> <artifactId>product-api</artifactId> <version>1.0-SNAPSHOT</version> </dependency> <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId> <version>2.2.1.RELEASE</version> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> <version>2.2.5.RELEASE</version> </dependency> <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId> <version>2.2.1.RELEASE</version> </dependency> <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-dubbo</artifactId> <version>2.2.1.RELEASE</version> </dependency> <!--Dubbo Spring Cloud基于Spring Cloud Commons开发的，org.apache.http.client.HttpClient类确实存在于旧版本的httpclient中， 但是它使用内部的org.apache.http.impl.client.HttpClientBuilder类在新版本中却不存在--> <dependency> <groupId>org.apache.httpcomponents</groupId> <artifactId>httpclient</artifactId> <version>4.5.4</version> <scope>compile</scope> </dependency>
spring-cloud-starter-dubbo基于spring-cloud-starter-commons开发的，org.apache.http.client.HttpClient类确实存在于旧版本的httpclient中，但是它使用内部的org.apache.http.impl.client.HttpClientBuilder类在新版本中却不存在。如果类路径上没有HttpClient，则HttpClientConfiguration自动配置将失败 HttpClientConfiguration的自动配置因对HttpClient的旧依赖性而失败，异常如下所示：
java.lang.IllegalStateException: Error processing condition on org.springframework.cloud.commons.httpclient.HttpClientConfiguration$ApacheHttpClientConfiguration.apacheHttpClientBuilder
Caused by: java.lang.ClassNotFoundException: org.apache.http.impl.client.HttpClientBuilder
（2）实现Dubbo接口
@Service
public class HelloServiceImpl implements HelloService {
@Override
public String hello(String name) {
return "hello " + name;
}
}
注意：@Service注解不是Spring的，而是dubbo的，完全限定名为：org.apache.dubbo.config.annotation.Service
（3）配置Dubbo服务相关的信息
配置说明如下：
spring:
application:
name: dubbo-consumer
cloud:
nacos:
discovery:
server-addr: www.onething.top:8848 # nacos服务注册中心的地址
cluster-name: consumer-cluster #集群名称
namespace: b7ef9579-df75-41c2-8a95-e04aa03c273a #命名空间
config:
server-addr: www.onething.top:8848 # nacos配置中心地址
namespace: b7ef9579-df75-41c2-8a95-e04aa03c273a
file-extension: yaml #配置文件的后缀名
refresh-enabled: true #默认true：自动刷新
dubbo:
protocol: #Dubbo 服务暴露的协议配置，其中子属性 name 为协议名称，port 为协议端口（ -1 表示自增端口，从 20880 开始）
name: dubbo
port: -1 #dubbo协议缺省端口为20880，rmi协议缺省端口为1099，http和hessian协议缺省端口为80；如果没有配置port，则自动采用默认端口，如果配置为-1，则会分配一个没有被占用的端口。Dubbo 2.4.0+，分配的端口在协议缺省端口的基础上增长，确保端口段可控
registry:
#dubbo服务注册端口，注册中心服务器地址，如果地址没有端口缺省为9090，同一集群内的多个地址用逗号分隔，如：ip:port,ip:port
#其中前缀spring-cloud说明：挂载到 Spring Cloud注册中心
address: spring-cloud://www.onething.top:8848
#check: false #关闭注册中心是否启动的相关检查,false表示不检查注册中心是否启动，就不会报错
cloud:
subscribed-services: dubbo-product
consumer:
check: false #关闭订阅服务是否启动的检查【检查时，没有服务提供者会报错】
- dubbo.scan.base-packages: 指定 Dubbo 服务实现类的扫描基准包
- dubbo.protocol: Dubbo 服务暴露的协议配置，其中子属性 name 为协议名称，port 为协议端口（ -1 表示自增端口，从 20880 开始）
- dubbo.registry: Dubbo 服务注册中心配置，其中子属性 address 的值 “spring-cloud://localhost”，说明挂载到 Spring Cloud 注册中心
注意：如果使用Spring Boot 2.1及更高版本时候，需要增加配置spring.main.allow-bean-definition-overriding=true
（4）创建应用主类
@EnableDiscoveryClient【此注解可以省略】
@SpringBootApplication
public class DubboServerApplication {
public static void main(String[] args) {
SpringApplication.run(DubboServerApplication.class, args);
}
}
构建服务接口消费方法
（1）创建一个Spring Boot项目，在pom.xml中引入第一步中构建的API包以及Spring Cloud Alibaba对Nacos和Dubbo的依赖，具体内容与服务提供方一致
<dependencies>
<dependency>
<groupId>top.onething</groupId>
<artifactId>product-api</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
<version>2.2.1.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<version>2.2.5.RELEASE</version>
</dependency>
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
<version>2.2.1.RELEASE</version>
</dependency>
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-dubbo</artifactId>
<version>2.2.1.RELEASE</version>
</dependency>
</dependencies>
（2）配置Dubbo服务相关的信息
spring:
application:
name: dubbo-consumer
cloud:
nacos:
discovery:
server-addr: www.onething.top:8848 # nacos服务注册中心的地址
cluster-name: consumer-cluster #集群名称
namespace: b7ef9579-df75-41c2-8a95-e04aa03c273a #命名空间
config:
server-addr: www.onething.top:8848 # nacos配置中心地址
namespace: b7ef9579-df75-41c2-8a95-e04aa03c273a
group: test-group
file-extension: yaml #配置文件的后缀名
dubbo:
protocol: #Dubbo 服务暴露的协议配置，其中子属性 name 为协议名称，port 为协议端口（ -1 表示自增端口，从 20880 开始）
name: dubbo
port: -1 #dubbo协议缺省端口为20880，rmi协议缺省端口为1099，http和hessian协议缺省端口为80；如果没有配置port，则自动采用默认端口，如果配置为-1，则会分配一个没有被占用的端口。Dubbo 2.4.0+，分配的端口在协议缺省端口的基础上增长，确保端口段可控
registry:
#其中前缀spring-cloud说明：挂载到 Spring Cloud注册中心
address: spring-cloud://www.onething.top:8848 #dubbo服务注册端口，注册中心服务器地址，如果地址没有端口缺省为9090，同一集群内的多个地址用逗号分隔，如：ip:port,ip:port
cloud:
subscribed-services: dubbo-product
（3）创建应用主类，并实现一个接口，在这个接口中调用Dubbo服务
@EnableDiscoveryClient
@SpringBootApplication
@RestController
public class DubboClientApplication {
@Reference
HelloService helloService;
public static void main(String[] args) {
SpringApplication.run(DubboClientApplication.class, args);
}
@GetMapping("/test")
public String test() {
return helloService.hello("didispace.com");
}
}
注意：这里的@Reference注解是org.apache.dubbo.config.annotation.Reference
SpringCloudAlibaba之Dubbo总结
GitHub地址：https://github.com/apache/dubbo
Dubbo的故事比较长了，Demo中也有调用的示例，所以示例就不补充了，我的gitee仓库上也有一些可参考的示例。目前在这里就只针对目前的最新版本2.7.7，做一点总结把。
另外，关于Dubbo，出来这么多年了，很多人更关注Dubbo的动态代理、底层Netty协议等一些问题。但是我觉得，其实更应该关注的是Dubbo在服务调用这个场景中做到了哪些，想到了哪些，这些应该是比手写Dubbo更有价值的地方。这中间的关系就像架构师跟程序员之间的差距，并不是架构师代码就写得就比程序员好，而是架构师能考虑到各种情况，组合成系统化解决实际问题的解决方案。
Dubbo概述
官网的特性描述：
- 面向接口代理的高性能RPC调用：提供高性能的基于代理的远程调用能力，服务以接口为粒度，为开发者屏蔽远程调用底层细节。
- 智能负载均衡:内置多种负载均衡策略，智能感知下游节点健康状况，显著减少调用延迟，提高系统吞吐量。
- 服务自动注册与发现：支持多种注册中心服务，服务实例上下线实时感知。
- 高度可扩展能力：遵循微内核+插件的设计原则，所有核心能力如Protocol,Transport,Serialization被设计为扩展点，平等对待内置实现和第三方实现。
- 运行期流量调度：内置条件、脚本等路由策略，通过配置不同的路由规则，轻松实现灰度发布、同机房优先等功能。
- 可视化的服务治理与运维：提供丰富服务治理、运维工具，随时查询服务元数据，服务健康状态即调用统计、实时下发路由策略、调整配置参数。
这个图可以看到Dubbo的各角色职责，Registery负责服务发现与注册，Provider往Registry上注册服务信息，Consumer订阅Registry上的服务信息，Registry会及时向Consumer进行推送。然后Consumer从服务列表中选择一个Provider，进行服务调用。
Dubbo配置方式
Dubbo的服务有三种配置方式，API方式、基于Spring的XML方式和基于SpringBoot的Properties方式。三种方式的服务配置在Demo工程中都有实现，就不多说了。这里要记录一下的，是各种配置的优先级。
三种配置方式之间的关系
显而易见，API方式其实已经不是服务化的配置方式了，是底层的实现方式，展示的是如何将Dubbo的几个核心对象组装成服务。正常情况下也是不太会用得到的，只是在一些脱离Spring的环境中可以偶尔强行用一下，比如MapReduce、spark计算等一些情况可以强行用上一点。
而后两种配置方式，其实效果是等价的。例如 dubbo.application.name=foo和<dubbo:registry name=“foo” />是等价的，而dubbo.registry.address=nacos://localhost:8848和<dubbo:registry address="nacos://localhost:8848"这两个也是等价的。而在多配置的时候，需要用ID进行区分时，dubbo.protocol.rmi.port=1099 equals to <dubbo:protocol id=“rmi” name=“rmi” port=“1099” />这两种方式也是等价的。而且实际上，在SpringBoot工程中，也是可以通过引入@ImportResource注解，来指定dubbo的服务配置XML的。
而如果在一个SpringBoot工程中，将两种配置方式整合在一起，那配置的优先级又是怎样的呢？这时的优先级是{java -D}>{xml}>{properties}。并且，如果一个项目中有多个dubbo.properties(例如多个jar包中都有配置文件)，那么，dubbo会随机的读取一个配置文件，同时会抛出异常信息。官方的建议也是多使用xml方式进行配置。
另外，基于SpringCloud的properties配置，其实还有另一种基于注解的服务声明方式，@Service暴露服务，@Reference调用服务，而这种方式，其实跟xml配置的方式也是等价的。
服务端与消费端的配置优先级
有很多服务属性如retris(重试次数)、timeout(超时时间)、loadbalance(负载方法)等属性，在服务提供端和服务消费端都可以进行配置。此时，服务消费端的配置是优先于服务提供端的。服务提供端的配置相当于是服务的默认属性，因此，官方建议要在服务提供端尽量多的配置这些服务属性。另外，官方还建议，在服务端尽量提供更详细的服务配置，例如在配置服务时，如果可以的话，对每个method提供详细的配置。例如：
<dubbo:protocol threads="200" /> <dubbo:service interface="com.alibaba.hello.api.HelloService" version="1.0.0" ref="helloService" executes="200" > <dubbo:method name="findAllPerson" executes="50" /> </dubbo:service>
这样指定了线程池200，而findAllPerson的线程池为50.
指定dubbo的Cache File
官方建议要在registry中指定file。例如<dubbo:registry file=”${user.home}/output/dubbo.cache” />。这个Cache File可以缓存服务注册信息，这样，在注册中心停止服务后，消费端依然可以进行服务调用。由于这个文件很重要，虽然不指定也会默认生成到本地，但是官方建议是要单独指定缓存文件，并且注意不要有多个工程指定同一个缓存文件的情况，这样会造成文件写入权限竞争以及服务注册信息被覆盖的情况。
这个CacheFile机制可以允许消费者绕过注册中心访问服务提供者，而如果需要防止这种情况，可以使用dubbo的令牌验证机制，这样需要在注册中心进行权限验证才可以访问。开启方式也很简单，在provider或者service指定token属性即可：
<!--随机token令牌，使用UUID生成--> <dubbo:provider interface="com.foo.BarService" token="true" /> <!--固定token令牌，相当于密码--> <dubbo:provider interface="com.foo.BarService" token="123456" />
其他一些有意思的地方
官方的文档中很详细的说明了dubbo的许多特性，这里挑一些有意思的特性。其他可以多参考官方文档。
服务集群容错机制
可以在service中指定集群容错机制，例如 <dubbo:service cluster=“failsafe” />
- 默认是Failover，这种模式当访问出错时(超时等)，会自动寻找另外的提供者，发起重试。可以通过指定retries来指定重试次数Cretries配置的次数不包含第一次请求。这通常用于读操作，对于写操作，容易造成服务幂等问题。
- Failfast:只发起一次服务调用，如果出错就立即报错。这种比较适用于写操作。
- Failsafe:如果服务调用出错或者出现异常，则直接忽略。这种比较适用于写日志这类允许失败的操作。
- Failback:故障自动恢复，后台记录失败的请求，并定期重传。这种比较适用于消息驱动的场景。
- Forking: 同时向多个服务端发起请求，一旦有一个服务提供端返回成功，则服务调用成功。这种比较适用于实时性要求较高的读操作。但是显然，这样会浪费更多的服务资源。可以使用fork属性配置并行数。
- BroadCast: 同时向所有服务提供端发起请求，依次请求，并会报告每一个错误。这通常用于通知所有服务端进行缓存更新之类的操作。
本地服务存根与本地伪装 local stub， local mock
1、通常情况下，服务消费端只有一个接口，对服务的调用实现全部依赖服务提供端。但是，有时候，服务提供端希望在服务消费端也做一些本地操作，例如做ThreadLocal缓存、参数检查、调用失败后返回Mock假数据等。这样，有些在SpringCloud中需要在消费端用Hystrix做的事情，就可以用这个本地服务存根，在服务端直接帮消费端处理完了，这样可以让消费端更进一步忽略服务调用细节。例如，在服务提供端做如下配置：
<dubbo:service interface="com.foo.BarService" stub="true" /> or <dubbo:service interface="com.foo.BarService" stub="com.foo.BarServiceStub" />
然后服务提供端就可以通过提供一个本地存根方法，这样BarServiceStub的sayHello方法会在消费端的本地执行，让消费端在服务调用失败后返回容错数据。
public class BarServiceStub implements BarService {
private final BarService barService;
// 构造函数传入真正的远程代理对象
public BarServiceStub(BarService barService){
this.barService = barService;
}
public String sayHello(String name) {
// 此代码在客户端执行, 你可以在客户端做ThreadLocal本地缓存，或预先验证参数是否合法，等等
try {
return barService.sayHello(name);
} catch (Exception e) {
// 你可以容错，可以做任何AOP拦截事项
return "容错数据";
}
}
}
2、针对Mock这种容错场景，dubbo可以使用mock属性进行更简单的配置；
<dubbo:reference interface="com.foo.BarService" mock="true" /> or <dubbo:reference interface="com.foo.BarService" mock="com.foo.BarServiceMock" />
这样，在barServiceMock中，就不用try cache，而只用关注cache后的处理。
public class BarServiceMock implements BarService {
public String sayHello(String name) {
// 你可以伪造容错数据，此方法只在出现RpcException时被执行
return "容错数据";
}
}
这样，服务消费者可以省掉很多不必要的try cache操作。
3、在mock属性中，可以直接返回一些指定的对象，从而连实现代码都可以省略调了。例如：
<dubbo:reference interface="com.foo.BarService" mock="return null" />
mock属性可以返回的对象有：
- empty:空对象，代表基本类型的默认值，或者空集合等。
- null: java中的null对象
- boolean: true 或者 false
- JSON 格式: 一个对象的JSON反序列化对象。
还有， mock属性中，还可以简单的抛出异常
<dubbo:reference interface="com.foo.BarService" mock="throw" /> //抛出一个RPCException异常 <dubbo:reference interface="com.foo.BarService" mock="throw com.foo.MockException" /> //抛出一个指定异常
4、这个版本的dubbo中，mock属性还支持force和fail的mock行为。
fail跟默认流程一致，即表示当消费端远程调用出现异常时才进行。
而force则表示不走远程调用，直接返回mock数据。这在调试时还是有点用的。
force和fail都支持与上面的return或者throw进行组合。、
<dubbo:reference interface="com.foo.BarService" mock="force:return fake" /> or <dubbo:reference interface="com.foo.BarService" mock="force:throw com.foo.MockException" />
5、这个local mock，在处理服务调用异常时，是挺强大的。官方建议，尽量在方法级别上使用mock，而不要在整个服务上使用。像这样，只在sayHello方法上使用mock.
<dubbo:reference id="demoService" check="false" interface="com.foo.BarService"> <dubbo:parameter key="sayHello.mock" value="force:return fake"/> </dubbo:reference>
6、注意下，stub和mock在服务的提供端和消费端都可以指定，应该还是消费端的优先级高于提供端。
泛化服务 GenericService
Dubbo的服务总是面向接口的，意味着服务调用总是需要一个固定的接口对象，这样很安全，但是同时也不够灵活。而Dubbo可以通过GenericService泛华服务来增加服务灵活性。
1、服务提供端：
在服务提供端，可以用org.apache.dubbo.rpc.service.GenericService替代所有的接口实现。 例如，先按如下方式提供一个服务：
<bean id="genericService" class="com.foo.MyGenericService" /> <dubbo:service interface="com.foo.BarService" ref="genericService" />
而指定的MyGenericService，可以通过继承GenericService来实现扩展逻辑：
public class MyGenericService implements GenericService {
@Override
public Object $invoke(String methodName, String[] parameterTypes, Object[] args) throws GenericException {
if ("sayHello".equals(methodName)) {
return "Welcome " + args[0];
}
}
}
这样就可以在不需要接口的情况下，响应服务端的 barService.sayHello(String args)这样的服务请求了。
这种泛化服务方式同样支持API方式的服务暴露，跟xml的配置基本是对等的。
2、泛化服务调用
泛化服务调用，只需要在reference中指定generic为true就行。
<dubbo:reference id="barService" interface="com.foo.BarService" generic="true" />
泛化服务没有了预先定义好的方法，需要使用GenericService的$invoke方法来进行调用
GenericService barService = (GenericService) applicationContext.getBean("barService");
Object result = barService.$invoke("sayHello", new String[] { "java.lang.String" }, new Object[] { "World" });
这种调用方式同样支持API格式的服务调用。
泛化方法的返回对象，如果是个POJO的对象，则会以Map结构返回POJO的信息，类似于下面的结构
Map<String, Object> map = new HashMap<String, Object>();
// 注意：如果参数类型是接口，或者List等丢失泛型，可通过class属性指定类型。
map.put("class", "com.xxx.PersonImpl");
map.put("name", "xxx"); // Person的属性
map.put("password", "yyy");
服务管理控制台
Dubbo使用Nacos作为注册中心的话，Nacos已经可以充当服务控制台。
而另外有一个项目则可替代原有的Dubbo Admin作为Dubbo的服务管理控制台。github地址：https://github.com/apache/dubbo-admin 一个基于Vue.js和Verify+SpringBoot做的前后端分离的管理控制台。
国人的官网看着舒适，示例丰富，说明也很简单详尽，目前版本的Dubbo还有些如分布式事务之类的功能尚未实现，期待Dubbo更强大把。
以上为个人经验，希望能给大家一个参考，也希望大家多多支持服务器之家。
原文链接：https://blog.csdn.net/user2025/article/details/108338849
