关于Subscribe Rancher Events的思考

2016年2月14日「Rancher社区技术支持计划」全面启动，本文是Rancher研发人员在社区答疑过程当中关于Subscribe Rancher Events的一些心得和思考。

引言

几乎每一个大型的分布式的集群软件，都离不开同样东西，就是所谓的message bus（消息总线）， 它就如同人体的血管同样，连通着各个组件，相互协调，一块儿工做。 与不少同类软件不一样的是，Rancher使用的基于websocket协议实现的消息总线， Rancher不会依赖任何MQ，基于websocket的实现十分轻量级， 同时在各类语言库的支持上，也毫无压力，毕竟websocket是HTTP的标准规范之一。

初识Rancher Events

基于websocket的消息总线能够很好的与前端兼容，让消息的传递再也不是后端的专利。 在Rancher UI上，很容易就能捕获到rancher events，好比：

这里面监听的事件名称是resource.change，这个resource.change在前端UI上有很大的用处， 其实咱们都知道，不少POST形式的create请求并非同步返回结果的，由于调度引擎须要处理， 这个等待的过程当中，固然不能前端一直wait，因此作法都是发起create后直接返回HTTP 202， 转入后台执行后，Rancher的后端会把建立的执行过程当中间状态不断发送给消息总线， 那么前端经过监听resource.change就会得到这些中间状态，这样在UI上就能够给用户一个很好的反馈体验。

固然Rancher Events并非只有resource.change，好比在Iaas Events集合中就有以下这些：

除了Events的事件定义，固然还有如何去subscribe 这些events，这部份内容在以前的文章Rancher event机制及其实践指南中有所涉猎，便不赘言。

Subscribe Rancher Events的架构模式

Rancher的体系内，不少微服务的组件都是基于Subscribe Rancher Events这种架构，举个例子来看， 以rancher-metadata组件为例：

metadata服务能够提供当前host的元数据查询，咱们能够很容器的知道env内的stack/service/container的状况， 这些数据其实由rancher-server也就是cattle引擎生成的，那么生成以后怎么发送给各个agent呢？ 其实就是metadata进行了subscribe rancher events，固然它只监听了config.update事件， 只要这个事件有通知，metadata服务便会下载新的元数据，这样就达到了不断更新元数据的目的。

随着深刻的使用Rancher，确定会有一些伙伴须要对Rancher进行扩展，那就须要自行研发了， 毕竟常见的方式就是监听一些事件作一些内部处理逻辑，并在DB中存入一些数据， 同时暴露API服务，架构以下：

若是须要作HA，可能须要scale多个这样的服务，那么架构就变成这样：

这里其实会有一个问题，若是你监听了一些广播事件，那么实际上每一个实例都会收到一样的事件， 那么你的处理逻辑就要注意了，尤为是在处理向DB中写数据时，必定要考虑到这样的状况。

好比，能够只有其中一个实例来监听广播事件，这样不会致使事件重复收取：

Event Handler要考虑必定failover机制，这样事件收取不会长时间中断。

Rancher Events有一些非广播事件，那么就须要在subscribe的时候指定一些特殊参数， 这样事件就会只发送给注册方，不会发送给每一个节点，好比：

总结

此文算是这段时间作Rancher服务扩展的心得，深度参与一个开源软件最终确定会但愿去改动它扩展它。 这也是客观需求所致，开源软件能够拿来即用，可是真正可用实用，必须加以改造，适应自身需求。