Apache Pulsar 在騰訊云上的最佳實(shí)踐

本次 Meetup，騰訊云高級(jí)工程師林宇強(qiáng)為大家?guī)砹俗h題為《Apache Pulsar 在騰訊云上的最佳實(shí)踐》的精彩演講，接下來的篇幅將從系統(tǒng)架構(gòu)、設(shè)計(jì)思路、尋址服務(wù)、跨集群遷移、跨地域容災(zāi)幾個(gè)方面詳細(xì)為大家介紹 Apache Pulsar 在騰訊云上的最佳實(shí)踐。

Pulsar 系統(tǒng)架構(gòu)

上圖是一個(gè)很常見的 Pulsar 部署架構(gòu)，ZK 采用了騰訊云 TSE ZK；對(duì)接內(nèi)部的配置中心、CICD 平臺(tái)可以實(shí)現(xiàn)標(biāo)準(zhǔn)化部署，其余的 Bookie 和 Broker 和開源自建的部署模式差別不大。

這里需要介紹下騰訊云自研部分的診斷三件套：Metrics，Trace，日志采集。

Metrics：Broker 自研采集→上報(bào) Monitor 集群 Topic →Pulsar Sink 聚合預(yù)處理→騰訊云監(jiān)控。這里值得說明的是我們?cè)?Broker 和云監(jiān)控之間加了一層 Pulsar Broker 集群（Monitor 集群）作為緩沖，并使用 Pulsar 自帶的 Sink 來進(jìn)行 Metrics 數(shù)據(jù)的預(yù)處理，因?yàn)樵摫O(jiān)控鏈路是地域級(jí)別，比如廣州地區(qū)只部署一套，而對(duì)外提供業(yè)務(wù)服務(wù)的 Broker 集群數(shù)則規(guī)模較多，總的 Topic 數(shù)規(guī)模大，故而需要中間增加一層來緩解對(duì)云監(jiān)控的壓力，這是量變引發(fā)質(zhì)變的結(jié)果。

Trace：Broker 自研采集→Trace 日志→Filebeat 上報(bào)→APM，這也是演進(jìn)的結(jié)果。原先的架構(gòu)是 Skywalking 采集→內(nèi)存排隊(duì)上報(bào)→APM，這種架構(gòu)看似簡(jiǎn)單，但是當(dāng) Broker 的流量規(guī)模到達(dá)一定程度時(shí)，Trace 產(chǎn)生的速度高于上報(bào)的速度，導(dǎo)致內(nèi)存不斷增長進(jìn)而 OOM，因此 Trace 最終也是回歸原始，放棄 Skywalking，利用磁盤承受住短時(shí)的洪峰。當(dāng)然，也有一部分業(yè)務(wù)持續(xù)高流量，造成上報(bào)永遠(yuǎn)追不上 Trace 日志的產(chǎn)生，這種情況下也只有兩種做法：對(duì)于對(duì)消息軌跡不強(qiáng)求的業(yè)務(wù)，關(guān)閉 Trace 上報(bào)；對(duì)于流量大并且對(duì)軌跡仍然有要求的，只能通過升配的方式，調(diào)大 Filebeat 的可用核心數(shù)硬抗。

CLS日志采集：Metrics 和 Trace 由于和 Broker 自身的邏輯有強(qiáng)耦合，我們只能針對(duì) Broker 進(jìn)行定制化開發(fā)。但是日志采集是個(gè)普適性功能，因此我們直接采用騰訊云 CLS 來實(shí)現(xiàn)我們的目的：日志采集匯總，根據(jù)環(huán)境、地區(qū)、集群分類，關(guān)鍵字監(jiān)控，日志長時(shí)間存檔，關(guān)鍵字告警等。

Lookup Service：Lookup Service 是個(gè)地域級(jí)別的模塊，每個(gè)地區(qū)只部署一套，用于同一個(gè)地區(qū)所有 Broker 集群的路由、尋址功能，這個(gè)模塊后續(xù)會(huì)重點(diǎn)介紹。

設(shè)計(jì)背景及思路

介紹完 Pulsar 系統(tǒng)架構(gòu)，接下來介紹一下我們?cè)隍v訊云場(chǎng)景下所面臨的問題及解決思路。

• 完全容器化：包括 ZK、BK、Broker 以及其他周邊設(shè)施，全部部署在容器平臺(tái)上。

