共計(jì) 2271 個(gè)字符，預(yù)計(jì)需要花費(fèi) 6 分鐘才能閱讀完成。

如何從微服務(wù)治理的角度看 RSocket、. Envoy 和. Istio，很多新手對(duì)此不是很清楚，為了幫助大家解決這個(gè)難題，下面丸趣 TV 小編將為大家詳細(xì)講解，有這方面需求的人可以來學(xué)習(xí)下，希望你能有所收獲。

很多同學(xué)看到這個(gè)題目，一定會(huì)提這樣的問題：RSocket 是個(gè)協(xié)議，Envoy 是一個(gè) proxy，Istio 是 service mesh control plane + data plane。這三種技術(shù)怎么能放在一起比較呢？

的確，從技術(shù)定位的角度來講，它們確實(shí)是有很大的差距。但是，如果我們用 RSocket 來治理微服務(wù)，會(huì)有哪些不同呢？

RSocket 

RSocket 是一種應(yīng)用層協(xié)議，不是一個(gè)傳輸層的協(xié)議。一方面，它可以包容和支持不同的傳輸層協(xié)議和相關(guān)技術(shù)，比如 tcp 和 proto buf。另一方面，它的重點(diǎn)是把反應(yīng)流的實(shí)現(xiàn)，提升到應(yīng)用層上來。

其實(shí)在底層的協(xié)議中，就有反應(yīng)流的實(shí)現(xiàn)，tcp 的滑動(dòng)窗口就是很好的例子。但是往上，這種好的機(jī)制不見了，給編程的工作造成很多的麻煩。很大一部分的線上故障是由于阻塞鏈接造成的。另一方面，很多應(yīng)用層的網(wǎng)絡(luò)軟件，從設(shè)計(jì)的時(shí)候就開始避免這樣的麻煩，造成結(jié)構(gòu)臃腫，通訊效率底下。簡單的例子是如果所有的通訊都是反應(yīng)式的，那就不用熔斷了。

基于 RSocket 的應(yīng)用不止是端到端通訊，Broker 也是對(duì)這個(gè)協(xié)議水到渠成的應(yīng)用。作為一個(gè)反應(yīng)式的 Broker，它同樣是異步，非阻塞的通訊方式，主要維護(hù)與就近的各個(gè)應(yīng)用的鏈接以及和其它 Broker 的鏈接。與其它協(xié)議相比，它是多路復(fù)用，同時(shí)支持長鏈接。

經(jīng)過這樣的解釋，不難理解，本文主要是針對(duì) RSocket 應(yīng)用通過 RSocket Broker 聯(lián)結(jié)而形成的 Mesh，與其它 Service Mesh 項(xiàng)目在不同層次和方面的對(duì)比。

RSocket vs .Envoy

Envoy 作為一個(gè) proxy，它主要是基于 HTTP2/HTTP1.1 的協(xié)議，當(dāng)然這樣做是符合市場的口味，但是這個(gè)協(xié)議的局限性也限制了 Envoy 的性能。這就是我們比較的第一點(diǎn)，

1. Envoy 不支持多路復(fù)用，非阻塞和有限支持長鏈接。說是有限，其實(shí)就是不支持，因?yàn)槟愕逆溄又灰荒芤恢遍_著，就得依靠第三方做 health check。這絕對(duì)增加開發(fā)難度。不支持多路復(fù)用，就無法對(duì)每個(gè)服務(wù)都開個(gè)鏈接，那么就要靠第三方作 service registry。

這樣的限制，不但使得 Envoy 必須依靠一個(gè) control plane, 自己無法獨(dú)立擔(dān)負(fù) weave mesh 的重?fù)?dān)，而且也大大限制了它的性能，比如新版本 Istio Proxy（就是 Envoy）用的聯(lián)接池管理就占了很多的內(nèi)存。

而對(duì)于 RSocket 來說，
2. RSocket 的主要障礙是應(yīng)用程序之間必須要用 RSocket 通訊。隨著 Spring Cloud 的推出，Spring Framework 5.2 即將要把 RSocket 作為缺省的反應(yīng)通訊協(xié)議，以及 Dubbo 和 RSocket 的整合，大家接觸 RSocket 的機(jī)會(huì)也會(huì)越來越多。

另外，
3. 很多場合中會(huì)聽到 Envoy 支持 Polygoat, 好像用了 Envoy 就不用 SDK 了。這種說法顯然是錯(cuò)覺。SDK 是一定要的，為了支持 Polygoat，就要選多語言支持的 SDK。因?yàn)檎{(diào)用另一個(gè)服務(wù)的代碼還是發(fā)生在自己的程序中，這不是 Envoy 可以替代的。Envoy 所說的省卻 SDK 開發(fā)，是指所謂的“胖 SDK”，就是包括了服務(wù)發(fā)現(xiàn)和路由功能的 SDK，類似大家現(xiàn)在用的 Dubbo，那的確是會(huì)讓 SDK 瘦身的。但是如果用了 RSocket 的 Broker，這些 SDK 同樣也不用再“胖”了，而且 RSocket 協(xié)議也有不同語言的 SDK。

RSocket vs .Istion

除了上述的簡化和高效等特性外，相比 Istio，RSocket Broker  有一個(gè)主要的優(yōu)勢(shì)，那就是不依賴 Kubernets。雖然 Istio 也號(hào)稱不依賴 Kubernets，但是在 Kubernets 外部署和管理 sidecar proxy 可不是一件容易的事，而 RSocket Broker 卻是哪里都能部署。

作為一個(gè) Service Mesh solution, Istio 其實(shí)是很難在 data center 外應(yīng)用的。那么對(duì)于眾多的 IoT 設(shè)備怎么辦？每一臺(tái)手機(jī)上裝個(gè) sidecar？而 RSocket 是很小且高效的 SDK，這也是像 Facebook 這樣的主要手機(jī)應(yīng)用商選擇 RSocket 的原因。

Istio 主打的特性是 observability, security and control。從 observability 和 control 方面來說，RSocket Broker 雖然有接口，但是實(shí)現(xiàn)還不夠，特別是 API 的部分。這也是社區(qū)要努力的一個(gè)方向。從 security 來說，如果是單純 RSocket 的服務(wù)是不用開端口的，這是又一項(xiàng)由先進(jìn)協(xié)議帶來的對(duì)特性的簡化，以后會(huì)有更多的介紹。

很早以前，在分布程序中訪問另一個(gè)服務(wù)是很直觀，透明的事。微服務(wù)普及后，其為了“簡化”微服務(wù)之間的通訊，引入了很多層的技術(shù)棧。這當(dāng)然是好事，但是很多的決定是由于收到上一代的通訊協(xié)議的技術(shù)所限制。

RSocket 的反應(yīng)流技術(shù)，簡化了程序間通訊對(duì)其它部件的依賴。我們可以享受 Service Mesh 提供的便利而不用那么復(fù)雜的技術(shù)棧。當(dāng)然 RSocket 帶來的好處不只是簡單。在我們的初步實(shí)驗(yàn)中，RSocket Broker 的 service mesh 比 Istio 帶來將近 10 倍的速度提升。

看完上述內(nèi)容是否對(duì)您有幫助呢？如果還想對(duì)相關(guān)知識(shí)有進(jìn)一步的了解或閱讀更多相關(guān)文章，請(qǐng)關(guān)注丸趣 TV 行業(yè)資訊頻道，感謝您對(duì)丸趣 TV 的支持。