微服务拆分如何平衡拆分粒度？

1、高内聚低耦合，服务粒度适中
2、以业务模型切入
3、演进式拆分
4、阶段性合并
总的原则: 拆分的大原则是当一块业务不依赖或极少依赖其它服务，有独立的业务语义，为超过 2 个的其他服务或客户端提供数据，那么它就应该被拆分成一个独立的服务模

关于这个问题，Spring Cloud Alibaba成员姬望（彭文杰）的一篇采访稿，可能对您有所帮助，核心的观点及段落内容如下：
微服务解决的本质问题是团队分工
SOA 也好、微服务也好，解决的根本问题是团队分工问题，详见康威定律，这是大型软件发展的必然，不因为人的喜好而改变。当你读懂康威定律，就会发现“服务拆分粒度难以准确把握”根本不是本质问题。 你有几个 2 pizza 团队，最好就拆成几个微服务。举一个现实的例子：只有一个开发人员时，尽量就做单体应用，不要没事找刺激拆成 10 个微服务，最终这个开发人员还会把他合成一个。微服务要求纵向的 2 pizza 团队（无数个小团队，包含开发、测试、运维），当然我们也实施过一些传统大型企业，但团队还是处在横向结构的场景下（开发、运维、测试各是一个团队），拆分微服务让他们很痛苦，尤其是运维团队。
这里面的概念可以网上查下，我个人觉得说的还是非常有道理的。我辖内的系统就经历了单体应用向微服务拆分的过程，拆分的背景是行内一个秒杀内的业务需要调用辖内系统应用，传统的架构性能不满足要求，故进行容器化改造，对此业务场景涉及的业务进行微服务拆分。乍看下来是业务驱动，但实际上这个系统的开发团队也因此做了拆分，安排专人服务微服务模块的开发、测试，运维方面暂未拆分。但是如果拆分的范围进一步扩大，运维团队拆分也是必然。