本期 TGIP-CN 直播，我們邀請到了來自中國移動雲能力中心的張浩，他在 AMQP on Pulsar 專案中參與了很多，也一起協助推進了專案的開發與更新，接下來的內容主要基於此次直播中關於 AoP 的一些介紹和細節乾貨。

相關背景

首先一個很重要的問題，就是我們移動內部為什麼要自己做 AMQP 訊息佇列？答案很明顯。

一是為了滿足內部元件的需求，中國移動是 OpenStack 的重度使用使用者，而 OpenStack 中預設使用 RabbitMQ 作為 RPC 通訊元件。使用 RabbitMQ 在線上環境部署和運維中，遇到了很多問題。由於我們中介軟體團隊主要採用 Java 架構，圍繞 RabbitMQ 只能做一些外圍改造。

同時，中國移動的公有云中有很多需要使用 AMQP 訊息佇列的客戶，但是現有的 RabbitMQ 不滿足雲訪問的條件，因此，中國移動的中介軟體團隊開始研究 AMQP 訊息佇列。在對比 Qpid，RocketMQ 和 Pulsar 之後，發現 Pulsar 的計算分離儲存架構非常適合目前的需求。

同時在對 Pulsar 進行調研之後，發現 StreamNative 已經開源了 KoP，這更加確定了我們要基於 Pulsar 開發 AMQP 的可行性。同時 Pulsar 社群活躍度很高，社群方面對本專案的支援力度很高。

所以，我們便開啟了與 StreamNative 共同開發 AoP 協議處理外掛的征程，攜手實現將 AoP 從 0 到 1 的蛻變。

AMQP 0.9.1

AMQP 0.9.1(高階訊息佇列協議)是一種訊息傳遞協議，它允許符合標準的客戶端應用程式與符合標準的訊息傳遞中介軟體代理進行通訊。

在 AoP 的初始版本中，首先實現了 0.9.1 版本協議。在這裡主要有以下幾個概念需要大家理解：

• VirtualHost：資源的邏輯分組以及隔離
• Exchange：訊息路由
• Queue：訊息儲存
• Binding：路由規則

大體操作流程如上圖：首先訊息會發送到 Exchange 中，後根據不同的設定/型別等路由到不同的 queue 中。消費者消費訊息時，是直接從 queue 中進行。

Protocol Handler

在瞭解了 AMQP 0.9.1 的模型後，我們來看下 AoP 實現依賴的元件——Protocol Handler。

在 Pulsar 架構中，基於 Managed Leger 已經實現了一套分散式的流程封裝，包括如何去儲存訊息和防止訊息丟失。Broker 本身也實現了一些特性，比如 load-balancer、geo-replicator 等。

上層中的 Protocol Handler 屬於輕量級工具，主要處理 Pulsar 中生產者和消費者傳送出來的 TCP 請求，將其轉化為可讀取狀態的操作。

Pulsar 2.5 版本後，將 Protocol Handler 介面單獨脫離了出來，利用這個框架就可以單獨實現自定義協議的轉換，比如 Kafka、AMQP、MQTT 等。實現了不同協議的 Protocol Handler，Pulsar broker 就具有讀寫/解析其他協議的能力。下圖為 AMQP on Pulsar 採用的架構模型。

如何實現 AoP

具體實現主要是四個部分：模型轉換（將 AMQP 模型接入到 Pulsar 內部）、訊息傳送、訊息消費和 Proxy。

模型轉換

AMQP 0.9.1 引入了一些基礎概念，如 Exchagne、Queue 等。這些與 Pulsar 的模型有著較大的區別。所以我們需要找到一種方法，支援利用 Pulsar 現有的一些特徵，並將它們聯絡在一起。下圖展示了訊息在 AoP 中的流轉，並討論了關於訊息持久化，訊息路由，訊息投遞的細節。