Service Mesh在企業級應用的生存之道

導讀

近期與幾位企業使用者交流 Service Mesh 及其相關技術，大家對於它所展現的形態以及未來發展都表示出極大的興趣。但對當下企業應用現狀如何與 Service  Mesh 整合到一起又表現出極大的困惑。本文力圖結合Service Mesh技術特性與企業應用的實際情況，就 Service Mesh 如何應對企業應用給出博雲自身的思考，歡迎有興趣的朋友一起討論。

在進行詳細探討之前，我們首先回顧一下 Service Mesh 的定義：服務網格是一個用於處理服務間通訊的基礎設施層，它負責為構建複雜的雲原生應用傳遞可靠的網路請求。在實踐中，服務網格通常實現一組與應用程式部署在一起的輕量級的網路代理，但對應用程式來說是透明的。
 
從定義中我們可以清晰地看到 Service Mesh 的技術定位：“處理服務間通訊的基礎設施層”。因此我們不能希望它幫我們簡化開發測試場景面臨的挑戰（DevOps 或者應用服務化，當然一定程度上可以解耦應用與基礎中介軟體的呼叫關係，稍後會詳細說明），或者解決應用部署場景的問題（部署問題由容器編排平臺處理更加合適）。

總體來說，Service Mesh 專注業務應用部署上線後期的通訊領域問題，同時一定程度上解耦業務單元與基礎中介軟體的呼叫關係（例如服務註冊中心）。如圖所示：

圍繞 Service Mesh 所聚焦的領域以及如何服務於企業級應用，本文重點探討4個問題：

• Service Mesh 的技術特性；
• Service Mesh 與企業應用的整合之道；
• Service Mesh 的部署管理形態；
• Service Mesh 的遠景形態。

Service Mesh技術特性

考慮到目前 Service Mesh 落地方式集中在以容器化為首的 PaaS 領域之內，因此我們也將重點基於容器化方案探討 Service Mesh 所具備的技術特性。

從 Service Mesh發 展來看，無論是基礎的 Docker 執行環境，還是以Kubernetes 為“事實標準”的容器編排環境，都是 Service Mesh 能夠快速發展的基石。以 Kubernetes 為例，Service Mesh 並非技術上的創新，更多是利用 CRD 特性對 Kubernetes 的擴充套件以及傳統技術的整合（防火牆、DNS服務發現等）。以 Isito 為例， Istio 基於引入的標準規範以及 Kubernetes CRD 特性自定義幾十種自身的資源，並依賴 kubectl CLI 命令工具對這些 CRD 進行統一管理。

我們發現Service Mesh 的技術特性主要體現在5個方面：容器編排環境；資料代理控制；配置管理分發；服務鏈路追蹤；服務通訊安全。

容器編排環境

結合 Service Mesh 落地的幾個方案來看，容器編排環境是 Service Mesh 能夠落地的必備要素之一（這裡暫時不深入討論容器化採用的技術原理，如namespace，AUFS等）。容器化編排環境的特效能夠將企業應用或者業務例項組織成方便管理和定址的業務單元，方便系統化的方式訪問這些單元。這裡同樣暫時忽略 Mesh 外圍對接的各種 Adapter。

資料代理控制

從 Service Mesh 定義中可知，其本身是一個與應用繫結在一起的輕量級網路代理，該代理攔截所有服務請求的出站和入站流量，並依賴控制層面標準化介面提供的規則資訊（最終轉化成防火牆內的路由配置）進行流量的轉發和控制，同時對呼叫日誌、呼叫鏈路、響應時長進行記錄和彙報。

配置管理分發

Service Mesh 為了保證資料代理功能的獨立性，將配置與資料代理進行解耦。配置也稱作控制層面，負責從容器環境蒐集服務資訊，並且以高度抽象化的標準介面提供給資料代理服務，為流量轉發提供可靠的路由依賴。同時控制層面面向使用者提供“宣告式”的規則定義，這些規則會儲存在容器平臺中，同時生成路由轉發的流量控制規則，並且以介面的形式提供給資料代理服務，為路由轉發的流量控制提供管理依據。例如在 Istio 中規則定義表現為 Istio 定義的 CRD 資源，規則生效介面表現為 Policy 提供的 XDS 介面。

服務鏈路追蹤

服務鏈路在 Service Mesh 中是基礎必備的功能。它的實現依賴兩部分：資料採集和鏈路呈現。資料採集主要依賴資料代理服務進行服務請求攔截或者轉發時記錄服務請求的源IP地址、目的IP地址和對應的服務名稱等有效資訊；鏈路呈現依賴於分散式跟蹤系統，將採集的服務呼叫鏈路資訊儲存在分散式跟蹤系統中，做集中呈現，例如 Zipkin 等。

