公司介紹
Soul 是基于興趣圖譜和游戲化玩法的產品設計，屬于新一代年輕人的虛擬社交網絡。成立于2016年，Soul 致力于打造一個“年輕人的社交元宇宙”，最終愿景是“讓天下沒有孤獨的人”。在 Soul，用戶可以無顧慮地表達自己，認知他人，探索世界，交流興趣和觀點，獲得精神共鳴和認同感，在交流中獲取信息，并獲得有質量的新關系。
問題與挑戰(zhàn)
2.1 多層網關鏈路長
Soul 在 2020 年開始逐漸試探容器服務，在 ECS 轉型容器階段，出現了容器入口網關(Ingress-Nginx)，微服務網關，加上統(tǒng)一接入層的 SLB+Tengine；造成了多重網關的架構；鏈路太長不僅帶來成本和 RT 的問題，而且導致排查一個請求異常，需要拉非常多的人解決，定位問題代價非常大。
2.2 Ingress-Nginx 開源問題
今年 Ingress-Nginx 社區(qū)反饋穩(wěn)定性和安全問題比較多，暫時停止接收新功能，對 Soul 是一個巨大隱患。
2.3 Grpc 轉發(fā)負載不均衡問題
- 內網部分服務開放 gRPC 入口，gRPC 是基于 HTTP/2 之上的，而 HTTP/2 被設計為一個長期存在的 TCP 連接，所有都通過該連接進行多路復用。這樣雖然減少了管理連接的開銷，但是在負載均衡上又引出了新的問題。
- 由于我們無法在連接層面進行均衡，為了做 gRPC 負載均衡，我們需要從連接級均衡轉向請求級均衡。換句話說，我們需要打開一個到每個目的地的 HTTP/2 連接，并平衡這些連接之間的請求。
- 這就意味著我們需要一個 7 層負載均衡，而 K8s 的 Service 核心使用的是 kube proxy，這是一個 4 層負載均衡，所以不能滿足我們的要求。
- 目前使用獨立 evnoy + headless 方案解決 gPRC 轉發(fā)不均衡問題，slb 暴露 envoy 的端口供其他服務調用；但維護成本較高，evnoy 節(jié)點資源浪費較為嚴重
2.4 Ingress 穩(wěn)定性及局限性
1.由于業(yè)務的不確定性，隨著業(yè)務請求的波動，nginx ingress controller 會出現連接數突增，導致 ingress controller 健康檢查不通過；nginx ingress controller上游的檢測需要時間及 fail 次數積累，導致這一階段用戶請求大量失敗或重試。(如下圖)
2.HTTP 路由僅支持 host 和 path 匹配，對于高級路由功能沒有通用配置，只能通過 annotation 來實現，比如使用 Nginx Ingress Controller 實現 URL 重定向，需要配置?http://nginx.ingress.kubernetes.io/rewrite-target?annotation 已無法適應可編程路由的需求。
3.不同命名空間中的服務要綁定到同一個網關中的情況在實際情況下經常出現，而入口網關無法在多個命名空間中共享；這樣就增加 Ingress-Nginx 及 Ingress-Controller的拆分難度。
2.5 業(yè)務發(fā)布抖動
- 雖然 Kubernetes 自身具備優(yōu)雅線上機制，及 Liveness 和 Readiness 等就緒檢查，但服務啟動后，瞬間開始接收請求，服務還是會受到瞬間流量的沖擊及鏈接層面的壓力。
- 服務發(fā)布可分為多批，但我們將整個發(fā)布過程中看做整體時，看到的是服務RT忽然升高，造成局部業(yè)務階段性響應變慢，給用戶最直觀的感受是卡頓（單次請求較慢或請求失敗后的重試），在用戶側可能感知到服務降級或服務不可用，從而影響用戶體驗。
技術選型
由于開源 Ingress-Nginx 遇到比較多的問題，由于線上流量巨大難以定位和解決概率超時問題，因此我們考慮投入更多研發(fā)人員解決這個問題，還是選擇 Envoy 網關解決，還是選擇阿里云 ASM、MSE 云原生網關兩個產品，因此我們針對這三個新技術方向做了全面評估。
綜上所述, Envoy 已是現階段數據面較好的選擇(可以解決現有nginx ingress controller的性能和穩(wěn)定性問題)，由于性能要求比較高，因此我們優(yōu)先做了性能壓測。
3.1 壓測數據
我們通過對線上服務三種不同方案的壓測數據對比（SLB+Envo+headless svc、ALB、MSE），主要測試性能和 gRPC 負載均衡能力兩方面；壓測數據顯示，MSE 云原生網關在 RT 和成功率上均有優(yōu)勢，并且能滿足 Soul gRPC 的轉發(fā)需要；那 MSE 是否能滿足 Soul 所有業(yè)務需求呢？是否能解決最大集群超時問題呢？因此我們對 MSE 進行了更全面的評估。
3.2 全面技術評估
- 對 MSE 云原生網關進行功能、穩(wěn)定性、性能、安全等全方位評估，看看是否滿足 Soul 未來要求。
- Soul 的業(yè)務場景比較復雜，評估 MSE 云原生網關將流量網關、微服務網關、安全網關三合一，集成 10+ 云產品，開箱即用，滿足業(yè)務需求。
- Soul 對穩(wěn)定性要求非常高，任何抖動都會導致大量用戶影響，考慮 MSE 云原生網關經歷阿里雙十一大規(guī)模生產驗證，久經打磨，奠定了我們生產使用的信心。
- 由于 Soul 流量非常大，網關機器規(guī)模大，因此成本是一個關鍵的考量點，壓測顯示 MSE 云原生網關采用軟硬一體解決方案，比自建性能高 1 倍左右。
- Soul 后端有大量 Dubbo 服務，目前通過自研業(yè)務網關做 HTTP 到 Dubbo 協(xié)議轉換，考慮 MSE 云原生網關支持 HTTP 到 Dubbo 協(xié)議轉換，支持直接掛 Dubbo 服務，有利于未來架構收斂。
3.3 遷移方案
- 由于 MSE 兼容 Ingress 標準，因此創(chuàng)建完云原生網關實例，監(jiān)聽已有的 Ingress 資源，就可以直接遷移后端到路由轉發(fā)規(guī)則；
- MSE 與 Ingress-Nginx 可以共存，因此只需要從上游把流量從 Ingress-Nginx 逐漸切到 MSE 云原生網關即可，按照不同的域名進行灰度，降低變更風險。
- 在 Soul 的場景中，流量切換 MSE 后，Ingress-Nginx 沒有完全的下線，保持了 2 個節(jié)點，并增加 HPA 配置，以備不時之需；
- gRPC 轉發(fā) MSE 替換原有的獨立 Envoy，業(yè)務服務修改 svc 中服務暴露協(xié)議及端口即可，逐個服務遷移；
3.4 技術方案
3.4.1 短期方案
Soul 的網關鏈路比較長，解決最緊迫超時問題、服務發(fā)布預熱問題，因此第一期先替換Ingress-Nginx，并將容器入口網關/微服務網關合并；
3.4.2 終態(tài)方案
將網關鏈路降為最短；下線微服務網關，將http轉發(fā)rpc能力托管MSE；下線Tengine，將 ECS 轉發(fā)能力托管在 MSE；最終實現 SLB->MSE->POD/ECS04
落地效果
4.1 穩(wěn)定性及 RT 前后對比
MSE 切換后處理及響應請求時間平穩(wěn)，從峰值 500ms 下降至峰值 50ms
4.2 服務發(fā)布產生的錯誤碼對比
Ingress-Nginx 與 MSE 錯誤碼對比，服務發(fā)布期間 502 降為 0，499 平均降低 10%;
4.3 預熱與啟動 RT 問題
落地解決了大部分超時問題，但是啟動慢 Java 程序發(fā)布超時問題還沒解決，因此我們開啟服務預熱功能，業(yè)務啟動逐步打流量過來，防止大量流量打到剛啟動 Java 進程超時。
開啟預熱效果：從圖中可以看出，Pod 在剛剛啟動后，并沒有瞬間接收到全量，而是在 5 分鐘的時間里逐漸預熱服務，這一點在服務 http 入口請求數量，Pod 網絡進出流量，Pod CPU 使用率均可以看到；Nginx 需要自己從底層到上層的各種監(jiān)控，采用云原生網關后，提供一站式觀測視圖，提供豐富網關 prometheus 指標，方便觀測和解決復雜問題。
未來規(guī)劃
- 采用云原生網關將流量、安全、微服務網關三合一，大幅降低請求鏈路條數、降低架構復雜度
- 降低運維和排查成本，降低整個鏈路 RT，提升客戶滿意度。
- 開啟 HTTP 3.0，提升網絡傳輸效率，提升客戶體驗
- 采用服務自治（在線抓包、診斷、巡檢）降低排查問題消耗
- 采用混沌工程提前識別穩(wěn)定性風險；
MSE 實踐價值
1. 隨著MSE 的落地，可以看到鏈路明顯縮短，問題排查及運維工作大大減少
2. 替代業(yè)務網關，Http轉Dubbo能力的抽象，大大減少了研發(fā)及運維工作量3. 穩(wěn)定性及平滑遷移方案完善，可以做到真正的開箱即用
原文鏈接文章來源：http://www.zghlxwxcb.cn/news/detail-782307.html
本文為阿里云原創(chuàng)內容，未經允許不得轉載。文章來源地址http://www.zghlxwxcb.cn/news/detail-782307.html
到了這里，關于Soul 云原生網關最佳實踐的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網！
