Ir al contenido principal

Apache Apisix: El API gateway cloud-native de alto rendimiento para arquitecturas de microservicios

Apache Apisix: The high-performance cloud-native API gateway for microservice architectures

En la actualidad, las organizaciones dependen de un ecosistema cada vez más amplio de aplicaciones y servicios distribuidos. Este aumento en la complejidad genera una interrogante difícil de responder: ¿cómo una empresa puede administrar y controlar el tráfico de APIs de forma eficiente, segura y sin interrupciones? Ahí entra en juego Apache APISIX.

En este artículo exploraremos los aspectos clave que hacen de Apache APISIX una plataforma destacada en el mundo de la gestión de APIs:

  • Ventajas principales y características técnicas que lo diferencian de otros gateways.
  • Casos de uso prácticos en arquitecturas de microservicios y entornos híbridos.
  • Comparativas con otros API Gateways líderes del mercado, como Kong o Envoy.

Quédate hasta el final del artículo, ya que mostraremos ejemplos aplicados en la práctica, asi como un testimonio de Jesús Navarro, Director Técnico en Chakray Consulting México.

¿Qué es Apache APISIX?

Apache APISIX es una plataforma open source de gestión de APIs pensada como API Gateway moderno y de alto rendimiento. Su objetivo es optimizar, administrar y proteger el tráfico de APIs en arquitecturas basadas en microservicios.

Una de sus fortalezas es su enfoque cloud-native. APISIX se apoya en NGINX a través de OpenResty (con LuaJIT) para lograr latencias muy bajas, y ofrece un sistema de plugins extensible (Lua, runtimes multilenguaje y un runtime WASM experimental) para autenticación, seguridad y observabilidad.

El proyecto nació en 2019, inicialmente desarrollado por ZhiLiu Technology, y se donó a la Apache Software Foundation en octubre de ese año; desde el 15 de julio de 2020 es un Top-Level Project de Apache. API7.ai —fundada por parte del equipo creador— sigue invirtiendo en su evolución y en la comunidad. 

¿Por qué elegir Apache APISIX?

Al elegir APISIX, las organizaciones no solo obtienen un gateway de alto rendimiento, sino también una plataforma que evoluciona con las necesidades del negocio, que se integra con entornos híbridos y multicloud, y que soporta la innovación continua mediante un ecosistema de plugins extensible y dinámico.

APISIX distingue un plano de control (configuración) y un plano de datos (enrutamiento/proxy). En el modo tradicional, la configuración se gestiona vía Admin API y se persisten en etcd; los nodos del plano de datos “observan” etcd y aplican los cambios en segundos, permitiendo clústeres distribuidos con sincronización en tiempo real. 

Asi mismo, para escenarios sin etcd, existe un modo standalone (experimental) que carga una configuración declarativa (YAML/JSON) y la recarga periódicamente sin reinicios. 

Apache APISIX architecture

—El siguiente artículo puede interesarte: “API Management: el mejor aliado para acelerar tu negocio digital”

Características clave y beneficios

Antes de entrar de lleno, conviene entender la propuesta general: APISIX centraliza políticas y configuración para que equipos de plataforma y squads de producto trabajen con independencia pero bajo reglas comunes. 

Su hub de plugins cubre desde balanceo, canary y circuit breaking hasta autenticación OIDC/JWT y observabilidad con Prometheus/Grafana. Todo esto se activa por recursos declarativos (rutas, servicios, consumidores) o como Ingress Controller en Kubernetes

1. Gestión de tráfico avanzada (Load Balancing, routing y multiprotocolo)

Apache APISIX es un gateway totalmente dinámico pensado para gobernar el tráfico entre clientes y microservicios sin reinicios, con políticas de enrutamiento ricas, balanceo de carga de alto rendimiento y soporte multiprotocolo (L7 y L4). Esto permite implementar despliegues graduales (canary, A/B), proteger upstreams con límites de tasa y circuit breaking, y observar la salud de los servicios de forma continua.

¿Qué es el BPMN y para qué sirve?

1. 1. Algoritmos de balanceo de carga soportados

APISIX usa el objeto Upstream para distribuir solicitudes entre nodes siguiendo distintos algoritmos. Soporta round-robin (y weighted), chash (consistent hashing), ewma (media móvil exponencial basada en latencia) y least_conn (menos conexiones). 

