轉載于:https://mp.weixin.qq.com/s/dLSYkBH4wNwq2o2eTuVPAw
作者:jartto
本節篇幅較長,我們主要圍繞以下幾點來展開:
- 什么是服務網格?
- 初識 Istio
- 核心特性
- 流程架構
- 核心模塊
- Envoy 進階
- 方案暢想
對許多公司來說,Docker 和 Kubernetes 這樣的工具已經解決了部署問題,或者說幾乎解決了。但他們還沒有解決運行時的問題,這就是服務網格(Service Mesh)的由來。
什么是服務網格?
服務網格(Service Mesh)用來描述組成這些應用程序的微服務網絡以及它們之間的交互。
它是一個用于保證服務間安全、快速、可靠通信的網絡代理組件,是隨著微服務和云原生應用興起而誕生的基礎設施層。
它通常以輕量級網絡代理的方式同應用部署在一起。比如 Sidecar 方式,如下圖所示:
我們對上圖做個解釋:Service Mesh 設計一般劃分為兩個模塊,控制面和數據面。對于應用來說,所有流量都會經過數據面進行轉發。
順利轉發的前提:數據面需要知道轉發的目標地址,目標地址本身是由一些業務邏輯來決定的(例如服務發現)。
所以自然而然地,我們可以推斷控制面需要負責管理數據面能正常運行所需要的一些配置:
- 需要知道某次請求轉發去哪里:服務發現配置。
- 外部流量進入需要判斷是否已經達到服務流量上限:限流配置。
- 依賴服務返回錯誤時,需要能夠執行相應的熔斷邏輯:熔斷配置。
Serivce Mesh 可以看作是一個位于 TCP/IP 之上的網絡模型,抽象了服務間可靠通信的機制。
但與 TCP 不同,它是面向應用的,為應用提供了統一的可視化和控制。
Service Mesh 具有如下優點:
- 屏蔽分布式系統通信的復雜性(負載均衡、服務發現、認證授權、監控追蹤、流量控制等等),服務只用關注業務邏輯。
- 真正的語言無關,服務可以用任何語言編寫,只需和 Service Mesh 通信即可。
- 對應用透明,Service Mesh 組件可以單獨升級。
Service Mesh 目前也面臨一些挑戰:
- Service Mesh 組件以代理模式計算并轉發請求,一定程度上會降低通信系統性能,并增加系統資源開銷。
- Service Mesh 組件接管了網絡流量,因此服務的整體穩定性依賴于 Service Mesh,同時額外引入的大量 Service Mesh 服務實例的運維和管理也是一個挑戰。
隨著服務網格的規模和復雜性不斷的增長,它將會變得越來越難以理解和管理。
Service Mesh 的需求包括服務發現、負載均衡、故障恢復、度量和監控等。
Service Mesh 通常還有更復雜的運維需求,比如 A/B 測試、金絲雀發布、速率限制、訪問控制和端到端認證。
Service Mesh 的出現,彌補了 Kubernetes 在微服務的連接、管理和監控方面的短板,為 Kubernetes 提供更好的應用和服務管理。
因此,Service Mesh 的代表 Istio 一經推出,就被認為是可以和 Kubernetes 形成雙劍合璧效果的微服務管理的利器,受到了業界的推崇。
Istio 提供了對整個服務網格的行為洞察和操作控制的能力,以及一個完整的滿足微服務應用各種需求的解決方案。
Istio 主要采用一種一致的方式來保護、連接和監控微服務,降低了管理微服務部署的復雜性。
初識 Istio
Istio 發音「意絲帝歐」,重音在意上。官方給出的 Istio 的總結,簡單明了:
Istio lets you connect, secure, control, and observe services.
連接、安全、控制和觀測服務。
簡單來說,Istio 針對現有的服務網格,提供一種簡單的方式將連接、安全、控制和觀測的模塊,與應用程序或服務隔離開來,從而開發人員可以將更多的精力放在核心的業務邏輯上。
以下是 Istio 的核心功能:
- HTTP、gRPC、WebSocket 和 TCP 流量的自動負載均衡。
- 通過豐富的路由規則、重試、故障轉移和故障注入,可以對流量行為進行細粒度控制。
- 可插入的策略層和配置 API,支持訪問控制、速率限制和配額。
- 對出入集群入口和出口中所有流量的自動度量指標、日志記錄和追蹤。
- 通過強大的基于身份的驗證和授權,在集群中實現安全的服務間通信。
從較高的層面來說,Istio 有助于降低這些部署的復雜性,并減輕開發團隊的壓力。
它是一個完全開源的服務網格,作為透明的一層接入到現有的分布式應用程序里。它也是一個平臺,擁有可以集成任何日志、遙測和策略系統的 API 接口。
Istio 多樣化的特性使我們能夠成功且高效地運行分布式微服務架構,并提供保護、連接和監控微服務的統一方法。
核心特性
Istio 以統一的方式提供了許多跨服務網格的關鍵功能:
①流量管理
Istio 簡單的規則配置和流量路由允許我們控制服務之間的流量和 API 調用過程。
Istio 簡化了服務級屬性(如熔斷器、超時和重試)的配置,并且讓它輕而易舉的執行重要的任務(如 A/B 測試、金絲雀發布和按流量百分比劃分的分階段發布)。
有了更好的對流量的可視性和開箱即用的故障恢復特性,我們就可以在問題產生之前捕獲它們,無論面對什么情況都可以使調用更可靠,網絡更健壯。
②安全
Istio 的安全特性解放了開發人員,使其只需要專注于應用程序級別的安全。
Istio 提供了底層的安全通信通道,并為大規模的服務通信管理認證、授權和加密。
有了 Istio,服務通信在默認情況下就是受保護的,可以在跨不同協議和運行時的情況下實施一致的策略,而所有這些都只需要很少甚至不需要修改應用程序。
Istio 是獨立于平臺的,可以與 Kubernetes(或基礎設施)的網絡策略一起使用。
但它更強大,能夠在網絡和應用層面保護 Pod 到 Pod 或者服務到服務之間的通信。
③可觀察性
Istio 健壯的追蹤、監控和日志特性讓我們能夠深入的了解服務網格部署。通過 Istio 的監控能力,可以真正的了解到服務的性能是如何影響上游和下游的。
而它的定制 Dashboard 提供了對所有服務性能的可視化能力,并讓我們看到它如何影響其他進程。
Istio 的 Mixer 組件負責策略控制和遙測數據收集。它提供了后端抽象和中介,將一部分 Istio與后端的基礎設施實現細節隔離開來,并為運維人員提供了對網格與后端基礎實施之間交互的細粒度控制。
所有這些特性都使我們能夠更有效地設置、監控和加強服務的 SLO。當然,底線是我們可以快速有效地檢測到并修復出現的問題。
④平臺支持
Istio 獨立于平臺,被設計為可以在各種環境中運行,包括跨云、內部環境、Kubernetes、Mesos 等等。
我們可以在 Kubernetes 或是裝有 Consul 的 Nomad 環境上部署 Istio。
Istio 目前支持:
- Kubernetes 上的服務部署。
- 基于 Consul 的服務注冊。
- 服務運行在獨立的虛擬機上。
⑤整合和定制
Istio 的策略實施組件可以擴展和定制,與現有的 ACL、日志、監控、配額、審查等解決方案集成。
流程架構
Istio 服務網格邏輯上分為數據平面(Control Plane)和控制平面(Data Plane),架構圖如下所示:
數據平面(Data Plane)
由一組以 Sidecar 方式部署的智能代理 Envoy 組成。Envoy 被部署為 Sidecar,和對應服務在同一個 Kubernetes pod 中。
這允許 Istio 將大量關于流量行為的信號作為屬性提取出來,而這些屬性又可以在 Mixer 中用于執行策略決策,并發送給監控系統,以提供整個網格行為的信息。
這些代理可以調節和控制微服務及 Mixer 之間所有的網絡通信。
控制平面(Control Plane)
負責管理和配置代理來路由流量,此外配置 Mixer 以實施策略和收集遙測數據。
主要包含如下幾部分內容:
- Mixer:策略和請求追蹤。
- Pilot:提供服務發現功能,為智能路由(例如 A/B 測試、金絲雀部署等)和彈性(超時、重試、熔斷器等)提供流量管理功能。
- Citadel:分發 TLS 證書到智能代理。
- Sidecar injector:可以允許向應用中無侵入的添加功能,避免為了滿足第三方需求而添加額外的代碼。
核心模塊
上文提到了很多技術名詞,我們需要重點解釋一下:
①什么是 Sidecar 模式?
Sidecar 是一種將應用功能從應用本身剝離出來作為單獨進程的設計模式,可以允許向應用中無侵入的添加功能,避免為了滿足第三方需求而添加額外的代碼。
在軟件架構中,Sidecar 附加到主應用,或者叫父應用上,以擴展、增強功能特性,同時 Sidecar 與主應用是松耦合的。
Sidecar 是一種單節點多容器的應用設計形式,主張以額外的容器來擴展或增強主容器。
②Envoy 的作用是什么?
Envoy 是一個獨立的進程,旨在與每個應用程序服務器一起運行。
所有 Envoy組成了一個透明的通信網格,其中每個應用程序發送和接收來自本地主機的消息,并且不需要知道網絡拓撲。
與傳統的服務通信服務的庫方法相比,進程外架構有兩個實質性好處:
- Envoy 支持任何編程語言寫的服務。只用部署一個 Envoy 就可以在 JAVA、C++、Go、php、Python 等服務間形成網格。
- 任何使用過大型面向服務的體系結構的人都知道,部署庫升級可能會非常痛苦。Envoy 可以在整個基礎設施中迅速部署和升級。
Envoy 以透明的方式彌合了面向服務的體系結構使用多個應用程序框架和語言的情況。
③Mixer
Mixer 是一個獨立于平臺的組件,負責在服務網格上執行訪問控制和使用策略,并從 Envoy 代理和其他服務收集遙測數據,代理提取請求級屬性,發送到 Mixer 進行評估。有關屬性提取和策略評估的更多信息,請參見 Mixer 配置。
Mixer 中包括一個靈活的插件模型,使其能夠接入到各種主機環境和基礎設施后端,從這些細節中抽象出 Envoy 代理和 Istio 管理的服務。
④Pilot
控制面中負責流量管理的組件為 Pilot,它為 Envoy Sidecar 提供服務發現功能,為智能路由(例如 A/B 測試、金絲雀部署等)和彈性(超時、重試、熔斷器等)提供流量管理功能。
它將控制流量行為的高級路由規則轉換為特定于 Envoy 的配置,并在運行時將它們傳播到 Sidecar。
⑤Istio 如何保證服務通信的安全?
Istio 以可擴縮的方式管理微服務間通信的身份驗證、授權和加密。Istio 提供基礎的安全通信渠道,使開發者可以專注于應用層級的安全。
Istio 可以增強微服務及其通信(包括服務到服務和最終用戶到服務的通信)的安全性,且不需要更改服務代碼。
它為每個服務提供基于角色的強大身份機制,以實現跨集群、跨云端的互操作性。
如果我們結合使用 Istio 與 Kubernetes(或基礎架構)網絡政策,Pod 到 Pod 或者服務到服務的通信在網絡層和應用層都將安全無虞。
Istio 以 google 的深度防御策略為基礎構建而成,以確保微服務通信的安全。
當我們在 Google Cloud 中使用 Istio 時,Google 的基礎架構可讓我們構建真正安全的應用部署。
Istio 可確保服務通信在默認情況下是安全的,并且我們可以跨不同協議和運行時一致地實施安全政策,而只需對應用稍作調整,甚至無需調整。
Envoy 進階
Istio 使用 Envoy 代理的擴展版本,Envoy 是以 C++ 開發的高性能代理,用于調解服務網格中所有服務的所有入站和出站流量。
Envoy 的許多內置功能被 Istio 發揚光大,例如:
- 動態服務發現
- 負載均衡
- TLS 終止
- HTTP2 & gRPC 代理
- 熔斷器
- 健康檢查、基于百分比流量拆分的灰度發布
- 故障注入
- 豐富的度量指標
Envoy 分為主線程、工作線程、文件刷新線程,其中主線程就是負責工作線程和文件刷新線程的管理和調度。
而工作線程主要負責監聽、過濾和轉發,工作線程里面會包含一個監聽器,如果收到一個請求之后會通過過濾鏈來進行數據過濾。
前面兩個都是非阻塞的,唯一一個阻塞的是這種 IO 操作的,會不斷地把內存里面一些緩存進行落盤。
總結來說,我們可以圍繞如下五方面:
①服務的動態注冊和發現
Envoy 可以選擇使用一組分層的動態配置 API 來進行集中管理。
這些層為 Envoy 提供了動態更新,后端群集的主機、后端群集本身、HTTP 路由、偵聽套接字和通信加密。
為了實現更簡單的部署,后端主機發現可以通過 DNS 解析 (甚至完全跳過) 完成,層也可以替換為靜態配置文件。
②健康檢查
構建 Envoy 網格的建議方法是將服務發現視為最終一致的過程。Envoy 包括一個運行狀況檢查子系統,該子系統可以選擇對上游服務集群執行主動運行狀況檢查。
然后,Envoy 使用服務發現和運行狀況檢查信息的聯合來確定健康的負載均衡服務器。Envoy 還支持通過異常檢測子系統進行被動運行狀況檢查。
③高級負載均衡
分布式系統中不同組件之間的負載平衡是一個復雜的問題。
由于 Envoy 是一個獨立的代理而不是庫,因此它能夠在一個位置實現高級負載平衡技術,并使任何應用程序都可以訪問。
目前 Envoy 包括支持自動重試、斷路、通過外部速率限制服務限制全局速率、請求隱藏和異常值檢測。未來計劃為 Request Racing 提供支持。
④前端/邊緣系統代理支持
雖然 Envoy 主要是為服務通信系統而設計的,但對前端/邊緣系統也是很有用的,如:可觀測性、管理、相同的服務發現和負載平衡算法等。
Envoy 包含足夠的功能,使其可用作大多數 Web 應用服務用例的邊緣代理。這包括作為 TLS 的終點、HTTP/1.1 和 HTTP/2 支持,以及 HTTP L7 路由。
⑤最好的觀察統計能力
Envoy 的首要目標是使網絡透明。但是在網絡級別和應用程序級都無法避免的容易出現問題。
Envoy 包含了對所有子系統的強有力的統計支持。statsd 和其他兼容的數據提供程序是當前支持的統計接收器,插入不同的統計接收器也并不困難。
Envoy 可以通過管理端口查看統計信息,還支持通過第三方供應商進行分布式追蹤。
方案暢想
應用上面的原理,我們可以有很多具體的方案應用于日常開發。
方案一:應用 Istio 改造微服務
模仿在線書店的一個分類,顯示一本書的信息。頁面上會顯示一本書的描述,書籍的細節(ISBN、頁數等),以及關于這本書的一些評論。
應用的端到端架構:Bookinfo 應用中的幾個微服務是由不同的語言編寫的。
這些服務對 Istio 并無依賴,但是構成了一個有代表性的服務網格的例子:它由多個服務、多個語言構成,并且 reviews 服務具有多個版本。
用 Istio 改造后架構如下:要在 Istio 中運行這一應用,無需對應用自身做出任何改變。我們只需要把 Envoy Sidecar 注入到每個服務之中。
最終的部署結果將如下圖所示:
所有的微服務都和 Envoy Sidecar 集成在一起,被集成服務所有的出入流量都被 Sidecar 所劫持。
這樣就為外部控制準備了所需的 Hook,然后就可以利用 Istio 控制平面為應用提供服務路由、遙測數據收集以及策略實施等功能。
方案二:用 Istio 改造 CI/CD 流程
對上述流程圖簡單解釋一下:
- 通過 Docker 對代碼進行容器化處理。
- 通過 Gitlab 托管代碼。
- Jenkins 監聽 Gitlab 下的代碼,觸發自動構建,并執行 Kustomize 文件。
- Kustomize 通過配置文件,設置了 Istio 的配置(染色識別、流量分發),并啟動 K8s 部署應用。
- 最終我們通過 Rancher 來對多容器進行界面化管理。
- 打開瀏覽器進行訪問。
看到這里,相信你也了解了,我們實現了一個前端多容器化部署的案例。
它有什么意義呢?
- 首先,當然是環境隔離了,研發每人一個容器開發,互不干擾。
- 其次,我們可以做很多小流量、灰度發布等事情。
- 自動化部署,一站式的流程體驗。
如果你對容器化還不太了解,請先看看前面兩篇文章:
- Docker 邊學邊用
- 一文了解 Kubernetes
Istio 還是有很多可圈可點的地方,相信看到這里你也有了更全面的認識。如果你想深入了解,不妨仔細研究官方示例,并且在實際項目中不斷打磨。