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