Design and Implementation of the AMB Asynchronous Message Bus for Alibaba Advertising Platform
To solve the scalability, visibility, and debugging challenges of heterogeneous asynchronous calls after Alibaba Momma’s advertising services shifted to micro‑services, the team created the AMB (Alibaba Momma Application Message Bus), a console‑driven, bus‑style platform with layered connectors, reusable components, isolated JStorm topologies, and centralized monitoring that turns hours‑long coding into rapid visual workflow configuration.
Under the goal of platformizing support for business development, Alibaba Momma's advertising application team launched reforms and upgrades across application system architecture, development models, and organizational structures, aiming to build a new "Advertising Business Platform" that enhances engineering capabilities, consolidates business assets, cultivates talent, and empowers marketing innovation.
Business centralization is a key step in platform construction. Advertising services are abstracted into multiple business centers, each responsible for a domain. The former monolithic promotion service became a set of micro‑service business centers, turning internal calls into inter‑system calls. Managing the resulting massive, heterogeneous asynchronous calls became a pressing challenge.
In a micro‑service architecture, synchronous calls are handled by HSF (RPC) middleware, so the focus shifts to asynchronous interactions. Two common async patterns are message‑queue based processing (e.g., Metaq, Notify) and database‑driven DRC messages. An example: when a product is penalized, the audit system sends a penalty message; the advertising system receives it and takes the product’s ads offline.
Building an async chain with a message queue involves:
1) System A develops message‑sending logic. 2) System B imports A’s data object definitions (increasing coupling). 3) System B implements subscription, consumption, retry, and flow‑control logic.
Problems of this approach include:
Low development efficiency: Developers must write subscription, retry, and flow‑control code that adds little business value, and coordination among multiple teams slows integration.
Operational difficulty: Async logic is scattered across services without a centralized management platform, making visibility, control, and hand‑over problematic, especially during high‑traffic events.
Debugging difficulty: Inconsistent logging formats and dispersed storage hinder rapid issue diagnosis.
To achieve visibility, manageability, and controllability, the team adopted the Enterprise Service Bus (ESB) concept, proposing a bus‑style architecture to replace the current mesh of async links.
Solution Design
The team built the AMB (Alibaba Momma Application Message Bus) platform, which handles message conversion, routing, processing, monitoring, alerting, retry, and flow‑control for asynchronous requests across applications.
AMB’s architecture consists of a console and a backend. The console offers two main functions: “Create Task” for visual, drag‑and‑drop workflow configuration using a set of standard components, and “Task Management” for controlling task lifecycle and viewing logs.
The backend follows a layered design:
Connector Layer: Interfaces with external protocols such as Metaq, Notify, DRC, HSF, and is extensible for new protocols.
Link Component Layer: Provides a library of standard components (filters, transformers, processors, splitters, routers, etc.) that can be extended.
Platform Service Layer: Supplies common capabilities like logging, retry policies, monitoring, and flow‑control.
Execution Engine Layer: Runs on the task‑hosting platform QiaoQiao; each AMB workflow occupies a separate JStorm topology, ensuring isolation and enabling dynamic scaling.
Technical Highlights
Usability: A self‑service console lets developers configure workflows faster than writing code, using a WYSIWYG drag‑and‑drop interface.
Rich Component Library: A set of reusable, extensible components covers most development needs, with support for custom components when required.
Isolation: Each workflow runs in its own JStorm topology, guaranteeing physical isolation and allowing rapid scaling via JStorm’s elastic mechanisms.
Operations Monitoring: Centralized monitoring, alerting, flow‑control, and standardized logging simplify troubleshooting and reduce operational overhead.
Business Impact
Since its launch in early 2016, AMB has covered the majority of asynchronous scenarios in Alibaba Momma’s advertising systems. It transformed development from day‑level coding to hour‑level configuration, improved architecture stability, unified retry and flow‑control mechanisms, and made link status and logs instantly visible, greatly simplifying maintenance.
Future Outlook
AMB aims to support more business lines, improve resource utilization by migrating the underlying stream‑processing engine to Blink, and introduce intelligent resource scheduling. While platformization brings benefits, challenges such as architectural complexity and cross‑team coordination remain. The team plans to integrate AMB with the broader advertising application platform to achieve standardized business capabilities and visual orchestration.
Alimama Tech
Official Alimama tech channel, showcasing all of Alimama's technical innovations.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.