下一代微服務-ServiceMesh

一、簡介

系統服務化以後，服務間通訊須要關注什麼？

服務發現、負載均衡、路由、流控、通訊可靠性、彈性、安全、監控、日誌

API網關能夠集中式的管理這些功能，可是會出現單點故障，而且實現起來網關會變得愈來愈臃腫。 而且網關是一個集中式的處理

Service Mesh是網絡通訊基礎設施，能夠將網絡功能從代碼中剝離出來。 經過Service Mesh不用在服務代碼中實現用於可靠性通訊的模式或斷路，超時等控制。

Service Mesh是一個專門的軟件基礎設施層，和主進程獨立，經過（HTTP，GRPC）進行代理通訊，用於控制和監控微服務應用程序中服務到服務的內部通訊，讓服務到服務通訊變得快速，安全，可靠。

二、由來

微服務中的服務發現問題如何解決

一、傳統集中式代理

這是最簡單和傳統作法，在服務消費者和生產者之間，代理做爲獨立一層集中部署，由獨立團隊(通常是運維或框架)負責治理和運維。經常使用的集中式代理有硬件負載均衡器(如F5)，或者軟件負載均衡器(如Nginx)，F5(4層負載)+Nginx(7層負載)這種軟硬結合兩層代理也是業內常見作法，兼顧配置的靈活性(Nginx比F5易於配置)。

這種方式一般在DNS域名服務器的配合下實現服務發現，服務註冊(創建服務域名和IP地址之間的映射關係)通常由運維人員在代理上手工配置，服務消費方僅依賴服務域名，這個域名指向代理，由代理解析目標地址並作負載均衡和調用。

國外知名電商網站eBay，雖然體量巨大，但其內部的服務發現機制仍然是基於這種傳統的集中代理模式，國內公司如攜程，也是採用這種模式。

二、客戶端嵌入式代理

這是不少互聯網公司比較流行的一種作法，代理(包括服務發現和負載均衡邏輯)以客戶庫的形式嵌入在應用程序中。這種模式通常須要獨立的服務註冊中心組件配合，服務啓動時自動註冊到註冊中心並按期報心跳，客戶端代理則發現服務並作負載均衡。

Netflix開源的Eureka(註冊中心)是這種模式的典型案例，國內阿里開源的Dubbo也是採用這種模式。

三、主機獨立進程代理

這種作法是上面兩種模式的一個折中，代理既不是獨立集中部署，也不嵌入在客戶應用程序中，而是做爲獨立進程部署在每個主機上，一個主機上的多個消費者應用能夠共用這個代理，實現服務發現和負載均衡，以下圖所示。這個模式通常也須要獨立的服務註冊中心組件配合，做用同模式二。

四、服務網格

所謂的ServiceMesh，其實本質上就是上面提到的模式三~主機獨立進程模式，這個模式其實並不新鮮，業界(國外的Airbnb和國內的惟品會等)早有實踐，那麼爲何如今這個概念又流行起來了呢？我認爲主要緣由以下：

1. 上述模式一和二有一些固有缺陷，模式一相對比較重，有單點問題和性能問題；模式二則有客戶端複雜，支持多語言困難，沒法集中治理的問題。模式三是模式一和二的折中，彌補了二者的不足，它是純分佈式的，沒有單點問題，性能也OK，應用語言棧無關，能夠集中治理。
2. 微服務化、多語言和容器化發展的趨勢，企業迫切須要一種輕量級的服務發現機制，ServiceMesh正是迎合這種趨勢誕生，固然這還和一些大廠(如Google/IBM等)的背後推進有關。

模式三(ServiceMesh)也被形象稱爲邊車(Sidecar)模式

三、業界開源對比

目前，業界主流的 Service Mesh 相關的框架有三個，分別是 Google，IBM，Lyft都參與其中的 Istio，以及 Bouyant 公司下的兩個開源的 Service Mesh 的框架 Linkerd 以及 Conduit。

一、Istio

完整地包含了一個 Data Plane 以及 Control Plane，可是Istio 一直以來被挑戰的地方其實在於他的 Control Plane 的 Mixer 的部分，Istio 的 Mixer 承擔了服務鑑權，Quota 控制，Tracing，Metrics等等能力，它是一箇中央的節點，那 Mixer 就成了一個單點，這個單點的運維和高可用又成了一個問題。

另外，Istio 的性能是咱們一直以來比較擔憂的問題

二、Linkerd

Linkerd 沒有 Control Plane 這一層，只有 Sidecar。

Linkerd是用 Scala 寫的，跑在 JVM 上面。 Linkerd 所須要的內存至少都須要 100M，這也是 Bouyant 官方不推薦 Linkerd 和應用作一對一的部署，而是採用 DaemonSet 的方式進行部署。而咱們指望的一個部署方式是和應用作一對一的部署，這樣的內存佔用對於咱們來講成本太過，咱們指望將 Sidecar 的內存佔用控制在 10M 左右。

三、Conduit

Conduit 也是 Linkerd 不久以前推出的一個Service Mesh 的框架，還不太成熟。Conduit 選擇的語言是 Rust。比較小衆

四、SOFA Mesh（阿里自研）

SOFA Mesh 其實直接採用了 Istio 的 Control Plane 的Pilot 和 Auth，由於咱們以爲 Istio 在這塊上沒有太大的問題甚至裏面也有一些很是不錯的設計，好比Pilot 這部分的 Universal Data API 就是很是不錯的設計。Istio 的 Auth 這部分也充分地利用了 Kubernetes 的安全機制。

而Mixer 這部分，其實我以前就提到咱們是以爲有設計上問題的，因此咱們的想法是直接把 Mixer 搬到 Sidecar 中實現。

再者，你們都知道 Istio 的 Sidecar 是 Envoy，它是一個用 C++ 寫的，那麼咱們怎麼把Mixer 移入到 Sidecar 中去呢，其實咱們的 SOFA Mesh 的 Sidecar 是採用了 Golang 來寫的，因此纔給把 Mixer 移入Sidecar 提供了可能性，固然，咱們選擇用 Golang 來研發 Sidecar 不只僅是爲了把 Mixer 移入到 Sidecar 而已，其實也有其餘的考慮，一方面，在雲計算的時代，Golang以及成爲構建基礎設施的首選語言，咱們看到大量的基礎設施都是用 Golang 寫的，包括 Docker，Kubernetes 等等，選擇 Golang，其實也是但願可以更好地和雲原生時代的這些基礎設施貼合。

參考：

https://www.sohu.com/a/235575064_99940985

http://www.javashuo.com/article/p-kbrpnzwp-bc.html