入门 - 架构
节点角色说明
| 节点 | 角色说明 |
|---|---|
Provider |
暴露服务的服务提供方 |
Consumer |
调用远程服务的服务消费方 |
Registry |
服务注册与发现的注册中心 |
Monitor |
统计服务的调用次数和调用时间的监控中心 |
Container |
服务运行容器 |
调用关系说明
- 服务容器负责启动，加载，运行服务提供者。
- 服务提供者在启动时，向注册中心注册自己所需的服务
- 服务消费者在启动时，想注册中心订阅自己所需的服务
- 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
- 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
- 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
Dubbo架构具有以下几个特点，分别是连通性、健壮性、伸缩性，以及向未来架构的升级性。
连通性
- 注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小。
- 监控中心负责统计各服务调用次数，调用时间等，统计先在内存中汇总后每分钟一次发送到监控中心服务器，并以报表展示。
- 服务提供者向注册中心注册其提供的服务器，并汇报调用时间到监控中心，此时间不包括网络开销。
- 服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间包括网络开销。
- 注册中心、服务提供者、服务消费者三者之间均为长连接，监控中心除外
- 注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者。
- 注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表
- 注册中心和监控中心都是可选的，服务消费者可以直连服务提供者。
健壮性
- 监控中心宕掉不影响使用，只是丢失部分采样数据
- 数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务
- 注册中心对等集群 ，任意一台宕掉后，将自动切换到另一台
- 注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯。
- 服务提供者无状态，任意一台宕掉后，不影响使用
- 服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复
伸缩性
- 注册中心为对等集群，可动态增加机器部署实例，所有客户端将自动发现新的注册中心
- 服务提供者无状态，可动态增加机器部署实例，注册中心将推送新的服务提供者信息给消费者。
升级性
当服务集群规模进一步扩大，带动T治理结构进一步升级，需要实现动态部署，进行流动计算，现有分布式服务架构不会带来距离。下面是未来可能的一种架构：
节点角色说明
| 节点 | 角色说明 |
|---|---|
Deployer |
自动部署服务的本地代理 |
Repository |
仓库用于存储服务应用发布包 |
Scheduler |
调度中心基于访问压力自动增减服务提供者 |
Admin |
统一管理控制台 |
Registry |
服务注册与发现的注册中心 |
Monitor |
统计服务的调用次数和调用时间的监控中心 |
Zookeeper 注册中心
流程说明：
- 服务提供者启动时: 向
/dubbo/com.foo.BarService/providers目录下写入自己的 URL 地址 - 服务消费者启动时: 订阅
/dubbo/com.foo.BarService/providers目录下的提供者 URL 地址。并向/dubbo/com.foo.BarService/consumers目录下写入自己的 URL 地址 - 监控中心启动时: 订阅
/dubbo/com.foo.BarService目录下的所有提供者和消费者 URL 地址。
支持以下功能：
- 当提供者出现断电等异常停机时，注册中心能自动删除提供者信息
- 当注册中心重启时，能自动恢复注册数据，以及订阅请求
- 当会话过期时，能自动恢复注册数据，以及订阅请求
- 当设置
- 可通过
- 可通过
- 支持
*号通配符
可靠性声明
阿里内部并没有采用 Zookeeper 做为注册中心，而是使用自己实现的基于数据库的注册中心，即：Zookeeper 注册中心并没有在阿里内部长时间运行的可靠性保障，此 Zookeeper 桥接实现只为开源版本提供，其可靠性依赖于 Zookeeper 本身的可靠性。
兼容性声明
因 2.0.8 最初设计的 zookeeper 存储结构不能扩充不同类型的数据，2.0.9 版本做了调整，所以不兼容，需全部改用 2.0.9 版本才行，以后的版本会保持兼容 2.0.9。2.2.0 版本改为基于 zkclient 实现，需增加 zkclient 的依赖包，2.3.0 版本增加了基于 curator 的实现，作为可选实现策略。
建议使用 2.3.3 以上版本的 zookeeper 注册中心客户端
Redis 注册中心
使用 Redis 的 Key/Map 结构存储数据结构：
- 主 Key 为服务名和类型
- Map 中的 Key 为 URL 地址
- Map 中的 Value 为过期时间，用于判断脏数据，脏数据由监控中心删除
使用 Redis 的 Publish/Subscribe 事件通知数据变更：
- 通过事件的值区分事件类型：register, unregister, subscribe, unsubscribe
- 普通消费者直接订阅指定服务提供者的 Key，只会收到指定服务的 register, unregister 事件
- 监控中心通过 psubscribe 功能订阅 /dubbo/*，会收到所有服务的所有变更事件
调用过程：
- 服务提供方启动时，向
Key:/dubbo/com.foo.BarService/providers下，添加当前提供者的地址 - 并向
Channel:/dubbo/com.foo.BarService/providers发送register事件 - 服务消费方启动时，从
Channel:/dubbo/com.foo.BarService/providers订阅register和unregister事件 - 并向
Key:/dubbo/com.foo.BarService/consumers下，添加当前消费者的地址 - 服务消费方收到
register和unregister事件后，从Key:/dubbo/com.foo.BarService/providers下获取提供者地址列表 - 服务监控中心启动时，从
Channel:/dubbo/*订阅register和unregister，以及subscribe和unsubsribe事件 - 服务监控中心收到
register和unregister事件后，从Key:/dubbo/com.foo.BarService/providers下获取提供者地址列表 - 服务监控中心收到
subscribe和unsubsribe事件后，从Key:/dubbo/com.foo.BarService/consumers下获取消费者地址列表
Redis 是一个高效的 KV 存储服务器
从 2.1.0 版本开始支持
Redis 过期数据通过心跳的方式检测脏数据，服务器时间必须同步，并且对服务器有一定压力，否则过期检测会不准确
Telnet 命令参考手册
从 2.0.5 版本开始，dubbo 开始支持通过 telnet 命令来进行服务治理。
使用
telnet localhost 20880
或者：
echo status | nc -i 1 localhost 20880
status命令所检查的资源也可以扩展，参见：扩展参考手册。
命令
以下展示了 dubbo 内建的 telnet 命令的说明和用法，此外，telnet 命令还支持用户自行扩展，参见：Telnet 命令扩展。
ls
-
ls: 显示服务列表 -
ls -l: 显示服务详细信息列表 -
ls XxxService: 显示服务的方法列表 -
ls -l XxxService: 显示服务的方法详细信息列表
ps
-
ps: 显示服务端口列表 -
ps -l: 显示服务地址列表 -
ps 20880: 显示端口上的连接信息 -
ps -l 20880: 显示端口上的连接详细信息
cd
-
cd XxxService: 改变缺省服务，当设置了缺省服务，凡是需要输入服务名作为参数的命令，都可以省略服务参数 -
cd /: 取消缺省服务
pwd
-
pwd: 显示当前缺省服务
trace
-
trace XxxService: 跟踪 1 次服务任意方法的调用情况 -
trace XxxService 10: 跟踪 10 次服务任意方法的调用情况 -
trace XxxService xxxMethod: 跟踪 1 次服务方法的调用情况 -
trace XxxService xxxMethod 10: 跟踪 10 次服务方法的调用情况
count
-
count XxxService: 统计 1 次服务任意方法的调用情况 -
count XxxService 10: 统计 10 次服务任意方法的调用情况 -
count XxxService xxxMethod: 统计 1 次服务方法的调用情况 -
count XxxService xxxMethod 10: 统计 10 次服务方法的调用情况
invoke
-
invoke XxxService.xxxMethod({"prop": "value"}): 调用服务的方法 -
invoke xxxMethod({"prop": "value"}): 调用服务的方法(自动查找包含此方法的服务)
select
-
select 1: 当 invoke 命令匹配到多个方法时使用，根据提示列表选择需要调用的方法
status
-
status: 显示汇总状态，该状态将汇总所有资源的状态，当全部 OK 时则显示 OK，只要有一个 ERROR 则显示 ERROR，只要有一个 WARN 则显示 WARN -
status -l: 显示状态列表
log
-
log debug: 修改 dubbo logger 的日志级别 -
log 100: 查看 file logger 的最后 100 字符的日志
help
-
help: 显示 telnet 命帮助信息 -
help xxx: 显示xxx命令的详细帮助信息
clear
-
clear: 清除屏幕上的内容 -
clear 100: 清除屏幕上的指定行数的内容
exit
- exit`: 退出当前 telnet 命令行
shutdown
-
shutdown: 关闭 dubbo 应用 -
shutdown -t 1000: 延迟 1000 毫秒关闭 dubbo 应用
服务化最佳实践
分包
建议将服务接口、服务模型、服务异常等均放在 API 包中，因为服务模型和异常也是 API 的一部分，这样做也符合分包原则：重用发布等价原则(REP)，共同重用原则(CRP)。
如果需要，也可以考虑在 API 包中放置一份 Spring 的引用配置，这样使用方只需在 Spring 加载过程中引用此配置即可。配置建议放在模块的包目录下，以免冲突，如：com/alibaba/china/xxx/dubbo-reference.xml。
粒度
服务接口尽可能大粒度，每个服务方法应代表一个功能，而不是某功能的一个步骤，否则将面临分布式事务问题，Dubbo 暂未提供分布式事务支持。
服务接口建议以业务场景为单位划分，并对相近业务做抽象，防止接口数量爆炸。
不建议使用过于抽象的通用接口，如：Map query(Map)，这样的接口没有明确语义，会给后期维护带来不便。
版本
每个接口都应定义版本号，为后续不兼容升级提供可能，如：
建议使用两位版本号，因为第三位版本号通常表示兼容升级，只有不兼容时才需要变更服务版本。
当不兼容时，先升级一半提供者为新版本，再将消费者全部升为新版本，然后将剩下的一半提供者升为新版本。
兼容性
服务接口增加方法，或服务模型增加字段，可向后兼容，删除方法或删除字段，将不兼容，枚举类型新增字段也不兼容，需通过变更版本号升级。
各协议的兼容性不同，参见：服务协议
枚举值
如果是完备集，可以用Enum，比如：ENABLE, DISABLE。
如果是业务种类，以后明显会有类型增加，不建议用Enum，可以用String代替。
如果是在返回值中用了Enum，并新增了Enum值，建议先升级服务消费方，这样服务提供方不会返回新值。
如果是在传入参数中用了Enum，并新增了Enum值，建议先升级服务提供方，这样服务消费方不会传入新值。
序列化
服务参数及返回值建议使用 POJO 对象，即通过setter, getter方法表示属性的对象。
服务参数及返回值不建议使用接口，因为数据模型抽象的意义不大，并且序列化需要接口实现类的元信息，并不能起到隐藏实现的意图。
服务参数及返回值都必须是传值调用，而不能是传引用调用，消费方和提供方的参数或返回值引用并不是同一个，只是值相同，Dubbo 不支持引用远程对象。
异常
建议使用异常汇报错误，而不是返回错误码，异常信息能携带更多信息，并且语义更友好。
如果担心性能问题，在必要时，可以通过override掉异常类的fillInStackTrace()方法为空方法，使其不拷贝栈信息。
查询方法不建议抛出checked异常，否则调用方在查询时将过多的try...catch，并且不能进行有效处理。
服务提供方不应将 DAO 或 SQL 等异常抛给消费方，应在服务实现中对消费方不关心的异常进行包装，否则可能出现消费方无法反序列化相应异常。
调用
不要只是因为是 Dubbo 调用，而把调用try...catch起来。try...catch应该加上合适的回滚边界上。
Provider 端需要对输入参数进行校验。如有性能上的考虑，服务实现者可以考虑在 API 包上加上服务 Stub 类来完成检验。