当前页面: 开发资料首页 → J2EE 专题 → 什么是按需计算?
什么是按需计算?
摘要: 世界正以风险管理和减少支出（例如外包）这个双重需要为方向发展着。目前的IT 应用过于复杂并需要过多的人工干预。按需计算（ ODC ）为当今公司的这些需要提供了一个基础性的解决方案，通过向更自主化的IT业务基础设施迁移可管理风险并降低开销。
按需计算（ ODC ）是一种计算和通信的基础设施，用来促进业务服务的灵活性并提供以下基本功能：
● 自主计算。
● 对外部业务引发的变化快速响应。
● 自适应的业务流程可保障收益并控制成本。
● 公司边界对内、对外的复杂接口。
● 对病毒、入侵和电力中断等外部威胁的自恢复能力。
本文内容
1. 交给别人做
2. 向ODC迁移
3. 向自主计算迁移
4. 使软件可管理
5. 商业策略驱动的计算
6. 提升IT投资回报率
7. 自主化产品
8. ODC的局限性
9. 结束语
版权声明：任何获得Matrix授权的网站，转载时请务必保留以下作者信息和链接
作者:Stephen B.Morris;observer
原文:http://www.onjava.com/pub/a/onjava/2005/11/30/what-is-on-demand-computing.html
Matrix:http://www.matrix.org.cn/resource/article/44/44614_ODC.html
关键字:ODC;按需计算
交给别人做
世界正以风险管理和减少支出（例如外包）这个双重需要为方向发展着。目前的IT 应用过于复杂并需要过多的人工干预。按需计算（ ODC ）为当今公司的这些需要提供了一个基础性的解决方案，通过向更自主化的IT业务基础设施迁移可管理风险并降低开销。
今天仅有极少的（如果有的话）业务是真正以按需的模式运作的。因此 ODC 对于当今的基础设施而言是一个迁移（不是直接升级）目标，迁移的最终结果是使其成为更自主、由商业策略驱动的模式。它代表的是转化而不是革命！
迁移到ODC
简而言之，我们可以说当今的基础设施受到两个弱点的困扰：复杂性和过多的人工输入。事实上，IBM声称40％的计算机宕机是由操作失误引起的，有的公司（如EMA）则声称复杂网络的误配置率高达60％。
ODC 的主要特点如下：
● 因自主计算带来的自主性和工业级的健壮性
● 商业策略驱动的计算
● 提升IT投资回报率
有关 ODC 比较有意思的是它的集成本性。它集各领域之所长――如系统/网络管理、标准化的技术（XML、J2EE、web service、EJB 等）――将它们结合成一个健壮、自配置、自保护和自恢复的基础设施，并全部基于开放的标准和规范。IBM 将此称为按需操作环境。
让我们从自主计算开始来看看 ODC 的要素。
向自主计算迁移
IBM 将自主计算分为5级：
● 基础级：需要技术娴熟的员工；非常依赖人工操作；业务经常因IT系统宕机而被制约。
● 可管理级：需要技术娴熟的员工判读管理数据；少量的自动化操作；业务仍会因IT系统宕机而被制约。
● 预防级：无需技术娴熟的员工判读和确认；更多的自动化操作；尽管频次比上一级要少，业务仍会因IT系统宕机而被制约。
● 自适应级：员工监视下的自动变动/修正，以确保系统运行良好；业务仍会因IT系统宕机而被制约，但可通过服务品质协议对此进行限制。
● 自主级：完全自动化操作；员工专注于按既定策略推动业务。
现今大部分的公司处于第一级。重要的是应牢记 ODC 是现有IT 应用和基础设施的一次业务转换而不是大规模的替换。这种迁移方法也适用于自主计算――我们可以通过阶段化的方式从现有模式迈向自主化的时代。
智能控制系统是自主计算的核心。在大多数情况下，现今的这些控制系统是一个复杂的迷宫，由以人为中心的业务处理和定制的代码（如机票预定系统）组成。这些控制系统的自动化水平为所需的自主式自动化奠定了基础。让我们来了解一下智能控制系统。
智能控制系统
自主管理是自主计算的关键组成部分。它在概念上与网络管理类似，需要控制系统完成以下工作：
从系统各部件处收集信息。
从参与者处收集信息。
分析信息。
在分析的基础上决策。
根据需要调整系统的部件。
通知参与者关注变化。
让我们看一个电信网络故障处理的例子。以下的一系列步骤表明了当发生一次或多次的连接失败这一网络故障时所引发的业务处理流程。
网络故障
故障立案
创建故障单
故障根源分析
启动工作流程
排除故障
关闭故障单
该流程的第一步可能导致网络监控中心某个监视屏被刷新，或者呼叫到某个技术支持人员的呼机上――通过某种方式与在某个地方的某个人取得联系。
流程的下一步是全力解决该故障。故障可能是源于网络自身的不连续，或者由错误的开挖导致。如果是后者就会创建一个故障单。这个阶段将致力于确定该故障的根源所在。要记住一条光纤被切断可能会产生大量的网络警报，因此从如洪水般涌来的管理数据中找出关键信息需要花费时间。我们假定发生了光纤被切断的情况，此时有必要启动和跟踪一个特定的工作流程。通常需要派人去事故地点进行修复工作。一旦完成修复，故障单就被关闭。
图1所描述的业务流程可通过以下更为概括的词汇与控制系统相对应：
网络故障 -> 收集
故障根源分析 -> 分析
启动工作流程 -> 决策
排除故障 -> 调整系统部件
通知参与者 -> 及时联络用户（如发email、呼叫或文本消息）
这里要着重指出的是，大多数业务流程都可以采用类似于上述的方式由控制系统来运作。正如前面所说的，这些过程是可以自动化的。
其它控制系统
我们在日常生活中都用到了控制系统：加热/冷却系统、任何基于时间的电子设备、燃料加注系统等。闭环的控制系统总是与一种危险相伴：不稳定性。这在自动控制理论中是个众所周知的难题，受控单元（如加热系统）因逐渐发散而失去控制。这一难题对自主计算理念提出了严峻挑战。
自主计算的组成部分
控制系统包含了两个主要的自主化组件：
自主管理器
受控单元
图1是这些组件的示意图。有两个实体是自主管理器和受控单元共用的：传感器和效应器。传感器通过两者之一的方式收集特定单元的状态数据：轮询（或者说“获取”）或基于基准的通知。效应器提供了调整单元状态或配置的手段。传感器和效应器合在一起提供了一个可管理的接口。
图1 自主化组件：自主管理器和受控单元
自主管理器实现了控制系统并由四个部分组成，每个部分都共享一个公共知识库。这四个部分是：
● 分析：为收集到的数据建立对应关系。
● 计划：规定为实现与商业策略一致的特定目标所需要的操作。
● 监视器：收集、整合、过滤和报告从受控单元处得到的数据。
● 执行：允许按照计划对受控单元进行调整。
IBM 在其纽约Hawthorne 的Thomas J. Watson研究中心维护着一个自主计算的架构蓝图。
使软件可管理
我觉得ODC 中很吸引人的一个方面是它所提倡的软件单元的可管理性，它对 ODC 软件的开发方式产生了相当的影响。日志就是一个简单的例子：比方说我们想生成机器可读的日志。为什么会这样想？对了，理由之一是使下游的软件能读入日志数据。除了能让读日志的软件解读数据并提示可能出了什么问题之外，再也没有其它这么做的理由了。
这就是关闭人为管理环路并潜在地让软件开始动态处理其自身问题的开端。
商业策略驱动的计算
常见的策略驱动计算的例子涉及到网络服务质量；比方说，如果 CEO 和一个工程师都需要访问网络，那么会对CEO 的访问给予优先权。这个例子有点过时了，如今策略的应用已扩展到整个商业领域。比如一家厂商在一个竞争非常激烈的网上商城以价格 X 销售配件,此时出现一家新的厂商，在宣传中声称以比X 低 Y 的价格在线销售同样的配件。
如果第一家厂商的按需环境已形成并开始运作，那么他们就能自动将他们的价格调整为 X － Z 以继续竞争。价格调整的基础是策略，它可用一个条件反应语句来表示：
如果（（我们的价格－竞争者的价格） > 允许值） 则 调整我们的价格 下调
厂商们必须密切关注对方及许多其它的商业事件，如收益担保、成本管理、利润等。
商业永续基础设施也可被视为一种策略：
如果 （我们的站点1故障） 则 （将不能访问站点者转到站点2）
随着策略控制的场景数量增加，我们可能会看到更多类似的考虑，这样的策略对传统的IT基础设施（如非按需业务）来说是难以想像的。
提升IT投资回报率
如果公司有改善投资回报率的压力，那么执行官们渴望“榨干他们的 IT 资产”使其价值最大化也就不足为奇了。或许由自主计算带来的自动化会减少员工级别、提高收益，让 IT 员工去从事更复杂的业务核心工作。然而现今大多数的 IT 基础设施都是以独立的方式运作的，这让人想起存在于制造业部门中的“自动化孤岛”。公司对于 IT 集成的需求是迫切的，以便多个服务器协同工作获得商业价值。
Web 服务的应用使那些原本用于处理静态问题的资源更多地用于动态处理。所谓的静态问题，我是指那些以自动机票预定系统为例的情形。该例中主要的变量是客户的数量，例如，假定航班 X 提供了极具诱惑力的价格，那么它的网站就得准备接受非同寻常的高访问量，这件事在本质上是个静态问题。
IBM 目前将 ODC 战略视为两个领域的纽带：
● 自主计算
● 网格计算
我们已经讨论了前者，让我们再来简要了解一下网格计算。
网格计算问题
一种不同类型的计算难题是那些需要大量的处理，比如天气模式的建模、预测火山喷发、预测海啸、股票价格变化模型、分子建模等等。网格计算在这类问题中的应用日渐增长。网格也被作为外包IT设施的基础用于协作和使用；例如Oracle将在得克萨斯州奥斯汀子公司的一个巨大网格对外经营，公司客户能将软件应用外包给Oracle然后在需要时用网格来访问。
即使网格的费用看起来高昂（年费是百万美元），但通常少于客户自己拥有这些基础设施所需的花费。
自主化产品
IBM和Cisco已在一批项目上开展合作，一个引起关注的合作结晶是Cisco推出的名为CRS-1的新路由器，这是一台具备了自主计算能力的重要设备。
ODC的局限性
ODC项目可能存在的一个弱点是它是由厂商推动的，这意味着它可能受到厂商“产品升级”的意愿带来的负面影响。我的观点是，计算的未来主要是由网络化及网络访问来驱动，而不是处理能力。然而，这些见解必须由历史去检验，从中就可看出厂商已经非常成功地推动了技术的发展。这样的例子有：Sun与Java、Cisco和IP路由器、微软和Windows等等。因此只由一家公司来推动ODC的事实或许并不是件坏事。从另一方面讲，ODC是一种新式的生产和使用软件的方式。想从许多不同的厂商处购买或许不错，但这种情形不一定会出现。
结论
我们已经简要回顾了一组潜在强大的新技术。ODC 在集成方面引人注目――它采用了现有的技术、标准和规范并将它们融合为一个运营 IT 的全新方式。通过与网格计算结合，不难看出 ODC 在概念上与全球外包现象相类似。电信业在外包能力方面过去已有先例，比如象 MPLS 和 VPN 管理这样的精英领域。通过把局域网转交给训练有素的专业人员和资金充沛的服务提供商以甩开这些复杂的技术包袱，公司可节省费用并专注于核心工作。
不管 ODC 的出炉是否夹带了 IBM 的理念，其它的厂商也在做类似的主动尝试；Oracle已在其Oracle 10g 产品中加入了网格能力。此外，历史告诉我们，在技术大战之后通常会有一个绝对的胜者来引领下一次革命――微软赢得了桌面战争。我们将有希望看到一个 ODC 胜者的出现，有意思的是还没有一家公司能够连续引领两次革命浪潮――微软现在不再被视为创新的代表（现在它的股票均等地分配红利，它认定自己处于一个既定品牌拥有者的地位！），它在电信和游戏领域的出击也只被看作是寻求问题的解决方案。
我个人对于 ODC 的看法是它是非常必要的，我乐于看到的好处之一是它能缔造出更为简便的系统。倘若二十一世纪的头十年里充满了风险多变，就不再有选择的问题了。全世界会有足够数量的程序员来生产数以千计的软件包以满足全球技术市场。对于这么多的软件，或许从形式和功能上都需要一个新鲜的方式？也许 ODC 就能带来这些。
Stephen B. Morris 是爱尔兰Omey Communications 公司的 CTO。
↑返回目录
前一篇: 用Spring JMS使异步消息变得简单
后一篇: 如何在Web工程中实现任务计划调度