作者：黃家琦
來源：金融級分布式架構公衆号
本文主要是介紹 MOSN 在無人值守變更上的實踐以及過程中的一些思考。主要分為 3 個部分：
-介紹 MOSN 在規模化運維中遇到的挑戰
-無人值守上的實踐
-MOSN 與技術風險方面的思考
MOSN 規模化後的運維挑戰
MOSN 早期在内部推進的時候，變更方面的支援是比較傳統的。早期的變更工具隻有基礎的 pod 粒度的 MOSN 更新的能力。變更過程中的問題，最初依賴于上層業務系統的監控和回報，稍後我們又在 MOSN 内建設了錯誤碼。釋出控制上，将版本區分為穩定版和灰階版本，更新的灰階過程和大範圍的覆寫過程都由人工控制。這些方式在小範圍、大量人力投入的情況下，保證了 MOSN 早期的快速演進和範圍覆寫，也兼顧了基本的穩定性需求。
随着MOSN的成熟，MOSN的接入規模快速增長到了覆寫多個技術棧，數千應用的數十萬 pod，涉及螞蟻内部幾乎所有的業務，早期的這些做法也遇到了很多問題。我們接入的應用不再隻是 SOFA 技術棧的某些版本，業務也不再局限在某幾條鍊路，大範圍變更影響範圍數倍甚至數十倍增長，風險變得極高，需要投入大量的人力評估每一個版本變更的影響。
舉個例子，早期的 MOSN 幾乎隻需要考慮與較新版本的 SOFA 的對接。而當 node.js 應用開始接入時，MOSN 的變更也需要相應的考慮對 node.js 應用的影響。
同樣是為了減小風險，變更過程中盡可能減少機關時間的可能的影響範圍，變更時長不可避免被拉長。
早期的 MOSN 可能隻需釋出數十個應用，當範圍擴大到過千時，如果機關時間釋出的 pod 資料不變，那麼變更時長即增加數十倍，變更的總時長變得荒謬。而如果總時長不變，則影響面和風險增加數十倍，風險不可控，業務也無法接受。
最終結果是平衡機關時間的影響面和變更時長，風險放大無法避免，整體的疊代周期同樣變長。更糟糕的是，新的特性不斷堆積在下一個大版本，bugfix 也難以及時上線。這些問題最終不僅推高了下一次變更的風險，甚至直接影響目前生産的穩定。
這麼一個負向的循環需要如何打破呢。我們希望跳出傳統的運維模式，既要變更的高效率，又要整體的穩定性。我們希望用技術來解決問題。
MOSN 的無人值守變更
關于無人值守，一個可以借鑒的定義來源于近年火熱的自動駕駛領域。同樣都是希望把人從乏味的工作中解放出來，同樣都需要面臨複雜的環境問題。
自動駕駛領域的等級定義方式也給了無人值守變更一個很好的參考點。最低級别的是 L0，一切都是人工操作，像雲時代之前的時代，從裝系統到應用部署，都依賴于人工指令行處理。
然後是 L1，平台提供了原子粒度的變更工具支援和基礎的觀察工具支援，如同早期的 MOSN。
當這些工具更完善，提供一些基本的流程編排能力之後，開始進入自動化的時代，但可能随時需要人工介入處理。在此基礎上，加上自動化的觀測規則，把人工觀察介入變成系統自動阻斷，變更開始具備了無人值守的基本能力。
曆經一年多的演進，MOSN 目前就處于這個階段。我們也還在持續的完善和打磨，向着完全無人幹預的方向演進。
接下來我們來看 MOSN 是如何逐漸達到無人值守的。
首先來看下風險的防控。前面我們提到，在傳統的變更流程裡面，需要人工介入的有變更範圍控制；還有變更準入的檢查，變更批次完成後，還要抽查确認變更結果以及業務異常情況。
也就是圖上标紅的這些内容。
但是人本身是不可靠的。人為控制變更範圍意味着灰階過程無法保證，準入的檢查會存在比如資訊不同步，規則遺漏的情況，完成情況的檢查在大量應用或 pod 同步變更時，也隻能做到少量抽檢，無法避免問題被漏過。
把人工介入的部分交給系統，我們就有了一個初步可以脫離手動操作和人工觀察的流程。
上圖展示了變更防禦的介入流程。
變更範圍改為由算法來自動産生的帶有強度灰階的批次範圍。前置準入與後置檢查通過将變更類型與變更範圍傳遞給變更防禦的檢查，通過檢查才能繼續執行。
舉一個簡單的場景。MOSN 覆寫很多不同業務的鍊路，各業務有不同的變更保護時段，怎麼來解決呢？
首先在已經業務有保護時段的情況下，我們當然不能不管業務的風險強行變更。在有變更自動防控之前，我們隻能找個共同的可變更時段，很多時候這就是半夜，但對于 MOSN 這麼大規模的變更，半夜變更不僅僅是影響研發和運維幸福感的問題，隻有半夜能變更的話，效率也無法接受。而有了變更的自動準入阻斷規則，這個時間選擇的問題立即就不存在了，我們隻需要把所有應用的變更都跑起來，系統自動判斷各自的可執行時段，甚至不需要參與變更的各方都知道所有業務的可變更時段。
變更防控上線以後，極大的解決了我們的變更風險問題。但它并沒有解決效率問題，一段時間來看，我們的效率甚至下降了。為什麼?
我們分析了自身的變更過程，注意到兩點：一是我們引用的業務錯誤的檢查标準不一，部分業務的敏感度偏高或是門檻值不合理，導緻變更被持續阻斷，無法繼續；二則我們的全面檢查放大了上面的問題，多個批次下來被中斷的的機率也極大的提高了。
仔細來看業務的錯誤檢查。這些檢查不僅說明了 MOSN 自身的檢查，還包括了業務的自身的錯誤和其它中間件、基礎設施的問題。這些檢查無法直接說明 MOSN 自身的健康情況。怎麼解決呢？我們決定不再依賴這個不靠譜的檢查，由 MOSN 自己來說明自己的健康情況。
我們在 MOSN 中建設了兩個層面的健康度觀測能力。第一層是靜态健康度，主要是 MOSN 的啟動自檢，在流量進入前完成，展現 MOSN 運作環境和基本啟動依賴的健康情況；第二層是動态健康度，主要是 error metrics 日志，展現核心功能運作狀态。結合這兩層健康層，MOSN 就具備了完整了自身狀态的觀察能力，可以把業務的錯誤檢查從變更檢查中移除。
我們還做了一個進一步提升變更效率的事情，徹底解決業務冷啟動消耗的時間。
無論是傳統的原地更新或者是滾動更新的模式，過程都無法避免業務需要冷啟動。由于業務依賴比較多，大部分業務的啟動速度和成功率是大幅低于 MOSN 的，是以業務的冷啟動時間一直是 MOSN 變更時間的大頭。
一個很好的解決方案是熱更新。MOSN 自身是具備熱更新能力的，下圖展示了熱更新的過程。
稍微解釋一下的 MOSN 熱更新過程。sidecar operator 會給待更新的 pod 注入一個新版本的 MOSN sidecar，舊版本的 MOSN 會收到連接配接遷移的請求，所有的長連接配接會被新版本的 MOSN 接管，完成之後舊版本 MOSN 會停止，sidecar container 被删除。
熱更新是一個很理想的更新方式，但是完善的熱更新需要的條件和環境都比較複雜，需要 k8s 和 operator 的相應支援，而且被遷移的長連接配接需要同步的遷移狀态，對于 MOSN 内的有狀态協定也帶來比較大的研發壓力。
我們的選擇是把複雜做到了運維側，做一個相對折中的方式。相對于熱更新，這個方案沒有那麼熱，我們稱為溫更新。上圖展示了溫更新的過程。概括起來是三步：關閉待運維 pod 的所有入流量，更新 MOSN 的容器，打開流量。
溫更新去掉了業務的冷啟動時間，避免了業務重新開機失敗。MOSN 隻需要做好配置的向下相容，更新過程和傳統更新過程幾乎完全一樣，但成倍的提升了更新效率。
最後，我們說說 MOSN 整體研發流程。隻有生産的提升是不足以全鍊路的提升 MOSN 的效率的。原有的研發流程裡，CI 流程，灰階版本試點，生産釋出是割裂在各個流程裡的。我們希望把整個研發流程串起來，向 L5 無人值守演進。
我們首先引入了 nightly 釋出，建設 nightly 版本的釋出流，讓灰階版本試點可以自動跑起來。我們打通了 CI 流程，借助品質同學在 CI 流程中建設的測試，保證 nightly 版本可釋出，讓 nightly 版本常态化、自動化推進到灰階驗證階段，加速每一個 commit 的研發回報。最後，我們正在将正式釋出串到 nightly 的驅動路徑中，周期性選擇通過評估的 nightly 版本推進到生産，縮短正式釋出的延遲周期。
原來割裂的各個部分，在研發側由 CI 驅動産出 nightly 版本，然後由 CD 平台驅動一直推進到生産。我們在持續的建設自動變更推進和變更自主決策的能力，向 L5 手機可關機的變更方向演進。
MOSN 技術風險的思考與方向
除了依托于技術風險的能力為 MOSN 保駕護航，MOSN 自身也是技術風險能力的重要承載。
舉個盒子來說，我們在 MOSN 上建設了秒級自愈的能力，依賴于 MOSN 最接近于業務流程的特點，實作了在業務局部有損時秒級響應止損的能力。下圖展示了秒級自愈的流程。
MOSN 可以擷取一段時間片内下遊節點的調用情況做統計，推導下遊可能的故障節點，并将故障節點加入到自己的亞健康下遊清單裡，在秒級時間區間将潛在的故障節點隔離。同時資料會同步上報給自愈中心。自愈中心可以通過多個 MOSN 的上報資訊進一步聚合判定故障節點，做自愈處理。
類似長在 MOSN 的技術風險能力還包括 chaos mesh 的能力，自适應限流的能力等等。對于上層業務，MOSN 越來越成為整體技術風險能力的重要組成部分。
另一方面，技術風險能力的持續提升要讓 MOSN 更穩更快。我們在持續建設更完善的 MOSN SLO 能力，更精準的判定 MOSN 的問題，進而建設變更流程中的自主決策能力，例如變更出現問題時的自主復原；我們也在完善 MOSN 的持續釋出能力，向月度釋出演進，邁向 L5 無人值守。
MOSN：
https://github.com/mosn/mosn歡迎 Star～
延伸閱讀
- SOFAGW 網關：安全可信的跨域 RPC/消息 互通解決方案
- 螞蟻 ServMesh 大規模落地實踐與展望
- Service Mesh 雙十一後的探索和思考(上)
- Service Mesh 雙十一後的探索和思考(下)