一文帶你徹底理解最熱門微服務框架 Istio ( 文末送書,數量有限,先到先得!)

2019-09-12 01:16:15


什麼是 Istio

作為服務網格的實現產品,Istio 一經推出就備受矚目,成為各大廠商和開發者爭相追逐的 “香饃饃”。我個人認為 Istio 會成為繼 Kubernetes 之後的又一個明星級產品。Istio 的官方網站這樣定義自己的:

它是一個完全開源的服務網格,以透明層的方式構建在現有分散式應用中。它也是一個提供了各種 API 的平臺,可以與任何日誌平臺、監控系統或策略系統整合。Istio 的多樣化特性可以讓你高效地執行分散式微服務架構,並提供一種統一的方式來保護、連線和監控微服務。從上面的定義中可以瞭解到,Istio 為微服務應用提供了一個完整的解決方案,可以以統一的方式去檢測和管理微服務。同時,它還提供了管理流量、實施訪問策略、收集資料等功能,而所有這些功能都對業務程式碼透明,即不需要修改業務程式碼就能實現。

有了 Istio,就幾乎可以不需要其他的微服務框架,也不需要自己去實現服務治理等功能。只要把網路層委託給 Istio,它就能幫助完成這一系列的功能。簡單來說,Istio 就是一個提供了服務治理能力的服務網格。

Istio 的架構

對服務網格來講,業務程式碼無侵入和網路層的全權代理是其重要的優勢。我們來了解一下 Istio 的架構,看一看它是如何做到這兩點的,並瞭解架構中的各個元件是如何協同工作並完成網路層功能的。

Istio 的架構從邏輯上分成資料平面(Data Plane)和控制平面(Control Plane)。是否覺得似曾相識?沒錯,Kubernetes 的架構也具有相似的結構,分為控制節點和計算節點。毫無疑問,這樣的設計可以很好地解耦各個功能元件。

  • 資料平面:由一組和業務服務成對出現的 Sidecar 代理(Envoy)構成,它的主要功能是接管服務的進出流量,傳遞並控制服務和 Mixer 元件的所有網路通訊(Mixer 是一個策略和遙測資料的收集器,稍後會介紹)。

  • 控制平面:主要包括了 Pilot、Mixer、Citadel 和 Galley 共 4 個元件,主要功能是通過配置和管理 Sidecar 代理來進行流量控制,並配置 Mixer 去執行策略和收集遙測資料(Telemetry)。

從 Istio 的架構中可以看出,Istio 追求儘可能的透明,通過各種解耦設計讓系統對內對外都沒有依賴。同時,它還提供了高度的擴充套件性。Istio 認為隨著應用的增長和服務的增多,擴充套件策略系統是最主要的需求,因此它被設計為以增量的方式進行擴充套件。可移植也是 Istio 在設計中充分考慮的因素,它被設計為支援多種平臺,以便服務可以被方便地遷移到不同的雲環境中。

通過資料平面和控制平面的分離,各個元件都成為外掛,這種開放和包容的設計思路相當具有前瞻性,我想這也就是其他服務網格產品都放棄了和它競爭而選擇合作的重要原因。下面對架構中的各元件做進一步介紹。

Istio 架構

Istio 的核心控制元件

Envoy

從上面的架構圖可以看出,Istio 的資料平面就是指代理。Istio 選擇 Envoy 作為 Sidecar 代理,Envoy 本質上是一個為面向服務的架構而設計的 7 層代理和通訊匯流排。Envoy 基於 C++ 11 開發而成,效能出色。除了具有強大的網路控制能力外,Envoy 還可以將流量行為和資料提取出來傳送給 Mixer 元件,用以進行監控。

Envoy 在網路控制方面的主要功能如下。

  • HTTP 7 層路由

  • 支援 gRPC、HTTP/2

  • 服務發現和動態配置

  • 健康檢查

  • 高階負載均衡

我們知道,在Kubernetes環境中,同一個Pod內的不同容器間共享網路棧,這一特性使得Sidecar可以接管進出這些容器的網路流量,這就是Sidecar模式的實現基礎。Envoy是目前Istio預設的資料平面,實際上因為Istio靈活的架構,完全可以選擇其他相容的產品作為Sidecar。目前很多服務網格產品都可以作為Istio的資料平面並提供整合。

Pilot

Pilot 是 Istio 實現流量管理的核心元件,它主要的作用是配置和管理 Envoy 代理。比如:可以為代理之間設定特定的流量規則,或者配置超時、重試、熔斷這樣的彈效能力。Pilot 會將控制流量行為的路由規則轉換為 Envoy 的配置,並在執行時將它們廣播到 Envoy。另外,Pilot 還能夠把服務發現機制抽象出來並轉換成 API 分發給 Envoy,使得後者具有服務發現的能力。

