關於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服務擴展的心得，深度參與一個開源軟件最終確定會但願去改動它擴展它。 這也是客觀需求所致，開源軟件能夠拿來即用，可是真正可用實用，必須加以改造，適應自身需求。