Esto permite elegir la estrategia adecuada según el caso: reparto uniforme, afinidad de sesión, latencia dinámica o conexiones de larga duración.

  • round-robin / weighted round-robin: reparte secuencialmente; con pesos, un nodo con peso 2 recibe ~el doble que otro con peso 1. Útil cuando los servidores tienen capacidad similar.
  • chash (consistent hashing): fija las peticiones de una misma clave (IP, cookie, cabecera, consumer, etc.) al mismo nodo para preservar estado o caché.
  • ewma: prioriza nodos con menor latencia observada, adaptándose a variaciones en tiempo real.
  • least_conn: envía al nodo con menos conexiones activas; útil con WebSockets u otros escenarios de conexión prolongada.

Además, los Upstreams incluyen reintentos, health checks activos/pasivos y filtrado automático de nodos no saludables para mantener la estabilidad.

1. 2. Enrutamiento dinámico por path, host, método y cabeceras

Las Routes emparejan solicitudes por URI, host, método, cabeceras, IP remota y expresiones (vars), cargan los plugins y reenvían al upstream correspondiente. APISIX ofrece tres opciones de router para HTTP:

  • radixtree_host_uri (por defecto): prioriza hostname sobre la URI; estilo NGINX.
  • radixtree_uri: prioriza la ruta (URI) sobre el hostname.
  • radixtree_uri_with_parameter: como el anterior, pero soporta parámetros en la URI.  Esto facilita escenarios complejos (coincidencias exactas, prefijos, headers, methods, query args, etc.).

1. 3. Soporte multiprotocolo (L7 y L4)

APISIX no se limita a HTTP/1.1:

  • HTTP/2 y gRPC / gPRCS: proxying nativo de gRPC (HTTP/2), con rutas tipo /service/method y upstream grpc o grpcs. 
  • gRPC-Web: plugin grpc-web para clientes web; ideal cuando el navegador no expone HTTP/2.
  • gRPC transcoding: plugin grpc-transcode para convertir HTTP/JSON ↔ gRPC sin tocar el backend.
    WebSocket: proxying de conexiones WebSocket y guías para autenticación durante el handshake.
  • HTTP/3 (QUIC): soporte de HTTP/3/QUIC para reducir latencia y mejorar resiliencia de conexión.
  • TCP/UDP (L4): Stream Proxy para enrutar tráfico de transporte (LDAP, MySQL, DNS, etc.).
  • MQTT: plugin mqtt-proxy, con load balancing por client_id (MQTT 3.1.* y 5.0).
  • Dubbo: plugin dubbo-proxy (y http-dubbo) para publicar servicios Dubbo mediante HTTP.
  • Proxy Protocol (HAProxy PROXY): puede habilitarse en stream para conservar IP/puerto de cliente tras un L4 LB.
  • SSL/TLS y mTLS dinámicos: certificados gestionados como objetos SSL (vía Admin API) y soporte mTLS; todo sin reinicios.

Además de esto, APISIX sincroniza configuración en tiempo real vía etcd y soporta hot reload de plugins y cambios de configuración (incluidos certificados TLS), evitando ventanas de indisponibilidad. Incluso los plugin runners externos contemplan recarga en caliente en sus guías

Beneficios: reducción de timeouts y errores en picos, despliegues seguros de nuevas versiones con canary, y reglas de ruteo declarativas fáciles de versionar.

Apache APISIX first image

2. Seguridad integral (Security)

APISIX centraliza políticas de autenticación, control de acceso y cifrado, aplicables por ruta/servicio/consumidor y activables en caliente. El objetivo: reducir superficie de ataque, estandarizar el acceso y cumplir requisitos de seguridad sin reescribir microservicios.

  • Autenticación: plugins nativos para API Key (key-auth) y JWT; también soporta OpenID Connect mediante plugin dedicado. Se configuran en Consumers y se habilitan por rutas/servicios.
  • Listas de control por IP: whitelist/blacklist y compatibilidad con real-ip cuando el gateway está detrás de otro proxy. Útil para restringir entornos, admin endpoints o partners.
  • Limitación de tráfico: rate limiting por consumidor/clave, con opción de conteo en memoria o a nivel clúster usando Redis, para absorber picos y mitigar abuso.
  • Cifrado y confianza cero: habilita mTLS de extremo a extremo —cliente↔APISIX y APISIX↔upstream— con autenticación mutua. Cada parte presenta y valida su certificado frente a una CA de confianza, bloqueando conexiones no autenticadas. APISIX también admite mTLS con etcd para proteger el plano de control. Es idóneo para entornos de alto cumplimiento que exigen cifrado en tránsito e identidad fuerte en ambos sentidos.

