書籍英文版下載連結為 https://developers.redhat.com/books/introducing-istio-service-mesh-microservices/，作者 Burr Sutter 和 Christian Posta。 

第一章 概述

中文翻譯  劉世民 @2020.02

如果你正在尋找帶有詳細示例的有關Istio的介紹性文件，那這本書正好合適你。本書適合正在基於微服務架構開發雲原生應用的應用架構師和開發團隊組長們閱讀。本書假設你已有Docker使用經驗；因為Istio已在多個Linux容器編排專案中被用到，本書聚焦在Kubernetes和OpenShift中使用Istio。本書中，我們會不加區分地使用Kubernetes和OpenShift這兩個術語（OpenShift是紅帽公司釋出的Kubernetes發行版本）。 

如果你需要一本介紹基於Spring Boot和Thorntail（之前被稱為WildFly Swarm）的Java微服務的書，我推薦你閱讀由Christian Posta寫作的Microservices for Java Developers（O’Reilly）一書。

如果你對響應式微服務（reactive microservice）感興趣，那我推薦你從閱讀Clement Escoffier所作的Build Reactive Microservices in Java（O’Reilly）一書開始。這書詳細介紹了Vert.x，這是一個使用JVM的響應式微服務程式設計套件。 

另外，本書還假設你已有一些Kubernetes/OpenShift使用經驗；如果還沒有，那我推薦你閱讀由Grant Shipley 和 Graham Dumpletion寫作的OpenShift for Developers（面向開發者的OpenShift，O’Reilly）一書。我們會在OpenShift環境中部署、配置和使用Istio；然而，我們所用到的大多數命令都可以直接在Kubernetes中使用。 

我們現在來看下Istio可以幫助開發者解決哪些困難，然後介紹它的主要元件。 

1.1 前方的挑戰 

當前，軟體開發領域正處於數字化轉型時代，正在追求更好地服務客戶和使用者。如今的數字化創造者，也就是應用程式設計師們，不僅已通過運用Agile標準進入更快的開發週期，而且還在不斷追求更快的開發速度。儘管單體應用有可能每月或每週做一次部署，但是，通過將大型單體應用拆分為更小的單元，將大型開發團隊拆分為更小的小組，採用小組間無依賴的工作流、管理模型和開發流水線，我們還可能取得更快的產品交付速度。業界將這稱為微服務架構。 

關於使用微服務而會面臨的各種挑戰已有很多報道，首當其衝的，是將它和分散式計算（distributed computing）混為一談。最大的假象是“網路是可靠的”。微服務通過網路（即微服務之間的連線）進行有效通訊。這是過去幾十年來大多數企業軟體製作方式的根本變化。當你將網路依賴性新增到應用程式的邏輯中時，就會導致很多潛在風險，這些風險與應用程式所依賴的連線數量成指數性增長，而不是成倍增加。 

很容易理解的是，當部署週期從每幾個月一次顯著提升到每週甚至可能每天數十次時，挑戰會層出不窮。 

一些大型網際網路公司不得不開發特殊的框架和庫來幫助緩解不可靠的網路、易失性的雲主機以及海量程式碼量所帶來的挑戰。例如，像Netflix這樣的公司建立了Ribbon、Hystrix和Eureka等專案來解決這種問題。Twitter和Google等其他公司也做了類似的事情。他們建立的這些框架具有非常強的語言和平臺依賴性，因此，當使用這些框架不支援的程式語言時，這些框架將很難用得上。每當這些框架更新後，還需要相應地更新應用程式。最後，即使他們為每種語言執行時在框架中都增加了支援，在使用過程中也會有大量開銷。至少在Netflix中，這些庫的建立是在虛擬機器（VM）作為主要可部署單元的情景中，它們只能在單個雲平臺和單個應用程式執行時（Java虛擬機器）上實現標準化。大多數公司不能也不會這樣做。 

