從微服務治理的角度看RSocket,. Envoy和. Istio

不少同窗看到這個題目，必定會提這樣的問題：RSocket是個協議，Envoy是一個 proxy，Istio是service mesh control plane + data plane。 這三種技術怎麼能放在一塊兒比較呢？

的確，從技術定位的角度來說，它們確實是有很大的差距。可是，若是咱們用RSocket來治理微服務，會有哪些不一樣呢？

RSocket

RSocket是一種應用層協議，不是一個傳輸層的協議。一方面，它能夠包容和支持不一樣的傳輸層協議和相關技術，好比tcp 和 proto buf。另外一方面，它的重點是把反應流的實現，提高到應用層上來。

其實在底層的協議中，就有反應流的實現，tcp的滑動窗口就是很好的例子。可是往上，這種好的機制不見了，給編程的工做形成不少的麻煩。很大一部分的線上故障是因爲阻塞連接形成的。另外一方面，不少應用層的網絡軟件，從設計的時候就開始避免這樣的麻煩，形成結構臃腫，通信效率底下。簡單的例子是若是全部的通信都是反應式的，那就不用熔斷了。

基於RSocket 的應用不止是端到端通信，Broker也是對這個協議水到渠成的應用。做爲一個反應式的Broker，它一樣是異步，非阻塞的通信方式，主要維護與就近的各個應用的連接以及和其它Broker的連接。與其它協議相比，它是多路複用，同時支持長連接。

通過這樣的解釋，不難理解，本文主要是針對RSocket應用經過RSocket Broker聯結而造成的Mesh，與其它Service Mesh項目在不一樣層次和方面的對比。

RSocket vs .Envoy

Envoy做爲一個proxy，它主要是基於HTTP2/HTTP1.1的協議，固然這樣作是符合市場的口味，可是這個協議的侷限性也限制了Envoy的性能。這就是咱們比較的第一點，

1. Envoy不支持多路複用，非阻塞和有限支持長連接。說是有限，其實就是不支持，由於你的連接只要不能一直開着，就得依靠第三方作health check。這絕對增長開發難度。不支持多路複用，就沒法對每一個服務都開個連接，那麼就要靠第三方做service registry。 這樣的限制，不但使得Envoy必須依靠一個control plane,本身沒法獨立擔負weave mesh的重擔，並且也大大限制了它的性能，好比新版本Istio Proxy（就是Envoy）用的聯接池管理就佔了不少的內存。

2. RSocket的主要障礙是應用程序之間必需要用RSocket通信。隨着Spring Cloud的推出，Spring Framework 5.2 即將要把RSocket做爲缺省的反應通信協議，以及Dubbo和RSocket 的整合，你們接觸RSocket的機會也會愈來愈多。

3. 不少場合中會聽到Envoy支持Polygoat,好像用了Envoy就不用SDK了。這種說法顯然是錯覺。SDK是必定要的，爲了支持Polygoat，就要選多語言支持的SDK。由於調用另外一個服務的代碼仍是發生在本身的程序中，這不是Envoy能夠替代的。Envoy所說的省卻SDK開發，是指所謂的「胖SDK」， 就是包括了服務發現和路由功能的SDK，相似你們如今用的Dubbo，那的確是會讓SDK瘦身的。可是若是用了RSocket的Broker，這些SDK一樣也不用再「胖」了，並且RSocket協議也有不一樣語言的SDK。

RSocket vs .Istion

除了上述的簡化和高效等特性外，相比Istio，RSocket Broker 有一個主要的優點，那就是不依賴Kubernets 。雖然Istio也號稱不依賴Kubernets，可是在Kubernets外部署和管理sidecar proxy可不是一件容易的事，而RSocket Broker倒是哪裏都能部署。

做爲一個Service Mesh solution, Istio實際上是很難在 data center外應用的。那麼對於衆多的IoT設備怎麼辦？每一臺手機上裝個sidecar？而RSocket是很小且高效的SDK，這也是像Facebook這樣的主要手機應用商選擇RSocket的緣由。

Istio主打的特性是observability, security and control。從observability和control方面來講，RSocket Broker雖然有接口，可是實現還不夠，特別是API的部分。這也是社區要努力的一個方向。從security來講，若是是單純RSocket的服務是不用開端口的，這是又一項由先進協議帶來的對特性的簡化，之後會有更多的介紹。

結論

很早之前，在分佈程序中訪問另外一個服務是很直觀，透明的事。微服務普及後，其爲了「簡化」微服務之間的通信，引入了不少層的技術棧。這固然是好事，可是不少的決定是因爲收到上一代的通信協議的技術所限制。

RSocket的反應流技術，簡化了程序間通信對其它部件的依賴。咱們能夠享受Service Mesh提供的便利而不用那麼複雜的技術棧。固然RSocket帶來的好處不僅是簡單。在咱們的初步實驗中，RSocket Broker的service mesh比Istio帶來將近10倍的速度提高。若是你們有興趣，能夠去了解一下RSocket。

Andy Shi：阿里巴巴中間件硅谷團隊 Istio 技術專家，Andy長期關注Service Mesh，在Cloud Foundry，Kubernetes，Envoy上有着豐富的實踐和開發經驗。

---

阿里巴巴中間件官方微博 ※一個集乾貨與前衛的技術號