概述
在前一期文章中，我介绍了微服务的概念及其由来。简而言之，微服务是将复杂的单体应用拆分成细粒度的服务，独立部署，并由各个中小团队负责开发、测试、上线和运维。
那么，什么时候应该拆分单体应用？拆分单体应用的标准是什么？
为了解答这些问题，今天我将通过具体案例进行阐述，希望帮助你掌握单体应用拆分成微服务的正确方法。
什么时候进行服务化拆分？
根据我经历的多个项目来看，项目的第一阶段主要是快速开发和验证想法，证明产品思路是否可行。这个阶段的功能设计通常不会太复杂，开发方式也以快速迭代为主，架构不宜过度设计。因此，将所有功能打包在一起，集中进行开发、测试和运维，是起步阶段最高效、最节省成本的方式。当可行性验证通过后，可以逐步增加新特性。
例如，开发一个社交应用，初期为了快速上线并验证可行性，可以只开发首页信息流和评论等基本功能。产品上线后，随着用户逐渐增多，下一阶段需要增加更多新特性来吸引用户，如添加个人主页显示和消息通知功能。
在这个阶段，通常需要扩展开发团队以支持多个功能的开发。如果继续采用单体应用架构，不同功能模块混杂在一起开发、测试和部署，会导致功能之间相互影响，一次打包部署需要所有功能测试通过才能上线。
此外，多个功能模块混合部署也会对线上服务的稳定性构成挑战。例如，某个功能代码上线后产生内存泄漏，运行一段时间后导致进程异常退出，进而影响所有功能的可用性。一个典型案例是某视频应用，因为短时间内某个付费视频访问量巨大，超过服务器承载能力，导致全站几乎崩溃。
根据我的经验，当单体应用的开发人员超过10人时，就应该考虑进行服务化拆分。
服务化拆分的两种方法
服务化拆分可以通过以下两种方式实施：
纵向拆分：按照业务维度进行拆分。例如，将社交应用的首页信息流、评论、消息通知和个人主页分别拆分为独立的服务。标准是按照业务的关联程度来决定，关联较紧密的业务适合拆分为一个微服务，功能相对独立的业务适合单独拆分为一个微服务。
横向拆分：按照公共且独立功能维度进行拆分。例如，无论是首页信息流、评论、消息通知还是个人主页，都需要显示用户昵称。如果将用户昵称功能单独部署为一个独立服务，那么有变更时只需上线该服务即可，其他服务不受影响，开发和上线成本大大降低。
-
服务化拆分的前置条件
引入新技术必然会带来架构复杂度的提升，在决策之前，需要认识到新架构可能带来的问题，并考虑如何解决。以下是从单体应用迁移到微服务架构时必须解决的问题：
服务定义：单体应用中不同功能模块通常通过类库方式提供功能，而微服务则通过接口（HTTP或RPC）进行调用。
服务发布和订阅：单体应用中的接口调用属于进程内调用，拆分为微服务后，需要有一个注册中心记录每个服务提供者的地址供调用者查询。
服务监控：需要一种通用的监控方案覆盖业务埋点、数据收集、数据处理和数据展示。
服务治理：拆分为微服务后，服务数量增加，依赖关系变复杂。需要设定调用性能阈值，超过阈值时进行熔断等服务治理手段。
在解决这些问题后，才能进一步进行服务化拆分。
总结
无论是纵向拆分还是横向拆分，都是将单体应用的功能进行拆分，抽离成独立的服务部署。但功能拆分并不是越细越好，过度拆分会导致服务数量膨胀，难以管理。找到适合自己业务现状和团队技术水平的拆分粒度才是最重要的。建议每个开发人员负责不超过3个大的服务。