2018年數人雲Meetup第一站，聯合vivo在深圳舉辦 Building Microservice 系列活動第一期。本次技術沙龍vivo、中興通訊、華為、數人雲共同派出技術大咖，為開發者們帶來有關微服務、容器化、配置中心、服務網格等領域的實戰與幹貨分享。
數人雲Meetup每月一期，歡迎大家來面基、學習。本文為中興通訊資深研發教練&系統架構師張晔分享的“微服務2.0：istio架構縱覽”現場演講實錄。
近幾年我一直從事于微服務系統的設計以及實作方面的工作，屬于微服務架構一線實踐者。之前做過一些單體系統的微服務改造，在微服務拆分、治理等方面都有一定的經驗。
本人比較特殊一點的經曆是既做過 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的關鍵特性:
1、智能路由和負載均衡。這裡的智能路由和負載均衡是屬于比較進階的，不是像傳統簡單的随機負載均衡，而是可以基于一些資料包内部的内容來進行負載均衡。
2、跨語言和平台的彈性。對于平台來說 Istio 是支援各種各樣的平台，并且能支援A/B測試，金絲雀釋出，并使用藍綠部署運維上的一些進階功能。
3、全面政策執行。Istio 有一個元件是專門負責保障政策能夠通過一個元件下發到具體的資料面闆。
4、遙測和上報。即具體的測量以及流量的監控等。
這個就是 Istio 整個的系統架構，如圖，上面是控制台，下面是很多資料 Envoy，很多個代理，形成一個資料面闆。後面我們會對單個進行詳細介紹。
這是在 K8S 下面 Istio 部署的示意圖，可以看到它們之間最關鍵的東西是所有服務群組件都會有一個代理，這代理是必備的，包括控制台都會有代理。沒有畫的有兩個東西，一個是 Ingress，一個是初始化器，初始化器主要是做代理注入。它們之間互相的互動都是通過加密，由TLS協定來完成。
五、Istio元件
1
資料面闆Envoy
介紹一下 Istio 的核心元件，首先是 Istio 的資料面闆 Envoy。
Envoy 的目标是透明地處理叢集内服務間、從服務到外部服務之間的出入口流量。Envoy 是用C++編寫的，高并行、非阻塞。并且是可裝卸的L3/4過濾器，以及L7的過濾器，最終會形成一個過濾鍊來對流量進行管理或者控制，Envoy 是通過 xDS 動态配置來進行接口提供。
下面就是一些固有的功能，服務發現、健康檢查。Envoy 的健康檢查也做的顆粒度比較細，包含主動健康檢查和被動健康檢查。主動健康檢查像正常的健康檢查，主動地發一個健康檢查的接口調用請求，查詢一下。被動的是通過對其他服務的一些請求，從一些傳回值進行健康檢查。當然還包含進階的負載均衡，監控、跟蹤這些功能。
Envoy最關鍵的三個點：
- 高性能。一直在強調的是資料面闆必須要高性能，因為是要和業務服務部署在一起的。
- 可擴充。
- 可配置。具有動态配置的特性。
Envoy 是如何做到高性能的？
Envoy 的線程模型分為三類線程，如果做過C++開發，這種單程序多線程的架構是很常見的。Envoy 分為主線程、工作線程、檔案重新整理線程，其中主線程就是負責工作線程和檔案重新整理線程的管理和排程。而工作線程主要負責監聽、過濾和轉發，工作線程裡面會包含一個監聽器，如果收到一個請求之後會通過剛才所介紹的過濾鍊來進行資料過濾。前面兩個都是非阻塞的，唯一一個阻塞的是這種 IO 操作的，會不斷地把記憶體裡面一些緩存進行落盤。
服務網格所強調的另外一個功能，是動态配置不用重新開機，實際上是重新開機的，它會啟動一個新的程序，然後在這程序之上進行新的政策，還有一些初始化，這時候再請求監聽，之前那個程序的 socket 副本。當老的關閉連結以及退出之後，它才會接收新的，這時候就實作了對使用者沒有感覺的重新開機。
這就是它的 xDS，如圖，可以看到它的密度是非常細的，
- 終端發現服務（EDS），實際上就是服務的發現服務；
- 叢集發現服務（CDS）是為了發現叢集；
- 路由發現服務（RDS）是為了對路由進行一些處理；
- 監聽器（LDS）來動态地添加、更新、删除監聽器，包括過濾鍊的一些管理、維護。
- 另外還有剛才說到的健康檢查（HDS），
- 還有聚合（ADS）是對于監控名額進行聚合的接口；
- 另外一個密鑰發現（KDS）是和安全相關的。
首先，如果來了一個請求，會到剛才所說的工作線程裡面去，工作線程會有監聽器，收到之後進行一些處理，然後要往外發，這時會調用路由的發現功能，然後再找到相應的叢集，再通過這個叢集找到相應的服務，一層一層的往下面調用。
2
控制台Pilot
接下來介紹的是控制台的三大元件，第一個就是 Pilot。
Pilot 是運作時的代理配置，剛才所說的 xDS，就是用 Pilot 來進行調用，負責把相應的一些政策，失敗恢複的特性派發下去。Pilot 是負責管理所有的這些代理，代理和管理就通過 Pilot 來完成，是平台無關的一個拓撲模型。目前主要支援的是 K8S。
Pilot 是一層抽象的獨立于底層平台的模型，因為這裡有個代理，對于多平台或多樣性的管理架構，即擴充卡的架構。平台特定的擴充卡負責适當填充這些規範，要通過具體平台的擴充卡形成一些規範，和通用的模型結合，生成必須要往 Envoy 下發的資料，并且配置、推送都是由 Pilot 來完成的。
Pilot 的整個服務發現和負載均衡，如圖，Pilot 是Kubernetes DNS提供的域名進行通路，首先調用 Service B 的url，這時候 Envoy 會進行截獲并處理，處理完之後會找到相應的負載均衡的池子挑選一個進行流量下發。Pilot 目前支援的這種負載均衡的方法，規劃了很多種。但目前隻實作了三種，前兩種還是随機和輪循，多了一個最小請求的負載均衡算法。它能找到這些 Pilot 裡面哪個被調用的最少，然後進行調用。
Pilot 的一些規則配置，可以看到基本是負責規則的管理以及下發。
- 路由規則。
- 目的地政策。主要包含負載均衡的算法，以及對于負載均衡算法抽象的政策預演。
- 出站規則。
把這些規則分了三類，好處是對這三類都會生成一些模闆。
流量的拆分可以看到是基于标簽的流量拆分，這裡配置的如版本，環境，環境類型，它根據這個規則來進行流量的派發。比如說99%都發給之前版本，新版本先1%先測一下，類似于A/B測試。
另外一個比較進階的是基于内容，因為它是L7的這種過濾，可以基于内容來過濾，并且支援表達式，這種将iPhone的流量全部導到新的服務裡面去，并且有标簽，版本必須得是金絲雀版本。
3
混合器Mixer
Mixer 是在應用代碼和基礎架構之間提供一個中間層，來隔離 Enovy 和背景基礎設施，這裡的背景是指 Promethus，ELK 這些。
Mixer 有三個核心特性：
- 先決條件檢查。負責白名單以及 ACL檢測；
- 配額管理。負責這種使用頻率上的控制；
- 遙測報告。
總共分為兩類，在生成配置模闆的時候它是有兩類的，第一類就是負責檢查check，第二類就是負責報告reporter。
Mixer 是采用通用的插件模型以實作高擴充性，插件被稱為擴充卡。運維人員下發一些配置到這裡面，這些模闆又是由模闆開發人員進行開發的，Istio提供了很多通用性的模闆，上面簡單地改造一下就能做出一個模闆來。擴充卡也有很多種，各種背景、平台的都有。
Mixer 是抽象了不同後端的政策，遙測系統的細節，它就對這兩個東西進行了抽象，形成了一套抽象的東西。
剛才介紹過擴充卡，再來介紹一下處理器，它是配置好的擴充卡，由運維人員進行配置，之後形成最終的處理器，負責真正往背景發東西。
它封裝了與後端接口所需的邏輯，指定了配置規格，以及擴充卡。如果要在背景進行消息互動的話，所需要的操作參數在這裡也會定義。而右邊就是兩個模闆，第一個模闆是 Prometheus，它是一個處理器，下面是它的一些名額。另外一個是白名單檢查的模闆，提供URL，以及它請求的接口傳回值。
剛才介紹了整個通路是怎麼打通的，包括擴充卡和處理器都是為了幹這個事情，這個通路怎麼建立？接下來要介紹的是這個參數怎麼生成，它是請求屬性到一個模闆的映射結果。
Mixer 會收到 Envoy 發過來的很多屬性（請求），請求裡面包含的資料都稱之為屬性。通過它的模闆來生成相應的具體參數，這邊也是剛才兩個例子裡面對應的模闆。上面是度量名額采集用的，下面是白名單。
這裡有個遙測報告的示例，當收到一個請求之後會發生什麼。它會以屬性的形式，這邊有個 Zipk，就直接上報了，這是因為 Envoy 原生的就支援Zipk。Envoy 支援後端監控的東西，就是 Zipk，是以它可以直接發給它。其他的需要通過 Mixer 來進行轉發。
首先它收到這個屬性之後，會把這個屬性生成具體的執行個體。根據運維人員提供的配置，Mixer 将生成的資料分發到一組擴充卡，擴充卡要根據運維人員的配置來生成具體的資料，之後就可以把剛才所生成的執行個體往下發了。發到後端後可以進行進一步的分析和處理。
4
密鑰管理
最後要介紹的就是安全相關的，Certificate Authority 這塊，這是整個密鑰管理的示意圖，可以看到服務和 Envoy 是通過 TCP 進行互動的，但是Envoy 和 Envoy 之間是通過 MTIS 進行加密，是雙向的 TIS 加密。它的好處是，會在内部的每一個服務節點之間做加密，當然這是可選的，根據性能的需求來進行選擇。
密鑰管理分為四個步驟，這四步就是四個特性，第一，通過服務帳戶生成的密鑰和證書，然後再将密鑰和證書部署到 Envoy上，它還支援周期性的對這證書進行更新，另外還支援撤銷的功能。
這是它的兩種部署方式，一種 K8S 的部署方式，另外如果是虛拟機，它會單獨有一個節點代理，通過節點代理來發出簽名請求給CA，CA再生成密鑰和證書給代理，代理再來負責部署到 Envoy上。
具體的運作時它們都有各自的證書，開始進行雙向的 TIS，這時候會到名字資訊裡面去查詢，後端有沒有權限通路，如果有的話就往下，沒有就結束了。
第三步，如果收到一個用戶端的請求，會去 Mixer 裡面判斷一下，它是白名單上的一個判斷或者是不是黑名單上的一個判斷，會影響“握手”的成功與否。最終它們就形成了安全互動的通道。
謝謝大家，今天我們主要給大家介紹一下 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。