《微服务设计》，Building Microservices，作者Sam Newman，译者崔力强、张骏，人民邮电出版社，2016年。

笔记中有些内容直接引用原书。

================================================================

第五章分解单块系统

1.关键是接缝。Michael Feathers在《修改代码的艺术》一书中定义了接缝的概念。从接缝处可以抽取出相对独立的一部分代码，对这部分代码进行修改不会影响系统的其他部分。接缝即边界，前面说的限界上下文就是一个比较好的接缝。

2.分解MusicCorp。MusicCorp是书中举的一个例子。根据业务识别出高层限界上下文。创建包结构表示这些上下文，把对应的代码挪过去。分析包之间的依赖关系，要和组织架构相匹配。使代码围绕接缝组织起来。

3.分解单块系统的原因。要考虑分解的速度、团队结构、安全审计、某些特殊技术实现的功能单独形成一个服务等因素。

4.杂乱的依赖。

要使拉出来的接缝尽量少被其他组件依赖。

5.数据库。不要用数据库集成。找到数据库中的接缝，分离出来。

6.找到问题的关键。把数据库映射相关的代码和功能代码放在同一个上下文，根据业务来组织。另外，数据库表和表之间有约束，可以通过工具来可视化这些约束，如SchemaSpy(http://schemaspy.sourceforge.net)。

7.例子：打破外键关系。将对属于其它上下文的表的访问转变为对其服务的访问，放弃外键关联，如果需要可以将约束从数据库转移到代码。

8.例子：共享静态数据。像国家代码这种存在数据库的情况，可以用三种方法解决：每个包复制一份该表；这些共享静态数据放入代码（如属性文件或一个枚举），比数据库修改简单；静态数据放入一个单独的服务（有些极端）。推荐第二种。

9.例子：共享数据。共享数据可以创建一个单独的包，提供该共享数据的服务。业务概念显性化了。

10.例子：共享表。不同上下文的共享表按上下文实际需要的信息分开。

11.重构数据库。数据库分离操作具体可参见Scott J. Ambler和Pramod J. Sadalage编写的Refactoring Databases。推荐先分离数据库，别先着急分离服务，观察一下效果，再考虑是否分离服务。

12.事物边界。使用单块表结构，可以通过事务来保证多个操作的全部完成或全部回退。但按服务分表之后，无法使用事务来提供保证了。那应该怎么办呢？

再试一次。可以把操作放在队列或日志中，之后再尝试触发。最终一致性。

终止整个操作。通过补偿事务来抵消之前的操作，可能还需要重试补偿事务。

分布式事务。手动编排补偿事务会比较难，可以采用分布式事务，使用事务管理器来统一编配。处理分布式事务常用算法：两阶段提交。投票，根据投票结果实施。不要自己实现，尽量使用现有实现。

应该怎么办呢。上述方法会增加复杂性。要考虑是否一定要一致性，还是最终一致性就能满足业务需求。最终一致性的系统构建和扩展都更容易。如果一定要一致性，可以显式创建一个概念来表示这个服务，这样更容易实现补偿事务等操作。

13.报告。存储分离后，需要考虑报告会出现的问题。

14.报告数据库。报告需要获得各个部分的数据生出输出。在单块系统中，数据在一个数据库中，报告所需要的数据容易获得。

15.通过服务调用来获取数据。依赖API调用获取数据只适合简单报告系统。使用SQL接口的问题在于不同的微服务暴露的API不一定能够很好适用于报告场景。缓存能够加快访问速度，但也会有无法命中的情况。可以通过提供批量API来简化过程，批量请求变为一个资源，处理好后通过共享文件给调用系统获取，减少HTTP开销。不过作者认为应该有更简单的方式。

16.数据导出。使用一个独立的程序直接访问其他服务使用的数据库，把这些数据库导出到单独的报告数据库。虽然该程序成为了一个数据库集成程序，违反了低耦合原则，但它使得报告很简单，因此可以接受。可以通过维护团队负责将服务数据库的数据导出到报告系统数据库，缓解耦合性。也可以通过数据库技术，如使用视图创建一个聚合，使得对于报告系统来说看到的是单块数据表，但修改数据库时会增加复杂性。还是建议数据导出方式。

17.事件数据导出。对于服务发出的事件可以通过事件订阅器导入到报告数据库中，比周期导入更及时，而且能够将服务内部实现和报告系统解耦。缺点是所需要的信息都要以事件形式广播出去，数据量大时，不容易像数据导出那样在数据库级别进行扩展。

18.数据导出的备份。Netflix使用Cassandra作为数据备份的标准方式，开源了Aegisthus项目（一个能够处理大量数据的流水线）。

19.走向实时。可以考虑将不同的数据按需路由到不同地方。

20.修改的代价。做小的、增量的修改。可以用白板便于思考。可以用CRC（类-职责-交互）卡片帮助设计。

21.理解根本原因。服务一定会慢慢变大，大到需要拆分。要及时发现需要拆分的时机。