關(guān)于Subscribe Rancher Events的思考

yuxue 發(fā)布于2019-06-28 15:38 / 3457人閱讀

摘要：年月日社區(qū)技術(shù)支持計(jì)劃全面啟動(dòng)，本文是研發(fā)人員在社區(qū)答疑過(guò)程中關(guān)于的一些心得和思考。初識(shí)基于的消息總線可以很好的與前端兼容，讓消息的傳遞不再是后端的專(zhuān)利。

2016年2月14日「Rancher社區(qū)技術(shù)支持計(jì)劃」全面啟動(dòng)，本文是Rancher研發(fā)人員在社區(qū)答疑過(guò)程中關(guān)于Subscribe Rancher Events的一些心得和思考。

引言

幾乎每個(gè)大型的分布式的集群軟件，都離不開(kāi)一樣?xùn)|西，就是所謂的message bus（消息總線），它就如同人體的血管一樣，連通著各個(gè)組件，相互協(xié)調(diào)，一起工作。與很多同類(lèi)軟件不同的是，Rancher使用的基于websocket協(xié)議實(shí)現(xiàn)的消息總線， Rancher不會(huì)依賴任何MQ，基于websocket的實(shí)現(xiàn)十分輕量級(jí)，同時(shí)在各種語(yǔ)言庫(kù)的支持上，也毫無(wú)壓力，畢竟websocket是HTTP的標(biāo)準(zhǔn)規(guī)范之一。

初識(shí)Rancher Events

基于websocket的消息總線可以很好的與前端兼容，讓消息的傳遞不再是后端的專(zhuān)利。在Rancher UI上，很容易就能捕獲到rancher events，比如：

這里面監(jiān)聽(tīng)的事件名稱(chēng)是resource.change，這個(gè)resource.change在前端UI上有很大的用處，其實(shí)我們都知道，很多POST形式的create請(qǐng)求并不是同步返回結(jié)果的，因?yàn)檎{(diào)度引擎需要處理，這個(gè)等待的過(guò)程中，當(dāng)然不能前端一直wait，所以做法都是發(fā)起create后直接返回HTTP 202，轉(zhuǎn)入后臺(tái)執(zhí)行后，Rancher的后端會(huì)把創(chuàng)建的執(zhí)行過(guò)程中間狀態(tài)不斷發(fā)送給消息總線，那么前端通過(guò)監(jiān)聽(tīng)resource.change就會(huì)獲得這些中間狀態(tài)，這樣在UI上就可以給用戶一個(gè)很好的反饋體驗(yàn)。

當(dāng)然Rancher Events并不是只有resource.change，比如在Iaas Events集合中就有如下這些：

除了Events的事件定義，當(dāng)然還有如何去subscribe 這些events，這部分內(nèi)容在之前的文章Rancher event機(jī)制及其實(shí)踐指南中有所涉獵，便不贅言。

Subscribe Rancher Events的架構(gòu)模式

Rancher的體系內(nèi)，很多微服務(wù)的組件都是基于Subscribe Rancher Events這種架構(gòu)，舉個(gè)例子來(lái)看，以rancher-metadata組件為例：

metadata服務(wù)可以提供當(dāng)前host的元數(shù)據(jù)查詢，我們可以很容器的知道env內(nèi)的stack/service/container的情況，這些數(shù)據(jù)其實(shí)由rancher-server也就是cattle引擎生成的，那么生成之后怎么發(fā)送給各個(gè)agent呢？其實(shí)就是metadata進(jìn)行了subscribe rancher events，當(dāng)然它只監(jiān)聽(tīng)了config.update事件，只要這個(gè)事件有通知，metadata服務(wù)便會(huì)下載新的元數(shù)據(jù)，這樣就達(dá)到了不斷更新元數(shù)據(jù)的目的。

隨著深入的使用Rancher，肯定會(huì)有一些伙伴需要對(duì)Rancher進(jìn)行擴(kuò)展，那就需要自行研發(fā)了，畢竟常見(jiàn)的方式就是監(jiān)聽(tīng)一些事件做一些內(nèi)部處理邏輯，并在DB中存入一些數(shù)據(jù)，同時(shí)暴露API服務(wù)，架構(gòu)如下：

如果需要做HA，可能需要scale多個(gè)這樣的服務(wù)，那么架構(gòu)就變成這樣：

這里其實(shí)會(huì)有一個(gè)問(wèn)題，如果你監(jiān)聽(tīng)了一些廣播事件，那么實(shí)際上每個(gè)實(shí)例都會(huì)收到同樣的事件，那么你的處理邏輯就要注意了，尤其是在處理向DB中寫(xiě)數(shù)據(jù)時(shí)，一定要考慮到這樣的情況。

比如，可以只有其中一個(gè)實(shí)例來(lái)監(jiān)聽(tīng)廣播事件，這樣不會(huì)導(dǎo)致事件重復(fù)收?。?/p>

Event Handler要考慮一定failover機(jī)制，這樣事件收取不會(huì)長(zhǎng)時(shí)間中斷。

Rancher Events有一些非廣播事件，那么就需要在subscribe的時(shí)候指定一些特殊參數(shù)，這樣事件就會(huì)只發(fā)送給注冊(cè)方，不會(huì)發(fā)送給每個(gè)節(jié)點(diǎn)，比如：

總結(jié)

此文算是這段時(shí)間做Rancher服務(wù)擴(kuò)展的心得，深度參與一個(gè)開(kāi)源軟件最終肯定會(huì)希望去改動(dòng)它擴(kuò)展它。這也是客觀需求所致，開(kāi)源軟件可以拿來(lái)即用，但是真正可用實(shí)用，必須加以改造，適應(yīng)自身需求。