3. Observabilidad y monitoreo

APISIX actúa como punto central de observación del tráfico API y, mediante plugins, se integra con plataformas como Prometheus, SkyWalking y OpenTelemetry

La observabilidad se apoya en tres pilares —logs, métricas y trazas— que permiten entender uso, rendimiento y seguridad sin instrumentar cada microservicio por separado.

  • Logs: plugins como http-logger, kafka-logger y otros envían registros estructurados a HTTP/HTTPS o brokers para depuración y auditoría.
  • Métricas: el plugin prometheus expone latencias, códigos de estado y conteos en un endpoint para scrape y visualización (p. ej., Grafana).
  • Trazas: plugins para OpenTelemetry/Zipkin/SkyWalking generan y exportan trazas distribuidas (OTLP/HTTP o Zipkin API) para seguir cada solicitud a través de servicios.

4. Extensibilidad con plugins

APISIX se basa en un sistema de plugins modular y dinámico que permite añadir capacidades sin reinicios, aplicarlas con granularidad (por ruta, servicio, consumer o como reglas globales) y orquestarlas en un flujo de ejecución consistente mediante prioridades y fases

Esto facilita incorporar autenticación, control de tráfico, transformación, logging, observabilidad o casos avanzados (IA/LLM, MQTT, Kafka) sin tocar los microservicios.

  • Catálogo oficial y activación dinámica. En el Plugin Hub se documenta decenas de plugins listos para uso (autenticación, seguridad, traffic shaping, serverless, observabilidad, transformaciones, loggers, proxies específicos, etc.). Se habilitan y configuran de forma declarativa, con recarga en caliente.
  • Orden de ejecución y prioridades. Cada plugin define una prioridad para garantizar un orden determinista a través de las fases (por ejemplo, rewrite, access, log), incluso cuando conviven plugins de ruta, consumidor y globales.
  • Runners multilenguaje. Además de plugins nativos (usando Lua), puedes escribirlos en Go o Python mediante plugin runners gestionados por APISIX como subprocesos del gateway (comunicación RPC por unix socket).
  • WebAssembly (Proxy-Wasm). APISIX soporta plugins Wasm siguiendo la especificación Proxy-Wasm, lo que habilita portabilidad del código entre proxies compatibles y desarrollo en distintos lenguajes/SDKs. 

5. Preparado para cloud-native

APISIX está diseñado para integrarse de forma natural en entornos cloud-native. Ofrece un Ingress Controller con CRDs para gestionar rutas y políticas como código, despliegues simplificados mediante Helm Charts, y métricas listas para Prometheus/Grafana. 

Además, soporta descubrimiento dinámico de servicios (Consul, Nacos, ZooKeeper) y modos declarativos/GitOps que permiten administrar el gateway sin interrupciones ni dependencias de herramientas externas.

  • Kubernetes Ingress con CRDs. Define rutas HTTP/TCP/UDP con ApisixRoute, y configura upstreams (balanceo, health checks, timeouts, retries) con ApisixUpstream. El controlador reconcilia estos recursos y aplica cambios en caliente sobre el gateway.
  • Despliegue con Helm. Charts mantenidos por el proyecto permiten instalar APISIX, su Ingress Controller y componentes asociados en un solo comando; incluyen ServiceMonitor para que Prometheus scrapee métricas del controlador.
  • Observabilidad cloud-native. El Ingress expone métricas compatibles con Prometheus/Grafana para supervisar reconciliaciones, latencia y errores del plano de control; se habilitan automáticamente al desplegar con Helm + Prometheus Operator.
  • Descubrimiento de servicios. Integra registros como Nacos, ZooKeeper (en el plano de control) y Consul para resolver dinámicamente backends, evitando listas estáticas y facilitando autoscaling.
  • Modos declarativos y GitOps. En el modo standalone basado en archivos, APISIX lee y supervisa el archivo apisix.yaml, donde se definen rutas, upstreams y plugins

