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

微服務調用為啥用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ù)自己的硬件能力來選擇相應的技術就可以了！

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

Service層和Dao層真的有必要每個類都加上接口嗎？

簡單來說就是看情況。

主要看你項目：

• 變動情況
• 以及架構
• 人員
• 項目情況

比如，項目原來使用的hibernate，后續(xù)可能要切換為mybatis，那么dao就需要使用接口。這就不會影響上層代碼的修改。

再比如，項目是個單體應用，任何代碼的修改都需要重新編譯整個項目，那可以不用接口。而如果項目是分模塊編譯部署的，那就可以使用接口解耦，假設dao有修改，只需要重新編譯部署dao模塊即可，不影響上層模塊。

再來，如果項目組新手較多，可能簡單的代碼結構更適合。復雜項目結構的學習成本要高。

假如，項目進度很急，可以使用簡單粗暴的方式先擼～

可以用經(jīng)濟學上的成本來解釋原因。

經(jīng)濟學上的成本定義是：你做一件事，所放棄的其它事情中，價值最大的那件事的價值就是你做這件事的成本。

你使用接口的成本就是你不使用接口所花費的成本（包括后續(xù)的維護成本）。

如果項目變動多、模塊部署、項目不急，那使用接口的成本就低于不使用接口的成本，雖然早期可能不用接口看起來更簡單；反之，則不用接口的成本低，甚至框架都可以不使用～

畢竟工具是為了提高效率的，何必和自己過不去呢！

RPC和Socket的區(qū)別？

RPC（遠程過程調用）采用客戶機/服務器模式實現(xiàn)兩個進程之間相互通信。SOCKET是RPC經(jīng)常采用的通信手段之一。除了SOCKET，RPC還有其他的通信方法，比如，微軟的Windows系統(tǒng)中，RPC也會采用命名管道進行通信。