Capítulo 4. Malla de Servicios:Gestión del Tráfico de Servicio a Servicio
Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com
En el capítulo anterior de exploraste cómo exponer tus API y gestionar el tráfico de entrada asociado desde usuarios finales y otros sistemas externos de forma fiable, observable y segura utilizando una pasarela API. Ahora aprenderás a gestionar el tráfico de las API internas, es decir, la comunicación de servicio a servicio, con objetivos similares.
En un nivel fundamental, las implementaciones de malla de servicios proporcionan funcionalidad para enrutar, observar y asegurar el tráfico para la comunicación de servicio a servicio. Vale la pena decir que incluso esta elección de tecnología no es pan comido; como con todas las decisiones arquitectónicas, hay compensaciones; ¡no existe el almuerzo gratis cuando desempeñas el papel de arquitecto!
En este capítulo evolucionarás el caso práctico extrayendo la funcionalidad de gestión de sesiones del sistema de conferencias heredado y convirtiéndola en un nuevo servicio interno de Sesión. Al hacerlo, aprenderás los retos de comunicación que plantea la creación o extracción de nuevos servicios y API que se implementan y ejecutan junto con el sistema de conferencias monolítico existente. Todas las técnicas de API y gestión del tráfico que exploraste en el capítulo anterior se aplicarán aquí, por lo que tu inclinación natural puede ser utilizar una pasarela de API para exponer el nuevo servicio Sesión. Sin embargo, dados los requisitos, lo más probable es que esto resulte en una solución subóptima. Aquí es donde el patrón de malla de servicios y las tecnologías asociadas pueden proporcionar un enfoque alternativo.
¿Es la malla de servicios la única solución?
Prácticamente toda aplicación de software basada en web necesita hacer llamadas de servicio a servicio, aunque se trate simplemente de una aplicación monolítica que interactúa con una base de datos. Por ello, existen desde hace tiempo soluciones para gestionar este tipo de comunicación. El enfoque más habitual consiste en utilizar una biblioteca específica del lenguaje, como una biblioteca del kit de desarrollo de software (SDK) o un controlador de base de datos. Estas bibliotecas asignan las llamadas basadas en la aplicación a solicitudes de API de servicio y también gestionan el tráfico correspondiente, normalmente mediante el uso de protocolos HTTP o TCP/IP. A medida que el diseño de las aplicaciones modernas ha ido adoptando arquitecturas orientadas a servicios, se ha ampliado el espacio problemático de las llamadas de servicio a servicio. Es muy común que un servicio necesite llamar a la API de otro servicio para satisfacer la petición de un usuario. Además de proporcionar un mecanismo de enrutamiento del tráfico, normalmente también requerirá fiabilidad, observabilidad y seguridad.
Como aprenderás a lo largo de este capítulo, tanto una biblioteca como una solución basada en mallas de servicios pueden satisfacer a menudo tus requisitos de comunicación de servicio a servicio. Hemos visto una rápida adopción de las mallas de servicios, sobre todo en el contexto empresarial, y a medida que aumenta el número de consumidores y proveedores, suele ser la opción más escalable, mantenible y segura. Por eso, este capítulo se ha centrado principalmente en el patrón de malla de servicios.
Directriz: ¿Deberías adoptar la Malla de Servicios?
La Tabla 4-1 proporciona a una serie de Directrices ADR para ayudarte a decidir si debes adoptar la tecnología de malla de servicios en tu organización.
Caso práctico: Extraer la funcionalidad de las sesiones a un servicio
Para el estudio de caso de próxima evolución de nuestro sistema de conferencias, te centrarás en las peticiones de los propietarios de las conferencias para que admitan una nueva función esencial: Ver y gestionar las sesiones de conferencia de un asistente a través de la aplicación móvil.
Se trata de un cambio importante que justificaría la creación de una ADR. El Cuadro 4-2 es un ejemplo de ADR que podría haber propuesto el equipo de ingeniería propietario del sistema de conferencias.
| Estado | Propuesta |
|---|---|
Contexto |
Los propietarios de la conferencia han solicitado otra nueva función para el sistema de conferencias actual. El equipo de marketing cree que el compromiso de los asistentes a la conferencia aumentará si un asistente puede ver los detalles de las sesiones de la conferencia e indicar su interés en ellas a través de la aplicación móvil. El equipo de marketing también quiere poder ver cuántos asistentes están interesados en cada sesión. |
Decisión |
Daremos un paso evolutivo para dividir el componente Sesión en un servicio independiente. Esto permitirá el desarrollo API-first contra el servicio Sesión y permitirá invocar la API desde el servicio de conferencia heredado. Esto también permitirá que el servicio Asistente llame directamente a la API del servicio Sesión para proporcionar información de la sesión a la aplicación móvil. |
Consecuencias |
La aplicación heredada llamará al nuevo servicio Sesión cuando gestione todas las consultas relacionadas con las sesiones, tanto para las funciones existentes como para las nuevas. Cuando un usuario quiera ver, añadir o eliminar sesiones que le interesen en una conferencia, el servicio Asistente tendrá que llamar al servicio Sesión. Cuando un administrador de la conferencia quiera ver quién asiste a cada sesión, el servicio Sesión tendrá que llamar al servicio Asistente para determinar quién asiste a cada sesión. El servicio de Sesión podría convertirse en un punto único de fallo en la arquitectura y puede que tengamos que tomar medidas para mitigar el impacto potencial de ejecutar un único servicio de Sesión. Dado que la visualización y gestión de sesiones por parte de los asistentes aumenta drásticamente durante un evento de conferencia en directo, también tendremos que tener en cuenta los grandes picos de tráfico y, potencialmente, que uno o más servicios de Sesión se sobrecarguen o actúen de forma degradada. |
El Modelo C4 que muestra el cambio arquitectónico propuesto se muestra en la Figura 4-1.
Figura 4-1. Modelo C4 que muestra la extracción del servicio Sesión del sistema de conferencias
Ten en cuenta que, aunque no es necesario exponer externamente el nuevo servicio de Sesión, podrías cumplir fácilmente los requisitos de enrutamiento y fiabilidad indicados en el ADR anterior exponiendo este servicio a través de la pasarela API y configurando tanto el sistema heredado como el servicio de Asistentes para llamar a este nuevo servicio a través de la dirección externa de la pasarela. Sin embargo, esto sería un ejemplo del antipatrón "loopback de pasarela de API" que conociste en "Errores comunes en la implementación de pasarelas de API". Este antipatrón puede hacer que el tráfico destinado internamente salga potencialmente de tu red, lo que tiene implicaciones de rendimiento, seguridad y (proveedor de la nube) costes. Exploremos ahora cómo una malla de servicios puede ayudarte a cumplir tus nuevos requisitos evitando este antipatrón .
¿Qué es la Malla de Servicios?
Fundamentalmente, "malla de servicios" es un patrón para gestionar toda la comunicación de servicio a servicio (o de aplicación a aplicación) dentro de un sistema de software distribuido. Hay mucho solapamiento entre los patrones de malla de servicios y de pasarela API, con dos diferencias principales: en primer lugar, las implementaciones de malla de servicios están optimizadas para gestionar el tráfico de servicio a servicio, o de este a oeste, dentro de un clúster o centro de datos. En segundo lugar, a raíz de esto, el originador de la comunicación suele ser un servicio interno (en cierto modo) conocido, en lugar del dispositivo de un usuario o un sistema que se ejecuta de forma externa a tus aplicaciones.
La malla de servicios no es una red mallada
La malla de servicios es , que no debe confundirse con las redes de malla, que son topologías de red de nivel inferior. Las redes de malla son cada vez más frecuentes en el contexto del Internet de las Cosas (IoT) y también para implantar infraestructuras de comunicación móvil en escenarios remotos o difíciles (como la ayuda en catástrofes). Las implantaciones de malla de servicios se basan en los protocolos y topologías de red existentes.
El patrón de malla de servicios se centra en proporcionar gestión del tráfico (enrutamiento), resiliencia, observabilidad y seguridad para la comunicación de servicio a servicio. No te preocupes si no has oído hablar mucho de este patrón, ya que no fue hasta 2016 cuando el equipo de Buoyant acuñó el término para explicar la funcionalidad de su tecnología Linkerd.1 Esto, en combinación con la introducción de otras tecnologías relacionadas como Istio, patrocinada por Google, condujo a la rápida adopción del término "malla de servicios" dentro de los dominios de la computación en nube, DevOps y arquitectura.
Al igual que una pasarela API, una malla de servicios se implementa con dos componentes fundamentales de alto nivel: un plano de control y un plano de datos. En una malla de servicios, estos componentes siempre se implementan por separado. El plano de control es donde los operadores interactúan con la malla de servicios y definen las rutas, las políticas y la telemetría necesaria. El plano de datos es el lugar donde se realiza todo el trabajo especificado en el plano de control y donde se enrutan los paquetes de red, se aplican las políticas y se emite la telemetría.
Si tomamos como ejemplo la configuración del tráfico de servicio a servicio dentro de un clúster Kubernetes, un operador humano definirá primero el enrutamiento y la política mediante la configuración de Recursos Personalizados -por ejemplo, en nuestro caso de estudio, especificando que el servicio de Asistentes puede llamar al servicio de Sesiones- y luego lo "aplicará" al clúster mediante una herramienta de línea de comandos, como kubectl, o una canalización de entrega continua. Una aplicación de controlador de malla de servicios que se ejecuta en el clúster de Kubernetes actúa como plano de control, analizando esta configuración y dando instrucciones al plano de datos -normalmente una serie de proxies "sidecar" que se ejecutan junto a cada uno de los servicios de Asistente y Sesión- para que la aplique.
Todo el tráfico de servicio a servicio dentro del clúster de Kubernetes se enruta a través de los proxies sidecar, normalmente de forma transparente (sin que las aplicaciones subyacentes reconozcan que hay un proxy implicado), lo que permite que todo este tráfico se enrute, observe y asegure según sea necesario. En la Figura 4-2 se muestra un ejemplo de topología del plano de control y el plano de datos de los servicios y la malla de servicios .
Figura 4-2. Topología de servicios y plano de control y plano de datos de una malla de servicios (utilizando Istio como ejemplo)
¿Qué funciones ofrece una malla de servicios?
A nivel de red , un proxy de malla de servicios actúa como un proxy completo, aceptando todo el tráfico entrante de otros servicios e iniciando también todas las peticiones salientes a otros servicios. Esto incluye todas las llamadas a la API y otras peticiones y respuestas. A diferencia de una pasarela API, el mapeo desde un plano de datos de malla de servicios a un servicio suele ser uno a uno, lo que significa que un proxy de malla de servicios no agrega llamadas a través de múltiples servicios. Una malla de servicios proporciona funcionalidades transversales como la verificación de usuarios, la limitación de la tasa de solicitudes y los tiempos de espera/reintentos, y puede proporcionar métricas, registros y datos de rastreo para apoyar la implementación de la observabilidad dentro del sistema. Ésta es exactamente la funcionalidad que necesitamos para evolucionar nuestro caso práctico extrayendo el servicio Sesión y llamándolo tanto desde el sistema de conferencias heredado como desde el servicio Asistente.
Aunque son menos comunes en comparación con una pasarela API, algunas mallas de servicios proporcionan funciones adicionales que permiten a los desarrolladores gestionar el ciclo de vida de una API. Por ejemplo, un catálogo de servicios asociado puede ayudar a la incorporación y gestión de los desarrolladores que utilizan las API de servicios, o un portal para desarrolladores proporcionará administración de cuentas y control de acceso. Algunas mallas de servicios también proporcionan auditoría de políticas y gestión del tráfico para cumplir los requisitos de gobernanza empresarial .
¿Dónde se implementa una red de servicios?
Una malla de servicios se despliega en una red interna o en un clúster. Los sistemas o redes grandes suelen gestionarse desplegando varias instancias de una malla de servicios, a menudo con cada una de ellas abarcando un segmento de red o un dominio empresarial.
En la Figura 4-3 se muestra un ejemplo de topología de red de malla de servicios.
Figura 4-3. Una topología típica de malla de servicio, desplegada en dos clusters (con flechas sólidas que muestran el tráfico de malla de servicio)
¿Cómo se integra una Malla de Servicios con otras tecnologías de red?
Una pila de red moderna puede tener muchas capas, sobre todo cuando se trabaja con tecnologías de nube en las que la virtualización y el sandboxing se producen en varios niveles. Una malla de servicios debe funcionar en armonía con estas otras capas de red, pero los desarrolladores y operadores también deben ser conscientes de las posibles interacciones y conflictos.La Figura 4-4 muestra la interacción entre la infraestructura de red física (y virtualizada), una pila de red típica y una malla de servicios.
Figura 4-4. Modelo OSI que muestra que una malla de servicios funciona entre las capas 3 y 7
Por ejemplo, al desplegar aplicaciones en un clúster Kubernetes, un Servicio puede localizar y dirigirse a otro Servicio dentro del mismo clúster mediante un nombre prescrito que se asigna a una dirección IP. Las políticas fundamentales de seguridad de control del tráfico pueden implementarse con NetworkPolicies, que controlan el tráfico a nivel de dirección IP y puerto (capa OSI 3 o 4), y los controles de políticas adicionales suelen ser proporcionados por el complemento Container Networking Interface (CNI) de un clúster.2
Las mallas de servicios pueden anular la resolución y el enrutamiento predeterminados de direcciones de servicio a IP de CNI y también proporcionar funciones adicionales, como el enrutamiento transparente entre clústeres, la aplicación de seguridad de capa 3/4 y 7 (como identidad y autorización de usuario), el equilibrio de carga de capa 7 (útil si utilizas un protocolo keepalive multiplexado como gRPC o HTTP/2) y la observabilidad a nivel de servicio a servicio y en toda la pila de redes .
¿Por qué utilizar una Malla de Servicios?
En un modo similar a decidir por qué deberías implantar una pasarela de API en tu arquitectura actual, determinar por qué adoptar una malla de servicios es un tema polifacético. Tienes que equilibrar las ganancias y los costes de implantación a corto plazo con los requisitos de mantenimiento a largo plazo. Hay muchas preocupaciones transversales relacionadas con las API que puedes tener para cada uno de tus servicios internos o para todos ellos, como la gestión del ciclo de vida del producto (publicar nuevas versiones de un servicio de forma incremental), la fiabilidad, la compatibilidad con la comunicación multilingüe, la observabilidad, la seguridad, el mantenimiento y la extensibilidad. Una malla de servicios puede ayudarte con todas ellas.
Esta sección del capítulo te proporcionará una visión general de los principales problemas que puede resolver una malla de servicios, como por ejemplo
-
Permitir un control detallado del encaminamiento de servicios, la fiabilidad y la gestión del tráfico
-
Mejorar la observabilidad de las llamadas entre servicios
-
Aplicar la seguridad, incluyendo la encriptación del transporte, la autenticación y laautorización
-
Apoyar los requisitos de comunicación interfuncional en variosidiomas
-
Gestión separada del tráfico de entrada y de servicio a servicio
Control detallado del encaminamiento, la fiabilidad y la gestión del tráfico
Enrutar el tráfico con un sistema distribuido basado en microservicios puede ser más difícil de lo que parece a primera vista. Normalmente habrá varias instancias de un servicio desplegadas en un entorno con los objetivos de mejorar tanto el rendimiento (equilibrar la carga entre servicios) como la fiabilidad (proporcionar redundancia). Además, muchas plataformas de infraestructura modernas están construidas sobre "hardware básico" que se manifiesta como recursos informáticos efímeros que pueden apagarse, reiniciarse o desaparecer en un momento; y esto significa que la ubicación de un servicio puede cambiar de un día para otro (¡o de un minuto para otro!).
Por supuesto, puedes emplear las tecnologías de enrutamiento y las técnicas asociadas que conociste en el Capítulo 3. El reto aquí es que normalmente hay muchos más servicios y API internas en comparación con el número de API externas que exponen tus aplicaciones, y el ritmo de cambio de los sistemas internos y sus correspondientes API y funcionalidad suele ser mucho mayor. En consecuencia, el coste operativo aumentaría drásticamente si tuvieras que desplegar una pasarela API delante de cada servicio interno, tanto en lo que respecta a los recursos informáticos necesarios como a los costes de mantenimiento humano.
Enrutamiento transparente y normalización del nombre del servicio
Fundamentalmente, el enrutamiento es el proceso de seleccionar una ruta para el tráfico en una red o entre varias redes o a través de ellas. En las aplicaciones web, el enrutamiento a nivel de red se ha gestionado normalmente dentro de la pila TCP/IP y la infraestructura de red asociada (en la capa 3/4 del modelo OSI). Esto significa que sólo se necesitan la dirección IP y el puerto del destino y el originador de la conexión. Antes de la nube, y a menudo con centros de datos locales, las direcciones IP de los servicios internos suelen ser fijas y conocidas. Aunque el DNS se utiliza ampliamente para asignar nombres de dominio a direcciones IP, sigue ocurriendo que las aplicaciones y servicios heredados utilizan direcciones IP codificadas. Esto significa que cualquier cambio en la ubicación de un servicio requiere una redistribución de todos los servicios que llaman a este servicio.
Con la adopción de la nube y la naturaleza efímera de nuestra infraestructura que conlleva, las direcciones IP de las instancias informáticas y sus correspondientes servicios cambian con regularidad, lo que a su vez significa que si codificas las direcciones IP y de puerto, éstas tendrán que cambiarse con frecuencia. A medida que las arquitecturas basadas en microservicios se hicieron más populares, la dificultad de volver a desplegarlas aumentó en relación con el número de servicios de una aplicación. Los primeros adoptantes de microservicios crearon soluciones para superar esto implementando directorios o registros externos de "descubrimiento de servicios" que contenían una asignación dinámica de nombres de servicios a direcciones IP y puertos.3
Las mallas de servicios pueden gestionar esta búsqueda dinámica del nombre del servicio en la ubicación, de forma externa al servicio y también de forma transparente, sin necesidad de modificar el código, volver a implementar o reiniciar. Otra ventaja de una malla de servicios es que puede normalizar la nomenclatura entre entornos utilizando la "conciencia de entorno" en combinación con la configuración almacenada de forma externa a la aplicación. Por ejemplo, una malla de servicios implementada en "producción" reconocerá que se está ejecutando en este entorno. Entonces, la malla de servicios asignará de forma transparente el nombre del servicio a nivel de código sessions-service a la ubicación específica del entorno AWS-us-east-1a/prod/sessions/v2 buscando la ubicación en un registro de servicios (que puede estar integrado en la malla o ejecutarse externamente). El mismo código desplegado en el entorno de ensayo con una malla de servicios configurada adecuadamente dirigirá sessions-service a internal-staging-server-a/stage/sessions/v3.
Fiabilidad
La naturaleza efímera de los entornos informáticos y de clústeres modernos plantea retos relacionados con la fiabilidad, además de los cambios de ubicación. Por ejemplo, cada servicio debe gestionar correctamente los problemas de comunicación con otro servicio con el que esté interactuando. En breve aprenderás más sobre "Las 8 falacias de la informática distribuida", pero los problemas que hay que tener en cuenta en este contexto incluyen que se interrumpa la conexión de un servicio, que un servicio deje de estar disponible temporalmente o que un servicio responda con lentitud. Estos retos pueden tratarse en código utilizando patrones de fiabilidad bien conocidos, como reintentos, tiempos de espera, disyuntores, mamparos y fallbacks. El libro de Michael Nygard ¡Lánzalo! Design and Deploy Production-Ready Software, ya en su segunda edición, proporciona una guía completa de exploración e implementación. Sin embargo, como explorarás más a fondo en "Apoyo a la comunicación interfuncional entre lenguajes", intentar implementar esta funcionalidad en el código suele dar lugar a comportamientos incoherentes, sobre todo en diferentes lenguajes y plataformas.
Como una malla de servicios se encarga de iniciar y gestionar todas las comunicaciones entre servicios, es el lugar perfecto para implantar sistemáticamente estos patrones de fiabilidad y ofrecer tolerancia a fallos y una degradación gradual. Dependiendo de la implementación, una malla de servicios también puede detectar problemas y compartir esta información con toda la malla, lo que permite a cada servicio de la malla tomar las decisiones adecuadas sobre cómo dirigir el tráfico; por ejemplo, si la latencia de respuesta de un servicio está aumentando, se puede ordenar a todos los servicios que llamen al servicio de destino que inicien sus acciones de emergencia.
Para el caso práctico, una malla de servicios te permitirá definir cómo gestionar los fallos que se produzcan al comunicarse con el nuevo servicio Sesión. Imagina que varios miles de asistentes a un evento acaban de ver el discurso de apertura de la conferencia matutina y quieren ver su horario del día. Este repentino pico de tráfico para el servicio Sesión puede provocar un comportamiento degradado. Para la mayoría de los casos de uso, definirías los tiempos de espera y los reintentos adecuados, pero también puedes definir una acción de interrupción del circuito que desencadene un comportamiento de la aplicación. Por ejemplo, si falla repetidamente una llamada a la API desde el servicio de Asistentes al servicio de Sesiones para obtener el programa de sesiones diarias de un asistente, puedes activar un cortacircuitos en la malla de servicios que falle rápidamente todas las llamadas a este servicio (para permitir que el servicio se recupere). Lo más probable es que dentro de la aplicación móvil gestiones este fallo "retrocediendo" para mostrar todo el programa de sesiones de la conferencia en lugar de un programa personal de .
Enrutamiento avanzado del tráfico: Shaping, policing, splitting y mirroring
Desde el boom de las punto com de finales de los 90, las aplicaciones web de consumo han manejado cada vez más usuarios y más tráfico. Los usuarios también se han vuelto más exigentes, tanto en lo que respecta al rendimiento como a las funciones ofrecidas. En consecuencia, la necesidad de gestionar el tráfico para satisfacer las necesidades de seguridad, rendimiento y liberación de funciones se ha vuelto más importante. Como aprendiste en "¿Cómo se integra una pasarela de API con otras tecnologías en el perímetro?", en el perímetro de la red surgieron dispositivos dedicados para satisfacer estos requisitos, pero esta infraestructura no era apropiada para desplegarla delante de cada servicio interno. En esta sección del capítulo aprenderás más sobre los requisitos que se han vuelto típicos para una aplicación basada en microservicios en lo que respecta a la conformación y vigilancia del tráfico interno.
Conformación del tráfico
Traffic shaping es una técnica de gestión del ancho de banda que retrasa parte o todo el tráfico de la red para ajustarlo a un perfil de tráfico deseado. El traffic shaping se utiliza para optimizar o garantizar el rendimiento, mejorar la latencia o aumentar el ancho de banda utilizable para algunos tipos de tráfico retrasando otros. El tipo más común de moldeado de tráfico es el moldeado de tráfico basado en aplicaciones, en el que primero se utilizan herramientas de huellas dactilares para identificar las aplicaciones de interés, que luego se someten a políticas de moldeado. Con el tráfico este-oeste, una malla de servicios puede generar o monitorear las huellas dactilares, como la identidad del servicio o algún otro proxy para ello, o una cabecera de solicitud que contenga metadatos relevantes -por ejemplo, si una solicitud procede de un usuario de nivel libre de una aplicación de conferencia o de un cliente de pago.
Vigilancia del tráfico
Control del tráfico es el proceso de monitorizar el tráfico de la red para comprobar que cumple una política o contrato de tráfico y tomar medidas para hacer cumplir dicho contrato. El tráfico que viola una política puede descartarse inmediatamente, marcarse como no conforme o dejarse como está, dependiendo de la política administrativa. Esta técnica es útil para evitar que un servicio interno que funciona mal cometa un ataque de denegación de servicio (DoS), o para evitar que un recurso interno crítico o frágil se sature excesivamente de tráfico (por ejemplo, un almacén de datos), Antes de la llegada de las tecnologías en la nube y las mallas de servicios, el control del tráfico en las redes internas sólo se aplicaba, por lo general, dentro de un contexto empresarial, utilizando dispositivos de hardware o software especializados, como un bus de servicios empresariales (ESB). La computación en la nube y las redes definidas por software (SDN) facilitaron la adopción de técnicas de control del tráfico mediante el uso de grupos de seguridad (SG) y listas de control de acceso a la red (NACL).
Al gestionar las comunicaciones este-oeste, los servicios dentro de la red o del límite del clúster pueden ser conscientes de un contrato de tráfico y pueden aplicar un moldeado de tráfico internamente para asegurarse de que su salida se mantiene dentro del contrato. Por ejemplo, tu servicio de Asistentes puede implementar un limitador de velocidad interno que evite llamadas excesivas a la API del servicio de Sesión dentro de un periodo de tiempo específico.
La malla de servicios permite un control granular de la conformación, división y duplicación del tráfico que hace posible cambiar o migrar gradualmente el tráfico de una versión de un servicio objetivo a otra. En "Estrategias de lanzamiento", veremos cómo puede utilizarse este enfoque para facilitar la separación de la compilación y el lanzamiento para las estrategias de lanzamiento basadas en el tráfico.
Proporcionar Observabilidad Transparente
Cuando opera cualquier sistema distribuido como una aplicación basada en microservicios, la capacidad de observar tanto la experiencia del usuario final como los componentes internos arbitrarios es de vital importancia para la identificación de fallos y la depuración de los problemas correspondientes. Históricamente, la adopción del monitoreo de todo el sistema requería la integración de agentes o bibliotecas de tiempo de ejecución altamente acoplados dentro de las aplicaciones, lo que exigía una implementación de todas las aplicaciones durante la puesta en marcha inicial y todas las actualizaciones futuras.
Una malla de servicios puede proporcionar parte de la observabilidad necesaria, en particular las métricas de aplicación (L7) y de red (L4), y hacerlo de forma transparente. Una actualización correspondiente de cualquier componente de recopilación de telemetría o de la propia malla de servicios no debería requerir un redespliegue de todas las aplicaciones. Por supuesto, existen limitaciones a la observabilidad que puede proporcionar una malla de servicios, y también deberías instrumentar tus servicios utilizando métricas específicas del lenguaje y bibliotecas emisoras de registros. Por ejemplo, en nuestro caso de estudio, la malla de servicios proporcionaría métricas sobre el número, la latencia y la tasa de error de las llamadas a la API del servicio Sesión, y normalmente también decidirías registrar métricas específicas del negocio y KPI de las llamadas a la API.
Aplicar la Seguridad: Seguridad en el Transporte, Autenticacióny Autorización
En gran parte del mismo modo que la observabilidad, la seguridad de la comunicación de servicio a servicio se ha implementado históricamente utilizando bibliotecas específicas de cada lenguaje. Estos enfoques altamente acoplados presentan los mismos inconvenientes y matices. Por ejemplo, implementar el cifrado a nivel de transporte dentro de una red interna es un requisito relativamente común, pero las bibliotecas de los distintos lenguajes manejan la gestión de certificados de forma diferente, lo que aumentaba la carga operativa de desplegar y rotar certificados. Gestionar tanto la identidad del servicio (máquina) como la del usuario (humano) para la autenticación y autorización también era difícil en los distintos lenguajes. También era a menudo fácil eludir accidentalmente (o deliberadamente) cualquier implementación de seguridad al no incluir las bibliotecas necesarias.
Como el plano de datos de una malla de servicios está incluido dentro de la ruta de cualquier tráfico dentro del sistema, es relativamente trivial hacer cumplir el perfil de seguridad requerido. Por ejemplo, el plano de datos de la malla de servicios puede gestionar identidades de servicio (por ejemplo, utilizando SPIFFE) y certificados criptográficos, habilitando mTLS, y autenticación y autorización a nivel de servicio. Esto nos permite implementar fácilmente mTLS dentro de nuestro caso de estudio sin necesidad de modificar el código.
Apoyar la comunicación interfuncional entre idiomas
A medida que crea o extrae servicios dentro de una aplicación basada en microservicios y pasa de la comunicación dentro del proceso a la comunicación fuera del proceso, tienes que pensar en los cambios en el enrutamiento, la fiabilidad, la observabilidad y la seguridad. La funcionalidad necesaria para manejar esto puede implementarse dentro del código de la aplicación, por ejemplo, como una biblioteca. Sin embargo, si tu aplicación o sistema utiliza varios lenguajes de programación -y un enfoque políglota es bastante común en los sistemas basados en microservicios-, esto significa que tendrás que implementar cada biblioteca para cada lenguaje utilizado. Como una malla de servicios suele implementarse utilizando el patrón sidecar, en el que toda la comunicación entre servicios se enruta a través de un proxy de red externo al servicio pero que se ejecuta dentro del mismo espacio de nombres de red, la funcionalidad necesaria puede implementarse una vez dentro del proxy y reutilizarse en todos los servicios. Puedes pensar en esto como "inyección de dependencias de infraestructura" En nuestro estudio de caso, esto nos permitiría reescribir nuestro servicio de Asistente utilizando un lenguaje diferente (quizás para cumplir nuevos requisitos de rendimiento) y seguir confiando en que los aspectos interfuncionales de la comunicación entre servicios se gestionen de forma coherente.
Separar la gestión del tráfico de entrada y de servicio a servicio
Recuerda en "Caso práctico: Un paso evolutivo" que introdujimos brevemente los conceptos clave de tráfico norte-sur y este-oeste. En términos generales, el tráfico norte-sur es el que entra en tu sistema desde una ubicación externa. El tráfico este-oeste es el que transita internamente de sistema a sistema o de servicio a servicio. Las definiciones pueden complicarse cuando profundizas en la definición de "tus sistemas"; por ejemplo, ¿se extiende esta definición a los sistemas diseñados y operados sólo por tu equipo, tu departamento, tu organización o tus terceros de confianza, etc.?
Varios colaboradores del espacio API, entre ellos Marco Palladino de Kong, han argumentado que el uso de norte-sur y este-oeste es en gran medida irrelevante y es más bien un resabio de la generación anterior de redes informáticas, cuando los límites entre sistemas eran más claros. Exploraremos este argumento con más detalle en el Capítulo 9, ya que afecta a la idea de la API como producto (incluida la gestión del ciclo de vida de la API) y a la conectividad de servicios de capa 7 y capa 4 (del modelo OSI de redes.) Las diferencias entre las propiedades y características básicas del tráfico de entrada y de servicio a servicio se muestran en la Tabla 4-3.
| Entrada (n/s) | Servicio a servicio (e/w) | |
|---|---|---|
Fuente de tráfico |
Externo (usuario, terceros, internet) |
Interna (dentro de los límites de la confianza) |
Destino del tráfico |
API pública o orientada a empresas, o sitio web |
API de servicio o dominio |
Autenticación |
"usuario" (entidad del mundo real) centrado |
"servicio" (entidad máquina) y "usuario" (entidad del mundo real) centrados |
Autorización |
funciones de "usuario" o nivel de capacidad |
identidad de "servicio" o segmento de red centrado, y funciones de "usuario" o nivel de capacidad |
TLS |
Unidireccionales, a menudo obligatorias (por ejemplo, actualización del protocolo) |
Mutuo, puede hacerse obligatorio (mTLS estricto) |
Implementaciones primarias |
Pasarela API, proxy inverso |
Malla de servicios, bibliotecas de aplicaciones |
Propietario principal |
Pasarela/redes/equipo operativo |
Plataforma/cluster/equipo operativo |
Usuarios de la organización |
Arquitectos, gestores de API, desarrolladores |
Desarrolladores |
Como se ha ilustrado, las propiedades y los requisitos asociados para gestionar los dos tipos de tráfico suelen ser muy diferentes. Por ejemplo, la gestión del tráfico externo de usuario final destinado a una API de producto tiene requisitos fundamentalmente distintos en comparación con la gestión del tráfico interno de servicio a servicio destinado a una API interna de negocio, dominio o componente. En la práctica, esto significa que los planos de control tanto de una pasarela API como de una malla de servicio deben ofrecer capacidades distintas para soportar la configuración de los respectivos planos de datos. Como ejemplo en nuestro caso práctico, el equipo de desarrollo del servicio de Sesión puede querer especificar que el servicio sólo puede ser llamado por la aplicación de conferencia heredada y el servicio de Asistentes, mientras que el equipo del servicio de Asistentes no especificaría normalmente qué sistemas externos pueden o no llamar a la API pública: esto sería responsabilidad del equipo de la pasarela o de la malla de servicios asociada.
Esta diferencia entre la gestión de las llamadas API de entrada y de servicio a servicio puede entenderse mejor si comparas la evolución y el uso de la tecnología de pasarela API, tal y como se explora en "Una historia moderna de las pasarelas API", con la evolución de la tecnología de malla de servicio, tal y como se describe en la siguiente sección de .
Evolución del Servicio Malla
Aunque el término "malla de servicios" se acuñó en 2016, varias de las primeras organizaciones "unicornio" como Twitter, Netflix, Google y Amazon estaban creando y utilizando tecnologías relacionadas dentro de sus plataformas internas desde finales de la década de 2000 y principios de 2010. Por ejemplo, Twitter creó su marco Finagle RPC basado en Scala, que fue de código abierto en 2011. Netflix creó y publicó sus bibliotecas compartidas de microservicios basadas en Java "OSS" en 2012, incluyendo Ribbon, Eureka e Hystrix.4 Más tarde, el equipo de Netflix publicó el sidecar Prana para que los servicios no basados en JVM pudieran aprovechar estas bibliotecas. La creación de las bibliotecas Finagle y la adopción de sidecares acabaron dando lugar a Linkerd, posiblemente la primera malla de servicios basada en sidecares y también un proyecto inicial en la CNCF cuando se formó esta fundación. Google no tardó en seguir su ejemplo publicando la malla de servicios Istio, basada en el proyecto Envoy Proxy que había surgido del equipo de ingeniería de Lyft.
En un giro que parece que la industria cierra el círculo, las capacidades de la malla de servicios están volviendo a las bibliotecas compartidas, como estamos viendo con gRPC, o se están añadiendo al núcleo del SO. Esta evolución se puede ver en la Figura 4-5. Aunque el desarrollo y el uso de muchos de estos componentes y plataformas anteriores están ahora obsoletos, es útil hacer un rápido recorrido por su evolución, ya que pone de manifiesto varios retos y limitaciones del uso del patrón de malla de servicios, algunos de los cuales siguen existiendo.
Figura 4-5. Evolución de la tecnología de malla de servicios
Historia temprana y motivaciones
En los años 90, Peter Deutsch y otras personas de Sun Microsystems recopilaron "Las 8 falacias de la informática distribuida", en las que enumeraban los supuestos que los ingenieros tienden a hacer cuando trabajan con sistemas distribuidos. Señalaban que, aunque estos supuestos podían ser ciertos en arquitecturas de red más primitivas o en los modelos teóricos, no se cumplen en las redes modernas:
-
La red es fiable
-
La latencia es cero
-
El ancho de banda es infinito
-
La red es segura
-
La topología no cambia
-
Hay un administrador
-
El coste de transporte es cero
-
La red es homogénea
Peter y su equipo afirman que estas falacias "todas resultan ser falsas a largo plazo y todas causan grandes problemas y dolorosas experiencias de aprendizaje" Los ingenieros no pueden limitarse a ignorar estas cuestiones; tienen que abordarlas explícitamente.
Ignora las falacias de la informática distribuida ¡por tu cuenta y riesgo!
Dado que las "8 falacias de la informática distribuida" se acuñaron en los años 90, resulta tentador pensar que son una reliquia de la informática. Sin embargo, ¡sería un error! Al igual que muchas otras leyes y pautas informáticas atemporales derivadas de los años 70 y 80, los problemas siguen siendo los mismos, aunque la tecnología cambie. Cuando trabajes como arquitecto, debes recordar constantemente a tus equipos que muchos de los retos de red recogidos en estas falacias siguen siendo válidos hoy en día, ¡y debes diseñar los sistemas en consecuencia!
A medida que los sistemas distribuidos y las arquitecturas de microservicios se hicieron populares en la década de 2010, muchos innovadores del sector, como James Lewis, Sam Newman y Phil Calçado, se dieron cuenta de la importancia de construir sistemas que reconocieran y compensaran estas falacias por encima de la funcionalidad proporcionada en las pilas de redes estándar. Basándose en el conjunto inicial de "Requisitos previos de microservicios" de Martin Fowler, Phil creó los "Requisitos previos de microservicios de Calçado" e incluyó el "RPC estandarizado" como requisito previo clave que encapsulaba muchas de las lecciones prácticas que había aprendido de las falacias de la informática distribuida. En una entrada posterior de su blog de 2017, Phil afirmaba que "aunque la pila TCP/IP y el modelo general de redes desarrollados hace muchas décadas siguen siendo una herramienta poderosa para hacer que los ordenadores se comuniquen entre sí, las arquitecturas más sofisticadas [basadas en microservicios] introdujeron otra capa de requisitos que, una vez más, tienen que cumplir los ingenieros que trabajan en dichas arquitecturas."5
Patrones de aplicación
Aunque la implementación de mallas de servicios más extendida hoy en día utiliza el modelo de implementación "sidecar" basado en proxy, no siempre ha sido así, y puede que no lo sea en el futuro. En esta sección del capítulo aprenderás cómo han evolucionado hasta ahora los modelos de implementación de mallas de servicios y explorarás lo que puede deparar el futuro.
Bibliotecas
Aunque muchos líderes técnicos se dieron cuenta de la necesidad de una nueva capa de funcionalidad de red dentro de los sistemas basados en microservicios, comprendieron que implantar estas tecnologías no sería trivial. También reconocieron que se repetiría mucho esfuerzo, tanto dentro de las organizaciones como entre ellas. Esto condujo a la aparición de marcos de trabajo de red centrados en microservicios y bibliotecas compartidas que podían construirse una vez y reutilizarse, primero en toda una organización, y más tarde de código abierto paraun consumo más amplio.
En la entrada de su blog antes mencionada, Phil Calçado comentaba que incluso las funciones básicas de red, como el descubrimiento de servicios y la ruptura de circuitos, eran difíciles de implementar correctamente, lo que llevó a la creación de grandes y sofisticadas bibliotecas, como Finagle de Twitter y la pila OSS de Netflix, que se hicieron muy populares como medio para evitar reescribir la misma lógica en cada servicio y también como proyectos para centrar los esfuerzos compartidos en garantizar la corrección. Algunas organizaciones más pequeñas asumieron por sí mismas la carga de escribir las bibliotecas y herramientas de red necesarias, pero el coste solía ser elevado, sobre todo a largo plazo. A veces este coste era explícito y claramente visible -por ejemplo, el coste de los ingenieros asignados a equipos dedicados a crear herramientas-, pero más a menudo el gasto real era difícil de cuantificar plenamente, ya que se manifiesta como el tiempo que tardan los nuevos desarrolladores en aprender las soluciones propietarias, los recursos necesarios para el mantenimiento operativo u otras formas de restar tiempo y energía al trabajo en tus productos de cara al cliente.
Phil también observó que el uso de bibliotecas que exponen la funcionalidad a través de enlaces de lenguaje o un SDK limitaba las herramientas, tiempos de ejecución y lenguajes que puedes utilizar para tus microservicios. Las bibliotecas para microservicios suelen estar escritas para una plataforma específica, ya sea un lenguaje de programación o un tiempo de ejecución como la JVM. Si utilizas plataformas distintas de la soportada por la biblioteca, lo más probable es que tengas que portar el código a la nueva plataforma en sí, con lo que tus costes aumentarán en relación con el número de lenguajes.
Las Bibliotecas de Malla de Servicios y el Precio del Políglota
Muchas organizaciones adoptan un enfoque políglota para codificar aplicaciones y utilizan diversos lenguajes, eligiendo el más adecuado para un servicio con el fin de cumplir los requisitos. Por ejemplo, utilizar Java para servicios empresariales de larga duración, Go para servicios de infraestructura y Python para trabajos de ciencia de datos. Si adoptas el enfoque basado en bibliotecas para implementar una malla de servicios, tendrás que ser consciente de que tendrás que construir, mantener y actualizar todas tus bibliotecas al mismo tiempo para evitar problemas de compatibilidad o proporcionar una experiencia de desarrollador subóptima para algunos lenguajes. También puedes encontrar diferencias sutiles entre las implementaciones en las plataformas de lenguajes, o errores que sólo afectan a un tiempo de ejecución específico de.
Sidecares
En , a principios de la década de 2010, muchos ingenieros estaban adoptando el enfoque de la programación políglota, y no era raro que una sola organización tuviera servicios escritos en varios lenguajes que se desplegaran en producción. El deseo de escribir o mantener una biblioteca que gestionara todas las abstracciones de red necesarias llevó a la creación de bibliotecas que se ejecutaban externamente a un servicio como procesos independientes. Había nacido el "sidecar" de microservicios. En 2013, Airbnb escribió sobre "Synapse and Nerve", su implementación de código abierto de un sidecar de descubrimiento de servicios. Un año más tarde, Netflix introdujo Prana, un sidecar que exponía una interfaz HTTP para que las aplicaciones no JVM se integraran con el resto del ecosistema OSS de Netflix para el descubrimiento de servicios, la ruptura de circuitos, etc. El concepto central aquí era que un servicio no se conectaba directamente a sus dependencias descendentes, sino que todo el tráfico pasaba a través del sidecar Prana, que añadía de forma transparente la abstracción y las funciones de red deseadas.
A medida que aumentaba el uso del estilo de arquitectura de microservicios, vimos surgir una nueva oleada de proxies lo suficientemente flexibles como para adaptarse a diferentes componentes de infraestructura y requisitos de comunicación. El primer sistema ampliamente conocido en este espacio fue Linkerd, creado por Buoyant y basado en su experiencia de ingeniería de haber trabajado en la plataforma de microservicios de Twitter. Poco después, el equipo de ingeniería de Lyft anunció Envoy Proxy, que seguía un principio similar y fue adoptado rápidamente por Google en su malla de servicios Istio. Cuando utilices el patrón sidecar, cada uno de tus servicios tendrá un proceso proxy compañero que se ejecuta de forma autónoma junto a tu aplicación. Este sidecar suele compartir el mismo espacio de nombres de procesos, archivos y redes, y se proporcionan garantías de seguridad específicas (por ejemplo, que cualquier comunicación con la red "local" está aislada de la red externa). Dado que los servicios se comunican entre sí sólo a través del proxy sidecar, acabamos con una implementación similar al diagrama de la Figura 4-6.
Figura 4-6. Los proxies de malla de servicios forman una abstracción de red de nivel superior
Como han señalado personas como Phil Calçado y William Morgan, de Buoyant, el aspecto más poderoso de esta integración de proxies sidecar es que te aleja de pensar en los proxies como componentes aislados y te acerca al reconocimiento de la red que forman como algo valioso en sí mismo.
A mediados de la década de 2010, las organizaciones empezaron a trasladar sus implementaciones de microservicios a tiempos de ejecución más sofisticados, como Apache Mesos (con Marathon), Docker Swarm y Kubernetes, y empezaron a utilizar las herramientas que estas plataformas ponían a su disposición para implementar una malla de servicios, lo que llevó a dejar de utilizar un conjunto de proxies independientes que trabajaban de forma aislada, como vimos con Synapse y Nerve, y a utilizar un plano de control centralizado. Si observas este patrón de implementación desde arriba, verás que el tráfico de servicios sigue fluyendo directamente de proxy a proxy, pero el plano de control conoce cada instancia de proxy y puede influir en ella. El plano de control permite a los proxies implementar funciones como el control de acceso y la recopilación de métricas, que requieren cooperación y coordinación entre servicios, como se muestra en la Figura 4-7.
Figura 4-7. Control y coordinación del plano de datos de una malla de servicios
El enfoque basado en sidecares es el patrón más común en la actualidad y probablemente sea una buena elección para nuestro sistema de conferencias. Los costes principales de la implementación de una malla de servicios basada en sidecares están relacionados con la instalación inicial y el mantenimiento operativo continuo, así como con los recursos necesarios para ejecutar todos los sidecares: como nuestras necesidades deescalabilidad son modestas en la actualidad, no deberíamos necesitar grandes cantidades de potencia informática para ejecutar los proxies sidecares.
El coste de gestionar Sidecars a escala
Muchas de las soluciones de malla de servicios más populares hoy en día requieren que añadas y ejecutes un contenedor proxy sidecar, como Envoy, Linkerd-proxy o NGINX, en cada servicio o aplicación que se ejecute en tu clúster. Incluso en un entorno relativamente pequeño con, digamos, 20 servicios, cada uno ejecutando cinco pods repartidos en tres nodos, tendrás 100 contenedores proxy en ejecución. Por pequeña y eficiente que sea la implementación del proxy, la mera duplicación de los proxies repercutirá en los recursos.
Dependiendo de la configuración de la malla de servicios, la cantidad de memoria utilizada por cada proxy puede aumentar en relación con el número de servicios con los que necesita poder comunicarse.Pranay Singhal escribió sobre sus experiencias configurando Istio para reducir el consumo de alrededor de 1 GB por proxy a unos mucho más razonables 60-70 MB cada uno. Sin embargo, incluso en el pequeño entorno imaginario con 100 proxies en tres nodos, esta configuración optimizada sigue requiriendo aproximadamente 2 GB por nodo.
Bibliotecas gRPC sin proxilos
En una evolución de que parece que hemos cerrado el círculo, la Nube de Google empezó a promover el "gPRC sin proxy" a principios de 2021, en el que las abstracciones de red se trasladan de nuevo a una biblioteca específica del lenguaje (aunque una biblioteca mantenida por Google y una gran comunidad de OSS). Estas bibliotecas gRPC se incluyen dentro de cada servicio y actúan como el plano de datos dentro de la malla de servicios. Las bibliotecas requieren acceso a un plano de control externo para la coordinación, como el servicio Traffic Director de Google. Traffic Director utiliza "APIs xDS" de código abierto para configurar directamente las bibliotecas gRPC dentro de las aplicaciones.6 Estas aplicaciones gRPC actúan como clientes xDS, conectándose al plano de control global de Traffic Director que permite el enrutamiento global, el equilibrio de carga y la conmutación por error regional para casos de uso de malla de servicios y equilibrio de carga. Traffic Director admite incluso un modo de funcionamiento "híbrido", que incluye implementaciones que incorporan tanto servicios basados en proxy sidecar como servicios sin proxy, como se muestra en la Figura 4-8.
Figura 4-8. Ejemplo de diagrama de red de servicios que utilizan tanto sidecars como comunicación sin proximidad
Como nuestro sistema de conferencias utiliza las API REST además de las API gRPC, esto excluiría actualmente esta opción de implementación de una malla de servicios. Si nuestro uso de las API REST a nivel interno quedara obsoleto, o las bibliotecas gRPC se mejoraran para ofrecer soporte a la comunicación no basada en gRPC, podría reevaluarse el uso de este enfoque.
Sidecarless: Implementaciones del núcleo del sistema operativo (eBPF)
Otra alternativa emergente de implementación de la malla de servicios se basa en devolver las abstracciones de red necesarias al propio núcleo del sistema operativo (SO). Esto ha sido posible gracias al auge y la amplia adopción de eBPF, una tecnología de núcleo que permite ejecutar programas personalizados en un espacio aislado (sandbox) dentro del núcleo. Los programas eBPF se ejecutan en respuesta a eventos a nivel de SO, de los que hay miles a los que se pueden asociar. Estos eventos incluyen la entrada o salida de cualquier función en el espacio del núcleo o del usuario, o "puntos de rastreo" y "puntos de sondeo", y -lo que es importante para la malla de servicios- la llegada de paquetes de red. Como sólo hay un núcleo por nodo, todos los contenedores y procesos que se ejecutan en un nodo comparten el mismo núcleo. Si añades un programa eBPF a un evento en el núcleo, se activará independientemente del proceso que haya causado ese evento, tanto si se ejecuta en un contenedor de aplicaciones como directamente en el host. Esto debería eliminar cualquier posible intento de eludir la malla de servicios, accidentalmente o no.
El proyecto Cilium , basado en eBPF, proporciona capacidades para asegurar y observar la conectividad de red entre cargas de trabajo de contenedores. Cilium aporta este modelo "sin sidecar" al mundo de la malla de servicios. El uso de Cilium puede reducir la latencia entre llamadas de servicio, ya que algunas funcionalidades pueden ser proporcionadas por el núcleo sin necesidad de realizar un salto de red a un proxy sidecar.7 Además del modelo sidecar convencional, Cilium permite ejecutar un plano de datos de malla de servicios utilizando una única instancia de Proxy Envoy por nodo, lo que reduce el uso de recursos. La Figura 4-9 muestra cómo pueden comunicarse dos servicios utilizando Cilium y un único Envoy Proxy por nodo.
Figura 4-9. Uso de Cilium, eBPF y un único Envoy Proxy por nodo para implementar la funcionalidad de malla de servicios
Taxonomía de la malla de servicios
Enla Tabla 4-4 se destaca la diferencia entre los tres estilos de implementación de la malla de servicios, tal y como se ha comentado en el apartado anterior.
Caso práctico: Utilización de una Malla de Servicios para el Enrutamiento, la Observabilidad y la Seguridad
En esta sección del capítulo explorarás varios ejemplos concretos de cómo utilizar una malla de servicio para implementar los requisitos comunes de enrutamiento, observación y segmentación segura (mediante autorización) de tu tráfico de servicio a servicio. Todos estos ejemplos utilizarán Kubernetes, ya que es la plataforma más común en la que se implementan las mallas de servicio, pero los conceptos demostrados se aplican a todas las plataformas e infraestructuras para las que cada malla de servicio es compatible. Aunque recomendamos elegir y adoptar sólo una implementación de malla de servicios dentro de la pila tecnológica de tu aplicación, demostraremos la configuración del sistema de conferencias utilizando tres mallas de servicios diferentes, con fines puramente didácticos.
Enrutamiento con Istio
Istio puede instalarse en tu clúster de Kubernetes con la herramienta istioctl. El principal requisito previo para utilizar Istio es habilitar la inyección automática de los sidecars de proxy a todos los servicios que se estén ejecutando en tu clúster. Esto puede hacerse de la siguiente manera:
$ kubectl label namespace default istio-injection=enabled
Con la autoinyección configurada, los dos Recursos Personalizados principales con los que trabajarás son VirtualServices y DestinationRules.8 Un VirtualService define un conjunto de reglas de enrutamiento del tráfico que se aplican cuando se dirige a un host, por ejemplo, http://sessions. Un DestinationRule define las políticas que se aplican al tráfico destinado a un servicio después de que se haya producido el enrutamiento. Estas reglas especifican la configuración para el equilibrio de carga, el tamaño del grupo de conexiones del sidecar y la configuración de detección de valores atípicos para detectar y desalojar a los hosts no saludables del grupo de equilibrio de carga.
Por ejemplo, para habilitar el enrutamiento a tus servicios Sesión y Asistente dentro del caso práctico, puedes crear los siguientes VirtualServices:
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: sessions
spec:
hosts:
- sessions
http:
- route:
- destination:
host: sessions
subset: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: attendees
spec:
hosts:
- attendees
http:
- route:
- destination:
host: attendees
subset: v1
También se pueden crear las siguientes DestinationRules. Observa cómo la DestinationRule de los asistentes especifica dos versiones del servicio; ésta es la base para activar el enrutamiento canario para la nueva versión v2 del servicio:
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: sessions
spec:
host: sessions
subsets:
- name: v1
labels:
version: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: attendees
spec:
host: attendees
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
Con Istio instalado y los anteriores VirtualServices y DestinationRules configurados, puedes empezar a enrutar el tráfico y las llamadas a la API entre los servicios Attendee y Session. Empezar es así de fácil, aunque configurar y mantener Istio en un entorno de producción puede ser más complicado. Istio se encargará del enrutamiento y también generará telemetría relacionada con cada conexión. Aprendamos más sobre la observabilidad utilizando la malla de servicios Linkerd.
Observar el tráfico con Linkerd
Puedes instalar Linkerd en un clúster Kubernetes siguiendo las instrucciones de "Cómo empezar". Las funciones de telemetría y monitoreo de Linkerd se activan automáticamente, sin que tengas que hacer ningún cambio de configuración en la instalación por defecto. Estas funciones de observabilidad incluyen:
-
Registro de métricas de primera línea ("de oro") (volumen de solicitudes, tasa de éxito y distribuciones de latencia) para el tráfico HTTP, HTTP/2 y gRPC
-
Registro de métricas a nivel TCP (bytes de entrada/salida, etc.) para otro tráfico TCP
-
Informes de métricas por servicio, por par llamante/receptor, o por ruta/camino (con Perfiles de Servicio)
-
Generar gráficos de topología que muestren la relación entreservicios en tiempo de ejecución
-
Muestreo de solicitudes en directo y a la carta
Puedes consumir estos datos de varias formas:
-
A través de la CLI de Linkerd, por ejemplo, con linkerd viz stat y linkerd viz routes
-
A través del panel Linkerd y los paneles Grafana preconstruidos
-
Directamente desde la instancia Prometheus integrada en Linkerd
Para acceder a las funciones de observabilidad de Linkerd, sólo tienes que instalar la extensión viz y abrir el panel de control utilizando tu navegador local:
linkerd viz install | kubectl apply -f -linkerd viz dashboard
Esto proporciona acceso a gráficos de servicios que muestran el flujo de tráfico. En la Figura 4-10, puedes ver el tráfico que fluye a través de la malla desde la webapp a los servicios de libros y autores.
Figura 4-10. Uso de Linkerd viz para observar el flujo de tráfico entre servicios
También puedes ver las métricas de tráfico de primera línea utilizando los paneles Grafana preconstruidos, como se muestra en la Figura 4-11.
Figura 4-11. Visualización de los cuadros de mando de Linkerd viz Grafana
Utilizar una malla de servicios para proporcionar observabilidad a tus aplicaciones es útil tanto durante el desarrollo como en producción. Aunque siempre debes automatizar la detección del tráfico no válido de servicio a servicio en producción, también puedes utilizar esta herramienta de observabilidad de la malla de servicios para identificar cuándo se está llamando incorrectamente a las API internas o a los servicios. Exploremos ahora el uso de políticas para especificar exactamente qué servicios pueden comunicarse entre sí en la malla de servicios utilizando Consul de HashiCorp.
Segmentación de redes con Consul
Puedes instalar y configurar Consul como una malla de servicios dentro de un clúster de Kubernetes siguiendo la guía "Primeros pasos con Consul Service Mesh para Kubernetes". Antes de los microservicios, la autorización de la comunicación interservicios se aplicaba principalmente mediante reglas de cortafuegos y tablas de enrutamiento. Consul simplifica la gestión de la autorización interservicios con intenciones que te permiten definir permisos de comunicación de servicio a servicio por nombre de servicio.
Las intenciones controlan qué servicios pueden comunicarse entre sí y son aplicadas por el proxy sidecar en las conexiones entrantes. La identidad del servicio entrante se verifica mediante su certificado de cliente TLS, y Consul proporciona a cada servicio una identidad codificada como certificado TLS. Este certificado se utiliza para establecer y aceptarconexiones hacia y desde otros servicios.9 A continuación, el proxy sidecar comprueba si existe una intención que autorice al servicio entrante a comunicarse con el servicio de destino. Si el servicio entrante no está autorizado, la conexión finalizará.
Una intención tiene cuatro partes:
- Servicio de origen
-
Especifica el servicio que inicia la comunicación. Puede ser el nombre completo de un servicio o ser "*" para referirse a todos los servicios.
- Servicio de destino
-
Especifica el servicio que recibe la comunicación. Será el "ascendente" (servicio) que hayas configurado en tu definición de servicio. Puede ser el nombre completo de un servicio o también "*" para referirse a todos los servicios.
- Permiso
-
Define si se permite la comunicación entre el origen y el destino. Puede establecerse como permitir o denegar.
- Descripción
-
Campo de metadatos opcional para asociar una descripción a una intención.
La primera intención que crearás cambia la política "permitir todo", en la que se permite todo el tráfico a menos que se deniegue en reglas específicas, por una política "denegar todo", en la que se deniega todo el tráfico y sólo se permiten conexiones específicas:
apiVersion: consul.hashicorp.com/v1alpha1
kind: ServiceIntentions
metadata:
name: deny-all
spec:
destination:
name: '*'
sources:
- name: '*'
action: deny
Especificando el carácter comodín (*) en el campo de destino, esta intención impedirá toda comunicación de servicio a servicio. Una vez definida la política por defecto como denegar todo, puedes autorizar el tráfico entre el servicio heredado del sistema de conferencias, el servicio de Asistentes y el servicio de Sesión definiendo un CRD de ServiceIntentions para cada interacción de servicio requerida. Por ejemplo:
---
apiVersion: consul.hashicorp.com/v1alpha1
kind: ServiceIntentions
metadata:
name: legacy-app-to-attendee
spec:
destination:
name: attendee
sources:
- name: legacy-conf-app
action: allow
---
apiVersion: consul.hashicorp.com/v1alpha1
kind: ServiceIntentions
metadata:
name: legacy-app-to-sessions
spec:
destination:
name: sessions
sources:
- name: legacy-conf-app
action: allow
---
apiVersion: consul.hashicorp.com/v1alpha1
kind: ServiceIntentions
metadata:
name: attendee-to-sessions
spec:
destination:
name: sessions
sources:
- name: attendee
action: allow
---
apiVersion: consul.hashicorp.com/v1alpha1
kind: ServiceIntentions
metadata:
name: sessions-to-attendee
spec:
destination:
name: attendee
sources:
- name: sessions
action: allow
La aplicación de esta configuración al clúster de Kubernetes permitirá que estas interacciones -y sólo estas interacciones de servicio a servicio- se procesen como es debido. Se impedirá cualquier otra interacción, y se descartará la llamada o solicitud a la API.
Además de las intenciones de Consul, el proyecto Open Policy Agent (OPA) es una opción popular para implementar una funcionalidad similar dentro de una malla de servicios. Puedes encontrar un ejemplo de uso de OPA para configurar la política de servicio a servicio dentro de Istio en la "Documentación tutorial de OPA".
Ahora que has explorado la configuración de ejemplo que se aplicará a medida que evolucionemos el sistema de conferencias, vamos a centrar nuestra atención en la ejecución y gestión de la implementación de la malla de servicios propiamente dicha.
Implementación de una Malla de Servicios: Comprender ygestionar los fallos
Independientemente del patrón de implementación y del número de instancias que se ejecutan dentro de un sistema o red, una malla de servicios suele estar en la ruta crítica de muchas, si no todas, las solicitudes de los usuarios que se mueven por tu sistema. Una interrupción de una instancia de malla de servicios dentro de un clúster o red suele provocar la indisponibilidad de todo el sistema dentro del radio de explosión de esa red. Por esta razón, es de vital importancia aprender los temas de comprensión y gestión de fallos.
La Malla de Servicios como Punto Único de Fallo
Una malla de servicios se encuentra a menudo en la ruta caliente de todo el tráfico, lo que puede suponer un reto en relación con la fiabilidad y la conmutación por error. Obviamente, cuantas más funcionalidades dependan de la malla de servicios, mayor será el riesgo y el impacto de una interrupción. Como una malla de servicios se utiliza a menudo para orquestar el lanzamiento de servicios de aplicación, la configuración también se actualiza continuamente, por lo que es fundamental poder detectar y resolver los problemas y mitigar cualquier riesgo. Muchos de los puntos tratados en "La pasarela API como punto único de fallo" pueden aplicarse a la comprensión y gestión de los fallos de la malla de servicios.
Retos comunes de la implantación de la malla de servicios
Como las tecnologías de malla de servicios son más recientes en comparación con las tecnologías de pasarela API, algunos de los retos comunes de implementación aún están por descubrir y compartir ampliamente. Sin embargo, hay un conjunto básico de antipatrones que hay que evitar.
Malla de Servicios como ESB
Con la aparición en de plug-ins de mallas de servicios o filtros de tráfico, y de tecnologías de apoyo como Web Assembly (Wasm), resulta cada vez más tentador pensar que las mallas de servicios ofrecen funcionalidades similares a las de ESB, como la transformación y traducción de cargas útiles. Por todas las razones ya expuestas a lo largo de este libro, desaconsejamos firmemente añadir funcionalidades empresariales o acoplar demasiadas "inteligencias" a la plataforma o infraestructura.
Malla de servicios como pasarela
Como muchas implementaciones de malla de servicios de proporcionan algún tipo de pasarela de entrada, hemos visto organizaciones que querían adoptar una pasarela de API, pero en lugar de ello optaban por implementar una malla de servicios y utilizar sólo la funcionalidad de la pasarela. La motivación tiene sentido, ya que los ingenieros de la organización se dan cuenta de que pronto querrán adoptar una funcionalidad similar a la de la malla de servicios, pero su mayor punto débil es la gestión del tráfico de entrada. Sin embargo, la funcionalidad que ofrecen la mayoría de las pasarelas de malla de servicios no es tan rica en comparación con una pasarela API en toda regla. Además, lo más probable es que te enfrentes a los costes de instalación y funcionamiento de una malla de servicios sin obtener ninguna de sus ventajas.
Demasiadas capas de red
Hemos visto que algunas organizaciones proporcionan un rico conjunto de abstracciones y funciones de red que cumplirán los actuales requisitos de comunicación de servicio a servicio, pero los equipos de desarrollo o no lo saben o se niegan a adoptarlo por alguna razón. Cuando los equipos de desarrollo intentan implementar una malla de servicio sobre las tecnologías de red existentes, aparecen problemas adicionales, como incompatibilidades (por ejemplo, tecnologías de red existentes que eliminan cabeceras), aumento de la latencia (debido a los múltiples saltos de proxy), o funcionalidad que se implementa varias veces dentro de la pila de red (por ejemplo, rotura de circuitos que se produce tanto en la malla de servicio como en la pila de red de nivel inferior). Por este motivo, siempre recomendamos que todos los equipos implicados se coordinen y colaboren con las soluciones de malla de servicio .
Seleccionar una malla de servicios
Ahora que has aprendido la funcionalidad que proporciona una malla de servicios, la evolución del patrón y las tecnologías, y cómo encaja una malla de servicios en la arquitectura general del sistema, lo siguiente es una pregunta clave: ¿cómo seleccionas una malla de servicios para incluirla en la pila tecnológica de tu aplicación?
Identificar los requisitos
Como ya se ha comentado en relación con la selección de una pasarela API, uno de los pasos más importantes de cualquier proyecto de nueva infraestructura es identificar los requisitos relacionados. Esto puede parecer obvio, pero seguro que recuerdas alguna ocasión en la que te distrajiste con una tecnología brillante, un marketing mágico o una buena documentación de ventas.
Puedes volver a la sección anterior "¿Por qué utilizar una malla de servicios ?" de este capítulo para explorar con más detalle los requisitos de alto nivel que deberías tener en cuenta durante un proceso de selección de una malla de servicios. Es importante hacer preguntas que se centren tanto en los puntos conflictivos actuales como en tu hoja de ruta futura.
Construir frente a comprar
En comparación con la decisión de construir o comprar una pasarela API, es menos probable que las discusiones relacionadas con la malla de servicios se produzcan por adelantado, especialmente en las organizaciones que tienen sistemas heredados o heredados. Esto puede atribuirse en parte a que la malla de servicios es una categoría de tecnología relativamente nueva. Según nuestra experiencia, en la mayoría de los sistemas heredados que están algo distribuidos (p. ej, más que una pila LAMP), las implementaciones parciales de una malla de servicios estarán dispersas por toda la organización; por ejemplo, algunos departamentos utilizarán bibliotecas específicas del lenguaje, otros un ESB y otros simples pasarelas API o proxies sencillos para gestionar el tráfico interno.
En general, si has decidido adoptar el patrón de malla de servicios, creemos que suele ser mejor adoptar y estandarizar una implementación de código abierto o una solución comercial en lugar de construir la tuya propia. Presentar el caso de construir frente a comprar con la tecnología de entrega de software podría ocupar un libro entero, por lo que en esta sección sólo queremos destacar algunos retos comunes:
- Subestimar el coste total de propiedad (TCO)
-
Muchos ingenieros descuentan el coste de ingeniería de una solución, los costes de mantenimiento continuado y los costes operativos en curso.
- No pensar en el coste de oportunidad
-
A menos que seas un vendedor de nubes o plataformas, es muy poco probable que una malla de servicios personalizada te proporcione una ventaja competitiva. En cambio, puedes ofrecer más valor a tus clientes creando una funcionalidad alineada con tu propuesta de valor principal.
- Costes operativos
-
No comprender el coste de incorporación y operativo de mantener varias implantaciones diferentes que resuelven los mismos problemas.
- Conocimiento de las soluciones técnicas
-
Tanto el espacio de los componentes de las plataformas comerciales como el del código abierto se mueven con rapidez, y puede resultar difícil mantenerse al día. Sin embargo, estar al tanto e informado es una parte esencial de la función de ser un líder técnico.
Lista de control: Seleccionar una malla de servicios
La lista de comprobación de la Tabla 4-5 destaca las decisiones clave que tú y tu equipo debéis tener en cuenta al decidir si implantar el patrón de malla de servicios y al elegir las tecnologías relacionadas.
Resumen
En este capítulo has aprendido qué es una malla de servicios y has explorado qué funcionalidad, ventajas y retos proporciona adoptar este patrón y las tecnologías asociadas:
-
Fundamentalmente, la "malla de servicios" es un patrón para gestionar toda la comunicación de servicio a servicio dentro de un sistema de software distribuido.
-
A nivel de red, un proxy de malla de servicios actúa como un proxy completo, aceptando todo el tráfico entrante de otros servicios e iniciando también todas las peticiones salientes a otros servicios.
-
Una malla de servicios se despliega en una red interna o en un clúster. Los sistemas o redes grandes suelen gestionarse desplegando varias instancias de una malla de servicios, a menudo con cada una de ellas abarcando un segmento de red o un dominio empresarial.
-
Una malla de servicios puede exponer puntos finales dentro de una zona desmilitarizada de la red (DMZ), o a sistemas externos, o a redes o clusters adicionales, pero esto se implementa frecuentemente utilizando una pasarela de "entrada", "terminación" o "tránsito".
-
Hay muchas preocupaciones transversales relacionadas con las API que puedes tener para cada uno de tus servicios internos o para todos ellos, entre ellas: gestión del ciclo de vida del producto (publicación incremental de nuevas versiones de un servicio), fiabilidad, compatibilidad con la comunicación multilingüe, observabilidad, seguridad, mantenibilidad y extensibilidad. Una malla de servicios puede ayudar con todas ellas.
-
Una malla de servicios puede implementarse utilizando bibliotecas específicas del lenguaje, proxies sidecar, marcos de comunicación sin proxy (gRPC) o tecnologías basadas en el núcleo como eBPF.
-
El componente más vulnerable de una malla de servicios suele ser el plano de control, que debe estar protegido, monitorizado y funcionar como un servicio de alta disponibilidad.
-
Entre los antipatrones de uso de la malla de servicios están: la malla de servicios como ESB, la malla de servicios como pasarela y el uso de demasiadas capas de red.
-
Decidir implantar una malla de servicios y seleccionar la tecnología para hacerlo son decisiones de Tipo 1. Hay que investigar, analizar los requisitos y diseñar adecuadamente.
-
Si has decidido adoptar el patrón de malla de servicios, creemos que lo mejor suele ser adoptar y estandarizar una implementación de código abierto o una solución comercial, en lugar de construir la tuya propia.
Independientemente de tu decisión de adoptar una malla de servicios, es importante que tengas en cuenta tanto las operaciones externas e internas como la seguridad de tus API. Éste es el tema central de la siguiente sección de este libro.
1 El proyecto Linkerd surgió de la tecnología Finagle de Twitter, creada para proporcionar un marco de comunicación a los desarrolladores que construyen las aplicaciones distribuidas de Twitter. Linkerd ha evolucionado hasta convertirse en un proyecto graduado de la Cloud Native Computing Foundation (CNCF).
2 Puedes obtener más información sobre los conceptos de red de Kubernetes en los documentos oficiales: Service, NetworkPolicies y Container Networking Interface (CNI).
3 El SmartStack de Airbnb fue una de las primeras implementaciones del descubrimiento externo de servicios de microservicios.
4 Debes tener en cuenta que tanto el marco Finagle RPC como las bibliotecas Netflix OSS están ahora obsoletos y no se recomienda su uso en sistemas de producción modernos.
5 Puedes obtener más información en los siguientes sitios web: "Requisitos previos de los microservicios " de Fowler , "Requisitos previos de los microservicios de Calçado" y el blog de Phil "Patrón: Service Mesh".
6 Puedes obtener más información sobre Traffic Director y el protocolo xDS inspirado en Envoy Proxy a través de sus respectivos sitios web de documentación.
7 Aprende más sobre esto en "Cómo solucionará eBPF la Malla de Servicios-Adiós a los Sidecars".
8 Puedes obtener más información sobre VirtualServices y DestinationRules en la documentación de Istio.
9 La identidad se codifica en el certificado TLS conforme al Documento de Identidad X.509 de SPIFFE, que permite a los servicios Connect establecer y aceptar conexiones con otros sistemas conformes con SPIFFE.
Get Dominar la arquitectura API now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
