格蘭仕微波爐操作方法 微服務(wù)調(diào)用為啥用RPC框架，http不更簡單嗎？
微服務(wù)調(diào)用為啥用RPC框架，http不更簡單嗎？簡單點，HTTP是協(xié)議，RPC是概念！實現(xiàn)RPC可以基于HTTP協(xié)議（Feign），TCP協(xié)議(Netty)，RMI協(xié)議（Soap），WebServic
微服務(wù)調(diào)用為啥用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é)議等等。其實，都是基于遠程調(diào)用的概念，何為遠程調(diào)用？
重點是，RPC就是遠程調(diào)用，遠程調(diào)用就是客戶端把調(diào)用的接口，參數(shù)，參數(shù)類型，方法，返回值，返回值類型等（這些稱為方法簽名），通過如上的協(xié)議，發(fā)送給服務(wù)端，告知服務(wù)端需要調(diào)用的接口方法，這個過程就是RPC的實現(xiàn)過程！HTTP和RPC是不同層面的兩個東西！
性能方面，HTTP本身是基于TCP協(xié)議的，屬于應(yīng)用層協(xié)議，所以HTTP協(xié)議本身在實現(xiàn)過程中就會占用大量的資源（內(nèi)存，帶寬等），性能上肯定沒有通過TCP直接實現(xiàn)RPC協(xié)議快，不管HTTP如何優(yōu)化肯定的是不如TCP的！而TCP則是依靠字節(jié)碼，現(xiàn)在普遍采用的是將客戶端調(diào)用的接口信息，序列化的方式發(fā)送給服務(wù)端，序列化框架又包含很多（Hession，Protobuf，Kryo等等，序列化性能最高的是Kryo，序列化后字節(jié)碼最小的是Protobuf），序列化后的字節(jié)碼越小，占用帶寬越少，序列化時間越短，線程IO等待時間就會越小。所以，在具體應(yīng)用層面有很多可探討的技術(shù)，可以根據(jù)自己的硬件能力來選擇相應(yīng)的技術(shù)就可以了！
歡迎熱愛技術(shù)的人來探討！
大家一般用什么工具測試HTTP和json接口？
SoupUI，這是我現(xiàn)在用的最多的接口測試工具。
在我們?nèi)粘５拈_發(fā)過程中，大多數(shù)是兩種類型的接口：SOAP API和Rest API兩種，SoupUI對這兩種接口都有很好的支持，而且還支持Amazon Web Service，這個只在軟件的首頁上看到過，沒有實際使用過。
其實很多的接口測試工具對這兩種常用的接口都有很好的支持，具體的使用方法我在這里也不詳細講了，都是圖形界面的操作，按照指示一步一步的新建即可完成。
其中它可以很方便地進行壓力測試，也是按照提示，一步一步新建，最后的的操作頁面是這樣的：
可以設(shè)置：并發(fā)數(shù)、策略，壓力測試的時間等。
結(jié)果可以展示：接口的最大響應(yīng)時間、最小響應(yīng)時間、平均響應(yīng)時間、TPS等等。
非常好用，大家可以嘗試。