转载：微服务拆分
这篇文章讲的太好了，生怕以后被删掉。转到我博文列表里把-。- 正文： 开发者在刚开始尝试实现自己的微服务架构时往往会产生一系列问题 ： 微服务到底应该怎么划分？ 一个典型的微服务到底应该有多微？ 如果做了微服务设计，最后真的会有好处吗？ 回答上面的问题需要首先了解微服务设计的逻辑，科学的架构设计应该通过一些输入并逐步推导出结果，架构师要避免凭空设计和“拍脑门”的做法。 解耦的单体应用和微服务系统在逻辑上是一样的。对于服务拆分的逻辑来说，先设计高内聚低耦合的领域模型，再实现相应的分布式系统是一种比较合适的方式。 服务的划分有一些基本的方法和原则，通过这些方法能让微服务划分更有操作性。最终在微服务落地实施时也能按图索骥，无论是对遗留系统改造还是全新系统的架构都能游刃有余。 微服务拆分的几个阶段 在开始划分微服务之前，架构师需要在大脑中有一个重要的认识：微服务只是手段，不是目的。 微服务架构是为了让系统变得更容易拓展、更富有弹性。在把单体应用变成靠谱的微服务架构之前，单体系统的各个模块应该是合理、清晰地。 也就是说，从逻辑上单体系统和微服务没有区别，某种理想情况下微服务只是把单体系统的各个模块分开部署了而已（最近流行的monorepo把多个服务的代码仓库以模块的形式组织到了一起，证明了这一点）。 大量的实践教训告诉我们，混沌的微服务架构，比解耦良好的单体应用会带来更多麻烦。