dubbo基础和开发规范

基本概念

最重要的3个

  • Provider 服务提供着
  • Consumer 服务消费者
  • Registry 注册中心,服务提供者注册服务的地方,服务消费者获取可用服务的地方

两个web应用

  • Admin 服务管理,治理,一个web项目,可对各服务进行管理控制,路由,参数配置,负载均衡等。
  • Monitor 监控,RPC调用次数和调用时间监控

一些自己摸索的开发原则

模块划分

一个Provider包含如下模块

  • domain 对应数据库表格
  • dao 和原dao功能一样,使用spring data,大部分情况,仅需定义接口即可
  • biz 和原biz一样
  • api 包含api-domain(request, response, 即接口的参数和返回值), 和service接口定义, 作为给Consumer引用的jar包, api不可引用biz, dao, domain,service任意jar包
  • service 和原service一样,但不包含service接口
    引用关系图如下
    1
    2
    service---api
    |---------biz----dao---domain

注意事项

  • Service, 使用Autowire注解, 被注入字段必须写set方法, xml中定义bean时,需要加上autowire=”byType”(或许时配置问题,寻求解决办法)
  • Dubbo 对外提供的Rpc服务,所有用到的请求返回参数,即com.simpletour.blog.api.*.domain 下的POJO,都需要implement Serializable (考虑添加Base对象)

Consumer

jar包引用

Consumer只能引用api包,对于其他service, biz, dao, domain都不可引用,保证Consumer不会直接调用底层未暴露的接口和domain

配置

Consumer基本是存在于rest或web项目中,建议只配置dubbo必须的配置

1
2
3
4
5
6
   <dubbo:registry address="zookeeper://localhost:2181" />

<dubbo:application name="dubbo-comsumer"/>

<!-- 扫描注解包路径,多个包用逗号分隔,不填pacakge表示扫描当前ApplicationContext中所有的类 -->
<dubbo:annotation package="com.simpletour.blog.rest.api.controller"/>

而对于Provider的引用使用注解的方式
即:

1
2
@Reference(version = "1.0.0")
IBlogService blogService;

和原来相比,仅将@Resource 替换成@Reference

Consumer若为rest服务

  • rest对外提供的接口中用到的pojo,单独一个protocal jar包, 思路同dubbo Provider中的api包,以便rest调用者为web服务时,不需再次定义pojo对象
    此时Consumer包含protocal, rest两个模块
    jar包引用关系图如下
    1
    2
    Consumer---api
    |----------protocal

因此最终打包之后,Consumer中不应该存在Provider中,除api以外的任意jar包(domain, dao, biz, service)

一些官方的开发原则(http://dubbo.io/User+Guide-zh.htm)

分包

建议将服务接口,服务模型,服务异常等均放在API包中,因为服务模型及异常也是API的一部分,

粒度

服务接口尽可能大粒度,每个服务方法应代表一个功能,而不是某功能的一个步骤,否则将面临分布式事务问题,Dubbo暂未提供分布式事务支持。
服务接口建议以业务场景为单位划分,并对相近业务做抽象,防止接口数量爆炸
不建议使用过于抽象的通用接口,如:Map query(Map),这样的接口没有明确语义,会给后期维护带来不便。

版本

每个接口都应定义版本号,为后续不兼容升级提供可能,如:<dubbo:service interface="com.xxx.XxxService" version="1.0" />
建议使用两位版本号,因为第三位版本号通常表示兼容升级,只有不兼容时才需要变更服务版本。
当不兼容时,先升级一半提供者为新版本,再将消费者全部升为新版本,然后将剩下的一半提供者升为新版本。

兼容性

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

枚举值

如果是完备集,可以用Enum,比如:ENABLE, DISABLE。
如果是业务种类,以后明显会有类型增加,不建议用Enum,可以用String代替。
如果是在返回值中用了Enum,并新增了Enum值,建议先升级服务消费方,这样服务提供方不会返回新值。
如果是在传入参数中用了Enum,并新增了Enum值,建议先升级服务提供方,这样服务消费方不会传入新值。

序列化

服务参数及返回值建议使用POJO对象,即通过set,get方法表示属性的对象。
服务参数及返回值不建议使用接口,因为数据模型抽象的意义不大,并且序列化需要接口实现类的元信息,并不能起到隐藏实现的意图。
服务参数及返回值都必需是byValue的,而不能是byRef的,消费方和提供方的参数或返回值引用并不是同一个,只是值相同,Dubbo不支持引用远程对象。

异常

建议使用异常汇报错误,而不是返回错误码,异常信息能携带更多信息,以及语义更友好,
如果担心性能问题,在必要时,可以通过override掉异常类的fillInStackTrace()方法为空方法,使其不拷贝栈信息,
查询方法不建议抛出checked异常,否则调用方在查询时将过多的try…catch,并且不能进行有效处理,
服务提供方不应将DAO或SQL等异常抛给消费方,应在服务实现中对消费方不关心的异常进行包装,否则可能出现消费方无法反序列化相应异常。

调用

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

推荐用法

  • 在Provider上尽量多配置Consumer端属性,服务的提供者,比服务使用方更清楚服务性能参数
  • Provider上配置合理的Provider端属性, threads,服务线程池大小, executes,一个服务提供者并行执行请求上限
  • 尽量不要使用重试,超时则返回错误,除非你可以保证你所写的方法是幂等的, 否则很容易导致数据出错(ydf补充)
文章目录
  1. 1. 基本概念
  2. 2. 一些自己摸索的开发原则
    1. 2.1. 模块划分
    2. 2.2. 注意事项
    3. 2.3. Consumer
      1. 2.3.1. jar包引用
      2. 2.3.2. 配置
      3. 2.3.3. Consumer若为rest服务
  3. 3. 一些官方的开发原则(http://dubbo.io/User+Guide-zh.htm)
    1. 3.1. 分包
    2. 3.2. 粒度
    3. 3.3. 版本
    4. 3.4. 兼容性
    5. 3.5. 枚举值
    6. 3.6. 序列化
    7. 3.7. 异常
    8. 3.8. 调用
    9. 3.9. 推荐用法
,