從 Kafka 遷移至 Pub/Sub

如果您考慮從自行管理的 Apache Kafka 遷移至 Pub/Sub，這份文件就很實用，因為它可以協助您查看及考量功能、價格和用途。每個部分都會說明常見的 Kafka 用途，並提供實用指南，協助您在 Pub/Sub 中實現相同功能。

Pub/Sub 簡介

Pub/Sub 是非同步訊息傳遞服務。Pub/Sub 會分離產生事件的服務與處理事件的服務。您可以將 Pub/Sub 用於訊息導向中介軟體，或用於串流分析管道的事件擷取和傳送機制。在兩種情況下，發布端應用程式都會建立訊息並傳送至主題。訂閱者應用程式可為主題建立訂閱項目，以便從中接收訊息。訂閱項目是一種具名實體，代表接收特定主題相關訊息的意願。

Pub/Sub 會在所有Google Cloud 區域中執行。Pub/Sub 會將發布者流量導向最近的 Google Cloud 資料中心，該資料中心允許儲存資料，如資源位置限制政策中所定義。

Pub/Sub 可整合許多 Google Cloud 服務，例如 Dataflow、Cloud Storage 和 Cloud Run。您可以將這些服務設為資料來源，以便將訊息發布至 Pub/Sub，或設為資料接收器，以便接收來自 Pub/Sub 的訊息。

Kafka 總覽

Apache Kafka 是開放原始碼分散式事件串流平台，可讓應用程式發布、訂閱、儲存及處理事件串流。Kafka 伺服器會做為機器叢集執行，用於與用戶端應用程式互動，以讀取、寫入及處理事件。您可以使用 Kafka 分離應用程式、傳送及接收訊息、追蹤活動、匯總記錄資料和處理資料串流。

在 Kafka 叢集中，叢集中的部分節點會指定為代理程式。仲介會接收供應商傳送的訊息，並將訊息儲存到磁碟。儲存的訊息會依主題分類，並在叢集中的多個不同中介軟體中進行分區。發布到主題的新事件會附加至其中一個主題區段的結尾。接著，消費者可以從中介程擷取訊息，這些訊息會從磁碟讀取，然後傳送給消費者。

瞭解 Kafka 和 Pub/Sub 的差異

下圖顯示 Kafka 和 Pub/Sub 的縮放策略差異：

使用 Kafka 的分區和 Pub/Sub 的無分區來進行調整策略。

在上圖中，每個 M 代表一則訊息。Kafka 代理程式會管理多個有序的訊息分區，這些分區以訊息的水平列表示。取用者會讀取特定分割區的訊息，該分割區的容量取決於代管該分割區的機器。Pub/Sub 沒有分割區，取而代之的是，消費者會從可根據需求自動調整的分割區讀取主題。您可以根據處理預期使用者負載所需的分區數量，設定每個 Kafka 主題。Pub/Sub 會視需求自動調整資源配置。

比較功能

下表比較 Apache Kafka 和 Pub/Sub 的功能：

Apache Kafka Pub/Sub
訊息排序 在分區內是 是的，在主題中
訊息簡化 是 是，使用 Dataflow
推送訂閱 否 是
無效信件佇列
(無法處理的訊息佇列)		 自 2.0 版起 是
交易 是 否
訊息儲存空間 僅受機器可用儲存空間限制 31 天：主題最多可保留 31 天的已發布訊息 (包括已確認的訊息)。
您可以透過主題的 `message_retention_duration` 屬性設定這項屬性。
重播訊息 是 是
縣市 本機叢集可使用 MirrorMaker 進行複製 全球分散式服務，提供可設定的訊息儲存位置
記錄和監控 自行管理 使用 Cloud Logging 和 Cloud Monitoring 進行自動化
串流處理 可以，使用 KSQL 可以，只要使用 Dataflow

瞭解 Pub/Sub 訊息儲存和重播

