springcloud是rpc框架嗎？nacos是rpc框架嗎

大家好，今天來為大家解答springcloud是rpc框架嗎這個問題的一些問題點，包括nacos是rpc框架嗎也一樣很多人還不知道，因此呢，今天就來為大家分析分析，現(xiàn)在讓我們一起來看看吧！如果解決了您的問題，還望您關(guān)注下本站哦，謝謝~

spring cloud和dubbo哪個會被淘汰

事實上，很多系統(tǒng)根本就沒必要用什么所謂微服務(wù)。目前過度設(shè)計已經(jīng)泛濫，明明是一個用戶數(shù)量有限，功能并不復(fù)雜的系統(tǒng)，也要套用所謂的微服務(wù)架構(gòu)，或者要大搞所謂中臺，既浪費時間，又浪費金錢，最后系統(tǒng)運維還比較復(fù)雜，需要持續(xù)投入運維。

以服務(wù)調(diào)用的方式，固然可以有更好的復(fù)用性，也可以解耦復(fù)雜系統(tǒng)。但實際上，我認(rèn)為微服務(wù)也僅僅是組件化的一種實現(xiàn)方式。對于組件化，廣義的講，有多種實現(xiàn)方式：

第一種，最原始的方式就是以靜態(tài)函數(shù)庫或者包的形式存在。這種形式優(yōu)點是開發(fā)方式簡單，調(diào)用效率高，數(shù)據(jù)以參數(shù)方式進(jìn)行傳遞，但耦合度也高，底層組件函數(shù)一旦發(fā)生變化，則需要重新編譯整個工程。通常對于不經(jīng)常發(fā)生變化的基礎(chǔ)函數(shù)庫，可以用這種形式進(jìn)行開發(fā)，形成所謂的公共函數(shù)庫，供大家使用。

第二種，稱之為動態(tài)函數(shù)庫，在windows環(huán)境下以dll形式存在，linux環(huán)境下以so形式存在。動態(tài)函數(shù)庫相對于靜態(tài)函數(shù)庫，優(yōu)勢在于可以在運行時動態(tài)加載，可以在不用重新啟動整個應(yīng)用的情況下進(jìn)行更新。缺點是動態(tài)函數(shù)不能共享原應(yīng)用程序的存儲空間，導(dǎo)致動態(tài)函數(shù)調(diào)用有時需要傳遞大量參數(shù)，導(dǎo)致一些不便。動態(tài)函數(shù)庫也具有一定耦合度，函數(shù)名和參數(shù)必須嚴(yán)格按照約定調(diào)用，否則會報錯。在早期單體架構(gòu)下，動態(tài)函數(shù)庫還是有大量使用的。

第三種，就是目前所謂的微服務(wù)架構(gòu)了。微服務(wù)事實上也是可以看作是一種函數(shù)調(diào)用方式，提供基于RPC和restful遠(yuǎn)程調(diào)用方式。調(diào)用時需要傳遞調(diào)用的服務(wù)名稱及數(shù)據(jù)報文。這種方式耦合度自然是比較低一些的，但是調(diào)用效率肯定低于函數(shù)調(diào)用方式，主要是數(shù)據(jù)傳輸和報文解析方面消耗的時間。此外還需要考慮通訊流量控制，超時機(jī)制，服務(wù)尋址，服務(wù)可用性等方面的問題。因而降低耦合度，事實上是以增加了系統(tǒng)的整體復(fù)雜度和降低調(diào)用效率為代價的。個人認(rèn)為不應(yīng)該過度解耦，或者僅僅強(qiáng)調(diào)可復(fù)用性。要知道，任何事情都是有代價的，必須要充分評估這種代價是否值得。

第四種，就更進(jìn)一步，即以獨立的系統(tǒng)存在，該系統(tǒng)具有獨立性和完備性，可以不過于依賴其他外部系統(tǒng)獨立運行，對外部以服務(wù)或api的形式進(jìn)行交互。例如，單點登錄系統(tǒng)，信貸系統(tǒng)，核心系統(tǒng)等。

