决策技术栈迁移的因素

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

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

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

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

在一个系统的完整生命周期内，系统从诞生到发展，衰老和死亡，与人一样，是不可规避的过程。对遗留系统进行技术栈迁移，无非是希望通过新的技术给旧有系统注入活力，就像器官移植一般，对腐朽的部分进行切除与替换。系统之所以会衰老，会腐朽，原因还在于需求的变化，从而导致系统结构变得庞大而混乱。

我们在进行技术决策时，常常是根据当下的需求以及目前现有的技术，结合团队技术能力做出的最符合当时场景的合理决策。因而，技术栈迁移的原因常常是是因为“此一时彼一时”。在当时场景下做出的明智决策，随着时间的推移，会显得不合时宜。这一点在质量需求的满足上，体现得尤为明显。例如，系统对可伸缩性、性能、安全的要求，都可能因为新的质量需求的提出发生变化。而这些质量属性往往靠旧有技术无法解决。

RackSpace对日志处理的案例就属于这一场景[2] 。RackSpace的架构对日志的支持，先后经历了三个大版本的演化，从文件服务器到中心数据库，再到MapReduce，每次技术栈的迁移都是质量属性的驱动，不得不为之。

出于战略的考虑

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

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

我们的一个客户是一家大型的金融企业，提供了多种品牌的保险与银行业务。企业的战略目标是在体现品牌价值的同时，整体展现企业的平台作用。这对于IT系统而言，就意味着需要对各种业务系统进行整合、迁移。

整个系统的主要核心是对客户数据的管理，这些数据的管理会影响到整个企业的服务质量、市场推广与产品维护。由于该企业在银行业与保险业的发展壮大，是通过不断的合并与兼并来促进自身的发展。因而在其IT系统中，事实上存在多种不同的系统。客户信息散落在不同系统的数据库中。客户数据的整合，不仅有利于对这些信息的管理，保证数据的一致性，还在于从市场营销角度考虑，可以通过一致的客户信息对客户的情况做出全面了解，制定更好的推广策略。

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

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

使用旧有技术的成本太高

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