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

根据我的实际项目经验，一旦单体应用同时进行开发的人员超过 10 人，就会遇到上面的问题，这个时候就该考虑进行服务化拆分了。

服务化拆分的两种姿势

• 纵向拆分, 不同功能, 业务
• 横向拆分, 被多个服务依赖, 独立

服务化拆分的前置条件

下面几个问题，是从单体应用迁移到微服务架构时必将面临也必须解决的。

• 服务如何定义. 接口描述
• 服务如何发布和订阅. 注册中心
• 服务如何监控. 监控方案
  • QPS
  • AvgTime
  • P999
• 服务如何治理. 熔断
• 故障如何定位. 请求标记, 串联请求路径

精选留言

oddrock

我现在对拆分的考量：
一是业务维度聚类，业务和数据关系密切的应该放在一起。
二是功能维度聚类，公共功能聚合为一个服务。
三是人员聚类，这是个实际中的考量，如果某几个业务就是这几个人比较熟，那么最好放在一起，未来开发部署都好办。
四是性能聚类，性能要求高的并发大的和性能要求低的并发小的，要分开为不同的服务，这样部署和运行都独立，好维护。
还请老师指教

作者回复: 总结的很好，看得出来属于业务经验很丰富的。😁

技术修行者

关于服务拆分策略，我理解在实际工作中应该是横向和纵向相结合的方式:
1. 首先收集整理公用的模块，将其进行服务化处理，这是横向拆分。
2. 其次根据不同业务之间的耦合程度，将相对独立的服务拆分到不同的服务中，这属于纵向拆分。

最后的微服务列表中，既有被其他微服务使用的公共服务，也有彼此独立运行的业务服务。

作者回复: 对，实际业务中这两种拆分方式一般是相互结合使用的，如果业务比较多分散，适合做纵向拆分。如果多个业务之间有公共模块耦合，适合把公共模块拆分出来，适合做横向拆分。

jogin

看评论感觉好多人不需要微服务。
1.业务复杂度问题单体应用没能梳理清楚，微服务也搞不懂定。
2.人手太少，微服务只会增加系统复杂度，运维成本，大家不要看到把原先的函数调用改成接口调用，没真正了解服务拆分后带来的系统复杂度。
3.系统设计问题，代码写的乱，开发流程问题，不是微服务能解决的。

作者回复: 对，微服务只能解决单体膨胀后的痛，但也会带来架构复杂性，要权衡利弊

明天更美好

我们是单体应用，一共22个接口，但是有一个接口并发巨大，二期势必拆分微服务架构。我觉得按照功能进行垂直拆分比较合适，我们之前有17个开发人员，现在裁员就剩下4个。希望胡老师给个建议

作者回复: 4个人搞微服务，有没有基础架构人员？没有就算了吧……

Geek_8d2caa

开始是10多人的团队，对业务进行了拆分，上线后，人员陆续离职，现在是6个人背着将近30个微服务，开发一个功能点，基本上所有人都得上，就演变成天天开会还解决不了问题，效率奇低……所以，有没有微服务退回到单体的做法？

作者回复: 可以适当做服务合并