Backend Development 11 min read

Janus Gateway: Architecture, Routing Rules, and Performance at Baidu

The article explains Baidu's Janus gateway—its motivations, three‑level routing design, variable and condition expression language, plugin implementations for disaster recovery and caching, and performance benchmarks—showing how it supports millions of QPS while remaining flexible and efficient.

Top Architect
Top Architect
Top Architect
Janus Gateway: Architecture, Routing Rules, and Performance at Baidu

Janus is Baidu's internal, general‑purpose gateway that processes several million QPS and provides traffic routing for more than ten middle‑platform services such as Feed, Comment, Like, Follow, Live, as well as external traffic for Baidu App, Zhidao, Experience, Passport, Baike, and Q&A.

Although Baidu already has the open‑source BFE, Janus was created to support three distinct scenarios: a pure traffic gateway, a business‑specific gateway, and a hybrid gateway, allowing both generic functions and highly customized logic.

The deployment topology (see accompanying diagrams) shows Janus sitting between the client side and downstream services, handling both internal and external traffic flows.

Key challenges identified include: making simple routing rules easy to configure with high performance, while also supporting complex, business‑specific routing policies, and providing a unified plugin mechanism that can be both generic and customizable.

Janus solves these by introducing a three‑level routing hierarchy (similar to Nginx) and a lightweight expression language. Variable expressions such as ${idc} , ${time} , ${query} , and ${header} describe system features, while condition expressions combine logical operators and function calls to evaluate those features.

Examples of simple rules (domain matching + tree routing) and advanced rules (e.g., shifting 30% of traffic from API1's A and B data centers to C) are provided. Performance tests compare the compiled expression engine with raw Go code, showing less than a 10% overhead: BenchmarkRandom-8 35817918 34.52 ns/op 0 B/op 0 allocs/op BenchmarkRawRandom-8 39136900 31.63 ns/op 0 B/op 0 allocs/op

Plugin design is illustrated with a disaster‑recovery plugin that runs only when a user‑defined condition expression evaluates to true, and a Redis cache plugin where the cache key is defined via variable expressions (e.g., comment_${request.query.id} , fans_${request.query.id}_${request.query.uk} ).

The article concludes that Janus’s combination of variable/condition expressions and a plugin framework enables flexible traffic scheduling, supports millions of QPS, and is being extended to integrate Go’s standard library for even richer dynamic configuration.

BackendPerformanceplugin architecturetraffic routinggatewayExpression Language
Top Architect
Written by

Top Architect

Top Architect focuses on sharing practical architecture knowledge, covering enterprise, system, website, large‑scale distributed, and high‑availability architectures, plus architecture adjustments using internet technologies. We welcome idea‑driven, sharing‑oriented architects to exchange and learn together.

0 followers
Reader feedback

How this landed with the community

login 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.