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对象;

事务问题（分布式事务）

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

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

spring cloud微服务_年后进大厂，必备这份微服务面试题：Dubbo+SpringBoot+Cloud
Dubbo面试题 Dubbo与DubboX区别 Dubbo中zookeeper做注册中心,如果注册中心集群都挂掉,发布者和订阅者之间还能通信么? Dubbo中有哪些角色? Dubbo在安全机制方面是如 ...
分布式服务治理框架Dubbo的前世今生及应用实战
Dubbo的出现背景# Dubbo从开源到现在,已经出现了接近10年时间,在国内各大企业被广泛应用. 它到底有什么魔力值得大家去追捧呢?本篇文章给大家做一个详细的说明. 大规模服务化对于服务治理的要求 ...
SpringBoot集成Log4j2框架
1.说明本文详细介绍Spring Boot集成Log4j2框架的方法, 基于已经创建好的Spring Boot工程, 由于Spring Boot默认使用的是Logback框架, 需要先排除掉Logb ...
SpringBoot集成MyBatis-Plus框架详细方法
1.说明本文详细介绍Spring Boot集成MyBatis-Plus框架的方法, 使用MySQL数据库进行测试, 包括完整的开发到测试步骤, 从一开始的Spring Boot工程创建, 到MySQ ...
Activiti 快速入门教程：SpringBoot 集成 Activiti6 + Activiti Modeler 流程配置可视化
Activiti 快速入门教程:SpringBoot 集成 Activiti6 + Activiti Modeler 流程配置可视化 7大服务与核心表 23张表概览 7大核心服务(重要) 加依赖内部 ...
SpringBoot集成Actuator端点配置
1.说明 Actuator端点可以监控应用程序并与之交互. Spring Boot包括许多内置的端点, 比如health端点提供基本的应用程序运行状况信息, 并允许添加自定义端点. 可以控制每个单独的 ...
SpringBoot集成Actuator监控管理
1.说明本文详细介绍Spring Boot集成Actuator监控管理的方法, 基于已经创建好的Spring Boot工程, 然后引入Actuator依赖, 介绍监控管理相关功能的使用. Sprin ...
SpringBoot集成MyBatis-Plus代码生成器(Dao)
1.说明本文基于SpringBoot集成MyBatis-Plus代码生成器, 把原来生成Entity.Mapper.Mapper XML.Service.Controller等各个模块的代码, 修改 ...
SpringBoot集成MyBatis-Plus代码生成器
1.说明本文详细介绍Spring Boot集成MyBatis-Plus代码生成器的方法. 基于一个创建好的Spring Boot工程, 执行MyBatis-Plus提供的AutoGenerator代 ...

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

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

生产者服务

添加配置文件

添加启动类

实现类

消费者服务

添加配置文件

控制层

启动类

@Autowired和@Reference的区别

事务问题（分布式事务）

Dubbo Admin管控台

Dubbo的服务治理

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

服务集群

多版本发布

服务超时、重试、容错

服务降级

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

最新文章

热门文章