量力而行，聊聊旧系统升级改造那些事儿

本文是聊聊旧系统升级改造那些事儿的第二篇内容，文章分别介绍了改造的三个策划，包括激进策略、稳健策略和保守策略。点此阅读第一篇文章。

对于公司而言，无论是对于既存系统进行改造，还是新开的项目，一定会有相应的预算和人员配置，架构师需要是立足于公司给出的预算，根据团队的技术水平状况来做出相应的架构设计的，心中的需要建立全流程的成本意识，并与相关人员进行沟通。

我们看看具体可以采取的策略：

量力而为—稳健策略

在这样的情况下，你作为架构师可以采用更为激进些的架构策略，对于传统企业，可以采用比如买最好的服务器，雇佣最富有经验的工程师，乃至寻求最专业的公司来帮助升级改造，由他们帮你做更详尽的技术调研，配置强大的团队一同来完成改造，然而土豪毕竟是少数，大多数同行还得苦苦求索，寻找投入与产出的平衡点。

与之相对应的是互联网企业，他们面临的情形大不相同；由于用户增长迅速，系统迭代非常快，业务需求变化巨大，周期也更加短，是难以采用上述这样复杂，周期长的策略来对既有系统进行改造的，更多的时候是在老系统略显疲态的时候就需要开始对下一代系统的技术调研和开发，以小步快跑的姿态逐渐替换掉老系统，达到升级换代的作用，如我公司的商城系统短短两年已经更替三版了。所以行业的不同也决定了架构师采取具体架构策略的方向，或是成本优先，或是性能优先，亦或是可靠性安全性优先。

在确定好改造的目标后，根据现实的资源配置情况再来确定架构设计的策略，根据系统面临的主要问题为导向，采用与成本相适应的技术方案，并加以验证。例如上一节的项目中主要问题是运行平台陈旧，运维昂贵，那么迁移到相对价廉物美的 Windows 平台或者 Linux 平台就成了优先考虑的方向，进而去寻找目标平台上能够实现的技术方案，即转换 IBM COBOL 为 MF-COBOL，并利用 MF 的企业套件完成 COBOL 程序服务化的这一方案，且随着相关技术的特性，展开配套工程（Java web 应用）的开发，最终将整个解决方案完善。

这一过程中采用了商业套件开发，采购了 IBM websphere，Hitachi JP1 以及 MicroFocus 企业套件这一些列商业软件，也采取了对外外包开发的策略，整体付出的成本而言也相当客观。但综合来看，全部这些综合改造升级的投入比起原有环境下采购 ibm 大型机以及运维费用来讲却不及其十分之一。

有钱才可以任性—激进策略

我们也看到虽然在投入有限的情况下，这个项目仍然采购了诸多成熟的商业软件，而不是使用开源软件来替代，这也体现了对成本和技术风险的平衡，使用商业软件因为有良好的服务，从而避免因为开源软件带来的潜在问题，也算是一种降低技术风险措施。

与之相对的是，上述项目并不算是一种激进的升级改造策略，还是比较稳健的，毕竟有钱任性的项目也不是每家公司可以随意开展的。激进的策略是将平台语言全部替换，全部移植到新的平台新的语言，采用更多的新技术，新方案。

例如，IBM 公司的 GIAS 系统的升级改造就是如此，他是一个人寿险核心系统，原先运行于小型机 as400 环境的，由 COBOL，RPG 等程序开发的，面临着上述同样的问题，对于 IBM 这样的企业而言产品的升级换代有着重要的意义，因此投入就非常可观，所以 gias 系统就直接从 COBOL，RPG 和 jcl 等源代码程序通过工具转换为 Java，生成各种 bean、dao、service 等等组件，然后再人工消除一些工具不能做到的细节修改，最终完成平台的移植。

