前言

最近几年微服务架构开始流行起来，单体应用在部署效率、开发成本、系统可用性方面不如微服务架构。那么单体应用如何向微服务架构转变呢，这里就需要服务化拆分。

服务化拆分

服务化拆分有两种方式：

拿个简单的社交网站为例，网站有首页内容模块，评论模块，主页模块和私信模块等。

纵向拆分：

纵向拆分就是按照业务来分，分为首页内容服务、评论服务、主页服务和信息服务。像这种功能比较独立的模块都分成服务。

横向拆分：

横向拆分是按照公共功能来拆分，标准是按照是否有公共的被多个其他服务调用，且依赖的资源独立。上面的网站中，首页内容模块、评论模块、主页模块都用到了用户信息，如果用户信息修改了需求，这些模块也都需要重新上线。如果将用户信息拆分出来，成为独立的服务。上线成本就降低了。

因地制宜

两种拆分方式已经介绍完了，但是怎样拆更适合公司里即将服务化的项目呢？

这里给出几点建议：

1. 可以考虑将两种拆分方式结合使用，首先整理公用的模块，将其服务化处理。接着根据业务耦合程度，将相对独立的模块拆分成服务。

2. 微服务架构在系统运维、问题追踪、分布式事务方面复杂度比单体应用高，如果系统开发人员较少，或者业务相对不复杂的项目，不建议服务化。微服务架构主要解决单体应用膨胀的问题。

3. 如果拆分出的服务太多以至于开发人员手忙脚乱，可考虑适当服务合并。

4. 即使没有服务化，单体应用在模块分配方面设计得好，以后项目服务化会更容易。

5. 如果不确定如何横向拆分，可以先纵向拆分，在项目发展一段时间后，看哪些功能是其他业务系统频繁调用的，抽离出来做服务化处理。

6. 业内架构师给出可参考的数据：10个开发人员参与的项目就适合服务化了。3个开发人员开发一个新服务。一个开发人员维护不超过 3 个微服务为宜。