《微服务设计》第 3 章　如何建模服务

• 2019 年 10 月 8 日
• 筆記

3.1　MusicCorp简介

3.2　什么样的服务是好服务

• 我希望你专注在两个重要的概念上：松耦合和高内聚
• 如果这两点做不到，那么微服务也就没什么价值了

3.2.1　松耦合

• 使用微服务最重要的一点是，能够独立修改及部署单个服务而不需要修改系统的其他部分，这真的非常重要
• 一个松耦合的服务应该尽可能少地知道与之协作的那些服务的信息

3.2.2　高内聚

• 最好能够只在一个地方进行修改，然后就可以尽快地发布
• 在多个不同的地方进行修改会很慢，同时部署多个服务风险也很高，这两者都是我们想要避免的

3.3　限界上下文

• 限界上下文的定义是：“一个由显式边界限定的特定职责。”（http://blog.sapiensworks.com/post/2012/04/17/DDD-The-Bounded-Context-Explained.aspx）如果你想要从一个限界上下文中获取信息，或者向其发起请求，需要使用模型和它的显式边界进行通信。在这

3.3.1　共享的隐藏模型

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

3.3.2　模块和服务

• 然而对于一个新系统而言，可以先使用一段时间的单块系统，因为如果服务之间的边界搞错了，后面修复的代价会很大。所以最好能够等到系统稳定下来之后，再确定把哪些东西作为一个服务划分出去

3.3.3　过早划分

• 过早划分导致很多跨服务修改，这些修改的代价相当高

3.4　业务功能

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

3.5　逐步划分上下文

• 首先考虑比较大的、粗粒度的那些上下文，然后当发现合适的缝隙后，再进一步划分出那些嵌套的上下文
• 我见过有一种做法是，使这些嵌套的上下文不直接对外可见。对于外界来说，它们用的还是仓库的功能，但发出的请求其实被透明地映射到了两个或者更多的服务上

3.6　关于业务概念的沟通

• 微服务之间如何就同一个业务概念进行通信，也是一件很重要的事情
• 事实上，通信形式在整个组织范围内都非常重要

3.7　技术边界

• 洋葱架构，因为它有很多层，而且当纵切这些层次时，我只想哭

3.8　小结

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

书

• 《领域驱动设计》
• 《实现领域驱动设计》

工具

• SnapCI
• Go-CD