Dubbo——SpringBoot集成Dubbo（@Autowired和@Reference的区别、Dubbo的服务治理）
Dubbo——原生API实现远程调用_Strine的博客-CSDN博客
在上一篇文章中我们讲了如何使用原生API发起远程调用，显然这种方式肯定是非常麻烦的，因此我们这里就讲如何使用SpringBoot去集成Dubbo将这些配置简化。
生产者服务
添加配置文件
dubbo:
application:
name: product-server
registry:
address: zookeeper://127.0.0.1:2181
protocol:
name: dubbo
port: 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: website
registry:
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;
@Reference
private 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对象;
事务问题（分布式事务）
-
A服务开启事务对B服务发起远程调用
-
B服务掉调用也开启了一个事务，然后进行业务操作，业务正常执行，最终提交事务
-
A服务拿到远程调用的结果继续执行操作，但是后面出现异常了
-
请问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服务集群
只有一个服务对象时，所有压力都落在同一个对象上，逼近极限时很可能导致服务挂掉，我们可以通过多发布几个服务对象，通过负载均衡策略来缓解单一服务对象压力过大问题
-
生产者多发布几个服务对象，注意修改多个服务发布的端口
# 生产者发布端口 dubbo.protocol.port=20880 #生产者A # ------------ dubbo.protocol.port=20883 #生产者B # ------------ ... - 消费者修改负载均衡策略，有以下选择
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
