公司介紹

Soul 是基于興趣圖譜和游戲化玩法的產(chǎn)品設(shè)計，屬于新一代年輕人的虛擬社交網(wǎng)絡(luò)。成立于2016年，Soul 致力于打造一個“年輕人的社交元宇宙”，最終愿景是“讓天下沒有孤獨的人”。在 Soul，用戶可以無顧慮地表達自己，認(rèn)知他人，探索世界，交流興趣和觀點，獲得精神共鳴和認(rèn)同感，在交流中獲取信息，并獲得有質(zhì)量的新關(guān)系。

問題與挑戰(zhàn)

2.1 多層網(wǎng)關(guān)鏈路長

Soul 在 2020 年開始逐漸試探容器服務(wù)，在 ECS 轉(zhuǎn)型容器階段，出現(xiàn)了容器入口網(wǎng)關(guān)(Ingress-Nginx)，微服務(wù)網(wǎng)關(guān)，加上統(tǒng)一接入層的 SLB+Tengine；造成了多重網(wǎng)關(guān)的架構(gòu)；鏈路太長不僅帶來成本和 RT 的問題，而且導(dǎo)致排查一個請求異常，需要拉非常多的人解決，定位問題代價非常大。

2.2 Ingress-Nginx 開源問題

今年 Ingress-Nginx 社區(qū)反饋穩(wěn)定性和安全問題比較多，暫時停止接收新功能，對 Soul 是一個巨大隱患。

2.3 Grpc 轉(zhuǎn)發(fā)負(fù)載不均衡問題

1. 內(nèi)網(wǎng)部分服務(wù)開放 gRPC 入口，gRPC 是基于 HTTP/2 之上的，而 HTTP/2 被設(shè)計為一個長期存在的 TCP 連接，所有都通過該連接進行多路復(fù)用。這樣雖然減少了管理連接的開銷，但是在負(fù)載均衡上又引出了新的問題。
2. 由于我們無法在連接層面進行均衡，為了做 gRPC 負(fù)載均衡，我們需要從連接級均衡轉(zhuǎn)向請求級均衡。換句話說，我們需要打開一個到每個目的地的 HTTP/2 連接，并平衡這些連接之間的請求。
3. 這就意味著我們需要一個 7 層負(fù)載均衡，而 K8s 的 Service 核心使用的是 kube proxy，這是一個 4 層負(fù)載均衡，所以不能滿足我們的要求。
4. 目前使用獨立 evnoy + headless 方案解決 gPRC 轉(zhuǎn)發(fā)不均衡問題，slb 暴露 envoy 的端口供其他服務(wù)調(diào)用；但維護成本較高，evnoy 節(jié)點資源浪費較為嚴(yán)重

2.4 Ingress 穩(wěn)定性及局限性

1.由于業(yè)務(wù)的不確定性，隨著業(yè)務(wù)請求的波動，nginx ingress controller 會出現(xiàn)連接數(shù)突增，導(dǎo)致 ingress controller 健康檢查不通過；nginx ingress controller上游的檢測需要時間及 fail 次數(shù)積累，導(dǎo)致這一階段用戶請求大量失敗或重試。(如下圖)

2.HTTP 路由僅支持 host 和 path 匹配，對于高級路由功能沒有通用配置，只能通過 annotation 來實現(xiàn)，比如使用 Nginx Ingress Controller 實現(xiàn) URL 重定向，需要配置 http://nginx.ingress.kubernetes.io/rewrite-target annotation 已無法適應(yīng)可編程路由的需求。

3.不同命名空間中的服務(wù)要綁定到同一個網(wǎng)關(guān)中的情況在實際情況下經(jīng)常出現(xiàn)，而入口網(wǎng)關(guān)無法在多個命名空間中共享；這樣就增加 Ingress-Nginx 及 Ingress-Controller的拆分難度。

2.5 業(yè)務(wù)發(fā)布抖動

