*作者：劉如鴻  *

## 背景

合闊智雲(www.hexcloud.cn) 是專注於為大中型零售連鎖行業，提供全渠道業務中/前臺產品和解決方案，並建立以消費者為中心的全渠道交易和敏捷供應鏈的新一代零售運營協同平臺。

合闊智雲提供了從全渠道交易管理到訂單履約再到門店供應鏈完整的餐飲零售連鎖解決方案，整個方案採取微服務設計，並深度使用了 Kubernetes 作為生產排程平臺。

## 技術現狀

整個業務系統採用微服務架構，但不同業務場景在不同階段選擇了不同的技術語言來開發，如 Python、Golang 和 Java，甚至有部分應用使用了 Nodejs，因為技術棧的緣故，Spring Cloud 或者 Dubbo 這樣的全家桶並不適合我們，為了能夠適應業務需要，我們選擇了下面的策略：

-   不依賴於單一語言和單一技術框架，允許使用更加合適業務的開發語言，如快速業務迭代使用 Python，基礎服務和雲原生部分使用 Golang，核心的業務系統使用 Java

-   服務內部使用 gRPC 通訊，服務介面定義依賴於 Protobuf

-   原則上跨服務通訊不依賴於訊息佇列，訊息佇列只用於服務自身的排程與補償，這樣子降低了訊息系統本身的複雜性

-   所有系統不直接暴露 HTTP，需要提供 HTTP 服務的，使用團隊開發的 grpc-proxy 來實現 HTTP to gRPC 的轉碼代理工作
  
原則上應用只處理業務本身的問題，所有基礎架構部分的能力都轉由 K8s 來負責，包括：

-   閘道器
-   服務發現
-   負載均衡
-   指標與監控
-   健康檢查
-   故障恢復

## 當前挑戰

早期所有技術人員只需要專注業務的編寫，其他所有的工作全部交給 K8s，在流量比較小業務相對簡單的情況下，這個執行非常流暢。然而，隨著應用數量的增加，業務變得越加複雜，外部流量也在不斷增長，由此帶來了應用鏈路呼叫更加複雜等新的運維難題：

-   內部呼叫用的是 gRPC 協議，應用端沒有做特別處理，導致基於 HTTP2 的長連線協議無法實現負載均衡，尤其是單一客戶端呼叫變大的情況下，服務端無法有效負載；

-   因為應用本身比較薄，應用呼叫鏈路無法透明化，每次新的釋出部署容易出問題。
  
在 2022 年之前，我們使用 Linkerd，初步解決了服務在負載均衡和呼叫鏈路上的治理難題，但我們大部分的基礎架構都是依賴於阿里雲，比如：

-   日誌使用 SLS
-   應用監控使用 ARMS
-   鏈路追蹤使用 XTrace
-   儀表盤使用 Grafana
-   容器監控使用 Prometheus

為了簡化基礎架構的複雜性，我們在基礎服務上的基本原則是使用雲廠商而非自建，而 Linkerd 在實際的使用過程中遇到了一些問題：

-   需要使用自建的基礎設施，無法和阿里雲提供的基礎設施很好的融合
-   應用可觀測性比較簡單
-   Sidecar 使用預設配置，控制能力相對較少，在應對一些複雜一點的場景，無法做到靈活配置

而可觀測性是服務網格的基石，在一套自建的基礎架構上，我們會偶發的出現鏈路被熔斷、某個埠無法訪問的場景，最終的解決方案就是取消注入或者重新注入來解決。

## 基於服務網格 ASM 的探索

### 叢集現狀

我們目前有兩個生產叢集，合計 150 臺 ECS，2500 個 Pod，不同開發語言應用的特點如下：

-   Golang 用於使用者基礎架構以及計算密集型性的應用系統，總體記憶體佔用不會超過 500M，部分服務會隨著臨時性的記憶體而增長，如檔案的匯入匯出服務；

-   Python 用於早期業務敏捷迭代構建的業務系統，都是單程式多執行緒工作模式，單一 Pod 記憶體佔用不高，但一個 Deploy 需要更多的 ReplicaSet 數量；

-   Java 用於全渠道線上交易業務構建的系統，單一 Pod 需要耗費的資源比較多，但同等情況下單一 Pod 的處理能力比較強。

兩個叢集包括了不同的應用場景：

-   ACK-PROD：早期針對大型客戶專有部署的應用叢集，每個客戶的規模體量比較大，應用資源的隔離透過namespace和排程繫結來隔離；

-   ACK-SAAS：針對 SME/KA 全新開發的 SaaS 平臺，所有客戶都使用統一的計算資源。

### 調研阿里雲服務網格 ASM

