内容来自《持续演进的 Cloud Native》
每个产品在实施微服务架构最初的动力都不一样，目标也有所区别，所以判断是否划分合理，首先要看是否达成了目标。其次，可以参考以下几种衡量方式。每种衡量方式不能单独作为一个判断标准，需要综合考虑。
一个小功能的修改从需求到上线需要多长时间？正常情况下的微服务架构交付周期应该是以天为单位的。如果一个小功能的修改需要几周到几个月的时间，可能意味着服务划分粒度过大，存在太多的冲突，要等待合并代码。
大多数功能修改是否可以在一个服务内完成？如果经常需要跨服务团队的联合开发组才能完成一个新功能的开发或者旧功能的修改，则说明服务划分存在问题。
是否要频繁修改接口？频繁修改接口有可能是接口设计不合理导致的，也有可能是服务划分的问题导致的，说明服务之间的边界并不是特别明确和稳定。
响应时间是否能满足要求？在某些追求极致性能的场景中，对响应时间要求较高，服务划分的层次太多、粒度太小都可能导致响应时间不能满足要求。
是否存在大量的跨服务更新？是否存在大量的跨服务的关联查询？出现这两个问题，可能是因为划分不合理。