微服務調用為什么用RPC框架，http不更簡單嗎？簡單點，HTTP是協(xié)議，RPC是概念！實現(xiàn)RPC可以基于HTTP協(xié)議（Feign），TCP協(xié)議(Netty)，RMI協(xié)議（Soap），WebServi

微服務調用為什么用RPC框架，http不更簡單嗎？

簡單點，HTTP是協(xié)議，RPC是概念！實現(xiàn)RPC可以基于HTTP協(xié)議（Feign），TCP協(xié)議(Netty)，RMI協(xié)議（Soap），WebService（XML—RPC）框架。傳輸過程中，也因為序列化方式的不同，又有一些框架和協(xié)議，比如Dubbo中的Dubbo協(xié)議，gRpc—Protobuf序列化協(xié)議等等。其實，都是基于遠程調用的概念，何為遠程調用？

重點是，RPC就是遠程調用，遠程調用就是客戶端把調用的接口，參數(shù)，參數(shù)類型，方法，返回值，返回值類型等（這些稱為方法簽名），通過如上的協(xié)議，發(fā)送給服務端，告知服務端需要調用的接口方法，這個過程就是RPC的實現(xiàn)過程！HTTP和RPC是不同層面的兩個東西！

性能方面，HTTP本身是基于TCP協(xié)議的，屬于應用層協(xié)議，所以HTTP協(xié)議本身在實現(xiàn)過程中就會占用大量的資源（內存，帶寬等），性能上肯定沒有通過TCP直接實現(xiàn)RPC協(xié)議快，不管HTTP如何優(yōu)化肯定的是不如TCP的！而TCP則是依靠字節(jié)碼，現(xiàn)在普遍采用的是將客戶端調用的接口信息，序列化的方式發(fā)送給服務端，序列化框架又包含很多（Hession，Protobuf，Kryo等等，序列化性能最高的是Kryo，序列化后字節(jié)碼最小的是Protobuf），序列化后的字節(jié)碼越小，占用帶寬越少，序列化時間越短，線程IO等待時間就會越小。所以，在具體應用層面有很多可探討的技術，可以根據(jù)自己的硬件能力來選擇相應的技術就可以了！

歡迎熱愛技術的人來探討！

后端開發(fā)完接口才給出接口文檔，合理嗎？你怎么看？

一個非常好的問題，我是工作多年的Web應用架構師，來回答一下這個問題。歡迎關注我，了解更多IT專業(yè)知識。

后端給出接口文檔太晚，也合理也不合理，要看具體情況，總有解決方法，我來說一下我的觀點。

不合理：成熟的技術團隊，重視功能設計，在動手寫代碼之前已經有了完整的技術文檔和功能定義，甚至在TDD測試驅動開發(fā)模式中，測試數(shù)據(jù)已經準備就緒，那么這時接口文檔不管寫沒寫，接口邏輯都是已經確定的，整理出來是水到渠成。

合理：多存在于早期小型創(chuàng)業(yè)公司，主觀客觀原因都有。

- 先說主觀原因。趕進度、沒時間、懶得寫，甚至開發(fā)前都沒做仔細的設計，邊做邊改，這些原因普遍存在，也實在沒啥好辦法。

- 客觀原因，需求在變，功能跟著變，接口也要變，那么如果寫了文檔，理所當然也要更新維護??？我的天哪。

有解決方法嗎？建議試試：

1，Swagger接口文檔，將文檔融合到代碼中，讓維護文檔和修改代碼整合為一體，使得修改代碼邏輯的同時方便的修改文檔說明。

2，Postman接口測試工具，導入導出JSON文件，高效團隊協(xié)作。Postman支持各種請求方式和配置環(huán)境變量，并對返回結果進行測試校驗，支持批量自動化運行，可以和自動構建系統(tǒng)集成。