Cloud Native 19 min read

How ApsaraMQ’s Serverless Architecture Powers AI with Event‑Driven Messaging

The talk outlines ApsaraMQ’s journey to a fully serverless, cloud‑native messaging platform, detailing its compute‑storage separation, stateless proxy functions, RDMA‑enhanced performance, elastic scaling mechanisms, and how its event‑driven architecture empowers real‑time AI applications through seamless data vectorization.

Alibaba Cloud Native
Alibaba Cloud Native
Alibaba Cloud Native
How ApsaraMQ’s Serverless Architecture Powers AI with Event‑Driven Messaging

Evolution Timeline

ApsaraMQ originated as RocketMQ inside Alibaba in 2012, was open‑sourced on GitHub, donated to Apache in 2016, and subsequently expanded to support multiple protocols (RocketMQ, Kafka, RabbitMQ, MQTT). The product family achieved full serverless upgrade in 2023 and continues to enhance sub‑second elasticity, RDMA‑based CPU overhead reduction, and AI‑native event‑driven use cases.

2012 – Internal creation of RocketMQ and open‑source release.

2016 – Commercial launch and donation to Apache.

2017 – Apache TLP incubation; version 4.0 added ordered, transactional, and delayed messages.

2018 – Commercial Kafka‑based offering.

2019 – RabbitMQ and MQTT products added.

2021 – EventBridge event bus entered public testing.

2023 – All series completed serverless upgrade built on compute‑storage separation.

2024 – Focus on sub‑second elasticity, seamless scaling, RDMA integration, and AI‑native workloads.

Compute‑Storage Separation Architecture

The architecture is fully cloud‑native, deployed on Kubernetes (K8s) and leverages IaaS elasticity. It consists of four logical layers:

Infrastructure layer: K8s provides elastic compute resources and integrates OpenTelemetry for standardized metrics, tracing, and logging.

Storage layer: Built on Alibaba Cloud Feitian Pangu, offering leaderless nodes, flexible replica counts, and a cost‑reliability trade‑off.

Stateless compute (Proxy) layer: Handles access control, model abstraction, protocol adaptation, and message governance independent of storage.

Client access layer: A lightweight gRPC‑based SDK that complements existing rich clients.

Stateless Proxy Core Functions

Multi‑protocol adaptation: Detects remoting, gRPC, HTTP, etc., and translates them to the internal remoting protocol used by Brokers and NameServers.

Traffic routing & distribution: Classifies client traffic dimensions and forwards requests to the appropriate Broker cluster.

General business extensions: Provides access control, message tracing, and observability.

Topic route proxy: Answers client queries for detailed topic routing information.

Consumer model upgrade: Introduces a Pop consumption mode to avoid single‑client bottlenecks.

Serverless Capability Enhancements

The serverless transformation delivers three primary benefits: sub‑second elasticity without capacity planning, pay‑as‑you‑go cost model, and reduced operational effort. Core technical goals include:

Multi‑tenant and security isolation for traffic segregation.

Physical pre‑elasticity combined with logical elasticity for rapid scaling.

RDMA integration to cut CPU overhead between compute and storage layers.

Graceful up/down scaling via gRPC GOAWAY and extended Remoting protocols.

Intelligent traffic scheduling and smooth topic migration to control resource water‑level.

RDMA‑Accelerated Communication

RDMA (Remote Direct Memory Access) provides zero‑copy, kernel‑bypass, and CPU‑offload capabilities. By inserting an RdmaEventLoop adapter between the Proxy and storage Brokers, data moves directly from user space to the RDMA NIC, eliminating the TCP/IP copy path.

Benchmark results show:

26.7% CPU reduction on storage Brokers.

10.1% CPU reduction on the Proxy.

23.8% lower round‑trip latency for compute‑to‑storage communication.

Graceful Scaling and Down‑Scaling

During a scaling event, the stateless Proxy manages TCP long‑connection semantics. The shutdown sequence is:

SLB removes the retiring Proxy from the load‑balancing pool, preventing new connections.

The Proxy enters a draining state and returns a GOAWAY response for any new request.

Clients receiving GOAWAY close the existing connection and reconnect through SLB, which routes them to a healthy Proxy.

After a short grace period, lingering connections on the retired Proxy naturally close, achieving zero‑impact down‑scaling.

AI‑Native Event‑Driven Architecture

The platform supports real‑time processing pipelines for AI workloads:

Streaming data (RocketMQ, Kafka, OSS) is transformed into embeddings and stored in a vector database for low‑latency AI retrieval.

Active Pop consumption mode allows per‑message TTL configuration, enabling fine‑grained consumption windows.

Priority queues schedule multiple large‑model services according to business importance.

Serverless elasticity models (pure pay‑as‑you‑go, reserved + burst, timed elasticity) match AI traffic patterns.

EventBridge Vectorization for AI

EventBridge’s Event Streaming framework listens to heterogeneous sources (RocketMQ, Kafka, OSS), performs text tokenization, slicing, and vectorization, then writes the vectors to a vector database. This enables AI applications to perform real‑time, multi‑dimensional retrieval, improving latency and accuracy of AI‑driven query services.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

ServerlessMessage QueueEvent-drivenAI integrationRDMA
Alibaba Cloud Native
Written by

Alibaba Cloud Native

We publish cloud-native tech news, curate in-depth content, host regular events and live streams, and share Alibaba product and user case studies. Join us to explore and share the cloud-native insights you need.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.