原創(chuàng)：小姐姐味道（微信公眾號ID：xjjdog），歡迎分享，轉(zhuǎn)載請保留出處。

緊緊抓住最新技術(shù)的脈搏，用人話普及前沿技術(shù)，是xjjdog的一貫作風(fēng)，現(xiàn)在也是一種責(zé)任和習(xí)慣。從漫天飛舞的華麗辭藻中，抓住技術(shù)的本質(zhì)，可以避免喧賓奪主，也可以避免被忽悠。

基礎(chǔ)架構(gòu)，每一波都在革自己的命。ServiceMesh是處于云原生時代的改革尖兵，其中istio以其高貴的身份與絕佳的性能，一騎絕塵，隱隱有成為標(biāo)準(zhǔn)的可能。

接下來，讓我們抽絲剝繭，來看一下istio到底是個啥。

1. 中間層是基礎(chǔ)架構(gòu)的絕招

在介紹istio到底為何物的時候，我們先來描述一個問題。

假如你的公司，打算全面擁抱SpringCloud微服務(wù)，那么你一定會選擇Java語言。然后一些比較古老的項目，都往上面靠。

但總有一些比較頑固的項目，無法用Java重構(gòu)。比如，你的某個工程是使用C++寫的，重構(gòu)的成本非常大。那怎么辦呢？

1.1 sidecar

軟件行業(yè)有一個永恒不變的真理：如果你想要快速有效的解決兩個組件之間的問題，那就加入一個中間層。

無論是概念上的“中臺”，還是技術(shù)層面的“proxy”，甚至是啰里啰唆的DDD分層，都可以這么玩！

對于網(wǎng)絡(luò)請求來說，Proxy可以接管所有的流量，然后對這些流量進行轉(zhuǎn)化、分析、調(diào)度，就能夠把一個丑八怪服務(wù)套一層皮，變成一個外觀上漂漂亮亮的服務(wù)。

解決上面的問題，我們只需要使用SpringCloud兼容的技術(shù)開發(fā)這個Proxy，然后做一層轉(zhuǎn)化，將請求轉(zhuǎn)化成C++調(diào)用，就可以很好的完成工作。調(diào)用這個Proxy的請求，壓根不會想到后面竟然是C++。

通常情況下，我們需要把Proxy和C++服務(wù)部署在一臺機器上，它們就會有比較好的性能表現(xiàn)；當(dāng)然，現(xiàn)在容器搞起來之后，就可以運行在兩個不同的Docker實例上；再后來，k8s來了，一個Pod里可以直接放上Proxy和C++兩個容器實例，它們之間就可以通過localhost通信，成為了一個整體。

這就是sidecar的概念。對這一部分不是很熟悉的同學(xué)，可以看以前的一篇文章：《ServiceMesh的關(guān)鍵：邊車模式（sidecar）；又要開車了》。

為什么一定要講到代理呢？因為istio核心組件，本質(zhì)上，就是一個sidecar形式的proxy。你要請求后端的服務(wù)，就一定要經(jīng)過istio。它接管了所有的流量，并根據(jù)這些流量的屬性進行了劃分。

1.2 proxy的功能

理念就是這么簡單。但一旦把微服務(wù)里各種亂七八糟的功能，全部交給istio去做，那事情就變得復(fù)雜起來。

眾所周知，微服務(wù)所引入的問題，比它解決的問題還要多。有了配套的設(shè)施，微服務(wù)才算是真正的微服務(wù)。

我們來看一個請求從外圍進入微服務(wù)后，都要進行哪些動作。

• 微服務(wù)要想被找到彼此，就需要有一個統(tǒng)一的注冊中心，當(dāng)然它本質(zhì)上是一個配置中心
• 想要跟蹤一個請求在不同運行實例上的運行情況，就需要一個集中的Tracing系統(tǒng)
• 請求通過RPC調(diào)用后端的服務(wù)，首先要經(jīng)過負載均衡，還要熔斷、限流、重試、故障轉(zhuǎn)移等。當(dāng)然一切的基礎(chǔ)，需要在安全的前提下進行
• 一個請求還有更多屬性，比如鑒權(quán)、加密、認證，灰度等。如果每個功能都做一遍，又復(fù)雜又枯燥。
• 配套的CI/CD等，加快研發(fā)流程

