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

緊緊抓住最新技術的脈搏，用人話普及前沿技術，是xjjdog的一貫作風，現在也是一種責任和習慣。從漫天飛舞的華麗辭藻中，抓住技術的本質，可以避免喧賓奪主，也可以避免被忽悠。

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

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

1. 中間層是基礎架構的絕招

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

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

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

1.1 sidecar

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

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

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

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

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

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

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

1.2 proxy的功能

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

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

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

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

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

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

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

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

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

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

1.3 數據平面和控制平面

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

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

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

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

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

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

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

所以說。

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

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

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

2. 統(tǒng)一是基礎架構的首要目標

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

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

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

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

在功能上，Pod天然能夠將代理和服務綁在一塊，所以k8s成了首選的調度平臺。當然你非要做類似NodePort一樣的機器代理，那也沒什么本質的區(qū)別。

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

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

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

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

End

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

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

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

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

推薦閱讀：

1. 玩轉Linux
2. 什么味道專輯

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

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