我們知道， 服務網格作為一種用來管理應用服務通訊的基礎核心技術,  為應用服務間的呼叫帶來了安全、可靠、快速、應用無感知的流量路由、安全、可觀測能力。我們針對開源社群 Istio 和阿里雲服務網格 ASM 產品分別進行了調研， 透過試用瞭解到作為雲廠商的產品， ASM 具備了若干生產使用的功能和實戰經驗，具體來說， ASM 增強了多協議支援以及動態擴充套件能力，提供精細化服務治理，完善零信任安全體系，並持續提升效能及大規模叢集支援能力，降低在生產環境落地服務網格的門檻。商業版適用於有多語言互通，服務精細治理需求，在生產環境大規模使用服務網格的場景。

*詳細的介紹可以參見：*

*<https:>*

透過調研， 我們瞭解到作為業內首個全託管 Istio 相容的服務網格產品 ASM，一開始從架構上就保持了與社群、業界趨勢的一致性，控制平面的元件託管在阿里雲側，與資料面側的使用者叢集獨立。ASM 產品是基於社群開源的 Istio 定製實現的，在託管的控制面側提供了用於支撐精細化的流量管理和安全管理的元件能力。透過託管模式，解耦了 Istio 元件與所管理的 K8s 叢集的生命週期管理，使得架構更加靈活，提升了系統的可伸縮性。

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4acc48248f4d45968958d93380d45e79~tplv-k3u1fbpfcp-zoom-1.image "1.png")

託管式服務網格 ASM 在成為多種異構型別計算服務統一管理的基礎設施中, 提供了統一的流量管理能力、統一的服務安全能力、統一的服務可觀測效能力、以及實現統一的代理可擴充套件能力, 以此構築企業級能力。可以透過點選"閱讀原文"檢視具體的內容介紹。

基於上述的調研， 我們決定開始使用阿里雲服務網格 ASM 產品進行遷移。

## 遷移到阿里雲 ASM

### 第一輪

-   **第一次注入：ACK-PROD**

我們首先將一個足夠規模體量的單一客戶生產環境（門店供應鏈）（每天 50 萬筆訂單，1500 萬庫存流水）注入 Istio，因為這個環境的使用場景不是全天候的，出現問題會有半個小時的緩衝時間來解決問題，並且應用系統做了完善的自動補償，確保在出現問題我們取消 Istio 以後業務也能夠正常恢復，第一次注入非常成功。

-   **第二次注入：ACK-PROD**

然後我們將另外一個門店供應鏈的生產環境也做了 Istio 注入，相對於第一個環境，規模體量小一點，但業務環境更加複雜，有更多的應用服務在執行，第二次注入非常成功。

-   **第三次注入：ACK-SAAS**

隨著前面兩次的成功實踐，我們在一個更加重要的實時生產系統（門店全渠道交易）的基礎服務部分引入了 Istio，因為這些服務只使用 Golang 編寫，都是一些實時處理要求比較高，但業務相對簡單的，第三次注入成功。

-   **第四次注入：ACK-SAAS**

我們在生產環境開始注入部分交易鏈路，注入以後系統生產可用，在第二天高峰期發現了會有部分服務出現 istio-proxy crash 導致應用不可用，從而影響了部分應用的正常執行。鑑於對生產環境的謹慎，我們重新覆盤了出現問題的場景，最終得到的結論是：

-   Java 應用的啟動對於資源的要求比較苛刻，我們沒有提前配置好更加合理的啟動引數，將會導致 Java 應用啟動緩慢；

-   檢查機制不完善，將會導致流量打給還沒有完全準備就緒的服務，此時 K8s 的健康檢查機制會在多次沒有響應時會再次重啟服務；

-   Istio Sidecar 預設的設定也會推慢整個 Pod 的啟動時間，之前應用的假設是 15s 內完成啟動，隨著 Sidecar 代理的注入，有時候會遇到更長的時間；

-   Java 應用提供 gPRC 服務的時候，istio-proxy 會出現某種特殊情況的 Crash，這也是導致生產服務不可用的直接原因。

簡單而言，在 istio-proxy 存在部分 bug 的情況下，我們的應用的快速啟動策略和健康檢查機制的不合理，直接導致了注入 Sidecar 代理的部分服務生產不可用。

針對這個問題，我們在阿里雲工程師的支援之下，在另外一個環境復現並做了改進，主要的改進如下：

-   針對 istio-proxyCRASH 問題，社群已經有了解決方案，在阿里雲工程師的支援下，我們升級了 Sidecar，並做了 A/B 測試，確定復現了這個 Crash 的場景；

-   針對 Java 應用一開始分配更多的CPU資源來加快 Java 應用啟動，在測試過程中，如果預設分配 0.2 調整到 1.5，啟動時間最長的會從 6 分鐘減少到 40 秒；

