Evolution of the Tianyi Account Gateway System: From Zuul 1.0 to Kong‑Based 3.0

Recently, the author reviewed gateway‑related articles and presents a comprehensive case study of the Tianyi Account gateway architecture evolution, highlighting the motivations, technical choices, and performance outcomes.

1. Introduction

Tianyi Account, China Telecom's internet account system, provides identity authentication for enterprises. Its gateway serves as a centralized entry point, billing, and access control layer, supporting isolation, configurability, easy development, dynamic routing, degradation, and high concurrency.

Since its launch in 2017, the gateway has withstood major traffic spikes such as the 2021 Spring Red Packet and Double‑11 events, handling 100 k QPS and billions of daily requests while maintaining stable metrics.

2. Evolution Timeline

2.1 Early Stages (2017‑2021)

During this period the system underwent several major upgrades, moving from a Zuul‑based 1.0 implementation to a Kong‑based 2.0 solution.

2.2 Gateway 1.0 (Zuul)

Built on the open‑source Spring Cloud Zuul filter chain, the 1.0 gateway suffered from performance bottlenecks (≈1 k QPS per instance) and limited flexibility for dynamic routing and filter configuration.

To meet high‑traffic demands, horizontal scaling was used, which increased operational cost and risk.

2.3 Gateway 2.0 (Kong)

After evaluating OpenResty‑based Kong, Orange, Tyk, and Zuul, the team chose to extend Kong with custom plugins due to lower learning cost and strong community support.

Key upgrades included self‑developed plugins for authentication, encryption, logging, parameter conversion, traffic control, tracing, and more, totaling over 30 components.

Support for AppKey authentication, SSL/TLS encryption, IP/APP black‑ and white‑lists.

Financial‑grade cryptographic algorithms (SM2/SM3/SM4).

Asynchronous log aggregation via Redis and Kafka, with Zipkin/Prometheus tracing.

Fine‑grained rate‑limit and circuit‑breaker policies.

Performance tests showed single‑machine QPS around 12 k–13 k, confirming the efficiency of the custom plugins.

2.4 Gateway 3.0

To support password‑less authentication and stricter SLA requirements, the team designed a 3.0 architecture based on Kong 2.4, OpenResty 1.19.3.1, and Nginx 1.19.3.

2.4.1 Data Plane (DP) Upgrade

Adopted a CP/DP hybrid deployment, enabling feature decoupling, high availability, multi‑language plugins (Go, JavaScript, Lua), and UDP proxy support.

Feature Decoupling : CP pushes configuration to DP; DP handles traffic.

Run‑time Stability : DP can operate independently if CP fails.

Multi‑language Plugins : Go, JavaScript, TypeScript, Lua.

UDP Proxy : Routes, Services, Load Balancing, and logging support UDP.

2.4.2 Control Plane (CP) Upgrade

Integrated Consul for service discovery and configuration, replacing Nginx‑based routing.

Developed new plugins such as DP cache control (c‑cache‑manage) and traffic replication to enable safe testing of the 3.0 version without affecting production traffic.

Enhanced Prometheus plugin to differentiate CP and DP metrics.

2.4.3 Result

The 3.0 gateway achieves:

High concurrency, supporting >100 k QPS.

High availability with 99.96% SLA.

Flexible scaling via DNS‑driven automatic failover and Alibaba Cloud ACK.

Rich multi‑language plugin ecosystem (Go, JavaScript, Lua) and UDP proxy capability.

During the latest Double‑11 peak, the system maintained a TP99 latency under 20 ms, confirming its stability.

3. Conclusion

After multiple iterations, the Tianyi Account gateway now offers:

Performance improvements of over 20× compared to version 1.0.

Unified traffic entry handling >90% of requests.

Robust high‑availability architecture with DNS‑based automatic switching.

Standardized, reusable plugins for rate‑limiting, degradation, traffic mirroring, and API protocols.

Multi‑language plugin support (Lua, Go, JavaScript) to meet diverse team needs.

The gateway plays a pivotal role in China Telecom's unified account platform, providing a solid foundation for hundred‑thousand‑level concurrency, simplifying maintenance, and supporting the carrier's cloud‑native transformation strategy.