Service Mesh es un patrón arquitectónico bien conocido para la integración de microservicios y la transición a la infraestructura en la nube. Hoy en día, en el mundo de los contenedores en la nube, es bastante difícil prescindir de él. Ya hay varias implementaciones de código abierto de service mesh disponibles en el mercado, pero su funcionalidad, confiabilidad y seguridad no siempre son suficientes, especialmente cuando se trata de los requisitos de grandes empresas financieras a nivel nacional. Por eso, en Sbertech hemos decidido personalizar Service Mesh y queremos hablar sobre lo que es genial en Service Mesh, lo que no lo es tanto y lo que planeamos hacer al respecto.
La popularidad del patrón Service Mesh está en auge junto con la popularidad de las tecnologías en la nube. Se trata de una capa de infraestructura dedicada que simplifica la interacción entre varios servicios de red. Las aplicaciones modernas en la nube están compuestas por cientos e incluso miles de tales servicios, cada uno de los cuales puede tener miles de copias.
La interacción entre estos servicios y su gestión es la clave del Service Mesh. De hecho, se trata de un modelo de red compuesto por numerosos proxies, gestionado de forma centralizada y que ejecuta un conjunto de funciones muy útiles.
A nivel de proxy (data plane):
- Asignación y distribución de políticas de enrutamiento y balanceo de carga
- Distribución de claves, certificados, tokens
- Recolección de telemetría, generación de métricas de monitoreo
- Integración con la infraestructura de seguridad y monitoreo
A nivel del plano de control (control plane):
- Aplicación de políticas de enrutamiento y balanceo de carga
- Gestión de reintentos y tiempos de espera, identificación de nodos "muertos" (circuit breaking), gestión de situaciones de fallo (injecting faults) y mantenimiento de la resiliencia de los servicios a través de otros mecanismos
- Autenticación/autorización de llamadas
- Desechar métricas (observability)
El grupo de usuarios interesados en el desarrollo de esta tecnología es muy amplio, desde pequeñas startups hasta grandes corporaciones de Internet, como PayPal.
¿Para qué sirve Service Mesh en el sector empresarial?
El uso de Service Mesh aporta numerosas ventajas evidentes. Primero que nada, es muy conveniente para los desarrolladores: para la escritura de código aparece una plataforma tecnológica, que simplifica enormemente la integración en la infraestructura de la nube debido a que la capa de transporte está completamente aislada de la lógica de la aplicación.
Además, Service Mesh simplifica las relaciones entre proveedores y consumidores. Hoy en día, es mucho más fácil para proveedores y consumidores de API acordar interfaces y contratos por sí mismos, sin necesidad de un intermediario especial para la integración y un árbitro: el bus de servicios corporativo. Este enfoque influye significativamente en dos indicadores. Aumenta la rapidez del lanzamiento de nuevas funcionalidades al mercado (time-to-market), pero también incrementa el costo de la solución, ya que la integración debe hacerse de manera independiente. El uso de Service Mesh por equipos de desarrollo de funcionalidades comerciales permite equilibrar esta situación. Como resultado, los proveedores de API pueden centrarse exclusivamente en el componente de aplicación de su servicio y simplemente publicarlo en Service Mesh: la API se vuelve accesible inmediatamente para todos los clientes, y la calidad de la integración estará lista para producción y no requerirá ninguna línea de código adicional.
La siguiente ventaja es que el desarrollador, al usar Service Mesh, se enfoca exclusivamente en la funcionalidad comercial — en el aspecto del producto y no en el aspecto tecnológico de su servicio. Por ejemplo, ya no es necesario preocuparse de que, en una situación en la que se llame al servicio por la red, pueda haber una interrupción de la conexión. Además, Service Mesh ayuda a equilibrar el tráfico entre instancias de un mismo servicio: si una de las instancias 'ha fallado', el sistema redirigirá todo el tráfico a las instancias restantes que estén operativas.
Service Mesh — es una buena base para la creación de aplicaciones distribuidas, que oculta al cliente los detalles de la gestión de las llamadas a sus servicios tanto internas como externas. Todas las aplicaciones que utilizan Service Mesh están aisladas a nivel de transporte, tanto de la red como unas de otras: no hay comunicación entre ellas. Al mismo tiempo, el desarrollador tiene control total sobre sus servicios.
No se puede dejar de mencionar que la actualización de aplicaciones distribuidas en un entorno que utiliza Service Mesh se vuelve más sencilla. Por ejemplo, el despliegue blue/green, donde hay dos entornos de aplicación disponibles para la instalación, uno de los cuales no se actualiza y está en espera. La reversión a la versión anterior en caso de un lanzamiento fallido se realiza mediante un enrutador especial, que es perfectamente manejado por Service Mesh.. Para probar una nueva versión, también se puede utilizar el lanzamiento canario — dirigir solo el 10% del tráfico o las solicitudes de un grupo piloto de clientes a la nueva versión. El tráfico principal se gestiona a través de la versión antigua, sin que nada se rompa.
También Service Mesh nos brinda control del SLA en tiempo real. Un sistema de proxies distribuidos no permitirá colapsar el servicio cuando algún cliente exceda su cuota asignada. Si la capacidad de la API está limitada, nadie podrá hacer un ataque DDoS con una gran cantidad de transacciones: Service Mesh se sitúa frente al servicio y no permite tráfico innecesario. Simplemente se bloqueará en la capa de integración, mientras los propios servicios continúan operando sin darse cuenta.
Si una empresa desea reducir los costos de desarrollo de soluciones de integración, Service Mesh también se convierte en una gran ayuda: se puede migrar a su versión de código abierto desde productos comerciales. Nuestro Enterprise Service Mesh se basa en la versión de código abierto de Service Mesh.
Otra ventaja es la existencia de un conjunto completo de servicios de integración. Dado que toda la integración se construye a través de esta capa intermedia, podemos gestionar todo el tráfico de integración y las relaciones entre las aplicaciones que forman el núcleo empresarial de la compañía. Esto es muy conveniente.
Y por último Service Mesh impulsa a la empresa a adoptar una infraestructura dinámica. Actualmente, muchas personas están mirando hacia la contenedorización. Descomponer un monolito en microservicios y implementarlo de manera efectiva es un tema en auge. Sin embargo, cuando intentas adaptar un sistema que ha estado en producción durante muchos años a nuevas tecnologías, te enfrentas de inmediato a una serie de problemas: meter todo esto en contenedores y desplegarlo en una plataforma no es sencillo. Además, la implementación, la sincronización y la interacción de estos componentes distribuidos es otro tema complicado. ¿Cómo van a comunicarse entre sí? ¿Habrá fallos en cascada? Service Mesh puede abordar algunas de estas cuestiones y facilitar la migración de una arquitectura antigua a una nueva al permitir que te olvides de la lógica del intercambio de red.
¿Por qué es necesaria la personalización de Service Mesh?
En nuestra empresa coexisten cientos de sistemas y módulos, y el entorno en tiempo de ejecución está muy cargado. Por lo tanto, un simple patrón donde un sistema llama a otro y obtiene una respuesta no es suficiente, porque en producción queremos más. ¿Qué más se necesita de un Service Mesh empresarial?
Servicio de procesamiento de eventos
Imaginemos que necesitamos realizar un procesamiento de eventos en tiempo real — un sistema que analiza las acciones del cliente en tiempo real y puede hacerle una oferta relevante de inmediato. Para implementar esta funcionalidad, se utiliza un patrón arquitectónico llamado arquitectura impulsada por eventos (EDA). Ninguno de los Service Mesh actuales soporta nativamente tales patrones, lo cual es muy importante, ¡especialmente para un banco!
Es bastante extraño que todos los versiones de Service Mesh soporten el 'llamado remoto' Remote Procedure Call (RPC), pero no son compatibles con EDA. Porque Service Mesh es una forma de integración distribuida moderna, mientras que EDA es un patrón arquitectónico muy actual que permite hacer cosas únicas en términos de experiencia del cliente.
Nuestro Enterprise Service Mesh debe resolver este problema. Además, queremos ver en él la implementación de la entrega garantizada, el procesamiento de eventos en flujo y en lotes utilizando diversos filtros y plantillas.
Servicio de transferencia de archivos
Además de EDA, sería útil tener la capacidad de transferir archivos: en el ámbito empresarial, la integración de archivos es a menudo la única opción. En particular, se utiliza el patrón arquitectónico ETL (Extract, Transform, Load - «extracción, transformación, carga»). En este modelo, generalmente, todo se intercambia exclusivamente a través de archivos: se utilizan grandes volúmenes de datos que no es práctico enviar mediante solicitudes individuales. La capacidad de soporte nativo para la transferencia de archivos en un Enterprise Service Mesh proporciona la flexibilidad necesaria para el negocio.
Servicio de orquestación
En las grandes organizaciones, casi siempre hay diferentes equipos que desarrollan diferentes productos. Por ejemplo, en un banco, algunos equipos trabajan con depósitos, mientras que otros lo hacen con productos de crédito, y hay muchos casos de este tipo. Son diferentes personas, diferentes equipos que crean sus productos, desarrollan sus API y las ofrecen a otros. Y a menudo surge la necesidad de componer estos servicios, así como de implementar una lógica compleja de llamada secuencial de un conjunto de API. Para abordar este problema, se necesita una solución en la capa de integración que simplifique toda esta lógica compuesta (llamadas a múltiples API, descripción de rutas de solicitudes, etc.). Esto es lo que hace el servicio de orquestación en el Enterprise Service Mesh.
IA y ML
Cuando los microservicios se comunican a través de una única capa de integración, el Service Mesh naturalmente conoce todas las llamadas de cada servicio. Recopilamos telemetría: quién llamó a quién, cuándo, cuánto tiempo duró, cuántas veces, etc. Cuando hay cientos de miles de estos servicios y miles de millones de llamadas, toda esta información se acumula y forma Big Data. Estos datos pueden ser analizados con inteligencia artificial, machine learning, etc., y luego con base en los resultados del análisis se pueden hacer cosas útiles. Sería apropiado, al menos en parte, ceder el control de todo este tráfico de red y las llamadas de aplicaciones integradas en el Service Mesh a la inteligencia artificial.
Servicio API Gateway (Puerta de enlace API)
Por lo general, en el Service Mesh hay proxies y servicios que se comunican entre sí dentro de un perímetro de confianza. Pero también existen contrapartes externas. Los requisitos para las API proporcionadas a este grupo de consumidores son mucho más exigentes. Dividimos esta tarea en dos partes principales.
- Seguridad. Cuestiones relacionadas con DDoS, vulnerabilidad de protocolos, aplicaciones, sistemas operativos, etc.
- Escalas. Cuando el número de cuentas de API que deben entregarse a los clientes asciende a miles o incluso cientos de miles, surge la necesidad de un medio para gestionar este conjunto de APIs. Es fundamental monitorizar constantemente las APIs: si están funcionando o no, en qué estado se encuentran, qué tráfico reciben, qué estadísticas hay, etc. El gateway de API debe encargarse de esta tarea, haciendo que todo el proceso sea manejable y seguro. Gracias a este componente, el Enterprise Service Mesh aprende a publicar tanto APIs internas como externas sin complicaciones innecesarias.
Servicio de soporte a protocolos específicos y formatos de datos (gateway AS)
En la actualidad, la mayoría de las soluciones de Service Mesh pueden trabajar de manera nativa solo con tráfico HTTP y HTTP2, o en un modo limitado a nivel TCP/IP. El Enterprise Service Mesh cuenta con muchos otros protocolos de transmisión de datos bastante específicos. Algunos sistemas pueden utilizar brokers de mensajes, otros están integrados a nivel de bases de datos. Si la empresa cuenta con SAP, este también puede utilizar su propio sistema de integración. Y todo esto funciona y es una parte importante del negocio.
No se puede simplemente decir: "Abandonemos el legado y hagamos nuevos sistemas que puedan utilizar Service Mesh". Para integrar todos los sistemas antiguos con los nuevos (en arquitectura de microservicios), los sistemas que pueden utilizar Service Mesh necesitarán un adaptador, intermediario, o gateway. Sería ideal que este viniera en la caja junto con el servicio. El gateway AS puede respaldar cualquier tipo de integración. Imaginen, simplemente instalan el Enterprise Service Mesh y ya está preparado para interactuar con todos los protocolos que necesitan. Para nosotros, este enfoque es fundamental.
Así es como imaginamos la versión empresarial de Service Mesh (Enterprise Service Mesh). La personalización aquí descrita resuelve la mayoría de los problemas que surgen al intentar utilizar versiones open-source listas de plataformas de integración. Aparecida hace apenas un par de años, la arquitectura de Service Mesh sigue evolucionando, y estamos contentos de poder contribuir a su desarrollo. Esperamos que nuestra experiencia les sea útil.
Fuente: habr.com
