Dubbo——SpringBoot集成Dubbo（@Autowired和@Reference的区别、Dubbo的服务治理）

Dubbo——原生API实现远程调用_Strine的博客-CSDN博客

在上一篇文章中我们讲了如何使用原生API发起远程调用，显然这种方式肯定是非常麻烦的，因此我们这里就讲如何使用SpringBoot去集成Dubbo将这些配置简化。

生产者服务

添加配置文件

dubbo:application:name: product-serverregistry:address: zookeeper://127.0.0.1:2181protocol:name: dubboport: 20880#允许Bean覆盖
spring:main:allow-bean-definition-overriding: true

添加启动类

添加@EnableDubbo注解用来扫描dubbo的@Service注解

@SpringBootApplication
@EnableDubbo
public class ProductServer {public static void main(String[] args) {SpringApplication.run(ProductServer.class,args);}
}

实现类

贴上@Service注解，注意：是Dubbo提供的；

 消费者服务

添加配置文件

dubbo:application:name: websiteregistry:address: zookeeper://127.0.0.1:2181
spring:main:allow-bean-definition-overriding: true

控制层

@RestController
@RequestMapping("/product")
public class WebsiteController {@Reference   //引用Dubbo提供的动态代理对象private IProductService productService;@Referenceprivate IMemberService memberService;@GetMapping("/pro/{productId}")public Product getProduct(@PathVariable Long productId){return productService.get(productId);}

启动类

@SpringBootApplication
@EnableDubbo
public class WebsiteServer {public static void main(String[] args) {SpringApplication.run(WebsiteServer.class,args);}
}

@Autowired和@Reference的区别

@Autowired是Spring的DI特性，是注入当前项目的Bean对象；

@Reference是引用远程项目中的Bean对象;

事务问题（分布式事务）

1. A服务开启事务对B服务发起远程调用

2. B服务掉调用也开启了一个事务，然后进行业务操作，业务正常执行，最终提交事务

3. A服务拿到远程调用的结果继续执行操作，但是后面出现异常了

4. 请问A事务的回滚能影响B服务中的事务吗？

明显事务A和事务B是分别在不同机器上开启的事务，相互独立，他们是两个不同的事务，因此传统的事务管理方式是不能应用在分布式系统中的，在分布式系统中有专门的分布式事务处理方式，如：强一致性，最终一致性，例如Seata下的AT模式以及TCC模式，就可以解决分布式事务；

Dubbo Admin管控台

github源码地址：GitHub - apache/dubbo-admin at master

该项目是SpringBoot开发的需要使用maven命令打包后运行，或者直接放在idea工具中运行也可以

默认端口：7001 ，账号密码都是root

我们可以点开目标服务并对服务的提供者和消费者进行相关操作  

Dubbo的服务治理

启动时检测（循环调用服务问题）

在实际开发中，经常会存在服务交叉引用的情况，如：A服务引用B服务，B服务也引用A服务，那么此时就存在问题，无论哪个服务在启动时都会报错

那么此时我们可以设置消费者项目启动时不要去检查服务是否存在，就可以顺利的启动项目了，但是在运行时服务依然不存在的话还是会报错：  

#消费者不检测服务是否存在
dubbo.consumer.check=false

服务集群

只有一个服务对象时，所有压力都落在同一个对象上，逼近极限时很可能导致服务挂掉，我们可以通过多发布几个服务对象，通过负载均衡策略来缓解单一服务对象压力过大问题

1. 生产者多发布几个服务对象，注意修改多个服务发布的端口

   # 生产者发布端口
   dubbo.protocol.port=20880 #生产者A
   # ------------
   dubbo.protocol.port=20883 #生产者B
   # ------------
   ...

2. 消费者修改负载均衡策略，有以下选择

   RandomLoadBalance：随机（random），默认策略
   RoundRobinLoadBalance：轮询（roundrobin）
   ConsistentHashLoadBalance：hash一致（consistenthash）
   LeastActiveLoadBalance：最少活跃（leastactive）#appliaction.properties
   #修改消费者负载均衡策略
   dubbo.consumer.loadbalance=roundrobin

   多版本发布

   服务在升级改造的过程中，由于不清楚新版本的服务是否存在BUG，往往都是采用过度的方式来进行切换，此时就要求两个版本的服务都要存在

   

 

 

 生产者在生产服务的时候指定该服务的版本号

@Service(version="1.0")
public class UserServiceImpl implements IUserService { ... }@Service(version="2.0")
public class UserServiceImpl implements IUserService { ... }

并且消费者必须明确告知引用哪个版本的服务

@Reference(version="1.0")
private IUserService userService;@Reference(version="2.0")
private IUserService userService;@Reference(version="*") //随机引用
private IUserService userService;

服务超时、重试、容错

在服务调用的过程中，有可能服务生产者网络环境差，但是消费者并不知道，依然发出请求，长时间没有回应，此时我们可以设置消费者等待的超时时间，当调用超过设置的时间时放弃等待远程的响应，默认超时时间是：1s

当发生超时时，框架并不会马上就放弃服务的调用，还会进行重试，默认重试次数：2次

我们可以修改消费端的配置来改变默认的超时时间和重试次数

#消费者设置超时时间1.5s
dubbo.consumer.timeout=1500
#消费者设置重试次数，重试1次
dubbo.consumer.retries=1#注意：只有幂等性操作才能重试，非幂等性操作是不能重试的

此时因超时调用失败，出现的报错页面会直接的反馈给消费者，消费者再把报错信息响应出去，用户就会直接看到错误页面，这样不友好，而且用户也看不懂，应该对错误信息进行处理，给用户一个稍微正常点的数据，这个就是服务的容错

从Dubbo Admin控制台去配置当前服务的容错，当服务不能正常调用时，返回null代替异常的信息

另外，服务集群后还能配置集群下的容错机制，有以下策略可以选择：

1.FailoverCluster：失败自动切换，默认策略，用于幂等性操作，如：查询
2.FailfastCluster：快速失败，只发起一次调用，失败立即报错，用于非幂等性操作，如：插入数据
3.FailsafeCluster：失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作
4.FailbackCluster：失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作
5.ForkingCluster：并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks="2" 来设置最大并行数
6.BroadcastCluster：广播调用所有提供者，逐个调用，任意一台报错则报错。通常用于通知所有提供者更新缓存或日志等本地资源信息#消费者配置服务集群容错策略
dubbo.consumer.cluster=failfast

 服务降级

当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源以保证核心交易正常运作或高效运作。

此时我们要保证服务B能抗住压力，就只能去牺牲服务A，甚至直接把服务A功能关闭掉，把资源留给服务B使用，此时我们就可以对服务A进行降级处理

从Dubbo Admin控制台去配置当前服务的降级，消费者访问降级的服务时，不发起远程调用请求，直接返回null