首先，照惯例，先给答案：
微服务粒度有三个重要参考指标：
1、业务复杂度。
2、团队规模。
3、数据规模。
开始论证：
我们看一个简单的cms（内容发布）系统的生命周期。
阶段一：没流量，刚开始做。
业务需求：后台能人工发文章、视频，用户能看。
核心架构诉求：设计好库表，完成功能即可。
微服务？不用，单体应用即可。
阶段二：平台发展不错，100万pv了，内容发布流程也开始强管控了，功能高频迭代。
业务需求：各种新功能层出不穷。系统能抓取他站内容，用户也能发文章，发的文章，要人工介入审批；平台具备支付打赏功能；平台具备评论，盖楼功能；
核心架构诉求：业务开始复杂，研发团队也到了10人规模，服务如何划分使得服务功能聚焦，人员职责聚焦，从而降低服务互相影响，提升业务迭代效率。
关键tips：此时设计核心考量指标以业务发展为主，各领域划分清楚，要有些前瞻性，同时又不能YY的太远（未来说不准）。
至于怎么定义出打赏、评论、文章这些服务出来的，看看领域驱动设计（抽空我也发篇关于这个的文章），微服务是概念，领域驱动设计则是很好的一个方法论。
阶段三：1000万pv了，波峰上万qps。
业务需求：精细化体验，与其他平台各种换量，细化需求很多，跟竞对各种卷；
核心架构诉求：
确认什么是核心流程，将核心流程进行服务及存储剖离，同时做一定的性能扩展。
人员基本也50+了，把靠谱或者有潜力的人放在核心服务链路上，逐渐培养，半年内基本就全链路稳定了。
关键tips：此时设计核心参考指标就要综合人和事两方面来看了，事的话划分清楚核心链路，同时将靠谱的人扑在核心链路的服务上，不建议核心服务超过3人维护。
阶段四：几十亿pv，上百万qps了。
业务需求：好多...；
核心架构诉求：存储瓶颈，流量专项治理。
一套代码，布署多个服务？比如大V的流量，服务进行独立布署。
分布式存储，冷热数据，数据地域性存储。
关键tips：性能、稳定才是王道，如有必要，单个接口都能拆成一个服务，同时更多的要结合存储来看方案。
最后有一个总结，性能上的问题，要优先于业务发展考虑，而服务化，可以在业务发展确定后再做（即上面第二步晚点服务化也没关系）。
