De la terminación de conexiones a la aplicación de políticas, gobernanza, observabilidad y alta disponibilidad en plataformas corporativas de APIs
Edición en profundidad - material de estudio y consulta profesional
Por João Ricardo Dutra••Material completo
Del consumidor al : control centralizado en toda la
Figura de apertura: ocupa una posición de mediación entre los consumidores y los .
Principio central
La divide una llamada en dos relaciones independientes: consumidor- y - .
Edición en profundidad: material de estudio y consulta profesional.
Presentación del capítulo
Los capítulos anteriores construyeron las bases necesarias para comprender cómo funciona realmente una . El direccionamiento, , , , , certificados, autenticación, autorización, , OpenID Connect, , y federación no son temas periféricos de la : son mecanismos que ésta termina, valida, transforma, registra o reenvía con frecuencia. Este capítulo reúne este conocimiento en una arquitectura coherente.
Una a menudo se presenta como una simple caja que se encuentra frente a los servicios. Esta representación es útil en diagramas de alto nivel, pero insuficiente para el funcionamiento. En la práctica, la mantiene oyentes, finaliza conexiones, selecciona , ejecuta políticas, consulta repositorios, aplica límites, crea conexiones con servidores, transforma mensajes y produce telemetría. Cada llamada pasa por diferentes estados y puede ocurrir una falla antes de que se ejecute cualquier código comercial.
La arquitectura también incluye elementos que no participan directamente en cada solicitud. Los planos de control distribuyen las configuraciones, los planos de gestión organizan el ciclo de vida, los portales sirven a los desarrolladores, los bancos almacenan metadata y los componentes analíticos agregan eventos. Un diseño robusto necesita distinguir estos planes y decidir cómo se comporta el runtime cuando algún componente de gestión no está disponible.
El objetivo de este capítulo es proporcionar un modelo mental completo e independiente del producto. Los conceptos estarán relacionados con arquitecturas que se encuentran en comerciales, servicios gestionados, servidores programables y plataformas híbridas. Los próximos capítulos abordarán las políticas, Axway y Azure Management; Por lo tanto, este material enfatiza responsabilidades, límites y decisiones arquitectónicas que siguen siendo válidas en diferentes implementaciones.
Cómo estudiar este capítulo
Siga cada sección dibujando dos flechas: del consumidor a la y de la al . Para cada flecha, registre , , puerto, , protocolo, tiempo de espera, identidad y telemetría. Esta separación evita atribuir al una falla que ocurrió en el o atribuir al consumidor una falla creada en el segmento de .
Objetivos de aprendizaje
Defina y diferencielo de , balanceador de carga, , controlador de ingreso y malla de servicios.
Explique la separación entre el data plane, el control plane, el plano de gestión y el plano de desarrollador.
Describe el ciclo completo de una solicitud desde el hasta el y la respuesta.
Comprenda el enrutamiento, las políticas, la transformación, la autenticación, las cuotas, el y la observabilidad.
Compare topologías centralizadas, de dominio, en capas, regionales, híbridas y administradas.
Diseñe alta disponibilidad, tolerancia a fallas, consistencia de configuración y continuidad operativa.
Relacione , , certificados, grupos de conexiones, comprobaciones de estado, reintentos y disyuntores con la .
Analice la multitenant, el aislamiento, la gobernanza y el ciclo de vida de las .
Escale la capacidad en función de las conexiones, el rendimiento, la latencia, la CPU, la memoria y las dependencias externas.
Diagnostique fallas por etapa y cree evidencia correlacionada entre el consumidor, la y el .
Estructura del capítulo
21.1 ¿Qué es una ?
21.2 Qué no es una
21.3 Datos, control, gestión y planes de desarrollo
21.4 Anatomía de una solicitud en la
21.5 Oyentes, hosts virtuales y selección de
21.6 Motor de políticas y cadena de procesamiento
21.7 Enrutamiento, descubrimiento y conectividad con
21.8 Seguridad en la y
21.9 Control de tráfico, protección y
21.10 Topologías y modelos de implementación
21.11 Alta disponibilidad y coherencia
21.12 Estado, sesiones y dependencias externas
21.13 Observabilidad, auditoría y correlación
21.14 Gobernanza, portal y ciclo de vida
21.15 Planificación del desempeño y la capacidad
21.16 Fallos, antipatrones y retroubleshooting
21.17 Estudios de casos y laboratorios
Resumen, lista de verificación, ejercicios, glosario y referencias.
21.1 ¿Qué es una ?
Una es un componente de mediación que recibe llamadas de consumidores en un conjunto controlado de y las enruta a servicios de acuerdo con reglas de seguridad, tráfico, transformación y enrutamiento. Sirve como punto de aplicación de políticas en la del mensaje. La centralización de controles reduce la duplicación entre servicios, mejora la coherencia y permite proteger los de la exposición directa.
La palabra indica cambio de contexto. El componente no sólo reenvía bytes; puede finalizar una conexión , interpretar , validar credenciales, convertir una identidad externa en contexto interno, seleccionar una versión de , transformar , llamar a un servicio de autorización y crear una nueva conexión con el . Por lo tanto, la del consumidor y el son relaciones independientes.
En términos de arquitectura, la actúa principalmente en el data plane. Con cada solicitud, toma decisiones basadas en la configuración publicada y los datos de runtime. Estas decisiones deben ser rápidas, deterministas y observables. La no debe depender de una llamada remota lenta para cada simple, ni debe convertirse en un único punto de falla que bloquee toda la plataforma.
Una plataforma puede incluir múltiples . Una externa protege las públicas; otro sirve a las integraciones internas; un tercio está en una región específica; Los dominios regulados pueden utilizar dedicadas. La definición es funcional: todos son puntos de mediación y , aunque los productos, topologías y responsabilidades varían.
modelo mental
La puerta de no es sólo una dirección. Es un runtime que transforma una llamada entrante en una decisión de y una nueva llamada a un destino seleccionado.
21.2 Qué no es una
Un reverse acepta conexiones on-behalf-of servidores ascendentes y reenvía mensajes. Cada ejecuta algún tipo de reverse , pero no todos los reverse proxys ofrecen catalogación, publicación, suscripción, análisis, autenticación delegada o gobernanza del ciclo de vida. El concepto de añade una capa de productos y políticas además de la intermediación básica.
Un equilibrador de carga distribuye conexiones o solicitudes entre destinos elegibles. La también puede equilibrar los , pero su función no se limita a eso. Comprende la , la identidad del consumidor, la operación llamada y las políticas asociadas. Un equilibrador L4 puede elegir una instancia sin interpretar ; una normalmente opera en L7, aunque depende de los componentes circundantes de L4.
Un busca patrones de ataque en el tráfico web. Complementa la , pero no reemplaza la autorización comercial, la validación de , las cuotas de aplicaciones o la transformación de contratos. Un controlador de publica servicios desde un clúster de Kubernetes y puede tener capacidades de ; Una malla de servicios controla el tráfico entre cargas de trabajo y puede tener de y . Los límites se superponen, pero las responsabilidades de gobernanza y exposición deben permanecer claras.
Por último, la no debe convertirse en un servidor disfrazado. Cuando la lógica de dominio, las reglas comerciales complejas y las orquestaciones extensas se combinan en políticas, la plataforma se vuelve difícil de probar, versionar y evolucionar. La pasarela deberá realizar mediaciones y controles transversales; la lógica que define el negocio sigue siendo de los servicios responsables.
Tabla 1: Los conceptos cercanos no deben tratarse como sinónimos.
Componente
Responsabilidad principal
Relación con la API Gateway
reverse proxy
Termine y vuelva a crear conexiones a aguas arriba.
Es una capacidad básica de la API Gateway.
equilibrador de carga
Distribuir el flujo entre destinos.
Puede existir antes, dentro o después de la API Gateway.
WAF
Detecta y bloquea ataques web genéricos.
Complementa políticas API específicas.
Controlador de ingreso
Publicar servicios desde un clúster.
Puede implementar o integrar una API Gateway.
Malla de servicio
Controlar la comunicación entre cargas de trabajo.
Complementa la API Gateway en la malla interna.
21.3 Datos, control, gestión y planes de desarrollo
El data plane es el conjunto de tiempos de ejecución que procesan el tráfico. Mantiene escuchas, conexiones, tablas de rutas, políticas compiladas, cachés y grupos ascendentes. Tu prioridad es la disponibilidad y la baja latencia. Un problema en el portal o en la base de datos de configuración no debería interrumpir las llamadas ya publicadas, siempre y cuando el runtime tenga una copia válida y suficiente de la configuración.
El control plane transforma la intención en configuración distribuida. Recibe definiciones de , políticas, certificados, y parámetros, valida la coherencia y publica el estado en los tiempos de ejecución. Dependiendo de la plataforma, esta distribución se produce mediante push, pull, base de datos compartida, archivos, administrativas o mecanismos de configuración dinámica. El diseño debe gestionar el control de versiones, la confirmación de la aplicación y la reversión.
El plan de gestión concentra operaciones administrativas y de gobernanza: creación de , control del entorno, administrativo, auditoría, catálogo, informes y automatización CI/CD. El plan de desarrollador atiende a consumidores y productores a través de un portal, documentación, credenciales, productos, planes y análisis. Estos planes pueden estar en el mismo producto, pero tener diferentes requisitos de seguridad y disponibilidad.
La separación protege el runtime de un acoplamiento excesivo. También mejora la seguridad: no es necesario exponer la interfaz administrativa en la misma red o puerto que el tráfico . En entornos regulados, los cambios en el control plane pueden requerir aprobación, firma de artefactos, segregación de funciones y un seguimiento auditable antes de llegar al data plane.
Figura 1: La plataforma tiene planes con diferentes responsabilidades y criticidades.
21.4 Anatomía de una solicitud en la
El viaje comienza antes de la puerta de . El consumidor resuelve un nombre, selecciona una dirección, establece o y negocia . Un equilibrador o una puerta de puede recibir la conexión antes que la . Cuando el runtime finalmente acepta el mensaje, debe asociarlo con un y una definición de basada en , host, método, , u otras propiedades.
Después de la selección, la ejecuta una cadena de procesamiento. Algunos pasos son comunes: validación de tamaño y formato, autenticación, autorización, cuotas, transformación, enriquecimiento, enrutamiento y observabilidad. El orden importa. Aplicar una transformación antes de validar la firma puede cambiar el contenido protegido; consultar un antes de autorizar puede filtrar información debido al tiempo de respuesta; Registrar cargas útiles antes de enmascarar datos puede violar la privacidad.
En el tramo de , la resuelve el nombre del , elige la y la dirección de origen, abre o reutiliza una conexión, negocia y envía la solicitud transformada. La respuesta atraviesa las políticas de devolución, se puede convertir, filtrar, almacenar en caché y registrar. Sólo entonces se devuelve a través de la conexión de . Las dos partes pueden utilizar diferentes versiones de , diferentes certificados y diferentes tiempos de espera.
Una arquitectura operativa debe hacer visible esta secuencia. Los registros con estado final únicamente no indican dónde ocurrió la falla. El runtime debe exponer la etapa, la , la identificación de la , el flujo ascendente elegido, el tiempo de conexión, el tiempo de respuesta y el motivo del rechazo sin revelar secretos.
Figura 2 - Una llamada se procesa por etapas que pueden aceptar, transformar, reenviar o interrumpir el flujo.
21.5 Oyentes, hosts virtuales y selección de
Un asocia el runtime con direcciones y puertos en los que aceptará conexiones. Puede escuchar en una específica, en todas las interfaces o en direcciones virtuales proporcionadas por un balanceador de carga. El define los protocolos permitidos, las versiones de , los certificados, los límites de conexión y las opciones . Una configuración incorrecta puede hacer que la parezca no estar disponible incluso cuando las políticas sean correctas.
Los hosts virtuales permiten que varias compartan una dirección y un puerto, diferenciados por nombre. En , participa en la selección de certificados durante el protocolo de enlace ; luego, el encabezado del Host o la autoridad identifica el destino lógico de la solicitud. y Host suelen coincidir, pero no son el mismo objeto. Las discrepancias pueden provocar un certificado incorrecto, un enrutamiento inesperado o un rechazo de seguridad.
La selección de generalmente utiliza el método y la después de elegir el host. Las reglas deben ser deterministas. Las rutas superpuestas, los comodines amplios, las versiones ambiguas y las diferencias entre barras diagonales pueden dirigir una llamada a la incorrecta. Se recomienda probar la tabla de como contrato, incluidos casos negativos y conflictos.
La también debe normalizar las entradas con cuidado. La decodificación de , el manejo de barras diagonales duplicadas, la distinción entre mayúsculas y minúsculas y la normalización de pueden afectar la seguridad. Si la y el interpretan la de manera diferente, un atacante puede aprovechar la discrepancia para eludir la autorización o el .
El motor de políticas es la parte de la que evalúa las reglas sobre la solicitud y la respuesta. Una puede ser declarativa, como validar con un issuer y una audience específicos, o procesal, como ejecutar un script. Diferentes productos utilizan flujos gráficos, , , lenguajes propietarios o filtros de subprocesos. Independientemente de la forma, la debe tener insumos, resultados, fallas y efectos secundarios conocidos.
Las políticas transversales incluyen autenticación, autorización, limitación de velocidad, cuotas, , validación de esquema, transformación, enmascaramiento, , enrutamiento, reintentos y registro. Se debe diseñar la orden de ejecución. Por ejemplo, la autenticación suele preceder a las cuotas por consumidor; la validación del tamaño debe realizarse antes del costoso análisis; La desinfección de registros debe realizarse antes de emitir el evento de auditoría.
La debe distinguir entre fallas técnicas y decisiones comerciales. Una firma no válida puede generar 401; insuficiente, 403; límite superado, 429; no disponible, 503; error de conexión o protocolo, 502. Las respuestas estandarizadas mejoran la experiencia y la observabilidad del cliente, pero no deben ocultar la causa interna en los registros administrativos.
Los scripts y las extensiones ofrecen flexibilidad pero aumentan el riesgo. El código arbitrario puede bloquear subprocesos, consumir memoria, filtrar secretos o crear dependencias difíciles de gobernar. Prefiera capacidades nativas y declarativas para controles comunes; Utilice extensiones sólo cuando exista una estrategia de revisión, prueba, límites y mantenimiento.
Tabla 2: Las políticas deben evaluarse según su efecto operativo, no solo por su funcionalidad.
categoría
Ejemplos
pregunta de arquitectura
Seguridad
JWT, mTLS, clave API, autorización.
¿La decisión es local o depende de un servicio externo?
Tráfico
Límite de tasa, cuota, detención de picos.
¿El estado es por nodo, clúster o servicio global?
Mediación
Headers, JSON/XML, versionado.
¿La transformación preserva la semántica y la firma?
Resiliencia
Tiempo de espera, reintento, disyuntor.
¿Es la operación idempotente y segura de repetir?
Observabilidad
Registros, métricas, seguimientos, auditoría.
¿Cómo correlacionar las entradas y salidas?
21.7 Enrutamiento, descubrimiento y conectividad con
El enrutamiento convierte la lógica en un destino físico. El destino puede ser una fija, un grupo de servidores, un servicio descubierto por , un privado, un clúster de Kubernetes o una función administrada. La debe decidir cómo resolver nombres, cuánto tiempo almacenar en caché las respuestas, cuándo reevaluar los y cómo reaccionar ante los cambios de salud.
La conexión al es independiente de la conexión entrante. La utiliza una dirección y un puerto de origen, posiblemente sujetos a , listas permitidas y agotamiento de puertos. Puede reutilizar conexiones mediante agrupación, negociar /2, enviar diferente al Host y presentar el certificado del cliente en . Todos estos detalles deben estar alineados con las expectativas del .
Los controles de salud indican si un destino es elegible, pero no garantizan que todas las operaciones funcionen. Una prueba superficial en /health puede arrojar resultados exitosos mientras las dependencias críticas no estén disponibles. La preparación debe representar la capacidad real para recibir tráfico. El drenaje es necesario durante las implementaciones para evitar que se envíen nuevas solicitudes a una instancia de terminación.
Los reintentos y los disyuntores mejoran la resiliencia cuando se aplican con cuidado. Repetir automáticamente una operación no idempotente puede duplicar el pago o la creación de recursos. La debe considerar el método, la clave de idempotencia, la etapa de falla y el tiempo restante del presupuesto. Los disyuntores deben proteger el sistema sin transformar un problema local en una indisponibilidad prolongada debido a una configuración agresiva.
Tabla 3 - La conectividad saliente concentra la mayoría de los problemas 502 y 503.
Elemento
Función
Fallo típico
dns/descubrimiento
Encuentre endpoints actuales.
Caché obsoleto o falta resolución privada.
Grupo de conexiones
Reutilizar el transporte y reducir los apretones de manos.
Conexiones inactivas cerradas por el par.
control de salud
Eliminar objetivos incapaces.
Falso positivo debido a prueba superficial.
Reintentar
Recuperar fallas transitorias.
Duplicación o tormenta de llamadas.
disyuntor
Contener fallas persistentes.
Apertura inadecuada o recuperación lenta.
21.8 Seguridad en la y
Al ingresar, la generalmente finaliza , valida el certificado del servidor y, en , verifica el certificado del cliente. Luego interpreta mecanismos de aplicación como autenticación básica, clave , , o convertidos por un corredor. La autenticación identifica al principal; La autorización decide si puede llamar a la operación y acceder al recurso solicitado.
La no debe confiar automáticamente en los de identidad recibidos de Internet. Los como X-User, X-Roles o X-Client-ID deben eliminarse o sobrescribirse antes de propagar el contexto interno. De lo contrario, el consumidor podrá falsificar su identidad. El contexto confiable debe surgir de un mecanismo validado y estar protegido en el segmento de , preferiblemente mediante y autenticación entre cargas de trabajo.
A la , la puede presentar su propia identidad al mediante , identidad administrada, Exchange o credencial técnica. Esta identidad representa la o la aplicación de consumidor, según el modelo. Preservar solo una identidad genérica simplifica la integración, pero puede reducir la auditoría y la autorización detalladas. Propagar el original aumenta el contexto, pero expone el a semántica externa y puede ampliar la superficie de confianza.
Los secretos, claves y certificados deben obtenerse de repositorios apropiados, rotarse y auditarse. La configuración de texto claro, los registros de autorización y la exportación sin restricciones de claves privadas son fallas graves. El runtime debe continuar funcionando durante las rotaciones, aceptando períodos controlados de superposición cuando sea necesario.
Límite de confianza
La protege el solo cuando el acceso directo está bloqueado o estrictamente controlado. Si el servicio continúa expuesto a través de otra , se pueden eludir las políticas de .
21.9 Control de tráfico, protección y
La limitación de velocidad controla la velocidad de las llamadas dentro de una ventana; la cuota controla el consumo acumulado en un período; la limitación describe la reducción o el rechazo del tráfico cuando se alcanzan los umbrales; la detención de picos suaviza los picos. Los términos varían entre productos, pero la arquitectura debe definir la clave de conteo, la granularidad, el almacenamiento del estado y el comportamiento cuando falla el servicio de conteo.
El conteo por dirección es insuficiente en entornos con y . Contar por ID de aplicación, suscripción, asunto, tenant u operación produce un control más alineado con el contrato. En los clústeres, los límites locales por nodo pueden permitir un consumo agregado mayor al esperado. Los límites globales requieren coordinación distribuida y añaden latencia y dependencia.
El reduce la latencia y la carga, pero debe respetar la semántica, la identidad y la privacidad de . La clave de caché puede incluir método, , consulta, de negociación y contexto del consumidor. Almacenar respuestas personalizadas sin variar según el usuario puede filtrar datos. La también debe definir la invalidación, el , el manejo de errores y el comportamiento durante la indisponibilidad del .
Se deben implementar protecciones de tamaño, tiempo de espera, análisis y concurrencia antes de operaciones costosas. Umbrales demasiado bajos invalidan los casos válidos; Límites muy altos permiten el abuso de memoria y CPU. La plataforma debe publicar valores, medir rebotes y ajustar en función del tráfico real.
Tabla 4: Los controles de tráfico dependen de la clave, el estado y la semántica.
controlar
Posible clave
decisión importante
Límite de tarifa
cliente + API + operación.
Ventana fija, corredera o cubeta simbólica.
Cuota
suscripción + periodo.
Comportamiento al alcanzar el total.
Competencia
backend + ruta.
Cola, rebote o contrapresión.
caché
URI + headers + identidad.
Variación, TTL y datos sensibles.
Payload
operación + tipo de contenido.
Talla antes y después de la descompresión.
21.10 Topologías y modelos de implementación
En la topología centralizada, un clúster compartido publica de múltiples áreas. El modelo simplifica la gobernanza y las operaciones, pero puede crear una cola de cambios, un amplio radio de explosión y límites de capacidad comunes. La plataforma necesita multitenant, aislamiento de configuración y procesos claros para evitar que un equipo afecte a otro.
Las por dominio o producto acercan la propiedad al runtime y reducen el radio de explosión. Por otro lado, aumentan el número de instancias, los costos, la actualización y el riesgo de estándares divergentes. Un modelo federado puede combinar una plataforma de automatización y estándares centrales con tiempos de ejecución delegados a dominios.
Las arquitecturas en capas utilizan externas en el borde y internas cerca de los servicios. La capa externa concentra la protección contra Internet, la identidad de los socios y los contratos públicos; el interno controla el tráfico entre zonas y dominios. Es necesario evitar duplicidad de políticas y latencia acumulada. Cada capa debe tener una responsabilidad explícita.
Los modelos gestionados transfieren la operación de parte de la infraestructura al proveedor. Los modelos autohospedados ofrecen mayor control y personalización de la red. Las arquitecturas híbridas mantienen el control plane central y el data plane en centros de datos, clústeres o regiones privadas. La elección depende de los requisitos de conectividad, soberanía, latencia, cumplimiento, dotación de personal y continuidad.
Figura 3: La topología debe equilibrar la centralización, la autonomía, el aislamiento y el costo operativo.
21.11 Alta disponibilidad y coherencia
La alta disponibilidad comienza con el data plane. Varias instancias deben recibir tráfico a través del equilibrador de carga o enrutamiento equivalente. Las instancias deben ser reemplazables, con un estado mínimo local y una configuración reproducible. La pérdida de un nodo no puede interrumpir todo el servicio ni requerir una recuperación manual prolongada.
El control plane también debe ser resistente, pero su falta de disponibilidad puede tener un impacto diferente. Si las ya tienen una configuración válida, pueden continuar procesando llamadas mientras se bloquean nuevas publicaciones. Este modo degradado es deseable. El riesgo surge cuando el runtime consulta el control plane en cada solicitud o no mantiene suficiente configuración local.
La distribución de la configuración necesita control de versiones y confirmación. Una publicación parcial puede dejarnos con políticas diferentes. El sistema debe identificar la versión activa en cada instancia, rechazar artefactos no válidos, aplicar cambios de forma atómica cuando sea posible y permitir la reversión. El valor canario de configuración reduce el riesgo al exponer una pequeña porción del tráfico antes de la propagación completa.
La alta disponibilidad regional requiere decidir sobre , tráfico global, replicación de claves, cuotas, cachés y datos de suscripción. Activo-activo aumenta la capacidad y reduce el tiempo de recuperación, pero requiere coherencia y prevención de doble conteo. Activo-pasivo simplifica algunos estados, pero requiere pruebas frecuentes para que el entorno pasivo esté realmente listo.
Figura 4: La continuidad del runtime no debe depender de una sola instancia o del portal administrativo.
21.12 Estado, sesiones y dependencias externas
Las funcionan mejor cuando el procesamiento de solicitudes es predominantemente sin estado. Sin embargo, varias políticas introducen estados: cuotas, límites de velocidad distribuida, cachés, sesiones, , listas de revocación y disyuntores. La arquitectura necesita identificar dónde reside este estado, cómo se replica, qué coherencia se requiere y qué sucede cuando el repositorio deja de estar disponible.
Las dependencias externas incluyen proveedores de identidad, de introspección, PDP, bancos, servicios secretos, , y sistemas de análisis. Llamar a un servicio remoto en cada solicitud aumenta la latencia y la disponibilidad compuesta. Las cachés controladas, la validación local, las decisiones precompiladas y los tiempos de espera breves pueden reducir el riesgo, siempre que se consideren la revocación y la actualización.
La de fracaso debe ser explícita. La permite el tráfico cuando un control no está disponible; Bloques cerrados ante fallos. Para la autorización y validación de credenciales, a menudo es necesario el cierre fallido. Para la telemetría no crítica, el runtime puede almacenar eventos temporalmente o descartarlos de forma controlada para preservar la disponibilidad. No existe una regla única; existe una clasificación de criticidad.
Se deben evitar las sesiones de cuando no sean necesarias. La afinidad puede reducir la flexibilidad de escalado y dificultar la recuperación. Cuando un protocolo requiere un estado de conexión, como , este estado debe tratarse como una parte explícita de la arquitectura, con drenaje, reconexión y distribución de eventos.
Tabla 5: cada dependencia externa aumenta la disponibilidad compuesta de la API Gateway.
dependencia
Uso
Estrategia de resiliencia
Proveedor de identidad/JWKS
Validar tokens y claves.
Caché con actualización y rotación controladas.
PDP
Decisión de autorización.
Tiempo de espera corto, cache en riesgo y cierre fallido.
Redis/contador
Cuotas globales y límites de tarifas.
Clúster, degradación conocida y métricas.
tienda secreta
Credenciales y certificados.
Caché seguro, rotación y acceso mínimo.
Analítica
Eventos y reportajes.
Amortiguación asincrónica y contrapresión.
21.13 Observabilidad, auditoría y correlación
La observabilidad de la debe mostrar lo que sucedió en cada tramo. Las métricas entrantes miden las conexiones, las solicitudes, el estado y la latencia percibida por el consumidor. Las métricas de miden la resolución, la conexión, el protocolo de enlace, el tiempo hasta el primer byte y la respuesta del . La diferencia entre los dos ayuda a identificar los costos de las políticas y la espera interna.
Los registros deben registrar la marca de tiempo, , operación, versión, consumidor, identidad, de fallas, ID de , flujo ascendente, estado y tiempos relevantes. Es necesario enmascarar los secretos y los datos personales. La no debe registrar autorización, o carga útil completa de forma predeterminada. La auditoría administrativa debe estar separada de los registros de acceso y registrar quién cambió la configuración, qué cambió y cuándo entró en vigor.
El rastreo distribuido conecta al consumidor, la y el . La debe preservar o generar un contexto de seguimiento de acuerdo con la de la organización, creando intervalos para el procesamiento interno y las llamadas salientes. Cuando existen varios servidores , cada capa debe contribuir sin sobrescribir la correlación. Los ID de solicitud de propiedad aún pueden ser útiles, pero deben coexistir con los estándares de seguimiento.
La cardinalidad es un riesgo. Colocar asunto, completa o valores de consulta en etiquetas de métricas puede disparar las series temporales y los costos. Los datos de alta cardinalidad pertenecen a registros o seguimientos. Las métricas deben utilizar dimensiones controladas, como , operación, clase de estado, región y grupo de .
Figura 5: La correlación debe acompañar a la llamada en las dos conexiones mantenidas por la .
21.14 Gobernanza, portal y ciclo de vida
La es parte de una plataforma, no el ciclo de vida completo. Los productores deben registrar , publicar contratos, definir propiedad, entornos, versiones, productos y políticas. Los consumidores necesitan descubrir documentación, solicitar acceso, obtener credenciales y realizar un seguimiento del consumo. El materializa parte de esta relación, pero depende de procesos y datos fiables.
La gobernanza debe automatizarse en el proceso. , políticas, certificados, configuraciones de y pruebas se pueden versionar como código. Linting, validación de seguridad, diferenciación de contratos y promoción entre entornos reducen los cambios manuales. La interfaz administrativa de la no debería ser el único lugar donde existe la verdad.
El ciclo de vida incluye borrador, revisión, publicación, operación, depreciación y retiro. La debe permitir la coexistencia de versiones, la comunicación final y la medición de consumidores aún activos. Eliminar una sin telemetría y sin un plan de migración convierte la gobernanza en indisponibilidad.
Los productos y planes agrupan con reglas comerciales u operativas. Una suscripción puede vincular consumidor, credencial, cuota y conjunto de operaciones. Estos objetos necesitan propiedad, caducidad, rotación y auditoría. Las credenciales huérfanas suponen un riesgo tan importante como el de las huérfanas.
Gobernanza práctica
La configuración publicada en la debe ser reproducible en canalización, revisable por pares y asociada con un contrato. Los cambios exclusivamente manuales dificultan la auditoría, la reversión y la coherencia entre entornos.
21.15 Planificación del desempeño y la capacidad
El rendimiento de la no se puede resumir en solicitudes por segundo. El costo depende del tamaño de la carga útil, , algoritmo criptográfico, cantidad de políticas, transformaciones, llamadas externas, registro, compresión, protocolos y latencia de . Dos con el mismo RPS pueden consumir recursos muy diferentes.
Las conexiones son una dimensión en sí mismas. Una puede recibir muchas conexiones cortas, pocas conexiones /2 multiplexadas o miles de persistentes. Es necesario dimensionar los límites de los descriptores de archivos, los , los puertos efímeros, los pools y los tiempos de espera. La CPU puede agotarse a medida que el sistema agota los o la memoria intermedia.
Las pruebas de carga deben reproducir la distribución real de operaciones, autenticación, tamaños, errores y tiempo de reflexión. Probar solo una simple en un bucle le proporciona un número de laboratorio, no una capacidad de producción. Es necesario observar percentiles de latencia, saturación, colas, retransmisiones, recolección de basura, conexiones y dependencias externas.
La planificación incluye margen para fallas. Si el clúster solo admite una carga normal con todos los nodos, la pérdida de una instancia provoca la saturación. La capacidad debe considerar el mantenimiento, la implementación, el pico, el crecimiento y la conmutación por error regional. El ajuste de escala automático ayuda, pero tiene retrasos; el sistema necesita sobrevivir hasta que las nuevas instancias estén listas y en funcionamiento.
Tabla 6 - La capacidad es multidimensional y necesita pruebas representativas.
Dimensión
Indicadores
Pregunta de capacidad
Tráfico
RPS, bytes/s, operaciones.
¿Cuál es la combinación de llamadas real?
Conexiones
activo, nuevo/s, reutilización.
¿Existe agrupación, HTTP/2 o WebSocket?
CPU
cifrado, análisis y secuencias de comandos.
¿Qué políticas dominan el costo?
Memoria
buffers, caché, cargas útiles.
¿Cuál es el peor tamaño simultáneo?
Dependencias
Latencia y error externo.
¿Se satura la pasarela esperando a terceros?
21.16 Fallos, antipatrones y retroubleshooting
Se puede producir un error 404 porque el host no coincidió, no se encontró la , la versión no existe o el devolvió 404. Un 401 podría provenir de la , el , una personalizada o el servicio. Un 502 normalmente indica una falla al comunicarse con el canal ascendente, pero puede implicar , , , no válidos o una conexión cerrada. La investigación necesita localizar al remitente de la respuesta.
El antipatrón más común es tratar la como una caja opaca. Sin métricas de etapa ni acceso a registros correlacionados, los equipos cambian las políticas, los tiempos de espera y los mediante prueba. Otro antipatrón es acumular lógica empresarial en la puerta de , creando flujos largos y frágiles. También es peligroso publicar todas las en un clúster sin capacidades de aislamiento o contención de fallas.
La debe seguir capas. Primero confirme el y la dirección. Luego conexión , , escucha y selección de . Luego examine la autenticación, autorización, cuotas y transformaciones. Sólo entonces investigue la , el , la conexión saliente y la respuesta ascendente. La captura debe indicar el punto de observación, porque la y el puerto cambian al atravesar la .
Los cambios de configuración son una fuente importante de incidentes. Registre la versión activa, el tiempo de publicación y la diferencia con la versión anterior. Si solo unos pocos nodos tienen errores, sospeche de propagación parcial, caché o estado local. Si el problema aparece después de la rotación de certificados, verifique los almacenes de confianza, las cadenas, el y la superposición de validez.
Tabla 7 - El código final es sólo el comienzo del diagnóstico.
Síntoma
Pasos para comprobar
Evidencia útil
Conexión rechazada
oyente, firewall, IP/puerto.
SYN/RST, socket de escucha, estado del nodo.
El protocolo de enlace TLS falló
certificado, SNI, confianza, versión.
Alerta TLS y cadena presentada.
401 / 403
credencial, claims, póliza y PDP.
issuer, audience, scope e ID de política.
429
contar clave y estado.
mostrador, ventana, nodo y consumidor.
502/503
ruta, DNS, grupo, conexión y estado.
tiempos elegidos de entrada y salida.
Alta latencia
cola, política exterior, backend.
lapsos y descomposición del tiempo.
Lista de verificación de operativos
mínima de diagnóstico 1. Resolver nombre y confirmar destino. 2. Pruebe y hasta el . 3. Confirme el host, el método, la y la seleccionada. 4. Identifique la que aceptó o rechazó. 5. Confirmar elegida y . 6. Mida , conexión, y tiempo de . 7. Correlacione la respuesta con la versión de configuración.
21.17 Estudios de casos y laboratorios
Caso 1: externa e interna: una institución expone las a los socios a través de una perimetral y reenvía llamadas a una interna cercana a los servicios. La externa valida el certificado del socio y el ; el interno aplica autorización por dominio y rutas a privados. El diseño funciona cuando cada capa tiene una responsabilidad distinta y la correlación cruza ambas.
Caso 2: configuración parcial: después de una publicación, la mitad de las llamadas devuelven 401. El equilibrador distribuye el tráfico entre cuatro nodos, pero dos no recibieron la nueva clave . La versión de configuración registrada por instancia revela la divergencia. El incidente demuestra la necesidad de mantener el estado de la publicación, el compromiso y la configuración atómicos, no solo el estado del proceso.
Caso 3: Agotamiento de la : la recibe tráfico normalmente, pero comienza a devolver 502 en picos. La CPU y la memoria son estables. Las métricas de muestran una gran cantidad de conexiones y puertos cortos en TIME_WAIT debido a la ausencia de agrupación. Ajustar el mantenimiento de conexión, los límites y la estrategia resuelve la causa, que no estaba en las políticas .
Caso 4 - Dependencia de la autorización: todas las solicitudes consultan un PDP remoto. Cuando el PDP experimenta latencia, la acumula subprocesos y aumenta el tiempo de respuesta de las no relacionadas. La solución combina tiempo de espera, barrera, de decisiones de bajo riesgo y escalamiento discreto, preservando el cierre de fallas para operaciones sensibles.
Laboratorios sugeridos
1) Configure un reverse simple y observe ambas conexiones. 2) Simule la falla del de y compárelo con un no disponible. 3) Aplicar una y registrar la etapa de rechazo. 4) Prueba de agrupación, reintentos y tiempos de espera con un lento. 5) Publique dos versiones de configuración y verifique la reversión.
Resumen del capítulo
es un runtime de mediación y aplicación de políticas entre consumidores y . Finaliza una relación de transporte y crea otra, pudiendo cambiar identidad, protocolo, cabeceras, formato y destino. Esta posición concentra el valor de seguridad y gobernanza, pero también crea criticidad operativa.
Una plataforma madura separa el data plane, el control plane, el plano de gestión y el plano de desarrollador. El runtime debe permanecer disponible con una configuración válida incluso durante fallas de administración. Las publicaciones deben ser versionadas, confirmadas y reversibles. La topología, la alta disponibilidad y el estado distribuido deben definirse explícitamente.
El ciclo de solicitud incluye escucha, selección de , políticas, enrutamiento, conexión saliente y procesamiento de respuesta. La seguridad, el tráfico, el , la resiliencia y la observabilidad dependen del orden y el estado de estos pasos. Un diagnóstico confiable separa las entradas y las salidas y localiza el componente que produjo la decisión.
La no reemplaza la lógica empresarial, , balanceador de carga, malla de servicios ni gobernanza completa. Se integra con estos componentes. La arquitectura adecuada equilibra centralización, autonomía, aislamiento, capacidad y continuidad. El próximo capítulo profundizará en las políticas ejecutadas por el motor de .
Siguiente paso del curso
El Capítulo 22 profundizará en las Políticas de Puerta de Enlace: estructura, orden de ejecución, variables de contexto, autenticación, autorización, transformación, enrutamiento, resiliencia, scripts, manejo de errores y buenas prácticas de gobierno.
Lista de verificación de la arquitectura de la
Las responsabilidades de la se diferencian de , equilibrador de carga, ingreso y malla de servicios.
El data plane, el control plane, el plano de gestión y el plano de desarrollador tienen límites y definidos.
La indisponibilidad del plan de gestión no interrumpe el tráfico ya publicado.
Los oyentes, , host, rutas y reglas de selección son deterministas y probados.
El orden de las políticas evita eludiciones, costos innecesarios y fugas de datos.
El acceso directo a los servidores está bloqueado o estrictamente controlado.
Se dimensionan las conexiones salientes, , , , comprobaciones de estado y tiempos de espera.
Los reintentos solo se aplican cuando la operación se puede repetir de forma segura.
Los límites de velocidad y las cuotas tienen clave, y estado de almacenamiento conocidos.
Los cachés varían según la identidad y no almacenan datos confidenciales de forma insegura.
Las configuraciones están versionadas, canalizadas, confirmadas y reversibles.
Los registros, métricas y seguimientos correlacionan las políticas entrantes y salientes.
El clúster admite la pérdida de nodos y tiene margen para picos y conmutación por error.
Las dependencias externas tienen tiempo de espera, estrategia de falla y observabilidad.
Hay runbooks para 401, 403, 429, 502, 503, y latencia.
Ejercicios
Explique por qué la del consumidor y el de la son conexiones independientes.
Diferenciar entre , reverse , , balanceador de carga y malla de servicios.
Describir los cuatro planos lógicos de una plataforma .
Armar la secuencia de procesamiento de una solicitud y justificar el orden de las políticas.
Explique cómo y Host participan en la selección de .
Compare topologías centralizadas, de dominio, en capas e híbridas.
Proponer una arquitectura de alta disponibilidad que sobreviva la pérdida del control plane.
Analice cuándo es preferible la validación local a la introspección remota.
Explique cómo la agrupación y afectan la conectividad con los .
Proponer métricas para separar la latencia de la y la latencia del .
Analice los riesgos de almacenar una lógica empresarial extensa en las políticas.
Cree un script para investigar respuestas 502 intermitentes en una sola región.
Glosario
Tabla 8 - Vocabulario esencial del capítulo.
Término
Definición
API Gateway
Tiempo de ejecución para la mediación y aplicación de políticas entre consumidores y backends.
Plano de control
Plan que distribuye la configuración y el estado deseado a los tiempos de ejecución.
Plan de datos
Plan que procesa el tráfico real de las API.
Portal de desarrolladores
Interfaz de descubrimiento, documentación, incorporación y consumo.
Drenar
Proceso de detener nuevas solicitudes antes de terminar una instancia.
Salida
Tráfico saliente desde la API Gateway hacia el backend.
cerrado por falla
Comportamiento que bloquea cuando falla un control crítico.
Apertura fallida
Comportamiento que permite la continuidad cuando falla un control.
Entrada
Tráfico que ingresa al runtime a través del oyente.
oyente
Endpoint local que acepta conexiones y protocolos.
plan de manejo
Plan administrativo de publicación, catalogación y gobierno.
Política
Regla ejecutada ante solicitud, respuesta o error.
ruta
Mapeo entre API lógica y destino de backend.
SNAT
Traducción de la dirección y puerto de origen en el segmento de salida.
aguas arriba
Servidor o grupo de destino llamado por la API Gateway.
anfitrión virtual
Dirección y puerto compartidos de identidad del host lógico.
Referencias técnicas
. 9110 - Semántica .
. 9111: .
. 8446: Protocolo de seguridad de la capa de transporte, versión 1.3.
. 9457: Detalles del problema para las .
. SP 800-204 - Estrategias de seguridad para sistemas de aplicaciones basados en microservicios.
. SP 800-207: Arquitectura de confianza cero.
Iniciativa . Especificación de .
Centro de arquitectura de Microsoft Azure. Patrón de .
Documentación de del enviado. Descripción general de la arquitectura y filtros .
. Top 10 de seguridad de .
CNCF. de y materiales arquitectónicos de malla de servicios.
Nota de actualización
Los productos evolucionan a su propio ritmo. Al aplicar los conceptos a una plataforma específica, confirme la documentación de la versión implementada, especialmente para protocolos, políticas, agrupación en clústeres, límites, integración de identidades y comportamiento de alta disponibilidad.
