您对“遗留系统”的认识是怎样 的？ 正确看待大型机——它是业务的关键组成部分

您对“遗留系统”的认识是怎样
的？
英文原文：http://ibmdatamag.com/2012/03/hey-what-are-you-calling-a-legacy-system/
正确看待大型机——它是业务的关键组成部分
作者：Robert Catterall |
发表时间：2012 年 3 月 1 日
您是否听到过这样的一些说法？一名 IT 高级管理人员谈及其组织的应用基础架构。他很乐
观地描述了环境的“现代化”方面：多层式客户端-服务器系统；使用 PERL、Python 和 Ruby
等语言执行面向 Web 的开发；以及面向服务的架构。
如果您向这名 IT 高级管理人员询问他们正在使用的 IBM System z 服务器，回答很可能
是不屑一顾的：“噢，那是我们的遗留系统”。“遗留”这个词听上去就像是包含几分羞愧。
我从事大型机系统方面的工作已有 30 年之久，我对这类评论的反应往往是这样的（当然
只是在心里默默地说）：“遗留系统，您指的究竟是什么？是运行那些保持工厂正常运转、
保证货车照常运行、保持客户票据川流不息的应用程序的系统吗？这些应用程序不就是给您
带来盈利、保持企业生存的应用程序吗？您认为这是遗留系统？”
但是，我不会与他们争辩，通常我只会这样说：“谈到您的 System z 服务器，必须注意
到这种平台上的 DB2 是现代化、多层式、面向服务应用程序的优秀数据提供者，您非常关
注这些应用程序，不是吗？如果这还不能令您信服，请去观察一下您自己的开发团队最近在
做些什么。”
这是一种有几分讽刺意味的情况。这家组织的程序员可能会告诉 DB2 for z/OS 数据库管理
员，他们完全不想使用大型机，但这些程序员又完全可以接受在 Java 程序中编写 JDBC
调用代码，而 JDBC 调用的目标就是大型机 DB2 数据库。
这是不是有些自相矛盾？但我认为情况并非如此。我相信，在开发人员说不想使用大型机时，
他表达的真正意图并非不喜欢这种平台，而是反感绿屏和 3270 接口等。如果开发人员能
通过运用自如的接口（例如 JDBC、ODBC 或 ADO.NET）从关系数据库中检索数据（或
者将数据持久保存到关系数据库中），那么他们根本不会关注目标数据提供系统是不是 DB2
for z/OS。对于开发人员来说，平台仅仅是一种渠道。他们真正关心的是通过熟悉的方式获
得程序所需的数据。这些数据存储在大型机上？没有问题。
同样，在 IT 高级管理人员提到希望脱离大型机平台时，我们要怎样解释其组织内的大型机
DB2 工作负载仍在保持稳步增长？是不是 IT 部门的工作人员忽视了上司的意见？答案当
然是否定的。我认为此类 IT 高级管理人员真正的愿望是摆脱旧式应用程序架构，而由于这
种旧式架构源自 20 至 30 年前，所以往往以大型机为标志。当时大型机几乎是真正大规
模、任务关键型应用程序的惟一可行选择（至少在很多人心目中是这样）。这种架构在本质
上是单体式的，用户界面、业务和数据访问逻辑之间完全不具备物理分离，逻辑分离几乎也
不存在，该框架能够高效利用 CPU 资源，但灵活性极差。如今的企业需要敏捷性。敏捷、
可扩展的应用架构对于组织至关重要。在这种混乱的局面中，人们往往无法认识到，根据组
织的需求，大型机和 DB2 极其适合此类架构，甚至可能是“天作之合”。
不要去管那些对话。实际情况是怎样的？
某些大型机专业人员认为他们即将被淘汰，只能无助地等待这些大家伙丢到废品站。有趣的
是，其中一些人甚至没有认识到他们的眼前正在发生怎样的巨变。
我在 DB2 for z/OS 站点中通常会做这样一些事情：获取一天最繁忙的一到两个小时内的
DB2 监控器计算细目报告。这种报告内的数据可按照连接类型分组，便于查看 CICS-DB2
工作负载、成批 DB2 工作负载和 DRDA（即客户端-服务器）工作负载等活动。大多数 DB2
监控器产品都能生成这样的报告。
获得每次处理事务时 DB2 内所用 CPU 时间（即“2 类”CPU 时间）的平均值。这就得
到了每计算跟踪记录，它通常是 CICS 和 DRDA 工作负载的每次事务处理时间、成批工
作负载的每作业时间。将结果乘以报告的次数。乘积即为针对整个 DB2 工作负载的这一部
分的 SQL 语句执行 CPU 总成本。
猜猜结果怎样？客户端-服务器活动往往是整个大型机 DB2 工作负载中增长最快的组成部
分，在某些情况下甚至已经成为比例最高的工作负载组成部分，既超过 CICS-DB2，也超
过成批 DB2。而实际管理 DB2 for z/OS 系统的人员可能未能认识到这一点。莫非他们在
工作时心不在焉？当然不是这样。原因仅仅是他们太过关注单独的工作负载元素：他们要帮
助 Java 开发人员访问这里的 DB2 数据、支持 .NET 应用服务器访问那里的 DB2、处理
PHP DB2 驱动程序等等，因此无法从宏观角度把握全局；换句话说，他们没有注意到 DB2
for z/OS 已经成为所有类型的“现代”应用程序的首选数据服务器。
如果程序员根本不认为自己是大型机专业人员，那么他们为什么会在自己的代码中用到大型
机？首先，就像我之前提到的那样，对于开发人员希望使用的任何语言，几乎都有对应的
DB2 驱动程序。通过 IBM Data Server Driver Package 是获得这些驱动程序的最方便途径。
其次，开发人员以数据所在的位置为导向。组织的大量数据资产往往位于大型机之中（通常
由 DB2 管理）。如果存在此类位于大型机中的数据的开放接口（大多数情况下确实存在），
那为什么非要将数据迁移到其他系统中？为什么不能直接在原来的位置访问数据？在商业
智能和数据仓库领域中，在大型机上访问源自大型机的数据这一趋势已成为主流，为了使用
DB2 for z/OS 执行数据分析，企业越来越多地避免将大型机中的数据迁移到人们认为对 BI
友好的其他平台。
也有某些类型的 IT 管理人员要求在 DB2 for z/OS 上执行开发工作（通常是各类“现代化”
开发工作）。原因并不仅仅是数据往往位于大型机中，而是因为他们认为大型机是组织最安
全、最具可伸缩性、最高可用的数据提供平台。
成本如何？在根据道听途说的理论给 DB2 on System z 扣上“最昂贵”的帽子之前，请首
先仔细观察一下。您的大型机（可能用于运行大型工作负载）占用了多少楼层空间，而相比
之下，您的环境中使用的其他平台又占用了多少楼层空间？能耗如何？需要多少支持人员？
只要进行一些简单的对比分析，您就能认识到，System z 实际上通过一种极为经济高效的
方式为您的组织提供了可观的价值。
更新您的 DB2 知识
我想给这个故事加上一段简单的后记。在某些站点，一些 IT 人员认为大型机 DB2 分布式
数据库处理源于 20 世纪 90 年代的实际环境，因此拒绝对客户端-服务器应用程序使用
DB2 for z/OS。您是否认为来自 DDF（DB2 分布式数据工具）的所有内容都按照相同的优
先级运行呢？绝对不是这样。早在多年以前，实际情况就已经不再是这样了。
您是否认为客户端-服务器上下文中执行的所有 SQL 都是动态的？这种认识同样已经过时
了。举例来说，您可以将 DB2 服务器端的静态 SQL 语句打包为存储过程的形式，以便（当
然是通过一种开放的方式）从连接网络的客户端调用它。您是否认为 DB2 客户端-服务器
环境中的安全性过于松懈？请了解一下 DB2 9 交付的角色和受信任上下文等特性，如果
SQL 来自大型机以外的应用服务器，可以利用这些特性加强数据访问控制。结论：您对 DB2
for z/OS 的现状了解的越多，就越会希望将其作为您的多层式应用程序的基础。
下一次，如果您再听到有人将“遗留系统”的帽子扣到大型机头上，请深入研究具体情况。
首先，大型机和 DB2 是您组织中的服务器主力。第二，看清事实。所谓的遗留系统或许是
您企业中最优秀的客户端-服务器数据库平台。您手下的开发人员或者其他工作人员很可能
已经了解这些事实。您应该听听他们的意见。除了请他们喝杯咖啡之外，您不会有其他损失。
无相关文章。