微服務調(diào)用為啥用RPC框架，http不更簡單嗎？簡單一點，HTTP是協(xié)議，RPC是概念！RPC可以基于HTTP協(xié)議（feign）、TCP協(xié)議（netty）、RMI協(xié)議（soap）和web服務（XML-

微服務調(diào)用為啥用RPC框架，http不更簡單嗎？

簡單一點，HTTP是協(xié)議，RPC是概念！RPC可以基于HTTP協(xié)議（feign）、TCP協(xié)議（netty）、RMI協(xié)議（soap）和web服務（XML-RPC）框架實現(xiàn)。在傳輸過程中，由于序列化方法的不同，也出現(xiàn)了一些框架和協(xié)議，如Dubbo中的Dubbo協(xié)議、grpc protobuf序列化協(xié)議等。實際上，它們都是基于遠程調(diào)用的概念。什么是遠程呼叫？

關(guān)鍵是RPC是遠程調(diào)用。遠程調(diào)用是客戶端通過上述協(xié)議向服務器發(fā)送接口、參數(shù)、參數(shù)類型、方法、返回值、返回值類型等（稱為方法簽名），通知服務器要調(diào)用的接口方法。這個過程就是RPC的實現(xiàn)過程！HTTP和RPC是兩碼事

！在性能方面，HTTP本身是基于TCP協(xié)議的，屬于應用層協(xié)議，所以HTTP協(xié)議本身在實現(xiàn)過程中會占用大量的資源（內(nèi)存、帶寬等）。在性能方面，它肯定不如直接通過TCP實現(xiàn)的RPC協(xié)議快。不管HTTP有多優(yōu)化，它絕對沒有TCP那么快！另一方面，TCP依賴于字節(jié)碼。目前常用的是將客戶端調(diào)用的接口信息以序列化的方式發(fā)送到服務器端。序列化框架包括許多內(nèi)容（Hession、protobuf、kryo等）。Kryo具有最高的序列化性能，protobuf具有序列化后最小的字節(jié)碼）。序列化后的字節(jié)碼越小，占用的帶寬越小，序列化時間越長，線程IO延遲越短，線程IO延遲越小。因此，在具體的應用層，有很多技術(shù)可以討論。您可以根據(jù)自己的硬件能力選擇相應的技術(shù)

！歡迎熱愛科技的人們來探索

系統(tǒng)軟件架構(gòu)中，現(xiàn)在很流行微服務，那么使用微服務就一定好么？微服務有哪些缺點呢？

軟件的主要話題應該聽說過“沒有銀彈”吧？如果有一個軟件可以解決所有的問題，為什么有這么多的軟件開發(fā)人員？如果有人說是，他們要么沒有在軟件行業(yè)工作，要么在做廣告。

“微服務”不是萬能的，它不能解決所有的問題，它有自己的適應場景。我大致總結(jié)了以下幾種場景：

相對而言，簡單的業(yè)務需要快速實施，不適合微服務，后期的維護成本遠遠大于成本。

例如，大型超市有多個收銀機，而小型超市也有多個收銀機。營業(yè)額不足以支付員工的工資。

事實上，我對微服務的理解是，它們是特定于功能的，易于升級和擴展。微服務具有分而治之的思想。

2. Vue和python是集成的，前端和后端可以通過HTTP進行交互分離，Vue通過HTTP請求，python提供服務。這是前后端分離的雛形。

3. 第三代微服務是通過集裝箱化設計的。打電話給對方。

微服務怎么實現(xiàn)？是前端還是后端的事？

您需要自己考慮這個問題。關(guān)鍵取決于你想開發(fā)什么系統(tǒng)，公司技術(shù)人員的能力，以及公司的性質(zhì)。迪斯科、金福瑞、麗源信息、浦源等在中國比較好。梨園信息可以更好，沒有后期收費，開發(fā)過程中遇到的問題可以隨時解決。