從架構到元件，深挖istio如何連線、管理和保護微服務2.0？
近幾年我一直從事於微服務系統的設計以及實現方面的工作，屬於微服務架構一線實踐者。之前做過一些單體系統的微服務改造，在微服務拆分、治理等方面都有一定的經驗。
本人比較特殊一點的經歷是既做過 IT 領域的微服務，也做過 CT（通訊領域）的微服務，微服務架構在這兩個領域的具體形態和要求是不太一樣的，但其中一些思想是互通且是很有借鑑意義的。今天主要介紹一下關於微服務的最新發展動態，以及最近谷歌推出的 Istio平臺架構。
今天介紹的主題包含：服務治理、服務網格、Istio架構，以及 Istio 相應的系統組成。
一、分散式計算的八個謬論
1.png
彼得多維奇多年前提出的分散式計算的八個謬論，對於開發人員來說他們往往會忽視這八條。這八條基本上都和網路相關，例如在發起一個網路請求時，會不斷地做一些嘗試等待，來保障訊息投遞的有效性。
微服務是一個更為複雜的分散式系統，之前 SOA 或者B/S，CS 架構，它的顆粒度會更粗一點，但是如果採用微服務，它的顆粒度是更細的。在馬丁·富勒部落格《微服務的先決條件是什麼》一文中提到一條，你必須要成為“高個子”，想成為“高個子”其實並不簡單，很多公司，它們都是為了成為“高個子”，做了很多框架、平臺。
二、 服務治理
1、微服務治理的技術點
2.png
要成為“高個子”需要對微服務進行哪些改造，這裡是相關服務治理的技術點，其中只是一部分，和服務網格比較相關的技術點，包含服務發現、負載均衡、請求路由、認證與授權、可觀測性，還有健康檢查、容錯等。目前主流的解決方案有眾所周知的 Spring Cloud， Dubbo 等，這些都是提供庫來把服務治理相關的內容打包，供具體的業務去呼叫。
2、 庫或框架的問題
但是庫和框架會存在一些問題：
** 1、學習成本。**多一個庫對於開發人員而言，意味著要多學一些東西，並且在業務開發過程中，還會受到庫或者框架的制約。
2、對業務程式碼的侵入性。 例如用 Spring Cloud 會在程式碼裡面加很多額外的內容，比如每個請求裡面加一個註解來表達想引用服務治理的某些功能。
3、基礎庫的維護、升級和下線。 如果是以庫的方式來提升到服務裡面，庫的維護、升級、下線就會造成整個服務的維護、升級、下線。
4、不同語言和技術棧。 在提出微服務概念時，它的一個重要好處就是可以使用不同的技術棧來開發微服務，但如果受到框架制約，只能用這個語言，這是我們比較頭痛的事情，無法發揮微服務跨語言的能力。
這些問題其實是有嚴重程度的，從上往下越來越讓開發人員覺得不舒服。理想中的服務治理方案是什麼？可以先暢想一下，整個服務治理相關的東西，應該是和業務邏輯完全隔離的，並且服務和服務之間的互動是不會考慮服務治理這塊內容，最好對於業務開發來說是不可見的。
這時候怎麼去做呢？就引出了容器經典部署模式——Sidecar。
3、 Sidecar模式
4.png
Sidecar 模式通常是和容器一起使用，如果不和容器一起使用也沒關係，那就是兩個獨立的程序，如果和容器使用的話，就基於容器為單位。Sidecar模式是物理隔離的，並且與語言無關。因為是兩個獨立的東西，可以獨立釋出，和微服務理念一樣。另外它們是部署在同一個 Host 上面，所以資源之間可以做到相互訪問，並且因為在一起所以通訊延遲也不會太明顯。和業務無關的功能都可以放上去，形成多個 Sidecar。今天 Sidecar 主要是把一些服務治理相關的東西放在裡面，做軟體設計上的思想就是分離關注點。
5.png
基於 Sidecar 模式做服務治理，之後形成連線的具體狀況，如圖，對於服務A來說，服務A是不知道和 Sidecar 進行通訊，服務A還是向服務B發訊息，照常呼叫通訊介面，但是訊息可能會被 Sidecar 捕獲到，然後通過Sidecar 進行轉發。
三、服務網格
8.png
從整個系統來看，如果以 Sidecar 方式來部署服務治理以及服務的話，最終形成的系統如圖。能看到通過 Sidecar 進行相互連線，形成一個網路，這也是服務網格名字的由來。每一個節點上面都相當於具體的網格，和多年之前提的網格計算有點類似。
服務網格如果站在更抽象的層次來看是什麼樣子？把服務治理相關的東西抽象來看的話，服務網格也算是一種基礎設施，它和具體的業務無關。不管是 PaaS 的發展，還是服務網格的發展，都是將與業務無關的內容的共同點提取出來，然後形成獨立的一套平臺或者方案。另外，服務網格之間要形成可靠傳遞，剛才提到的重試等功能都應該具備。
服務網格是輕量級的網路代理，不能太重，不能喧兵奪主，服務才是整個系統中最重要的東西，而這些基礎設施並不應該取代服務最重要的價值地位。
更關鍵的一點是要對應用程式透明。對於服務而言是看不到 Sidecar、看不到代理的，服務如果要發訊息出去，它知道是發給這個代理的，那對於我們的業務來說同樣也是一種汙染。服務網格最終不再強調代理作為單獨的元件，不再孤立的來看代理，而是從全域性的角度來看待代理所形成的網路。
1、 服務網格定義
服務網格的定義是 Willian Morgan 提出來的，他是最早做服務網格的人。如圖，文字加粗的是服務網格一些關鍵技術點。右邊圖是最新發展的服務網格，在最上層還會加一個控制面板，通過控制面板來管理這些代理，這些代理是需要被管理的。如果我們的運維環境沒有控制面板，可能就沒辦法運維了。
2、 服務網格的基本構成
9.png
服務網格必須要具備 資料面板 和 控制面板 ，如果新開發一個服務網格只有資料面板，它肯定不是一個完整的服務網格。
資料面板是用來接收系統中的每一個包或者請求，提供服務發現、健康檢查等服務治理相關的，都是由資料面板來完成。資料面板的一些典型代表有 Linked 、 Envoy 、和 Nginx 公司開發的 Nginmesh ，以及硬體服務的代理廠商F5開發的 Aspen Mesh 。目前主要的、成熟的是 Linked 和 Envoy，這兩者都在生產環境上面真實部署過，實戰過。而且Linked的採用會更廣泛一些，因為它出現的時間最早。
對於控制面板來說，是為了在網格中運營的資料面板提供策略和配置，負責一些管理工作，它不會接收系統中的任何包或者請求。這裡的包和請求應該是業務相關的包和請求，和具體的業務是完全沒關係的。本來做微服務應該做去中心化的事情，但是又有一個控制點在那裡，要強調的是那個控制點和具體的業務沒什麼關係。控制面板的典型代表，包括 Istio、Conduit 、 Nleson、SmartStack， 目前最新的是 Istio 和 Conduit。
3、 資料面板對比
10.png
左邊是 Linked（Scala編寫），右邊是 Envoy（C++編寫），它們最大的區別就是實現語言的區別。同時，Linkerd 和 Envoy 都是在生產環境已經驗證過的兩個系統，功能上都沒問題，都比較強大，它們唯一的區別就是對於硬體資源的要求，Linked 是非常高的，它可能就會造成喧兵奪主的感覺，所以目前 Envoy 在這塊是比較火的，Envoy 是由C++開發的。
4
控制面板對比
11.png
兩個最新的控制面板，一個是 Istio，是由 Google、IBM、Lyft 開發的，而 Conduit 是由 Buoyant 公司開發的，跟剛才所說的效能不太好的資料面板Linkerd是同一家公司，Buoyant 在 Linkerd 之後又重新開發了 Conduit，專門來解決效能上的問題，所以在效能上面來看，Conduit 的效能指標已經出來了，就是微秒級，並且是P99延遲。
但是 Istio 的效能指標現在還沒出來，還在功能開發階段。因為 Istio 需要實現的功能比較多，要支援各種各樣的平臺和過濾，Istio 整個架構非常靈活，所以 Istio 整個量級是比較重量的，但是 Conduit 只支援 K8S，Conduit 的原則是怎麼快怎麼來。
從程式語言上來說，控制面板 Istio 和 Conduit 都是使用Go語言，但是在資料面板上 Istio 是使用C++，Conduit 使用 Rust，可以看出來這兩個語言都是那種比較高效的，在資料面板上面必須要使用高效的語言來完成。
四、Istio架構
12.png
一句話定義 Istio： 一個用來連線、管理和保護微服務的開放平臺。 剛才也說了 Istio 是 Google 開發的，所以 Istio 今後的趨勢肯定是會越來越火的，並且目前 K8S 已經把它整合到裡面了，做成一個可選的元件。
對於連線而言，Istio 它主要包含彈性、服務發現、負載均衡，管理是流量控制、策略增強，監控也有，並且安全這塊 Istio 也是有考慮，Istio 是端到端的身份驗證和授權，等一下會詳細的介紹。
Istio的****關鍵特性****:
13.png
14.png
1、智慧路由和負載均衡。 這裡的智慧路由和負載均衡是屬於比較高階的，不是像傳統簡單的隨機負載均衡，而是可以基於一些資料包內部的內容來進行負載均衡。
2、跨語言和平臺的彈性。 對於平臺來說 Istio 是支援各種各樣的平臺，並且能支援A/B測試，金絲雀釋出，並使用藍綠部署運維上的一些高階功能。
3、全面策略執行。 Istio 有一個元件是專門負責保障策略能夠通過一個元件下發到具體的資料面板。
4、遙測和上報。 即具體的測量以及流量的監控等。
這個就是 Istio 整個的系統架構，如圖，上面是控制面板，下面是很多資料 Envoy，很多個代理，形成一個數據面板。後面我們會對單個進行詳細介紹。
image.gif
這是在 K8S 下面 Istio 部署的示意圖，可以看到它們之間最關鍵的東西是所有服務和元件都會有一個代理，這代理是必備的，包括控制面板都會有代理。沒有畫的有兩個東西，一個是 Ingress，一個是初始化器，初始化器主要是做代理注入。它們之間相互的互動都是通過加密，由TLS協議來完成。
五、Istio元件
1、 資料面板Envoy
17.png
介紹一下 Istio 的核心元件，首先是 Istio 的資料面板 Envoy。
Envoy 的目標是透明地處理叢集內服務間、從服務到外部服務之間的出入口流量。Envoy 是用C++編寫的，高並行、非阻塞。並且是可裝卸的L3/4過濾器，以及L7的過濾器，最終會形成一個過濾鏈來對流量進行管理或者控制，Envoy 是通過 xDS 動態配置來進行介面提供。
下面就是一些固有的功能，服務發現、健康檢查。Envoy 的健康檢查也做的顆粒度比較細，包含主動健康檢查和被動健康檢查。主動健康檢查像常規的健康檢查，主動地發一個健康檢查的介面呼叫請求，查詢一下。被動的是通過對其他服務的一些請求，從一些返回值進行健康檢查。當然還包含高階的負載均衡，監控、跟蹤這些功能。
Envoy最關鍵的三個點：
- 高效能。一直在強調的是資料面板必須要高效能，因為是要和業務服務部署在一起的。
- 可擴充套件。
- 可配置。具有動態配置的特性。
Envoy 是如何做到高效能的？
18.png
Envoy 的執行緒模型分為三類執行緒，如果做過C++開發，這種單程序多執行緒的架構是很常見的。Envoy 分為主執行緒、工作執行緒、檔案重新整理執行緒，其中主執行緒就是負責工作執行緒和檔案重新整理執行緒的管理和排程。而工作執行緒主要負責監聽、過濾和轉發，工作執行緒裡面會包含一個監聽器，如果收到一個請求之後會通過剛才所介紹的過濾鏈來進行資料過濾。前面兩個都是非阻塞的，唯一一個阻塞的是這種 IO 操作的，會不斷地把記憶體裡面一些快取進行落盤。
19.png
服務網格所強調的另外一個功能，是動態配置不用重啟，實際上是重啟的，它會啟動一個新的程序，然後在這程序之上進行新的策略，還有一些初始化，這時候再請求監聽，之前那個程序的 socket 副本。當老的關閉連結以及退出之後，它才會接收新的，這時候就實現了對使用者沒有感知的重啟。
這就是它的 xDS，如圖，可以看到它的密度是非常細的，
20.png
- 終端發現服務（EDS），實際上就是服務的發現服務；
- 叢集發現服務（CDS）是為了發現叢集；
- 路由發現服務（RDS）是為了對路由進行一些處理；
- 監聽器（LDS）來動態地新增、更新、刪除監聽器，包括過濾鏈的一些管理、維護。
- 另外還有剛才說到的健康檢查（HDS），
- 還有聚合（ADS）是對於監控指標進行聚合的介面；
- 另外一個金鑰發現（KDS）是和安全相關的。
首先，如果來了一個請求，會到剛才所說的工作執行緒裡面去，工作執行緒會有監聽器，收到之後進行一些處理，然後要往外發，這時會呼叫路由的發現功能，然後再找到相應的叢集，再通過這個叢集找到相應的服務，一層一層的往下面呼叫。
2、 控制面板Pilot
接下來介紹的是控制面板的三大元件，第一個就是 Pilot。
22.png
Pilot 是執行時的代理配置，剛才所說的 xDS，就是用 Pilot 來進行呼叫，負責把相應的一些策略，失敗恢復的特性派發下去。Pilot 是負責管理所有的這些代理，代理和管理就通過 Pilot 來完成，是平臺無關的一個拓撲模型。目前主要支援的是 K8S。
23.png
Pilot 是一層抽象的獨立於底層平臺的模型，因為這裡有個代理，對於多平臺或多樣性的管理架構，即介面卡的架構。平臺特定的介面卡負責適當填充這些規範，要通過具體平臺的介面卡形成一些規範，和通用的模型結合，生成必須要往 Envoy 下發的資料，並且配置、推送都是由 Pilot 來完成的。
Pilot 的整個服務發現和負載均衡，如圖，Pilot 是Kubernetes DNS提供的域名進行訪問，首先呼叫 Service B 的url，這時候 Envoy 會進行截獲並處理，處理完之後會找到相應的負載均衡的池子挑選一個進行流量下發。Pilot 目前支援的這種負載均衡的方法，規劃了很多種。但目前只實現了三種，前兩種還是隨機和輪循，多了一個最小請求的負載均衡演算法。它能找到這些 Pilot 裡面哪個被呼叫的最少，然後進行呼叫。
Pilot 的一些規則配置，可以看到基本是負責規則的管理以及下發。
- 路由規則。
- 目的地策略。 主要包含負載均衡的演算法，以及對於負載均衡演算法抽象的策略預演。
- 出站規則。
把這些規則分了三類，好處是對這三類都會生成一些模板。
image.gif
流量的拆分可以看到是基於標籤的流量拆分，這裡配置的如版本，環境，環境型別，它根據這個規則來進行流量的派發。比如說99%都發給之前版本，新版本先1%先測一下，類似於A/B測試。
另外一個比較高階的是基於內容，因為它是L7的這種過濾，可以基於內容來過濾，並且支援表示式，這種將iPhone的流量全部導到新的服務裡面去，並且有標籤，版本必須得是金絲雀版本。
3、 混合器Mixer
28.png
Mixer 是在應用程式碼和基礎架構之間提供一箇中間層，來隔離 Enovy 和後臺基礎設施，這裡的後臺是指 Promethus，ELK 這些。
Mixer 有三個核心特性：
- 先決條件檢查。 負責白名單以及 ACL檢測；
- 配額管理。 負責這種使用頻率上的控制；
- 遙測報告。
總共分為兩類，在生成配置模板的時候它是有兩類的，第一類就是負責檢查check，第二類就是負責報告reporter。
Mixer 是採用通用的外掛模型以實現高擴充套件性，外掛被稱為介面卡。運維人員下發一些配置到這裡面，這些模板又是由模板開發人員進行開發的，Istio提供了很多通用性的模板，上面簡單地改造一下就能做出一個模板來。介面卡也有很多種，各種後臺、平臺的都有。
Mixer 是抽象了不同後端的策略，遙測系統的細節，它就對這兩個東西進行了抽象，形成了一套抽象的東西。
29.png
剛才介紹過介面卡，再來介紹一下處理器，它是配置好的介面卡，由運維人員進行配置，之後形成最終的處理器，負責真正往後臺發東西。
它封裝了與後端介面所需的邏輯，指定了配置規格，以及介面卡。如果要在後臺進行訊息互動的話，所需要的操作引數在這裡也會定義。而右邊就是兩個模板，第一個模板是 Prometheus，它是一個處理器，下面是它的一些指標。另外一個是白名單檢查的模板，提供URL，以及它請求的介面返回值。
剛才介紹了整個通路是怎麼打通的，包括介面卡和處理器都是為了幹這個事情，這個通路怎麼建立？接下來要介紹的是這個引數怎麼生成，它是請求屬性到一個模板的對映結果。
Mixer 會收到 Envoy 發過來的很多屬性（請求），請求裡面包含的資料都稱之為屬性。通過它的模板來生成相應的具體引數，這邊也是剛才兩個例子裡面對應的模板。上面是度量指標採集用的，下面是白名單。
32.png
33.png
這裡有個遙測報告的示例，當收到一個請求之後會發生什麼。它會以屬性的形式，這邊有個 Zipk，就直接上報了，這是因為 Envoy 原生的就支援Zipk。Envoy 支援後端監控的東西，就是 Zipk，所以它可以直接發給它。其他的需要通過 Mixer 來進行轉發。
首先它收到這個屬性之後，會把這個屬性生成具體的例項。根據運維人員提供的配置，Mixer 將生成的資料分發到一組介面卡，介面卡要根據運維人員的配置來生成具體的資料，之後就可以把剛才所生成的例項往下發了。發到後端後可以進行進一步的分析和處理。
4、 金鑰管理
38.png
最後要介紹的就是安全相關的，Certificate Authority 這塊，這是整個金鑰管理的示意圖，可以看到服務和 Envoy 是通過 TCP 進行互動的，但是Envoy 和 Envoy 之間是通過 MTIS 進行加密，是雙向的 TIS 加密。它的好處是，會在內部的每一個服務節點之間做加密，當然這是可選的，根據效能的需求來進行選擇。
金鑰管理分為四個步驟，這四步就是四個特性，第一，通過服務帳戶生成的金鑰和證書，然後再將金鑰和證書部署到 Envoy上，它還支援週期性的對這證書進行更新，另外還支援撤銷的功能。
這是它的兩種部署方式，一種 K8S 的部署方式，另外如果是虛擬機器，它會單獨有一個節點代理，通過節點代理來發出簽名請求給CA，CA再生成金鑰和證書給代理，代理再來負責部署到 Envoy上。
具體的執行時它們都有各自的證書，開始進行雙向的 TIS，這時候會到名字資訊裡面去查詢，後端有沒有許可權訪問，如果有的話就往下，沒有就結束了。
第三步，如果收到一個客戶端的請求，會去 Mixer 裡面判斷一下，它是白名單上的一個判斷或者是不是黑名單上的一個判斷，會影響“握手”的成功與否。最終它們就形成了安全互動的通道。
45.png
謝謝大家，今天我們主要給大家介紹一下 Istio 是什麼，大家有初步的認識，並且對它裡面比較關鍵的技術進行了介紹。
六、Q&A
Q1： 現在有這麼個專案，您怎麼看像這種專案的發展？第二個問題，你們中心現在在做，您也分析的挺深入，未來是什麼計劃，會和paas有融合嗎？
A1： 先回答第一個問題，我們可以看到不管是資料面板還是控制面板都會有很多個，但是控制面板，谷歌和IBM，剛才所說的是由三個公司來開發的，谷歌、IBM，還有Lyft，那個公司類似於滴滴那種業務的公司，它們負責Envoy的開發，資料面板是它們公司來負責。我們可以看出來它們是有點分離的感覺，對於谷歌或者IBM來說它們更關注的是控制面板，並且在控制面板和資料面板之間的介面設計的非常好，設計了一套通用的介面。它們最終是分為兩個方向發展，但是都可以通過同一套標準整合起來。
第二個問題，首先公司內部都在採用微服務，對於Istio至少要到1.0之後才會在內部環境使用，如果沒問題才會逐漸往真正的對外業務使用它，包含通訊裡面都可能會用它。但是對於CT領域來說的話，用這個可能代價就需要好好地評估一下了。因為效能上的問題，它畢竟還是多了一跳。如果兩個服務之間的互動就相當於多了兩跳，對於通訊這種實時性要求非常高的領域可能會存在問題。我們也會開發自己的一套侵入式框架，可以參考Envoy的實現。
Q2： 我們現在遊戲專案裡面剛好也用到它。但是它有個問題，用的感覺有點大材小用，我們用它做呼叫鏈關係分析，因為我們叢集開發很多遊戲，每個遊戲有個pilot，但是如果出了問題我不知道，那它裡面的一個插片自動生成，它只能識別K8叢集裡面pod。如果我們想用它把K8S的叢集和非K8S的叢集呼叫，並且全部進行連線起來的話，它是否支援？
A2： 我覺得它現在由於所處在初級階段所以暫時不支援是正常的，但它後續的發展肯定會支援，因為它們整個設計的目標就是為了達到這種服務粒度，而不僅限於K8S pod這種管理粒度。
Q3： 我有一個關於sidecar的問題，如果作為一個客戶端去請求的時候應該要引流引到sidecar上面，它引流是怎麼引的？如果直接轉過去的話又怎麼去識別目標的服務到底是什麼樣的？它呼叫的是什麼服務，後端可以路由到幾個上？
A3： 這個資訊都是由剛才所說的pilot來負責收集，它會把這些資訊下發到Envoy上，所以它在做路由演算法的時候會訪問，來獲取它可以訪問到哪些服務，它會把服務的資訊找到，包括它能訪問的服務池包含哪些內容，然後再通過策略進行控制。
它是會反向再去K8S裡面找到的，並不是完全Envoy自己來負責，這些資訊都是由pilot來給它，拿到這些資訊再做處理，最終還是會和平臺結合到一起。它有一個假設，所有的平臺都會實現這種服務發現的介面，並且會從服務發現的介面拿到一些必要的資訊，包含你剛才說的，會轉成相應的IP。