導讀：本文簡單介紹了Service Mesh出現的基本理念，對其關鍵組件做了對比分析。同時也對istio這一Service Mesh關鍵組件做了架構分析。

王啟軍，目前就職于華為公司架構部，負責華為公司的Cloud Native、微服務架構推進落地，前后參與了華為手機祥云4.0、物聯網IoT 2.0的架構設計。曾任知名電商平臺架構師，主導電商平臺架構設計，包括訂單、支付、價格、庫存、物流等。曾就職于搜狐，負責手機微博的研發。十余年的技術歷練，也曾作為技術負責人帶領過近百人的團隊。公眾號“奔跑中的蝸?！钡淖髡?。

1.1?Service Mesh

---

1.1.1?什么是Service Mesh

Service Mesh是最近才興起的一個名詞，最早在2016年9月29日由開發Linkerd的Buoyant公司首次提出[1]。2016年10月，Alex Leong開始在Buoyant公司的官方博客中連載一系列關于“A Service Mesh for Kubernetes”的文章。隨著2017年Linkerd加入CNCF，Service Mesh開始大規模出現在各個技術論壇。Service Mesh在國內被翻譯為“服務嚙合層”或“服務網格”。那到底什么是Service Mesh呢？目前比較公認的是Buoyant的CEO?William?Morgan在博客中給出的定義[2]，具體描述如下。

Service Mesh是用于處理服務到服務通信的專用基礎架構層。Cloud Native有著復雜的服務拓撲，它負責可靠的傳遞請求。實際上，Service Mesh通常作為一組輕量級網絡代理實現，這些代理與應用程序代碼部署在一起，應用程序無感知。

隨著Cloud Native的崛起，Service Mesh逐步發展為一個獨立的基礎設施層。在Cloud Native架構下，單個應用程序可能由數百個服務組成；每個服務可能有數千個實例；并且這些實例中的每一個實例都可能處于不斷變化的狀態，因為它們是由諸如Kubernetes之類的資源調度系統動態調度的。這個世界中的服務通信不僅非常復雜，而且是運行時行為的普遍和基本部分，管理它對于確保端到端的性能和可靠性至關重要。

Azure的云設計模式庫中，也描述了類似的模式，名為Sidecar[3]，這個概念很形象。就是我們以前在戰爭片中看到的那種挎斗車，如圖8-2所示。

圖82?現實中的Sidecar[4]

在模式庫中，Sidecar被這樣描述：

• 將應用程序的組件部署到單獨的進程或容器中以提供隔離和封裝。這種模式還可以使應用程序由異構組件和技術組成。

• 這種模式被命名為Sidecar，因為它類似于連接到摩托車的邊車。在該模式中，輔助車被附加到父應用程序并為應用程序提供支持功能。邊車也與父應用程序共享相同的生命周期，與父進程一起被創建和退出。

簡單來說，Service Mesh幫助應用程序在海量服務、復雜的架構和網絡中建立穩定的通信機制，業務所有的流量都轉發到Service Mesh的代理服務中，不僅如此，Service Mesh還承擔了微服務框架所有的功能，包括服務注冊發現、負載均衡、熔斷限流、認證鑒權、緩存加速等能力。不同的是，Service Mesh強調的是通過獨立的進程代理的方式，除此之外，還承擔了上報日志、監控的責任。Service Mesh架構，如圖8-3所示。

圖83?Service Mesh架構

?

1.1.2?為什么需要Service Mesh

Service Mesh的出現是由微服務架構推動的，原本一個應用，被拆分成幾百個甚至幾萬個應用，服務治理面臨這巨大的挑戰。這個時候，微服務框架出現，例如，Finagle、Dubbo、Spring Cloud、Netflix OSS等。這些框架都是基于客戶端負載均衡、直連的方式，此方案的優勢是性能高、應用性好，如Dubbo，如果你使用Java語言，可以直接引入JAR包，通過簡單的配置，就可以實現微服務之間的通信。

歸根結底，在微服務架構中，我們要解決的問題是讓開發人員感覺不到微服務之間的通信。當服務數量越來越多，升級微服務框架變得越來越復雜的時候，你不可能要求微服務框架一直不變，而且是沒有bug的。在技術更新速度如此之快的年代，就更不可能了。因此，微服務框架的部分功能開始逐步向服務端移動，希望客戶端可以盡量“薄”，但是客戶端不可能無限制的“薄”，剩余部分仍然比較“厚”。

因為使用客戶端更像一種交付的模式，不容易變更，控制力較差，而Service Mesh則從業務進程集成客戶端的方式，演進為獨立進程的方式，也就是說，原本的客戶端變成了一個獨立進程。對這個獨立進程升級、運維要比綁在一起強得多。

