您对遗留系统认识是怎样.PDFVIP

您对 “遗留系统”的认识是怎样 的？ 英文原文：/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。