演进式架构学习笔记(三):演进式数据及构建可演进的架构

第五章演进式数据

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

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

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

 

第六章构建可演进的架构

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

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

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

演进构建指南:

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

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

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

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

5、构建可牺牲架构。

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

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

8、持续交付优于快照

你可能感兴趣的:(编程思辨,读书笔记,架构设计,企业架构)