背景
最近因工作原因開始了解Service Mesh與Envoy，為系統性梳理所學内容，是以沉澱了此文檔，但由于所知有限，如文檔中有描述不當之處，希望不吝賜教。
提到Envoy就不得不提Service Mesh，說到Service Mesh就一定要談及微服務了，那麼我們就先放下Envoy，簡單了解下微服務、Service Mesh以及Envoy在Service Mesh中處于一個什麼樣的角色。
過去幾年間，架構領域最火的方向非微服務莫屬，那麼微服務架構到底為我們帶來了什麼樣的好處呢？下面通過一張圖說明架構的演進，如下：
伴随着業務規模的變大，微服務的好處顯而易見，例如它本身所具備的可擴充性、易維護性、故障和資源隔離性等諸多特性使得産品的生産研發效率大大提高，同時，基于微服務架構設計，研發人員可以建構出原生對于“雲”具備超高友好度的系統，讓産品的持續內建與釋出變得更為便捷。
然而沒有所謂的銀彈，微服務帶來很多好處的同時也引入了很多問題。在雲原生模型裡，一個應用可以由數百個服務組成，每個服務可能有數千個執行個體，每個執行個體的狀态可能持續的發生變化，此時，服務間的通信不僅異常複雜，而且都是運作時的行為，管理好服務間通信對于保證端到端的性能與可靠性來說無疑成為重中之重。在Service Mesh沒有出現之前，微服務架構之間的通訊大多采用SDK方案，但該方式短闆也非常明顯，例如對業務有侵入性、無法做到SDK更新對業務透明等。
基于以上種種複雜原因催生了服務間通訊層的出現，這個層即不應該與應用程式的代碼耦合，又能捕獲到底層環境的動态變化并作出适當的調整，避免業務出現單點故障；同時也可以讓開發者隻關注自身業務，将應用雲化後帶來的諸多問題以不侵入業務代碼的方式提供給開發者。
上述所說的這個服務間通訊層就是Service Mesh（國内通常翻譯為服務網格），它可以提供安全、快速、可靠的服務間通訊。如果用一句話來解釋什麼是Service Mesh，可以将其比作微服務間的TCP/IP層，負責服務之間的調用、限流、熔斷和監控等。
讀到這裡大家一定仍然存在這樣的疑惑，Service Mesh到底是什麼呢？這是一個全新的東西嗎？它的演進過程是什麼樣的呢？下面使用一張圖來說明其演進過程，如下：
從上圖可以看到最初的Service Mesh始于一個網絡代理，在2016年1月業界第一個開源項目Linkerd釋出，同年9 月 29 日的 SF Microservices 大會上，“Service Mesh”這個詞彙第一次在公開場合被使用，随後Envoy也釋出了自己的開源版本，但此時的Service Mesh更多停留在Sidecar層面，并沒有清晰的Sidecar管理面，是以屬于Service Mesh的第一代。此時雖然Service Mesh尚不成熟，但一個初具雛形的服務間通訊層已然出現，如下圖：
随後Google聯合IBM、Lyft發起了Istio項目，從架構層面明确了資料平面、控制平面，并通過集中式的控制平面概念進一步強化了Service Mesh的價值，再加上巨頭背書的緣故，是以Service Mesh、Istio概念迅速火爆起來。此時已然進入到了第二代的Service Mesh，控制平面的概念及作用被大家認可并接受，而更重要的一點是至此已經形成了一個完整意義上的SDN服務通訊層。此時的Service Mesh架構如下圖：
至此Service Mesh的背景資訊基本介紹完畢，接下來開始進入正題說說Envoy相關的内容。其在完整的Service Mesh體系中處于一個什麼位置呢？繼續看圖：
Envoy是Istio中的Sidecar官方标配，是一個面向服務架構的高性能網絡代理，由C++語言實作，擁有強大的定制化能力，通過其提供的Filter機制基本可以對請求轉發過程中超過50%的流程做定制化，在性能方面由于其實作參考了Nginx，也處于主流水準，當然還有很多特性，在這裡就不做一一介紹了。
從一份配置了解Envoy主流程
任何軟體架構設計，其核心都是圍繞資料展開的，基本上如何定義資料結構就決定了其流程的走向，剩下的不外乎加上一些設計手法，抽離出變與不變的部分，不變的部分最終會轉化為程式的主流程，基本固化，變的部分盡量保證擁有良好的擴充性、易維護性，最終會轉化為主流程中各個抽象的流程節點。
對于Envoy也不例外，作為一個網絡代理程式，其核心職責就是完成請求的轉發，在轉發的過程中人們又希望可以對其做一定程度的微處理，例如附加一個Header屬性等，否則就沒必要使用代理程式了。那麼Envoy是如何運作的呢？它是如何定義其資料結構，并圍繞該資料結構設計軟體架構、程式流程，又是如何抽象出變得部分，保證高擴充性呢？
帶着這些疑問，試想Envoy作為一個高度可定制化的程式，其定制化的載體必然是配置資訊，那麼我們下面就試着從Envoy的一份配置來解讀其架構設計與程式流程。
在檢視其配置前，我們不妨先腦補一下網絡代理程式的流程，比如作為一個代理，首先要能擷取請求流量，通常是采用監聽端口的方式實作，其次拿到請求資料後需要對其做些微處理，例如附加Header頭或校驗某個Header字段内容等，這裡針對來源資料的層次不同，就可以分為L3L4L7，然後将請求轉發出去，轉發這裡又可以衍生出如果後端是一個叢集，需要從中挑選出一台機器，如何挑選又涉及到負載均衡等。腦補下來大緻流程應該就是這個樣子，接下來我們看看Envoy是如何組織其配置資訊的。
Envoy配置的簡單配置資訊如下：
關鍵字段說明：
Listener: 服務(程式)監聽者。就是真正幹活的。 Envoy 會暴露一個或者多個listener監聽downstream的請求。
Filter: 過濾器。在 Envoy 中指的是一些“可插拔”和可組合的邏輯處理層。是 Envoy 核心邏輯處理單元。
Route_config: 路由規則配置，即請求路由到後端那個叢集(cluster)。
Cluster: 服務提供方叢集。Envoy 通過服務發現定位叢集成員并擷取服務。具體請求到哪個叢集成員是由負載均衡政策決定。通過健康檢查服務來對叢集成員服務狀态進行檢查。
根據上面我們腦補的流程，配合上這份配置的話，Envoy大緻處理流程如下圖：
Envoy内部對請求的處理流程其實跟我們上面腦補的流程大緻相同，即對請求的處理流程基本是不變的，而對于變化的部分，即對請求資料的微處理，全部抽象為Filter，例如對請求的讀寫是ReadFilter、WriteFilter，對HTTP請求資料的編解碼是StreamEncoderFilter、StreamDecoderFilter，對TCP的處理是TcpProxyFilter，其繼承自ReadFilter，對HTTP的處理是ConnectionManager，其也是繼承自ReadFilter等等，各個Filter最終會組織成一個FilterChain，在收到請求後首先走FilterChain，其次路由到指定叢集并做負載均衡擷取一個目标位址，然後轉發出去。
淺談Envoy架構
聊完了基本流程後，本節會試着分析其架構設計，希望從其架構設計中獲得一些益處。
先賣個關子，在本節開始之前我們不妨先思考一個有趣的問題：Envoy本身采用C++開發的，普遍認可C++程式執行性能會更好，那麼延伸下來可以想到Envoy的設計目标似乎是在追求高性能，那麼真是如此嗎？
在探究Envoy架構設計之前，我們先來看看Envoy自身是怎麼描述其設計目标的，如下：
Envoy并不是很慢（我們已經花了相當長的時間來優化關鍵路徑）。基于子產品化編碼，易于測試，而不是性能最優。我們的觀點是，在其他語言或者運作效率低很多的系統中，部署和使用Envoy能夠帶來很好的運作效率。
非常有意思的表述，Envoy并沒有把追求極緻性能作為目标，那麼其架構設計會弱化性能這塊嗎？
目前業内公認代理程式性能最好的是Nginx，其采用了per thread one eventloop模型，這種架構被業内普遍借鑒，那麼Envoy呢？我們先看看下面的架構圖：
看到裡面Worker的工作方式是不是很熟悉，會不會有一點點困惑呢？呵呵，沒錯，Envoy也采用了類Nginx的架構，方式是：多線程 + 非阻塞 + 異步IO（Libevent），雖然Envoy沒有把極緻性能作為目标，但不等于沒有追求，隻不過是相對于擴充性而言級别稍微低一點而已。
Envoy的另一特點是支援配置資訊的熱更新，其功能由XDS子產品完成，XDS是個統稱，具體包括ADS（Aggregated Discovery Service）、SDS（
Service Discovery Service）、EDS（
Endpoint Discovery Service）、CDS（
Cluster Discovery Service）、RDS（
Route Discovery Service）、LDS（
Listener Discovery Service）。XDS子產品功能是向Istio的Pilot擷取動态配置資訊，拉取配置方式分為V1與V2版本，V1采用HTTP，V2采用gRPC。
Envoy還支援熱重新開機，即重新開機時可以做到無縫銜接，其基本實作原理是：
- 将統計資訊與鎖放到共享記憶體中。
- 新老程序采用基本的RPC協定使用Unix Domain Socket通訊。
- 新程序啟動并完成所有初始化工作後，向老程序請求監聽套接字的副本。
- 新程序接管套接字後，通知老程序關閉套接字。
- 通知老程序終止自己。
Envoy同樣也支援Lua編寫的Filter，不過與Nginx一樣，都是工作在HTTP層，具體實作原理都一樣，不做贅述了。
到此為止我們看完了上面的架構圖，如果你對其内部實作也有興趣的話，可以看看下面的内部實作類圖：
其内部實作為了靈活性，做了很多抽象封裝，但基本上可以拆分為幾個大的功能子產品，具體如上圖，不再贅述。
Envoy性能談
軟體的世界從來就不存在什麼銀彈，雖然ServiceMesh優勢很明顯，甚至被尊稱為服務間的通訊層，但不可否認的是ServiceMesh的到來确實對應用的性能帶來了損耗，可以從兩個方面看待此問題：
- 資料面闆中Sidecar的加入增加了業務請求的鍊路長度，必然會帶來性能的損耗，由此延伸可知請求轉發性能的高低必然會成為各個Sidecar能否最終勝出的關鍵點之一。
- 控制台采用的是集中式管理，統一負責請求的合法性校驗、流控、遙測資料的收集與統計，而這要求Sidecar每轉發一個請求，都需要與控制台通訊，例如對應到Istio的架構中，這部分工作是由Mixer元件負責，那麼可想而知這裡必然會成為性能瓶頸之一，針對這個問題Istio官方給出了解決方案，即将Mixer的大部分工作下放到Sidecar中，對應到Envoy中就是新增一個MixerFilter來承擔請求校驗、流控、資料收集與統計工作，MixerFilter需要定時與Istio通訊以批量上報資料與拉取最新配置資料。這種方式在Istio之前微網誌的Motan、華為Mesher、唯品會的OSP中已經這麼做了。
本節主要談論Envoy在性能方面的努力及社群在性能方面呼聲較高的一些内容。
Envoy作為Sidecar其提供的核心功能可以簡單總結為以下三點：
- 對業務透明的請求攔截。
- 對攔截請求基于一定規則做校驗、認證、統計、流量排程、路由等。
- 将請求轉發出去，在ServiceMesh中所有的流量出入都要經過Sidecar，即由Sidecar承擔起所有的網絡通訊職責，由此可知請求轉出後的下一個接收方也必然是Sidecar，那麼Sidecar之間通訊協定的高效與否對ServiceMesh整體性能也會産生較大影響。
從上述三點中我們試着分析下性能優化的關鍵點，其中第1、3點是與業務基本無關的，屬于通用型功能，而第2點的性能是與業務複雜度呈現相關性的，比如請求校驗規則的多與少、遙測資料的采集精細度、資料統計的次元多樣性等，是以最有可能提升Sidecar性能的點就是對請求的攔截與Sidecar之間通訊協定的高效性。
針對請求的攔截，目前正常的做法是使用iptables，在部署Sidecar時配置好iptables的攔截規則，當請求來臨後iptables會從規則表中從上至下順序查找比對規則，如果沒遇到比對的規則，就一條一條往下執行，如果遇到比對的規則，那就執行本規則并根據本規則的動作(accept, reject, log等)，決定下一步執行的情況。為了更直覺的展示iptables的執行過程，請看下圖：
了解iptables的基本流程後，不難發現其性能瓶頸主要是兩點：
- 在規則配置較多時，由于其本身順序執行的特性，性能會下滑嚴重。
- 每個request的處理都要經過核心态--->使用者态--->核心态的過程，這其中會帶來資料從核心态拷貝到使用者态的，再拷貝到核心态的性能消耗，單次請求來看這種消耗很少，但是作為流量進出的守門人，可想而知每秒進出的請求量必然是一個很高的數字，其累積的消耗也必然很高，再進一步分析由于網絡中大量資料包的到來，會産生頻繁的硬體中斷、上下文切換，甚至是一個資料包在多個CPU核之間切換處理，這些因素疊加起來會對性能造成更大的損耗。
既然知道了iptables的缺陷，那麼優化手段不外乎從這兩點下手，而Linux社群與Envoy社群也正在計劃對此做優化，具體如下：
- Linux核心社群最近釋出了bpfilter，一個使用Linux BPF提供的高性能網絡過濾核心子產品，計劃用來替代netfilter作為iptables的核心底層實作，實作Linux使用者向BPF過渡的換心手術。
- Envoy社群目前正在推動官方重構其架構，目的是為了支援自定義的network socket實作，當然最終目的是為了添加VPP(Vector Packet Processing)、Cilium擴充支援，無論使用VPP或Cilium都可以實作資料包在純使用者态或者核心态的處理，避免記憶體的來回拷貝、上下文切換，且可以繞過Linux協定棧，以提高封包轉發效率，進而達到提升請求攔截效率的目的。
為什麼規避Linux正常協定處理過程中核心态與使用者态的轉換如此重要呢？就以對我們最直覺的記憶體拷貝為例，正常情況下，一個網絡資料包從網卡到應用程式需要經過如下的過程：資料從網卡通過 DMA 等方式傳到核心開辟的緩沖區，然後從核心空間拷貝到使用者态空間，在 Linux 核心協定棧中，這個耗時操作甚至占到了資料包整個處理流程的 57.1%。為了更直覺的對記憶體拷貝消耗有所了解，畫了一張簡圖，如下：
簡說DPDK
DPDK全稱Intel Data Plane Development Kit，是Intel提供的資料平面開發工具集，為Intel Architecture（IA）處理器架構下使用者空間高效的資料包處理提供庫函數和驅動的支援，它不同于Linux系統以通用性設計為目的，而是專注于網絡應用中資料包的高性能處理，它将資料包處理、記憶體管理、處理器排程等任務轉移到使用者空間完成，而核心僅僅負責部分控制指令的處理。這樣就解決了處理資料包時的系統中斷、上下文切換、系統調用、系統排程等問題。
VPP是the vector packet processor的簡稱，是一套基于DPDK的網絡幀處了解決方案，是一個可擴充架構，提供開箱即用的交換機/路由器功能。是Linux基金會下開源項目FD.io的一個子項目，由思科貢獻的開源版本，目前是FD.io的最核心的項目。
整個DPDK還是非常複雜的，通過一兩篇文章很難說清楚，且本文重點也不在DPDK，是以下面隻簡單介紹下其基本原理，讓我們大緻清楚為什麼Envoy引入VPP後可以大幅提升請求處理轉發效率。
為了說清楚DPDK是如何大幅提升了資料包的處理性能，我們先看一下普通的資料包在Linux中的收發過程，如下圖：
通過上面兩張圖我們可以大緻清楚資料包的一個完整的收發過程，可以看到整個處理鍊路還是比較長的，且需要在核心态與使用者态之間做記憶體拷貝、上下文切換、軟硬體中斷等。雖然Linux設計初衷是以通用性為目的的，但随着Linux在伺服器市場的廣泛應用，其原有的網絡資料包處理方式已很難跟上人們對高性能網絡資料處理能力的訴求。在這種背景下DPDK應運而生，其利用UIO技術，在Driver層直接将資料包導入到使用者态程序，繞過了Linux協定棧，接下來由使用者程序完成所有後續處理，再通過Driver将資料發送出去。原有核心态與使用者态之間的記憶體拷貝采用mmap将使用者記憶體映射到核心，如此就規避了記憶體拷貝、上下文切換、系統調用等問題，然後再利用大頁記憶體、CPU親和性、無鎖隊列、基于輪詢的驅動模式、多核排程充分壓榨機器性能，進而實作高效率的資料包處理。說了這麼多，接下來我們看下在DPDK中資料包的收發過程，如下圖：
通過對比得知，DPDK攔截中斷，不觸發後續中斷流程，并繞過核心協定棧，通過UIO（Userspace I/O）技術将網卡收到的封包拷貝到應用層處理，封包不再經過核心協定棧。減少了中斷，DPDK的包全部在使用者空間使用記憶體池管理，核心空間與使用者空間的記憶體互動不用進行拷貝，隻做控制權轉移，減少封包拷貝過程，提高封包的轉發效率。
DPDK能夠繞過核心協定棧，本質上是得益于 UIO 技術，UIO技術也不是DPDK創立的，是核心提供的一種運作在使用者空間的
I/O技術，
Linux系統中一般的驅動裝置都是運作在
核心空間，在使用者空間用的程式調用即可，UIO則是将
驅動的很少一部分運作在核心空間，絕大多數功能在使用者空間實作，通過 UIO 能夠攔截中斷，并重設中斷回調行為，進而繞過核心協定棧後續的處理流程。
那麼UIO是如何攔截中斷的呢？我們先看看作為一個裝置驅動的兩個主要職責：
- 存取裝置的記憶體。UIO 核心實作了mmap可以處理實體記憶體、邏輯記憶體、虛拟記憶體。UIO驅動的編寫是就不需要再考慮這些繁瑣的細節。
- 處理裝置産生的中斷。裝置中斷的應答是必須在核心空間的，是以UIO隻把非常小的一部分代碼邏輯放在核心，剩餘邏輯全部留給使用者空間程序處理。
UIO的實作機制其實是對使用者空間暴露檔案接口，比如當注冊一個 UIO 裝置 uioX，就會出現檔案 /dev/uioX，對該檔案的讀寫就是對裝置記憶體的讀寫。除此之外，對裝置的控制還可以通過 /sys/class/uio 下的各個檔案的讀寫來完成。UIO架構及流程圖如下，不再贅述。
說完了DPDK，那麼Cilium又是如何提高封包轉發效率呢？既然
Cilium是基于 eBPF 和 XDP 實作的，而XDP歸根結底也是利用eBPF為Linux核心提供高性能、可程式設計的網絡資料路徑架構，既然核心是eBPF，那麼我們先了解下eBPF是什麼。
簡說eBPF與XDP
eBPF（extended Berkeley Packet Filter）起源于BPF，它提供了核心的資料包過濾機制。Linux 3.15 開始引入 eBPF。其擴充了 BPF 的功能，豐富了指令集。它在核心提供了一個虛拟機，使用者态将過濾規則以虛拟機指令的形式傳遞到核心，由核心根據這些指令來過濾網絡資料包。直白地講就是我們可以讓核心按照我們的規則來對資料包進行處理，包括未進入協定棧之前的處理哦，有沒有瞬間覺得eBPF很牛逼，既然都這麼強大了，有沒有什麼最佳實踐或者應用呢？請看下圖：
我們可以看到XDP本身就是一個eBPF的最佳實踐，由于其他内容跟本文檔讨論内容無關，不再展開。作為eBPF是如何工作以提供強大的能力呢？請看下圖：
首先是将使用者的.c檔案編譯後自動生成eBPF 位元組碼檔案，也就是一堆的指令集合，其次通過系統調用将位元組碼注入到核心，然後核心驗證合法性，通過校驗後使用JIT将其run起來，使用者程式與run起來的eBPF程式使用核心提供的标準Maps做資料交換。
與DPDK的記憶體全部在使用者空間來避免記憶體拷貝、上下文切換、系統調用等不同，eBPF都是在核心空間執行的。但兩者的核心都是通過避免資料包在核心态與使用者态之間的往複來提升轉發效率。
說完了eBPF，接下來該XDP粉墨登場了。XDP（eXpress Data Path）為Linux核心提供了高性能、可程式設計的網絡資料路徑。由于網絡包在還未進入網絡協定棧之前就處理，它給Linux網絡帶來了巨大的性能提升（性能比DPDK還要高）。
XDP在Linux核心4.8中引入，在資料包到達協定棧、配置設定sk_buff之前攔截，不同于DPDK的是XDP是作為核心功能的一部分，是與核心協同工作的。其基本處理流程如下圖：
XDP同樣将使用者程式編譯後生成eBPF位元組碼檔案，注入核心執行包過濾。XDP包過濾是在資料包進入核心協定棧之前，如果判斷資料包不需進一步處理可直接在核心态轉發資料包，如果判斷TX裝置來不及處理會直接丢包，如果判斷資料包需再處理則轉給協定棧。
而為什麼會有XDP比DPDK更高效的結論呢？也許通過下面這張圖你可以自己找到答案。
作為資料封包處理的新貴，其帶來的性能優勢是不言而喻，但XDP真的那麼完美嗎？答案一定是否定的，其缺點有二：
- XDP不提供緩存隊列（qdisc），TX裝置太慢時直接丢包，因而不要在RX比TX快的裝置上使用XDP。
- XDP程式是專用的，不具備網絡協定棧的通用性。
聊了那麼多關于eBPF與XDP的内容，其在業界存在最佳實踐嗎？是的，目前facebook開源的katran項目，使用的正是這兩項技術，據稱其從IPVS轉到eBPF後，使其性能提高了10倍。Linux社群中有人用XDP編寫的一個簡單的入口防火牆就可以輕松實作每秒處理1100萬個資料包的性能。
簡說QUIC協定
說完了如何高效的轉發請求，接下來我們聊聊Sidecar之間如何高效的通訊。
提到通訊那就一定要提及通訊協定了，作為我們耳熟能詳的兩大基本通訊協定TCP與UDP的優缺點這裡就不再贅述了，那麼我們是否能整合TCP與UDP兩者的優點呢，這樣既保證了TCP的可靠與安全性，又兼具UDP的速度與效率，不可否認的是往往正是出于人們對美好事物的向往，才持續不斷的推動我們前進的腳本。QUIC在這種期許下誕生，旨在建立幾乎等同于TCP的獨立連接配接，但有着低延遲，并對類似SPDY的多路複用流協定有更好的支援。
QUIC協定本身就内置TLS棧，實作自己的
傳輸加密層，而沒有使用現有的TLS 1.2。同時QUIC還包含了部分HTTP/2的實作，是以QUIC的地位看起來是這樣的：
QUIC協定的誕生就是為了降低網絡延遲，開創性的使用了UDP協定作為底層傳輸協定，通過多種方式減少了網絡延遲。是以帶來了性能的極大提升，且具體的提升效果在Google旗下的YouTube已經驗證。
既然QUIC協定相比現有其他的協定更具優勢 ，那是否也可以将其應用到Envoy中呢？Envoy社群正在推動官方重構其架構的目的之一就是為了QUIC，最終目的是希望使用QUIC作為Sidecar之間的通訊協定。
試想一下如果Envoy應用了上述技術，性能會有怎樣的提升呢？這個就留給各位看官自行腦補吧。
讀到這裡不知各位是否會産生這樣的疑問，目前作為ServiceMesh中資料面闆的Sidecar有好幾個，為什麼隻有Envoy社群在性能方面呼聲最高呢？這就牽扯到一個老掉牙的話題了，因為Envoy是C系語言編寫的，在應用OS特性時有着先天優勢。
雜談
上節内容提到目前有與Envoy同類的幾個程式，包括Linkerd、Conduit、NginMesh，下面就以個人所知簡單描述下各自的特點，僅供諸位參考。
就個人而言，其實挺希望Conduit的壯大，正如其設計初衷說的那樣：輕量化，相比Istio這種重部署模式來講，非常适合小規模業務的快速上手，且Conduit與Linkerd系出同門，足以保證其設計理念的先進性，雖然Buoyant公司宣稱Conduit與Linkerd的目标不同，但細想下來未嘗Buoyant公司沒有存在一絲不甘，希望推出一個完整的Service Mesh方案來颠覆Istio一家獨大的局面，奪回Service Mesh開創者的殊榮。
下面是各自的特性簡述。
NginMesh：
- Golang實作。
- Sidecar實作模式：agent + nginx，agent負責監聽Istio的配置變化（例如路由規則、叢集資訊、服務發現等），并将其轉換為nginx的配置，然後通過重新開機nginx應用配置。
- 與istio、k8s強綁定，使用k8s的Initializer機制實作sidecar的自動注入。
- 目前尚未在生産環境驗證。
- 雖然nginx也可以使用ngixscript/lua進行擴充，但大多局限于http處理上，對于L3L4的過濾上就無能無力了。
- 部署圖如下：
淺談Service Mesh體系中的Envoy
NginMesh給人的感覺更多的像是做了一個Istio的橋接器，隻負責把Istio的配置資訊翻譯成Nginx所知的，通過重新開機Nginx的方式應用配置。給我的感覺僅僅是為了搭上ServiceMesh的順風車而臨時推出的一個方案。
Linkerd：
- Scala語言開發，運作在Java虛拟機上，“Service Mesh”概念的締造者，經生産環境驗證可靠的。
- 建構基于Netty、Finagle上，工作于RPC層。
- 插入式的服務發現，例如File-based、Zookeeper、k8s。
- 由于工作在RPC層，可根據實時觀測到的RPC延遲、要處理請求隊列大小決定如何分發請求，優于傳統啟發式負責均衡算法，例如LRU、TCP活動請求等。
- 提供多種負載均衡算法如：Power of Two Choices (P2C): Least Loaded、Power of Two Choices: Peak EWMA、Aperture: Least Loaded、Heap: Least Loaded以及Round-Robin。
- 資料流程圖如下：
淺談Service Mesh體系中的Envoy
作為“Service Mesh”概念的締造者、布道者，最終卻在Service Mesh的大潮中，被由Google、IBM、Lft聯手打造的Istio + Envoy打敗，不得不感歎巨頭的強大與初創公司的弱小與艱辛，由衷的希望看到Conduit的崛起，逆殺Istio。話說這是不是典型的弱者心态啊，哈哈。
Conduit：
- 脫胎于Linkerd，針對Linkerd部署模型太重的問題，其秉承的設計目标是成為最快、最輕、最簡單的Service Mesh，使用Rust建構資料平面，使用Go建構控制平面。與Linkerd同出Buoyant公司。
- 不同于Envoy、Linkerd是資料平面，Istio是控制平面，Conduit中既包括資料平面，也包括控制平面，控制平面提供API，使用者通過Conduit CLI與Web UI使用。
- 隻能運作在K8s上。
- 目前釋出了0.3版本，仍然處于初期開發階段。
- 對經過Conduit proxy的流量，産生一系列的監控名額，名額格式是Prometheus的，内容存放在proxy監控端口的metrics路徑下面，Prometheus可以直接抓取名額内容，做聚合展示。
- 利用Rust本身的語言安全特性來保證自身的安全性。
誠邀您關注阿裡中間件微信公衆号！
我們懂您的胃口：定期分享最前沿技術幹貨！
我們懂您的喜好：大量精品大會、沙龍、比賽為您量身定做！
我們懂您的情調：海量驚喜獎品随時放送！
你還不來加入我們嗎？就現在！最in的程式圈子，由您創造！
淺談Service Mesh體系中的Envoy