dubbo 在服务治理方面的一些策略

本文策略说明所有来自官方文档.

 

1. 集群容错策略:

Failover Cluster

• 失败自动切换，当出现失败，重试其它服务器。(缺省)
• 一般用于读操做，但重试会带来更长延迟。
• 可经过retries="2"来设置重试次数(不含第一次)。

Failfast Cluster

• 快速失败，只发起一次调用，失败当即报错。
• 一般用于非幂等性的写操做，好比新增记录。

Failsafe Cluster

• 失败安全，出现异常时，直接忽略。
• 一般用于写入审计日志等操做。

Failback Cluster

• 失败自动恢复，后台记录失败请求，定时重发。
• 一般用于消息通知操做。

Forking Cluster

• 并行调用多个服务器，只要一个成功即返回。
• 一般用于实时性要求较高的读操做，但须要浪费更多服务资源。
• 可经过forks="2"来设置最大并行数。

Broadcast Cluster

• 广播调用全部提供者，逐个调用，任意一台报错则报错。(2.1.0开始支持)
• 一般用于通知全部提供者更新缓存或日志等本地资源信息。

 

 

2. 负载均衡策略

Random LoadBalance

• 随机，按权重设置随机几率。
• 在一个截面上碰撞的几率高，但调用量越大分布越均匀，并且按几率使用权重后也比较均匀，有利于动态调整提供者权重。

RoundRobin LoadBalance

• 轮循，按公约后的权重设置轮循比率。
• 存在慢的提供者累积请求问题，好比：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，长此以往，全部请求都卡在调到第二台上。

LeastActive LoadBalance

• 最少活跃调用数，相同活跃数的随机，活跃数指调用先后计数差。
• 使慢的提供者收到更少请求，由于越慢的提供者的调用先后计数差会越大。

ConsistentHash LoadBalance

• 一致性Hash，相同参数的请求老是发到同一提供者。
• 当某一台提供者挂时，本来发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引发剧烈变更。
• 算法参见：http://en.wikipedia.org/wiki/Consistent_hashing。
• 缺省只对第一个参数Hash，若是要修改，请配置<dubbo:parameter key="hash.arguments" value="0,1" />
• 缺省用160份虚拟节点，若是要修改，请配置<dubbo:parameter key="hash.nodes" value="320" />

 

 

3. 静态服务

有时候但愿人工管理服务提供者的上线和下线，此时需将注册中心标识为非动态管理模式。

服务提供者初次注册时为禁用状态，需人工启用，断线时，将不会被自动删除，需人工禁用。

 

4. 服务分组

当一个接口有多种实现时, 能够用group区分

 

5. 多版本

当一个接口实现，出现不兼容升级时，能够用版本号过渡，版本号不一样的服务相互间不引用。

• 在低压力时间段，先升级一半提供者为新版本
• 再将全部消费者升级为新版本
• 而后将剩下的一半提供者升级为新版本

 

6. 分组聚合

按组合并返回结果，好比菜单服务，接口同样，但有多种实现，用group区分，如今消费方需从每种group中调用一次返回结果，合并结果返回，这样就能够实现聚合菜单项.

 

7. 泛化引用:

泛接口调用方式主要用于客户端没有API接口及模型类元的状况，参数及返回值中的全部POJO均用Map表示，一般用于框架集成，好比：实现一个通用的服务测试框架，可经过GenericService调用全部服务实现。

 

8. 泛化实现:

泛接口实现方式主要用于服务器端没有API接口及模型类元的状况，参数及返回值中的全部POJO均用Map表示，一般用于框架集成，好比：实现一个通用的远程服务Mock框架，可经过实现GenericService接口处理全部服务请求。

 

9. 回声测试:

回声测试用于检测服务是否可用，回声测试按照正常请求流程执行，可以测试整个调用是否通畅，可用于监控。

全部服务自动实现EchoService接口，只需将任意服务引用强制转型为EchoService，便可使用。

 

10. 异步调用:

基于NIO的非阻塞实现并行调用，客户端不须要启动多线程便可完成并行调用多个远程服务，相对多线程开销较小。

 

11. 参数回调:

参数回调方式与调用本地callback或listener相同，只须要在Spring的配置文件中声明哪一个参数是callback类型便可，Dubbo将基于长链接生成反向代理，这样就能够从服务器端调用客户端逻辑。

 

