演进式架构学习笔记（三）：演进式数据及构建可演进的架构

第五章演进式数据

数据库脚本管理策略：目前项目采用的策略是合适的，即保留每个产品版本的基础全量脚本，同时添加从上一版本到目前最新版本的升级脚本。最新的全量版本包含了最新的升级脚本。这样的好处是，如果是升级场景，在不迁移数据情况下，仅通过升级脚本即可完成升级。在新系统部署时，则运行全量脚本。

在存在大量数据库操作的时候，微服务的限界上下文如何确定？因为数据库是整个系统的强力耦合点，因此单纯构建一个数据库微服务，第一直觉是不合适的。个人觉得，应该是先从业务领域入手，服务要围绕业务来构建。当需要操作数据库时，如果这种操作是一个业务操作，那就应该通过调用其他业务服务来实现，而不是直接修改数据库表中的数据，业务服务来负责完成数据的维护。这样的好处是，所有对同一数据的操作，会集中于特定的服务，从而避免了数据层面的耦合复杂度。

数据是非常重要的，正因为重要，所以需要和代码一样来看待，需要重构，需要演进。要不断审视业务变化带来的数据变化，权衡变更带来的影响。

 

第六章构建可演进的架构

如何构建可演进的架构呢？首先需要识别受演进影响的架构维度，然后为每一个架构维度构建合适的适应度函数，最后使用部署流水线自动化适应度函数。

那如何改良现有架构呢？主要取决于三个因素，组件本身的耦合程度，工程实践成熟度，以及开发人员构建适应度函数的难易程度。其中，对业务本身的理解程度是最关键的，只有彻底理解现有业务，才有可能选择出最合适的架构。

如何迁移到另外一种架构呢？共享问题是其中最棘手的。模块的共享，原则是能拆分的拆分，不能拆分的复制副本（这里有个疑问，所谓的副本，是指DLL等的拷贝？）划分好服务后，就是在服务内部进行单体分层设计（这里的分层，我觉得应该采用洋葱架构或者六角架构等，即依赖关系应该是向内核依赖，向业务依赖）。最后是服务发现，即服务的查找与调用，可以通过服务代理来完成（服务代理是一种典型的中间层设计，在软件设计中，两者无法直接调用时，中间层是最佳实践。）迁移到微服务架构时，步子不要迈得太大，此过程可以逐步进行。

演进构建指南：

1、去除不必要的可变性，让基础设施变为不可变部分。这里联想到操作系统。构建核心不可变部分对于演进非常重要。

2、让决策可逆。通常采用蓝绿部署和功能开关来完成。功能开关在我们项目中常用。蓝绿部署看起来通常是在互联网行业应用比较多。

3、演进优于预测。由于未知的未知问题肯定存在，所以预测很难。与其预测，不如让架构具备可迭代性。

4、构建防腐层。这里防腐层指的是隔离可能的变化点，比如第三方数据库，组件，动态库，框架等等。防腐层首先从业务层面定义相关的API，然后在防腐层中实现这些API与三方的桥接。

5、构建可牺牲架构。

6、应对外部变化。和防腐层一个意思？

7、框架和库。确实来说，库的依赖性管理显著优于框架，框架一般是通过回调来调用应用，应用只是框架的扩展点，但从经典架构设计来说，这种依赖关系显然是不合理的。应用系统的构建，关键在于应用的核心业务逻辑，这才是一款产品能够获取客户认可的最重要一点。如果依赖于框架，一旦框架变更（而且从实际来说，框架的生命周期实在属于短命的），应用就必须升级，这样显然不利于应用系统的演进。而库就简单许多，它允许应用通过库的接口来使用库的功能。

8、持续交付优于快照