服務通訊安全

安全是企業應用必然關注的因素之一，那麼 Service Mesh 在安全領域提供哪些技術特性呢？Service Mesh 作為 PaaS 的擴充套件實現，主要從3個層面為企業應用安全保駕護航：

第一：基於TLS的雙向通行加密。例如Isito中可以在部署時開啟TLS雙向認證配置，並且依賴獨立的證書管理功能，實現服務通訊過程的加密。

第二：許可權控制訪問。Service Mesh為了保證服務呼叫的合法性，提供了許可權訪問控制。例如Isito中基於RBAC的許可權訪問控制；

第三：基於策略的黑白名單訪問控制以及服務熔斷控制。

當然僅僅依靠 Service Mesh 保證企業應用的安全是不夠的，同樣需要藉助其他軟硬體手段，例如防火牆、網路安全監控、內部異常檢測等，具體不在本文討論範圍。

Service Mesh與企業級應用整合之道

在瞭解 Service Mesh 技術特性以後，我們重點來聊一下 Service Mesh 如何與企業級應用整合。

在具體展開之前，首先我們說一下企業應用的現狀與特性：根據 Gartner 對當前 PaaS 市場的統計調研結果，大部分企業處於傳統應用（物理或者虛擬化）向容器化轉型的階段，不同行業都期望能夠把自己的應用合理地遷移到雲端（重點考慮 PaaS 領域）。但對於遺留的企業系統，尤其是核心系統上 PaaS 多多少少有一定的顧慮，因此我們把企業應用的部署形態分為三個等級（等級沒有先後之分）：

• 第一：核心系統，短期（未來幾年）不會考慮容器化處理，例如金融行業的核心資料庫和核心繫統等；
• 第二：支撐系統，當下以虛擬化居多，可能會嘗試服務容器化；
• 第三：外部系統，虛擬化為主，期望遷移到 PaaS 平臺；而目前無論是專案交付還是產品自研，絕大多數圍繞第三類應用系統展開，這也是我們當下考慮的重點。

其次我們來分析一下企業應用的特性：企業應用在大多數情況下是以業務為驅動的。按照這個層面考慮，構建業務系統時存在兩種情況：一體化應用和服務化應用。

針對一體化應用，與 Service Mesh 進行整合時，並不能發揮 Service Mesh 的功效（由於業務集中處理，所有功能及非功能系統全部集中在程式碼本身，一定程度上 Service Mesh 整合意義不大）。因此我們重點考慮服務化應用與 Service Mesh 的整合。這樣考慮的緣由是基於微服務或者雲原生應用是構建系統的趨勢所在，也更符合應用形態的發展規律。

結合企業級應用的現狀以及特性，我們把 Service Mesh 與企業應用的整合劃分為四個階段，如下圖所示：

應用服務化

應用服務化與大家所說的微服務構建有一些不同之處。整體來講，應用服務化還是利用微服務拆分原則，對應用業務單元進行服務拆分，同時確定服務間互動依賴的支撐元件。

不同的地方在於服務直接的互動元件的選型，不再採用 Spring Cloud、Dubbo 或者其他元件提供的支撐功能（如服務註冊與發現，服務鏈路跟蹤，負載均衡等），而是依賴容器平臺（如 kubernetes 提供的服務註冊發現，負載均衡）和 Service Mesh。此種做法的目的是將應用支撐元件下沉，幫助客戶從技術調研與選型的細節中解脫出來，完全從業務角度考慮問題。業務之外的事情交由 PaaS 平臺、Service Mesh 統一處理。

應用服務化，有兩個目的：拆分應用業務單元和梳理業務單元呼叫鏈。(需要進一步說明：摒棄服務註冊與發現元件，並非拋棄其能力，而是更換一種更方便的實現方式。開發環境下，各個服務聯調直接利用 HTTP 或者其他協議的呼叫框架進行遠端服務呼叫即可；測試或者生產環境中，將服務地址替換為容器平臺註冊的 Service 地址，從而具備服務註冊發現，服務負載的能力)。

當然針對之前已經基於 Spring Cloud 或者 Dubbo 開發的業務系統，在不改變原有架構的基礎上同樣可以與 Service Mesh 進行整合，但是在服務治理層面會存在一定衝突，目前來看，最有效的解法是把支撐能力交給平臺本身，將業務與支撐解耦，實現徹底的服務化。

應用容器化

