如何把项目改成微服务项目_微服务拆分那点事

Mar. 19th 2018 BY 王保平 [email protected]

背景

最近参与了两个项目的开发，两个项目都有多组件，各自服务功能清晰等特点，也就是所谓的微服务，再结合以前的一些单体项目的开发经验，这里主要探讨一下我所理解的微服务和单体项目的优缺点。

fig1 Microservice Architecture

我的理解

其实所谓这些服务的拆分与否都是与很多因素有关系，比如：该项目的开发人员数目，该项目的运维敏感度，项目的紧急程度，开发人员的技术熟练程度，微服务架构的基础储备程度等等。

因为我们的最终目的是将项目快速完整的实现好，而不是为了显得逼格高而微服务，不是为了人多每人分点活，而故意拆成微服务。总之不能为了微服务而微服务。

比如该项目总工就一个人开发，然后该项目你重启一下服务，对用户接入没啥敏感性，本来就是个没有并发的对内系统，那就完全没必要拆成微服务，就写个单体的，把接入层，数据处理层等通过模块化的代码方式拆开就行了，没必要增加复杂度，加上一些 rpc，把一个单体服务拆成四五个微服务，然后增加自己的运维成本和实现成本。

如果该项目是多人协作的，有一定的并发度，对用户接入比较敏感，不能随便重启，并且开发者都对微服务有一定的经验，并且底层 rpc，连接池等初始化库都有积累，然后有比较丰富的 rpc 多服务运维经验，那就可以拆微服务，拆完之后，服务的水平扩展一