配置的覆盖规则
以 timeout 为例,下图显示了配置的查找顺序,其它 retries, loadbalance, actives 等类似:
- 方法级优先,接口级次之,全局配置再次之。
- 如果级别一样,则消费方优先,提供方次之。
其中,服务提供方配置,通过 URL 经由注册中心传递给消费方。
其余的配置信息,以及dubbo的功能,可以通过查看dubbo官网的文档。http://dubbo.apache.org/zh-cn/docs/user/quick-start.html
在 Provider 端尽量多配置 Consumer 端属性
原因如下:
- 作服务的提供方,比服务消费方更清楚服务的性能参数,如调用的超时时间、合理的重试次数等
- 在 Provider 端配置后,Consumer 端不配置则会使用 Provider 端的配置,即 Provider 端的配置可以作为 Consumer 的缺省值 。否则,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 端属性有:
timeout
:方法调用的超时时间retries
:失败重试次数,缺省是 2loadbalance
:负载均衡算法,缺省是随机random
。还可以配置轮询roundrobin
、最不活跃优先leastactive
和一致性哈希consistenthash
等actives
:消费者端的最大并发调用限制,即当 Consumer 对一个服务的并发调用到上限后,新调用会阻塞直到超时,在方法上配置dubbo:method
则针对该方法进行并发限制,在接口上配置dubbo:service
,则针对该服务进行并发限制
详细配置说明请参考:Dubbo配置参考手册。
在 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 端属性有:
threads
:服务线程池大小executes
:一个服务提供者并行执行请求上限,即当 Provider 对一个服务的并发调用达到上限后,新调用会阻塞,此时 Consumer 可能会超时。在方法上配置dubbo:method
则针对该方法进行并发限制,在接口上配置dubbo:service
,则针对该服务进行并发限制
配置管理信息
目前有负责人信息和组织信息用于区分站点。以便于在发现问题时找到服务对应负责人,建议至少配置两个人以便备份。负责人和组织信息可以在运维平台 (dubbo Ops) 上看到。
在应用层面配置负责人、组织信息:
<dubbo:application owner=”ding.lid,william.liangf” organization=”intl” />
在服务层面(服务端)配置负责人:
<dubbo:service owner=”ding.lid,william.liangf” />
在服务层面(消费端)配置负责人:
<dubbo:reference owner=”ding.lid,william.liangf” />
若没有配置服务层面的负责人,则默认使用 dubbo:application
设置的负责人。
配置 dubbo 缓存文件
提供者列表缓存文件:
<dubbo:registry file=”${user.home}/output/dubbo.cache” />
注意:
该文件会缓存注册中心列表和服务提供者列表。配置缓存文件后,应用重启过程中,若注册中心不可用,应用会从该缓存文件读取服务提供者列表,进一步保证应用可靠性。
监控配置
-
使用固定端口暴露服务,而不要使用随机端口
-
使用 Dubbo Admin 监控服务在注册中心上的状态,确保注册中心上有该服务的存在。
-
服务提供方可使用 dubbo Qos 的 telnet 或 shell 监控项
监控服务提供者端口状态:
echo status | nc -i 1 20880 | grep OK | wc -l
,其中的 20880 为服务端口 -
服务消费方可通过将服务强制转型为 EchoService,并调用
$echo()
测试该服务的提供者是可用如
assertEqauls(“OK”, ((EchoService)memberService).$echo(“OK”));
不要使用 dubbo.properties 文件配置,推荐使用对应 XML 配置
dubbo 中所有的配置项都可以配置在 Spring 配置文件中,并且可以针对单个服务配置。
如完全不配置则使用 dubbo 缺省值,详情请参考 Dubbo配置参考手册 中的说明。
dubbo.properties 中属性名与 XML 的对应关系
-
应用名
dubbo.application.name
<dubbo:application name="myalibaba" >
-
<dubbo:registry address="11.22.33.44:9090" >
-
可以在多个配置项设置超时
timeout
,由上至下覆盖(即上面的优先)[5],其它的参数(retries
、loadbalance
、actives
等)的覆盖策略与timeout
相同。示例如下:提供者端特定方法的配置
<dubbo:service interface="com.alibaba.xxx.XxxService" > <dubbo:method name="findPerson" timeout="1000" /> </dubbo:service>
提供者端特定接口的配置
<dubbo:service interface="com.alibaba.xxx.XxxService" timeout="200" />
-
服务提供者协议
dubbo.service.protocol
、服务的监听端口dubbo.service.server.port
<dubbo:protocol name="dubbo" port="20880" />
-
服务线程池大小
dubbo.service.max.thread.threads.size
<dubbo:protocol threads="100" />
-
消费者启动时,没有提供者是否抛异常
alibaba.intl.commons.dubbo.service.allow.no.provider
<dubbo:reference interface="com.alibaba.xxx.XxxService" check="false" />
分包
建议将服务接口、服务模型、服务异常等均放在 API 包中,因为服务模型和异常也是 API 的一部分,这样做也符合分包原则:重用发布等价原则(REP),共同重用原则(CRP)。
如果需要,也可以考虑在 API 包中放置一份 Spring 的引用配置,这样使用方只需在 Spring 加载过程中引用此配置即可。配置建议放在模块的包目录下,以免冲突,如:com/alibaba/china/xxx/dubbo-reference.xml
。
粒度
服务接口尽可能大粒度,每个服务方法应代表一个功能,而不是某功能的一个步骤,否则将面临分布式事务问题,dubbo 暂未提供分布式事务支持。
服务接口建议以业务场景为单位划分,并对相近业务做抽象,防止接口数量爆炸。
不建议使用过于抽象的通用接口,如:Map query(Map)
,这样的接口没有明确语义,会给后期维护带来不便。
版本
每个接口都应定义版本号,为后续不兼容升级提供可能,如: <dubbo:service interface="com.xxx.XxxService" version="1.0" />
。
建议使用两位版本号,因为第三位版本号通常表示兼容升级,只有不兼容时才需要变更服务版本。
当不兼容时,先升级一半提供者为新版本,再将消费者全部升为新版本,然后将剩下的一半提供者升为新版本。
兼容性
服务接口增加方法,或服务模型增加字段,可向后兼容,删除方法或删除字段,将不兼容,枚举类型新增字段也不兼容,需通过变更版本号升级。
各协议的兼容性不同,参见:服务协议
枚举值
如果是完备集,可以用 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 类来完成检验。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。