如果做微服务了 这个模块怎么去划分？

还是高内聚 低耦合的一个思想吧 ，单一职责的设计原则，也是一个封装的思想吧，

业务维度：

​ 按照业务的关联程度来决定，关联比较密切的业务适合拆分为一个微服务，而功能相对比较独立的业务适合单独拆分为一个微服务。用户模块，订单模块，视频点播模块。

业务复杂和足够的人力的角度：没有足够复杂到 2~3 个人没法维护的地步，没必要继续将商品服务拆的更细。划分太多，因为人力的不足导致更多的问题，如研发效率大幅下降。

避免环形依赖与双向依赖:

​ 尽量不要有服务之间的环形依赖或双向依赖，原因是存在这种情况说明我们的功能边界没有划分清楚或者有通用的功能没有下沉下来。

独立功能维度：

​ 且依赖的资源独立不与其他业务耦合。比如网关模块，日志服务、监控服务

稳定性维度：

​ 将系统中的业务模块按照稳定性进行排序。稳定的、不经常修改的划分一块；将不稳定的，经常修改的划分为一个独立服务。比如日志服务、监控服务都是相对稳定的服务，可以归到一起。这个很类似上面提到的2/8原则，80%的业务是稳定的。

高性能维度：

把对性能要求较高的模块独立成一个服务，对性能要求不高的放在一起。比如全文搜索，商品查询和分类，秒杀就属于高性能的核心模块。

---

多种方面去考虑**，主要还是以业务维度去考虑吧 也需要考虑公司团队成员人数**。拆分后的维护成本要低于拆分前。

真的没有绝对的标准，只有合理才是标准。

扩展：

弓箭原理:

平衡拆分粒度可以从两方面进行权衡，一是业务发展的复杂度，二是团队规模的人数。如上图，它就像弓箭一样，只有当业务复杂度和团队人数足够大的时候，射出的服务拆分粒度这把剑才会飞的更远，发挥出最大的威力。

三个火枪手原则: 一种开发的建议

3个人写一个微服务

• 3 个人负责开发一个系统，系统的复杂度刚好达到每个人都能全面理解整个系统。

• 3 个人可以形成一个稳定的备份，即使 1 个人休假或者调配到其他系统，

• 3 个人的技术小组既能够形成有效的讨论，又能够快速达成一致意见