• 多環(huán)境、多地區(qū)：這是云服務(wù)提供商相比常規(guī)的業(yè)務(wù)。我們不僅有測(cè)試、預(yù)發(fā)、線上環(huán)境，線上環(huán)境還有多個(gè)地區(qū)，比如北京、上海、廣州、新加坡、香港等，每個(gè)地區(qū)分別有多個(gè)集群。

• 多可用區(qū)（同城多機(jī)房）：云自身自帶同城多機(jī)房，因此可以很方便做同城多活的容災(zāi)。

• 集群數(shù)量多、Topic 規(guī)模大：集群數(shù)量多、Topic 多，這對(duì)應(yīng)的我們要設(shè)計(jì)標(biāo)準(zhǔn)化部署流程，前面講到的監(jiān)控鏈路也是在這個(gè)背景下的產(chǎn)物。

• 產(chǎn)品形態(tài)多種多樣：產(chǎn)品形態(tài)對(duì)應(yīng)的是部署架構(gòu)上的差別，租戶、Broker、Bookie 之間的部署關(guān)系。

• 虛擬網(wǎng)絡(luò)，接入方式多樣：這是云服務(wù)提供商必然要面對(duì)的多網(wǎng)絡(luò)平面的問題。

• 支持集群熱遷移：在客戶端 url 不變的前提下，將租戶從集群1遷移到集群2，這也是云服務(wù)提供商所需的產(chǎn)品能力，比如將一個(gè)集群從標(biāo)準(zhǔn)版升級(jí)到專業(yè)版，那么就對(duì)應(yīng)租戶和底層物理資源分配上的遷移。

雖然 Pulsar Broker 可以稱作為云原生消息隊(duì)列，但是實(shí)際上，Broker在運(yùn)行時(shí)是有狀態(tài)的，比如：Topic 和 Broker 之間的歸屬關(guān)系。

因此我們?cè)谶M(jìn)行容器化的時(shí)候，整體的思路就是讓 Pod 和 VM 盡可能劃上等號(hào)，于是我們做了以下設(shè)計(jì)：

• 固定 IP：IP 不會(huì)隨著 Pod 的銷毀重建而隨機(jī)變化。

• Pod 與 Node 網(wǎng)絡(luò)拉平：針對(duì)騰訊云的場(chǎng)景，Client 一定不是運(yùn)行在 Broker 部署的容器集群上，如果不拉平的話，Lookup 時(shí)就得考慮容器網(wǎng)絡(luò)（Overlay）和基礎(chǔ)網(wǎng)絡(luò)（Underlay）之間的映射關(guān)系，會(huì)讓 Lookup 變得很復(fù)雜。

• 云盤：Pod 中掛的數(shù)據(jù)盤為云盤，真正的計(jì)算存儲(chǔ)分離。

• 與 CVM 共存：每個(gè) Pod 獨(dú)占一臺(tái) CVM，兩者 CPU 和內(nèi)存參數(shù)對(duì)等，這樣能最大程度保證 Pulsar 運(yùn)行時(shí)的物理隔離性，當(dāng)然，這也是騰訊云 EKS（TKE Serverless）天然提供的能力。另外，在容器化遷移過程中，同一個(gè)集群必然存在 Pod 節(jié)點(diǎn)和 CVM 節(jié)點(diǎn)同時(shí)存在，因此也需要考慮這二者之間的相容性。

• 優(yōu)雅停機(jī)：Pod 銷毀時(shí)，需要確保觸發(fā) Pulsar 的 Shutdown 邏輯，否則對(duì) Client 來說就會(huì)變得強(qiáng)烈感知，這也是容器場(chǎng)景和 CVM 場(chǎng)景在 CICD 流程上的差異導(dǎo)致需要注意的地方。

• Liveness probe 調(diào)優(yōu)：Liveness probe 也有一個(gè)有意思的點(diǎn)，由于 k8s 自身的各種健康檢查機(jī)制其實(shí)都是依賴于一個(gè)超時(shí)時(shí)間，如果 Broker 啟動(dòng)階段不能在約定超時(shí)時(shí)間內(nèi)返回正確的結(jié)果，k8s 容易誤判為失敗，造成 Broker 無限重啟。舉個(gè)例子：假設(shè)某個(gè) Broker 集群有幾萬個(gè) Topic，那么其 Broker 啟動(dòng)時(shí)間可能需要耗時(shí)90s以上，如果 Liveness 設(shè)置超時(shí)時(shí)間低于該值，就需要特別注意。當(dāng)然，這也是我們集群規(guī)模多導(dǎo)致，我們的不同集群可能是不同的業(yè)務(wù)場(chǎng)景在使用，因此很多類似的參數(shù)都需要針對(duì)性調(diào)優(yōu)。

