Sidecar
1.什么是Sidecar模式
Sidecar 模式是 Service Mesh 中習慣采用的模式
將應用程序的功能划分為單獨的進程可以被視為 Sidecar 模式。如圖所示，Sidecar 模式允許您在應用程序旁邊添加更多功能，而無需額外第三方組件配置或修改應用程序代碼。
在軟件架構中， Sidecar 連接到父應用並且為其添加擴展或者增強功能。Sidecar 應用與主應用程序松散耦合。它可以屏蔽不同編程語言的差異，統一實現微服務的可觀察性、監控、日志記錄、配置、斷路器等功能
Istio與Envoy使用的模型 也是用的這種模型
2. Sidecar的使用
-
使用 Sidecar 模式部署服務網格時，無需在節點上運行代理，但是集群中將運行多個相同的 Sidecar 副本
-
在Sidecar部署方式中，會為
每個應用的容器部署一個伴生的容器。 -
對於Service Mesh，Sidecar接管進出應用程序容器的所有網絡流量
-
在 Kubernetes 的 Pod 中，在原有的應用容器旁邊注入一個 Sidecar 容器，兩個容器共享存儲、網絡等資源，可以廣義的將這個包含了 Sidecar 容器的 Pod 理解為一台主機，兩個容器共享主機資源。
3. 一些思考
- 大多數（Kubernetes）集群每個節點上有多個pod（因此每個節點有多個sidecar），如果每個sidecar都需要知道“整個配置”，那么就需要更多的帶寬來同步該配置（以及更多的內存來存儲配置副本），不得不給每個Sidecar的配置范圍加以限制，這很強，但從另一個角度看：必須花費更多精力為每個Sidecar減少配置（如
Istio中的Pilot）。 - 通過Sidecar復制其他東西會帶來類似的開銷, 如果復制的內容完全相同並且使用了正確的驅動，容器運行時就會容器重用鏡像一樣， 因此磁盤損失就不重要了， 並且代碼塊也會在內存中共享。 但是每個Sidecar都是獨一無二的， 要避免在每個sidecar上做一堆復制二十的Sidecar變重。
4. Envoy 和 MOSN流量劫持
MOSN 兼容 Istio，使用 Go 語言開發的替換了 Envoy。
MOSN 作為 Sidecar 和業務容器部署在同一個 Pod 中時，需要使得業務應用的 Inbound 和 Outbound 服務請求都能夠經過 Sidecar 處理。區別於 Istio 社區使用 iptables 做流量透明劫持，MOSN 目前使用的是流量接管方案，並在積極探索適用於大規模流量下的透明劫持方案。
流量接管
MOSN 使用的流量接管的方案如下：
-
假設
服務端運行在 1.2.3.4 這台機器上，監聽 20880 端口，首先服務端會向自己的 Sidecar 發起服務注冊請求，告知 Sidecar 需要注冊的服務(比如充值服務Deposit)以及 IP + 端口（1.2.3.4:20880） -
服務端的 Sidecar 會向服務注冊中心（如 SOFA Registry）發起服務注冊請求，告知需要注冊的服務(
Deposit)以及 IP + 端口，不過這里需要注意的是注冊上去的並不是業務應用的端口（20880），而是 Sidecar 自己監聽的一個端口（例如：20881） -
調用端向自己的 Sidecar 發起服務訂閱請求，告知需要訂閱的服務信息
-
調用端的 Sidecar 向調用端推送服務地址，這里需要注意的是推送的 IP 是本機，端口是調用端的 Sidecar 監聽的端口（例如 20882）
-
調用端的 Sidecar 會向服務注冊中心（如 SOFA Registry）發起服務訂閱請求，告知需要訂閱的服務信息；
-
服務注冊中心（如 SOFA Registry）向調用端的 Sidecar 推送服務地址（1.2.3.4:20881）
服務調用過程
經過上述的服務發現過程，流量轉發過程就顯得非常自然了：
-
調用端拿到的服務端地址是
127.0.0.1:20882，所以就會向這個地址發起服務調用 -
調用端的 Sidecar 接收到請求后，通過解析請求頭，可以得知具體要調用的服務信息，然后獲取之前從服務注冊中心返回的地址后就可以發起真實的調用（
1.2.3.4:20881） -
服務端的 Sidecar 接收到請求后，經過一系列處理，最終會把請求發送給服務端（
127.0.0.1:20880）
