Bluecore 利用 Istio 遷移至 Kubernetes

Bluecore 是一個多管道個人化平台，專門提供高度個人化的電子郵件、網站訊息和付費媒體廣告，並大規模傳遞。由於 Bluecore 的獨特服務需要處理客戶推薦數據，並發送大量個人化數位通訊，他們需要處理大量的資料擷取、處理和發送。這是一項龐大的工作量；在最近的黑色星期五期間，他們發送了超過 20 億封電子郵件。

除了量以外，Bluecore 還需要速度。他們與大多數合作夥伴都有服務協議，保證任何客戶在提交任務後幾個小時內都會收到電子郵件、網站訊息或廣告，這意味著處理速度至關重要。他們透過在 Google App Engine 上執行的單體應用程式，以及在 Google Kubernetes Engine (GKE) 叢集上執行的約 12,000 個 Pod 來完成這項壯舉。

挑戰：單體架構和不斷增加的資料流量

Bluecore 是一個大型營運，對資料傳輸和處理有嚴格的要求。他們面臨著一個艱鉅的挑戰；他們需要處理的資料量不斷增加。他們知道如果他們的架構無法更新以應對不斷增長的需求，他們的管線將會超載。

對他們架構的檢查顯示，單體應用程式將會是最大的挑戰。Bluecore 開發團隊意識到，為了實現未來的成長，是時候開始遷移到更靈活和可擴展的基礎設施了。

Kubernetes 提供了一條擴展的途徑，而且由於 Bluecore 已經在 App Engine 上執行，因此將部分工作流程遷移到 GKE 看起來是理所當然的。但是，Bluecore 的大多數工程師對容器化的應用程式沒有足夠的經驗。這可能會使遷移到 GKE 成為一個痛苦的過渡。

幸運的是，他們找到了解決方案。

解決方案：透過 Istio 服務網格啟用開發人員

Bluecore 基礎設施團隊的軟體工程師 Shray Kumar 解釋說：「Istio 實現了一種開箱即用的建構方法。而且你可以確保你正在以正確的方式建構東西。」

如果沒有服務網格，將單體應用程式分解為容器化服務會帶來許多挑戰，而這些挑戰沒有明顯的解決方案。例如，其中之一是實作身份驗證和授權。如果每個容器化服務都需要自己的解決方案，則個別開發人員很可能會提出自己的方法來執行此操作。這可能會導致程式碼分散，並在未來造成許多頭痛問題。

幸運的是，Kumar 和基礎設施團隊熟悉 Istio。他們與 Bluecore 數據平台團隊的首席工程師 Al Delucca 密切合作，制定了開始實施 Istio 的計畫。

Delucca 解釋說：「我們遇到了問題。但是，Istio 是否是解決這個問題的工具，這是我們必須弄清楚的。」

他們發現 Istio 的功能集為現有的挑戰提供了許多解決方案。授權是一個很大的問題。來自合作夥伴應用程式的傳入訊息需要進行身份驗證。Istio 可以在邊緣執行該身份驗證，這意味著每個單獨的服務都不需要實作自己的方法。

Delucca 說：「我們能夠將身份驗證和授權推送到邊緣，這減輕了我們的工程師理解這些系統的負擔。這不是他們直接用 Istio 做什麼，而是 Istio 在他們不知情的情況下為他們做什麼。這是關鍵——對我們來說是一大勝利。」

當他們的工程師開始將單體應用程式分解為服務時，他們遇到了另一個 Istio 能夠解決的挑戰。追蹤對服務的呼叫看起來會很麻煩。許多舊函數沒有關於其依賴項和需求的明確文件。這意味著效能問題和遠端服務呼叫可能會讓開發人員摸不著頭腦。幸運的是，Istio 的分散式追蹤派上了用場。透過它，開發人員能夠找出瓶頸以及需要錯誤修復和額外工作的服務。

Istio 的服務網格使開發人員能夠專注於將單體應用程式分解為個別服務，而無需深入了解整個基礎設施。這使 Bluecore 的工程師能夠更快地提高生產力。

結論：未來

儘管 Bluecore 團隊已經在他們使用的 Istio 功能中發現了難以置信的價值，但他們仍在尋求利用更多功能。這些功能包括管理自動擴展金絲雀部署的能力。金絲雀部署允許團隊透過僅使用一小部分應用程式流量來測試新版本的服務。如果測試順利，則可以自動部署升級，同時逐步淘汰舊版本。另一方面，如果在新版本中檢測到問題，則可以快速回滾到舊版本。

Bluecore 團隊將繼續將他們的單體應用程式分解為容器化服務，使用 Istio 將越來越多的服務推送到邊緣，並讓他們的開發人員有更多時間去做他們最擅長的事情。他們相信他們已準備好迎接下一個成長階段，因為他們需要擷取和處理越來越多的資料。