Wix如何零停機將將2000個微服務遷移到多叢集Kafka？

banq發表於2022-04-05
微服務Kafka

為了更輕鬆地將 2000 個微服務的生產者和消費者遷移到多個託管的 Kafka 叢集，最初的設計依賴於首先完全排空每個資料中心（DC）的流量。
這種設計意味著只需將生產者和消費者的連線細節切換到他們的新 Kafka 叢集。由於 Wix 微服務使用 Greyhound 層連線到 Kafka 叢集，因此只需要在一個地方更改連線——Greyhound 生產配置（同時確保只有 1 個 DC 受到影響）。
儘管這個設計很簡單，但遺憾的是無法實現和執行。有幾個原因：
  1. 有些服務只部署在其中一個資料中心，很難移動。
  2. 這種設計意味著全有或全無，並且在流量返回的那一刻非常危險。在未切換的邊緣情況下，它們可能會遭受資料丟失。
  3. 流量不能在很長一段時間內完全從資料中心排出，因為這可能會大大增加某些服務停機的風險。

相反，計劃進行一項新設計，涉及實時流量期間的遷移。

隨流量遷移
在實時流量期間執行遷移意味著必須進行細緻的規劃和執行。
這個過程必須是漸進的（每次隻影響一些微服務，以便在出現問題時減少爆炸半徑）並且完全自動化，以減少手動錯誤的機會，包括回滾過程的自動化。
首先遷移生產者（在消費者之前）不是一種選擇，因為這意味著需要相當長的時間來確保所有消費者都完成了對自託管叢集上的所有記錄的處理，並且可以安全地切換到新的叢集主題。這將導致處理中的相當大的延遲，從而可能損害某些 OLTP 業務流程和使用者。此外，如果沒有資料丟失，由於某些意外問題而回滾消費者是不可能的。
必須首先切換活動的 Kafka 消費者，同時確保沒有訊息丟失並且對記錄的重新處理最少。這樣做的唯一方法是首先將所有消費主題的記錄從自己的主機叢集複製到目標託管叢集。

複製
為了確保在遷移過程中不會丟失訊息處理，我們建立了一個專用的複製服務。一旦確定了所有消費者主題，複製器服務就會被命令在適當的雲叢集中建立主題，並開始使用自託管叢集中的記錄並將它們生成到目標叢集。

消費者遷移
為了方便消費者遷移，Replicator 還持久化了每個分割槽的偏移量對映，以便 Greyhound 消費者可以從正確的偏移量開始處理雲叢集中的記錄——該偏移量是從自託管叢集中的第一個未提交的偏移量對映的.
除了 Replicator 之外，還有一個 Migration Orchestrator 可以確保複製主題、對映所有偏移量，然後繼續請求 Greyhound 消費者取消訂閱自託管叢集。驗證成功後，Orchestrator 請求消費者訂閱雲叢集，同時首先尋找正確的對映偏移量。
如果發生故障，Orchestrator 能夠請求使用者恢復到自託管叢集。
所有這些 Orchestrator 到消費者的通訊本身都是透過專門的 Kafka 遷移主題完成的。Greyhound 消費者在這些主題開始時就開始偵聽。

生產者遷移
一旦某個主題的所有消費者被遷移，就有可能遷移其生產者。
最初的遷移設計需要請求生產者切換叢集連線，同時仍然接受傳入的生產請求。這意味著在記憶體中緩衝這些請求，而且被認為是相當危險的。
後來我們想出了一個更簡單的設計，它依賴於Wix的漸進式Kubernetes部署過程。每個新的pod只有在其所有的健康檢查都正常時才開始接受傳入的請求，包括與Kafka的連線。由於這個過程是循序漸進的，總有一些 "老 "的pod在執行，這樣服務作為一個整體總是可以接受傳入的請求。
在pod啟動時，Greyhound生產者只需檢查一個資料庫，以確定他們應該連線到哪個叢集。這比動態叢集切換和記錄緩衝要簡單得多。這意味著遷移是安全的，沒有請求會丟失，服務保持在高可用性。

複製的瓶頸
只有當生產者被遷移後，停止話題的複製才是可以接受的。但是為了遷移生產者，首先必須遷移其所有的主題消費者。
事實證明，許多主題有來自不同服務的多個消費者，這意味著Replicator消費者需要處理和複製的流量越來越多。
這就造成了一個問題，由於我們相對較老的自營Kafka經紀人版本的技術限制，消費者可以處理的主題數量達到了限制。在幾次嘗試增加message.max.bytes的結果都適得其反（見KAFKA-9254 bug），並造成了嚴重的問題後，我們決定簡單地增加Replicator消費者，並在他們之間分片處理要複製的主題。

最佳實踐和提示
以下是成功進行Kafka叢集遷移的最佳實踐和技巧清單。

  • 建立一個指令碼，自己檢查狀態，如果沒有達到預期狀態就停止
    讓遷移過程儘可能的自動化是關鍵，所以讓指令碼自己檢查是否可以進入下一階段，可以大大加快遷移過程。另一方面，自動回滾和自我修復是很難做到的，所以最好把它留給人工干預。
  • 準備好隨時可以使用的回滾
    不管你的遷移程式碼測試得有多好，生產環境是不確定的領域。為每個階段準備一個現成的回滾選項是非常重要的。一定要提前準備好，並在開始執行遷移之前儘可能多地測試它。
  • 從測試/中繼主題和無影響主題開始
    遷移可能是非常危險的，因為記錄有可能丟失，或者恢復起來很痛苦。請確保用測試主題開始測試你的遷移程式碼。為了有一個真實的檢查。使用測試主題，透過將真實的生產記錄複製到一個特殊的測試應用中的測試主題，實際模仿生產主題。這樣，消費者遷移過程中的失敗不會對生產產生任何影響，但它將為你提供一個更真實的生產模擬。
  • 建立自定義的指標儀表板，顯示當前和演變的狀態
    即使你建立了一個完全無人值守的自動遷移過程，你仍然需要能夠監控正在發生的事情，並在出現問題時擁有調查的工具。請確保提前準備好專門的監控儀表板，清楚地顯示你正在遷移的消費者和生產者的當前和歷史狀態。
  • 確保你的自我託管的Kafka代理處於最新的補丁版本上
    由於我們的自營Kafka代理沒有使用最新的補丁版本，當我們多次嘗試增加message.max.bytes的值時，最終出現了生產事故（詳見本篇文章的複製瓶頸部分）。我的建議是，首先增加你的自營叢集Kafka Broker的版本。如果不是最新的，那至少也要增加到最新的補丁版本。

相關文章