“脚手架”软件——过渡架构

过渡架构:为替换遗留系统而安装的软件元素,会在替换完成后移除。

目录

  • 过渡架构的工作原理

  • 过渡架构的使用环境

  • 示例:架构演变

要想成功替换遗留系统,最核心的一点是用新的软件逐步替换遗留系统,这样既可以尽早获得效益, 又可以规避较大的风险。在替换遗留系统的过程中,必须同时运行遗留系统和新系统,让新旧系统一起参与分工,而且这种分工要随着遗留系统的消失呈现动态的变化。

为了让遗留系统和新系统相辅相成,我们需要搭建过渡架构,而且要随着遗留系统的替换过程动态的改变过渡架构。另外,我们可能需要集成中间构形,而且这种集成不会出现在新系统的目标架构中。

说的直白一点,过渡架构用完就会被拆除,但我们还是得搭建它。

过渡架构的工作原理

举个例子,假如我们要翻新一幢建筑,设计师已经给我们看了成品效果图,施工人员已经进场准备施工,但我们施工的第一步其实是在施工现场搭起脚手架。

我们要想翻新建筑,必须得花钱租赁脚手架,雇佣施工人员。我们得用脚手架完成一些关键的工作,而且脚手架可以降低风险,保证施工人员的安全。有了脚手架的辅助,我们可以一次性解决好几个问题——可以在替换屋顶的同时修复烟囱、修剪悬在房顶的树枝。完工后要拆除脚手架,至此,翻修工作圆满完成。

与施工类似,替换遗留系统也需要“脚手架”,只不过替换遗留系统用的是软件组件脚手架,目的是简化搭建目标架构的步骤。目标架构搭建完成后,就可以像装修完工拆除脚手架那样把这些软件组件拆除。

当然,一次性替换大型遗留单体架构有较大的风险,最好能分步进行,安全地替换遗留系统。我们可以采用提取价值流提取产品线的模式,使用功能或数据的子集来实现。首先,拆分单体架构,给单体架构引入一个接缝(seam)。这个向单体架构引入接缝的组件就是过渡架构,一旦单体架构被完全替换,就不再需要这些组件了。

在引入接缝前,我们得先了解单体架构各部分之间的通信路径,在通信路径上放置一个组件就可以修改该通信路径并把信息流转移或复制到其他元素。事件拦截通过监听事件来修改通信路径以及转移、复制信息流,抽象分支则是通过 API。创建接缝时,我们可以使用Legacy Mimics为遗留通信流引入新的组件。

替换遗留系统的难点之一是数据处理,遗留系统通常可以直接访问这些数据,所以最好能通过 API 引入接缝来代替直接的数据访问,例如采用存储库模式。 如果不能引入 API,我们需要复制系统的状态,遗留模仿事件拦截也都用得到。

                                  常用的过渡架构模式
使用 模式
创建接缝 事件拦截 遗留模仿 存储库 防腐层
复制状态:新 ➔ 老 (Keeping the lights on) 遗留模仿 (消耗 Mimic)
复制状态:老 ➔ 新 遗留模仿 (提供 Mimic) 事件拦截

搭建目标架构的方法有很多种,但每种方法都得使用过渡架构,所以我们要仔细分析每种方法的成本和效益,做出最佳选择。

只要使用了过渡架构,就必然会有拆除它的一天。我们在搭建它时稍微多花一些成本,增强其承受力,可以为之后的拆除省点力。另外,我们得采用正确的拆除方法——如果组件拆除不彻底,即使是全新组件,也会影响系统的维护和升级。

过渡架构的使用环境

我们在搭建过渡架构时就知道早晚得拆除它。大家都不喜欢做无用功,而且觉得没必要在用完即弃的东西上花费太多成本,但是过渡架构带来的价值与搭建它所耗费的成本几乎相当。

使用过渡架构有很多优势:第一、使用过渡架构能提高交付效率。沿用上文的建筑施工的例子,油漆工在漆墙时会在墙面边缘贴上油漆工胶带。如果不使用油漆工胶带,在对边缘涂漆时就要小心翼翼的,尽量把边缘漆成一条直线,还要防止把漆涂到窗户等物体表面。所以,大部分油漆工都会在施工前贴上胶带,在施工完成撕掉胶带,这样不但可以避免漆错地方,还可以加快施工速度,对技巧的要求也不高,所以,油漆工胶带来的便利完美弥补了贴胶带和撕胶带的时间和金钱成本。