• Helm 編排：Pulsar 的部署步驟其實(shí)比較繁雜，Bookie 部署、Bookie 初始化、Broker 部署、Broker 初始化，以及所需的 Secret、ConfigMap、網(wǎng)絡(luò)模塊等，要講這么多模塊有序的編排起來，Helm 當(dāng)然是最好的選擇。

Topic 數(shù)多會(huì)引發(fā)以下問題：

• ZK 元數(shù)據(jù)過多，負(fù)載高

• 啟動(dòng)變慢，K8s 就緒誤判

• Broker 重啟爆炸半徑大

• Lookup 性能變差

• 監(jiān)控采集聚合引發(fā)質(zhì)變

騰訊云 Pulsar 目前提供兩種產(chǎn)品形態(tài)，對(duì)應(yīng)底層就是部署架構(gòu)的多樣性，當(dāng)然，這會(huì)對(duì)應(yīng)最終每個(gè)實(shí)例的售賣價(jià)格和騰訊云本身的成本。

• 共享版：Bookie 和 Broker 都是共享的，本質(zhì)和一個(gè)公司自建一個(gè)集群給公司內(nèi)所有業(yè)務(wù)團(tuán)隊(duì)共用是一個(gè)模型，共享版下的一個(gè)實(shí)例對(duì)應(yīng) Pulsar 的一個(gè)租戶。

• 專業(yè)版：Bookie 和 Broker 都是獨(dú)占的，且該集群只有一個(gè)租戶，該租戶獨(dú)占完整的所有物理資源。

騰訊云 Pulsar 提供了多種網(wǎng)絡(luò)接入方式，網(wǎng)絡(luò)接入即 Broker 和 Client 之間的網(wǎng)絡(luò)連通關(guān)系。

• 內(nèi)網(wǎng)接入

內(nèi)網(wǎng)接入在本質(zhì)上和常規(guī)的公司內(nèi)自建使用類似，Broker 和 Client 都處在同一個(gè)內(nèi)網(wǎng)之中，且二者之間是完全互通的，Client 連接的 IP 也都是 Broker 的節(jié)點(diǎn)原始 IP，無任何網(wǎng)絡(luò)轉(zhuǎn)換。

• VPC 接入

VPC 即虛擬私有網(wǎng)絡(luò)，每個(gè)用戶可以創(chuàng)建多個(gè)VPC，每個(gè)VPC下又可以創(chuàng)建多個(gè)子網(wǎng)。想了解更多可查看：https://cloud.tencent.com/document/product/215/20046。

兩個(gè) VPC 之間通常是無法互通的，比如圖上的10.0.0.0/8和192.168.0.0/16，除非使用云聯(lián)網(wǎng)、對(duì)等連接等 VPC 之間的互通產(chǎn)品，但是這個(gè)不在我們的討論范圍。

如圖所示，Broker 部署在10.0.0.0/8，而 Client 在192.168.0.0/16，那么這時(shí)候，Client 想要訪問 Broker 就變得不可能。

在云網(wǎng)絡(luò)場(chǎng)景，VPC 提供了云虛擬網(wǎng)關(guān)（僅內(nèi)部組件）來支持兩個(gè) VPC 之間的互通，我們便稱之為跨網(wǎng)絡(luò)平面互通。

當(dāng)然，其本質(zhì)就是做網(wǎng)絡(luò)映射，比如：

• Broker1：在10.0.0.0/8的 IP 是10.2.0.1，我們通過云虛擬網(wǎng)關(guān)創(chuàng)建 Broker1 在192.168.0.0/16的 IP 為192.168.1.1，那么當(dāng) Client 在10.0.0.0/8中就需要用10.2.0.1訪問Broker1，當(dāng) Client 在192.168.0.0/16中就要用192.168.1.1來訪問 Broker1。

• 由于 Pulsar Client 的連接協(xié)議是先 Lookup 后直連的方式（這個(gè)可以參照后面的 Lookup 尋址時(shí)序圖），就對(duì) Broker 的 Lookup 接口提高了要求，Broker 就需要自動(dòng)化地判定：

  1、當(dāng) Client 來自于10.0.0.0/8網(wǎng)絡(luò)，返回10.2.0.1

  2、當(dāng) Client 來自于192.168.0.0/16網(wǎng)絡(luò)，返回192.168.1.1