12. 事件通知:

在调用以前，调用以后，出现异常时，会触发oninvoke, onreturn, onthrow三个事件，能够配置当事件发生时，通知哪一个类的哪一个方法。

 

13. 本地存根:

远程服务后，客户端一般只剩下接口，而实现全在服务器端，但提供方有些时候想在客户端也执行部分逻辑，好比：作ThreadLocal缓存，提早验证参 数，调用失败后伪造容错数据等等，此时就须要在API中带上Stub，客户端生成Proxy实，会把Proxy经过构造函数传给Stub，而后把Stub 暴露组给用户，Stub能够决定要不要去调Proxy。

 

14. 本地假装:

Mock一般用于服务降级，好比某验权服务，当服务提供方所有挂掉后，客户端不抛出异常，而是经过Mock数据返回受权失败。

Mock是Stub的一 个子集，便于服务提供方在客户端执行容错逻辑，因常常须要在出现RpcException(好比网络失败，超时等)时进行容错，而在出现业务异常(好比登 录用户名密码错误)时不须要容错，若是用Stub，可能就须要捕获并依赖RpcException类，而用Mock就能够不依赖 RpcException，由于它的约定就是只有出现RpcException时才执行。

 

15. 并发控制:

可控制客户端, 服务端并发执行的个数

 

16. 链接控制:

可控制服务端接受的链接数, 限制客户端使用的链接数

 

17. 延迟链接:

只对dubbo长链接有效, 只有当调用发起时, 再建立长链接

 

18. 粘滞链接:

粘滞链接用于有状态服务，尽量让客户端老是向同一提供者发起调用，除非该提供者挂了，再连另外一台。

 

19. 令牌验证:

    防止消费者绕过注册中心访问提供者

    在注册中心控制权限，以决定要不要下发令牌给消费者

    注册中心可灵活改变受权方式，而不需修改或升级提供者

20. 路由规则:

    条件路由规则, 几个有用的示例:

 

1) 排除预发布机：

=> host != 172.22.3.91

2) 白名单：(注意：一个服务只能有一条白名单规则，不然两条规则交叉，就都被筛选掉了)

host != 10.20.153.10,10.20.153.11 =>

3) 黑名单：

host = 10.20.153.10,10.20.153.11 =>

4) 服务寄宿在应用上，只暴露一部分的机器，防止整个集群挂掉：

=> host = 172.22.3.1*,172.22.3.2*

5) 为重要应用提供额外的机器：

application != kylin => host != 172.22.3.95,172.22.3.96

6) 读写分离：

method = find*,list*,get*,is* => host = 172.22.3.94,172.22.3.95,172.22.3.96

method != find*,list*,get*,is* => host = 172.22.3.97,172.22.3.98

7) 先后台分离：

application = bops => host = 172.22.3.91,172.22.3.92,172.22.3.93

application != bops => host = 172.22.3.94,172.22.3.95,172.22.3.96

8) 隔离不一样机房网段：

host != 172.22.3.* => host != 172.22.3.*

9) 提供者与消费者部署在同集群内，本机只访问本机的服务：

=> host = $host

 

21. 配置规则:

可动态的向注册中心写入动态配置覆盖规则.

 

22. 服务降级:

 

• 消费方对该服务的方法调用都直接返回null值，不发起远程调用。

屏蔽不重要服务不可用时对调用方的影响。

• 或者消费方对该服务的方法调用在失败后，再返回null值，不抛异常。

容忍不重要服务不稳定时对调用方的影响。

 

23. 优雅停机:

原理：

• 服务提供方
  • 中止时，先标记为不接收新请求，新请求过来时直接报错，让客户端重试其它机器。
  • 而后，检测线程池中的线程是否正在运行，若是有，等待全部线程执行完成，除非超时，则强制关闭。
• 服务消费方
  • 中止时，再也不发起新的调用请求，全部新的调用在客户端即报错。
  • 而后，检测有没有请求的响应尚未返回，等待响应返回，除非超时，则强制关闭。

设置优雅停机超时时间，缺省超时时间是10秒：(超时则强制关闭)

 

24. 服务容器:

服务容器是一个standalone的启动程序，由于后台服务不须要Tomcat或JBoss等Web容器的功能，若是硬要用Web容器去加载服务提供方，增长复杂性，也浪费资源。