2.3 业务服务化带来的效益

1.提升代码复用率

项目体系变大和架构变复杂后，系统难免会分模块，甚至分组件。但是模块之间、组件之间还是有大量的代码重复。

2.消除依赖爆炸

各组件之间如果不经过抽取公共层来屏蔽直接依赖和调用，将会造成依赖爆炸，给运维、升级带来巨大的工作量。

3.缓解持久层压力

没有服务化，持久层自然要面对更多上层的直接压力，缓存只能起到缓冲的作用，没有命中的缓存将会导致整个底层库受影响，进而影响其他系统用户。

4.降低维修难度

正是由于上述的几个问题，在系统出问题时定位问题就比较困难，修改一个微小的地方，轻则需要重新发布、重启系统，重则程序崩溃、服务下线，直接造成重大经济损失。

5.开发团队分工更明确

用一个上百人的团队去维护同一份代码，相信没有人愿意干这样的事情。

正是基于以上的这些亟待解决的痛点，单体架构的服务化改造变得非常有必要，同时，服务化也是从领域建模发展到微服务架构的过渡性产物。

限界上下文的划分是为了更好地管理业务单元，让业务具有高内聚、低耦合的特性，因为业务是经常变化的，要尽量封装这种变化，不让其影响周边业务。服务化刚好能起到这种作用，内部封装、对外提供接口、业务之间的调用可以通过企业服务总线ESB、消息队列MQ、REST API以及其他RPC方式来完成。

服务化的过程涉及三个角色，如图2-9所示，包括服务提供者、服务消费者、服务管理者。

图2-9 参与服务化的三个角色