Linux容器（例如Docker）和Kubernetes / OpenShift的出現，使得DevOps團隊通過在高度自動化的流水線中使用快速流轉的不可變映象來獲得更高的速度。現在，開發團隊管理流水線的方式獨立於容器內執行的語言或框架。OpenShift使我們能夠為一組複雜的分散式多語種工作負載提供更好的彈性和整體管理。OpenShift確保開發人員可以輕鬆部署和管理數百個甚至數千個微服務。這些服務被打包為在Kubernetes Pod中執行的容器，並帶有它們各自的語言執行時（例如Java Virtual Machine，CPython和V8）及其所有必要的依賴庫，通常以特定語言的框架的形式出現（例如Spring或Express）和庫（例如jar或npms）。但是，OpenShift並不介入在各個Pod中執行的應用程式元件之間的互動。這是架構師和開發人員所面臨的挑戰。快速部署和管理多語言服務的工具和基礎架構已經成熟，但是當處理這些服務之間的互動時，我們卻缺少類似功能。在這裡，Istio這種服務網格將使你作為應用程式開發人員可構建更好的軟體並比以往更快地交付它。 

1.2 初始Istio 

Istio是一種服務網格（service mesh）的實現。服務網格是服務之間的連線組織，帶有一些附加功能，例如流量控制、服務發現、負載平衡、彈性、可觀察性和安全性等。服務網格使得應用程式從程式碼中解除安裝這些功能，以讓開發人員專注於業務邏輯。 

Istio一開始就被設計為可跨部署平臺工作的，同時它具有一流的對Kubernetes的整合性支援。 

就像Kubernetes生態系統中的許多開源專案一樣，Istio是希臘航海術語，意為“風帆”，就像Kubernetes本身是希臘語中的“舵手”或“船上駕駛員”一樣。有了Istio後，人們對服務網格概念的興趣與日俱增，而Kubernetes / OpenShift離開的地方就是Istio的起點。Istio為開發人員和架構師提供了豐富的宣告式服務發現和路由功能。在Kubernetes / OpenShift的服務（service）元件為你提供預設的輪詢（round-robin）負載均衡功能時，Istio允許你在網格內的所有服務之間引入唯一且細粒度的路由規則。Istio還為我們提供了強大的可觀察性，以能更深入地研究分散式微服務間的網路拓撲，瞭解它們之間的流（跟蹤）並能夠即時檢視關鍵指標。

既然網路實際上並不總是可靠的，那麼，就需要對微服務間的關鍵鏈路進行更嚴格的監控和操作。Istio為我們提供了網路層的彈性功能，例如重試、超時以及各種斷路器功能。 

Istio還為開發人員和架構師提供了實踐混沌工程學的能力。在第5章中，我們描述了Istio推動混沌注入的能力，以便你可以看到整個應用程式及其潛在的數十種相互依賴的微服務的彈性和健壯性。 

在開始討論之前，我們想確保你對Istio有基本的瞭解。以下部分將概述Istio的基本元件。

1.3 理解Istio元件 

Istio服務網路主要包含兩個平面：資料平面（data plane）和控制平面（control plane），如圖1-1所示。

 圖1-1 Istio的資料平面和控制平面

1.3.1 資料平面 

資料平面的實現方式是攔截所有入站（ingress，入口）和出站（egress，出口）網路流量。你的業務邏輯、應用程式和微服務都不會覺察到這種攔截。你的微服務可使用簡單框架在整個網路上呼叫遠端HTTP端點（例如Spring RestTemplate或JAX-RS客戶端），並且大多數情況下對這種攔截帶來的眾多有趣能力全然不知。圖1-2描述了Istio出現之前的典型微服務。

 圖1-2 Istio出現前的微服務架構 

Istio服務網格的資料平面由以邊車容器（sidecar container）形式執行的istio-proxy例項組成，如圖1-3所示。

圖1-3 Evoy邊車（istio-proxy）

服務代理 

服務代理（Service proxy）增強了應用程式服務。每當需要通過網路進行通訊時，應用程式服務就會通過服務代理進行呼叫。服務代理充當中介或攔截器，可以新增諸如自動重試、斷路器、服務發現和安全性等功能。Istio的預設服務代理基於Envoy代理。 