簡單來說,Pilot 的主要任務有兩個。

  • 從平臺(如:Kubernetes)獲取服務資訊,完成服務發現

  • 獲取 Istio 的各項配置,轉換成 Envoy 代理可讀的格式並分發

Pilot 架構

上圖展示了 Pilot 架構,Pilot 維護了一套獨立於平臺的服務規則,並提供了一個平臺介面卡,以便接入各種不同的平臺。Rules API 對運維人員開放,使得他們可以設定想要的流量規則,Pilot 會把這些配置好的規則通過 Envoy API 分發給 Envoy 代理,以使其執行指定的規則。Pilot 還公開了用於服務發現並且可以動態更新負載均衡和路由表的 API。

Mixer

Mixer 的主要功能是提供策略控制,並從 Envoy 代理收集遙測資料。每次網路通訊時 Envoy 代理都會向 Mixer 發出預檢要求,用來檢測呼叫者的合法性。呼叫之後 Envoy 代理會發送遙測資料供 Mixer 收集。一般情況下 Sidecar 代理可以快取這些資料,不需要頻繁地呼叫 Mixer。

介面卡是 Mixer 的重要組成部分,它本質上是一個外掛模型,每個外掛叫作介面卡。這項特性使得 Mixer 可以接入幾乎任意的(只要定義好介面)後端基礎設施。比如可以選擇接入不同的日誌收集器、監控工具和授權工具等;可以在執行時切換不同的介面卡或者是開啟(關閉)它們;還可以自定義介面卡以滿足特定需求。介面卡極大地提高了 Mixer 的擴充套件性,它讓 Istio 的功能擁有了更多可能性。下圖展示了 Mixer 的架構圖並展示了它和 Envoy 的互動方式。

Mixer 架構

Citadel

Citadel 是與安全相關的元件,主要負責金鑰和證書的管理。它可以提供服務間和終端使用者的身份認證,還可以加密服務網格中的流量。

Galley

在 2019 年 3 月份釋出的 1.1 版本中,Galley 作為一個獨立的元件被新增到了架構當中(在此之前的版本中 Galley 並未獨立出現),它現在是 Istio 主要的配置管理元件,負責配置的獲取、處理和分發。Galley 使用了一種叫作 MCP(Mesh Configuration Protocol,網格配置協議)的協議與其他元件進行通訊。

Istio 的主要功能

下面詳細地介紹一下 Istio 的 4 個主要功能和實現原理。

流量管理

微服務應用最大的痛點就是處理服務間的通訊,而這一問題的核心其實就是流量管理。首先來看一看傳統的微服務應用在沒有服務網格介入的情況下,如何完成諸如金絲雀釋出這樣的動態路由。假設不借助任何現成的第三方框架,一個簡單的實現方法是,在服務間新增一個負載均衡(如Nginx)做代理,通過修改配置的權重來分配流量。這種方式將對流量的管理和基礎設施(雲伺服器、虛擬機器、實體機等)繫結在了一起,難以維護。

而使用 Istio 就可以輕鬆地實現各種維度的流量控制。下圖展示了兩種不同的金絲雀釋出策略。第一種是根據權重把 5% 的流量路由給新版本;第二種是根據請求的頭資訊 User-Agent 把使用 iPhone 的使用者流量路由到新版本。

Istio 的流量管理

Istio 的流量管理是通過 Pilot 和 Envoy 這兩個元件實現的,將流量和基礎設施進行了解耦。Pilot 負責配置規則,並把規則分發到 Envoy 代理去實施;而 Envoy 按照規則執行各種流量管理的功能,比如動態請求路由,超時、重試和熔斷,還可以通過故障注入來測試服務之間的容錯能力。下面對這些具體的功能進行逐一介紹。

  1. 請求路由

Istio 為了控制服務請求,引入了服務版本(Version)的概念,可以通過版本這一標籤將服務進行區分。版本的設定是非常靈活的,可以根據服務的迭代編號進行定義(如 v1、v2 版本);也可以根據部署環境進行定義(如 Dev、Staging 和 Production);或者是自定義任何用於區分服務的標記。通過版本標籤,Istio 就可以定義靈活的路由規則以控制流量,上面提到的金絲雀釋出這類應用場景就很容易實現了。

