Apache APISIX Service Mesh: Architecture, Challenges, and the apisix-mesh-agent Solution

Service mesh is an infrastructure layer that handles inter‑service communication, often using a sidecar proxy for each service instance to manage traffic, observability, and security.

The article first gives a brief overview of Apache APISIX, a dynamic, real‑time, high‑performance API gateway that provides load balancing, dynamic upstreams, canary releases, circuit breaking, authentication, and observability.

Key highlights of APISIX include full dynamism (no reload required for configuration changes), a rich set of load‑balancing strategies (weighted round‑robin, consistent hash, EWMA), service discovery and governance (integration with Consul and Nacos, rate limiting, throttling, circuit breaking), and strong extensibility via plugins written in Lua, Java, Go, or WASM.

The architecture consists of a data plane and a control plane, with etcd as the configuration store. The design avoids single points of failure and ensures high availability.

Why use a service mesh? It abstracts governance functions (rate limiting, discovery, circuit breaking) away from business code, improving developer productivity and service stability.

API gateways share many governance features with service meshes, such as discovery, rate limiting, and authentication, making APISIX a candidate for the data‑plane role in a mesh.

A 2021 survey of Chinese enterprises revealed early adoption of service meshes, heavy reliance on HTTP proxy, canary/blue‑green deployments, and a focus on observability.

APISIX already supports the required data‑plane capabilities (HTTP/gRPC/TCP/UDP proxy, traffic splitting, load balancing, health checks, mTLS/JWT authentication, and observability integrations with SkyWalking, Prometheus, Zipkin).

Challenges when using APISIX as the data plane include timely configuration propagation to many instances, selecting an appropriate control plane (Istio, Kuma, Open Service Mesh, or a custom solution), and the effort needed to adapt APISIX’s Lua/OpenResty stack.

The control plane typically relies on etcd, which can become a bottleneck under high QPS; etcd proxy cannot fully solve this because APISIX communicates via HTTP‑to‑gRPC gateway.

To address these issues, the open‑source apisix-mesh-agent was created as an intermediate layer that implements the etcd V3 client API, translates xDS configuration from the control plane into APISIX‑compatible format, and injects iptables rules for traffic interception.

Key functions of apisix‑mesh‑agent include support for xDS (LDS, RDS, CDS, EDS), implementation of essential etcd client APIs (Range, Watch), and seamless integration with existing APISIX deployments without code changes.

The overall architecture places the control plane (e.g., Istio, Kuma) above, while each mesh data‑plane pod runs both APISIX and apisix‑mesh‑agent side‑by‑side, communicating via the simulated etcd API.

Advantages of using APISIX in a service mesh are its high‑performance routing (Radix Tree), extensive plugin ecosystem (50+ plugins, multi‑language support), and reduced operational complexity by consolidating north‑south and east‑west traffic handling into a single component.

Future roadmap includes expanding xDS support, adding request rewriting, authentication (JWT, mTLS), fault injection, enhancing observability integrations, and potentially developing a dedicated control plane for APISIX.

Author: Zhang Chao, Engineer at Shenzhen Zhiliu Technology, Apache APISIX PMC member, contributor to multiple open‑source projects.

Apache APISIX architecture diagram