1. 雖然 Kubernetes 自身具備優(yōu)雅線上機制，及 Liveness 和 Readiness 等就緒檢查，但服務(wù)啟動后，瞬間開始接收請求，服務(wù)還是會受到瞬間流量的沖擊及鏈接層面的壓力。
2. 服務(wù)發(fā)布可分為多批，但我們將整個發(fā)布過程中看做整體時，看到的是服務(wù)RT忽然升高，造成局部業(yè)務(wù)階段性響應(yīng)變慢，給用戶最直觀的感受是卡頓（單次請求較慢或請求失敗后的重試），在用戶側(cè)可能感知到服務(wù)降級或服務(wù)不可用，從而影響用戶體驗。

技術(shù)選型

由于開源 Ingress-Nginx 遇到比較多的問題，由于線上流量巨大難以定位和解決概率超時問題，因此我們考慮投入更多研發(fā)人員解決這個問題，還是選擇 Envoy 網(wǎng)關(guān)解決，還是選擇阿里云 ASM、MSE 云原生網(wǎng)關(guān)兩個產(chǎn)品，因此我們針對這三個新技術(shù)方向做了全面評估。

綜上所述, Envoy 已是現(xiàn)階段數(shù)據(jù)面較好的選擇(可以解決現(xiàn)有nginx ingress controller的性能和穩(wěn)定性問題)，由于性能要求比較高，因此我們優(yōu)先做了性能壓測。

3.1 壓測數(shù)據(jù)

我們通過對線上服務(wù)三種不同方案的壓測數(shù)據(jù)對比（SLB+Envo+headless svc、ALB、MSE），主要測試性能和 gRPC 負(fù)載均衡能力兩方面；壓測數(shù)據(jù)顯示，MSE 云原生網(wǎng)關(guān)在 RT 和成功率上均有優(yōu)勢，并且能滿足 Soul gRPC 的轉(zhuǎn)發(fā)需要；那 MSE 是否能滿足 Soul 所有業(yè)務(wù)需求呢？是否能解決最大集群超時問題呢？因此我們對 MSE 進行了更全面的評估。

3.2 全面技術(shù)評估

• 對 MSE 云原生網(wǎng)關(guān)進行功能、穩(wěn)定性、性能、安全等全方位評估，看看是否滿足 Soul 未來要求。

• Soul 的業(yè)務(wù)場景比較復(fù)雜，評估 MSE 云原生網(wǎng)關(guān)將流量網(wǎng)關(guān)、微服務(wù)網(wǎng)關(guān)、安全網(wǎng)關(guān)三合一，集成 10+ 云產(chǎn)品，開箱即用，滿足業(yè)務(wù)需求。

• Soul 對穩(wěn)定性要求非常高，任何抖動都會導(dǎo)致大量用戶影響，考慮 MSE 云原生網(wǎng)關(guān)經(jīng)歷阿里雙十一大規(guī)模生產(chǎn)驗證，久經(jīng)打磨，奠定了我們生產(chǎn)使用的信心。

• 由于 Soul 流量非常大，網(wǎng)關(guān)機器規(guī)模大，因此成本是一個關(guān)鍵的考量點，壓測顯示 MSE 云原生網(wǎng)關(guān)采用軟硬一體解決方案，比自建性能高 1 倍左右。

• Soul 后端有大量 Dubbo 服務(wù)，目前通過自研業(yè)務(wù)網(wǎng)關(guān)做 HTTP 到 Dubbo 協(xié)議轉(zhuǎn)換，考慮 MSE 云原生網(wǎng)關(guān)支持 HTTP 到 Dubbo 協(xié)議轉(zhuǎn)換，支持直接掛 Dubbo 服務(wù)，有利于未來架構(gòu)收斂。

3.3 遷移方案

