ServiceMesh的關鍵：邊車模式（sidecar）；又要開車了
本文轉載自微信公眾號「小姐姐味道」，作者小姐姐養的狗 。轉載本文請聯系小姐姐味道公眾號。
哎，又堵車了。
記性好的同學，一定記得我們那輛敞快明亮的JMC 。擁有一輛JMC，任嘶吼的狂風穿過車窗打在臉上，是一件無比暢快的事情。
這次的車不一樣。有點高級。開的猛的時候，狂風能夠掀掉頭盔。
仔細觀察上面的這輛車，它有三個輪子。其中左邊多出來的輪子和座位，就叫做邊車。它是可拆卸的，加上之后，就可以帶人兜風了。
邊車模式(sidecar)，就像是梅超風對于陳玄風，莫邪對于干將。由于和比較前沿的ServiceMesh概念息息相關，所以很容易讓人望而卻步。你到網上去隨便一搜，都是晦澀難懂的概念。要了解下一代微服務，提前布局，需要啃一些枯燥的知識。
隨著我的介紹，你會發現sidecar模式，是一個高度抽象的模式。但是不要著急，這輛車形狀怪異的交通工具，我們依然能夠駕馭。它的概念很簡單，只不過有很多使用限制。
一步步升級
注意：下面都是邊車模式，只不過有的邊車實在是簡陋。
<1>
大家都知道，微服務是復雜的，引入了一系列的問題，服務治理顯得尤關重要。比如日志收集、服務監控、服務治理等。
比如上面這張圖，我們在一個Linux服務器上，部署了四個進程。其中，web服務是最主要的進程，其他進程只是作為一些附加功能部署上去的。
其實，這三個圓圈，就是邊車的功能。只要把它給掛載上，上面的服務就擁有了這些功能。
但對于這三個組件的配置，是相當復雜的。我們需要很多重復的工作。
<2>
上面這張圖，通過將Web應用與我們的輔助應用打包在一塊，進一步增強了 不可變性。擁有了容器的加持，我們就能夠靠約定來簡化打包和發布操作。比如，上面的各個組件就可以通過localhost直接通信。
但可惜的是，我們的這些輔助程序，都是作為docker容器里的進程去啟動的，這種 富容器模式 有諸多缺陷，不符合不可變基礎設施的理念，所以并不值得推薦。
<3>
k8s的Pod，在容器的基礎上，進一步抽象。一個Pod中可以包含多個容器。如下圖，基礎服務和Web服務可以分別獨自構建，最后以Pod作為載體，搭上便車就可以了。
為了更加顯著的看到這個過程，下面這張圖以日志收集為例，介紹了兩個pod，相同日志收集docker容器的拓撲圖。
從上面的演進過程我們可以看到。邊車，就是輔助或者基礎程序而已。但如何方便的管理這些附加的程序，我們有不同的組織方式。只有高度的抽象層次，才能進行方便的組裝與設計。
<4>
到此為止，我們可以看一下ServiceMesh經典的兩張圖了。
我們把Web應用(業務服務)，抽象成綠色的方塊。然后把輔助組件(sidecar)，抽象成藍色方塊。在一個相對簡單的環境中，我們的部署方式如下所示。
由于輔助組件并不能單獨存在，所以它們都依附在綠色的服務上面。
我們抽調服務集群的血肉(Web服務)，只留下它的筋骨(sidecar)，就可以獲得下面這張圖，這就是ServiceMesh。可以看到里面的連接線條是非常復雜的，人工不可能完成，只能依靠平臺去管理。
任何東西只要一上規模了，就體現了它的復雜度。這還僅僅是只有36個服務節點的拓撲圖。
不要小看這一個小小的藍色方塊。它不僅僅可以是一個輔助程序，而且可以成為基礎設施。現在典型的service mesh，分為`數據平面`和`控制平面`，大多數落地的企業使用proxy方式實現了數據平面，對控制平面的實現有限。
像比較流行的Istio，通過負載均衡、服務間的身份驗證、監控等方法，它可以輕松地創建一個已經部署了服務的網絡，而服務的代碼只需很少更改甚至無需更改。通過在整個環境中部署一個特殊的 sidecar代理，為服務添加 Istio 的支持，而代理會攔截微服務之間的所有網絡通信，然后使用其控制平面的功能來配置和管理 Istio。
我們看下它官方的功能描述：
- 為 HTTP、gRPC、WebSocket 和 TCP 流量自動負載均衡。
- 通過豐富的路由規則、重試、故障轉移和故障注入對流量行為進行細粒度控制。
- 可插拔的策略層和配置 API，支持訪問控制、速率限制和配額。
- 集群內(包括集群的入口和出口)所有流量的自動化度量、日志記錄和追蹤。
- 在具有強大的基于身份驗證和授權的集群中實現安全的服務間通信。
可以說，ServiceMesh將業務屬性剝離了出去，只剩下一張大網，涵蓋了所有運維和基礎服務的工作。
要用它，不能說是沒有代價的。其中有兩點比較重要：
網絡包通過層層的代理和轉發(Ambassador模式)，效率會降低，排錯會變困難。
需要按照這個網格的規范進行改造，也就是寫一堆適配器(Adapter模式)。
SpringCloud的Sidecar
說到適配器，就不禁想起了SpringCloud的Sidecar。
Java里要說玩新概念，怎么能少的了Spring家族?SpringCloud同樣有一個sidecar的組件，它的maven坐標如下。
- <dependency>
- <groupId>org.springframework.cloud</groupId>
- <artifactId>spring-cloud-netflix-sidecar</artifactId>
- </dependency>
它做的事情，更加像一個適配器。它能把一個普通的php或者nodejs服務，偽裝成一個正常的SpringCloud服務。
通過簡單的配置，我們就可以讓一些其他語言開發的Web應用，加入到SpringCloud體系中來。
它的使用比較簡單，在此不過多介紹。
End
可以看到，我們今天的這輛車，雖然簡陋，但是很高級，甚至和最前沿的ServiceMesh掛鉤了。在這里，我實在是佩服計算機界的名詞創造能力和抽象能力。一個簡單的生產者消費者，玩出了響應式編程;一個簡單的邊車模式，玩出了ServicemMesh。
雖然這個東西比較新，但比起什么中臺概念來，能夠落地不務虛，是更加有技術說服力的。因為中臺搞不死程序員，但會搞死公司。
未來還會有什么奇形怪狀的交通工具呢?這是個未知數。請搭上xjjdog的輕便列車，一塊探索吧。
作者簡介：小姐姐味道 (xjjdog)，一個不允許程序員走彎路的公眾號。聚焦基礎架構和Linux。十年架構，日百億流量，與你探討高并發世界，給你不一樣的味道。我的個人微信xjjdog0，歡迎添加好友，進一步交流。
