Design and Implementation of an Automated Operations Platform Based on Apache APISIX

Project Background – At the end of 2019 the company faced several pain points: a Java‑centric development stack, operations engineers skilled in Shell/Python, insufficient developer resources, and a fragmented set of open‑source tools. To address these issues an automated operations platform was initiated to enable rapid development, empower operations engineers, and streamline management.

Why Apache APISIX – APISIX provides ~90% of NGINX functionality, multiple load‑balancing strategies, multi‑language plugin support, soft WAF covering 95% of security scenarios, and powerful logging that integrates with ELK. Its extensible plugin system reduces development cost.

Platform Architecture – The platform consists of five layers:

Storage layer: CMDB for managing business and IT resources, change tracking, permissions, work‑order data, and monitoring metrics.

Common services layer: Core APIs built on open‑source tools (the "base middle‑platform").

Business orchestration layer: Engineers compose atomic APIs into workflows and expose them to the front‑end.

Gateway layer: APISIX handles load balancing, service discovery, authentication, request/response transformation, logging, and generic security controls.

Presentation layer: A responsive admin UI template allowing operations engineers to create forms and reports without deep JavaScript knowledge.

Platform Components

Core gateway: Apache APISIX (logging, security, load‑balancing, custom plugins).

API management: YAPI for interface definition, testing, and ACL data source.

Access control: Casbin (via PyCasbin for RESTful policies).

Data storage: MySQL 5.7.

Custom web framework: mug‑skeleton for deeper technical control.

Third‑party integrations: CMDB (RESTful wrapper), OpenLDAP (account verification), Activiti workflow engine.

User Login and Permission Verification – Requests first pass through APISIX to check a whitelist. Protected pages are routed to a custom authentication service that validates credentials against LDAP, retrieves user organization info from CMDB, generates a JWT token via APISIX's jwt plugin, and stores it in a cookie. Subsequent requests use the token for access control, enforced by the consumer‑restriction plugin.

New Micro‑service Integration – All micro‑services must define their APIs in YAPI, which produces mock requests and populates ACL rules. The platform reads these definitions, creates Casbin policies, and loads them into APISIX's etcd, enabling automatic permission management for new services.

Technical Details – APISIX is built on NGINX + Lua. Key NGINX phases used:

access_by_lua : Executes deny commands for IP whitelisting and permission checks (implemented in acl_plugin.lua ).

header_filter_by_lua : Inserts custom key:value headers for gray‑release routing; can also use the traffic‑split plugin.

log_by_lua : Sends trace or error information to loggers such as skywalking‑logger , kafka‑logger , or rocketmq‑logger .

The custom acl-plugin.lua decodes the JWT token from the cookie, queries an ACL service, logs success or failure, and returns appropriate HTTP status codes.

Auth Service – Works with acl-plugin.lua to decode request data, generate JWT tokens, register consumers in APISIX, and sync ACL rules from YAPI into the database and Casbin.

Conclusion – The automated operations platform demonstrates how Apache APISIX can serve as a cloud‑native API gateway, providing extensible authentication, fine‑grained access control, and seamless micro‑service integration, while supporting plugin development in Lua, Wasm, and Python.