服務網格：微服務進入2.0時代

Emac發表於2019-03-02

微服務自2014年3月由Martin Fowler首次提出以來，在Spring Cloud、Dubbo等各類微服務框架的幫助下，以燎原之勢席捲了整個IT技術界，成為了最主流的分散式應用解決方案。但仍然還有很多問題沒有得到根本性的解決，比如技術門檻高、多語言支援不足、程式碼侵入性強等。如何應對這些挑戰成為了下一代微服務首要回答的問題。直到服務網格（Service Mesh）被提出，這一切都有了答案。

1 微服務之殤

時光回到2017年初，那時所有主流的微服務框架，不管是類庫性質的Finagle、Hystrix，還是框架性質的Spring Cloud、Dubbo，本質上都歸於應用內解決方案，都存在以下三個問題：

技術門檻高：隨著微服務實施水平的不斷深化，除了基礎的服務發現、配置中心和授權管理之外，團隊將不可避免的在服務治理層面面臨各類新的挑戰，包括但不限於分散式跟蹤、熔斷降級、灰度釋出、故障切換等，這對團隊提出了非常高的技術要求。

圖片出處：Service Mesh：下一代微服務

多語言支援不足：對於稍具規模的團隊，尤其在高速成長的網際網路創業公司，多語言的技術棧是常態，跨語言的服務呼叫也是常態，但目前開源社群上並沒有一套統一的、跨語言的微服務技術棧。
程式碼侵入性強：主流的微服務框架（比如Spring Cloud、Dubbo）或多或少都對業務程式碼有一定的侵入性，框架替換成本高，導致業務團隊配合意願低，微服務落地困難。

這些問題加起來導致的結果就是，在實施微服務的過程中，小團隊Hold不住，大公司推不動。

2 另闢蹊徑

如何解決上述三個問題呢？最容易想到的是代理模式，在LB層（比如Nginx、Apache HTTP Server）處理所有的服務呼叫，以及部分服務治理問題（比如分散式跟蹤、熔斷降級）。但這個方案有兩個顯著的缺點，第一，中心化架構，代理端自身的效能和可用性將是整個系統的瓶頸；第二，運維複雜度高，業務團隊笑了，運維團隊哭了。

難道這就是桃園嗎？

服務網格（Service Mesh）應運而生！自2016年9月Linkerd第一次公開使用之後，伴隨著Linkerd、Envoy、Istio、NGINX Application Platform、Conduit等新框架如雨後春筍般不斷湧現，在微服務之後，服務網格和它的邊車（Sidecar）模式引領了IT技術界2017一整年的走向。

3 服務網格

3.1 元定義

首先，我們來看一下服務網格的提出者William Morgan是如何描述它的。

A service mesh is a dedicated infrastructure layer for handling service-to-service communication. Consists of a control plane and data plane (service proxies act as “mesh”). – William Morgan, What`s a Service Mesh? And Why Do I Need One?

上面這段話非常清晰的指明瞭服務網格的職責，即處理服務間通訊，這正是服務治理的核心所在。而a dedicated infrastructure layer這幾個單詞將服務網格和之前所有的微服務框架（framework）劃清了界限，也即服務網格獨立於具體的服務而存在，這從根本上解決了前文提到的老的微服務框架在多語言支援和程式碼侵入方面存在的問題。並且，由於服務網格的獨立性，業務團隊不再需要操心服務治理相關的複雜度，全權交給服務網格處理即可。

那你可能會問，這不跟之前提到的代理模式差不多嗎？區別在於服務網格獨創的邊車模式。針對每一個服務例項，服務網格都會在同一主機上一對一併行部署一個邊車程式，接管該服務例項所有對外的網路通訊（參見下圖）。這樣就去除了代理模式下中心化架構的瓶頸。同時，藉助於良好的框架封裝，運維成本也可以得到有效的控制。

圖片出處：What`s a Service Mesh? And Why Do I Need One?

3.2 演化史

追本溯源，服務網格從無到有可分為三個演化階段（參見下圖）。第一個階段，每個服務各顯神通，自行處理對外通訊。第二個階段，所有服務使用統一的類庫進行通訊。第三個階段，服務不再關心通訊細節，統統交給邊車程式，就像在TCP/IP協議中，應用層只需把要傳輸的內容告訴TCP層，由TCP層負責將所有內容原封不動的送達目的端，整個過程中應用層並不需要關心實際傳輸過程中的任何細節。

圖片出處：Pattern: Service Mesh

3.3 時間線

最後，再來回看一下服務網格年輕的歷史。雖然服務網格的正式提出是在2016年9月，但其實早在2013年，Airbnb就提出了類似的想法——SmartStack，只不過SmartStack侷限於服務發現，並沒有引起太多關注，類似的還有Netflix的Prana和唯品會的OSP Local Proxy。2016年服務網格提出之後，以Linkerd和Envoy為代表的框架開始嶄露頭角，並於2017年先後加入CNCF基金（Cloud Native Computing Foundation），最終促使了一代新貴Istio的誕生。2018年，Istio將釋出1.0版本，這也許意味著微服務開始進入2.0時代。