• 由于 MSE 兼容 Ingress 標(biāo)準(zhǔn)，因此創(chuàng)建完云原生網(wǎng)關(guān)實例，監(jiān)聽已有的 Ingress 資源，就可以直接遷移后端到路由轉(zhuǎn)發(fā)規(guī)則；
• MSE 與 Ingress-Nginx 可以共存，因此只需要從上游把流量從 Ingress-Nginx 逐漸切到 MSE 云原生網(wǎng)關(guān)即可，按照不同的域名進行灰度，降低變更風(fēng)險。
• 在 Soul 的場景中，流量切換 MSE 后，Ingress-Nginx 沒有完全的下線，保持了 2 個節(jié)點，并增加 HPA 配置，以備不時之需；
• gRPC 轉(zhuǎn)發(fā) MSE 替換原有的獨立 Envoy，業(yè)務(wù)服務(wù)修改 svc 中服務(wù)暴露協(xié)議及端口即可，逐個服務(wù)遷移；

3.4 技術(shù)方案

3.4.1 短期方案

Soul 的網(wǎng)關(guān)鏈路比較長，解決最緊迫超時問題、服務(wù)發(fā)布預(yù)熱問題，因此第一期先替換Ingress-Nginx，并將容器入口網(wǎng)關(guān)/微服務(wù)網(wǎng)關(guān)合并；

3.4.2 終態(tài)方案

將網(wǎng)關(guān)鏈路降為最短；下線微服務(wù)網(wǎng)關(guān)，將http轉(zhuǎn)發(fā)rpc能力托管MSE；下線Tengine，將 ECS 轉(zhuǎn)發(fā)能力托管在 MSE；最終實現(xiàn) SLB->MSE->POD/ECS04

落地效果

4.1 穩(wěn)定性及 RT 前后對比

MSE 切換后處理及響應(yīng)請求時間平穩(wěn)，從峰值 500ms 下降至峰值 50ms

4.2 服務(wù)發(fā)布產(chǎn)生的錯誤碼對比

Ingress-Nginx 與 MSE 錯誤碼對比，服務(wù)發(fā)布期間 502 降為 0，499 平均降低 10%;

4.3 預(yù)熱與啟動 RT 問題

落地解決了大部分超時問題，但是啟動慢 Java 程序發(fā)布超時問題還沒解決，因此我們開啟服務(wù)預(yù)熱功能，業(yè)務(wù)啟動逐步打流量過來，防止大量流量打到剛啟動 Java 進程超時。

開啟預(yù)熱效果：從圖中可以看出，Pod 在剛剛啟動后，并沒有瞬間接收到全量，而是在 5 分鐘的時間里逐漸預(yù)熱服務(wù)，這一點在服務(wù) http 入口請求數(shù)量，Pod 網(wǎng)絡(luò)進出流量，Pod CPU 使用率均可以看到；Nginx 需要自己從底層到上層的各種監(jiān)控，采用云原生網(wǎng)關(guān)后，提供一站式觀測視圖，提供豐富網(wǎng)關(guān) prometheus 指標(biāo)，方便觀測和解決復(fù)雜問題。

未來規(guī)劃

1. 采用云原生網(wǎng)關(guān)將流量、安全、微服務(wù)網(wǎng)關(guān)三合一，大幅降低請求鏈路條數(shù)、降低架構(gòu)復(fù)雜度
   
2. 降低運維和排查成本，降低整個鏈路 RT，提升客戶滿意度。
3. 開啟 HTTP 3.0，提升網(wǎng)絡(luò)傳輸效率，提升客戶體驗
4. 采用服務(wù)自治（在線抓包、診斷、巡檢）降低排查問題消耗
5. 采用混沌工程提前識別穩(wěn)定性風(fēng)險；

MSE 實踐價值

1. 隨著MSE 的落地，可以看到鏈路明顯縮短，問題排查及運維工作大大減少
2. 替代業(yè)務(wù)網(wǎng)關(guān)，Http轉(zhuǎn)Dubbo能力的抽象，大大減少了研發(fā)及運維工作量3. 穩(wěn)定性及平滑遷移方案完善，可以做到真正的開箱即用

原文鏈接

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。