《微服务设计》读书笔记（五）

如何把单块系统循序渐进地分解？

关键是接缝

1. 什么是接缝

1) 在《修改代码的艺术》，Michael Feathers定义了接缝的概念。

2) 从接缝处可以抽取相对独立的代码，对这部分代码的修改不会影响到系统的其它部分。

3) 这些被识别出的接缝可以成为服务的边界

4) 好的接缝；限界上下文、命名空间等

2. 如何找到接缝

1) 首先找到限界上下文

2) 创建包结构表示这些上下文

3) 把已有代码移动的相应的包里：

a. 利用现代IDE的重构功能

b. 利用测试捕获任何可能的破坏性修改

c. 过段时间，看哪些代码找到自己的位置，哪些没有找到自己的位置

d. 没有找到位置的代码很可能是我们遗漏掉的限界上下文

e. 同时利用工具（Structure 101）分析包之间的依赖关系。包的依赖关系应该和组织相匹配。

3. 从哪里下手

把哪部分代码抽取出来收益最大，而不是为了抽取而抽取。

要考虑的因素：

1) 改变的速度：抽离成一个可以自治的服务后，后期开发的速度将大大加快

2) 团队结构：将异地开发的代码独立出来，由异地团队独立负责

3) 安全：敏感的信息独立出来，单独做监控

4) 技术：新的语言

4. 对数据库的特殊处理

数据库是所有杂乱依赖的源头

1) 分离仓储层:

a. 把数据库映射相关的代码和功能代码放到同一个上下文；

b. 如果使用Hibernate的话，可以针对每个限界上下文写一个映射文件

要回答的问题：

a. 存在不同上下文的表之间有什么样的耦合？SchemaSpy可以用图形的形式展现表之间的依赖关系

b. 同一个表被不同的上下文使用，又该如何处理？

2) 打破外键关系

去掉外键关联，将约束从数据库移动到代码里

a. 去掉跨限界上下文的表的访问

b. 通过暴露API访问另一上下文里的数据，而不是直接 访问

c. 测试速度，看是否可以接受

d. 需要做：1）跨服务的一致性检查；2）周期性清理数据

3) 共享静态数据：有三个常见的方法

a. 为每一个包复制一份数据库。会有一致性问题。

b. 放到属性文件中，或者放到代码里的枚举里。仍然会有一致性问题（每个包都有自己的属性文件或枚举）。仍有一致性问题，但是修改属性文件或枚举会比修改数据库简单

c. 把这些静态数据放入一个单独的服务：考虑数据量、复杂性及相关的规则是否值得去做

大部分的情景，都可以放倒属性文件或者代码里的枚举来解决

4) 共享数据：多个跨限界上下文的表访问同一个数据

a. 把共享的数据创建一个新的包

b. 通过API访问新创建的包

这种情况的原因是领域模型的缺失。领域是在数据库中隐式地进行建模

5) 分离共享表

• 跨界上下文需要访问同一个表里的不同字段。这时需要分离该共享表，将不同的字段分离。

6) 重构数据库

参考书籍：Refactoring Databases, Scott J. Amber和Pramod J. Sadalage编写

逐步进行

a. 找到应用程序的接缝

b. 按照限界上下文对它们进行分组

c. 找到数据库的接缝，对数据库进行分离。问题：需要从不同的地方拿到数据，然后在内存中进行连接；会破坏事务完整性；

d. 先不考虑服务的分离。当对数据库的分离的效果满意后，再考虑对服务的分离。好处：可以随时选择回退或是继续进行，而不影响服务的任何消费者。

7) 事务边界

尽量避免一个业务操作发生在跨系统的单个事务中。分布式事务很容易出错，而且不利于扩展。

a. 通过重试和补偿达成最终一致性的方式，会使定位问题更加困难，而且有可能需要其它的补偿措施

需要保持一致性的场景，尽量避免把它们放在不同的地方。

8) 报告

a. 中央报告数据库：使用数据导出技术来周期性地把数据推送到报告数据库

b. 使用试图来构建一个单块报告程序的表结构

c. 基于状态改变时间来将事件导出到报告数据库中

对于报告，需要用到数据湖的架构。