微服務架構更強調去中心化、獨立自治、跨語言，但是通常微服務框架限制了這一點，不可能為每種語言都實現一個框架，要么都用一種語言，要么實現多種語言的框架。而Service Mesh通過獨立進程的方式進行了隔離，可以低成本實現跨語言。

隨著Docker及Kubernetes的崛起，微服務的部署模式開始發生轉變，越來越趨向于輕量級，越來越強調隔離自治。每個服務獨立占用一個容器，將服務、依賴包、操作系統、監控運維所需的代理打包成一個鏡像。這種模式促成了Service Mesh的發展，讓Service Mesh實現起來更容易。否則開發人員需要額外維護Service Mesh進程，就非常麻煩了。

?

1.1.3?Service Mesh的現狀

目前Service?Mesh的框架如雨后春筍般快速涌現，以下幾個框架是目前為止被提到次數最多的。

Linkerd

2016年1月15日，Twitter前基礎設施工程師William Morgan和Oliver Gould組建了一個名為Buoyant的公司，同時在GitHub上發布了Linkerd?0.0.7版本。它由Scala實現，業界第一個Service Mesh項目誕生。2016年下半年，Linkerd陸續發布了0.8和0.9版本，宣布支持HTTP/2和gRPC。2017年1月23日，Linkerd加入CNCF。2017年4月25日，Linkerd發布了1.0版本。

Linkerd在生產環境得到了大規模使用，但是隨著Istio的誕生，Linkerd開始走下坡路。由于Istio背后有強大的Google和IBM的支持，社區非?；钴S，雖然到目前為止還沒有大規模使用，但是業界已將Istio列為第二代Service Mesh。2017年7月11日，Linkerd迫于壓力發布版本1.1.1，宣布和Istio項目集成，但是Linkerd在Istio中替代Envoy的難度非常大，前景并不是特別樂觀。

Envoy

2016年9月13日，Lyft的Matt Klein宣布Envoy在GitHub開源，發布1.0.0版本。Envoy由C++實現，性能和資源消耗上非常出色。和Linkerd相比，Envoy發展得更平穩，被Istio收編之后，Envoy專注于數據平面。2017年9月14日，Envoy加入CNCF，成為CNCF繼Linkerd之后的第二個Service Mesh項目。目前，Envoy已用于生產系統中，據Lyft介紹：“Envoy在Lyft上可以管理一百多個服務，跨域上萬臺虛擬機，每秒可處理近兩百萬次請求?！?

nginMesh

2017年9月，在波特蘭舉行的nginx.conf大會上，Nginx宣布了nginMesh在GitHub上發布了0.1.6版本。nginMesh的定位是作為Istio的服務代理，也就是專注于數據平面，替代Envoy，和Linkerd與Istio集成的思路一致。nginMesh的發展一直比較緩慢，目前它還沒有應用到生產環境中。

Conduit

由于Buoyant在Linkerd上受到Istio壓制，2017年12月5日，Buoyant在KubeConf上發布了Conduit 0.1.0版本，作為Istio的競爭產品。Conduit的架構幾乎和Istio一樣，也分成了數據平面和控制平面，為了性能和資源占用方面的優勢，它直接采用Rust語言開發。Conduit也被稱為第二代Service Mesh。

Istio

2017年5月24日，Istio?0.1版本發布，目前已經到了0.7版本。Istio背后是強大的Google和IBM，所以Istio自誕生之日起就備受矚目。Istio的初期版本只支持Kubernetes平臺，從0.3版開始支持非Kubernetes平臺，可以獨立運行。

雖然它的架構思想被很多人認同，功能也很多，但是Istio的問題仍然較多，可用性較差，幾乎沒有生產級的案例。盡管如此，Istio被認為是Service Mesh的未來，很多公司都在跟隨這個框架。

實際上，如果在一個小公司，Service Mesh的優勢體現的并不是十分明顯。例如小公司很少會考慮采用多語言，因為多一種語言就意味著要分散額外的精力進行維護，所以到目前為止，大多數公司在后端只使用一兩種語言。另外，微服務框架相對來說比較穩定，就如同Spring Framework一樣，不會輕易進行不兼容的升級，只要保持好節奏，問題不會太多。因此，像Netflix、阿里這樣的公司，基本上還是沿用類似Spring Cloud的模式。

此外，Service Mesh降低開發人員的門檻也并沒有那么明顯，因為完全不考慮是不可能的，Service Mesh在沒有理解業務的情況下，是不能私自做決定的。例如A服務調用B服務的超時時間，設置多少合理呢？還是需要開發人員根據業務進行配置的。

另外，Service Mesh對業務開發人員友好，但是基礎設施層的研發會更復雜，需要依賴更多的服務、組件，否則將帶來極大的架構、運維復雜度。對于很多公司來說，門檻稍高，且需要投入成本。

