服务化的目标：

• 将系统中独立的业务模块抽取出来，按业务的独立性进行垂直划分，抽象出基础服务层。

• 基础服务为上游业务的功能实现提供支撑，基础服务应用本身无状态，可随着系统的负荷灵活伸缩来提供服务能力。

• 服务子系统的数量把控

过多： . 可能划分过细，破坏业务子系统的独立性（如：支付订单、退款订单，用户、账户） . 部署维护工作量大，独立进程占用内存多

过少： . 没能很好的解耦 . 开发维护不好分工 . 升级维护影响面大

• 服务子系统划分注意事项：

• 不要出现A服务中的SQL需要链接查询到B服务中的表等情况，

• 这样在A服务与B服务进行垂直拆库时就会出错

• 服务子系统间避免出现环状的依赖调用

• 服务子系统间的依赖关系链不要过长

• 尽量避免分布式事务

服务子系统的划分是一个不断优化的过程

接口类型

接口粒度：

• 服务接口尽可能大粒度，每个服务方法应代表一个功能，而不是某功能的一个步骤，否则将面临分布式事务问题，Dubbo暂未提供分布式事务支持。同时可以减少系统间的网络交互。

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

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

接口版本：

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

接口兼容性：

• 服务接口增加方法，或服务模型增加字段，可向后兼容；

• 删除方法或删除字段，将不兼容，枚举类型新增字段也不兼容，

• 需通过变更版本号升级。

异常处理：

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

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

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

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

必要的接口输入参数校验

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

原因如下：

作服务的提供者，比服务使用方更清楚服务性能参数，如调用的超时时间，合理的重试次数，等等 在Provider配置后，Consumer不配置则会使用Provider的配置值，即Provider配置可以作为Consumer的缺省值。否则，Consumer会使用Consumer端的全局设置，这对于Provider不可控的，并且往往是不合理的。

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

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

样例：

服务接口设计与服务子系统划分过程相互优化

集群容错模式

标签：
      
       、
       
        、      
        
         、
         
        
       
      

       或：
       或：
       
        
       

2、Failfast Cluster

      或：
      

3、Failsafe Cluster

      或：
      

4、Failback Cluster

5、Forking Cluster

      或：
      

启动时检查