Service Mesh是一種基礎通信設施，它的出現(xiàn)時為了解決微服務之間復雜的通信問題。我們都知道，使用微服務思想去構(gòu)建系統(tǒng)之后，會出現(xiàn)很多獨立的微服務模塊。模塊之間的服務發(fā)現(xiàn)，負載均衡，失敗重傳等這些考慮因素，是每個模塊都需要重復地去解決的，同時復雜性會隨著模塊數(shù)量增多而變大。
解決模塊間通信問題之路
在計算機先驅(qū)引入了TCP/IP協(xié)議后，保證了鏈路層通信的可靠性。但是隨著系統(tǒng)規(guī)模的擴大，引入了分布式，微服務這些概念，使一個系統(tǒng)的模塊數(shù)量變得越來越多，模塊間通信的可靠性就是個問題了，分布式通信需要解決下面幾個問題：
服務發(fā)現(xiàn)。怎么讓一個模塊感知到其它的模塊，硬編碼是最簡單的方式，但顯然不是最好的方式。
負載均衡。一個模塊有多臺機器運行，怎么在多臺機器上做負載均衡？除了手動做
IP輪詢，需要有更豐富的輪詢方式。失敗重傳&熔斷。當一個模塊不可用時，需要能夠重試，重試幾次還不行就需要熔斷機制來保證響應速度，避免請求堆積。
流量監(jiān)控。日志，請求監(jiān)控，鏈路追蹤。這些是一個工業(yè)級別系統(tǒng)必須具備的基本能力。
流量控制。常見的有訪問控制，頻率限制，配額控制。
模塊鑒權(quán)。模塊之間的鑒權(quán)，入口模塊需要具備的能力。
另外分布式系統(tǒng)還有應用生命周期管理的需求（發(fā)布，灰度，回滾，擴容，縮容等），這是另外一個維度的事情，后續(xù)再另寫文章講述。
為了解決這些問題，業(yè)界已經(jīng)做出了很多努力。下面使用三個階段來劃分。
階段一，自建服務
自建分布式服務是分布式發(fā)展的初級階段，最開始應該是出現(xiàn)在各大互聯(lián)網(wǎng)公司。隨著互聯(lián)網(wǎng)的普及，請求的量級開始上來，單機無法承載龐大的請求量，萌芽出來分布式處理的需求。各個互聯(lián)網(wǎng)公司開始自建一些處理分布式的組件，比如負載均衡，流量監(jiān)控，日志收集等。
該階段的特點：
各個公司基本是自研分布式組件，自給自足
沒有系統(tǒng)性，都是些比較零散的組件
開源的比較少
這個階段寫出來的實用組件為后續(xù)開源的標準框架打下了基礎。
階段二，標準框架
隨著各大互聯(lián)網(wǎng)公司在分布式上的積累和實踐，漸漸對分布式系統(tǒng)有了些系統(tǒng)性梳理，從而產(chǎn)生出了一些成熟的分布式框架，下面是幾個主流的框架。
這個階段出現(xiàn)的框架，基本具有如下特點：
不同程度上解決了分布式通信的問題，各有優(yōu)劣。具體選擇哪種框架建議去詳細了解下它們的特點和評價。
業(yè)務實現(xiàn)語言受框架語言限制?？蚣芏际腔谀撤N語言實現(xiàn)，業(yè)務代碼基本是跟著框架語言走的。
框架對業(yè)務代碼有侵入性的。因為為了使用框架的某些特性，必須在業(yè)務代碼中使用框架提供的通信API和其它特性。這種耦合對代碼的復用是有影響的。
這些框架雖然一定程度上簡化了解決分布式通信問題的難度，但是顯然還是不夠靈活，業(yè)務代碼還是需要去關心如何解決分布式通信問題，無法做到只需要關注業(yè)務代碼。
下一階段將講述目前的最新進展，也就是致力于如何使業(yè)務代碼只用關心業(yè)務的實現(xiàn)，不用去關心分布式通信問題。
階段三，將通信問題協(xié)議化
大家都知道，TCP/IP協(xié)議棧的出現(xiàn)，是為了屏蔽鏈路層和物理層通信的各種細節(jié)，為廣大程序員們提供一個省心穩(wěn)定的字節(jié)流通道。現(xiàn)在在TCP/IP協(xié)議通信的基礎上，又出現(xiàn)了了新的問題，那就是分布式通信的各種問題考慮，前面已經(jīng)羅列了大部分。大神們?yōu)榱私鉀Q這個問題，想到的辦法就是把分布式通信的實現(xiàn)作為一種基礎通信設施，作為協(xié)議棧的一部分提供給廣大程序猿們，這樣大家就不用重復去考慮實現(xiàn)分布式通信了。這個想法就是Service Mesh(服務網(wǎng)格)。
當然Service Mesh目前的實現(xiàn)不是以協(xié)議棧的形式提供的，而是以sidecar（邊車）的形式提供。sidecar的意思與我們小時候看到的三輪車很類似，就是主駕旁邊的那個副駕。
下圖是
Service Mesh部署后的示意圖，其中藍色塊就代表通信Proxy，通信Proxy就是實現(xiàn)了分布式通信，它作為sidecar與業(yè)務Service部署一起。業(yè)務Service之間的所有出入通信都會通過Proxy
目前最流行的兩款
Service Mesh開源軟件是Istio和Linkerd。其中Istio是由Google，IBM和Lyft聯(lián)合開發(fā)的，而Linkerd是CNCF成員，兩者都有深厚的背景，而目前Istio比Linkerd用的還是相對廣泛一些。
下面是Istio的架構(gòu)圖
其中
Proxy還是以sidecar模式提供了可靠的分布式通信實現(xiàn)。其它模塊實現(xiàn)了配置和策略檢查等功能，后續(xù)再另寫文章詳細介紹。
結(jié)語
其實Service Mesh也不是什么高深的概念，說白了就是通過一個專門的agent來代理通信，讓業(yè)務Service專注于實現(xiàn)業(yè)務邏輯，而agent就專注于實現(xiàn)可靠的分布式邏輯。本文通過講解發(fā)展歷史的方式來解釋了這種思想。
另外文中還沒講到的是目前Service Mesh的應用，大部分都是云原生的，基于容器服務Kubernetes之上實現(xiàn)的。關于容器服務Kubernetes的講解，可以去參考它的官網(wǎng)資料，或者關注我后期的相關文章。
版權(quán)聲明：本文為原創(chuàng)文章，版權(quán)歸 Roper所有，轉(zhuǎn)載請注明出處！
