一、分包
1、接口服务、请求服务模型(请求的bean和返回的bean的封装,最好能使用继承实现)、异常信息的封装(一般会定义每个服务自身的错误代码)都放在api(可参考dubbo的源码分包中各个模块的api),符合重用发布的等价原则和共同重用原则
2、api中最好防止spring的引用配置信息(最好使用dubbo默认的配置地址META-INF下),当然也可防止在provider项目中
二、粒度
1、尽量把接口设置成粗粒的,每个服务方法代表一个独立的功能,而不是某个功能的一部分,否则会引入分布式事物
2、服务接口建议以场景进行划分,并对相近的业务进行抽象,防止接口的暴增和防止后续需求变化而引起的重构
3、不建议使用过于抽象的通用接口,接口没有明确的语义,造成后续的维护麻烦
三、版本
1、每个接口都应该定义版本,为后续的兼容性提供前瞻性的考虑。(适应快速变更的需求,适应现在的快速迭代和持续交付)
2、建议使用两位版本号,因为第三位版本号表示兼容性升级,只有不兼容时候才变更服务版本
3、当接口做到不兼容升级的时候,先升级一半或者一台提供者为新版本,再进行全部升级(预发布或灰度发布)
四、推荐
1、在provider端尽可能的配置consumer端的属性(服务端更清楚服务的性能,业务设计等)
如:timeout,retries、线程池大小、负载均衡机制等
2、配置管理员信息
application中建议配置的owner建议配置两个以上(监控中心使用)
3、配置dubbo的缓存配置文件(增加可用性)
<dubbo:registry protocal="zookeeper" address="192.168.1.1:2181,192.168.1.2:2181" file=“/data/dubbo.cache” / >
缓存的信息包括,注册中心的列表和暴露服务的服务列表,当服务中心挂掉之后,只是新注册的服务受到影响,已经暴露的服务可正常使用