[[343608]]

本文轉(zhuǎn)載自微信公眾號「小姐姐味道」，作者小姐姐養(yǎng)的狗 。轉(zhuǎn)載本文請聯(lián)系小姐姐味道公眾號。  

哎，又堵車了。

記性好的同學(xué)，一定記得我們那輛敞快明亮的JMC 。擁有一輛JMC，任嘶吼的狂風(fēng)穿過車窗打在臉上，是一件無比暢快的事情。

這次的車不一樣。有點高級。開的猛的時候，狂風(fēng)能夠掀掉頭盔。

仔細(xì)觀察上面的這輛車，它有三個輪子。其中左邊多出來的輪子和座位，就叫做邊車。它是可拆卸的，加上之后，就可以帶人兜風(fēng)了。

邊車模式(sidecar)，就像是梅超風(fēng)對于陳玄風(fēng)，莫邪對于干將。由于和比較前沿的ServiceMesh概念息息相關(guān)，所以很容易讓人望而卻步。你到網(wǎng)上去隨便一搜，都是晦澀難懂的概念。要了解下一代微服務(wù)，提前布局，需要啃一些枯燥的知識。

[[343610]]

隨著我的介紹，你會發(fā)現(xiàn)sidecar模式，是一個高度抽象的模式。但是不要著急，這輛車形狀怪異的交通工具，我們依然能夠駕馭。它的概念很簡單，只不過有很多使用限制。

一步步升級

注意：下面都是邊車模式，只不過有的邊車實在是簡陋。

<1>

大家都知道，微服務(wù)是復(fù)雜的，引入了一系列的問題，服務(wù)治理顯得尤關(guān)重要。比如日志收集、服務(wù)監(jiān)控、服務(wù)治理等。

比如上面這張圖，我們在一個Linux服務(wù)器上，部署了四個進(jìn)程。其中，web服務(wù)是最主要的進(jìn)程，其他進(jìn)程只是作為一些附加功能部署上去的。

其實，這三個圓圈，就是邊車的功能。只要把它給掛載上，上面的服務(wù)就擁有了這些功能。

但對于這三個組件的配置，是相當(dāng)復(fù)雜的。我們需要很多重復(fù)的工作。

<2>

上面這張圖，通過將Web應(yīng)用與我們的輔助應(yīng)用打包在一塊，進(jìn)一步增強了 不可變性。擁有了容器的加持，我們就能夠靠約定來簡化打包和發(fā)布操作。比如，上面的各個組件就可以通過localhost直接通信。

但可惜的是，我們的這些輔助程序，都是作為docker容器里的進(jìn)程去啟動的，這種 富容器模式 有諸多缺陷，不符合不可變基礎(chǔ)設(shè)施的理念，所以并不值得推薦。

<3>

k8s的Pod，在容器的基礎(chǔ)上，進(jìn)一步抽象。一個Pod中可以包含多個容器。如下圖，基礎(chǔ)服務(wù)和Web服務(wù)可以分別獨自構(gòu)建，最后以Pod作為載體，搭上便車就可以了。

為了更加顯著的看到這個過程，下面這張圖以日志收集為例，介紹了兩個pod，相同日志收集docker容器的拓?fù)鋱D。

從上面的演進(jìn)過程我們可以看到。邊車，就是輔助或者基礎(chǔ)程序而已。但如何方便的管理這些附加的程序，我們有不同的組織方式。只有高度的抽象層次，才能進(jìn)行方便的組裝與設(shè)計。

<4>

到此為止，我們可以看一下ServiceMesh經(jīng)典的兩張圖了。

我們把Web應(yīng)用(業(yè)務(wù)服務(wù))，抽象成綠色的方塊。然后把輔助組件(sidecar)，抽象成藍(lán)色方塊。在一個相對簡單的環(huán)境中，我們的部署方式如下所示。

由于輔助組件并不能單獨存在，所以它們都依附在綠色的服務(wù)上面。

我們抽調(diào)服務(wù)集群的血肉(Web服務(wù))，只留下它的筋骨(sidecar)，就可以獲得下面這張圖，這就是ServiceMesh。可以看到里面的連接線條是非常復(fù)雜的，人工不可能完成，只能依靠平臺去管理。