根據預設，Pub/Sub 會將未確認訊息保留最多 7 天，但您也可以設定 Pub/Sub 訂閱項目保留已確認訊息，最多 7 天，具體取決於訂閱項目中最舊訊息 (已確認或未確認) 的年齡。保留已確認的訊息後，您就可以根據時間戳記重播部分或所有這些訊息。根據時間戳記重播訊息時，系統會將時間戳記之後收到的所有訊息標示為未確認。系統會重新傳送未確認的訊息。

您可以視需要建立個別訂閱項目的快照，而無須事先設定訂閱項目。舉例來說，您可以在部署新的訂閱者程式碼時建立快照，因為您可能需要從意外或錯誤的確認訊息中復原。

內建無效信件主題的安全機制

Pub/Sub 提供的功能類似於 Kafka 2.0 錯誤處理，以及 Kafka Connect 處理死信主題的方式。如要通知 Pub/Sub 訊息已成功傳送，Pub/Sub 主題的訂閱者可以確認所收到及處理的訊息。如果訂閱者一段時間內無法處理訊息，Pub/Sub 會自動將這些訊息轉送至死信主題，並儲存這些訊息以供日後存取。您可以設定 Pub/Sub 嘗試傳送訊息的次數，然後再將訊息傳送至無效信件主題。

使用 Dataflow 在 Pub/Sub 中去除重複的訊息

Pub/Sub 會為每個訂閱項目傳送每個發布的訊息至少一次。訂閱者通常需要遵循冪等原則來處理訊息，才能進行多次提交。如果現有的訂閱者無法以冪等的方式運作，您可以整合 Dataflow 來去除重複訊息。如果訂閱者收到重複訊息的頻率很高，表示他們可能沒有正確回覆訊息，或是回覆期限太短。

Pub/Sub 中的訊息排序

如果 Kafka 訂閱者應用程式依賴訊息排序，您可以在使用排序鍵時，在 Pub/Sub 中支援這項需求。目前，特定區域中發布的訊息，可保證順序正確。如要充分利用訊息排序功能，請確保發布者和訂閱者使用位置端點，將訊息傳送至正確的區域。

瞭解自行代管服務和代管服務的責任

下表比較哪些功能是使用 Kafka 自行代管，以及哪些功能是 Google 使用 Pub/Sub 管理：

Apache Kafka Pub/Sub
可用性 手動將 Kafka 部署到其他位置 部署在所有 Google Cloud 區域，以提供高可用性和低延遲
災難復原 設計及維護自己的備份和複製作業 由 Google 管理
基礎建設管理 手動部署及操作虛擬機器 (VM) 或機器。您必須維持一致的版本和修補程式。 由 Google 管理
處理能力規劃 事先手動規劃儲存空間和運算需求 由 Google 管理
支援 無 提供 24 小時值班人員和支援服務

Pub/Sub 訊息大小限制和解決方法

在處理大量小型訊息時，Kafka 和 Pub/Sub 的效能都相當出色。Kafka 對訊息大小沒有硬性限制，可讓您設定允許的訊息大小，而 Pub/Sub 則將訊息大小限制在 10 MB。您可以先將物件儲存在 Cloud Storage 中，間接傳送較大的酬載，如下圖所示：

發布者會將物件儲存在 Cloud Storage 中。

上圖顯示，當發布者將物件儲存在 Cloud Storage 時，會發布含有該已儲存物件網址的訊息。當訂閱端接收含有網址的訊息時，就會從 Cloud Storage 下載檔案，並照常繼續處理。

Kafka 和 Pub/Sub 費用比較

在 Pub/Sub 中，預估和管理成本的方式與 Kafka 不同。在內部或雲端部署 Kafka 叢集的費用包括機器、磁碟、網路、傳入和傳出訊息的費用，以及管理和維護這些系統及其相關基礎架構的額外成本。管理 Kafka 叢集時，通常需要手動升級及修補機器，也需要規劃叢集容量，而且實作災難復原作業需要大量規劃和測試。您必須推斷並匯總所有這些費用，才能判斷真正的總持有成本 (TCO)。

