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

成都創(chuàng)新互聯(lián)是一家專業(yè)提供尖草坪企業(yè)網(wǎng)站建設(shè),專注與成都網(wǎng)站制作、成都網(wǎng)站建設(shè)、外貿(mào)營銷網(wǎng)站建設(shè)、H5頁面制作、小程序制作等業(yè)務(wù)。10年已為尖草坪眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)站建設(shè)公司優(yōu)惠進(jìn)行中。

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

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

RSocket 

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

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

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

RSocket vs .Envoy

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

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

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

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

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

RSocket vs .Istion

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

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

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

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

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

看完上述內(nèi)容是否對您有幫助呢？如果還想對相關(guān)知識有進(jìn)一步的了解或閱讀更多相關(guān)文章，請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝您對創(chuàng)新互聯(lián)的支持。

新聞名稱：如何從微服務(wù)治理的角度看RSocket、.Envoy和.Istio
文章分享：http://www.rwnh.cn/article16/jeeogg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供搜索引擎優(yōu)化、服務(wù)器托管、用戶體驗(yàn)、網(wǎng)站改版、云服務(wù)器、營銷型網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)