這也就是 Pulsar 這個(gè)服務(wù)在云服務(wù)場(chǎng)景所要面對(duì)的問題。

• 公網(wǎng)接入

前面介紹了 VPC 接入，其實(shí)公網(wǎng)接入和 VPC 接入也是類似的。

唯一的差別是:

• VPC 接入：Broker 和 Client 處在兩個(gè)不同的內(nèi)網(wǎng)網(wǎng)絡(luò)平面。

• 公網(wǎng)接入：Broker 部署在內(nèi)網(wǎng)，而 Client 來自于公網(wǎng)，可以直接把公網(wǎng)看作一個(gè)特殊的 VPC 就很好理解了。

尋址服務(wù)

下面我們來介紹下騰訊云的尋址服務(wù)的思路來源，也是尋址服務(wù)的價(jià)值所在。

我們看下 RocketMQ 的服務(wù)，其架構(gòu)分為 NameServer 和 Broker。

• NameServer 保存了集群的元數(shù)據(jù)：Topic 和 Broker 之間的歸屬關(guān)系，這樣就可以動(dòng)態(tài)地配置 Topic 和 Broker 之間的從屬關(guān)系，也可以將 Topic 在不同的 Broker 集群之間調(diào)度。

• RocketMQ 同 Pulsar 一樣，也有類似 Lookup 的尋址流程，只不過 RocketMQ Client 尋址的請(qǐng)求對(duì)象是 NameServer，而 Pulsar Client 尋址的請(qǐng)求對(duì)象是 Broker，從這方面看來，架構(gòu)上可以理解為 Pulsar Broker 相當(dāng)于是 RocketMQ NameServer 和 RocketMQ Broker 結(jié)合到了一起。

優(yōu)缺點(diǎn)：

Pulsar 這樣做部署架構(gòu)簡(jiǎn)單，不會(huì)額外多出一個(gè) NameServer 服務(wù)，但是同樣也失去了 Topic 在物理集群之間的調(diào)度能力。

RocketMQ 雖然多出了一個(gè)模塊，但是其提供的集群調(diào)度能力，是一種非常重要的運(yùn)維能力。

這種調(diào)度能力，恰恰是云服務(wù)所需要的，有了這種調(diào)度能力，我們的云服務(wù)才能對(duì)集群有可運(yùn)維性和靈活的資源調(diào)度方式。

如前面所說，在云服務(wù)場(chǎng)景，針對(duì) Pulsar Broker，我們需要提供的內(nèi)網(wǎng)、VPC、公網(wǎng)三種網(wǎng)絡(luò)接入場(chǎng)景，和 Pulsar Broker 本身提供的 Lookup 能力的矛盾。使用尋址模塊，便有以下好處：

• 將多網(wǎng)絡(luò)接入這種云服務(wù)場(chǎng)景收斂在尋址服務(wù)內(nèi)核中，而 Broker 仍然只提供最純粹的內(nèi)網(wǎng)服務(wù)，更好地保持 Broker 的原始能力以及與開源的銜接。

• 動(dòng)態(tài)地增減接入點(diǎn)（即不同的網(wǎng)絡(luò)接入方式的概念名稱），對(duì)于一個(gè) Pulsar 集群來說增加、減少一個(gè)內(nèi)網(wǎng)、VPC、公網(wǎng)接入點(diǎn)時(shí)，不需要對(duì) Broker 做任何變動(dòng)。

• 實(shí)現(xiàn)擴(kuò)縮容的自動(dòng)化和無感知化，Broker 的擴(kuò)縮容，等同的也需要對(duì)該集群的所有接入點(diǎn)中的網(wǎng)絡(luò)映射進(jìn)行擴(kuò)縮容變更，由于尋址模塊的存在，這部分全部收斂在該模塊，Broker 的擴(kuò)縮容不需要對(duì)存量節(jié)點(diǎn)做任何變動(dòng)。

前面介紹了很多尋址模塊和尋址流程，這里來重點(diǎn)介紹下 Pulsar-Client 的尋址時(shí)序，來補(bǔ)充下對(duì)前面的介紹，以及科普下 Pulsar Client 的機(jī)制：

