说法:至少从发出第
个SNMP自陷起
事件/警报/通知在IT管理领域已经成为中心概念甚至有可能比这更旧远
然而它们在所有云管理API/协议中神奇蒸发了
然而现今大部分云管理API都是基于轮询按照George Reese说法这样轮询方式:...造成
结果就是对CPU能力极大效率浪费...不仅是对云计算供应商同时也会浪费双方带宽我们当然会进行各种优化以尽量避免轮询...[但]这底线仍存在无论如何我们大多数
白白浪费了
为了解决这问题Reeser提出种事件驱动API解决的道由"云计算供应商通知我们所关心资源变更"他可以还注意了该提案可能会遇到了些挑战:个事件驱动API要求定层次标准化而这种标准化目前在云计算领域还不具备你不能让每个消费者都设计他们自己回调API而且就算支持跨云系统每个云计算供应商设计其自己回调协议仍然是有问题 你不能通过回调来提供数据
提供数据要求逆向身份验证这将会使整个流程复杂化 最后消费者无法完全信赖回调API仍然需要创建自己以验证云计算供应商在真实有效合理运作
对于这些挑战Reese提出了些简单解决方案:引入标准
回调格式(应当非常简洁比如像这样[consumer-base]/[as
]/[id]) 将回调事件集成到现有云API中
基于他在WS-Not
ication系列规范标准方面工作Vambenepe强烈支持简单API设想按照他观点以云计算为中心事件协议可以通过关注于少量用例(仅针对云计算场景)而得以简化在Vambenepe观点中以下元素可以被用作云计算事件实现根基:* 事件
类型客户端应当能够指明它所感兴趣
是什么类型资源信息 你如何描述你所关心变更？是否有个达成致状态集而对于资源你仅需要在状态转换才收到通知？你是否能够指明个激发个事情最小严重性等级？...在Vambenepe看来WS-Topics展现了解决这问题最佳方案 *事件格式
云事件应当符合
个标准事件模型定义: 事件元数据是如何被捕捉(如观察时间戳也许和通知消息发出时间不样)？如果事件负载是资源新状态表示那么它能否指明域变更(原来值是什么)？*订阅创建
需要创建
个标准订阅机制考虑如下问题: 你需要变更订阅载体所用过滤器吗？你能更改投递端点吗？...来谁来设置过期时间？提供者能否设置最大持续时间？是否能续订个订阅...？如果你订阅投递端点下线而失效了如何办？...你订阅时候能够提供个单独...订阅管理...端点(和事件投递端点区别开)吗？*投递机制
事件投递有许多选择
从永久性开放HTTP连接(和COMET长轮询相似)到HTTP回调URL以及AMQP,或是电子邮件 *安全
取决于投递机制可能会需要区别安全实现 *流量控制
个事件实现应该保证不管是资源还是消费者都不会被发出/接收到事件洪流淹没 如InfoQ早前曾为你报道过
那样异步API对于云计算非常重要引入完整事件协议可以解决这问题和附带问题希望这规范标准作者可以吸取WS-Notication经验创造出个不以牺牲覆盖性和延伸范围简单协议
最新评论