También existe el modo standalone basado en API, en el que toda la configuración reside en memoria y se gestiona a través de la Admin API de forma declarativa. Ambos enfoques permiten implementar flujos GitOps, eliminando la dependencia del dashboard y garantizando mayor trazabilidad y control de cambios.

Apache APISIX second image

Comparativa breve: APISIX vs. otros API Gateways

El ecosistema de API Gateways ha evolucionado con distintas filosofías y prioridades: algunos se enfocan en alto rendimiento y extensibilidad, otros en la profundidad de su integración con Kubernetes, y otros en la simplicidad operativa para entornos de menor complejidad. 

Antes de elegir, conviene tener una visión clara de cómo se posiciona Apache APISIX frente a alternativas populares como Kong Gateway, Envoy Gateway y Traefik

Esta comparación no busca un “ganador absoluto”, sino resaltar las fortalezas y escenarios ideales de uso de cada opción, de manera que puedas identificar cuál se adapta mejor a tu arquitectura, necesidades de escalabilidad y nivel de madurez tecnológica.

Aspecto Apache APISIX Kong Gateway Envoy Gateway Traefik
Núcleo / stack NGINX + LuaJIT (OpenResty); plugins Lua, runners multi-lenguaje y WASM NGINX + Lua; extensible por plugins Basado en Envoy Proxy; control-plane Kubernetes-native Proxy cloud-native con descubrimiento automático
Modelo K8s Ingress Controller y soporte Gateway API (Helm) Ingress/CRDs (Konnect/OSS) Gateway API nativo (control-plane para Envoy) Ingress/Gateway API y autodiscovery (Docker, K8s)
Plugins/Extensibilidad Amplio Plugin Hub; hot-reload Amplio catálogo de plugins Extensión mediante filtros/CRDs y ecosistema Envoy Middlewares y plugins (Catálogo Traefik)
Casos típicos API Gateway generalista y AI Gateway; N-S y E-W API Gateway generalista Control-plane para Envoy en K8s Enrutamiento dinámico y edge proxy sencillo

Testimonio de Jesús Navarro, director técnico de Chakray Consulting México

«En nuestra experiencia, Apache APISIX nos ha permitido gestionar grandes volúmenes de tráfico con una latencia muy baja y sin sacrificar rendimiento. Su arquitectura, basada en NGINX y LuaJIT, supera alternativas como Kong, lo que lo convierte en una opción sólida para entornos cloud-native, y Kubernetes. 

La posibilidad de extenderlo en múltiples lenguajes y su integración nativa con herramientas de observabilidad como Prometheus y OpenTelemetry nos dan la flexibilidad y visibilidad que necesitamos, con el respaldo de una gran comunidad activa y sin costos de licencia.»

—Quieres explorar otras soluciones de la Fundación Apache, lee el siguiente artículo: “Apache Camel: Guía definitiva para integrar aplicaciones y microservicios”

Cómo empezar con Apache APISIX

Esta sección propone un itinerario de adopción rápido: del Hello, API al operar en producción.

Requisitos y despliegue rápido

  • Docker: la guía oficial explica cómo ejecutar APISIX y configurar config.yaml (puertos 9080/9443 y Admin API en 9180 por defecto).
  • Kubernetes (Helm): instala APISIX + Dashboard + Ingress Controller desde el repositorio de charts con un par de comandos.
  • Imágenes: dispones de imágenes oficiales en Docker Hub (APISIX y Dashboard) y distribuciones de terceros como Bitnami.
  • Modos de despliegue: elige entre tradicional, desacoplado (data plane/control plane) o standalone según necesidades de control y blast radius.

Tu primera API en minutos

  1. Crear una Route hacia httpbin.org con Admin API (entorno local):

# Asumiendo admin_key configurada en conf/config.yaml

curl -i -X PUT «http://127.0.0.1:9180/apisix/admin/routes/1» \

  -H «X-API-KEY: ${admin_key}» \

  -d ‘{

    «uri»: «/ip»,

    «upstream»: { «type»: «roundrobin», «nodes»: { «httpbin.org:80»: 1 } }

  }’

  1. Probarla:

curl -i «http://127.0.0.1:9080/ip» -H «Host: httpbin.org»

Guías oficiales: Configure Routes y Admin API.

¿En Kubernetes? Crea un ApisixRoute que apunte a un Service (o dominio externo) y deja que el Ingress Controller sincronice la configuración: la documentación incluye manifestos listos para copiar.

Algunos casos de uso destacados

A continuación mencionaremos algunos ejemplos de la aplicación de APISIX en casos concretos, la siguiente información puede encontrarse en Apache.org.

1. API Aggregator

Descripción: En este patrón, el API Gateway actúa como punto central que recibe una petición del cliente, hace llamadas a múltiples servicios internos y fusiona esas respuestas (o transforma los datos) para devolver una única respuesta coherente al cliente.

Esto reduce el número de llamadas que el cliente debe hacer, minimiza la latencia y simplifica el cliente. 

Aplicación en APISIX:
APISIX permite configurar rutas que agregan o transforman las respuestas de múltiples upstreams. Puedes usar plugins para transformar payloads y concatenar información de distintos servicios. 

Esto es especialmente útil para aplicaciones móviles o microfrontends cuando deseas que la vista consuma un único endpoint, aunque los datos provienen de servicios distintos.

2. API Caching

Descripción: El Gateway puede almacenar en caché respuestas de endpoints upstream, de forma que si se recibe una petición para un recurso ya solicitado recientemente (y que aún sea válido), se pueda responder directamente desde la caché, sin necesidad de llamar al backend. 

Esto reduce carga, mejora rendimiento y latencia para los clientes.

Aplicación en APISIX:
Con APISIX, puedes usar plugins de caché para configurar qué rutas utilizarán caché, cuánto tiempo conservarán los datos y bajo qué condiciones se invalidan. Por ejemplo, puedes cachéar respuestas GET comunes, o endpoints que cambian poco, lo que mejora la velocidad de respuesta y reduce la presión sobre los servicios internos.

3. API Fault Handling

Descripción: Los sistemas no son perfectos: fallas en red, servicios inaccesibles, latencias inesperadas, etc. En este caso de uso, el API Gateway soporta mecanismos para manejar estos fallos: health checks de servicios upstream, retry (reintentos), timeouts, circuit breakers, fallback, etc., para mejorar la resiliencia del sistema en conjunto. 

Aplicación en APISIX:
APISIX incluye soporte para health checks en los upstreams, configuración de timeout, y también plugins o mecanismos para circuit breakers o descarga de fallos (fault-injection) que te permitan probar la resiliencia. 

Así, si un servicio está caído o degradado, el gateway puede redirigir el tráfico automáticamente, retornar un error controlado, o usar alguna estrategia alternativa (fallback) garantizando que los clientes tengan una experiencia más predecible.

Conclusión

Apache APISIX se a consolidado como uno de los API Gateway cloud-native de alto rendimiento para microservicios mas completos, ofrece gestión avanzada de tráfico, seguridad centralizada, observabilidad y extensibilidad con plugins. 

Así mismo, su integración con Kubernetes mediante CRDs e Ingress Controller lo convierte en una pieza clave para la gobernanza de APIs y la adopción de prácticas DevOps y GitOps.

Casos de uso como API Aggregator, API Caching y API Fault Handling muestran cómo APISIX facilita la administración del tráfico y aporta valor directo en el rendimiento, la experiencia del usuario final y la resiliencia de las plataformas digitales.

En Chakray contamos con amplia experiencia en la implementación de soluciones de integración, gestión de APIs y plataformas cloud-native. Nuestro equipo de especialistas puede ayudarte a:

  • Diseñar e implementar un API Gateway como APISIX adaptado a las necesidades de tu negocio.
  • Optimizar la seguridad y el rendimiento de tus arquitecturas de microservicios.
  • Integrar observabilidad y automatización para garantizar una operación más confiable y eficiente.
  • Acompañarte en tu viaje hacia la modernización de tu ecosistema tecnológico, con asesoría experta y soporte continuo.

¡Si tu organización está lista para llevar sus APIs al siguiente nivel con Apache APISIX, contáctanos!