时间就是金钱,选择好用的软件可以节省时间。假设你要交付一个项目,要做一个能把遗留系统与新系统的数据集成起来的新的商业智能仪表盘,你可以在新仪表盘中搭建一个网关,读取遗留系统的数据,然后把这些数据转换为仪表盘兼容的格式,最后在遗留系统替换完成之后删除网关,这样做比集成新的仪表板更快。但如果你选择先集成新的仪表板再替换遗留系统,那集成仪表盘的时间成本可能会远超创建仪表盘的金钱成本,而且替换遗留系统需要的时间可能也比预期的要长。

第二、使用过渡架构可以降低替换遗留系统的风险。尽管在客户管理系统中添加事件拦截功能会提高成本,但事件拦截功能可以分批迁移客户(例如:通过提取产品线提取价值流)。分批迁移客户可以降低迁移过程中的风险,就算发生严重事故,也可以使用事件拦截让系统快速恢复到之前的状态。

我建议所有团队在替换遗留系统时使用过渡架构,而且一定要选择最合用的临时软件,这样才能实现效益最大化。另外,各团队可以综合评估一下降低时间成本带来的效益和花费成本搭建这种一次性软件能降低的风险。我相信评估后大家就会发现过渡架构的好处。

示例:架构演变

本节探讨的是文章概述中的中间件移除的例子——如何使用过渡架构顺利升级系统。

遗留配置

如上所述,此架构包括一个主遗留系统,该遗留系统通过一些集成中间件给产品定价并将产品发布到遗留店面。中间件消费遗留队列里的产品发布事件,跟踪并协调产品的店面展示方式。产品售出后,遗留店面调用中间件在内部共享遗留数据库中更新产品状态。遗留中间件的状态也存储在该遗留数据库中,通过数据仓库反馈至关键报告。参见关键聚合器

transitional-arch-legacy

目标架构

目标架构中仍有遗留店面,只不过遗留店面的一些工作由新的店面管理器组件接手。 如果产品被路由到资产处置路由进行出售,店面管理器会消费资产处置路由产生的业务事件,并使用新的 API 将该产品发布到店面。店面管理器负责店面的产品展示方式。如果产品被售出,遗留店面使用上述新的 API 调用店面管理器,发出业务事件,由下游的资产销售处理组件消费。

2

第一步:开启

搭建过渡架构的第一步是添加事件路由组件。在下面这个事件拦截模式的示例中,事件路由创建了一个技术接缝,通过新组件路由要售卖的产品。

3

第二步:引入店面管理器

下一步是添加新的店面管理器。这里也添加了过渡架构,主要目的是:第一、把新组件与遗留问题(如:数据结构和消息)隔离开来;第二、保证遗留系统处于运行状态。为实现新组建与遗留问题的隔离 (防腐层),我们创建了一个事件转化器,将事件路由器路由的遗留消息转化为新的、纯净的商业事件格式,供店面管理器消费,这种模式会沿用到目标架构中。店面管理器和遗留店面将通过一个新的 API 进行合作,因此添加了新的 API 和内部事件拦截,当产品被售出时,遗留店面将“回调”到发布该产品的系统,为保证系统处于运行状态,我们需要两个过渡架构。首先,产品被售出时会发布新的商业事件,由临时的遗留数据库适配器模仿的集成中间件消费,销售信息会在遗留数据库中更新。其次,创建 MI 数据模仿器。这既是一个事件拦截器,也是一个遗留模仿器——在新 API 中拦截事件,并用业务关键报告的“状态”信息来更新遗留数据库。

4

第三步:业务成果——遗留中间件的拆除

遗留系统仍负责确定哪些是可以出售的资产,并发送产品进行发布。路由到新组件的产品数量随时间不断增加(见提取产品线),直到全部流量都不需要再通过遗留中间件来处理,这时候,拆除遗留中间件,将新的店面管理器和过渡架构组件留在生产中。

5

第四步:引入资产处置路由

一段时间后,新的资产处置路由开始投入使用(这是个简化版示例,节选自一个大型遗留替换计划)。这个组件为店面管理器可以消费的产品发布新的业务事件。因为已经有了其他可以决定哪些资产需要处置的组件,所以我们可以把事件路由器和事件转换器拆除。我们已经拆除了遗留中间件,业务关键报告已被变更为使用来自新组件的数据(参见来源),因此,我们也可以拆除 MI 数据模仿组件。

6

第五步:完成目标架构

稍后,新的资产销售处理组件上线,接管本示例中的遗留系统的最后职责。现在我们可以移除最后一个过渡架构——遗留数据库适配器。店面管理器产生的业务事件由资产销售处理组件消费。

2

原文作者:Ian Cartwright、Rob Horn、James Lewis
原文链接:Transitional Architecture