• 第一步：獲取 Topic 分區(qū)數(shù)：Client→CLB→Broker，一對(duì)多指的是該請(qǐng)求落到 CLB 后面的任意一臺(tái) Broker 都能對(duì)等返回正確結(jié)果。

• 第二步：?jiǎn)畏謪^(qū) Topic Lookup：針對(duì)單個(gè)分區(qū)進(jìn)行 Lookup，詢問該 Topic 當(dāng)前的 Owner Broker 地址，同樣是一對(duì)多，不同 Broker 之間提供對(duì)等服務(wù)。

• 第三步：基于第二步返回的該 Topic 分區(qū)的 Owner Broker 地址，進(jìn)行直連，隨后進(jìn)行消息收發(fā)。一對(duì)一，特指此時(shí)的直連必須精準(zhǔn)連接 Broker 集群中的某臺(tái) Broker，比如 Broker-2，連接別的 Broker 則會(huì)連接失敗。

這就是 Pulsar-Client 初始化一個(gè) Producer/Consumer 的步驟。

我們的尋址模塊切入點(diǎn)在哪呢？

就是第一和第二步，如圖所示，在這兩個(gè)步驟中間加入一層代理層，這樣就可以在尋址返回結(jié)果上針對(duì)多網(wǎng)絡(luò)接入、Topic 和物理集群從屬關(guān)系調(diào)度上做一些篡改，以達(dá)到我們的目的。

上圖是我們加入尋址模塊后，Pulsar 架構(gòu)上的改變，整個(gè)架構(gòu)就變得和 RocketMQ 有點(diǎn)類似，有一個(gè)中央元數(shù)據(jù)服務(wù)用來管理 Topic 資源和物理計(jì)算資源之間的關(guān)系。

跨集群遷移

前面鋪墊了這么多，介紹了尋址模塊以及架構(gòu)上的優(yōu)化，接下來介紹下在此之上我們所做的產(chǎn)品化能力——跨集群遷移。

跨集群遷移特指一個(gè)租戶從物理集群1遷移到物理集群2，兩個(gè)集群同時(shí)提供服務(wù)，在線熱切換，Client 輕微感知。

如圖所示，整個(gè)流程也很簡(jiǎn)單，尋址服務(wù)保存了租戶和物理集群的路由關(guān)系，路由關(guān)系一變更，即集群遷移變更。

基于 Pulsar Lookup 尋址的協(xié)議，路由關(guān)系的切換粒度可以做到租戶粒度、Namespace 粒度、Topic 粒度、分區(qū)粒度。

切換的方式：路由切換+Topic unload

機(jī)制上來說，這個(gè)切換流程很簡(jiǎn)單，難點(diǎn)在前置準(zhǔn)備工作上：

• 元數(shù)據(jù)遷移：租戶、Namespace、Policies、Topic、訂閱、Token 等。

• 消息雙向同步：切換過程中兩個(gè)集群同時(shí)提供服務(wù)，為了提供可回滾能力，發(fā)送的消息需要在兩個(gè)集群之間雙向同步，保證兩個(gè)集群都有完整的所有消息。

• 進(jìn)度同步：每個(gè) Topic 的訂閱消費(fèi)進(jìn)度不同，需要定時(shí)同步，盡量較少切換過程中的重復(fù)消費(fèi)。

消息同步比較簡(jiǎn)單，我們采用了 Pulsar 自帶的 GEO-Replicator 功能，這里不再贅述。

這里簡(jiǎn)單介紹下進(jìn)度同步的機(jī)制。

1. 消息遷移：在消息同步階段（GEO-Replicator）會(huì)在消息頭部攜帶消息的源集群里的消息 IP。

2. 定時(shí)同步：定時(shí)將源集群的消費(fèi)進(jìn)度同步到目標(biāo)集群，基于 Compact topic 同步和持久化。

3. 進(jìn)度緩存：目標(biāo)集群讀取 Compact topic 中的消費(fèi)進(jìn)度信息，將消費(fèi)進(jìn)度加載到內(nèi)存。

4. 投遞過濾：在 Pulsar 的投遞流程 Dispatcher 處理過程中，過濾掉本要投遞，但是已經(jīng)在源集群進(jìn)度中投遞過的。

跨地區(qū)容災(zāi)

地區(qū)容災(zāi)，也是我們基于尋址服務(wù)的架構(gòu)改進(jìn)后，所開發(fā)出的產(chǎn)品化能力。

