Evolution of the Tianyi Account Gateway Architecture: From Zuul 1.0 to Kong‑Based 3.0
This article chronicles the architectural evolution of China Telecom's Tianyi Account gateway from its initial Zuul‑based 1.0 version through successive upgrades to a Kong‑powered 2.0 and 3.0 system, highlighting performance bottlenecks, technology selections, plugin development, CP/DP separation, cloud‑native deployment, and the resulting high‑concurrency capabilities.
1. Introduction
The Tianyi Account gateway is a core component of China Telecom's internet account system, providing centralized entry, billing, and authentication while supporting isolation, configurability, dynamic routing, degradation, and high concurrency.
2. Gateway Evolution
2.1 Evolution Timeline
From 2017 to 2021 the gateway underwent several major upgrades to meet increasing traffic demands, illustrated by a timeline diagram.
2.2 Gateway 1.0 (Zuul)
Built on the open‑source Spring Cloud Zuul filter chain, the 1.0 version suffered from performance bottlenecks (≈1k QPS per instance) and limited flexibility, requiring extensive manual configuration.
2.3 Gateway 2.0
2.3.1 Technology Selection
Evaluated Kong, OpenResty, Tyk, Zuul, Nginx, and other solutions. Chose Kong for its extensibility and decided to develop custom plugins on top of it.
2.3.2 Architecture Upgrade
Deployed a Kong‑based architecture with custom plugins covering authentication, encryption, logging, rate‑limiting, tracing, etc., and introduced horizontal scaling and high‑availability features.
2.3.3 Results
Performance tests showed ~12k QPS on a single node, reaching >13k QPS when optional plugins were disabled, confirming the viability of the 2.0 design.
2.4 Gateway 3.0
2.4.1 Data Plane (DP) Upgrade
Upgraded to Kong 2.4.0 (OpenResty 1.19.3.1, Nginx 1.19.3) achieving >20k QPS, introduced CP/DP separation, multi‑language plugin support (Lua, JavaScript, Go), and UDP proxy capabilities.
2.4.2 Control Plane (CP) Upgrade
Replaced Nginx routing with Consul for service discovery, added cache‑control and traffic‑replication plugins, and enhanced Prometheus metrics to distinguish CP and DP data.
2.4.3 Effects
The 3.0 gateway supports >100k QPS, 99.96% SLA, automatic DNS‑based failover, and rich plugin ecosystem, proving stable during major traffic spikes such as Double 11.
3. Conclusion
The successive iterations have dramatically improved performance (20× over 1.0), unified traffic control, high availability, standardized reusable plugins, and multi‑language extensibility, positioning the gateway as a critical backbone for China Telecom's high‑concurrency services and future cloud‑native evolution.
Wukong Talks Architecture
Explaining distributed systems and architecture through stories. Author of the "JVM Performance Tuning in Practice" column, open-source author of "Spring Cloud in Practice PassJava", and independently developed a PMP practice quiz mini-program.
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.