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

阿里巴巴中介軟體發表於2019-01-02

從微服務治理的角度看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,. Envoy和. Istio

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上有著豐富的實踐和開發經驗。


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

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

相關文章