Patrón embajador

Crea servicios auxiliares que envían solicitudes de red en nombre de una aplicación o servicio de consumidor. Piense en un servicio de embajador como un proxy fuera del proceso que está ubicado junto al cliente.

Use el patrón Ambassador para descargar tareas comunes de conectividad de cliente como supervisión, registro, enrutamiento, seguridad como Seguridad de la capa de transporte (TLS) y patrones de resistencia de forma independiente del lenguaje. Amplíe las funcionalidades de red de las aplicaciones heredadas u otras aplicaciones que son difíciles de modificar mediante el patrón Ambassador. Los equipos especializados también pueden usar el patrón Ambassador para implementar 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 las actualizaciones de configuración relacionadas con la red. Si el equipo de desarrollo no mantiene el código o no puede modificarlo fácilmente, puede ser difícil o incluso imposible actualizar aplicaciones heredadas o bibliotecas de código existentes para agregar estas características.

Las llamadas de red también pueden requerir una configuración sustancial para la conexión, la autenticación y la autorización. Cuando varias aplicaciones usan estas llamadas en distintos lenguajes y marcos, debe configurar las llamadas por separado para cada instancia. Es posible que un equipo central de su organización tenga que 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 desconocido.

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. Para proporcionar control sobre las características de enrutamiento, resistencia y seguridad, y para evitar restricciones de acceso relacionadas con el host, implemente el proxy en el mismo entorno de host que la aplicación. Use el patrón ambassador para estandarizar y ampliar la instrumentación. El proxy puede supervisar las métricas de rendimiento, como la latencia o el uso de recursos, en el mismo entorno de host que la aplicación.

Diagrama que muestra una aplicación cliente y un proxy de embajador colocado en el mismo host. La aplicación cliente envía solicitudes al embajador en lugar de llamar directamente a servicios externos. El embajador reenvía esas solicitudes al servicio remoto. Las respuestas del servicio remoto regresan a través del embajador y vuelven a la aplicación cliente.

Puede gestionar características que se delegan al embajador de forma independiente de la aplicación. Puede actualizar y modificar el embajador sin alterar la funcionalidad heredada de la aplicación. Los equipos especializados independientes también pueden implementar y mantener características de seguridad, redes o autenticación que se han movido al embajador.

Puede implementar servicios de embajador como sidecar para acompañar el ciclo de vida de una aplicación o servicio de consumo. Como alternativa, si varios procesos independientes en un host común comparten un ambassador, puede implementarlo como demonio o servicio de Windows. Si el servicio de consumo está en contenedores, cree el embajador como un contenedor independiente en el mismo host y configure los vínculos adecuados para la comunicación.

Problemas y consideraciones

Tenga en cuenta los puntos siguientes al decidir cómo implementar este patrón:

• El proxy agrega cierta sobrecarga de latencia. Considere si una biblioteca cliente a la que invoca la aplicación directamente es un enfoque mejor.

• Tenga en cuenta el posible impacto de incluir características generalizadas en el proxy. Por ejemplo, el embajador podría controlar los reintentos, pero ese enfoque podría no ser seguro a menos que todas las operaciones sean idempotentes.

• Considere un mecanismo que el cliente puede usar para pasar algún contexto al proxy y volver 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.

• Considere 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:

• Debe crear un conjunto común de características de conectividad de cliente para varios lenguajes o marcos.

• Debe delegar las cuestiones transversales de conectividad de clientes a los desarrolladores de infraestructura u otros equipos más especializados.

• Debe 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 controlen fácilmente las puertas de enlace de API, las mallas de servicio o los controles de entrada y salida estándar.

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

• La latencia de la solicitud de red es fundamental. Un proxy presenta una sobrecarga mínima y esta sobrecarga puede afectar a la aplicación.

• Las características de conectividad de cliente las consume un solo idioma. En ese caso, una mejor opción podría ser una biblioteca cliente que se distribuya a los equipos de desarrollo como un paquete.

• Las características de conectividad no se pueden generalizar y estas características requieren una integración más profunda con la aplicación cliente.

• La plataforma de aplicaciones admite soluciones preconstruidas, como una malla de servicio, para gestionar TLS mutuo (mTLS), la administración del tráfico y las capacidades de políticas. Use estas soluciones en lugar de crear una solución de embajador personalizada.

Diseño de cargas de trabajo

Evalúe cómo usar el patrón Ambassador en el diseño de una carga de trabajo para abordar los objetivos y principios descritos en los pilares de Azure Well-Architected Framework. En la tabla siguiente se proporciona una guía sobre cómo este patrón apoya los objetivos de cada pilar.

Fundamento	Cómo apoya este patrón los objetivos de los pilares
Las decisiones de diseño de fiabilidad ayudan a que su carga de trabajo sea resiliente a fallos y garantizan que se recupere a un estado de pleno funcionamiento después de que se produzca un fallo.	Este patrón presenta un punto de mediación de comunicaciones de red, por lo que puede agregar patrones de confiabilidad a la comunicación de red, como reintento o almacenamiento en búfer. - RE:07 Autopreservación
Las decisiones de diseño de seguridad ayudan a garantizar la confidencialidad, integridad y disponibilidad de los datos y sistemas de su carga de trabajo.	Con este patrón, puede implementar la seguridad en las comunicaciones de red que el cliente no puede controlar directamente. - SE:06 Controles de red - SE:07 Cifrado

Si este patrón introduce concesiones dentro de un pilar, considérelas en relación con los objetivos de los otros pilares.

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.

Diagrama que muestra una aplicación cliente que envía una solicitud a un proxy de embajador. La aplicación envía una solicitud al servicio remoto a través de un proxy de embajador. El embajador determina la ubicación de los servicios remotos y enruta la solicitud de forma adecuada. El embajador comprueba el estado del disyuntor y enriquece los encabezados de solicitud con información de seguimiento. El embajador comienza a medir la latencia de la solicitud. El embajador cifra y envía la solicitud mediante la autenticación mutua basada en certificados. El servicio remoto recibe la solicitud y envía la respuesta. El embajador registra la latencia de la solicitud. El embajador devuelve la respuesta al cliente. La aplicación recibe la respuesta.

En entornos de contenedores, este embajador se ejecutaría como un contenedor adicional (sidecar) al lado del contenedor de aplicaciones. En entornos no contenerizados, lo implementarías como un proceso local o un servicio de Windows en el mismo host.

Paso siguiente

• Patrón Sidecar