詳解微服務之間3大通信方式：網關 API、RPC 和 SideCar
0、前言
微服務，相信大家已經不陌生了。傳統的單體應用有很多缺點，比如：代碼數據集中管理、開發效率低、啟動慢、可靠性差、技術單一等。而微服務則有很多優點，比如：按照功能拆分、自治、松耦合、跨語言、輕量級通信等。
我們來逐步拆解其中的細節部分，首先介紹微服務間的三大通信方式：基于網關 API、基于 RPC 和 基于 SideCar 的方式。
1、基于網關 API
簡單來說，網關 API 的功能可以分為四部分：
1). 請求接入
為各種應用提供統一的服務接入
處理所有的接入請求
2). 治理策略
包括負載均衡、限流、熔斷、超時重試、 灰度發布、協議適配、流量監控、日志統計等
3). 認證鑒權
包括用戶鑒權、身份校驗、黑白名單管理、防web攻擊等
4). 統一管理
管理所有的服務及策略
提供配置管理的工具
2、基于 RPC
RPC 指遠程服務調用(remote process call)，假如兩個應用 A 和 B 分別部署在兩臺服務器上，如果 A 想要調用 B 應用上的函數，由于不在同一個內存空間，怎么辦呢?則需要通過網絡來表達需要調用的語義和傳達調用的數據。
主流 RPC 框架有 Dubbo、gRPC、bRPC 和 Thrift
從 github star 來看，Dubbo > gRPC > bRPC > Thrift.
3、基于 SideCar
提到 SideCar，總是會聯系到 Service Mesh，何為 Service Mesh?Service Mesh 表征了云上應用了 SideCar 技術后服務之間呈現出來的一種關系，如下圖所示：
SideCar 可以說是后 Kubernetes 時代誕生的技術。它與原生 Kubernetes 的關系如下圖所示：
原生 K8S 中每個 node 里有一個 kube-proxy，而 Service Mesh 中每個 pod 里都有一個 proxy(SideCar)，這個 proxy(上圖中藍色部分) 可以是獨立容器部署，也可以和業務進程(上圖中綠色部分)共同部署在一個容器里。node 里的多個 proxy 是同一個 proxy 的相同副本。這也很好理解嘛!如果每個業務進程都有一個不同的 proxy，那 SideCar 的存在就沒意義了嘛。
使用 Service Mesh 并不是說它會與 Kubernetes 決裂，而是它會自然而然地發生。 Kubernetes 的本質是通過聲明式配置進行應用生命周期管理，而 Service Mesh 的本質是提供應用之間的流量和安全管理和可觀察性。
SideCar 的代表性技術是 istio，其控制面實現是 Envoy.
Istio Service Mesh 可以使用 Kubernetes 中的服務進行服務注冊。它還可以通過控制平面的平臺適配器連接到其他服務發現系統，然后生成數據平面的配置(使用CRD語句，存儲在etcd中)，數據平面的透明代理。
『透明代理』部署在每個應用服務 pod 中的 sidecar 容器中。這些代理需要請求控制平面同步代理配置。之所以是透明代理，是因為沒有應用容器完全感知代理，進程 kube-proxy 組件喜歡阻塞流量，但是 kube-proxy 阻塞了 Kubernetes 節點的流量，而 Sidecar 代理阻塞了 pod 之外更多信息。
