從 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 天，具體保留時間取決於訂閱項目中最舊訊息 (已確認或未確認) 的存在時間。保留已確認的訊息後，您就能根據時間戳記重播部分或所有訊息。根據時間戳記重播訊息時，系統會將時間戳記之後收到的所有訊息標示為未確認。然後重新傳送未確認的訊息。

您可以視需要建立快照，不必預先設定訂閱項目。舉例來說，部署新的訂閱者程式碼時，您可以建立快照，因為您可能需要從非預期或錯誤的確認中復原。

透過 dead-letter 主題內建安全機制

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

使用 Dataflow 在 Pub/Sub 中重複資料刪除訊息

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

Pub/Sub 中的訊息排序

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

瞭解自行託管與代管服務的責任

下表比較了 Kafka 自行代管的功能，以及使用 Pub/Sub 時由 Google 管理的功能：

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 使用者帳戶和服務帳戶。Pub/Sub 主題和訂閱項目的精細存取權控管，是由 Identity and Access Management (IAM) Google Cloud控管。使用使用者帳戶時，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 服務本身的健康狀態。

後續步驟