这个工具的开发就非常重要，也是非常复杂的，从技术难度上，从成本上来讲普通公司是难以付出这样的成本的，何况 IBM 通过这样的项目移植升级后还可以对其客户的系统提供相应的升级服务，把投入的钱再赚回来，传统企业在 IT 上的投入很少又能提供对外服务把自身的 IT 投入再赚回来的可能的。

在有限的预算下，技术团队水平尚可的时候，通过自身的努力，对既存系统进行改造是我们大多数架构师面临的情况。在完成对系统环境，业务流程乃至系统升级目标做出详尽的分析之后，架构师心里就应该有相应的蓝图了，根据预算给出相适应的架构策略，亦或激进，亦或稳健，亦或保守。

看米下锅–保守策略

激进和稳健的策略我们都讲过，而保守的策略其实大多数是在预算寥寥，人员有限和团队技术水平有限的情况下不得不采取的策略。这样的情况下，更多的是经过前面的系统调研，对主要问题了解清楚之后，选取最重要的一个问题点进行局部升级改造，同时注意其改造过程中是否存在可以通过系统改造，比如加缓存，使用最新版本性能更好的服务器，增加系统带宽，使用 CDN，优化数据库服务器等外部手段来提升系统性能，以解决瓶颈问题。如果是新的相对独立的功能开发，在不得不依赖原有系统的基础上，视情况而定做出重新开发亦或是改造的决定。

例如我们在原有商城的改造的过程中所做的，原有系统是购买的某公司的一套商城系统，我们针对我们的业务需求改造了其原有业务逻辑，这一过程中发现其源代码各种混乱，业务逻辑与页面逻辑相互交织，性能也不佳。与此同时，我们团队刚组建，人员技术水平参差不齐，老板要求上线的时间紧迫，使得权衡利弊之下，于保守的策略来讲，就是只做功能改修，而不是完全推翻重来，以降低项目风险。况且，我们 IT 团队分布于重庆上海两地，沟通协作也带来了诸多困难。

这样的情况下，我们难以一开始就采用激进亦或是稳健的策略，只能采取保守的做法。但，在我们开发微信版商城的时候，就因为原有系统过于繁杂，难以在其基础上一下支持不同平台，就只是使用了他的数据表，全新开发了微信商城的相关功能，通过前面一阶段的功能改修，锻炼了团队，使其明确了商城系统的各个模块，相关业务流程，于是在微信商城的功能开发上，进度和质量都有着不错的提升，其性能效果各方面都优于原有系统。

在改造的技术上，我们针对该商城业务特点，将系统进行集群化改造。通过使用分布式缓存 Memcache 来降低数据库压力和提升页面反应速度。使用 Tomcat 集群，并修改原有系统的用户 Session 管理，做到用户状态与他访问的具体服务器无关，在访问量大的情况下，集群的负载能力得到大幅提升。在外部支撑上，使用阿里云 CDN 来缓存页面资源降低 IDC 带宽的压力，提高全国各地用户访问速度。CDN 的使用使得我们系统的负载能力得到有效提升，因为创业公司支付不起更为充裕的带宽，在现有条件下，结合自身需要，使用外部云服务算一个不错的选择。比如，开展一些活动的时候，将活动程序独立开发并部署到云服务上，来解决自身 IDC 资源有限，不足以应对短时间大量服务请求的问题。

纵然保守的策略是最为无奈的选择，但如同有大牛提到的，架构最终是妥协的产物。在系统构建，维护升级过程中，架构师需要跟需求妥协，跟时间跟团队技术水平妥协，甚至跟用户使用习惯妥协，保守的策略更多是对成本的妥协，花最少的钱办更多的事架构师此刻要做的就是锱铢必较，力求精打细算，以最大努力挖掘系统的潜力，硬件的潜力，以达到更好的用户体验。

作者介绍：

王巍，涟拓网络架构师，前后就职于 Achievo、IBM、HP，关注前沿技术，分布式系统架构，组件化系统开发，机器学习和大数据，现在创业公司负责系统架构，乐于与大家一起聊聊架构。

原文链接:

量力而行，聊聊旧系统升级改造那些事儿