服務器通訊REST、gRPC，Swagger/OpenAPI，Consul

服務間的通訊方式是在採用微服務架構時須要作出一個最基本的決策。默認的選項是經過 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 來定義一個服務。