Envoy代理是Lyft開發的第7層（L7）代理（請參閱Wiki上的OSI模型），目前Lyft在生產環境中使用該代理每秒處理數百萬個請求。它使用C ++編寫，經過了實戰測試，效能高和輕量級。它提供諸如HTTP1.1，HTTP2和gRPC的負載平衡功能。它具有收集請求級別指標和跟蹤範圍（trace span）能力，提供服務發現和注入故障等功能。你可能會注意到Istio的某些功能與Envoy重疊。由於Istio使用Envoy來實現這些功能，因此這一點很好理解。 

但是Istio如何將Envoy部署為服務代理呢？Istio使用一種稱為邊車（sidecar）的部署技術，使服務代理功能與應用程式程式碼儘可能靠近。 

邊車（Sidecar） 

當Kubernetes / OpenShift誕生時，它們並沒有像人們原本期望的那樣將Linux容器用作可執行和可部署單元。相反，它創造了Pod概念，這是在Kubernetes / OpenShift世界中被管理的主要目標。為什麼需要Pod呢？有人認為這借鑑了1956年的電影《Invasion of the Body Snatchers》，但實際上借鑑了家庭或鯨魚概念。鯨魚是與Docker開源專案相關聯的早期映像，該專案是那個時代最流行的Linux容器解決方案。Pod可以是一組Linux容器。Sidecar是另一個Linux容器，直接與你的業務邏輯應用程式或微服務容器並存。在現實世界中，邊車被固定在摩托車的一側作為一簡單附屬品；與之不同的是，Istio中的邊車可以接管車把和油門。 

使用Istio，可以將第二個Linux容器“ istio-proxy”（也稱為Envoy服務代理）手動或自動注入到容納你的應用程式或微服務的pod中。該邊車負責攔截來自業務邏輯容器的所有入站（入口）和出站（出口）網路流量，這意味著可以應用新策略來重新路由傳入或傳出的流量，還可以應用諸如訪問控制列表之類的策略（ ACL）或速率限制，還會抓取監視和跟蹤資料（Mixer），甚至引入一些混亂，例如網路延遲或HTTP錯誤。 

1.3.2 控制平面 

控制平面負責成為配置和策略的中心，並使資料平面在群集中變得可操作，該群集可能由分散在多個節點上的數百個Pod組成。Istio的控制平面包括Istio的三項主要服務：Pilot，Mixer和Citadel。 

Pilot 

Pilot是一個Istio元件，它負責管理在Kubernetes / OpenShift叢集中執行的所有微服務的邊車。Istio Pilot將每個獨立的istio-proxy微服務包裝成Linux容器並在應用程式pod中執行，並具有整體拓撲的實時檢視和保持更新的“路由表”。Pilot提供了服務發現等功能，以及對VirtualService的支援。VirtualService使你可以進行細粒度的請求分發、重試、超時等。我們將在第3章和第4章中對此進行詳細介紹。 

Mixer 

顧名思義，Mixer是將事物整合在一起的Istio服務。每個分散式istio-proxy將遙測資料傳遞迴Mixer。此外，Mixer維護整個微服務套件使用和訪問策略的規範模型。使用Mixer，你可以建立策略，應用速率限制規則，甚至抓取自定義指標。Mixer具有可插拔的後端體系結構，並隨著新外掛和合作夥伴的發展而迅速發展，這些外掛和合作夥伴以許多新穎有趣的方式擴充套件了Mixer的預設功能。Mixer的許多功能超出了本書的範圍，但我們會在第6章中介紹可觀察性，在第7章中介紹了安全性。 

Citadel 

Istio Citadel元件（以前稱為Istio CA或Auth）負責證書籤名、頒發、吊銷及輪換。Istio向所有微服務頒發X.509證書，從而允許服務間進行雙向傳輸層安全（mTLS）通訊並透明地加密所有流量。它使用內建在基礎平臺中的身份，並將其構建到證書中。此身份使你可以執行策略。第7章討論了設定mTLS的示例。  

本英文譯稿版本由本人所有。水平有限，錯誤肯定是有的，還請海涵。 

感謝您的閱讀，歡迎關注我的微信公眾號：

&n