读书笔记《微服务设计》---分解单块系统

书籍《微服务设计》，地址：微服务设计 (豆瓣)

庞大的单块系统，也可以使用正确的工具，进行分解。

1、关键是接缝：限界上下文就是一个非常好的接缝，因为它的定义就是组织内高内聚和低耦合的边界。所以分接单块系统，要识别出这些边界，这些边界可以根据命名空间来识别。接缝边界定义好后，可以根据代码进行分解。

2、分解单块系统的原因

     改变的速度：将某一个功能抽出来作为一个服务，称为自治单元，那么后期开发的速度将大大加快。

     团队结构：团队很有可能是异地工作，那么根据团队划分服务，就可以更方便的全权负责了。

     安全：不同功能对安全的要求也不同，那么根据这个点考虑划分服务的话，就可以独立的对某个安全性要求高的服务进行监控、数据保护等。

     技术：某一种算法，大大改善我们的服务，就可以将其分离到单独的服务中，这样后续维护和实现更加容易。

3、杂乱的依赖：已经识别了备选接缝，就需要考虑其他代码和接缝之间有没有依赖。存在依赖会比较难处理。

4、数据库：数据库是杂乱依赖得源头，所以需要找到数据库中得接缝。这样就可以把他们分离干净。

5、找到问题得关键：

      第一步，看代码中对数据库进行读写的部分。将数据库映射相关的代码和功能代码放到同一个上下文中。

      第二步，可以用SchemaSpy工具，查看数据库约束。那么怎么切断这些约束连接呢？后续的6\7\8\9，可以解决这些问题。

6、打破外键关系：放弃外键关联，如果需要访问不同服务下的数据表，可以通过Api调用来实现。这样数据库的约束移到代码上，就需要检查一致性，或者周期性触发清理数据的任务。怎么处理要根据具体的业务决定。

7、共享静态数据：可以将共享的静态数据放入代码，比如放到属性文件中，或者简单的放到枚举中，但是依然存在数据一致性的问题。也可以将静态数据放到单独的服务中。

8、共享数据：例如客户这种信息，经常和其他服务都有关系，这种情况下，需要将客户的服务单独出来，其他服务需要访问这部分数据进行交互，就通过API来实现。

9、共享表：不同服务可能在单块系统中，访问同一张表，但是服务分开后，也需要将表分开。

10、重构数据库：单块项目分离，建议先分离数据库，根据上述6\7\8\9提到的数据库分离后，先观察一段时间决定是否继续分离，如果可以再分离应用程序。

11、事务边界：事务可以理解为一个业务流程要么全部做完，要么什么都不变。那么数据表根据服务分离后，就失去了事务提供的安全性，下边的几个方法可以解决这个问题。

       再试一次：出错的业务放到队列里，再执行一次。这种形式也叫最终一致性。这种方法对于长时间的操作非常有用。

       终止整个操作：这种方式会比较繁琐，比如一系列的操作，某一个环节出错了，就需要用补偿事务将其已经执行的操作回退，保证数据的一致性。

       分布式事务：分布式事务是使用事务管理器来统一编配其他底层系统中运行的事务。处理分布式事务常用的算法是两阶段提交。首先是投票阶段，如果每个参与者都投票成功，那么管理器告知进行提交，如果收到一个否定票，那么所有参与者都回退。这种方式依赖事务管理器，如果事务管理器出现宕机，那么等待的事务都会永远无法完成。如果采用这种方式，尽量用现有的API实现。

       应该怎么办：根据具体业务进行选择，如果业务无法再划分，那么最终一致性可能会更加容易。如果一定要确保业务上的一致性，那么再考虑一下服务的划分是不是可以优化，尽量不要单纯的依靠技术来解决事务问题，如果一致性的业务划分到一个服务中，或许更容易一些。

12、报告：报告系统的用户和其他用户一样，他们的需求也应该得到满足。

13、报告数据库：报告系统可以单独去读报告服务本数据。而主数据周期性的同步给报告数据库。数据库的选型也要考虑，Cassandra对大数据量处理的很好。数据建模成图的可以考虑Neo4j或者MongoDB。

14、通过服务调用来获取数据：面对报告系统这种数据量大，关联性也很强的服务，我们可以采用服务调用来获取数据，但是简单的服务之间API会增加很大的压力，那么可以让服务根据一组ID批量获取数据，或者提供一个接口来分页访问所有的数据。这种方式操作比较复杂。

15、数据导出：使用一个独立的程序之际访问其他服务使用的哪些数据库，把这些数据导出到单独的报告数据库中。

16、事件数据导出：对于一些暴露事件聚合的微服务来说，可以编写自己的事件订阅器来把数据导出到报告数据库中。这样相比周期性的数据导出，能更快的流入报告数据库中。这种方式的缺点是，数据量大时不容易像数据导出方式那样直接在数据库级别进行扩展。

17、数据导出的备份：Aegishus项目，是一个能够处理大量数据的流水线。可以理解为数据导出的特殊形式。将数据进行备份，将备份数据作为任务的数据源。

18、走向实时：以上关于报告的方法很多，需要根据不同的业务需要选择不同的方式。

19、修改的代价：修改会带来风险，所以设计的时候尽量落实到纸上。例如CRC  类--职责--交互，按照这种方式写下来去思考。

20、小结：通过寻找服务边界来把系统分解，这可以是一个增量的过程。