任何東西只要一上規(guī)模了，就體現(xiàn)了它的復(fù)雜度。這還僅僅是只有36個服務(wù)節(jié)點的拓?fù)鋱D。

不要小看這一個小小的藍(lán)色方塊。它不僅僅可以是一個輔助程序，而且可以成為基礎(chǔ)設(shè)施?，F(xiàn)在典型的service mesh，分為`數(shù)據(jù)平面`和`控制平面`，大多數(shù)落地的企業(yè)使用proxy方式實現(xiàn)了數(shù)據(jù)平面，對控制平面的實現(xiàn)有限。

像比較流行的Istio，通過負(fù)載均衡、服務(wù)間的身份驗證、監(jiān)控等方法，它可以輕松地創(chuàng)建一個已經(jīng)部署了服務(wù)的網(wǎng)絡(luò)，而服務(wù)的代碼只需很少更改甚至無需更改。通過在整個環(huán)境中部署一個特殊的 sidecar代理，為服務(wù)添加 Istio 的支持，而代理會攔截微服務(wù)之間的所有網(wǎng)絡(luò)通信，然后使用其控制平面的功能來配置和管理 Istio。

我們看下它官方的功能描述：

1. 為 HTTP、gRPC、WebSocket 和 TCP 流量自動負(fù)載均衡。
2. 通過豐富的路由規(guī)則、重試、故障轉(zhuǎn)移和故障注入對流量行為進(jìn)行細(xì)粒度控制。
3. 可插拔的策略層和配置 API，支持訪問控制、速率限制和配額。
4. 集群內(nèi)(包括集群的入口和出口)所有流量的自動化度量、日志記錄和追蹤。
5. 在具有強大的基于身份驗證和授權(quán)的集群中實現(xiàn)安全的服務(wù)間通信。

可以說，ServiceMesh將業(yè)務(wù)屬性剝離了出去，只剩下一張大網(wǎng)，涵蓋了所有運維和基礎(chǔ)服務(wù)的工作。

要用它，不能說是沒有代價的。其中有兩點比較重要：

網(wǎng)絡(luò)包通過層層的代理和轉(zhuǎn)發(fā)(Ambassador模式)，效率會降低，排錯會變困難。

需要按照這個網(wǎng)格的規(guī)范進(jìn)行改造，也就是寫一堆適配器(Adapter模式)。

SpringCloud的Sidecar

說到適配器，就不禁想起了SpringCloud的Sidecar。

Java里要說玩新概念，怎么能少的了Spring家族?SpringCloud同樣有一個sidecar的組件，它的maven坐標(biāo)如下。

<dependency> 
            <groupId>org.springframework.cloud</groupId> 
            <artifactId>spring-cloud-netflix-sidecar</artifactId> 
</dependency> 

它做的事情，更加像一個適配器。它能把一個普通的php或者nodejs服務(wù)，偽裝成一個正常的SpringCloud服務(wù)。

通過簡單的配置，我們就可以讓一些其他語言開發(fā)的Web應(yīng)用，加入到SpringCloud體系中來。

它的使用比較簡單，在此不過多介紹。

End

可以看到，我們今天的這輛車，雖然簡陋，但是很高級，甚至和最前沿的ServiceMesh掛鉤了。在這里，我實在是佩服計算機界的名詞創(chuàng)造能力和抽象能力。一個簡單的生產(chǎn)者消費者，玩出了響應(yīng)式編程;一個簡單的邊車模式，玩出了ServicemMesh。

雖然這個東西比較新，但比起什么中臺概念來，能夠落地不務(wù)虛，是更加有技術(shù)說服力的。因為中臺搞不死程序員，但會搞死公司。

未來還會有什么奇形怪狀的交通工具呢?這是個未知數(shù)。請搭上xjjdog的輕便列車，一塊探索吧。

作者簡介：小姐姐味道 (xjjdog)，一個不允許程序員走彎路的公眾號。聚焦基礎(chǔ)架構(gòu)和Linux。十年架構(gòu)，日百億流量，與你探討高并發(fā)世界，給你不一樣的味道。我的個人微信xjjdog0，歡迎添加好友，進(jìn)一步交流。