什么是可演进架构

本文是春节读了 thoughtworks 的《演进式架构》（Building Evolutionary Architectures）后的一些总结思考和感悟。主要想探讨一下什么是可演进式的架构，我们做架构设计时如何才能做到可演进或者有长期的生命力，在流程、规范、方法论上分别有哪些好的实践。

首先，martin fowler 是我非常推崇和尊敬的大牛，我在卓越工程里面提出的契约测试的思想就是源自于他的文章Customer-Driven Contracts。《演进式架构》全文也有很多可以学习和吸收的内容，可以看出来是 thoughtworks 公司长期咨询实践的总结。

在展开论述之前，先简单介绍一下《演进式架构》的核心观点。总结下来，thoughtworks 的可演进架构理论主要就是三点：

1. 用适应度函数来评判架构演进的方向和质量。

2. 采用增量变更的方式实施架构演进。

3. 架构之间必然存在适度的耦合，提出了架构量子的概念：系统最小的可部署单元（代码+数据...）。架构量子越小，架构的演进能力越强。通过这个来评判架构的可演进性。所以，架构可演进性：Faas>微服务>SOA>模块化单体>分层单体>普通单体架构。

观点是很清晰的，但是，根据这个理论，可以指导我们的架构设计么？选择 Faas 和微服务就可以了？同时用各种测试、巡检来定义适应的函数？但是同样是微服务，为什么不同公司的迭代效率和质量还是有巨大差别？有些公司为啥随着业务的变化，架构就演进不下去了？

这就是学术和工程的巨大差异。《演进式架构》架构里面提出的观点，其实就是把进化论引入了 IT 而已。更确切的说，《演进式架构》提出的是对架构演进过程的控制理论，而不是演进式架构的设计模式或者架构演进的最佳实践。在学术界，提出一个软件进化论的理论同时提出控制方法论，是非常耀眼的。但是在工业界，无法指导生产的理论都是在耍流氓。

从控制论的角度，《演进式架构》提出的观点是自洽的。首先 Finess Function 这个观点就非常好，适者生存嘛。每个开发人员都可以做架构迭代，适应的留下来不适应的淘汰（不是人的汰换^_^）。同时，增量式变更就是要小步快跑。防止变更过大，无法区分出进化部分和退化部分。最后架构量子这个，无非就是说组织越简单越能适应环境，给 Faas 和微服务搞个广告罢了（Martin Fowler 本身就是微服务的鼻祖）^_^

所以，《演进式架构》就是 IT 界面的《物种起源》。

但是，我们的架构到底应该怎么去设计和升级，才能满足业务的快速变化，同时能保持很好的产品质量和迭代效率呢？

当然，首先拆分是必然的一个选项。在「微服务和单体架构」一文我就指出了，对于一定复杂程度的业务，单体架构是不可能承载的。业务越复杂，组织就越复杂，同时功能就会呈几何技术的膨胀。如果用单体架构，就好比一只手举着几十吨铁块另一只手同时在上面进行微雕操作，画面是不是很壮观？结果可想而知也会比较壮观吧。。。

其次，我们不能有“银弹”的幻想，将架构能力想象的过于强大，认为架构具有无限的演进能力。我们需要认识到架构的演进是一个微调的过程。架构的设计要勇于抛弃。业务如果有巨大的变化，或者技术环境有很大的变化。比如业务从 toC 走向了 toB，架构模式从单体走向了微服务、Faas，那么原先的架构就应该果断的抛弃掉，基于新的业务和技术进行全新的架构设计。否则，需要考虑大量的历史遗产的处理，架构设计会处处别扭，最终产出的架构会有各种的妥协和变形。

再次，我们需要原生的从动态视角去进行架构设计。背后的含义就是我们设计架构的时候要考虑到前面版本的兼容，也要考虑到后续版本的迭代。在这方面，有一些实践上的心得。

第一，考虑服务兼容性。因为我们存在系统之间相互调用的关系。所以新设计的架构需要能处理老服务的流量。最简单的就是通过增加一个适配层来兼容。但是也不能无限兼容，我们不可能在系统中保存十几个服务版本。所以对于老的服务需要有一个逐步下线的过程。包括历史服务存续期的规范、下线的通知机制、历史流量的监控机制。对于服务兼容性，我们有相应的测试能力进行保障，契约测试就是一个很好的方式。

第二，需要考虑到遗留数据的处理。对于遗留数据，又可以分为两类数据。一类是交易过程中的临时数据，生命周期随着交易结束就结束了。比如议价过程、意向单据等。一类是长期的数据，在交易结束后还会长期保存并被查询。比如账单、交易订单等。对于第一类单据，不需要做数据迁移，虽然有的单据可能存续的时间比较长，比如意向单会存在三个月到半年。这无非就要求新旧的产品在三个月到半年时间并存罢了。对于第二类单据，是需要考虑进行数据迁移。对于有停机窗口的系统，可以通过离线 ETL 的方式将数据从老模型迁移到新模型。对于没有停机窗口的系统，对历史单据查询需要增加双读的方式，保证在数据迁移过程中也能提供查询能力。同时，为了支撑数据迁移，在做数据模型设计的时候，要充分理解业务，对于一些业务上目前说不清楚的信息，尽量能先预置到模型中，这样在模型升级的过程中可以尽量避免信息丢失的情况。

最后，演进可能进化也可能退化。所以，我们在架构演进的过程中需要充分考虑到系统稳定性和资金安全。通过灰度来保证稳定性，通过实时和离线的核对来保证资金安全。这个是另一趴的话题，在这里不展开。