宣布 Eventing RabbitMQ 轉為正式版 (GA) ¶

發佈時間：2022-08-02，修訂時間：2024-01-17

宣布 Eventing RabbitMQ 轉為正式版 (GA)¶

作者：Gab Satchi，VMware 資深軟體工程師

我們很高興宣布 Eventing RabbitMQ 現在正式上市 (GA)。有了這個里程碑，所提供的 API 在未來迭代中將保持穩定。您可以在此處找到快速入門。

主要功能¶

使用任何 RabbitMQ 執行個體¶

Eventing RabbitMQ 可與使用 RabbitMQ Cluster Kubernetes Operator 佈建的 RabbitMQ 叢集良好運作，但也可以設定為使用透過其他方式佈建的 RabbitMQ 執行個體。RabbitMQ Broker 和 Source 都包含一個 rabbitmqClusterReference 欄位，可以參考使用 Operator 建立的 RabbitMQ 叢集，或是包含 RabbitMQ 執行個體認證的 Secret。完整的文件可以在此處找到。

平行處理和事件排序¶

RabbitMQ 預設使用先進先出 (FIFO) 的事件排序模式。然而，在某些使用案例中，可能不需要排序，而且可能會偏好較高的輸送量。RabbitMQ Broker 和 Source 都包含一個 parallelism 註解，可以設定為平行處理多個訊息。您可以在此處找到說明 FIFO 和高輸送量模式的範例。

仲裁佇列¶

仲裁佇列是一種容錯、複寫的佇列類型，用於多節點設定。RabbitMQ 預設使用仲裁佇列。可以針對 RabbitMQ Broker 設定佇列類型，任何訂閱 Broker 的觸發器都會繼承佇列類型。完整的文件可以在此處找到。

指標¶

Eventing RabbitMQ 會鏡像此處找到的部分事件處理指標。由於單一租戶性質，Broker - Filter 指標不適用。

架構¶

Eventing RabbitMQ 遵循單一租戶模型，其中會為每個 Broker、Trigger 和 Source 物件建立專用資源。雖然這種方法有一些額外負荷，但也存在一些好處：- Pod 可以自動調整規模，以處理給定 Broker、Trigger 或 Source 的預期流量。- 使用者現有的原則和角色可以用於角色型存取控制 (RBAC)。- 提高叢集上正在執行的透明度。

Eventing RabbitMQ broker architecture

建立 Broker 會自動建立一個可以接收 CloudEvents 的輸入 Pod，以及透過 RabbitMQ 系統路由 CloudEvents 所需的 RabbitMQ 資源。觸發器會建立從 RabbitMQ 取用訊息的分配器 Pod，並將 CloudEvents 傳送至可定址的資源。

Eventing RabbitMQ source architecture

RabbitMQSource 物件可以從佇列擷取訊息、將其轉換為 CloudEvents，並將這些 CloudEvents 傳送至可定址的消費者。

效能¶

每個版本都會執行一套效能測試，以確保足夠的輸送量和可接受的延遲。您可以在此處找到最新執行結果。

採用者¶

Eventing RabbitMQ 目前由 VMware Event Broker Appliance (VEBA)、Cloud Native Runtimes (CNR) 使用。

意見反應¶

我們將感謝社群對試用此新版本的意見反應，並回報您可能有的任何問題或查詢。您可以在此處建立新的問題。