我们公司落地微服务架构已多年，而我也接触开发了一段时间了。恰好，最近又抽空把《微服务设计》一书随手翻了一遍，便有了抒写此文的念头，虽然文中所述并非具有很强的普适性，倒也权当自己近来的总结和思考罢了。
我想对于许多初始接触微服务开发的人员来说，都会或多或少有这样的疑问
在探讨这些问题之前，我们不妨先问自己：什么才算是好的服务？
坦率地讲，这个问题与微服务无关，我们不妨抽象在一个更高层面去思考：什么代码才算好的代码？我想很多人都会脱口而出：高内聚、低耦合。
没错，而这两个原则也是微服务的根基，如果做不到这两点，那么微服务的价值也就无从体现了。
试想一下，服务提供者对于有多少服务消费者在使用是无感知的（虽然我们可以通过注册中心得知，但是意义不大，我们也并不关心），假设服务提供者的某个服务要做调整导致所有的消费者都需要连带调整，这是一件非常麻烦，也非常让人难以接受的事情。
低耦合
在微服务架构中，很重要的一点就是，在设计的时候，应尽可能的少知道协作者的信息，独立修改和部署服务而不需要其他服务同步修改。
高内聚
把相关的行为都聚集在一个地方，不相关的放在别处。多处修改一方面比较麻烦，另一方面，多处修改多处部署风险也会相对更高。
在谨记两条原则的基础上，我们便可以带着疑惑进入到我们的下一个问题中去，也就是前文所提到的，「微服务应该如何划分」？
限定上下文
在《领域驱动设计》中，有一个比较重要的概念----限定上下文。
在初次看到这个概念时，觉得非常的晦涩，但是随着在业务中的思考，这种概念变得清晰起来。我们不妨将限定上下文拆分成两个单词来看，「限定」+「上下文」。
限定指的是某个范围或者环境中，比如在商品这个系统中。而上下文可以理解为语境。总结起来似乎可以这么理解：针对共同定义的某个模型，在不同的系统中有不同范围的属性；或者这么说，在对内和对外而言，虽然服务提供者需要暴露某些数据（共享模型），但是针对不同的业务，并非需要将所有的数据都暴露出去。
举个更加清晰的例子而言，比如我们需要将商品作为一个服务划分出去，那么服务消费者所看到和我们内部系统所使用的是不同的，或者说，我们只会向外部共享他们所需要的，而我们内部表示并不共享，否则如果有朝一日内部有所调整，那么就必然影响到了服务消费者。
因此，我们需要思考的点在于，共享特定模型，而不要共享内部表示，避免高耦合。
值得一提的是，当我们在划分服务时，需要注意的是我们面临的是什么功能，而不是单纯的只考虑共享数据出去，否则极容易陷入贫血的误区。
粒度
当我们在划分设计时，有时候也会陷入过早划分的误区。一开始就把微服务划分的比较明细虽然并不是一件坏事，但是总会造成前期开发成本大的局面。
我们在设计时，我更倾向于由粗到细的过程，然而，在这个过程中也会出现两种情况，比如嵌套式和完全分离的区别
这两种划分方式的选择更多的取决于你公司的架构，如果说它们是不同团队在维护，那么完全分离更合适，如果是一个团队维护，那么嵌套式更为合适。
欢迎关注我的公众号，每周至少一篇比较有深度的原创文章：