Design and Implementation of an Access‑Layer API Gateway with OpenResty

The article begins by recalling a previous popular post on high‑performance short‑link design and introduces the goal of summarizing OpenResty, a high‑performance web platform, through the lens of an access‑layer gateway design.

Gateway Role : The gateway is the entry point for all traffic, handling security, rate limiting, circuit breaking, monitoring, logging, risk control, and authentication. Two types are described: an access gateway (routing, WAF, logging, caching) and an application gateway (micro‑service routing, authentication, retries, etc.).

Access‑Layer Architecture : Core function is routing requests to the appropriate backend cluster based on host, URL, and other rules. Required features include routing, plugin‑based routing policies, dynamic backend cluster changes, and monitoring.

Technology Selection : Although Nginx provides high‑performance non‑blocking I/O, it lacks runtime configurability. OpenResty (Nginx + Lua) is chosen because it adds dynamic scripting capabilities while retaining Nginx’s performance.

OpenResty Principles : OpenResty integrates many Lua libraries and modules, allowing dynamic control of routing, upstreams, SSL, requests, and responses without restarting. It supports synchronous non‑blocking programming via Lua coroutines.

Example of synchronous vs. asynchronous code:

local res, err  = query‑mysql(sql)
local value, err = query‑redis(key)

In OpenResty, all APIs are non‑blocking; Lua coroutines yield during I/O, letting the worker process handle other requests.

Nginx Worker Model : A master process forks multiple single‑threaded workers. Workers share a LuaJIT VM; each request runs in a Lua coroutine. The event‑driven epoll model enables high concurrency.

Request Lifecycle : Nginx has 11 phases, each with a corresponding *_by_lua directive (e.g., set_by_lua, rewrite_by_lua, access_by_lua, content_by_lua, header_filter_by_lua, body_filter_by_lua, log_by_lua). This allows clean separation of concerns such as decryption in the access phase and encryption in the body‑filter phase.

Shared Data : Workers use shared dict to store configuration data atomically, avoiding contention under high load.

Plugin‑Based Routing : Routing policies (URL, action, cluster) are stored in a database, compiled into Lua functions at startup, and cached in shared dict. Changes are propagated via a management interface that triggers a reload of the compiled rules.

Dynamic Upstream Configuration : Traditional static upstream blocks require reloads. OpenResty’s dyups module provides an API to add, delete, or modify upstream servers at runtime.

# Dynamic upstream configuration example
-- add upstream:user_backend
curl -d "server 10.53.10.191;" 127.0.0.1:81/upstream/user_backend

-- delete upstream:user_backend
curl -i -X DELETE 127.0.0.1:81/upstream/user_backend

The final architecture diagram (omitted) shows a fully configurable and dynamic gateway built on OpenResty.

Conclusion : Choosing OpenResty offers high performance and dynamic configurability, proven by large companies. The article provides a concise overview of OpenResty’s key features, encouraging readers to explore deeper resources for advanced usage.