2.3 业务服务化带来的效益

1.提升代码复用率

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

2.消除依赖爆炸

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

3.缓解持久层压力

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

4.降低维修难度

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

5.开发团队分工更明确

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

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

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

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

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