1樓：小烏龜
http慢在哪，不就多了幾十位元組的頭嗎，你自己設計協議頂多讓頭變成幾個位元組，但這種差別你要看什麼樣的資料內容，如果互動的都是幾個位元組的實時控制資料，http就嫌太重了，但一般都是幾k到幾十上百k的資料，幾十個位元組的頭影響不大，除非追求極限效能
2樓：師太慢走老衲來了
不慢如果你用feign 預設給你加了keepalive 也是長鏈結就多了http的20位元組報文頭，但是開發效率卻提公升了幾個檔次，孰優孰劣一目了然啊
3樓：巴喬
FEIGN是走HTTP的，即使利用介面特性做成類RPC的方式，但也還是走HTTP的。但是就我使用感受，速度還行，比想象中要快。rpc固然速度比http快，但是你要考慮的穩定性、資料傳輸的可靠性、熔斷保護，以及更方便的鏈路監控和追蹤，這時候HTTP的優勢就體現了。
Spring cloud的http從幾個方面可以優化：1、換成okhttp3。2、應用中不要做非同步傳輸，防止非同步等待，如果遇到非同步場景，一定要利用好訊息佇列和快取。
3、如果http1.1，有些場景利用keep-alive，減少連線損耗。4、可以考慮嘗試HTTP/2。
4樓：高天星
弱答一下，供參考。
還是先看你的業務場景和需求，真的對於響應和高併發有特殊要求才去考慮框架方面的差異。選擇框架我覺得主要還是看社群、文件、整體成熟度以及團隊已有經驗等等方面。我覺得一般場景下spring cloud的效能足以滿足大多數需求。
最終還是要看你的服務拆分合理不合理和業務場景的實際需求。
附：孰優孰劣？Dubbo VS Spring Cloud效能測試大對決！
電商，Spring Cloud架構，微服務之間耦合過多的問題如何解決？
倚天碼農 你講了了兩個問題。乙個是高度耦合 程式架構和設計 另乙個是http的呼叫效率。這兩個問題的解決方案一般情況下是互相矛盾的。要想解決高度耦合，就需要優雅的設計，但一般效率都不高。要想提高效率，就要使用一些特殊的設計和手段，這必然使程式設計很難看。我們先來看高度耦合 程式架構和設計 模組拆分之...
Spring Cloud架構的各個元件的原理分析
已登出 當時準備考北林於是看到了這個知乎，現在考入北林了覺得評價的不真實啊。七人間，桌子衣櫃我覺得都夠啊。暖氣空調也很給力每層樓的公共廁所真的很乾淨，每天都有人早中晚打掃。北方宿舍普遍較差。北林算是北京比較好的了，對比了高中同學現在的情況。的確如此。 他的大王 更新一下吧 即將讀研究生，暑假住臨時宿...
SpringCloud專案的前端用什麼技術？可以和SSM的前端是一樣的嗎？
HandsomJin 看到是新手提問，不知道理解的對不對，如果是想問能用什麼的話，是都可以。SpringCloud是微服務框架，主要解決後端服務設計問題，本身和前端沒啥關係。無論前端用啥Js還是Android還是什麼其他的都無所謂。 陳龍 Spring Cloud專案的前端用AJAX和Gateway...