服務間的通信方式是在采用微服務架構時需要做出一個最基本的決策。默認的選項是通過 HTTP 發送 JSON，也就是所謂的 REST API。我們也是從 REST 開始的，但最近我們決定改用 gRPC。
gRPC是谷歌開發的一個遠程調用框架，現在已開源。盡管它已經出現了多年，但網上關於人們為什么要用它或者為什么不用它的信息並不多。於是，我決定寫這篇文章分享一下我們為什么要使用 gRPC。
gPRC 的一個很明顯的優勢是它使用了二進制編碼，所以它比 JSON/HTTP 更快。雖然說速度越快越好，但我們也要考慮另外兩個因素：清晰的接口規范和對流式傳輸的支持。
Swagger/OpenAPI
當然，如果使用的是 JSON/HTTP，Swagger或者OpenAPI也提供了類似的東西。下面的例子與上述的 gRPC API 相當。
流式傳輸
今年早些時候，我開始為我們的搜索服務設計一個新的 API。在我使用 JSON/HTTP 設計了第一版 API 之后，我的一個同事告訴我說，在某些情況下，我們需要流式傳輸搜索結果，也就是在有第一批結果時就開始傳輸。而我之前設計的 API 只返回一個單獨的 JSON 數組，在服務器端收集到所有結果之前是不會向客戶端發送任何數據的。
我們的 API 要求客戶端輪詢搜索結果，先是發送一個 POST 請求發起搜索，然后再不斷發送 GET 請求獲取搜索結果。響應消息中包含了一個用於表示搜索是否已完成的字段。這種方式雖然沒有什么問題，但還不夠優雅，而且要求服務器端將中間結果保存在數據存儲（如 Redis）中。
注意事項
gRPC 也有一些不足之處，不過它們都與相關的開發工具有關，並不是 gRPC 本身的問題。
如果我們使用 JSON/HTTP 開發 API，就可以使用 curl、httpie 或者 Postman 進行簡單的手動測試。gRPC 也有一個類似的工具叫作grpcurl，不過它使用起來並不是很方便，你要么需要在服務器端添加gRPC 服務器反射插件，要么需要在每個命令后面附上.proto 文件。
另一個是 Kubernetes 負載均衡器問題，負載均衡器可以支持 HTTP，但對 gPRC 支持得並不好。gPRC 要求應用層的負載均衡，而不是在 TCP 連接層。為了解決這個問題，我們參考了這篇文章搭建了 Linkerd。
Consul 是 HashiCorp 出品的開源服務發現工具。
Consul 提供了諸如服務發現，健康檢查，KV 數據庫等功能，方便你使用它構建自己的服務集群。
基礎概念
Agent: agent 就是實際運行的 consul 服務，啟動時可選以 server 或者 client 模式運行，每個集群至少有 1 個 server，由於使用了 Raft 算法，所以對於每個集群你應該把它的 server 數設置成 3 或 5 個。
Server: 核心的 consul 服務，存儲了所有服務注冊的信息，響應查詢操作，跨數據中心通信等。
Client: 用來在集群中每個機器上運行，進行服務注冊 / 健康檢查的進程。
Cluster: 集群，由多台共同提供服務的機器組成的集合稱為集群，agent 在集群的每個成員上都要運行。
DataCenter: 數據中心。consul 支持跨數據中心組成集群。
Node: 安裝了 agent，接入集群的機器稱為 node。
Service: 你的服務，即服務注冊和服務發現之類操作的對象。通過提供 config 文件或者調用 consul 的 HTTP API 來定義一個服務。