打包微服務的訂閱者/工作組件的最佳實踐是什么

Question

我有一個帶有 api 和訂閱者的微服務，可以在一個 repo 中用 NodeJS 編寫。 我將使用 argo-events 來監聽事件總線，並在從事件總線接收到特定消息時觸發多個訂閱者。 每當收到消息時，訂閱者將作為 Kubernetes 中的作業資源被觸發。

我的問題是 - 將訂閱者打包為 Docker 鏡像的最佳實踐是什么？ 由於微服務位於一個包含 API 和訂閱者的存儲庫中，您 (A) 是否為整個微服務創建了一個映像，並僅更改入口點/命令來運行訂閱者？ 或者 (B) 您是否為每個訂閱者創建了單獨的 docker 鏡像？

如果（A），您認為圖像的大小會導致任何問題嗎？ 如果（B），你如何組織 Dockerfiles 和管理具有多個 docker 鏡像的 CI/CD 管道？

Answer 1

讓我從你的問題開始。 我假設您的所有訂閱者和 API 服務都有不同的行為和責任。

帶有 api 和訂閱者的微服務將在一個 repo中用 NodeJS 編寫

這是我們在從微服務開始時經常看到的一種方法，將我們所有的代碼放在一起，我們有一個巨大的存儲庫來存儲我們所有的代碼，並且有一個單一的構建管道。 從開發人員的角度來看，這完全沒問題，而且非常簡單，如果只有一個團隊在處理所有事情，這可能會很好，但時間很短。 但這是您在早期階段應該避免的模式之一。 這種模式有一些明顯的缺點。 例如，API 服務和所有其他服務中的一個小變化將得到不必要的驗證和構建，這確實會影響我們將一個簡單的更改從開發人員表移動到 prod 環境的速度，並且您將重新部署您的“訂閱者” ' 沒有更改的包留下了測試的工作和一個帶有空更改日志的包的新版本!!。 有人會爭辯說他們有一個不同的部署模型，所以他們只部署有更改的包，我猜他們將失去完全自動化的能力。 除此之外，我們剛剛在 API 服務中所做的一個小改動，很有可能會破壞整個構建。 所以現在所有其他包都需要等待這個休息時間來修復！！ 簡而言之，這種設置最終會導致很大的依賴風險，如果您的團隊發展並分成多個團隊，那將會很混亂。 我在這里只提到了幾個問題，但有很多問題會導致架構失敗。

將訂閱者打包為 Docker 鏡像的最佳實踐是什么？ 由於微服務位於一個包含 API 和訂閱者的存儲庫中，您是否 (A) 為整個微服務創建了一個映像，並僅更改入口點/命令來運行訂閱者？ 或者 (B) 您是否為每個訂閱者創建了一個單獨的 docker 鏡像？

容器化的最佳實踐是每個容器應該只有一個關注點。 這里的重點是，始終考慮將應用程序解耦到多個容器中，這樣很容易進行水平擴展。 在您的情況下，嘗試為每個訂閱者構建不同的圖像。

你認為圖像的大小會導致任何問題嗎？

最佳實踐是最小化 docker 鏡像的大小。

您如何組織 Dockerfiles 並使用多個 docker 鏡像管理 CI/CD 管道？

如果您正在考慮多個 docker 圖像（圖像/訂閱者），為什么您不能考慮拆分您的巨型存儲庫。 你看，因為這個項目結構，你有很多問題。 拆分您的存儲庫，為每個服務創建 CI/CD 管道並分別為服務構建 docker 映像，無耦合且完全敏捷！！。