Dubbo 最佳实践，我整理了以下 9 点

点击上方蓝色字关注我们~

Dubbo服务化，在当前互联网后端开发中，大部分都使用了Dubbo。截止目前github dubbo上，star也将近3万，使用dubbo的公司数量也很可观，Dubbo确实也是一个比较不错的服务化框架。

下面整理比较不错的Dubbo服务化最佳实践 ，希望可以帮助我们少掉进一些坑，更好的使用Dubbo。

建议将服务接口，服务模型，服务异常等均放在 API 包中，因为服务模型及异常也是 API 的一部分，同时，这样做也符合 分包原则：

重用发布等价原则(REP)，共同重用原则(CRP)。

如果需要，也可以考虑在 API 包中放置一份 spring 的引用配置，这样使用方，只需在 spring 加载过程中引用此配置即可，配置建议放在模块的包目录下，以免冲突，如：

com/alibaba/china/xxx/dubbo-reference.xml。

在互联网公司开发的过程中，基本上也有一套开发规范，在这方面上也是有要求的，所以对于公共的服务接口、服务异常等，应该存放在公共的API包，这样有利于复用、减少系统交互之间的成本等。

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

服务接口建议 以 业务场景为单位划分，并对相近业务做抽象，防止接口数量爆炸 。

不建议使用过于抽象的通用接口，如： Map query(Map)，这样的接口没有明确语义，会给后期维护带来不便。

接口在设计的时候，要参考面向对象的基本原则，设计时就应该考虑其粒度，方便业务上的理解和扩展。

每个接口都应定义版本号，为后续不兼容 升级 提供可能，如： 

<dubbo:service interface="com.xxx.XxxService" version="1.0" />。

建议 使用两位版本号 ，因为第三位版本号通常表示兼容升级，只有不兼容时才需要变更服务版本。

当不兼容时，先升级一半提供者为新版本，再将消费者全部升为新版本，然后将剩下的一半提供者升为新版本。

接口升级在我们开发中也是非常常见的，新旧接口可能同时会存在，所以也存在兼容问题。使用版本号可以帮助我们过度接口的变更，以致达到平滑的上线。

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

各协议的兼容性不同，参见：  服务协议。

跟上面的接口版本升级相关，主要是为接口的兼容考虑，往往都是向后兼容：尽量多加接口方法而不删除或修改接口方法。

如果是完备集，可以用 Enum，比如：ENABLE, DISABLE。

如果是业务种类，以后明显会有类型增加，不建议用 Enum，可以用 String 代替。

如果是在返回值中用了 Enum，并新增了 Enum 值，建议先升级服务消费方，这样服务提供方不会返回新值。

如果是在传入参数中用了 Enum，并新增了 Enum 值，建议先升级服务提供方，这样服务消费方不会传入新值。

枚举非常常见，有时可能会增加类型或者删除类型，甚至修改类型。这样对我们服务的升级或者变更都会存在很大的问题，比如造成不兼容，可能丢失值或者抛出异常。一般在业务中尽量少用枚举作为参数或者返回值，而是用String代替。

服务参数及返回值建议 使用 POJO 对象 ，即通过 setter, getter 方法表示属性的对象。

服务参数及返回值不建议使用接口，因为数据模型抽象的意义不大，并且序列化需要接口实现类的元信息，并不能起到隐藏实现的意图。

服务参数及返回值都必须是 byValue 的，而不能是 byReference 的，消费方和提供方的参数或返回值引用并不是同一个，只是值相同，Dubbo 不支持引用远程对象。

序列化对象序列号建议生成唯一，或者为1L。这样可能在对象增加字段时造成序列化异常，从而造成服务调用异常，影响生产。(注意)

建议使用 异常汇报错误 ，而不是返回错误码，异常信息能携带更多信息，以及语义更友好。

如果担心性能问题，在必要时，可以通过 override 掉异常类的 fillInStackTrace() 方法为空方法，使其不拷贝栈信息。

查询方法不建议抛出 checked 异常，否则调用方在查询时将过多的 try...catch，并且不能进行有效处理。

服务提供方不应将 DAO 或 SQL 等异常抛给消费方，应在服务实现中对消费方不关心的异常进行包装，否则可能出现消费方无法反序列化相应异常。

不要只是因为是 Dubbo 调用，而把调用 try...catch 起来。 try...catch 应该加上合适的回滚边界上。

对于输入参数的校验逻辑在 Provider 端要有。

如有性能上的考虑，服务实现者可以考虑在 API 包上加上服务 Stub 类(本地存根)来完成检验。

9.1、在 Provider 上尽量多配置 Consumer 端属性

☉原因如 下：

• 作为服务的提供者，比服务使用方更清楚服务性能参数，如调用的超时时间，合理的重试次数，等等

• 在 Provider 配置后，Consumer 不配置则会使用 Provider 的配置值，即 Provider 配置可以作为 Consumer 的缺省值  1 。 否则，Consumer 会使用 Consumer 端的全局设置，这对于 Provider 不可控的，并且往往是不合理的

Provider 上尽量多配置 Consumer 端的属性，让 Provider 实现者一开始就思考 Provider 服务特点、服务质量的问题。

示例 ：

<dubbo:service interface="com.alibaba.hello.api.HelloService" version="1.0.0" ref="helloService"
    timeout="300" retry="2" loadbalance="random" actives="0"
/>

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

在 Provider 上可以配置的 Consumer 端属性有：

