淺談服務治理、微服務與Service Mesh（三） Service Mesh與Serverless
作為本系列文章的第三篇（前兩篇請戳：《 ofollow,noindex" target="_blank">淺談服務治理、微服務與Service Mesh（一）Dubbo的前世今生 》、《 淺談服務治理、微服務與Service Mesh（二） Spring Cloud從入門到精通到放棄 》），本文主要為大家介紹一下當前非常火熱的Service Mesh概念，最後也會簡單介紹一下目前同樣熱門的Serverless概念。Service Mesh目前比較多的翻譯為“服務網格”，也有翻譯為“服務齧合”。很多人將之稱為下一代微服務，或直接稱之為微服務2.0。前兩篇文章中介紹的Dubbo和Spring Cloud實際上距離真正意義上的微服務還有一定的距離，本文將帶你瞭解在微服務2.0時代，Service Mesh方式是如何實現下一代微服務標準的，並介紹當前比較常見的幾種Service Mesh實現方案。
微服務1.0時代
Dubbo本質上只能算是一個服務治理框架，而不能算是一個微服務框架。雖然在未來的Dubbo 3.0中會提供對Spring Cloud，以及對Service Mesh的支援，但是單憑Dubbo仍然是無法搭建一個完整的微服務體系結構。
Spring Cloud則是通過整合眾多的元件的形式實現了相對完整的微服務技術棧，但是Spring Cloud的實現方式程式碼侵入性較強，而且只支援Java語言，無法支援其他語言開發的系統。Spring Cloud全家桶包括的內容較多，學習成本也相對較高，對老系統而言，框架升級或者替換的成本較高，導致一些開發團隊不願意擔負技術和時間上的風險與成本，使得微服務方案在落地時遇到了諸多的困難。
總結一下，微服務1.0時代的主要問題主要包括如下三方面：
- 技術門檻高：開發團隊在實施微服務的過程中，除了基礎的服務發現、配置中心和鑑權管理之外，團隊在服務治理層面面臨了諸多的挑戰，包括負載均衡、熔斷降級、灰度釋出、故障切換、分散式跟蹤等，這對開發團隊提出了非常高的技術要求。
- 多語言支援不足：對於網際網路公司，尤其是快速發展的網際網路創業公司，多語言的技術棧、跨語言的服務呼叫也是常態，但目前開源社群上並沒有一套統一的、跨語言的微服務技術棧，而跨語言呼叫恰恰是微服務概念誕生之初的要實現的一個重要特性之一。
- 程式碼侵入性強：Spring Cloud、Dubbo等主流的微服務框架都對業務程式碼有一定的侵入性，技術升級替換成本高，導致開發團隊配合意願低，微服務落地困難。
微服務2.0時代
為了解決微服務1.0時代的諸多問題，Service Mesh概念開始走入了開發者的視線中。
在介紹Service Mesh概念之前，我們先來了解一下Sidecar。Sidecar是以第一次世界大戰時活躍在戰場上的軍用邊斗車命名（也是我們在抗日神劇中最常見的道具之一）。Sidecar是Service Mesh中的重要組成部分，Sidecar在軟體系統架構中特指邊斗車模式，這個模式的精髓在於實現了資料面（業務邏輯）和控制面的解耦。
在Service Mesh架構中，給每一個微服務例項部署一個Sidecar Proxy。該Sidecar Proxy負責接管對應服務的入流量和出流量，並將微服務架構中的服務訂閱、服務發現、熔斷、限流、降級、分散式跟蹤等功能從服務中抽離到該Proxy中。
Sidecar以一個獨立的程序啟動，可以每臺宿主機共用同一個Sidecar程序，也可以每個應用獨佔一個Sidecar程序。所有的服務治理功能，都由Sidecar接管，應用的對外訪問僅需要訪問Sidecar即可。當該Sidecar在微服務中大量部署時，這些Sidecar節點自然就形成了一個服務網格。
微服務的概念在2014年3月由Martin Fowler首次提出，而Service Mesh的概念則是在2016年左右提出，Service Mesh至今也經歷了第二代的發展。
第一代Service Mesh的代表為Linkerd和Envoy。Linkerd基於Twitter的Fingle，使用Scala編寫，是業界第一個開源的Service Mesh方案，在長期的實際生產環境中獲得驗證。Envoy底層基於C++，效能上優於使用Scala的Linkrd。同時，Envoy社群成熟度較高，商用穩定版本面世時間也較長。這兩個開源實現都是以Sidecar為核心，絕大部分關注點都是如何做好Proxy，並完成一些通用控制面的功能。但是當你在容器中大量部署Sidecar以後，如何管理和控制這些Sidecar本身就是一個不小的挑戰。
第二代Service Mesh主要改進集中在更加強大的控制面功能（與之對應的Sidecar Proxy被稱之為資料面），典型代表有Istio和Conduit。Istio是Google、IBM和Lyft合作的開源專案，是目前最主流的Service Mesh方案，也是事實上的第二代Service Mesh標準。在Istio中，直接把Envoy作為Sidecar。除了Sidecar，Istio中的控制面元件都是使用Go語言編寫。
Istio簡介
根據Istio官方文件的介紹，Istio在服務網路中主要提供了以下關鍵功能：
- 流量管理：控制服務之間的流量和API呼叫的流向，使得呼叫更可靠，並使網路在惡劣情況下更加健壯。
- 可觀察性：瞭解服務之間的依賴關係，以及它們之間流量的本質和流向，從而提供快速識別問題的能力。
- 策略執行：將組織策略應用於服務之間的互動，確保訪問策略得以執行，資源在消費者之間良好分配。策略的更改是通過配置網格而不是修改應用程式程式碼。
- 服務身份和安全：為網格中的服務提供可驗證身份，並提供保護服務流量的能力，使其可以在不同可信度的網路上流轉。
- 平臺支援：Istio旨在在各種環境中執行，包括跨雲、Kubernetes、Mesos等。最初專注於Kubernetes，但很快將支援其他環境。
- 整合和定製：策略執行元件可以擴充套件和定製，以便與現有的ACL、日誌、監控、配額、稽核等解決方案整合。
Istio針對可擴充套件性進行了設計，以滿足不同的部署需要。這些功能極大的減少了應用程式程式碼、底層平臺和策略之間的耦合，使得微服務更加容易實現。
下圖為Istio的架構設計圖，主要包括了Envoy、Pilot、Mixer和Istio-Auth等。
- Envoy：扮演Sidecar的功能，協調服務網格中所有服務的出入站流量，並提供服務發現、負載均衡、限流熔斷等能力，還可以收集與流量相關的效能指標。
- Pilot：負責部署在Service Mesh中的Envoy例項的生命週期管理。本質上是負責流量管理和控制，將流量和基礎設施擴充套件解耦，這是Istio的核心。可以把Pilot看做是管理Sidecar的Sidecar, 但是這個特殊的Sidacar並不承載任何業務流量。Pilot讓運維人員通過Pilot指定它們希望流量遵循什麼規則，而不是哪些特定的pod/VM應該接收流量。有了Pilot這個元件，我們可以非常容易的實現 A/B 測試和金絲雀Canary測試。
- Mixer：Mixer在應用程式程式碼和基礎架構後端之間提供通用中介層。它的設計將策略決策移出應用層，用運維人員能夠控制的配置取而代之。應用程式程式碼不再將應用程式程式碼與特定後端整合在一起，而是與Mixer進行相當簡單的整合，然後Mixer負責與後端系統連線。Mixer可以認為是其他後端基礎設施（如資料庫、監控、日誌、配額等）的Sidecar Proxy。
- Istio-Auth：提供強大的服務間認證和終端使用者認證，使用互動TLS，內建身份和證書管理。可以升級服務網格中的未加密流量，併為運維人員提供基於服務身份而不是網路控制來執行策略的能力。Istio的未來版本將增加細粒度的訪問控制和審計，以使用各種訪問控制機制（包括基於屬性和角色的訪問控制以及授權鉤子）來控制和監視訪問服務、API或資源的訪問者。
Istio的設計理念先進，功能也比較強大，加之Google、IBM的影響力讓Istio迅速傳播，讓廣大開發者認識到了Istio專案在Service Mesh領域的重要性。但是Istio目前版本也存在了一些不足：
- 目前的Istio大部分能力與Kubernetes是強關聯的。而我們在構建微服務的時候往往是希望服務層與容器層是解耦的，服務層在設計上需要能夠對接多種容器層平臺。
- Istio至今未有穩定版本，截至本文編寫時為止，Istio的最新版本為0.8版本，預計在2018年內會發布1.0版本。
Conduit簡介
我們再來看一下Conduit的實現，下圖是Conduit的架構設計圖，其中重點由Conduit Data Plane和Conduit Control Plane兩部分組成：
Conduit各方面的設計理念與Istio非常類似，作者使用Rust語言重新編寫了Sidecar, 叫做Conduit Data Plane, 控制面則由Go語言編寫的Conduit Control Plane接管。從Conduit的架構看，作者號稱Conduit吸取了很多Linkerd的教訓，比Linkerd更快、更輕、更簡單，控制面功能更強。與Istio比較，Conduit的架構一方面比較簡單，另一方面對於要解決的問題足夠聚焦。
Serverless簡介
Serverless被翻譯為“無伺服器架構”，這個概念在2012年時便已經存在，比微服務和Service Mesh的概念出現都要早，但是直到微服務概念大紅大紫之後，Serverless才重新又被人們所關注。
Serverless（無伺服器架構）並不意味著沒有任何伺服器去執行程式碼，Serverless是無需管理伺服器，只需要關注程式碼，而提供者將處理其餘部分工作。“無伺服器架構”也可以指部分伺服器端邏輯依然由應用程式開發者來編寫的應用程式，但與傳統架構的不同之處在於，這些邏輯執行在完全由第三方管理，由事件觸發的無狀態（Stateless）暫存於計算容器內。
對於開發者來說，Serverless架構可以將其伺服器端應用程式分解成多個執行不同任務的函式，整個應用分為幾個獨立、鬆散耦合的元件，這些元件可以在任何規模上執行。
下圖為一種常見的Serverless架構圖，所有的服務都以FaaS（函式即服務）的方式對外進行提供。在語言和環境方面，FaaS 函式就是常規的應用程式，例如使用JavaScript、Python以及 Java等語言實現。
Serverless架構優勢
- 縮短交付時間：Serverless架構允許開發人員在極短時間內（幾小時、幾天）交付新的應用程式，而不是像以前一樣需要幾個星期或幾個月。在新的應用程式中，依賴於第三方API提供服務的例子很多，如認證(OAuth)、社交、地圖、人工智慧等。
- 增強可伸縮性：所有人都希望自己開發的應用能夠快速獲取大量的新增使用者，但是當活躍使用者快速增長的時候，伺服器的壓力也會激增。使用Serverless架構的體系不再有上述擔憂，可以及時、靈活進行擴充套件來應對快速增長的活躍使用者帶來的訪問壓力。
- 降低成本：Serverless架構模式可以降低計算能力和人力資源方面的成本，如果不需要伺服器，就不用花費時間重新造輪子、風險監測、影象處理，以及基礎設施管理，操作成本會直線下降。
- 改善使用者體驗：使用者通常不太關心基礎設施，而更注重於功能和使用者體驗。Serverless架構允許團隊將資源集中在使用者體驗上。
- 減少延遲及優化地理位置資訊：應用規模能力取決於三個方面：使用者數量、所在位置及網路延遲。當應用要面向全國甚至全球使用者的時候，通常會產生較高的延遲，從而降低使用者體驗。在Serverless架構下，供應商在每個使用者附近都有節點，大幅度降低了訪問延遲，因此所有使用者的體驗都可以得到提升。
總結
對於大規模部署微服務，內部服務異構程度高的場景，使用Service Mesh方案是一個不錯的選擇。Service Mesh實現了業務邏輯和控制的解耦，但是也帶來了額外的開銷，由於網路中多了一跳，增加了效能的損耗和訪問的延遲。同時，由於每個服務都需要部署Sidecar, 這也會使本來就具有一定複雜度的分散式系統變得更加複雜。尤其是在實施初期，對Service Mesh的管理和運維會是一個棘手的問題。因此，當我們選擇使用Service Mesh架構的時候，需要對具體的Service Mesh實現方案（例如：Istio）做好充分的技術準備和經驗積累工作，方能確保方案的順利實施。
在微服務與容器技術火熱之後，Serverless（無伺服器架構）成為新的熱點，無伺服器雲函式可以讓使用者無需關心伺服器的部署運營，只需開發最核心的業務邏輯，即可實現上線運營，具備分佈容災能力，可以依據負載自動擴縮容，並按照實際呼叫次數與時長計費。
使用Serverless架構可以免除所有運維性操作，開發人員可以更加專注於核心業務的開發，實現快速上線和迭代，把握業務發展的節奏。Serverless架構可以認為是對微服務和容器化的一種補充，為使用者提供了一種新的選擇，來應對複雜多變的需求，尤其適合快速發展的初創型公司。