级别： 初级 Alfredo Da Silva (afdasilv@us.ibm.com), Advisory Software Engineer, IBM
2003 年 7 月 01 日 自主运算是一个新的时髦口号。然而，没有多少人提供一个关于这项技术是什么的实际证明，来解释这个大肆宣传的技术。在本文中，Alfredo Da Silva讨论了一个具体的实现，显示了自主运算是多么的有用。
自主运算101
复杂性以及高昂的安装和维护费用是今天的计算机系统中存在的一个事实。主要原因在于它们是用来满足其所有者和用户的特殊需求。一旦这些系统由几个不同的组件构成——硬件、中间件（例如Tomcat和WebSphere Application Server）和应用程序——那么管理费用将比获得这些组件本身的费用要高。
这些问题可用自主运算模型来解决。这种模型提议系统对环境和工作量改变有弹性，在失败和发生错误时自我愈合并且主动防范攻击，通过该方法大大降低总体管理费用。
为了达到这个被提议的目标，自治系统可以划分成四个不同的方面，如
图1。
预想的用于部署一个自治解决方案的环境应该有一个反馈控制系统，它能监控和收集数据、分析收集的数据、计划必须的修改，然后将这些修改作用在底层的组件上。
为了使得这样一个系统具有可行性，必须使用系统内部数据流的一个公用的表示，那就是Common Base Event（CBE）（参见
参考资料）。CBE提供一个一致的方式在完全不同的企业应用程序之间传递公有信息，这些企业应用程序支持登录、管理、问题确定、自主运算和电子商务功能。它的设计呈现出下面一些优点：数据表现为一种公有的和可理解的格式、公有的消息集和简单的标准接口。要了解更多关于这个主题的全面的讨论，请参考
参考资料部分。
自主运算的两个方面
该特征化的demo实现了自主运算的两个方面，如
图1所示：包括自愈合和自优化。
图2演示了第一个方面。
自愈合方面
从底部的App server组件开始然后顺时针方向移动。事件旁边的数字指示了它们的顺序。
-
App server -- 该部件管理所有运行的应用程序。它同时负责它们的启动和停止（这个特定功能可由外部控制）。
-
Log file -- 这个文件存储由App server生成的事件，由App server在每次应用程序启动或停止时产生。这些条目的格式由WebSphere showlog文件定义。
-
Sensor -- 它执行对日志文件的监视，并且，每当添加一条新的状态改变条目到日志文件中，便利用Broker（代理）发布一个
StateChange 主题。它使用一个叫做acadapter的组件来执行该任务（参见
参考资料）。
-
Broker -- 它表现为一个基于主题的pub/sub通知引擎。它的工作方式是使用代理发布主题。在该场景中，Sensor和M.A.P.E. Loop是发布者（它们分别地发布
StateChange 和
Restart 主题）。如果一个组件希望在每次有一个特定的主题发布时接收通知消息，它应该向代理程序订阅。代理程序负责保持订阅者列表并在每次有一个主题发布时确保所有订阅者收到通知消息。
-
M.A.P.E. loop -- 这是该系统地大脑。该缩写代表Monitor、Analyze、Plan和Execute。向代理程序订阅以收到
StateChange 通知消息。分析接收到的数据并决定是否发布一个
Restart 主题。它是基于ABLE框架的（参见
参考资料）。
-
Effector -- 该部件和App server交互，将发生故障的应用程序恢复到其运行状态。订阅以接收restart通知消息，每个接收到消息的组件发送一个
Restart 消息到App server。
该设计支持自主运算自愈合能力。每当探测到一个停止的应用程序，系统能够采取必要的步骤重新启动它。
图3描述自优化方面。
自优化方面
在
图3中，
AppNotBusy 流用绿色显示，
AppTooSlow 流用红色显示。如前，图中的数字指示事件的顺序。压力发生器可随时产生请求。
上述组件维护前面描述的主要行为，区别如下：
- App server -- 负责根据接收到的命令删除和添加应用程序。它也监控应用程序有多忙和一个
AppNotBusy 基于压力发生器组件产生的请求的数目。
-
Broker -- 在该场景中App server、EPP和M.A.P.E. Loop是发布者（它们发布各自的
AppNotBusy 、
AppTooSlow 、
Add App 和
Remove App 主题）。
-
M.A.P.E. Loop -- 向代理程序订阅以接收
AppNotBusy 和
AppTooSlow 通知消息。分析接收到的数据并决定是否发布各自的
Add App 或
Remove App 主题。
-
Effector -- 和App server交互以增加或删除应用程序。订阅以接收
Add App 和
Remove App 通知消息，并且每个接收到消息的组件发送一个
Add App 或
Remove App 消息到App server。
-
Stress Generator -- 模拟加载由App server管理的应用程序。
-
End-to-End Problem Platform (EPP) -- 测量一个发送给App server的请求的响应时间。在响应时间超过预置的临界值（1秒）时，它产生
AppTooSlow 通知消息。
这个设计支持自主运算自优化能力，因此响应时间的测量是持续的，（当EPP运行时），为了根据预先设定的参数维护响应时间，应用程序或被创建或被销毁。
让它运行起来
这个demo可用作IBM Emerging Technologies Toolkit (ETTK)的一部分（参见
参考资料）。一旦安装和配置好了ETTK，遵循下列步骤就可以使你的应用程序建立起来并运行：
- 启动被选中的App server。将你的Web浏览器指向http://host:port/actk/appHO/client/demo.html，将主机和端口替换成在配置toolkit时使用的值。
- 将你的Web浏览器指向
http://host:port/actk/appHO/client/demo.html，将主机和端口替换成在配置toolkit时使用的值。
该demo由一个Web页组成，该页有两个帧，每一个中包容了一个Java Applet。左边的Applet有一个分割成两个区域的panel。上面的区域中有包含所有该App server管理的应用程序的
Application Table。每一行显示一个应用程序，并且包含一个停止按钮允许直接的用户交互。下面的区域中有一个文本框，以简单的文本格式显示由系统产生的主要事件。
一个按钮，
Clear history，用于清除文本框中的内容，一个复选框，
Randomly stop applications，用于将该demo置入一个循环模式中，每10秒钟便随机的选择一个正在运行的应用程序并将其停止。在后面讨论自愈合时将谈到其他的控件。
右边的Applet名为
Event Viewer。它有两个面板：
Image Panel和
Text Panel。Image Panel显示在
图2中示出的部件以及事件流。Text Panel的内容在下面讨论。在下面的区域中有一组按钮可用：
Clear Display、
Set Delay ...、
Record ...、
Playback ...和
Delete ...。它们其中的三个按钮（
Record、
Playback和
Delete）允许创建、执行和删除一个包含了捕获事件的文件。
Clear Display按钮删除所有显示的事件流同时删除所有包含在Text Panel中的信息。
Set Delay按钮设置显示刷新间隔（它的缺省值是2秒）。
探讨自愈合行为
当该demo启动时，Application Table被处于运行状态（绿灯）的appId 0填充；当处于空闲状态，请求表示器（在灯旁边的小图标）是空的。每个应用程序在该模拟过程中可以处理三个并发的请求。
如果按下相应的停止按钮，会产生一个
StateChange 通知消息，并且会调用一个
Restart 动作，将应用程序恢复到运行状态，这一点在前面已经讲到了。当按下
Start loop按钮，也会触发类似的行为。唯一不同的是会每隔10秒自动的停止应用程序。
图4示出了所描述的事件流。
探讨自优化行为
左边的Applet下半部分是和这个行为相关的控件：
Enable EPP Performance monitor复选框、
Number of Clients滑块和
Average client response time指示器。EPP测量发送到App server的请求的响应时间，如果这个时间超过1秒（以红色显示），由于
Number of Clients滑块被移到右边，会生成一个
App Too Slow通知消息，并且发送一个相应的
Add App动作到App server，请求创建附加的应用程序来处理负载。
图5显示了这个场景。
当负载减少，增加的应用程序处于空闲，并被请求指示器和
Average client response time指示器（现在变回到黑色）察觉到，指示值少于或等于1秒，App Server检测该场景并发送一个
AppNotBusy 通知消息给代理程序（broker）。一个
Remove app 动作作为结果返回到App Server以删除空闲应用程序。即使没有负载，App id 0永远不会被删除。该机制如
图6所示。
在任何时候，如果
Event Viewer - Text Panel tab被选中，一个包含所有已交换的CBE消息的列表会以一个可展开的树格式显示，如
图7所示。
总结
有一点我们可以肯定，那就是随着时间的发展计算机系统的复杂性和相关成本只会增加不会减少。自主运算看起来似乎是解决这些问题的一个可行的方案。自主运算从这些问题的核心出发，它拥有传递处理配置的职责、优化和保护计算机系统的能力，更不用说长期期盼的拥有自知系统能力。
该demo通过可视化的结合实践的方式探讨了自主运算的两个关键方面：自愈合和自优化。它证实了实现一个自主运算方案的所有必须的方面都已具备，该技术今天就可以变成现实。
参考资料
关于作者  | 
| | Alfredo da Silva是IBM的一位软件开发人员。他是负责IBM Emerging Technologies Toolkit（ETTK）小组的一员。你可以通过afdasilv@us.ibm.com与他联系。 |
对本文的评价
| 