1.timeout 方法调用超时

2.retries 失败重试次数，缺省是 2

3.loadbalance 负载均衡算法，缺省是随机 random。 还可以有轮询 roundrobin、最不活跃优先 leastactive

4.actives 消费者端，最大并发调用限制，即当 Consumer 对一个服务的并发调用到上限后，新调用会 Wait 直到超时 在方法上配置 dubbo:method 则并发限制针对方法，在接口上配置 dubbo:service，则并发限制针对服务

9.2、Provider 上配置合理的 Provider 端属性

<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>

Provider 上可以配置的 Provider 端属性有：

1.threads 服务线程池大小;

2.executes 一个服务提供者并行执行请求上限，即当 Provider 对一个服务的并发调用到上限后，新调用会 Wait，这个时候 Consumer可能会超时。 在方法上配置 dubbo:method 则并发限制针对方法，在接口上配置 dubbo:service，则并发限制针对服务.

9.3、配置管理信息

目前有负责人信息和组织信息用于区分站点。 有问题时便于的找到服务的负责人，至少写两个人以便备份。

负责人和组织的信息可以在注册中心的上看到。 应用配置负责人、组织：

<dubbo:application owner=”ding.lid,william.liangf” organization=”intl” />

service 配置负责人：

<dubbo:service owner=”ding.lid,william.liangf” />

reference 配置负责人：

<dubbo:reference owner=”ding.lid,william.liangf” />

dubbo:service、dubbo:reference 没有配置负责人，则使用 dubbo:application 设置的负责人。

9.4、配置 Dubbo 缓存文件

提供者列表缓存文件：

<dubbo:registry file=”${user.home}/output/dubbo.cache” />

☉注 意：

1 、 文件的路径，应用 可以根据需要调整，保证这个文件不会在发布过程中被清除。

2、如果有多个应用进程注意不要使用同一个文件，避免内容被覆盖。

这个文件会缓存注册中心的列表和服务提供者列表。

有了这项配置后，当应用重启过程中，Dubbo 注册中心不可用时则应用会从这个缓存文件读取服务提供者列表的信息，进一步保证应用可靠性。

9.5、不要使用 dubbo.properties 文件配置，推荐使用对应 XML 配置

Dubbo 中所有的配置项都可以配置在 Spring 配置文件中，并且可以针对单个服务配置。

dubbo.properties 中属性名与 XML 的对应关系

1.应用名 dubbo.application.name

<dubbo:application name="myalibaba" >

2.注册中心地址 dubbo.registry.address

 <dubbo:registry address="11.22.33.44:9090" >

3.调用超时 dubbo.service.*.timeout

可以在多个配置项设置超时 timeout，由上至下覆盖（即上面的优先）5，其它的参数（retries、loadbalance、actives等）的覆盖策略也一样示例如下：

提供者端特定方法的配置

<dubbo:service interface="com.alibaba.xxx.XxxService" >
     <dubbo:method name="findPerson" timeout="1000" />
</dubbo:service>

4.服务提供者协议 dubbo.service.protocol、服务的监听端口 dubbo.service.server.port

<dubbo:protocol name="dubbo" port="20880" />

5.服务线程池大小 dubbo.service.max.thread.threads.size

<dubbo:protocol threads="100" />

6.消费者启动时，没有提供者是否抛异常 Fast-Fail alibaba.intl.commons.dubbo.service.allow.no.provider

<dubbo:reference interface="com.alibaba.xxx.XxxService" check="false" />

9.6、监控配置

1.使用 固定端口 暴露服务，而不要使用随机端口

这样在注册中心推送有延迟的情况下，消费者通过缓存列表也能调用到原地址，保证调用成功。

2.使用 Dragoon 的 http 监控项监控注册中心上服务提供方

Dragoon 监控服务在注册中心上的状态 ： http://dubbo-reg1.hst.xyi.cn.alidc.net:8080/status/com.alibaba.morgan.member.MemberService:1.0.5 确保注册中心上有该服务的存在。

3.服务提供方，使用 Dragoon 的 telnet 或 shell 监控项

监控服务提供者端口状 态： echo status | nc -i 1 20880 | grep OK | wc -l，其中的 20880 为服务端口

4.服务消费方，通过将服务强制转型为 EchoService，并调用 $echo() 测试该服务 的提供者是可用

如 assertEqauls(“OK”, ((EchoService)memberService).$echo(“OK”));

在dubbo服务化后端的开发，最佳实践可以更好的指导我们进行相关的业务开发。

对于现实使用中，我们可能会存在没有按照相关规范，或者可能是开发人员没有注意到或者不关心接口的升级或者变更、枚举类型的使用、序列化、异常的处理等，没有做到前后兼容、异常合适处理等，从而等到上线之后才发现原来之前没有在这方面考虑的比较周全，所以也造成了线上事故，或者发版延期等问题，这对我们开发人员也是 非常不利 。

所以我们应该要在这方面能够更加的重视，有了最佳实践，也是因为有人踩了坑，或者在这方面非常熟练知道这些潜在的问题，可以更好的指导我们，帮助 我们 尽可能避免踩坑。

如果你对Dubbo服务化最佳 实践这方面有所见识，或者曾经遇到了一些坑，欢迎你留言评论，大家一起探讨，一起进步吧。

【其它最佳实践】

》  R ocketMQ最佳实践

》 Kafka的20项最佳优化实践