Dubbo_服务化改造注意事项

一、分包

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

缓存的信息包括，注册中心的列表和暴露服务的服务列表，当服务中心挂掉之后，只是新注册的服务受到影响，已经暴露的服务可正常使用