關(guān)鍵是，這些功能對于業(yè)務(wù)開發(fā)的同學(xué)來說，并沒有什么用。業(yè)務(wù)的同學(xué)只需要關(guān)注自己的業(yè)務(wù)邏輯就可以了，但目前我們上面所提到的各種技術(shù)術(shù)語和功能組件，現(xiàn)階段的業(yè)務(wù)開發(fā)一點都繞不開。

更要命的是，不論我升級上面的哪一個組件，都需要業(yè)務(wù)重新引入一個新的SDK版本，然后滾動進行升級。因為它們之所以稱之為基礎(chǔ)設(shè)施，就是因為牽一發(fā)而動全身的。

所以我們的部署模式要有一些改變。如果我們的所有應(yīng)用，都不直接向外提供服務(wù)，而是全部通過代理去轉(zhuǎn)發(fā)請求，那么它就會變成下面這張圖的樣子。

Envoy Proxy就相當(dāng)于我們的代理sidecar，而Service A和Service B，就代表我們真正的微服務(wù)。服務(wù)實例和代理的數(shù)量，是1：1的。

那么我們上面所提到的所有流量，都可以由Envoy來接管---它和你直接調(diào)用后面的Service是沒什么兩樣的，但由于它是一個Proxy，那就可以像Aop一樣，在外面包一層，干任何事！

所有神奇的事情，都可以在代理發(fā)生！

1.3 數(shù)據(jù)平面和控制平面

如果你以前接觸過ServiceMesh，你一定聽說過這兩個詞。

數(shù)據(jù)平面，其實指的就是我們的Proxy集合。它雖然是個網(wǎng)狀，但如果我們把它的概念統(tǒng)一一下，它就叫平面。

那么控制平面，就是配套的控制管理臺，以及下發(fā)指令的管理后臺等。

也就是說，大多數(shù)情況下，僅僅數(shù)據(jù)平面，服務(wù)就能運行。但要看框架強不強，還得看控制平面易用不易用。

圖中的上半部分，就是傳說中的數(shù)據(jù)平面。經(jīng)過我們上面的介紹，應(yīng)該對其非常熟了。istio把它搞復(fù)雜的地方在于，它加入了證書體系來控制認證和授權(quán)。

但如果你的公司是自研ServiceMesh的話，那工作其實就簡單的多了。你的工作量全部集中在proxy的開發(fā)上。

控制平面，如果不按照istio的規(guī)則來，其實也是可有可無的。比如，你的日志收集，可以直接穿透Pod連接到你的ELKB平臺，遙測這一環(huán)，就可以沿用你公司原來的技術(shù)架構(gòu)。

所以說。

如果你的公司比較新，基礎(chǔ)設(shè)施還沒有完善，那么直接上istio，那是非常棒的，因為大部分基礎(chǔ)架構(gòu)的組件，它都替你做了。

但如果你的公司有些年月，基礎(chǔ)設(shè)施都開發(fā)的差不多了，那切換到istio的基礎(chǔ)設(shè)施，那就是閑的！你的最好選擇，就是開發(fā)這樣一個代理，然后把流量導(dǎo)到自己的基礎(chǔ)組件上。

使用C++或者Go語言而不是Java開發(fā)這樣的組件，是最好的選擇。因為Java開發(fā)Agent往往會占用比較多的內(nèi)存。當(dāng)然，如果內(nèi)存對你來說不值錢的話，這話當(dāng)我沒說。

2. 統(tǒng)一是基礎(chǔ)架構(gòu)的首要目標(biāo)

因為基礎(chǔ)架構(gòu)的范圍很大，所以每一種技術(shù)都有多種解決方案。比如MQ，比較流行的就有Kafka、RabbitMQ、Pulsar等。

對于社區(qū)來說，競爭和差異化是促進創(chuàng)新的原則。但對于一個公司來說，基礎(chǔ)架構(gòu)的統(tǒng)一才是首要目標(biāo)（那些巨無霸另說）。

