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/...）。

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

Service Mesh遠景形態

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