因此，對于絕大多數公司來說，Service Mesh并不具備壓倒性的優勢，在沒有成熟起來以前，大多都是觀望狀態。

?

1.1.4?Istio架構分析

Istio架構如圖8-4所示。Istio從邏輯上可以分為數據平面（Data Plane）和控制平面（Control Plane）。如果用服務化框架類比Istio，那么控制平面可以認為是注冊中心及管理配置面板，數據平面可以認為是服務化框架依賴的組件獨立而成的一個進程，數據平面代理業務服務的注冊發現、負載均衡、容錯等能力。

圖84?Istio架構[5]

?

數據平面也就是代理，使用Envoy實現，獨立進程，和業務服務部署在一起，主要是管理微服務之間的網絡通信及執行控制平面下發的指令。Envoy支持的通信協議包括：HTTP/1.1、HTTP/2、gRPC、TCP等，它支持TLS。

控制平面負責管理和配置這些代理，并動態執行策略。主要包括三個部分，分別是Pilot、Mixer、Istio-Auth，都是有Go語言開發。

Pilot主要的責任就是管理Envoy實例的生命周期。Pilot通過Envoy API接入Envoy實例，主要是服務發現以及流量控制。運維人員可以通過Rules API自定義流量管理規則，轉化為配置信息下發到Envoy，Envoy實例按照自定義的規則執行流控。從理論上說，Pilot抽象了模型，通過適配器可以適配Kubernetes、Mesos、CloudFoundry等平臺，但是目前只支持Kubernetes。Pilot架構如圖8-5所示。

圖85?Pilot架構[6]

?

利用Pilot可以輕松實現流量控制，如限流、灰度發布、熔斷等能力。圖8-6中的配置代表了Pilot分發到v1版本75%的流量，分發到v2版本25%的流量。

圖86?流量分發

?

此外，利用Pilot還可以輕松的注入故障。圖8-7中的示例就表示選擇“reviews”服務的“v1”版本的10％的請求中引入5秒的延遲。

圖87?示例

?

Mixer負責通過策略進行訪問控制，并從Envoy代理收集數據，代理提取請求級屬性，發送到Mixer進行決策。要理解Mixer，首先需要理解Istio中屬性的意義。屬性是具有名稱和類型的元數據片段，用來描述流量和這些流量所在的上下文環境。請求的路徑、大小、時間、源IP地址及目標服務如下所示。

request.path:?blog/article

request.size: 200

request.time: 13:34:56.789 04/17/2018

source.ip: 10.10.0.1

target.service:?article

Mixer提供如下三個核心功能。

• 校驗。在響應之前，先驗證調用者的身份、是否在服務的白名單、是否通過ACL檢查等。

• 配額。例如訪問頻率控制。當服務消費者對有限的資源進行爭搶時，配額就成了一種有效的資源管理工具，它為服務之間的資源搶占提供相對的公平。

• 報告。使服務通過Envoy上報日志和監控。

Istio Auth的目標是在不修改業務服務代碼的前提下，提升業務服務之間通信的安全性。Istio Auth利用secret volume mount，從Istio CA向Kubernetes容器傳遞keys/certs。由于Envoy代理一切流量，因此Envoy客戶端和Envoy服務端之間使用TLS非常簡單。Istio Auth為我們提供的能力如下。

• 每個服務都可以被設定身份，代表其角色，以實現跨集群和云的互通性。

• 可以加密服務間通信和終端用戶到服務的通信。

• 提供密鑰管理系統來自動執行密鑰和證書的生成、分發、輪換和撤銷。

在很多場景下，微服務通常不對外網開放訪問權限，只有邊緣服務才會通過API Gateway進行開放，而加密往往意味著性能的降低，因此通常會選擇不加密，除非部署的環境比較特殊。

?

文中注釋：

[1]?2016年1月15日，離開Twitter的基礎設施工程師William Morgan和Oliver Gould，在GitHub上發布了Linkerd?0.0.7版本，他們同時組建了一個創業公司Buoyant，業界第一個Service Mesh項目在這個公司誕生。

[2]?來自https://blog.buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/

[3] 來自https://docs.microsoft.com/en-us/azure/architecture/patterns/sidecar

[4] 來自圖片來自http://www.atobo.com.cn/Products/Detailed/5618736.html

[5]?圖片來自https://istio.io/docs/concepts/what-is-istio/overview/

[6]?圖片來自https://istio.io/docs/concepts/traffic-management/pilot/

?

本文節選自電子工業出版社《持續演進的Cloud Native：云原生架構下微服務最佳實踐》第 8 章，由電子工業出版社博文視點授權?；谄目紤]，部分內容進行了簡化，想了解本書全部詳細內容，可以在各大書店購買。

總結

以上是生活随笔為你收集整理的Cloud Native未来值得关注的方向：Service Mesh简介的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。