Patrón embajador

Crea servicios auxiliares que envían solicitudes de red en nombre de una aplicación o servicio de consumidor. Un servicio ambassador puede considerarse como un proxy fuera del proceso que se encuentra ubicado junto al cliente.

Este patrón puede ser útil para descargar tareas comunes de conectividad de cliente, como la supervisión, el registro, el enrutamiento, la seguridad (como TLS) y los patrones de resistencia de una manera independiente del lenguaje. A menudo se usa con aplicaciones heredadas u otras aplicaciones que son difíciles de modificar, con el fin de ampliar sus funcionalidades de red. También puede permitir que un equipo especializado implemente esas características.

Contexto y problema

Las aplicaciones basadas en la nube resistentes requieren características como la interrupción del circuito, el enrutamiento, la medición y la supervisión, y la capacidad de realizar actualizaciones de configuración relacionadas con la red. Puede ser difícil o imposible actualizar aplicaciones heredadas o bibliotecas de código existentes para agregar estas características, ya que el equipo de desarrollo ya no mantiene el código o no puede modificarlo fácilmente.

Las llamadas de red también pueden requerir una configuración sustancial para la conexión, la autenticación y la autorización. Si estas llamadas se usan en varias aplicaciones, creadas con varios lenguajes y marcos, las llamadas deben configurarse para cada una de estas instancias. Además, es posible que un equipo central de la organización deba administrar la funcionalidad de red y seguridad. Con una base de código grande, puede ser arriesgado que ese equipo actualice el código de aplicación con el que no está familiarizado.

Solución

Coloque marcos de cliente y bibliotecas en un proceso externo que actúe como proxy entre la aplicación y los servicios externos. Implemente el proxy en el mismo entorno de host que la aplicación para permitir el control sobre el enrutamiento, la resistencia, las características de seguridad y evitar restricciones de acceso relacionadas con el host. También puede usar el patrón de embajador para estandarizar y ampliar la instrumentación. El proxy puede supervisar las métricas de rendimiento, como la latencia o el uso de recursos, y esta supervisión se produce en el mismo entorno host que la aplicación.

Las características que se descargan en el embajador se pueden administrar independientemente de la aplicación. Puede actualizar y modificar el embajador sin alterar la funcionalidad heredada de la aplicación. También permite a los equipos independientes especializados implementar y mantener las características de seguridad, redes o autenticación que se han movido al embajador.

Los servicios de embajador se pueden implementar como un sidecar para acompañar el ciclo de vida de una aplicación o servicio consumidor. Como alternativa, si un embajador es compartido por varios procesos independientes en un host común, se puede implementar como demonio o servicio de Windows. Si el servicio de consumo está en contenedor, el embajador debe crearse como un contenedor independiente en el mismo host, con los vínculos adecuados configurados para la comunicación.

Problemas y consideraciones

Tenga en cuenta los siguientes puntos a medida que decida cómo implementar este patrón:

• El proxy agrega cierta sobrecarga de latencia. Considere si una biblioteca cliente, invocada directamente por la aplicación, es un enfoque mejor.
• Tenga en cuenta el posible impacto de incluir características generalizadas en el proxy. Por ejemplo, el embajador podría gestionar los reintentos, pero eso podría no ser seguro a menos que todas las operaciones sean idempotentes.
• Considere un mecanismo para permitir que el cliente pase algún contexto al proxy y vuelva al cliente. Por ejemplo, incluya encabezados de solicitud HTTP para no participar en el reintento o especificar el número máximo de veces que se va a reintentar.
• Tenga en cuenta cómo empaquetará e implementará el proxy.
• Considere si se debe usar una única instancia compartida para todos los clientes o una instancia de para cada cliente.

Cuándo usar este patrón

Use este patrón en los siguientes supuestos:

• Es necesario crear un conjunto común de características de conectividad de cliente para varios lenguajes o marcos.
• Es necesario delegar las preocupaciones transversales de conectividad del cliente a desarrolladores de infraestructura u otros equipos más especializados.
• Es necesario admitir los requisitos de conectividad de la nube o del clúster en una aplicación heredada o una aplicación que sea difícil de modificar.
• Debe admitir protocolos o patrones de conectividad que no se controlan fácilmente mediante puertas de enlace de API, mallas de servicio o controles de entrada y salida estándar.

Este patrón podría no ser adecuado cuando:

• Cuando la latencia de la solicitud de red es crítica. Un proxy presenta cierta sobrecarga, aunque es mínima y, en algunos casos, esto puede afectar a la aplicación.
• Cuando un solo idioma consume las características de conectividad de cliente. En ese caso, una mejor opción podría ser una biblioteca cliente que se distribuye a los equipos de desarrollo como un paquete.
• Cuando las características de conectividad no se pueden generalizar y requieren una integración más profunda con la aplicación cliente.
• Cuando la plataforma de aplicaciones admite soluciones precompiladas, como una malla de servicio, para controlar las funcionalidades de mTLS, administración de tráfico y directivas. En ese caso, úselos en lugar de crear una solución de embajador personalizada.

Diseño de cargas de trabajo

Un arquitecto debe evaluar cómo se puede usar el patrón Ambassador en el diseño de su carga de trabajo para abordar los objetivos y principios descritos en los pilares de Azure Well-Architected Framework. Por ejemplo:

Al igual que con cualquier decisión de diseño, hay que tener en cuenta las ventajas y desventajas con respecto a los objetivos de los otros pilares que podrían introducirse con este patrón.

Ejemplo

En el diagrama siguiente se muestra una aplicación que realiza una solicitud a un servicio remoto a través de un proxy de embajador. El embajador proporciona enrutamiento, interrupción del circuito y registro. Llama al servicio remoto y, a continuación, devuelve la respuesta a la aplicación cliente:

En un entorno containerizado, este 'ambassador' se ejecutaría como un contenedor 'sidecar' junto al contenedor de aplicaciones. En entornos no contenedorizados, se implementaría como un proceso local o un servicio de Windows en el mismo host.

Paso siguiente

• Patrón Sidecar