惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Vercel News
Vercel News
F
Fortinet All Blogs
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
GbyAI
GbyAI
MongoDB | Blog
MongoDB | Blog
Jina AI
Jina AI
aimingoo的专栏
aimingoo的专栏
I
InfoQ
IT之家
IT之家
罗磊的独立博客
Blog — PlanetScale
Blog — PlanetScale
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
The Cloudflare Blog
爱范儿
爱范儿
Microsoft Azure Blog
Microsoft Azure Blog
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
美团技术团队
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
B
Blog RSS Feed
G
Google Developers Blog
大猫的无限游戏
大猫的无限游戏
博客园_首页
Engineering at Meta
Engineering at Meta
Martin Fowler
Martin Fowler

个人博客

leetcode经典动态规划解题报告 Netty启动原理 web安全基础知识一 SpringBoot自动配置原理 跟踪SpringMVC请求过程 Netty之ChannelHandler 负载均衡的实现方式与算法 Netty之ByteBuf Netty线程模型 段页式内存管理 fork()与写时复制 fork()与写时复制 Linux内核设计与实现读书笔记一 MyBatis的使用回顾 Dubbo集群容错 Dubbo服务调用过程 InnoDB的锁 SpringBoot启动原理 Maven和Git命令的一些总结 高可用Redis:Redis Cluster
Dubbo小知识点总结
zofun · 2020-05-12 · via 个人博客

文章导航

Dubbo的几种集群容错方案

集群容错方案 解释
Failover(默认) 快速失败,只发起一次调用,失败立即报错。通常用于非幂等性的写操作,比如新增记录。
Failsafe 安全失败,出现异常时,直接忽略,通常用于写入日志
Failback 失败自动恢复,后台记录失败请求,定时重发。通常用于消息通知等。
Forking 并行调用多个服务器,只要有一个成功即放hi。通常用于对实时性要求较高的读操作。
Broadcast 广播所有的调用者,逐个调用,任意一台报错即报错。通常用于通知所有的提供者更新缓存本地资源信息。

它的配置方式是这样的:

1
<dubbo:service cluster="failsafe" />

Dubbo的负载均衡算法有哪些

Dubbo内部提供了4种负载均衡算法。

  1. 基于权重随机算法的RandomLoadBalance(默认)
  2. 基于最少活跃调用数算法的LeastActiveBalance
  3. 基于一致性hash算法的ConsistentHashLoadBalance
  4. 基于加权轮询算法的RoundRobinLoadBalance
    基于加权的轮询算法会根据每台服务器的性能为服务器设置一个权值,加权后,每台服务器能够得到的请求数比例,接近或等于他们的权重比。比如服务器 A、B、C 权重比为 5:2:1。那么在8次请求中,服务器 A 将收到其中的5次请求,服务器 B 会收到其中的2次请求,服务器 C 则收到其中的1次请求。
1
2
3
4
<dubbo:service interface="com.alibaba.hello.api.WorldService" version="1.0.0" ref="helloService"
timeout="300" retries="2" loadbalance="random" actives="0" >
<dubbo:method name="findAllPerson" timeout="10000" retries="9" loadbalance="leastactive" actives="5" />
<dubbo:service/>

服务化推荐用法

分包

将服务接口、服务模型、服务异常均放在API包中,因为服务模型和异常也是API的一部分,这样做服务分包原则:重用发布等价原则(REP),共同重用原则(CRP)

粒度

服务接口应该尽可能大粒度,每个服务方法应代表一个功能,而不是某功能的一个步骤,否则将面临分布式事务问题,而Dubbo并未提供分布式事务解决方案。

版本

每个接口都应该定义版本号,为后序不兼容升级提供可能。

兼容性

服务接口增加方法,或服务模型增加字段,可向后兼容,删除方法或删除字段,将不兼容,枚举类型新增字段也不兼容,需要通过变更版本号升级。

枚举值

如果是完备集,可以使用Enum
如果后期可能会有变更,建议使用String代替。

序列化

服务参数和返回值建议使用POJO对象。

异常

建议使用异常汇报错误,而不是返回错误码,异常信息能够携带更多信息,并且语义更加友好。

调用

不要只是因为是 Dubbo 调用,而把调用 try...catch 起来。try...catch 应该加上合适的回滚边界上。
Provider 端需要对输入参数进行校验。如有性能上的考虑,服务实现者可以考虑在 API 包上加上服务 Stub 类来完成检验。

Dubbo推荐用法

在Provider端尽可能多配置consumer端属性

因为作为服务的提供方,比服务消费方更清楚服务的性能。在服务提供端配置后,消费端不配置则会使用服务提供端的配置。如果在消费端进行配置,那么对服务端来讲就是不可控的。

一个配置示例:

1
2
3
4
5
6
7
<dubbo:service interface="com.alibaba.hello.api.HelloService" version="1.0.0" ref="helloService"
timeout="300" retries="2" loadbalance="random" actives="0" />

<dubbo:service interface="com.alibaba.hello.api.WorldService" version="1.0.0" ref="helloService"
timeout="300" retries="2" loadbalance="random" actives="0" >
<dubbo:method name="findAllPerson" timeout="10000" retries="9" loadbalance="leastactive" actives="5" />
<dubbo:service/>

建议在服务提供端配置的消费端属性有:
timeoutretriesloadbalance actives

在服务提供端配置合理的提供端属性

比如这样:

1
2
3
4
5
<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>

建议在服务提供端配置的提供端属性有:
threads (服务线程池的大小)、executes(一个服务提供者并行执行请求的上限)