本文主要是介紹 MOSN 在無人值守變更上的實踐以及過程中的一些思考。主要分爲 3 個部分： -介紹 MOSN 在規模化運維中遇到的挑戰 -無人值守上的實踐 -MOSN 與技術風險方面的思考
MOSN 規模化後的運維挑戰
MOSN 早期在內部推進的時候，變更方面的支持是比較傳統的。早期的變更工具只有基礎的 pod 粒度的 MOSN 升級的能力。變更過程中的問題，最初依賴於上層業務系統的監控和反饋，稍後我們又在 MOSN 內建設了錯誤碼。發佈控制上，將版本區分爲穩定版和灰度版本，升級的灰度過程和大範圍的覆蓋過程都由人工控制。這些方式在小範圍、大量人力投入的情況下，保證了 MOSN 早期的快速演進和範圍覆蓋，也兼顧了基本的穩定性需求。
隨着MOSN的成熟，MOSN的接入規模快速增長到了覆蓋多個技術棧，數千應用的數十萬 pod，涉及螞蟻內部幾乎所有的業務，早期的這些做法也遇到了很多問題。我們接入的應用不再只是 SOFA 技術棧的某些版本，業務也不再侷限在某幾條鏈路，大範圍變更影響範圍數倍甚至數十倍增長，風險變得極高，需要投入大量的人力評估每一個版本變更的影響。
MOSN 的無人值守變更
關於無人值守，一個可以借鑑的定義來源於近年火熱的自動駕駛領域。同樣都是希望把人從乏味的工作中解放出來，同樣都需要面臨複雜的環境問題。
也就是圖上標紅的這些內容。
但是人本身是不可靠的。人爲控制變更範圍意味着灰度過程無法保證，准入的檢查會存在比如信息不同步，規則遺漏的情況，完成情況的檢查在大量應用或 pod 同步變更時，也只能做到少量抽檢，無法避免問題被漏過。
把人工介入的部分交給系統，我們就有了一個初步可以脫離手動操作和人工觀察的流程。
上圖展示了變更防禦的介入流程。
仔細來看業務的錯誤檢查。這些檢查不僅說明了 MOSN 自身的檢查，還包括了業務的自身的錯誤和其它中間件、基礎設施的問題。這些檢查無法直接說明 MOSN 自身的健康情況。怎麼解決呢？我們決定不再依賴這個不靠譜的檢查，由 MOSN 自己來說明自己的健康情況。
我們在 MOSN 中建設了兩個層面的健康度觀測能力。第一層是靜態健康度，主要是 MOSN 的啓動自檢，在流量進入前完成，體現 MOSN 運行環境和基本啓動依賴的健康情況；第二層是動態健康度，主要是 error metrics 日誌，體現核心功能運行狀態。結合這兩層健康層，MOSN 就具備了完整了自身狀態的觀察能力，可以把業務的錯誤檢查從變更檢查中移除。
我們還做了一個進一步提升變更效率的事情，徹底解決業務冷啓動消耗的時間。
無論是傳統的原地升級或者是滾動升級的模式，過程都無法避免業務需要冷啓動。由於業務依賴比較多，大部分業務的啓動速度和成功率是大幅低於 MOSN 的，因此業務的冷啓動時間一直是 MOSN 變更時間的大頭。
稍微解釋一下的 MOSN 熱升級過程。sidecar operator 會給待升級的 pod 注入一個新版本的 MOSN sidecar，舊版本的 MOSN 會收到連接遷移的請求，所有的長連接會被新版本的 MOSN 接管，完成之後舊版本 MOSN 會停止，sidecar container 被刪除。
熱升級是一個很理想的升級方式，但是完善的熱升級需要的條件和環境都比較複雜，需要 k8s 和 operator 的相應支持，而且被遷移的長連接需要同步的遷移狀態，對於 MOSN 內的有狀態協議也帶來比較大的研發壓力。
原來割裂的各個部分，在研發側由 CI 驅動產出 nightly 版本，然後由 CD 平臺驅動一直推進到生產。我們在持續的建設自動變更推進和變更自主決策的能力，向 L5 手機可關機的變更方向演進。
MOSN 技術風險的思考與方向
舉個盒子來說，我們在 MOSN 上建設了秒級自愈的能力，依賴於 MOSN 最接近於業務流程的特點，實現了在業務局部有損時秒級響應止損的能力。下圖展示了秒級自愈的流程。
類似長在 MOSN 的技術風險能力還包括 chaos mesh 的能力，自適應限流的能力等等。對於上層業務，MOSN 越來越成爲整體技術風險能力的重要組成部分。
另一方面，技術風險能力的持續提升要讓 MOSN 更穩更快。我們在持續建設更完善的 MOSN SLO 能力，更精準的判定 MOSN 的問題，從而建設變更流程中的自主決策能力，例如變更出現問題時的自主回滾；我們也在完善 MOSN 的持續發佈能力，向月度發佈演進，邁向 L5 無人值守。
MOSN：https://github.com/mosn/mosn
歡迎 Star～
延伸閱讀
本文分享自微信公衆號 - 金融級分佈式架構（Antfin_SOFA）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。