官方文档:http://dubbo.io/User+Guide-zh.htm
A、服务配置相关
1、启动检查:
原理:Dubbo缺省会在启动时检查依赖的服务是否可用,不可用时会抛出异常,阻止Spring初始化完成,能及早发现问题,但是有些时候还是需要设置为false,测试的时候服务不一定有那边全
用途:测试使用false,上线使用true防止出现问题
2、线程模型:服务端可以配置Dispatcher和ThreadPool,调整负载
3、只订阅:提供有些服务禁用注册配置,这样测试中注册的服务不会被现网调用
4、服务版本号:版本兼容,提供同一版本的调用,为了多版本兼容
5、服务分组:隔离各个组的服务
6、服务多注册中心:可以同时注册到多个中心
7、同一服务提供多个中心,一个服务可以提供多种协议
8、延迟暴露服务,主要防止初始化没有完成的时候对外提供服务
<
dubbo:service
delay
=
"5000"
/> 延迟5秒暴露服务
<
dubbo:service
delay
=
"-1"
/> 延迟到Spring初始化完成后,再暴露服务
9、可以限制每个服务的并发限制,也可以限制方法
<
dubbo:service
interface
=
"com.foo.BarService"
executes
=
"10"
/> 服务器端并发执行(或占用线程池线程数)不能超过10个
10、服务连接控制,现在服务器器端接受的连接
11、令牌验证,从安全考虑防止直接连接
12、服务降级:通过管理界面提供初选问题后如何服务降低
13、优雅停机:
<
dubbo:application
...>
<
dubbo:parameter
key
=
"shutdown.timeout"
value
=
"60000"
/>
<!-- 单位毫秒 -->
</
dubbo:application
>
设置优雅停机超时时间,缺省超时时间是10秒:(超时则强制关闭)
14、粘滞连接 <dubbo:protocol name="dubbo" sticky="true" />
B、注册中心
1、注册中心中zookeeper本身就支持比较简单,也是常用的解决方案
2、使用redis作为注册中心的设计理念不错,虽然现网没有使用。文章看上去有点拗口,整理一个时序图如下:
c、总结
dubbo总体来说设计的非常好,路由,负载均衡、线上线下服务的升级都考虑的很周全,但分布式事务支持的不好。用什么都要用一段时间仔细品味,才能温故而知新。