很多同學看到這個題目，一定會提這樣的問題：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上有着豐富的實踐和開發經驗。