之前讲解了什么是微服务：微服务的核心在于服务治理，微服务架构是将复杂臃肿的单体应用进行细粒度的服务化拆分，每个拆分出来的服务各自独立打包部署，并交由小团队进行开发和运维，从而极大地提高了应用交付的效率。

什么时候进行服务化拆分？拆分单体应用有哪些标准呢？

什么时候进行服务化拆分？

比如做社交 App，初期为了快速上线，验证可行性，可以只开发首页信息流、评论等基本功能。产品上线后，经过一段时间的运营，用户开始逐步增多，可行性验证通过，下一阶段就需要进一步增加更多的新特性来吸引更多的目标用户，比如再给这个社交 App 添加个人主页显示、消息通知等功能。

这个时候就需要大规模地扩张开发人员，以支撑多个功能的开发。如果这个时候继续采用单体应用架构，多个功能模块混杂在一起开发、测试和部署的话，就会导致不同功能之间相互影响，一次打包部署需要所有的功能都测试 OK 才能上线。而且，多个功能模块混部在一起，对线上服务的稳定性也是个巨大的挑战。

再例举一个 58 到家的例子，随着业务越来越复杂，数据量越来越大，并发量越来越大，15 年的时候，58 到家的架构碰到了种种问题：

• 垂直业务扩展，家政、丽人、速运、平台，一些相似的业务代码拷贝越来越严重
• 数据量、并发量提升，底层架构复杂性不断向上游扩散，所有调用方都需要关注缓存、分库、存储引擎等，效率逐步降低
• jar 包耦合，多个系统依赖一个公用的 jar 包，一个业务升级导致兼容性问题，影响其他业务
• 数据库耦合，多个业务公用一个数据库，相互耦合，相互影响
• SQL 质量低，业务相互耦合，一个业务编写了一个低质量的 SQL，导致其他业务受影响

这个时候 58 到家开始进行服务化拆分，找到通用痛点，抽象出通用数据访问与子业务，然后将它们下沉成微服务。

一般来说，一旦单体应用同时进行开发的人员超过 10 人，就会遇到上面的问题，这个时候就该考虑进行服务化拆分了。

服务化拆分的两种姿势

那么服务化拆分具体该如何实施呢？一个最有效的手段就是将不同的功能模块服务化，独立部署和运维。以前面提到的社交 App