Why Baidu Built Janus: Design and Implementation of a High‑Performance General Gateway

Baidu’s Janus gateway processes millions of QPS and serves both internal services (feed, comments, likes, live streaming, etc.) and external traffic for products such as Baidu App, Zhidao, Baike, and more.

Why build Janus? Although BFE is open‑source and widely used, Janus offers a more flexible solution that can act as a traffic gateway, business gateway, or hybrid gateway, supporting both generic functions and highly customized requirements. Its plug‑in model allows each user to deploy and extend the gateway independently.

Core challenges include providing simple, high‑performance routing for the majority of cases while also supporting complex, business‑specific routing logic, and balancing universality, customizability, and flexibility.

Traffic scheduling design is organized into three layers of routing (similar to Nginx): domain matching, tree‑based URL routing, and feature‑based matching. Simple rules use domain + tree routing; complex rules employ a minimal scripting language for variable and condition expressions.

Example simple rules:

After a certain time, shift 30% of traffic from API1’s A and B data centers to C.

Route Android traffic of a specific app version to a new rule.

Forward traffic with particular cookie or query features to a preview environment.

Complex rules are expressed with variable expressions such as ${idc} (current data center), ${time} (current time), ${query} (GET parameters), and ${header} (header values). Hierarchical variable syntax (e.g., ${request.query.id} ) allows users to define custom keys.

Variable and condition expressions enable fine‑grained matching. Condition expressions support logical operators and function calls, for example:

random(0,100) || random(100,100)

Benchmark results show the expression engine incurs less than 10% overhead compared with raw Go code:

goos: windows
goarch: amd64
cpu: 11th Gen Intel(R) Core(TM) i5-1145G7 @ 2.60GHz
BenchmarkRandom-8       35817918   34.52 ns/op   0 B/op   0 allocs/op

goos: windows
goarch: amd64
cpu: 11th Gen Intel(R) Core(TM) i5-1145G7 @ 2.60GHz
BenchmarkRawRandom-8    39136900   31.63 ns/op   0 B/op   0 allocs/op

Plugin system demonstrates the balance between universality and customization. A disaster‑recovery plugin can be triggered by user‑defined condition expressions such as:

num_gt(${response.code}, 499)
num_gt(${response.code}, 499) || (!str_equal(${response.jsonbody.errno}, 0))
num_gt(${response.code}, 499) || (!str_equal(${response.header.sla_status}, 0))

A generic Redis cache plugin uses variable expressions to define cache keys, allowing different services to customize key composition:

// before downstream request
if data, ok := redis.Get(key); ok { return data }
// downstream request
data := request(xxx)
// after downstream request
redis.Set(key, data)

Key definitions can be customized, e.g., comment_${request.query.id} , fans_${request.query.id}_${request.query.uk} , or homepage_${request.query.uk} .

Outlook – Janus plans to further integrate its expression engine with Go’s standard library, enabling seamless dynamic programming capabilities from the control plane and expanding its applicability to more scenarios.

Overall, Janus demonstrates how a combination of hierarchical routing, extensible variable/condition expressions, and a plug‑in architecture can meet both generic and highly specific traffic‑control needs at massive scale.