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

時間 2019-11-17

標籤服務網格微服進入 2.0時简体版

原文原文鏈接

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

1 微服務之殤

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

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

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

多語言支持不足：對於稍具規模的團隊，尤爲在高速成長的互聯網創業公司，多語言的技術棧是常態，跨語言的服務調用也是常態，但目前開源社區上並無一套統一的、跨語言的微服務技術棧。
代碼侵入性強：主流的微服務框架（好比Spring Cloud、Dubbo）或多或少都對業務代碼有必定的侵入性，框架替換成本高，致使業務團隊配合意願低，微服務落地困難。

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

2 另闢蹊徑

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

難道這就是桃園嗎？apache

服務網格（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時代。