運維與業務的系統設計差異

運維繫統更適合 HTTP 而非 gRpc 。

熟悉 HTTP 的運維、研發人員比其他協議的人多。在掌握 HTTP 協議的基礎上，學習 Restful 風格的 HTTP API 很快。更多人熟悉、更易於學習，意味着更好溝通、更低的交接成本，因爲他們有着更多共同的領域背景。

支持 HTTP 調試的工具非常多。無論是瀏覽器，還是各種插件，命令行工具，都可以很方便地調試接口。

系統集成方便。運維人員擅長的是 Shell、Python 等腳本語言，調用一個 HTTP 接口很容易，而不用生成 gRPC Client 進行編程。系統集成的成本低意味着你提供的服務會得到更多使用。

對於運維繫統來說，清晰、簡單、兼容性好的通信協議更加重要，而不必強調性能，這與業務系統有着顯著差異。

運維繫統更適合集中管理數據，而非分散管理數據。

可以將運維繫統認爲是整個公司系統的控制平面，而業務系統認爲是整個公司系統的數據平面。控制面承載的是控制指令，應用怎麼部署、流量怎麼走、服務異常時怎麼處理等。而數據面承載的是業務用戶的數據，瀏覽頁面、下載圖片、上傳視頻等。

運維繫統會對權限、安全、審計等有着比較高的要求，集中管理數據能夠很好地滿足這一點。而業務存儲的是用戶數據，爲了合規不能跨國家跨地區傳輸，只能分散就地存儲。

需要強調的是一般的運維繫統併發量不大，能有 10K 臺機器的公司就已經頗具規模。如果只是考慮人使用，運維繫統能夠支撐 1K 的 PV 就足以滿足絕大多數公司的需求。運維繫統對擴展性的要求比業務系統低很多。

運維繫統選的是 CP，犧牲部分可用性；業務系統選的是 AP，犧牲部分一致性。

運維繫統對一致性要求更高，寧可接口響應慢一點，也一定要同步地完成各種檢測，再返回接口，確認調用成功。否則應該立即回滾，並提示用戶。

而業務系統會更在乎用戶體驗，大多數場景下能夠直接返回結果，將任務丟到隊列中異步處理。

在開發運維繫統時，應該基於最少的約束和規則進行設計，再考慮其他細節。

運維繫統比業務系統複雜很多，運維繫統是 ToB 的，而業務系統是 ToC 的。ToC 的產品最終是面向整個人羣的，而 ToB 的產品最終是面向垂直領域的，需要閱讀文檔、反覆嘗試才能熟練。因此 ToB 通常還會伴隨着一個培訓市場，對 ToB 的用戶進行指導、答疑、提供解決方案等。

但運維繫統的簡潔並不容易，得提升到設計理念的層次，並始終能用這套理念指引系統的設計。這就對團隊提出了很高的要求，否則整個產品體系就會顯得雜亂無章，用戶使用起來也會毫無頭緒。想象一下，如果需要進行一次變更，一會兒是命令式，一會兒是聲明式，用戶使用時得多麼迷惑。

因此在運維繫統設計之初，就要將簡潔放在第一位，這是爲了抵消因滿足業務需求引入的複雜性。

對於運維繫統，即使採用 ESB 的架構也是足夠的，不必強調微服務，更不要談網格。複雜度的增加是各種問題的根源。

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