2同行回答
如果当前业务系统能支撑好多年的业务发展，建议还是求稳吧。
需要看清楚当期业务系统是否为敏态应用，是否需要经常变更版本。当期是否因为部分业务变更影响整个业务链条的正常交易。是否需要对部分服务进行动态扩展，做灰度发布等等。
业务系统如何拆分，拆分粒度多大这个问题很难回答。从业务上拆？从架构上拆？业务、架构一起考虑再拆？等等，粒度多大才合适也是个伪命题，拆的很细那后期维护难度会加大很多，毕竟应用个数多了，调用链路复杂了；拆得不够细，那后期部分业务更新可能影响范围还是比较大等等问题。
收起微服务和业务场景无关，什么时候使用微服务呢？当你的项目或者产品遇到如下问题：
1、 代码冲突加剧
多个人或者一个团队一起维护一个模块，共同开发。当提交代码的时候发现大量冲
突，每次提测或者发版的时候需要花大量的时间来解决冲突。 随 着团队规模的增大
以及项目复杂程度增加，代码冲突的现象越严重 ；
2 、 模块耦合严重
模块之间通过接口或者 DB 相互依赖，耦合越来越严重。而且不同的人，写代码的
风格不一样，代码质量也不一样，上线前需要协调多个团队，任何小模块的异常都
会导致整个项目发 布 失败；
3 、 项目质量下降
由于所有的代码都是在一个服务里面，做一次改动，可能会牵一发而动全身，代码
冲突以及耦合严重，导致测试覆盖范围不充分，经常会出现没有更改的模块在线上
突然出现问题，查询后发现是由于工程师不小心做了某种改动，但是测试用例并没
有覆盖；
4 、 团队效率下降
由于大量时间在处理代码冲突，消耗了研发人员大量的时间；而测试人员为了提高
项目质量，不得不在每次发版之前做全方位的回归测试，本身一次小的迭代结果项
目时间却很长；
此时就可以开展微服务了。实施过程中首要解决的就是服务拆分问题， 服务拆分是否合理直接影响到微服务架构的复杂性、稳定性以及可扩展性。服务拆分过小，会导致不必要的分布式事务产生，而且整个调用链过程也会变长，反之，如果服务拆分过大，会逐步演变为单体应用，不能发挥微服务的优势。判断一个服务拆分的好坏，就看微服务拆分完成后是否具备服务的自治原则，如果把复杂单体应用改造成一个一个松耦合式微服务，那么按照业务功能分解模式进行分解是最简单的，只需把业务功能相似的模块聚集在一起。比如：
ü 用户管理：管理用户相关的信息，例如注册、修改、注销或查询、统计等。
ü 商品管理：管理商品的相关信息。