微服务笔记（二）：边界

上篇简单介绍了微服务，列举了单块应用和微服务的一些区别，之后又在网上阅读了别人写的一些微服务文章，对比之下感觉自己的归纳和文笔还是差的太远，以后还需多练。

既然要使用微服务，那就必须要考虑如何对整个系统进行分解，哪些功能应该放到一个服务中，哪些不应该，即确定微服务的边界。有人会觉得这个问题很头疼，无从下手，也有人会觉得这个很简单，但是分解后的服务不断出现各种问题，让后续的开发变得十分痛苦。

我认为找到边界是采用微服务架构的最基本前提，也是最有挑战的部分，在没有认清服务边界的情况下，不要轻易使用微服务，否则可能带来很多意想不到的问题和麻烦。

什么样的微服务边界是合适的？

了解面向对象设计的朋友应该对“单一职责原则”、“开闭原则”等基本原则都不陌生，这些原则在架构方面同样十分受用。架构的核心价值不在于使用多么先进或者NB的技术，而在于使系统具有高度可扩展性，从而灵活应对业务的不断变化，持续演进。有句话说的好，“架构不是设计出来的，而是演进出来的”。而扩展性的基础就是松耦合、高内聚，这是我们应该多花一些心思思考的地方。

松耦合

微服务之间应该是高度松耦合的，从而避免一个微服务中的问题扩散到整个系统。如何判断是不是松耦合，最直接的一点就是可以独立修改和部署一个服务而不影响系统其他部分，如果修改一个功能时不得不对系统其他部分也同时做出修改，那么就要反思服务的边界是不是有问题了。

松耦合的服务应尽可能避免暴露内部实现细节，因为暴露内部实现细节意味着服务的修改，可能会需要服务的消费方也要跟着修改。此外也应该避免存在多种服务间的调用方式，这样也会增加服务的耦合度。

高内聚

既然要避免修改一个服务的时候带来系统其它部分的修改，就要保证相关行为都放在一个服务内，这就是高内聚的核心，也即我们思考如何找到服务边界要考虑的核心问题。

前篇有说过，“一个微服务只专注于一种业务，遵循单一职责原则”，即微服务的专注，要确保专注，就不能有其他无关行为夹杂进来，也不能有自身相关行为偷溜到其他系统中，要准确的把握所有相关行为并牢牢地把它们拴在一起。

什么方法能找到微服务边界？

分层

很多应用都会采用分层架构，所以会有种划分微服务方案，就是直接将原来的分层作为系统分解的边界，分解出来的微服务各自负责一个层的工作。比如一个可能很多人见过的例子，就是把数据持久化层单独做成一个服务，它负责所有的数据库操作，带来的好处是业务开发只需关注业务模型，而不用考虑底层存储，有专门的团队对持久化服务进行迭代和优化，对业务模型和数据存储做适配，但是随之而来的问题是大部分业务的修改都需要该服务同时也跟着修改，新的业务需求需要业务开发团队和持久化服务开发团队进行大量沟通才能进行，服务针对某个业务作出修改后导致其他业务出现问题等等，所以系统虽然做了分解，但仍然是高耦合的，无法独立对一个服务随时进行修改和部署。

分割

如果说水平的分层作为服务边界不是一个好的选择，那么垂直分割又如何？通常一个良好的系统在开发时都会考虑用模块来组织代码，将不同的行为放在不同的模块中，比如订单模块、支付模块，如果设计得当，各个模块之间的耦合会相对较低，业务逻辑基本都是高内聚的，只是共用了一些非业务逻辑的代码，所以按照模块的边界来分割系统应该是不错的切入点。

领域驱动设计（DDD）

在QCon伦敦2016大会上，《领域驱动设计》一书的作者Eric Evans提出，使用领域驱动设计（DDD）概念减少微服务环境中通用语言的复杂性。Evans建议，将每个微服务设计成一个DDD限界上下文，这为系统内的微服务提供了一个逻辑边界，无论是功能，还是通用语言。

限界上下文（Bounded Context）为高内聚提供了很好的理论指导，它的核心就是将特定职责的相关行为控制在一个有显示边界的范围内，Evans的一个比喻非常形象：“细胞之所以会存在，是因为细胞膜定义了什么在细胞内，什么在细胞外，并且确定了什么物质可以通过细胞膜”。近年来微服务的兴起又为DDD提供了很好的应用场景，只要深入挖掘领域知识，识别出合理的上下文，就能合理拆分微服务。

不过我觉得领域驱动设计是一门需要长时间积累的学问，你需要和领域专家充分沟通，共同找出通用语言，逐步深入挖掘领域知识来对领域模型进行迭代，这是一个持续的过程，因此在初期对领域知识掌握有限的情况下，不应急着过早划分细粒度的上下文。比较好的方式是先找出粗粒度的上下文，循序渐进，随着领域知识的深入再逐步分解，这个过程可能是长期的，颇具挑战的，而且往往会走一些弯路、远路，但是随着领域知识的沉淀和经验的积累，最终总是能得出更加准确的上下文边界和模型的。

总结

微服务要求有低耦合、高内聚的边界，使用 DDD 的限界上下文作为微服务边界是一种很合理的方式，但是服务的拆分应随着领域知识的深入逐步迭代进行，不可操之过急。所以重点又落在了 DDD 上，这也是我一直以来最感兴趣的架构思想，待以后对 DDD 的精髓有了更深的理解再和大家进一步分享和交流。