所以無論是調(diào)度也好，還是流量攔截也罷，這個代理的職責(zé)只會變得越來越大。如果技術(shù)不統(tǒng)一，那么功能就會成為笛卡爾乘積式的爆炸。istio選用了比較主流的方式，代理通過Envoy來實現(xiàn)，而中間的網(wǎng)絡(luò)協(xié)議，則支持 HTTP/1.1，HTTP/2，gRPC 或者 TCP等主流的通信協(xié)議。

統(tǒng)一，是它在這里體現(xiàn)的價值。

在功能上，Pod天然能夠?qū)⒋砗头?wù)綁在一塊，所以k8s成了首選的調(diào)度平臺。當(dāng)然你非要做類似NodePort一樣的機器代理，那也沒什么本質(zhì)的區(qū)別。

最終，經(jīng)過社區(qū)的融合（或者說壟斷），istio成為了完成統(tǒng)一整個目標(biāo)的框架。它的職責(zé)也越來越多，慢慢演變成了上圖的模樣。

上半部分依然是雷打不動的數(shù)據(jù)平面，但istio在控制平面上開了花。

控制中心做了進一步的細分，分成了 Pilot、Mixer、和 Citadel，它們的各自功能如下：

• Mixer：為整個集群執(zhí)行訪問控制和 策略管理（限流、限額等），并收集代理所觀察到的，服務(wù)之間的流量統(tǒng)計數(shù)據(jù)，也就是遙測（監(jiān)控、APM等）數(shù)據(jù)。
• Pilot：為 Envoy 提供了服務(wù)發(fā)現(xiàn)，流量管理和智能路由（AB測試、金絲雀發(fā)布等），以及錯誤處理（超時、重試、熔斷）功能。
• Citadel：為服務(wù)之間提供認證和證書管理，可以讓服務(wù)自動升級成 TLS 協(xié)議。
• Galley：這個組件并不向數(shù)據(jù)平面直接提供業(yè)務(wù)能力，而是作為其他控制平面的協(xié)調(diào)組件，這樣解耦的更加徹底，核心功能也越來越多。

End

我們可以到，一個正常的請求，在加入istio之后，就全部變成了proxy和proxy之間的通訊。proxy既代理了入流量，也代理了出流量，所有的流量都從它這里轉(zhuǎn)了一圈，所以它能夠攔截和分析任何數(shù)據(jù)。借助于k8s的助力，服務(wù)和proxy之間可以通過localhost通信。

對于微服務(wù)架構(gòu)來說，一個請求會分散到多臺機器上，耗時、錯誤日志等都會變的分散，問題排查起來不得不依賴APM等組件。istio更加徹底，你根本不知道具體的服務(wù)節(jié)點到底被調(diào)度到哪里了，傳統(tǒng)的人肉運維方式失效，對上游的工具依賴性更高。

使用istio有很多前置的知識點需要啃掉，比如虛擬化、k8s。新公司直接跳過這兩者擁抱istio甚至是更好的選擇。但如果你的公司已經(jīng)有了非常好用的基礎(chǔ)設(shè)置工具，又與社區(qū)不兼容的話，那恐怕只有借鑒理念，自研proxy了。

作者簡介：小姐姐味道 (xjjdog)，一個不允許程序員走彎路的公眾號。聚焦基礎(chǔ)架構(gòu)和Linux。十年架構(gòu)，日百億流量，與你探討高并發(fā)世界，給你不一樣的味道。

推薦閱讀：

1. 玩轉(zhuǎn)Linux
2. 什么味道專輯

3. 藍牙如夢
4. 殺機！
5. 失聯(lián)的架構(gòu)師，只留下一段腳本
6. 架構(gòu)師寫的BUG，非比尋常

好了，這篇文章的內(nèi)容發(fā)貨聯(lián)盟就和大家分享到這里，如果大家網(wǎng)絡(luò)推廣引流創(chuàng)業(yè)感興趣，可以添加微信：80709525  備注：發(fā)貨聯(lián)盟引流學(xué)習(xí)； 我拉你進直播課程學(xué)習(xí)群，每周135晚上都是有實戰(zhàn)干貨的推廣引流技術(shù)課程免費分享！