庫 vs 服務 vs 側車Sidecar的比較

1.庫包
這是重用程式碼的最廣泛使用的方法。可重用程式碼作為庫開發和釋出。在這種方法中，客戶端應用程式將庫定義為直接依賴項，使用提供的 API 並將其程式碼與主應用程式邏輯一起傳送。庫和主應用程式邏輯的程式碼作為同一程式/容器的一部分執行。
優點

• 延遲：庫中的程式碼與主應用程式在同一程式中執行，因此沒有網路延遲。
• 可用性：整體可用性很高，因為沒有網路分割槽（CAP定理）。
• 易於使用：使用非常簡單。
• 環境上下文：庫可以訪問環境上下文（記憶體、CPU 等），因為它們是同一容器的一部分。

• 資源：記憶體、CPU 等資源與主應用程式共享。這意味著庫的效能會對主應用程式產生副作用。
• 技術：庫中使用的庫與主要應用程式的庫相同，因此，如果組織有不同的應用程式集，則每種語言都需要多個實現。
• 可維護性：庫中的任何錯誤修復都需要對所有客戶端應用程式進行程式碼更改和測試。

服務
下一個最廣泛使用的模式是為可重用功能定義服務。在這種方法中，應用程式使用請求-響應機制進行網路呼叫以呼叫另一個服務。服務和主要應用程式邏輯的程式碼在不同的 Pod/伺服器例項中執行。
優點

• 資源：應用程式和服務分開部署，因此資源不共享。資源可以獨立地針對應用程式和服務進行最佳化。
• 可維護性：當涉及到錯誤修復時，服務可以獨立釋出。不需要版本升級。
• 技術：可以使用適合其目的的任何技術選擇來開發服務。

• 易用性：與庫相比，服務的易用性相對較低。
• 延遲：由於應用程式和服務是分散式的，並且呼叫需要網路呼叫，因此延遲明顯更高。
• 環境上下文：服務無法訪問主應用程式的環境上下文（記憶體、CPU 等），因為兩者都在不同的例項中獨立執行。
• 可用性：由於網路分割槽，總體可用性將低於庫。

Sidecar:邊車、側車

Sidecar 模式是由兩個容器組成的單節點模式。side car 和主應用程式邏輯的程式碼作為不同程式/容器的一部分執行，但一起部署在同一個 pod/server 例項中。
優點和缺點

• 可維護性：當涉及到錯誤修復時，Sidecar可以獨立釋出。
• 技術。Sidecar可以使用任何適合其目的的技術來開發。
• 延遲性。與服務相比，其延遲性較低，但比庫高。這種方法的反模式是使所有可重複使用的元件成為側車，因為這將導致對效能的重大影響。
• 資源。應用程式和Sidecar被部署到一起，所以資源是共享的，但可以為側車單獨設定資源限制，以防止側車的過度使用。這種方法的反模式是使所有可重用的元件成為側車，因為這將導致資源配置管理的巨大開銷。
• 易用性：與庫相比，邊車的易用性相對較低，如果CI/CD管道支援開箱即用，那麼與服務相比，使用起來會更簡單。
• 環境背景。環境上下文（記憶體、CPU等）是可以被sidecar訪問的，因為它是同一個pod/伺服器例項的一部分。這使得側車可以進行應用效能監控等。
• 可用性：與服務相比，可用性會更高，因為沒有真正的網路分割槽。一般來說，可用性主要取決於主應用程式和側車之間的通訊協議。例如，如果協議是火災和遺忘，那麼側車的故障將不會對主應用程式產生連帶的副作用。

總結
上面提到的方法--庫、服務和Sidecar都可以一起用於一個應用程式，以達到預期的效果。一個應用程式可以使用庫來進行資料庫呼叫，使用sidecar來進行分散式日誌記錄，使用服務來提供認證功能。開發團隊需要權衡利弊，然後選擇正確的解決方案。