云计算呼唤基于事件的API

作者 Boris Lublinsky 译者 黄璜 发布于 2010年3月8日

领域

语言 & 开发,

架构 & 设计,

运维 & 基础架构,

企业架构

主题

活动 ,

SOA ,

云计算 ,

架构

引自 William Vambenepe的说法：

至少从发出第一个SNMP自陷起，事件/警报/通知在IT管理领域已经成为中心的概念，甚至有可能比这更旧远。然而它们在所有的云管理API/协议中神奇的蒸发了。

然而现今大部分云管理API都是基于轮询的。按照George Reese的说法，这样的轮询方式：

...造成的结果就是对CPU能力的极大的效率浪费...不仅是对云计算供应商，同时也会浪费双方的带宽。我们当然会进行各种优化以尽量避免轮询...[但]这一底线仍存在，无论如何，我们大多数的调用白白浪费了。

为了解决这一问题，Reeser提出一种事件驱动API的解决之道，由"云计算供应商通知我们所关心的资源的变更"，他可以还注意了该提案可能会遇到了一些挑战：

• 一个事件驱动的API要求一定层次的标准化，而这种标准化目前在云计算领域还不具备，你不能让每个消费者都设计他们自己的回调API，而且就算支持跨云系统的调用，每个云计算供应商设计其自己的回调协议仍然是有问题的。
• 你不能通过回调来提供数据，因为提供数据要求逆向的身份验证，这将会使整个流程复杂化。
• 最后，消费者无法完全信赖回调API。仍然需要创建自己的调用以验证云计算供应商在真实有效的合理运作。

对于这些挑战，Reese提出了一些简单的解决方案：

• 引入标准的回调格式(应当非常简洁，比如像这样[consumer-base]/[asset class]/[id])
• 将回调事件集成到现有的云API中。

基于他在WS-Notification系列规范方面的工作，Vambenepe强烈支持简单API的设想。按照他的观点，以云计算为中心的事件协议可以通过关注于少量的用例(仅针对云计算场景)而得以简化。在Vambenepe的观点中，以下的元素可以被用作云计算事件实现的根基：

• 事件的类型。客户端应当能够指明它所感兴趣的是什么类型的资源信息。

  你如何描述你所关心的变更？是否有一个达成一致的状态集，而对于资源你仅需要在状态转换才收到通知？你是否能够指明一个激发一个事情的最小严重性等级？...

  在Vambenepe看来WS-Topics展现了解决这一问题的最佳方案。
• 事件格式。云事件应当符合一个标准的事件模型定义：

  事件元数据是如何被捕捉的(如，观察的时间戳，也许与通知消息发出的时间不一样)？如果事件的负载是资源新状态的表示，那么它能否指明域的变更(原来的值是什么)？

• 订阅创建。需要创建一个标准的订阅机制，考虑如下问题：

  你需要变更订阅载体所用的过滤器吗？你能更改投递的端点吗？...来谁来设置过期时间？提供者能否设置最大的持续时间？是否能续订一个订阅...？如果你的订阅因为投递端点下线而失效了怎么办？...你订阅的时候能够提供一个单独的...订阅管理...端点(与事件投递端点区别开)吗？

• 投递机制。事件投递有许多选择，从永久性的开放HTTP连接(与COMET长轮询相似)到HTTP回调URL，以及AMQP,或是电子邮件。
• 安全。取决于投递机制，可能会需要不同的安全实现。
• 流量控制。一个事件实现应该保证，不管是资源还是消费者都不会被发出/接收到的事件洪流淹没。

如InfoQ早前曾为你报道过的那样，异步API对于云计算非常重要。引入完整的事件协议可以解决这一问题和附带的问题。希望这一规范的作者可以吸取WS-Notification的经验，创造出一个不以牺牲覆盖性和延伸范围的简单协议。

查看英文原文：The Need for an Event-based API in the Cloud

译者 黄璜 糊口靠的是Java Web，赶过SOA的潮，追过Cloud的风，真正欢喜的是Linux，向往的事情是研究网格计算。

• 更早的 >