目錄

一、概述

二、 設計

三、服務網格

四、總結

---

一、概述

容器化技術與容器編排推動了微服務架構應用的演進，于是應用的擴展與微服務的數量日益增加，新的問題隨之而來，監控服務的性能變得越來越困難，微服務與微服務之間相互通信變得越來越復雜，請求鏈路越來越長，排查問題變得越來越繁瑣……

云原生應用下使用服務網格作為解決上述問題的方案之一。

服務網格不僅描述了這個應用的網絡，而且還描述了分布式應用程序組件之間的交互，所有在該應用之間傳遞的數據都會由服務網格來接管。這意味著它能管控流量，控制路由……如果僅僅只是這些倒是與傳統的網關基礎設施沒什么區別。但微服務體系結構通常還有更復雜的操作需求，比如A/B測試，Canary部署，速率限制，訪問控制，加密和端到端身份驗證等。

服務網絡可以通過可觀測性，網絡和安全策略來分隔應用程序的業務邏輯。通過服務網格可以鏈接微服務，讓微服務更安全，可以更好地監控微服務。

二、 設計

假設我們現在已存在一個微服務架構的系統，但是我們用傳統的網關代理方式來作為服務之間的通信代理（如下圖所示）。

可以看到Nginx代理了該系統中的所有服務，無論是服務1還是Minio，DB等都在Nginx的代理下。在這種網絡代理下如果Server1請求Server2還是訪問DB服務都要將流量先打到Nginx，然后再由路由進行分發，代理到具體的某個服務下。

在上述這種代理模式下，服務的Path管理會變得很繁瑣，每引入或者擴容一個新服務就需要更改一次Nginx的配置，服務可能因為某種原因而崩潰，但是Nginx只能做到基礎的健康檢查，如果想做負載均衡還得再調整配置……

服務發現也許能通過引入Consul來解決，但是路由的代理最終還是需要在網關層面做配置，健康檢查也不能解決服務因為崩潰后斷連的問題，手動運維這些會相當繁瑣。這時候可能會想：不如直接上Kubernetes，容器化技術解決自啟動的問題，Kubernetes中自帶服務發現/注冊，只需要使用Nginx代理一下Server就好。

于是設計可能會演變成：

上述示意圖中為了代理各個服務，由ingress接管原本Nginx路由分發，然后將流量轉發給Service，由Service來做負載均衡。而Minio則代表著?些邊緣服務。

Minio API 在代碼訪問中不能添加Path路徑，它的安全策略不允許，所以 www.demo.com/minio 這類的地址是無法訪問的。使用Ingress時代理Minio需要額外申請一個域名。

當請求從客戶端發起時，由Nginx轉發到Kubernetes Nginx-Ingress服務端口，再由Ingress進行流量分割發送到不同的Service。這一網絡鏈路看似沒什么問題，但是在做單體應用向微服務應用拆分時，往往也容易背負巨大的技術債務。

例如：Minio/DB從單體部署演變成集群，勢必涉及到部署的方式改變，數據的遷移，數據備份，容災等......某些暫時無法進行拆分的基礎設施成為了云原生環境下的邊緣服務，示意圖中的Minio也代表著這一類的服務（它們不好拆分或成本略高）。

于是我們依舊保留著Nginx作為唯一網關的入口，并代理一部分的邊緣服務，業務服務的網絡代理由Kubernetes接管，服務與服務之間的通信使用集群網絡。

上述的方案可能對于一定規模的應用下夠用了，但是隨著業務要求，引入一些新技術，比如為了服務的穩定性，要求上線前做金絲雀發布（Kubernetes固然可以通過更改Pod的數量來按照比例伸縮達到目的)；收集整個系統的日志信息（還記得我們有一部分部署在集群之外的邊緣服務嗎？);跨集群進行訪問，亦或跨不同云廠商的集群訪問；

這些新技術的引入會讓原本就復雜的網絡鏈路變得更加復雜，當你想對系統進行測壓時，一個配置（可能是Nginx的配置，也可能是Ingress的配置）錯誤都會讓你難以定位，可能你會找錯瓶頸，混淆你的判斷從而走向錯誤的方向。

三、服務網格

Kubernetes最精細的顆粒度也只能達到容器層次，如果再想進一步只能依靠工程師來管理，容器編排系統很難提供更有效的支持。但是服務網格的出現就是為了彌補這一缺憾。

服務網格只是處理程序間通信的基礎設施，但它不是一個獨立的存在，它以"邊車"的形式直接部署在應用旁邊，一對一為應用提供服務代理。

"邊車",?種常見的容器設計模式，用來形容外掛在容器身上的輔助程序。

服務網格在容器的支持下，不需要侵入業務代碼就能強制性地對應用通信進行管理，原理類似中間人流量劫持，透明地接管容器。

下圖出自《鳳凰架構》

服務網格包括兩大塊內容：和微服務共同部署的邊車代理；用于控制這些代理的管理者；服務網格使用數據平面通信和控制平面通信來形容這兩類流量。

我們使用服務網格其實希望更好梳理網絡的訪問鏈路，期望在基礎設施服務就能解決網絡的一部分問題，比如中斷重試，不同云廠商之間平穩遷移，統一納入網絡平面，不依賴程序就能控制訪問等……

數據平面也被稱為轉發平面，為了在不可靠的物理網絡中保證程序間通信的最大可靠性，它可以在無感情況下自動完成服務路由，健康檢查，負載均衡，認證鑒權，產生監控數據等……

四、總結

我們從單體應用向微服務的演變講述了網絡代理在各個階段的變化。服務網格可能是未來的一個趨勢，時至今日服務網格的代表Istio已經從CNCF中畢業了，但服務網格并非是"銀彈"，它不支持與其他系統或服務集成，也不解決轉換映射或路由類型之類的問題……使用服務網格也需要云原生環境，一些邊緣，獨立部署的服務也無法納入系統中享受新技術帶來的便利；引入一套全新的網絡服務也會增加應用的成本，使用不當反而會增加項目風險，留下成本巨大的技術債務。?

在實際項目中我們需要考慮不同應用架構，規模使用最合適的網絡服務代理。如果僅僅只是一個單體應用，那么Nginx或許是最好的選擇；如果是正在演進的分布式系統，又在不斷迭代，那么Nginx ingress 在這一階段也許就能滿足需求；如果微服務應用已經達到一定規模，開發工程師或運維工程師已經無法了解整個系統的全貌，那使用服務網格倒也無可厚非。

版權聲明:本文由神州數碼云基地團隊整理撰寫，若轉載請注明出處。

公眾號搜索神州數碼云基地，了解更多技術干貨！