protobuf和json哪個快 微服務(wù)調(diào)用為啥用RPC框架，http不更簡單嗎？
微服務(wù)調(diào)用為啥用RPC框架，http不更簡單嗎？簡單點(diǎn)，HTTP是協(xié)議，RPC是概念！實(shí)現(xiàn)RPC可以基于HTTP協(xié)議（Feign），TCP協(xié)議(Netty)，RMI協(xié)議（Soap），WebServic
微服務(wù)調(diào)用為啥用RPC框架，http不更簡單嗎？
簡單點(diǎn)，HTTP是協(xié)議，RPC是概念！實(shí)現(xiàn)RPC可以基于HTTP協(xié)議（Feign），TCP協(xié)議(Netty)，RMI協(xié)議（Soap），WebService（XML—RPC）框架。傳輸過程中，也因?yàn)樾蛄谢绞降牟煌?，又有一些框架和協(xié)議，比如Dubbo中的Dubbo協(xié)議，gRpc—Protobuf序列化協(xié)議等等。其實(shí)，都是基于遠(yuǎn)程調(diào)用的概念，何為遠(yuǎn)程調(diào)用？
重點(diǎn)是，RPC就是遠(yuǎn)程調(diào)用，遠(yuǎn)程調(diào)用就是客戶端把調(diào)用的接口，參數(shù)，參數(shù)類型，方法，返回值，返回值類型等（這些稱為方法簽名），通過如上的協(xié)議，發(fā)送給服務(wù)端，告知服務(wù)端需要調(diào)用的接口方法，這個過程就是RPC的實(shí)現(xiàn)過程！HTTP和RPC是不同層面的兩個東西！
性能方面，HTTP本身是基于TCP協(xié)議的，屬于應(yīng)用層協(xié)議，所以HTTP協(xié)議本身在實(shí)現(xiàn)過程中就會占用大量的資源（內(nèi)存，帶寬等），性能上肯定沒有通過TCP直接實(shí)現(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ù)的人來探討！
如何優(yōu)化很長的JSON數(shù)據(jù)？
現(xiàn)在主流的網(wǎng)絡(luò)請求中都采用JSON作為其數(shù)據(jù)交互格式，這主要是因?yàn)镴SON有以下優(yōu)勢：
數(shù)據(jù)格式簡單，易于讀寫，格式都是壓縮的，占用帶寬??；
易于解析，客戶端JS很容易JSON數(shù)據(jù)進(jìn)行解析和編輯；
支持大多數(shù)后端語言，大大簡化了服務(wù)端和前端交互時的代碼開發(fā)量，且易于維護(hù)；
但如果在開發(fā)過程中，把很長很大的JSON數(shù)據(jù)在前后端傳輸，那就說明設(shè)計(jì)工作沒做好，應(yīng)該盡量避免這種數(shù)據(jù)傳輸，但也可以從下面幾個方面進(jìn)行下優(yōu)化：
優(yōu)化json數(shù)據(jù)的key-value的長度，盡量簡潔易懂即可；
異步分批加載，建設(shè)大數(shù)據(jù)量造成前端頁面卡死；
前端增加銷毀機(jī)制，可以一邊加載，一邊銷毀；
使用解析和壓縮性能高的JSON解析工具；
在 Skylake 處理器上，各種解析器解析同一個大數(shù)據(jù)量的JSON文件的速度（以 GB/s 為單位）如下所示：