本質(zhì)和跨集群遷移類似，但是由于跨地區(qū)的網(wǎng)絡(luò)時(shí)延問題，在側(cè)重點(diǎn)上有所不同：

如圖所示，假設(shè)我們的 Pulsar 實(shí)例在廣州地區(qū)，Client 也在廣州地區(qū)，但是由于不可抗力，導(dǎo)致廣州地區(qū)的 Pulsar 實(shí)例全部宕機(jī)，并且短時(shí)間內(nèi)無法迅速恢復(fù)，我們可以暫時(shí)將 Client 的流量切到上海地區(qū)的容災(zāi)實(shí)例，來保證 Client 在線業(yè)務(wù)的迅速恢復(fù)。

• 同一時(shí)間只有一個(gè)集群提供服務(wù)。

• 短時(shí)間、臨時(shí)性切換：由于跨地區(qū)時(shí)延的不可控（特別是國外地區(qū)），容災(zāi)機(jī)制一定是臨時(shí)的，待廣州地區(qū)恢復(fù)后，理應(yīng)盡快將流量回切。

• 元數(shù)據(jù)定時(shí)同步：因?yàn)槲覀儫o法預(yù)測(cè)廣州集群何時(shí)宕機(jī)，且該場(chǎng)景的使用頻度較低，這是一種權(quán)衡的結(jié)果。

• 消息、進(jìn)度不同步：面對(duì)的是廣州集群全部宕機(jī)，此時(shí)廣州集群磁盤中的數(shù)據(jù)暫時(shí)無法讀取，另一個(gè)原因就是跨地區(qū)時(shí)延大，做實(shí)時(shí)消息同步的性價(jià)比太低。

• 切換：基于域名解析切換，因?yàn)閺V州和上海的尋址服務(wù)互相獨(dú)立隔離，這個(gè)時(shí)候如果廣州集群有堆積，那部分只能繼續(xù)堆積著，等廣州地區(qū)恢復(fù)了才有機(jī)會(huì)重新消費(fèi)。

• 回切：由于上海集群只是用來緊急容災(zāi)，在廣州集群恢復(fù)后，必定要重新切回廣州，回切的過程中比較重要的就是上海集群上堆積的消息，需要回寫到廣州，這個(gè)過程中不可避免會(huì)出現(xiàn)一部分重復(fù)消費(fèi)和消費(fèi)順序錯(cuò)亂（同一分區(qū)內(nèi)）。

該方案是面對(duì)地區(qū)級(jí)別災(zāi)難場(chǎng)景下的容災(zāi)，因?yàn)槊總€(gè)地區(qū)本身已經(jīng)是多可用區(qū)部署（同城多機(jī)房），因此整個(gè)地區(qū)不可用的概率較低，因此跨地區(qū)容災(zāi)的整個(gè)產(chǎn)品設(shè)計(jì)側(cè)重主要用于應(yīng)急，而不是為了像跨集群遷移一樣的熱切換，需要做到非常嚴(yán)格的雙向同步。

總結(jié)

我們先從騰訊云 Pulsar 的整體架構(gòu)講起，介紹了在騰訊云的場(chǎng)景下所需要面對(duì)的問題，引出了尋址模塊（Lookup Service），并介紹了尋址模塊的引入對(duì)于 Pulsar 的部署架構(gòu)上的優(yōu)化。隨后介紹了 Lookup Service 解決的兩個(gè)核心問題：多網(wǎng)絡(luò) Lookup 和集群間調(diào)度，并保證對(duì)客戶端接入的無感知和對(duì)架構(gòu)的低侵入性。由于尋址模塊的存在，我們便能基于它做進(jìn)一步的產(chǎn)品化能力，跨集群遷移和跨地區(qū)容災(zāi)，從而能夠在不同級(jí)別的災(zāi)難場(chǎng)景下都能提供相應(yīng)的修復(fù)措施和運(yùn)維能力。

未來，我們還會(huì)繼續(xù)在容災(zāi)能力、Pulsar 周邊生態(tài)對(duì)接、存儲(chǔ)優(yōu)化等方面繼續(xù)努力，以提供成本更低、穩(wěn)定性更高的 Pulsar 產(chǎn)品。

掃描下方二維碼關(guān)注本公眾號(hào)，

了解更多微服務(wù)、消息隊(duì)列的相關(guān)信息！

解鎖超多鵝廠周邊！