服务化-服务拆分

服务化的过程中必然会面对服务拆分的问题；拆分粒度太粗不能体现服务化的优势，拆分过细会导致各项成本过高；所以架构师在服务拆分时要权衡各方面的利弊根据当前情况做出最优解;以下内容是我们团队在使用dubbo的过程，根据实际情况考虑的服务拆分方式；

拆分考虑的因素

• 业务领域
• 上下层级调用关系
• 技术因素
• 成本

我们在拆分过程中充分考虑以上4个因素；特别是在业务领域方面有较多的争议；业务领域下可以继续分子领域，所以在实际方案设计过程中部分团队服务拆分太细；经过多次沟通后我们将部分模块合并为一个provider，因为拆分过细对我们会有如下问题：

• 目前我们数据库没有拆分(下阶段会根据个业务线拆库)，服务过细会增加数据库的连接数量
• 增加了运维成本
• 增加硬件成本

拆分原则

• 模块按照子业务领域和上下层级拆分
• 服务调用只能上层服务调用下层服务
• 禁止provider之间循环调用
• 相同层级的模块可以作为同一个服务对外发布
• 模块可以低成本的拆分为一个独立的provider

模型

                        ___Api
                       |
          ___Model_A-->|
          |            |___Impl
          |            
          |
          |              ___Api
          |             |
Proider-->|___Model_B-->|
          |             |
          |             |___Impl
          |              
          |             
          |____dubbo_provider.xml   

模型特点

• Model_A和Model_B必须是同一层级的模块，比如: 同为数据访问层或者同为业务服务层
• 对外仅提供各个model的Api
• 同一个服务可以发布多个模块,节省成本
• 服务调用只能是上层服务调用下层服务，从而避免服务循环调用
• 各Model可以低成本的拆分为独立的provider