-   調整 Sidecar 配置，根據應用最佳化 istio-proxy 的啟動速度；

### 第二輪

在方案得到確認以後，我們開始了第二輪的 Istio 升級。

-   **第一次注入：ACK-SAAS**

我們將 SaaS 的供應鏈業務注入 Istio，除了升級過程中遇到部分服務資源不足的問題，其他都非常順利；

-   **第二次注入：ACK-SAAS-QA**

我們在測試環境復現了啟動速度慢的問題，並透過更加合理的啟動引數配置驗證了在 CPU 初始化申請對於 Java 應用的影響；

-   **第三次注入：ACK-SAAS-QA**

A/B 測試 Istio crash 場景，確認新的 Sidecar 已經修復這個問題；

-   **第四次注入：ACK-SAAS**

正式完成全渠道交易的 Istio 生產注入；

-   **第五次注入：ACK-SAAS**

將剩餘的應用全部完成注入。

此外，服務網格 ASM 相比社群 Istio 能夠實現更加豐富的能力，如流量標籤、配置推送最佳化等能力。在實際的應用場景中，我們充分利用配置推送最佳化能力。在預設情況下，由於無法確定資料平面內所有工作負載與服務之間的關係，服務網格資料平面內的所有 Sidecar 都必須儲存資料平面叢集內所有服務資訊的全量配置。同時，一次針對控制平面或資料平面的修改（例如在控制平面新建一條虛擬服務規則），都會導致控制平面向資料平面的所有 Sidecar 推送新的配置。

而在我們的資料平面 Kubernetes 叢集中的工作負載數量比較多， 預設情況下會增加 Sidecar 對資料平面叢集的資源消耗，同時控制平面會面臨較大的配置推送負擔，降低控制平面的效率與可用性。ASM 提供了選擇性/服務發現和 Sidecar 資源推薦功能，幫助最佳化配置推送效率。

服務網格 ASM 可以透過分析資料平面 Sidecar 產生的訪問日誌獲取資料平面服務之間的呼叫依賴關係，為資料平面中的每個工作負載自動推薦 Sidecar 資源。為工作負載推薦 Sidecar 資源後：

-   Sidecar 配置內將僅保留該 Sidecar 對應工作負載所依賴的服務資訊。

-   當該 Sidecar 資源對應的工作負載無依賴關係的服務發生改變，或與該服務相關的資源發生改變（例如虛擬服務等），都不會引起控制平面向該 Sidecar 的配置推送。

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d673bd1a5ab54bd682d449af8862849d~tplv-k3u1fbpfcp-zoom-1.image "2.png")

服務網格ASM透過訪問日誌分析自動推薦 Sidecar CR

經過最佳化後， Sidecar 配置大小從原來的 40 多M減少為 5M, 控制面配置推送時間也隨之大大減少。

總之， 經過一個多月的反覆測試和確認，我們終於完成了基於服務網格 ASM 的核心生產系統切換，相對於之前的服務網格方案，給我們帶來了很多益處。

## 方案優勢及進展規劃

### 完備的可觀測性以及應用監控

透過服務網格對應的控制面盤，我們發現了很多之前應用本身的問題，比如：

-   不合理的應用補償策略
-   不合理的應用部署（比如把大資料查詢和應用處理放在同一個服務）
-   不合理的應用報錯
-   ...

而這些問題隨著服務網格的上線，我們變得一清二楚，進而非常方便的推動應用架構的改造。

### 流量與資源的均衡

這是我們上線服務網格的初衷，隨著我們將所有應用放到服務網格，我們真正做到了在 CPU、記憶體、網路利用率的均衡，透過透過應用呼叫的監控來看，所有請求數量和錯誤也非常均衡的分配在不同的 Pod 上，不用再去擔心隨著流量的增長因為負載不均衡而導致橫向擴充套件失效

### 更加強大的流量治理能力

在沒有 Istio 之前，我們基於自身業務需要做了一些“手工”的流量治理工作，比如：

-   東西流量：基於基於租戶與門店的流量隔離，允許我們可以允許需要針對某一個租戶某一個門店釋出指定服務
-   南北流量：針對業務場景進行灰度測試，比如某一個租戶的美團訂單處理使用新的接單服務
-   為某個租戶提供自定義域名
-   ...

這些工作都是基於 K8s CRD 構建的，隨著服務網格的上線，我們發現 Istio 可以幫助我們實現更多，比如灰度釋出、熔斷、限流、流量標籤等。這些能力將在未來持續不斷提升我們線上業務的穩定性。</https:>

合闊智雲核心生產系統切換到服務網格 ASM 的落地實踐

相關文章