遗留系统的技术栈迁移

遗留系统的技术栈迁移2013-08-05 infoq 张逸什么是遗留系统（Legacy System）？根据维基百科的定义，遗留系统是一种旧的方法、旧的技术、旧的计算机系统或应用程序[1]。这一定义事实上并没有很好地揭露遗留系统的本质。我认为，遗留系统首先是一个还在运行和使用，但已步入软件生命周期衰老期的软件系统。它符合所谓的“奶牛规则”：奶牛逐渐衰老，最终无奶可挤；然而与此同时，饲养成本却在上升。这意味着遗留系统会逐渐随着时间的推移，不断地增加维护成本。

维护一个软件系统，就需要了解该软件系统的知识。若知识缺失，就意味着这会给维护人员带来极大的障碍和困难。从这个角度讲，所谓“遗留系统”，就是缺少了一部分重要知识，使得维护人员“知其然而不知其所以然”的软件系统。

若要让遗留系统焕发青春，最彻底的做法自然是推倒重来，但这样付出的代价太高；而且，即使对系统重新设计和开发，仍然免不了会重蹈遗留系统的覆辙。或者，可以对遗留系统进行重构，在不修改系统功能的情况下改善系统设计。只是这种重构常常是对系统进行重大扩展或修改的前奏，如无绝对必要，并不推荐这种偿还“技术债务（Technical Debt）”的方式。重构应与开发同时进行，而不应将其作为债务推迟到最后，以至于支付高昂的利息。最后，还有一种方式，则是对遗留系统进行技术栈迁移。

一. 决策技术栈迁移的因素

那么，为何要进行技术栈迁移呢？是否是原有技术无法满足新的业务需求？对于遗留系统而言，这种情况总是存在，即需要扩展旧有系统的功能来满足新的业务。然而，这一原因并不足以支持做出技术栈迁移的决策。因为，从技术实现的角度来看，无论采取何种技术，都可以实现各种业务功能，无非是付出的成本不同而已。基本上，这种成本一定会低于技术栈迁移的成本。此外，当今的软件开发，常常会将一个软件系统看做是完整的生态系统，在这个生态系统圈中，完全允许有多种技术平台（包括多种语言，甚至多种数据库范式）存在，只要我们能够合理地划定各个功能（或服务）的边界。

牵涉到架构中的任何一个重大决策，都需要综合考量和权衡，只有充分地识别了风险，才能制订有效的设计决策。个人认为，只有在如下几种情形出现时，才值得进行技术栈迁移。

· 原有技术不能保证新的质量需求

在一个系统的完整生命周期内，系统从诞生到发展，衰老和死亡，与人一样，是不可规避的过程。对遗留系统进行技术栈迁移，无非是希望通过新的技术给旧有系统注入活力，就像器官移植一般，对腐朽的部分进行切除与替换。系统之所以会衰老，会腐朽，原因还在于需求的变化，从而导致系统结构变得庞大而混乱。我们在进行技术决策时，常常是根据当下的需求以及目前现有的技术，结合团队技术能力做出的最符合当时场景的合理决策。因而，技术栈迁移的原因常常是是因为“此一时彼一时”。在当时场景下做出的明智决策，随着时间的推移，会显得不合时宜。这一点在质量需求的满足上，体现得尤为明显。例如，系统对可伸缩性、性能、安全的要求，都可能因为新的质量需求的提出发生变化。而这些质量属性往往靠旧有技术无法解决。RackSpace对日志处理的案例就属于这一场景[2] 。RackSpace的架构对日志的支持，先后经历了三个大版本的演化，从文件服务器到中心数据库，再到MapReduce，每次技术栈的迁移都是质量属性的驱动，不得不为之。

· 出于战略的考虑

这常常是因为企业架构的因素。对于一个企业而言，应该将其IT系统看作是一个整体的生态系统。对于一个正在成长中的企业而言，必然会随着整个企业组织结构、业务体系的变化而影响到IT系统。一般而言，企业IT系统的架构会存在两种情况。第一种情况是从无到有，根据企业架构师与业务架构师的设计，严格按照设计蓝图来规划所有的IT系统。第二种情况则可能是多种不同的系统并存（可能是因为企业采用了并购等方式兼并其他公司业务，也可能是因为不同的业务需要，购买了不同的软件系统）。第一种情况看似美好，但仍有可能发生规划蓝图不能满足需求的可能。第二种情况则处于龙蛇混杂的局面，最后可能导致所谓的“烟囱系统（Stovepipe System）[3]”，需要花大力气对各种系统进行整合。

无论是哪一种情况，一旦做出技术栈迁移的决定，都必然是企业战略上的考虑。当然这种战略指的是IT战略，也可能是企业的整体战略对IT系统产生影响。

我们的一个客户是一家大型的金融企业，提供了多种品牌的保险与银行业务。企业的战略目标是在体现品牌价值的同时，整体展现企业的平台作用。这对于IT系统而言，就意味着需要对各种业务系统进行整合、迁移。整个系统的主要核心是对客户数据的管理，这些数据的管理会影响到整个企业的服务质量、市场推广与产品维护。由于该企业在银行业与保险业的发展壮大，是通过不断的合并与兼并来促进自身的发展。因而在其IT系统中，事实上存在多种不同的系统。客户信息散落在不同系统的数据库中。客户数据的整合，不仅有利于对这些信息的管理，保证数据的一致性，还在于从市场营销角度考虑，可以通过一致的客户信息对客户的情况做出全面了解，制定更好的推广策略。

· 原有的技术提供者不再提供支持

这种情形最是无奈，却时有发生。一种情况是使用的技术（平台、框架）不再被供应商维护，这一点体现在开源项目上更为明显。另一种情况则是所选的技术平台进行了升级，却没有很好地提供向前兼容，使得系统难以随之而升级。在架构设计中，这种绑定具体平台与技术的做法，实际上是反模式的一种，即“供应商锁定（Vendor Lock-In）[4]”。

· 使用旧有技术的成本太高

IT技术并非一定是新技术成本高于旧技术，事实上，随着技术的创新和发展，技术越新，成本越能得到更好的控制。当新旧技术的成本之差，远远高于技术栈迁移的成本，就值得做出迁移的决策了。例如，我们的一个项目需要处理的遗留系统，使用了某软件公司的产品，该产品必须运行在大型服务器上。该产品主要提供客户信息的处理。这是一个存在超过十年以上的产品，之后加入的子系统并未再使用该产品。如今，该产品所支持的客户数量并不多，而每年的产品许可费用以及大型服务器的维护成本都非常高。最后，我们对该产品提供的功能进行了迁移，以渐进地方式逐渐替换了该产品，降低了系统成本。

二. 引入风险驱动模型

George Fairbanks提出的风险驱动模型（Risk-Driven Model）非常适合遗留系统的技术栈迁移。所谓“风险驱动模型”，就是通过识别风险，对风险排定优先级；然后根据风险选定相关技术，再对风险是否得到缓解进行评估的一种架构方法[5] 。在对遗留系统进行技术栈迁移时，如果未能事先对迁移过程的风险进行有效识别，就可能为系统引入新的问题，降低系统质量，或者导致迁移的成本过高。

根据我的经验，在对遗留系统进行技术栈迁移时，可以识别的主要风险包括：

遗留系统本身存在的质量问题，例如紧耦合、缺乏足够的测试、系统可维护性差；

缺乏足够的知识来帮助我们理解整个遗留系统；

成本、时间与人力的风险；

对迁移的新技术缺乏充分认识；

迁移能力的不足