因而，在系統(tǒng)架構(gòu)設(shè)計和建設(shè)過程中，必須認(rèn)真進(jìn)行評估，不應(yīng)該過分側(cè)重于某一方面特性的實現(xiàn)，否則就是過猶不及，最后導(dǎo)致整體出現(xiàn)問題。

個人認(rèn)為，目前大部分所謂基于微服務(wù)的中臺系統(tǒng)就是陷入了過于強(qiáng)調(diào)解耦的誤區(qū)，導(dǎo)致過度的解耦設(shè)計，而忽略了由此帶來的弊端，最后陷入了泥潭。

當(dāng)前主流的RPC框架有哪些

不知道題主說的是不是Java中的PRC框架。下面小冷就說下Java中的集中常見的RPC框架，RPC呢是遠(yuǎn)程過程調(diào)用框架，也就是說兩臺服務(wù)器A,B,一個應(yīng)用部署在A服務(wù)器上，另一個應(yīng)用部署在B服務(wù)器上，A服務(wù)器上的應(yīng)用想要調(diào)用B服務(wù)器上的應(yīng)用提供的方法/函數(shù)，由于不在一個內(nèi)存空間，不能直接調(diào)用，需要通過網(wǎng)絡(luò)來表達(dá)調(diào)用的語意和傳遞調(diào)用的參數(shù)。提供這種服務(wù)的框架我們就叫他RPC框架，RPC是遠(yuǎn)程過程調(diào)用的簡稱，廣泛應(yīng)用在大規(guī)模分布式應(yīng)用中，作用是有助于系統(tǒng)的垂直拆分，使系統(tǒng)更易拓展。Java中的RPC框架比較多，各有特色，廣泛使用的有Hessian、CXF、Dubbo、Dubbox、SpringCloud、gRPC、thrift等。RPC最顯著的特點就是能夠跨語言，多端調(diào)用。我記得收藏的有一篇博客就是寫RPC的，下面我們對比一下以上RPC框架功能比較：

下面是實際應(yīng)用場景中的選擇：

SpringCloud：Spring全家桶，用起來很舒服，只有你想不到，沒有它做不到。可惜因為發(fā)布的比較晚，國內(nèi)還沒出現(xiàn)比較成功的案例，大部分都是試水，不過畢竟有Spring作背書，還是比較看好。

Dubbox：相對于Dubbo支持了REST，估計是很多公司選擇Dubbox的一個重要原因之一，但如果使用Dubbo的RPC調(diào)用方式，服務(wù)間仍然會存在API強(qiáng)依賴，各有利弊，懂的取舍吧。

Thrift：如果你比較高冷，完全可以基于Thrift自己搞一套抽象的自定義框架吧。

Montan：可能因為出來的比較晚，目前除了新浪微博16年初發(fā)布的，

Hessian：如果是初創(chuàng)公司或系統(tǒng)數(shù)量還沒有超過5個，推薦選擇這個，畢竟在開發(fā)速度、運維成本、上手難度等都是比較輕量、簡單的，即使在以后遷移至SOA，也是無縫遷移。

rpcx/gRPC：在服務(wù)沒有出現(xiàn)嚴(yán)重性能的問題下，或技術(shù)棧沒有變更的情況下，可能一直不會引入，即使引入也只是小部分模塊優(yōu)化使用。

至于項目中用那種rpc框架，這個還是根據(jù)項目類型來好一點，如果是一個小型項目的話就沒有必要使用，如果是一個中大型的項目的話這個用那種要考慮好，后期更換的話比較麻煩。

從使用場景和功能比較，相信題主對常用的JavaRPC框架有一定了解了吧，希望對你有所幫助！

我是小冷，一個剛開始創(chuàng)組的小白，希望大家關(guān)注、點贊、評論、轉(zhuǎn)發(fā)！

既然有http請求，為什么還要用rpc調(diào)用

首先http和rpc并不是一個并行概念。

