微服务之如何建模微服务

1.什么样的服务是好的微服务？

它应该具备这两个特点：松耦合、高内聚

松耦合：

如果做到了服务之间的松耦合，那么修改一个服务就不需要修改另外一个服务了。使用微服务最重要的一点是，能够独立修改和部署单个服务而不需要修改系统的其他部分，这一点非常重要。

那么相对的什么是紧耦合呢？使用紧耦合来做服务之间的集成，会使的一个服务的修改致使其消费者的修改。

一个松耦合的服务应该尽可能少的知道与之协作的那些服务的信息。

高内聚：

我们希望把相关的行为聚集在一起，把不相关的行为放在别处。

因为如果你要改变某个行为的话，最好能够只在一个地方进行修改，然后就可以快速发布。如果你同时需要很多地方做修改，那么就可能同时发布多个微服务才能完成这个功能。这样的话，修改会变慢，部署服务的工作量和风险也会增大。

这就需要找到问题域的边界，从而确保相关的行为能放在同一个地方，并且它们会和其他边界以尽量松耦合的形式进行通信。

2.限界上下文

Eric Evans 的 《领域驱动设计》中，曾提到这个概念。

他认为，任何一个给定的领域都包含多个限界上下文，每个限界上下文中的模型分成两部分，一部分不需要与外部通信，另一部分则需要。

每个上下文都有明确的接口，该接口决定了它会暴露哪些模型给其他上下文。

2.1 共享的隐私模型

例如，对于MusicCorp来说，财务部门和仓库就可以是两个独立的限界上下文。它们都有明确的对外接口(存货报告，工资单等)，也都有着只需要自己知道的一些细节(铲车,计算器等)。

因为，财务部的雇员需要库存信息，所以库存项就变成了两个上下文之间的共享模型。但是我们不会把库存项在仓库模型中的所有内容都暴露出去。

很多情况下，这种情况就会导致是否要采用REST的讨论了。(因为这种情况也可以是REST方式。)

2.2 模块和服务

在单块系统中，一旦你发现了领域内部的限界上下文，一定要使用模块对其进行建模，同时使用共享和隐藏模型。

这些模块边界就可以成为绝佳的微服务候选。一般来讲，微服务应该清晰的和限界上下文保持一致。熟练之后，就可以省掉在单块系统中先使用模块的这个步骤，而直接使用单独的服务。

总结：微服务边界要和限界上下文保持一致。

在开始使用微服务的时候，过早的将一个系统划分成为微服务的代价非常高，尤其是面对新领域时。很多时候，将一个已有的代码库划分成微服务，要比从头开始构建微服务要简单的多。

3.业务功能

当你在思考组织内的限界上下文时，不应该从共享数据的角度来考虑，而应该从这些上下文能够提供的功能来考虑。

4.逐步划分上下文

一开始你会识别出一些粗粒度的限界上下文，而这些限界上下文可能又包含一些嵌套的限界上下文。

另外，组织结构和软件架构会相互影响。

另一个倾向于嵌套式方法的原因是，它可以使的架构更成块，从而更好的测试。

5.关于业务概念的沟通

微服务之间如何就同一个业务概念进行通信，也是一件很重要的事情。

以跟组织内通信相同的方式，来思考微服务之间的通信形式是非常有用的。

事实上，通信形式在整个组织范围内都非常重要。

6.技术边界

举个例子，一个系统被划分为两部分，一部分面向前端，该部分不保存任何状态；后端部分就是一个简单的数据存储，通过RPC（Remote Procedure Call,远程过程调用）来提供服务。

基本上，你可以理解为，把一个代码库中的仓储层变成一个独立的服务。

我们把这种架构称为洋葱架构，因为它有很多层。

在这个例子中，并不是按照业务进行的垂直划分，而是把原来进程内部的API水平划分了出去。

按照技术接缝(指不同技术)划分的服务边界进行建模也并不总是错误的。

但是，一般来讲，这不应该成为你考虑的首要方式。

7.小结

在这篇文章中，你学到了什么是好的微服务，以及如何在问题空间中寻找能达到高内聚低耦合的接缝。

限界上下文是寻找这些接缝的一个非常重要的工具，通过将微服务和这些边界相匹配，可以保证最终的系统能够得到微服务提供的所有好处。