Pub/Sub 定價包括從發布端傳輸至訂閱端的資料，以及暫時儲存未確認訊息的費用。您只需為實際使用的資源付費，系統會根據應用程式和預算需求自動調整容量。

以可靠性為目標的架構設計

Pub/Sub 是一種全球管理服務，可在所有Google Cloud 區域中執行。Pub/Sub 主題是全域主題，也就是說，您可以在任何 Google Cloud 位置查看及存取這些主題。不過，任何指定訊息都會儲存在單一 Google Cloud 區域中，該區域必須最靠近發布者，且符合資源位置政策規定。因此，主題的訊息可以儲存在 Google Cloud的不同區域中。Pub/Sub 可抵禦區域性中斷情形。在區域停機期間，您可能無法存取儲存在該區域的訊息，直到服務恢復後才可存取。視可用性需求而定，您可以在發生區域性中斷服務時，使用位置服務端點實作備援政策。

安全性和驗證

Apache Kafka 支援多種驗證機制，包括以用戶端憑證為基礎的驗證、Kerberos、LDAP 和使用者名稱和密碼。在授權方面，Kafka 支援使用存取控制清單 (ACL) 來判斷哪些產生器和消費者可以存取哪些主題。

Pub/Sub 支援 Google Cloud 使用者帳戶和服務帳戶的驗證。 Google Cloud中的身分與存取權管理 (IAM) 會控管 Pub/Sub 主題和訂閱項目的精細存取權。使用使用者帳戶時，Pub/Sub 作業會受到速率限制。如果需要進行大量交易，您可以使用服務帳戶與 Pub/Sub 互動。

規劃遷移至 Pub/Sub

任何遷移至 Google Cloud 的作業都會先評估工作負載，然後建構基礎。

使用 Pub/Sub Kafka Connector 進行分階段遷移

Pub/Sub Kafka 連接器可讓您分階段將 Kafka 基礎架構遷移至 Pub/Sub。

您可以設定 Pub/Sub 連接器，將特定主題的所有訊息從 Kafka 轉送至 Pub/Sub。接著，您可以更新個別訂閱者應用程式，讓這些應用程式接收 Pub/Sub 中的主題訊息，同時發布者應用程式繼續將訊息發布至 Kafka。這種分階段做法可讓您以迭代方式更新、測試及監控訂閱者應用程式，進而降低錯誤和停機風險。

本節提供兩個圖表，可協助您以兩個不同階段呈現這個程序。下圖顯示遷移階段的設定：

遷移的第一階段。

在上圖中，現有的訂閱者會繼續接收來自 Kafka 的訊息，您則逐一更新訂閱者，改為接收來自 Pub/Sub 的訊息。

特定主題的所有訂閱者都已更新為接收 Pub/Sub 訊息後，您就可以更新該主題的發布端應用程式，以便將訊息發布至 Pub/Sub。接著，您可以測試及監控端對端訊息流程，以便驗證設定。

下圖顯示所有訂閱者接收 Pub/Sub 訊息後的設定：

遷移作業的第二階段。

隨著時間推移，所有發布端都會更新為直接發布至 Pub/Sub，這樣遷移作業就完成了。許多團隊都會使用這種方法並行更新應用程式。Kafka 可與 Pub/Sub 共存，時間長度視需要而定，以確保遷移作業順利進行。

監控 Pub/Sub

在從 Kafka 遷移至 Pub/Sub 的過程中和之後，請務必監控應用程式。Pub/Sub 會使用 Cloud Monitoring 匯出指標，協助您掌握應用程式的效能、運作時間和整體健康狀態。舉例來說，你可以監控未送達郵件的數量，確保訂閱者能持續收到郵件。如要監控未送達的訊息，您可以在最久未確認訊息的時間戳記超過特定門檻時，建立快訊。您也可以監控傳送要求次數指標並檢查回應碼，監控 Pub/Sub 服務本身的健康狀況。

後續步驟