rpc是遠(yuǎn)端過程調(diào)用，其調(diào)用協(xié)議通常包含傳輸協(xié)議和序列化協(xié)議。

傳輸協(xié)議包含:如著名的[gRPC](grpc/grpc.io)使用的http2協(xié)議，也有如dubbo一類的自定義報文的tcp協(xié)議。

序列化協(xié)議包含:如基于文本編碼的xmljson，也有二進(jìn)制編碼的protobufhessian等。

因此我理解的你想問的問題應(yīng)該是：為什么要使用自定義tcp協(xié)議的rpc做后端進(jìn)程通信？

要解決這個問題就應(yīng)該搞清楚http使用的tcp協(xié)議，和我們自定義的tcp協(xié)議在報文上的區(qū)別。

首先要否認(rèn)一點http協(xié)議相較于自定義tcp報文協(xié)議，增加的開銷在于連接的建立與斷開。http協(xié)議是支持連接池復(fù)用的，也就是建立一定數(shù)量的連接不斷開，并不會頻繁的創(chuàng)建和銷毀連接。二一要說的是http也可以使用protobuf這種二進(jìn)制編碼協(xié)議對內(nèi)容進(jìn)行編碼，因此二者最大的區(qū)別還是在傳輸協(xié)議上。

HTTP有用信息占比少，畢竟HTTP工作在第七層，包含了大量的HTTP頭等信息。其次是效率低，還是因為第七層的緣故。還有，其可讀性似乎沒有必要，因為我們可以引入網(wǎng)關(guān)增加可讀性。此外，使用HTTP協(xié)議調(diào)用遠(yuǎn)程方法比較復(fù)雜，要封裝各種參數(shù)名和參數(shù)值。

通用定義的http1.1協(xié)議的tcp報文包含太多廢信息，一個POST協(xié)議的格式大致如下：

HTTP/1.0200OK

Content-Type:text/plain

Content-Length:137582

Expires:Thu,05Dec199716:00:00GMT

Last-Modified:Wed,5August199615:55:28GMT

Server:Apache0.84

<html>

<body>HelloWorld</body>

</html>

即使編碼協(xié)議也就是body是使用二進(jìn)制編碼協(xié)議，報文元數(shù)據(jù)也就是header頭的鍵值對卻用了文本編碼，非常占字節(jié)數(shù)。如上圖所使用的報文中有效字節(jié)數(shù)僅僅占約30%，也就是70%的時間用于傳輸元數(shù)據(jù)廢編碼。當(dāng)然實際情況下報文內(nèi)容可能會比這個長，但是報頭所占的比例也是非常可觀的。

那么假如我們使用自定義tcp協(xié)議的報文如下：

報頭占用的字節(jié)數(shù)也就只有16個byte，極大地精簡了傳輸內(nèi)容，采用自定義tcp協(xié)議的rpc來進(jìn)行通信減少了通訊內(nèi)容，可以提高通訊效率。

所謂的效率優(yōu)勢是針對http1.1協(xié)議來講的，http2.0協(xié)議已經(jīng)優(yōu)化編碼效率問題，像grpc這種rpc庫使用的就是http2.0協(xié)議。這么來說吧http容器的性能測試單位通常是kqps，自定義tpc協(xié)議則通常是以10kqps到100kqps為基準(zhǔn)

簡單來說成熟的rpc庫相對http容器，更多的是封裝了“服務(wù)發(fā)現(xiàn)”，"負(fù)載均衡"，“熔斷降級”一類面向服務(wù)的高級特性。可以這么理解，rpc框架是面向服務(wù)的更高級的封裝。如果把一個httpservlet容器上封裝一層服務(wù)發(fā)現(xiàn)和函數(shù)代理調(diào)用，那它就已經(jīng)可以做一個rpc框架了。

所以為什么要用rpc調(diào)用？因為良好的rpc調(diào)用是面向服務(wù)的封裝，針對服務(wù)的可用性和效率等都做了優(yōu)化。單純使用http調(diào)用則缺少了這些特性。