上面已經提到過，在當下的落地實踐中容器化是 Service Mesh 能夠存在的必要條件（當然可以非容器化，但代價無疑是巨大的）。應用服務拆分後的容器化改造，目前有多種實現的方式。最直接的是利用 DevOps 工具鏈，構建應用服務容器映象。當然針對不同平臺或者語言也可以進行獨立實現，例如 Maven 的 docker 外掛，github 提供的 CI 流程，Jenkins 提供的 pipeline 等都能夠很好的實現服務容器化操作，這裡不展開討論。需要指出的是，服務容器化的重點在於構建一套符合企業制度與風格的控制流程規範，這其中技術因素不是主導因素，需要結合企業自身情況決定。

應用Mesh整合

應用服務化和應用容器化能夠解決應用向 PaaS 平臺遷移的絕大多數場景。但是前兩者僅僅解決了服務編排部署問題，並沒有對服務上線後的管理支撐提供更多的功能，而 Service Mesh 恰恰定位於這一領域。那麼應用如何與 Mesh 進行整合呢？可以分四步進行，如圖所示：

第一步，Service Mesh 與 PaaS 基礎設施整合。利用 PaaS 平臺強大的編排部署能力，部署Service Mesh（具體專案例如Isito）的控制層面，各個元件在啟動時會自動初始化 Mesh 所需的環境以及從 PaaS 平臺中搜集需要的資訊，必要的時候，可以把 Mesh 作為 PaaS 平臺基礎設施的一部分。

第二步，配置 PaaS 平臺。使其具備Mesh中代理程式自動注入的功能（例如 Istio 自動注入Sidecar的配置），當然該步驟可以省略，後續由使用者手動注入，目的在於攔截服務請求與轉發流量。

第三步，利用 PaaS 平臺直接部署業務應用。此時應用已經與Mesh繫結在一起共享整個網路棧資源，實現應用與 Service Mesh 的初步整合。

第四步，利用第二步中部署的 Service Mesh 控制層面入口，設定服務通訊規則，從而控制服務之間的通訊，最終完成應用與 Mesh 的整合。

Mesh管理控制

Service Mesh 管理控制是客戶介入服務間通訊的唯一入口。而 Service Mesh 基於“宣告式”規則的控制將決定企業管理過程中更多的是規則的設定者，卻不具備對規則的有效性進行實時校驗的條件。因此需要結合其他外圍元件對當前服務是否符合預期進行監測。例如對接 Prometheus，獲取服務的執行資料（包括 tcp 連線數，請求成功數，請求鏈路時長等），並且基於 AlterManager 進行告警策略的管理；或者對接 ELK 日誌平臺，對服務呼叫的日誌進行統一分析管理。當然還有其他系統，統一稱為 Adapter。

總體而言，應用是資料的產生源頭，Service Mesh 負責服務通訊控制，服務資料收集以及服務資料上報，其他平臺負責資料處理，三者通力合作，才能將 Service Mesh 切實和企業應用整合在一起，發揮它最大的功效。

Service Mesh部署管理形態

Service Mesh部署形態從當下的技術實現考慮，需要緊緊依賴 PaaS 平臺的底層實現，尤其是對容器化環境的依賴。無論是單叢集還是誇叢集的部署，官方文件都提供了詳盡的部署方案，這裡不過多說明，可以參考 Istio 的實現（https://preliminary.istio.io/zh/docs/concepts/multicluster-deployments/）。

Servie Mesh 的管理形態最好的方式是與 PaaS 整合在一起，在 PaaS 自身的能力之上，增加服務治理的各種功能，有助於幫助 PaaS 平臺更好的整合資源。Service Mesh 同樣是對於 PaaS 的補充，從而形成全套的 PaaS 解決方案：包括 DevOps 工具形態，PaaS 編排部署形態，以及 Mesh 的服務治理形態。這時就具備了對應用生命週期各個階段的集中控制能力。

Service Mesh遠景形態

這個是大膽的預測了，無論從技術角度考慮，還是行業發展趨勢，Service Mesh 在未來必然會成為服務治理的主要工具之一。它對於企業應用最大的優勢是解耦應用業務，企業能夠徹底從業務角度考慮問題。相比純粹的微服務架構，又向前邁了一步，同時與容器編排部署平臺的整合，最終有可能成為企業級應用編排部署和服務治理的標準形態。

作者簡介

博雲研究院李寧，負責博雲容器，雲原生，微服務，ServiceMesh，Serverless，中臺等PaaS領域前沿技術研究，曾經主導並參與包括金融，電力，政務，資訊等行業的多個產品及專案交付工作。