微服务之如何建模微服务

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

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

松耦合

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

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

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

高内聚

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

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

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

2.限界上下文

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

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

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

2.1 共享的隐私模型

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

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

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

2.2 模块和服务

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

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

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

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

3.业务功能

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

4.逐步划分上下文

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

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

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

5.关于业务概念的沟通

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

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

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

6.技术边界

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

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

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

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

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

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

7.小结

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

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

 

posted @ 2019-09-03 23:32 Vincent-yuan 阅读(...) 评论(...) 编辑 收藏