下圖展示了使用服務版本實現路由分配的例子。服務版本定義了版本號(v1.5、v2.0-alpha)和環境(us-prod、us-staging)兩種資訊。服務 B 包含了 4 個Pod,其中 3 個是部署在生產環境的 v1.5 版本,而 Pod4 是部署在預生產環境的 v2.0-alpha 版本。運維人員根據服務版本指定路由規則,通過 Pilot 同步給 Envoy 代理,使得 99% 的流量流向 v1.5 版本的生產環境,而 1% 的流量進入 v2.0-alpha 版本的預生產環境。

服務版本控制

  1. 入口閘道器(Ingress)和出口閘道器(Egress)

服務間通訊是通過 Envoy 代理進行的。同樣,我們也可以在整個系統的入口和出口處部署代理,使得所有流入和流出的流量都由代理進行轉發,而這兩個負責入口和出口的代理就叫作入口閘道器和出口閘道器。它們相當於整個微服務應用的邊界代理,把守著進入和流出服務網格的流量。下圖展示了 Ingress 和 Egress 在請求流中的位置,通過設定 Envoy 代理,出入服務網格的流量也得到了控制。

請求流中的 Ingress 和 Egress

  1. 服務發現和負載均衡

服務發現的前提條件是具有服務註冊的能力。目前 Kubernetes 這類容器編排平臺也提供了服務註冊的能力。Istio 基於平臺實現服務發現和負載均衡時,需要通過 Pilot 和 Envoy 協作完成,如下圖所示。Pilot 元件會從平臺獲取服務的註冊資訊,並提供服務發現的介面,Envoy 獲得這些資訊並更新到自己的負載均衡池。Envoy 會定期地對池中的例項進行健康檢查,剔除離線的例項,保證服務資訊的實時性。

服務發現和負載均衡

  1. 故障處理

Istio 的故障處理都由 Envoy 代理完成。Envoy 提供了一整套現成的故障處理機制,比如超時、重試、限流和熔斷等。這些功能都能夠以規則的形式進行動態配置,並且執行執行時修改。這使得服務具有更好的容錯能力和彈性,並保證服務的穩定性。

  1. 故障注入

簡單來說,故障注入就是在系統中人為地設定一些故障,來測試系統的穩定性和系統恢復的能力。比如為某服務設定一個延遲,使其長時間無響應,然後檢測呼叫方是否能處理這種超時問題而自身不受影響(如及時終止對故障發生方的呼叫,避免自己受到影響且使故障擴充套件)。

Isito 支援注入兩種型別的故障:延遲和中斷。延遲是模擬網路延遲或服務過載的情況;中斷是模擬上游服務崩潰的情況,表現為 HTTP 的錯誤碼和 TCP 連線失敗。

策略和遙測

  1. 策略

在微服務應用中,除了流量管理以外,常常還需要進行一些額外的控制,比如限流(對呼叫頻率、速率進行限制)、設定白名單和黑名單等。

Istio 中的策略控制是依靠 Mixer 完成的。Envoy 代理在每次網路請求時,都會呼叫 Mixer 進行預先檢查,確定是否滿足對應的策略。同時,Mixer 又可以根據這些來自流量的資料,進行指標資料的採集和彙總,這就是遙測功能。

  1. 遙測(Telemetry)

遙測是工業上常用的一種技術,它是指從遠端裝置中收集資料,並傳輸到接收裝置進行監測。在軟體開發中,遙測的含義引申為對各種指標(metric)資料進行收集,並監控、分析這些指標,比如我們經常聽到的 BI 資料分析。

Mixer 的一大主要功能就是遙測。前面已經說過,Envoy 代理會發送資料給 Mixer,這就使得 Mixer 具有了資料收集的能力。在對 Mixer 的介紹中讀者已經瞭解到 Mixer 的外掛模型,也就是介面卡。Mixer 可以接入不同的後端設施作為介面卡,來處理收集到的指標資料,比如:日誌分析系統、監控系統等。

視覺化

在微服務應用越來越複雜的情況下,對整個系統的狀態進行監控和追蹤變得尤為重要。試想如果一個包含上百個服務的系統發生了故障卻無法準確定位問題的根源,或者系統壓力已經到了承受的臨界值而運維人員卻渾然不知,這是多麼可怕的事情。沒有完備的、可觀察的監控系統就無法保障系統的穩定性。

Istio 可以很方便地和各種監控、追蹤工具整合,以便我們以視覺化的方式(網頁)直觀地檢視整個系統的執行狀態。比如:可以整合 Prometheus 來進行指標資料的收集,然後將收集的資料放在 Grafana 監控工具中展示;還可以整合 Jaeger 作為追蹤系統,幫助我們對請求的呼叫鏈進行跟蹤,在故障發生時分析出現問題的根源;或者將請求日誌記錄到 Kibana 系統,以圖表的方式進行資料分析。

