微服务拆分是做微服务架构很重要也很难的话题，很多时候，几个服务是合还是拆在设计团队内也很难达成共识。
当你纠结应该拆分和合并时我建议就先合并，等后面版本迭代需要时有必要再去做拆分。从系统发展的角度说，很多平台也都是从单体大应用、逐步拆分演化而来的，就像有位大牛说的那样，一开始就拆分的很好的微服务实践往往是失败的，成功的微服务平台都是在演化中迭代而来的。因为微服务拆分看似单个服务明确简单了，但服务间调用管理就麻烦很多，原来进程内函数调用、单数据库表查询连接及事务处理都不能用了，要用各种方法处理数据一致性问题。
微服务的拆分一般是从业务角度入手，然后考虑功能复用及团队成员情况做适合粒度的划分。评价拆分好坏的重要指标是拆分前开发维护成本<拆分后的开发维护成本，并且每个服务应该有3-10个人的团队来负责，人数太多容易指责不清，人数太少如果负责人有事请假不在出问题就找不到人了。