Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Implemente componentes de aplicación en un proceso o contenedor independiente de la aplicación principal para proporcionar aislamiento y encapsulación. Este patrón le permite crear aplicaciones a partir de diversos componentes y tecnologías.
Al igual que un sidecar de motocicleta, estos componentes se conectan a una aplicación primaria y comparten su ciclo de vida, por lo que se crean y retiran juntos. Este patrón también se conoce como patrón Sidekick y admite la descomposición de la aplicación.
Contexto y problema
A menudo, las aplicaciones y los servicios requieren funcionalidad relacionada, como la supervisión, el registro, la configuración y los servicios de red. Puede implementar estas tareas periféricas como componentes o servicios independientes.
Los componentes estrechamente integrados se ejecutan en el mismo proceso y usan eficazmente recursos compartidos, pero carecen de aislamiento. Una interrupción en un componente puede afectar a toda la aplicación. También requieren la implementación en el lenguaje de la aplicación primaria, que crea la interdependencia.
Si descompone la aplicación en servicios, puede compilar cada servicio mediante diferentes lenguajes y tecnologías. Este enfoque proporciona más flexibilidad. Pero cada componente tiene sus propias dependencias y requiere bibliotecas específicas del lenguaje para acceder a la plataforma y a los recursos compartidos. Al implementar estas características como servicios independientes, se agrega latencia. El código y las dependencias específicos del lenguaje también aumentan la complejidad del hospedaje y la implementación.
Solución
Implemente un conjunto cohesivo de tareas junto con la aplicación principal en un proceso o contenedor independiente. Este enfoque proporciona una interfaz coherente para los servicios de plataforma en todos los lenguajes.
Un servicio sidecar se conecta a la aplicación sin formar parte de ella e implementa junto a ella. Cada instancia de aplicación obtiene su propia instancia de "sidecar" que comparte su ciclo de vida.
El patrón Sidecar proporciona las siguientes ventajas:
Independencia del idioma: El sidecar se ejecuta independientemente del entorno en tiempo de ejecución y el lenguaje de programación de la aplicación principal. Puede usar una implementación de sidecar en todas las aplicaciones escritas en distintos lenguajes.
Acceso a recursos compartidos: Sidecar puede acceder a los mismos recursos que la aplicación principal. Por ejemplo, el sidecar puede supervisar los recursos del sistema que usan ambos componentes.
Baja latencia: La proximidad del sidecar a la aplicación principal minimiza la latencia de comunicación.
Extensibilidad mejorada: Puede ampliar las aplicaciones que carecen de mecanismos de extensibilidad nativa mediante la asociación de un sidecar como un proceso independiente en el mismo host o subcontenedador.
La implementación más común de este patrón usa contenedores, que también se denominan contenedores sidecar o contenedores sidekick.
Problemas y consideraciones
Tenga en cuenta los siguientes puntos al implementar este patrón:
Considere el formato de implementación y empaquetado para implementar servicios, procesos o contenedores. Los contenedores funcionan bien para el patrón Sidecar.
Al diseñar un servicio sidecar, elija minuciosamente el mecanismo de comunicación entre procesos. Use tecnologías independientes del lenguaje o independientes del marco a menos que los requisitos de rendimiento hagan que ese enfoque no sea práctico.
Antes de agregar funcionalidad a un sidecar, evalúe si funciona mejor como un servicio independiente o un demonio tradicional.
Considere si implementar la funcionalidad como una biblioteca o a través de un mecanismo de extensión tradicional. Las bibliotecas específicas del lenguaje proporcionan una integración más profunda y menos sobrecarga de red.
Cuándo usar este patrón
Use este patrón en los siguientes supuestos:
La aplicación principal usa diversos lenguajes y marcos. Sidecars proporciona una interfaz coherente que diferentes aplicaciones pueden usar independientemente de su lenguaje o marco.
Un equipo independiente o asociado externo posee un componente.
Debe implementar un componente o una característica en el mismo host que la aplicación.
Necesita un servicio que comparta el ciclo de vida general de la aplicación principal, pero que puede actualizar de forma independiente.
Necesita un control específico sobre los límites de recursos para un recurso o componente específico. Por ejemplo, puede implementar un componente como sidecar para restringir y administrar su uso de memoria independientemente de la aplicación principal.
Este patrón podría no ser adecuado cuando:
Debe optimizar la comunicación entre procesos. Los sidecars añaden sobrecarga operacional, especialmente en términos de latencia, lo que los hace inadecuados para aplicaciones con comunicación frecuente entre componentes.
Tu aplicación es pequeña. El costo de recursos de la implementación de un sidecar para cada instancia puede superar las ventajas de aislamiento.
Debe escalar el componente de forma independiente. Si debe escalar el componente de forma diferente de la aplicación principal, impleméntelo como un servicio independiente en su lugar.
La plataforma proporciona una funcionalidad equivalente. Si la plataforma de aplicaciones ya proporciona las funcionalidades necesarias de forma nativa, los sidecars añaden complejidad innecesaria.
Diseño de cargas de trabajo
Evalúe cómo usar el patrón Sidecar 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 seguridad ayudan a garantizar la confidencialidad, integridad y disponibilidad de los datos y sistemas de su carga de trabajo. | Al encapsular estas tareas e implementarlas en procesos independientes, se reduce la superficie expuesta a ataques solo al código necesario. También puede usar sidecars para agregar controles de seguridad transversales a los componentes de la aplicación que carecen de compatibilidad nativa con estas características. - SE:04 Segmentación - SE:07 Cifrado |
| La excelencia operativa ayuda a ofrecer calidad de carga de trabajo a través de procesos estandarizados y cohesión de equipos. | Este patrón le permite integrar de forma flexible herramientas de observabilidad sin agregar dependencias al código de la aplicación. Puede actualizar y mantener el sidecar independientemente de la aplicación. - OE:04 Herramientas y procesos - OE:07 Sistema de supervisión |
| Eficiencia del rendimiento ayuda a su carga de trabajo a satisfacer eficientemente las demandas mediante optimizaciones en el escalado, los datos y el código. | Este patrón le permite centralizar tareas transversales en sidecars que se escalan entre varias instancias de aplicación. No es necesario implementar la funcionalidad duplicada para cada instancia de aplicación. - PE:07 Código e infraestructura |
Si este patrón introduce concesiones dentro de un pilar, considérelas en relación con los objetivos de los otros pilares.
Example
Puede aplicar el patrón Sidecar a muchos escenarios. Tenga en cuenta los ejemplos siguientes:
Abstracción de dependencias: Implemente un servicio personalizado junto con cada aplicación para proporcionar acceso a las funcionalidades de dependencia compartida a través de una API coherente. Este enfoque reemplaza las bibliotecas cliente específicas del lenguaje por un sidecar que controla aspectos como el registro, la configuración, la detección de servicios, la gestión de estados y las comprobaciones de salud.
El sidecar de Distributed Application Runtime (Dapr) ejemplifica este caso de uso.
Plano de datos de malla de servicio: Implemente un proxy sidecar junto con cada instancia de servicio para controlar problemas de red transversales, como el enrutamiento del tráfico, los reintentos, la seguridad mutua de la capa de transporte (mTLS), la aplicación de directivas y la telemetría.
Las mallas de servicio como Istio usan servidores proxy sidecar para implementar estas funcionalidades sin necesidad de cambios en el código de la aplicación.
Servicio complementario de embajador: Implemente un servicio de embajador como complementario. La aplicación enruta las llamadas a través del embajador, que controla el registro de solicitudes, el enrutamiento, la interrupción del circuito y otras características de conectividad.
Adaptadores de protocolo: Despliegue un sidecar para traducir entre protocolos incompatibles o formatos de datos, o para conectar sistemas de mensajería. Este enfoque permite a la aplicación usar interfaces más sencillas o heredadas.
Enriquecimiento de telemetría: Implemente un sidecar para preprocesar o enriquecer los datos de telemetría, como métricas, registros y seguimientos, antes de reenviar los datos a sistemas de supervisión externos. Los componentes como el OpenTelemetry Collector pueden ejecutarse como sidecars para normalizar, enriquecer o enrutar la telemetría de manera independiente a la aplicación.
Pasos siguientes
API de microservicios que usan Dapr: obtenga información sobre cómo Azure Container Apps usa sidecars de Dapr para ayudarle a crear microservicios sencillos, portátiles, resistentes y seguros.
Modo sidecar nativo para la característica de malla de servicio basada en Istio en Azure Kubernetes Service (AKS): obtenga información sobre cómo la característica de malla del servicio Istio para AKS usa el patrón Sidecar para abordar los desafíos de la arquitectura distribuida.