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

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

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

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

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

！歡迎熱愛(ài)科技的人們來(lái)探索

在做程序員的道路上，你掌握了什么概念或技術(shù)使你感覺(jué)自我提升突飛猛進(jìn)？

我是甲方的ERP程序員，公司剛推出ERP系統(tǒng)時(shí)，大家都覺(jué)得上帝的存在太復(fù)雜了。

上線(xiàn)后，各種問(wèn)題層出不窮，項(xiàng)目已通過(guò)驗(yàn)收。乙方一聽(tīng)我們的問(wèn)題，就會(huì)有兩個(gè)動(dòng)作：1）這個(gè)問(wèn)題不在需求范圍內(nèi)，需要付費(fèi)解決；2）這個(gè)問(wèn)題這個(gè)版本沒(méi)有解決，下一個(gè)版本可以解決。

顯然，這是個(gè)小問(wèn)題。為什么不能解決？最重要的原因是沒(méi)有源代碼。ERP歸根結(jié)底是對(duì)數(shù)據(jù)庫(kù)的添加、刪除和修改。直到我明白了這兩點(diǎn)，ERP的“九字真言”終于越過(guò)了前三個(gè)字。（所謂ERP九字咒語(yǔ)是：先剛性，后固化，再優(yōu)化）。

我理解的兩點(diǎn)如下：1）真正理解ERP邏輯的人不是計(jì)算機(jī)工作者，而是業(yè)務(wù)骨干。ERP構(gòu)建了最常見(jiàn)、最核心的業(yè)務(wù)邏輯，體現(xiàn)在操作流程和功能接口上。只有業(yè)務(wù)骨干才能真正理解這種設(shè)計(jì)的必要性。

2）只要程序員與業(yè)務(wù)主干相結(jié)合，盡管沒(méi)有源代碼，但還是有辦法看到添加、刪除、修改和查詢(xún)的代碼是如何操作數(shù)據(jù)庫(kù)的。這是SQL事件探查器跟蹤程序。

兩者結(jié)合后，ERP維護(hù)將變得非常簡(jiǎn)單。畢竟，一個(gè)已經(jīng)上市幾十年的ERP產(chǎn)品具有很好的穩(wěn)定性和繼承性。那么，各種個(gè)性化報(bào)表的開(kāi)發(fā)就非常簡(jiǎn)單了。

隨著對(duì)業(yè)務(wù)編程越來(lái)越熟悉，這個(gè)團(tuán)隊(duì)將對(duì)ERP產(chǎn)品有非常透徹的了解，終于有一天。乙方要求增加維修費(fèi)，我們想了想，沒(méi)有，我們自己維修吧。然后，我們將ERP的生產(chǎn)功能分離，自行定制開(kāi)發(fā)，并逐步完善，越來(lái)越喜歡它。這是九字咒語(yǔ)的最后一個(gè)階段：優(yōu)化。

當(dāng)然，這一過(guò)程的實(shí)現(xiàn)得益于ERP產(chǎn)品開(kāi)發(fā)平臺(tái)的支持和自身的開(kāi)發(fā)邏輯。大型工廠(chǎng)（包括國(guó)外SAP）的ERP從財(cái)務(wù)模塊開(kāi)始，再到供應(yīng)鏈，再到制造，再到商業(yè)智能。這決定了每個(gè)模塊是松散耦合的。在演化過(guò)程中，采用了多種接口方式，從硬寫(xiě)數(shù)據(jù)庫(kù)到使用XML交換數(shù)據(jù)，再到COM組件接口、API，甚至提出了整體開(kāi)發(fā)平臺(tái)，并用開(kāi)發(fā)平臺(tái)重寫(xiě)業(yè)務(wù)文檔。基本上，這些資料可以在網(wǎng)上找到。如果你參加幾次由大工廠(chǎng)組織的開(kāi)發(fā)培訓(xùn)，就更容易開(kāi)始。