使用事件總線改造運維體系

  1. 積重難返的運維服務體系

針對明確的運維訴求，開發相應的運維服務以供運維、業務用戶使用，本無可厚非。但如果僅滿足於此，很容易出現下面的情況:

用戶頻繁地尋找各個系統的入口，在各個系統之間來回跳轉，忙於尋找各種按鈕、拷貝參數。

一旦這樣的運維服務多起來，形成一個運維服務體系之後，更是積重難返。想變更，耦合太深，成本很高；想重構，缺少動力，風險很大。

能不能用？可以用！

好不好用？不太好用！

這樣一個運維體系，是很難自救的，幾乎不可能依靠內部的迭代完成升級。我指的升級，是指達到一個更先進的運維平臺水平。

怎樣的運維平臺更先進？可以從以下幾個方面考慮:

運維圍繞的是安全、穩定、高效、成本。成本不受運維平臺控制，安全、穩定是運維平臺的及格線，真正能使得上力氣的其實只有效率。

運維平臺的最終目標是支撐業務，獲得更大的比較優勢。好的方面是公司競爭的賽點是不斷切換的，去年是 VR，今年是 OpenAI，這樣就會對平臺不斷地提出新要求。需要思考的是，運維平臺能不能快速地滿足當前業務的運維訴求？

競爭對手需要 3 個月上線，如果你只需要 2.9 個月，那麼公司就多了 0.1 個月的先發優勢，逐步積累就能走得更遠。

相關平臺建設的論述在之前的博文中已經有很多，在此不再過多討論。

回到剛纔提到的積重難返的運維服務體系，這種情況下，只能藉助外力破局。引入一個外部的運維體系產品，從外部招一批帶着先進生成技術和理念的人，還需要負責人極大的魄力，纔有可能實現平臺飛躍。

  1. 使用事件總線破除 SaaS 的信息壁壘

用戶在不同的運維體系之間切換、操作時，到底在做什麼？

是事件的觸發，事件的流轉，只不過，這些都是人工完成的。

是人在支撐着，完成了各個 SaaS 之間的信息流轉。這樣的運維體系下，用戶使用很累，不得不來回切換，學習各種領域知識；平臺開發更累，服務之間集成很難，安全風險大，還得教會用戶使用、傳輸各種領域知識。

但只有引入外部系統，引發內部系統崩潰，重建運維體系一條路嗎？

當然不是隻有一條路線。如果是早期，體量不大時其實可以考慮基於某個成熟的運維平臺體系進行開發。一旦業務體量達到一定程度，必然不會接受外部產品全盤接收核心運維體系。

這裏提出的另外一條路線就是事件總線。

用戶需要一個新的工作臺 SaaS，用於產生各個子系統需要的事件並下發到事件總線，再推送到各個子 SaaS 系統。每個運維繫統都應該對接事件總線，既消費事件，也產生事件。

爲此，除了實現事件總線，基本的路由、過濾等功能，還需要能快速接入舊的 SaaS 。如下圖:

爲了快速接入，需要實現兩個核心的對接，一個是各系統需要的 API Middleware，以便於產生事件；另一個是，API Action，以便 SaaS 能根據事件通過 API 執行動作。

最終，在統一的事件協議（例如 CloudEvents）整合下，實現系統之間的松耦合，再也不用考慮依賴的 SaaS 接口發生變更導致的各種集成問題了。

  1. 事件總線更適合人的工作方式

技術是爲人服務的，人不應爲技術所累。如果累，那麼你就應該反思，是不是合理的，能不能改進，有沒有機會。

事件總線實現了關注點分離，是適合人的工作方式。

每個系統只需要關注事件總線的消息，而不用關注其他系統的可用性，可靠性。每個系統的研發人員，也只需要專注於自己維護的系統。

實時性高的場景，可以讓事件總線主動 push 消息；其他場景，各個系統可以 pull 訂閱的事件消息，各自完成任務，然後將結果事件寫回到事件總線。

更爲重要的是，事件總線爲運維演進提供了合適的方向。

基於事件總線的運維體系，既能夠滿足業務早期人工的訴求，也能夠滿足後期自動化需求。

業務早期體量小，爲了能夠快速上線，會有大量人工運維操作。通過事件總線，可以很好的將任務進行分類，以 TodoList 的面板形式展示給人工運維。

業務走向成熟後，必然走向運維的自動化。此時只需要通過腳本、命令行工具、SaaS 等任意自動化形式快速消費事件，即可高效地運維。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/XIhaMF1VE0IQzSZZuIwpZA

猜你喜歡