Preparación del entorno contenedorizado

Para iniciar el ecosistema de APISIX, primero organizaremos la estructura de directorios. Creamos un directorio raíz llamado gateway-stack y dentro de él un subdirectorio etcd-storage para garantizar la persistencia de datos del almacén de configuraciones distribuido.

Dentro del directorio principal generamos tres arcchivos de configuración esenciales: apisix-settings.yaml para el núcleo del gateway, ui-settings.yaml para el panel administrativo, y compose.yaml para orquestar los servicios.

Configuración del núcleo APISIX

El archivo apisix-settings.yaml define los parámetros fundamentales del servidor:

apisix:
  node_listen: 9080
  
  allow_admin:
    - 0.0.0.0/0
  
  admin_key:
    - name: "admin"
      key: edd1c9f034335f136f87ad84b625c8f1
      role: admin
    - name: "observador"
      key: 4054f7cf07e344346cd3f287985e76a2
      role: viewer

etcd:
  host:
    - "http://etcd:2379"
  prefix: "/apisix"
  timeout: 30

Configuración del panel de administración

El archivo ui-settings.yaml controla el acceso y funcionalidades del dashboard:

conf:
  listen:
    host: 0.0.0.0
    port: 9000
  allow_list:
    - 0.0.0.0/0
  etcd:
    endpoints:
      - "http://etcd:2379"

authentication:
  secret: secret
  expire_time: 3600
  users:
    - username: admin
      password: admin
    - username: usuario
      password: usuario

plugins:
  - api-breaker
  - authz-keycloak
  - basic-auth
  - batch-requests
  - consumer-restriction
  - cors
  - echo
  - fault-injection
  - grpc-transcode
  - hmac-auth
  - http-logger
  - ip-restriction
  - jwt-auth
  - kafka-logger
  - key-auth
  - limit-conn
  - limit-count
  - limit-req
  - openid-connect
  - prometheus
  - proxy-cache
  - proxy-mirror
  - proxy-rewrite
  - redirect
  - referer-restriction
  - request-id
  - request-validation
  - response-rewrite
  - serverless-post-function
  - serverless-pre-function
  - sls-logger
  - syslog
  - tcp-logger
  - udp-logger
  - uri-blocker
  - wolf-rbac
  - zipkin
  - server-info
  - traffic-split

Orquestación con Docker Compose

El archivo compose.yaml define la interconexión de los tres componentes:

version: '3.8'

services:
  apisix-core:
    image: apache/apisix:latest
    container_name: apisix-gateway
    volumes:
      - ./apisix-settings.yaml:/usr/local/apisix/conf/config.yaml:ro
    depends_on:
      - etcd-server
    ports:
      - "9080:9080"
      - "9443:9443"
    networks:
      - apisix-net

  admin-ui:
    image: apache/apisix-dashboard:latest
    container_name: apisix-dashboard
    volumes:
      - ./ui-settings.yaml:/usr/local/apisix-dashboard/conf/conf.yaml:ro
    ports:
      - "9000:9000"
    depends_on:
      - apisix-core
    networks:
      - apisix-net

  etcd-server:
    image: bitnami/etcd:latest
    container_name: etcd-store
    user: root
    volumes:
      - ./etcd-storage:/bitnami/etcd
    environment:
      ETCD_ENABLE_V2: "true"
      ALLOW_NONE_AUTHENTICATION: "yes"
      ETCD_ADVERTISE_CLIENT_URLS: "http://0.0.0.0:2379"
      ETCD_LISTEN_CLIENT_URLS: "http://0.0.0.0:2379"
    ports:
      - "2379:2379"
    networks:
      - apisix-net

networks:
  apisix-net:
    driver: bridge

Iniciamos el stack ejecutando docker-compose up -d desde el directorio raíz.

Configuración de enrutamiento de peticiones

Una vez desplegado, accedemos al panel de control mediante http://direccion-ip:9000 utilizando las credenciales definidas en la configuración (admin/admin por defecto).

Deifnición de backends (Upstream)

El primer paso cosniste en registrar los servicios destino:

1. En el menú lateral, seleccionamos Upstream → Create
2. Asignamos un nombre identificativo y descripción
3. Seleccionamos el algoritmo de balanceo de carga (round-robin, least-connections, etc.)
4. Configuramos los nodos destino mediante nombre de host o dirección IP
5. Especificamos protocolo, puerto y tiempos de espera para conexiones
6. Confirmamos para registrar el backend

Creación de reglas de enrutamiento (Route)

Accedemos a Route → Create para definir cómo se procesan las solicitudes entrantes.

Modalidad 1: Reenvío directo sin transformación

Esta modalidad mantiene la ruta original intacta al comunicarse con el servicio backend:

• Host: dominio que identifica la petición
• Path: patrón de coincidencia, por ejemplo /api/weather/*
• Rewrite: seleccionamos Keep original

Con esta configuración, una petición a /api/weather/forecast se transmite idéntica al servicio destino.

Modalidad 2: Reescritura de ruta mediante expresiones regulares

Esta modalidad elimina prefijos de servicio antes de enviar al backend:

• Path: /svc-pedidos/* (captura todo bajo este prefijo)
• Rewrite: Regex rewrite
• Pattern: ^svc-pedidos/(.*)
• Template: /$1

De este modo, /svc-pedidos/compras/listado se transforma en /compras/listado antes de llegar al servicio.

Evaluación de rendimiento

Realizamos pruebas de carga en entorno local con procesador Ryzen 7 3700X y 16GB de memoria.

Escenario A: Reescritura con expresiones regulares

El procesamiento de patrones regex introduce overhead computacional. Los resultados muestran capacidad para procesar más de 10,000 peticiones por segundo, suficiente para la mayoría de escenarios productivos.

Escenario B: Reenvío sin transformación

Eliminando la capa de reescritura, el gateway alcanza más de 30,000 RPS. Para contextualizar, una API nativa en .NET 5.0 sin intermediarios ronda los 40,000 RPS, posicionando a APISIX como una solución de gateway con impacto de latencia mínimo.