在上一篇文章中，有提過，在微服務的選型方面，使用什麼協定來建構微服務體系，一直是個比較熱門的話題，目前，較常用的是http和rpc兩種方式，本文将對比這兩種方式的優劣，進而使得讀者可以根據實際需求，去選擇通訊方式。
RPC：遠端過程調用(Remote Produce Call),自定義資料格式(較為通用的有Protobuf和Json)，基于原生的TCP進行通訊，速度快，效率高。
HTTP：超文本傳輸協定(HyperText Transfer Protocol),是一種網絡協定，通常在7層模型的傳輸層，其本身基于TCP，有特定的傳輸格式。現在的浏覽器采用的都是Http協定(此處Https歸為Http，其是在Http基礎上做了加密操作)
OSI七層模型
正如上文所說，HTTP處于七層模型的最頂端，即應用層，TCP處于第四層，即傳輸層。HTTP較TCP相比，包含了大量的HTTP頭部資訊，這就使得有用資訊比低，傳輸效率低。從使用者的角度來看，更多的是傳輸速度快，QPS(Query Per Second)優，是以從這個角度來看，HTTP的可讀性似乎不是那麼重要了。
在一般情況下，兩個應用或者接口之間的調用方式，可以分為HTTP和RPC兩種，如下圖所示：
最最簡單的方式，如果是部門之間，那麼建議使用HTTP方式，這樣使得耦合度盡可能的低，在業界，有個不成文的約定，就是部門之間盡量使用HTTP方式來調用，即使有時候中間件比如REDIS或者KAFKA使得業務實作更容易，這樣的目的隻有一個，在出現問題的時候，防止雙方互相推卸責任。
現在繼續回到上圖，在上圖中，RPC其功能上較HTTP更為豐富，大緻包括：
1、server選擇：
目前大部分RPC架構在底層server選擇上都使用的輪詢。假如有server端有ip0, ip1，ip2，ip3...ipn，在client内部實作一個機制，即某次調用的ip0 服務，那麼下次就調用ip1的服務。
輪詢方式，如果被調用的服務負載較低，或者業務功能簡單、永不出錯(理想情況下)，那麼這種基本就能滿足業務需求。但是随着接觸網際網路的使用者越來越多，QPS達到百萬級别，這樣在伺服器扛不住，或者某一台伺服器當機的情況下，上面這種簡單的輪詢方式顯然不能滿足一個優秀的RPC架構的需求，這就使得在server選擇上面，需要考慮下遊服務的負載情況以及該服務的可用性等等因素。
2、序列化和反序列化：
現在業界通用的RPC協定是Protobuf以及Json，在調用端，将需要的參數進行序列化(Protobuf)和封裝(Json)，在被調用放則進行反序列化和解析，進而拿到對應的參數進行資料處理。
3、通信：
RPC之間的通信，一般有HTTP、TCP和UDP三種，HTTP的優缺點上面已經有提，是以此處不再進行贅述。TCP是業界使用最多的通信方式，其特點是可靠傳輸，後面筆者将會深入帶大家了解下TCP。而對于UDP，大家第一印象就是不可靠的，因為其隻負責将資料包傳輸出去，不管對方有沒有接收到，這樣就導緻對于比較重要的業務，使用可靠的TCP進行傳輸，對于不重要的業務，使用HTTP進行通訊，這就顯得UDP比較雞肋。
4、容錯：
容錯功能，是一個優秀的RPC架構非常重要的功能，比如，如果下遊某個伺服器挂了，或者下遊所有服務均不可用，那麼是否能夠保證整個業務正常運作，即不至于影響其他業務線。筆者所負責的業務之前就有存在該情況，在節假日的時候，流量可能會較平時增加很多。這樣就有可能導緻下遊某些服務扛不住了，進而導緻整個業務線或者資料流受到了影響，由于臨時擴容需要時間，也需要人員配合，這就一定程度上導緻流量浪費，業務異常，進而引起收入損失。從該點來看，限流和熔斷，也是非常重要的功能之一。
上面，我們簡單介紹了HTTP以及RPC，HTTP方式較簡單，但效率低，RPC效率高，但是實作起來非常複雜。是以，對于這倆的選擇，目前沒有一個标準，隻能依賴業務場景，進行站位。