本文介紹sidecar模式的特點，及其應用的場景。熟悉native cloud或者微服務的童鞋應該知道，在雲環境下，技術棧可以是多種多樣的。那麼如何能夠將這些異構的服務元件串聯起來，成為了服務治理的乙個重大課題。而sidecar模式為服務治理，提供了一種解決方案。
將應用程式的元件部署到單獨的程序或容器中，以提供隔離和封裝。此模式還可以使應用程式由異構元件和技術組成。
這種模式被稱為sidecar，因為它類似於連線到電單車的邊車。在該模式中，邊車附加到父應用程式並為應用程式提供支援功能。 sidecar還與父應用程式共享相同的生命週期，與父項一起建立和退役。邊車圖案有時被稱為搭接圖案並且是分解圖案。
應用程式和服務通常需要相關的功能，例如監控、日誌、集中化配置和網路服務等。這些外圍任務可以作為單獨的元件或服務來實現。
如果它們緊密整合到應用程式中，它們可以在與應用程式相同的程序中執行，從而有效地使用共享資源。但是，這也意味著它們沒有很好地隔離，並且其中乙個元件的中斷可能會影響其他元件或整個應用程式。此外，它們通常需要使用與父應用程式相同的語言或者技術棧來實現。因此，元件和應用程式彼此之間具有密切的相互依賴性。
如果將應用程式分解為服務，則可以使用不同的語言和技術構建每個服務。雖然這提供了更大的靈活性，但這意味著每個元件都有自己的依賴關係，並且需要特定於語言的庫來訪問底層平台以及與父應用程式共享的任何資源。此外，將這些功能部署為單獨的服務可能會增加應用程式的延遲。管理這些特定於語言的介面的**和依賴關係也會增加相當大的複雜性，尤其是對於託管、部署和管理服務。
上述問題的解決方案是，將一組緊密結合的任務與主應用程式共同放在一台主機（host）中，但會將它們部署在各自的程序或容器中。這種方式也被稱為「sidecar（邊車）模式」。
下圖展示了任務與主應用程式的部署關係圖。
邊車服務不一定是應用程式的一部分，而是與之相關聯。它適用于父應用程式的任何位置。sidecar支援與主應用程式一起部署的程序或服務。這就像是如下圖所示的邊三輪電單車那樣，將邊車安裝在一輛電單車上，就變成了邊三輪電單車。每輛邊三輪電單車都有自己的邊車。類似同樣的方式，邊車服務共享其父應用程式的主機。對於應用程式的每個例項，邊車的例項被部署並與其一起託管。
使用邊車模式的優點包括：
sidecar模式通常與容器一起使用，並稱為邊車容器。有關容器方面的內容，可以參閱
spring cloud netflix sidecar框架提供了sidecar模式的現成解決方案。spring cloud netflix sidecar框架框架可以提供對其他非spring cloud技術棧的微服務的治理。比如，你可以使用node或者golang編寫乙個web專案，這個服務同樣可以以sidecar模式，納入到spring cloud管理中去。
下面是實現步驟。
提供rest介面，返回json格式內容。其中status用於描述微服務的狀態，常見的取值有up、down、out_of_service和unknown等。
建立專案，新增eureka、sidecar的依賴：
org.springframework.cloud
spring-cloud-netflix-sidecar
org.springframework.cloud
spring-cloud-starter-eureka
啟動專案，並訪問8887介面，就可以訪問到web專案中的介面。
以下是sidecar的常用端點：
將sidecar與web服進行部署。一般是部署在相同的主機裡面。
istio部署 sidecar注入
工作負載的 pod 必須有關聯的 service 準備測試用 yaml 檔案 cd 新的 yaml 檔案中多出了 sidecar 容器，並且出現了1個初始化容器 initcontainers istio init 初始化容器即用來劫持應用通訊到 sidecar 容器的工具 istioctl kube...
istio 禁用 允許sidecar設定
一 在namespace設定自動注入 給 default 命名空間設定標籤 istio injection enabled kubectl label namespace default istio injection enabled kubectl get namespace l istio in...
設計模式了解
設計模式 design pattern 是前輩們對 開發經驗的總結，是解決特定問題的一系列套路。它不是語法規定，而是一套用來提高 可復用性 可維護性 可讀性 穩健性以及安全性的解決方案。如果要強行舉例子的話，我覺得有點像古代留下的三十六計，什麼情況下用什麼計謀。什麼情況下用什麼設計模式一樣。簡單來說...