以上提到的這些視覺化工具都會在整合到 Istio 中得到詳細的介紹。

安全

Istio 中的安全架構是由多個元件協同完成的。Citadel 是負責安全的主要元件,用於金鑰和證書的管理;Pilot 會將授權策略等資訊分發給 Envoy 代理;Envoy 根據策略實現服務間的安全通訊;Mixer 負責管理授權等工作。下圖展示了 Istio 的安全架構和運作流程。

Istio 安全架構

  1. 認證

Istio 提供如下兩種型別的身份認證。

  • 傳輸認證:也叫作服務到服務認證。這種方式的認證是通過雙向 TLS(mTLS)來實現的,即客戶端和服務端(或者是呼叫者和被呼叫者)都要驗證彼此的合法性。

  • 來源認證:也叫作終端使用者認證,用於驗證終端使用者或裝置。Istio 使用目前業界流行的 JWT(JSON Web Token)作為實現方案(在配置項上 Istio 提供了擴充套件性,但在撰寫本書時仍然只支援 JWT)。

這兩種認證的工作原理類似,都是將來自平臺的認證策略儲存起來,然後通過 Pilot 分發給 Envoy 代理,如下圖所示。

認證架構

  1. 授權

Istio 的授權功能沿用了 Kubernetes 中的授權方式:RBAC(Role-Based Access Control,基於角色的訪問控制)。它可以為網格中的服務提供不同級別的訪問控制。比如名稱空間級別、服務級別和方法級別。

下圖顯示了授權的工作方式。運維人員編寫授權策略的清單檔案並將其部署到平臺(Kubernetes)。Pilot 元件會獲取策略資訊並將其儲存到自己的配置儲存中,同時監聽授權策略的變更情況,以便及時更新。然後 Pilot 會把授權資訊分發給 Envoy 代理。Envoy 在請求到達的時候,評估當前的請求是否合法並作出相應的返回。

授權架構

與安全相關的配置涉及很多細節,我們會在後面的練習章節有針對性地進行具體介紹,以便讀者可以通過演練加深理解。

小結

本文主要介紹了 Istio 的理論知識。Istio 作為一個開源的服務網格產品,提供了統一的方式去管理流量、設定安全和監控等服務治理的能力。

Istio 的架構分為資料平面和控制平面,這種優雅的設計使得各個元件充分解耦,各司其職,這就是很多人將它稱為第二代服務網格產品的原因。資料平面即 Envoy 代理,負責流量的接管;控制平面包含了 Pilot、Mixer、Citadel 和 Galley,它們分別負責流量控制、策略控制、安全加固和資料收集。通過這些元件的協同工作,Istio 順利地完成了流量管理、策略和遙測、視覺化和安全這 4 大功能。

福利時間:留言贈書活動

我們聯合 「非同步圖書」為大家帶來 6 本非常適合雲原生工程師閱讀的 「Istio 實戰指南」,以上技術乾貨內容均摘自這本書。

推薦理由:本書作者:馬若飛,是 Service Mesher 社群管委會成員,Service Mesh 的佈道者。對於 Istio 的瞭解和認知都具備一定的權威性。

本書是 Istio 服務網格技術的入門圖書。全書共分為 10 章,深入淺出地介紹了 Istio 的相關知識,結合大量的示例,清晰而詳細的闡述了 Istio 的 4 大特性:連線、策略、視覺化和安全。

本書的第 1 章介紹了服務網格的起源和發展,第 2~4 章介紹了 Istio 的基本概念和安裝。從第 5 章起通過例項練習的方式介紹了 Istio 的流量管理等內容,並把 Istio 應用到真實的專案開發中,幫助讀者進一步理解概念。

如何參與贈書活動

  1. 在本文評論區直接留言說出你的運維故事或者對微服務的理解,點贊最多的前 6 名讀者評論為中獎使用者。

  2. 中獎者可獲得「Istio 實戰指南」 1 本。

  3. 中獎者必須是公眾號「運維之美」讀者。

  4. 活動截止時間:2019 年 8 月 30 日 18:00 整。

如何領獎

  1. 中獎者請在活動結束後 24 小時內與我們聯絡,如未在規定時間內聯絡,則視為放棄。如果您還不知道如何聯絡我們,可戳「這裡」。

  2. 中獎者需提供收件人姓名、收件人地址、收件人電話。

大家趕快抓緊時間留言吧,人人都有機會中獎喲,祝你好運!



你可能還喜歡

點選下方圖片即可閱讀


一文讀懂如何在 Kubernetes 上輕鬆實現自動化部署 Prometheus




點選「閱讀原文,優惠價搶購
👇。

已同步到看一看
在看



熱點新聞