本人比較特殊一點的經歷是既做過 IT 領域的微服務，也做過 CT（通訊領域）的微服務，微服務架構在這兩個領域的具體形態和要求是不太一樣的，但其中一些思想是互通且是很有借鑒意義的。今天主要介紹一下關於微服務的最新發展動態，以及最近谷歌推出的 Istio平臺架構。

今天介紹的主題包含：服務治理、服務網格、Istio架構，以及 Istio 相應的系統組成。

一、分布式計算的八個謬論

彼得多維奇多年前提出的分布式計算的八個謬論，對於開發人員來說他們往往會忽視這八條。這八條基本上都和網絡相關，例如在發起一個網絡請求時，會不斷地做一些嘗試等待，來保障消息投遞的有效性。

微服務是一個更為復雜的分布式系統，之前 SOA 或者B/S，CS 架構，它的顆粒度會更粗一點，但是如果采用微服務，它的顆粒度是更細的。在馬丁·富勒博客《微服務的先決條件是什麽》一文中提到一條，你必須要成為“高個子”，想成為“高個子”其實並不簡單，很多公司，它們都是為了成為“高個子”，做了很多框架、平臺。

二、服務治理

1、微服務治理的技術點

要成為“高個子”需要對微服務進行哪些改造，這裏是相關服務治理的技術點，其中只是一部分，和服務網格比較相關的技術點，包含服務發現、負載均衡、請求路由、認證與授權、可觀測性，還有健康檢查、容錯等。目前主流的解決方案有眾所周知的 Spring Cloud， Dubbo 等，這些都是提供庫來把服務治理相關的內容打包，供具體的業務去調用。

2、庫或框架的問題

但是庫和框架會存在一些問題：

1、學習成本。多一個庫對於開發人員而言，意味著要多學一些東西，並且在業務開發過程中，還會受到庫或者框架的制約。

2、對業務代碼的侵入性。例如用 Spring Cloud 會在代碼裏面加很多額外的內容，比如每個請求裏面加一個註解來表達想引用服務治理的某些功能。

3、基礎庫的維護、升級和下線。如果是以庫的方式來提升到服務裏面，庫的維護、升級、下線就會造成整個服務的維護、升級、下線。

4、不同語言和技術棧。在提出微服務概念時，它的一個重要好處就是可以使用不同的技術棧來開發微服務，但如果受到框架制約，只能用這個語言，這是我們比較頭痛的事情，無法發揮微服務跨語言的能力。

這些問題其實是有嚴重程度的，從上往下越來越讓開發人員覺得不舒服。理想中的服務治理方案是什麽？可以先暢想一下，整個服務治理相關的東西，應該是和業務邏輯完全隔離的，並且服務和服務之間的交互是不會考慮服務治理這塊內容，最好對於業務開發來說是不可見的。

這時候怎麽去做呢？就引出了容器經典部署模式——Sidecar。

3、Sidecar模式

Sidecar 模式通常是和容器一起使用，如果不和容器一起使用也沒關系，那就是兩個獨立的進程，如果和容器使用的話，就基於容器為單位。Sidecar模式是物理隔離的，並且與語言無關。因為是兩個獨立的東西，可以獨立發布，和微服務理念一樣。另外它們是部署在同一個 Host 上面，所以資源之間可以做到相互訪問，並且因為在一起所以通信延遲也不會太明顯。和業務無關的功能都可以放上去，形成多個 Sidecar。今天 Sidecar 主要是把一些服務治理相關的東西放在裏面，做軟件設計上的思想就是分離關註點。

基於 Sidecar 模式做服務治理，之後形成連接的具體狀況，如圖，對於服務A來說，服務A是不知道和 Sidecar 進行通信，服務A還是向服務B發消息，照常調用通信接口，但是消息可能會被 Sidecar 捕獲到，然後通過Sidecar 進行轉發。

三、服務網格

從整個系統來看，如果以 Sidecar 方式來部署服務治理以及服務的話，最終形成的系統如圖。能看到通過 Sidecar 進行相互連接，形成一個網絡，這也是服務網格名字的由來。每一個節點上面都相當於具體的網格，和多年之前提的網格計算有點類似。

服務網格如果站在更抽象的層次來看是什麽樣子？把服務治理相關的東西抽象來看的話，服務網格也算是一種基礎設施，它和具體的業務無關。不管是 PaaS 的發展，還是服務網格的發展，都是將與業務無關的內容的共同點提取出來，然後形成獨立的一套平臺或者方案。另外，服務網格之間要形成可靠傳遞，剛才提到的重試等功能都應該具備。

服務網格是輕量級的網絡代理，不能太重，不能喧兵奪主，服務才是整個系統中最重要的東西，而這些基礎設施並不應該取代服務最重要的價值地位。

更關鍵的一點是要對應用程序透明。對於服務而言是看不到 Sidecar、看不到代理的，服務如果要發消息出去，它知道是發給這個代理的，那對於我們的業務來說同樣也是一種汙染。服務網格最終不再強調代理作為單獨的組件，不再孤立的來看代理，而是從全局的角度來看待代理所形成的網絡。

1、服務網格定義

服務網格的定義是 Willian Morgan 提出來的，他是最早做服務網格的人。如圖，文字加粗的是服務網格一些關鍵技術點。右邊圖是最新發展的服務網格，在最上層還會加一個控制面板，通過控制面板來管理這些代理，這些代理是需要被管理的。如果我們的運維環境沒有控制面板，可能就沒辦法運維了。

2、服務網格的基本構成

服務網格必須要具備數據面板和控制面板，如果新開發一個服務網格只有數據面板，它肯定不是一個完整的服務網格。

數據面板是用來接收系統中的每一個包或者請求，提供服務發現、健康檢查等服務治理相關的，都是由數據面板來完成。數據面板的一些典型代表有 Linked、Envoy、和 Nginx 公司開發的 Nginmesh，以及硬件服務的代理廠商F5開發的 Aspen Mesh。目前主要的、成熟的是 Linked 和 Envoy，這兩者都在生產環境上面真實部署過，實戰過。而且Linked的采用會更廣泛一些，因為它出現的時間最早。

對於控制面板來說，是為了在網格中運營的數據面板提供策略和配置，負責一些管理工作，它不會接收系統中的任何包或者請求。這裏的包和請求應該是業務相關的包和請求，和具體的業務是完全沒關系的。本來做微服務應該做去中心化的事情，但是又有一個控制點在那裏，要強調的是那個控制點和具體的業務沒什麽關系。控制面板的典型代表，包括 Istio、Conduit、Nleson、SmartStack，目前最新的是 Istio 和 Conduit。

3、數據面板對比

左邊是 Linked（Scala編寫），右邊是 Envoy（C++編寫），它們最大的區別就是實現語言的區別。同時，Linkerd 和 Envoy 都是在生產環境已經驗證過的兩個系統，功能上都沒問題，都比較強大，它們唯一的區別就是對於硬件資源的要求，Linked 是非常高的，它可能就會造成喧兵奪主的感覺，所以目前 Envoy 在這塊是比較火的，Envoy 是由C++開發的。

4

控制面板對比

兩個最新的控制面板，一個是 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架構

一句話定義 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。

關註數人雲公眾號，後臺回復“127”即可獲取本次演講PPT。

從架構到組件，深挖istio如何連接、管理和保護微服務2.0？