書籍英文版下載鏈接為 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的示例。
本英文譯稿版本由本人所有。水平有限，錯誤肯定是有的，還請海涵。
感謝您的閱讀，歡迎關注我的微信公眾號：
