网站建设设计策划,wordpress多用户商城主题,附近量身定做衣服店,小学校园门户网站建设方案Dubbo——原生API实现远程调用_Strine的博客-CSDN博客
在上一篇文章中我们讲了如何使用原生API发起远程调用#xff0c;显然这种方式肯定是非常麻烦的#xff0c;因此我们这里就讲如何使用SpringBoot去集成Dubbo将这些配置简化。
生产者服务
添加配置文件
dubbo:applicat…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.checkfalse
服务集群
只有一个服务对象时所有压力都落在同一个对象上逼近极限时很可能导致服务挂掉我们可以通过多发布几个服务对象通过负载均衡策略来缓解单一服务对象压力过大问题 生产者多发布几个服务对象注意修改多个服务发布的端口 # 生产者发布端口
dubbo.protocol.port20880 #生产者A
# ------------
dubbo.protocol.port20883 #生产者B
# ------------
... 消费者修改负载均衡策略有以下选择 RandomLoadBalance随机random默认策略
RoundRobinLoadBalance轮询roundrobin
ConsistentHashLoadBalancehash一致consistenthash
LeastActiveLoadBalance最少活跃leastactive#appliaction.properties
#修改消费者负载均衡策略
dubbo.consumer.loadbalanceroundrobin 多版本发布 服务在升级改造的过程中由于不清楚新版本的服务是否存在BUG往往都是采用过度的方式来进行切换此时就要求两个版本的服务都要存在 生产者在生产服务的时候指定该服务的版本号
Service(version1.0)
public class UserServiceImpl implements IUserService { ... }Service(version2.0)
public class UserServiceImpl implements IUserService { ... }
并且消费者必须明确告知引用哪个版本的服务
Reference(version1.0)
private IUserService userService;Reference(version2.0)
private IUserService userService;Reference(version*) //随机引用
private IUserService userService;
服务超时、重试、容错
在服务调用的过程中有可能服务生产者网络环境差但是消费者并不知道依然发出请求长时间没有回应此时我们可以设置消费者等待的超时时间当调用超过设置的时间时放弃等待远程的响应默认超时时间是1s
当发生超时时框架并不会马上就放弃服务的调用还会进行重试默认重试次数2次
我们可以修改消费端的配置来改变默认的超时时间和重试次数
#消费者设置超时时间1.5s
dubbo.consumer.timeout1500
#消费者设置重试次数重试1次
dubbo.consumer.retries1#注意只有幂等性操作才能重试非幂等性操作是不能重试的
此时因超时调用失败出现的报错页面会直接的反馈给消费者消费者再把报错信息响应出去用户就会直接看到错误页面这样不友好而且用户也看不懂应该对错误信息进行处理给用户一个稍微正常点的数据这个就是服务的容错
从Dubbo Admin控制台去配置当前服务的容错当服务不能正常调用时返回null代替异常的信息 另外服务集群后还能配置集群下的容错机制有以下策略可以选择
1.FailoverCluster失败自动切换默认策略用于幂等性操作如查询
2.FailfastCluster快速失败只发起一次调用失败立即报错用于非幂等性操作如插入数据
3.FailsafeCluster失败安全出现异常时直接忽略。通常用于写入审计日志等操作
4.FailbackCluster失败自动恢复后台记录失败请求定时重发。通常用于消息通知操作
5.ForkingCluster并行调用多个服务器只要一个成功即返回。通常用于实时性要求较高的读操作但需要浪费更多服务资源。可通过 forks2 来设置最大并行数
6.BroadcastCluster广播调用所有提供者逐个调用任意一台报错则报错。通常用于通知所有提供者更新缓存或日志等本地资源信息#消费者配置服务集群容错策略
dubbo.consumer.clusterfailfast 服务降级
当服务器压力剧增的情况下根据实际业务情况及流量对一些服务和页面有策略的不处理或换种简单的方式处理从而释放服务器资源以保证核心交易正常运作或高效运作。
此时我们要保证服务B能抗住压力就只能去牺牲服务A甚至直接把服务A功能关闭掉把资源留给服务B使用此时我们就可以对服务A进行降级处理
从Dubbo Admin控制台去配置当前服务的降级消费者访问降级的服务时不发起远程调用请求直接返回null
