How Yanxuan Evolved Its API Gateway from Kong to Cloud‑Native Envoy

Overall Evolution

Since its launch in 2016, Yanxuan's gateway has become the primary entry point for business traffic, ensuring stability, reliability, and efficient disaster recovery. The architecture has evolved alongside cloud‑native adoption, moving from ServiceMesh 1.0 (Consul + Nginx) to ServiceMesh 2.0 (Istio) and finally to a unified Envoy‑based gateway.

API Gateway 1.0 (Ianus) – System Construction

After product research and technology selection, Yanxuan built its API gateway on Kong, naming it Ianus. The deployment architecture includes three main components:

Yanxuan‑Ianus : data‑plane component handling actual business traffic.

Yanxuan‑Ianus‑PGProxy : control‑plane proxy that consolidates PostgreSQL write operations, leaving the data plane read‑only for security.

Yanxuan‑Ianus‑Admin : control‑plane component providing full API and plugin configuration.

Data‑Plane Construction

The data‑plane stack consists of Nginx (OpenResty) with Consul and VTS modules, OpenResty itself, Yanxuan‑Kong (extended with routing, clustering, tenant management, gray release, etc.), and Yanxuan‑Ianus for plugin management.

Control‑Plane Construction

Kong’s native configuration lacks permission control and versioning, so Yanxuan added:

Version Management : MongoDB‑backed configuration with history, rollback, and comparison.

Standardized Workflow : integrated with Yanxuan’s ticket system for request, review, and release.

Alert Integration : real‑time notifications on configuration changes.

Gray Release : targeted deployment to specific gateway instances.

Plugin Capability Construction

Over 30 plugins were added to Kong, including rate‑limit, routing, request/response transformation, AB‑testing, authentication, and custom business plugins. Disaster‑recovery features such as percentage‑based throttling, circuit‑breaker, and rate‑limit per service were also implemented.

Edge‑Gateway (API Gateway 1.5) – Cross‑ServiceMesh Traffic

During the transition from ServiceMesh 1.0 to 2.0, an edge gateway was deployed to handle traffic between the two meshes. The flow includes ServiceMesh 1.0 routing to the edge gateway (Ianus OUT), authentication and routing at the edge, then hand‑off to Envoy IN within ServiceMesh 2.0.

API Gateway 2.0 (Lightboat Envoy) – Cloud‑Native

After evaluating Kong, Traefik, Ambassador, Gloo, and Istio Gateway, Yanxuan chose Envoy for the data‑plane and Istio for the control‑plane, aligning with the Lightboat team’s cloud‑native strategy. The architecture separates control‑plane and data‑plane, reusing the existing Ianus deployment model for the data‑plane.

Control‑Plane Integration

The Lightboat Envoy control‑plane adapts Yanxuan’s API configuration model to Istio resources, storing them in the K8s Config Store. Components include API Gateway Admin (shared UI), API Plane (configuration adapter), and Istio Pilot (service discovery, configuration distribution, and Envoy lifecycle management).

Plugin Development for Envoy

Envoy native plugins were standardized via a schema, while existing Kong Lua plugins were migrated with minimal effort, enabling reuse of Lua extensions in the Envoy environment.

Benefits and Insights

Unified API entry point handling >90% of traffic.

Consistent traffic governance across microservices.

Standardized disaster‑recovery capabilities (rate‑limit, degradation, static content).

LUA plugin reuse simplifies custom feature development.

Summary

API Gateway 1.0 (Ianus) played a crucial role in Yanxuan’s cloud migration, and the transition to API Gateway 2.0 (Lightboat Envoy) builds on that foundation with cloud‑native, serverless‑ready capabilities, positioning Yanxuan’s gateway as an industry leader.