Service Mesh es un patrón arquitectónico bien conocido para integrar microservicios y pasar a la infraestructura de la nube. Hoy en el mundo de los contenedores en la nube es bastante difícil prescindir de él. Varias implementaciones de malla de servicios de código abierto ya están disponibles en el mercado, pero su funcionalidad, confiabilidad y seguridad distan de ser siempre suficientes, especialmente cuando se trata de los requisitos de las grandes compañías financieras de todo el país. Por lo tanto, en Sbertech decidimos personalizar Service Mesh y queremos hablar sobre lo que es genial en Service Mesh, qué no es muy bueno y qué vamos a hacer con él.
La popularidad de la plantilla de Service Mesh está creciendo con la popularidad de la tecnología en la nube. Es una capa de infraestructura dedicada que simplifica la interacción entre diferentes servicios de red. Las aplicaciones modernas en la nube consisten en cientos e incluso miles de dichos servicios, cada uno de los cuales puede tener miles de copias.
La interacción entre estos servicios y su gestión es una tarea clave de Service Mesh. De hecho, este es un modelo de red de muchos servidores proxy, gestionado de forma centralizada y que realiza un conjunto de funciones muy útiles.
En el nivel de proxy (plano de datos):- Asignar y distribuir políticas de enrutamiento y equilibrio de tráfico.
- Distribución de claves, certificados, tokens.
- Recolección de telemetría, formación de métricas de monitoreo.
- Integración con la infraestructura de seguridad y monitoreo.
En el nivel del plano de control:- Aplicar políticas de enrutamiento y equilibrio de tráfico
- Gestión de reintentos y tiempos de espera, definición de nodos "muertos" (interrupción de circuito), gestión de situaciones defectuosas (fallas de inyección) y mantenimiento de la resistencia de los servicios a través de otros mecanismos
- Autenticación de llamadas / Autorización
- Descartar métricas (observabilidad)
El círculo de usuarios interesados en desarrollar esta tecnología es muy amplio, desde pequeñas startups hasta grandes corporaciones de Internet, por ejemplo, PayPal.
¿Para qué sirve Service Mesh en el sector corporativo?
Usar Service Mesh trae muchos beneficios obvios. En primer lugar, es conveniente para los desarrolladores:
aparece una plataforma tecnológica para escribir código que simplifica significativamente la integración en la infraestructura de la nube debido al hecho de que la capa de transporte está completamente aislada de la lógica de la aplicación.
Además,
Service Mesh simplifica la relación entre proveedores y consumidores. Hoy en día, es mucho más fácil para los proveedores y consumidores de la API acordar interfaces y contratos por su cuenta, sin involucrar un intermediario de integración especial y un árbitro para esto: un bus de servicios corporativos. Este enfoque afecta significativamente dos indicadores. La velocidad de traer nuevas funcionalidades al mercado (tiempo de comercialización) está aumentando, pero al mismo tiempo el costo de la solución está aumentando, ya que la integración debe hacerse de forma independiente. El uso de Service Mesh por parte de los equipos de desarrollo empresarial ayuda a mantener el equilibrio aquí. 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 estará inmediatamente disponible para todos los clientes, y la calidad de integración estará lista para la producción y no requerirá una sola línea de código adicional.
Otra ventaja es que el
desarrollador, al usar el Service Mesh, se enfoca únicamente en la funcionalidad del negocio , en el producto y no en el componente tecnológico de su servicio. Por ejemplo, no tiene que pensar en el hecho de que en una situación en la que se llamará al servicio a través de la red, en algún lugar la conexión puede interrumpirse. Además, Service Mesh ayuda a equilibrar el tráfico entre copias del mismo servicio: si una de las copias "murió", el sistema cambiará todo el tráfico a las copias en vivo restantes.
Service Mesh es
una buena base para crear aplicaciones distribuidas , que oculta al cliente los detalles de proporcionar llamadas a sus servicios tanto interna como externamente. Todas las aplicaciones que usan Service Mesh están aisladas en la capa de transporte tanto de la red como entre sí: no hay conexión entre ellas. En este caso, el desarrollador obtiene el control total sobre sus servicios.
Cabe señalar que
actualizar las aplicaciones distribuidas en un entorno donde se utiliza Service Mesh es cada vez más fácil. Por ejemplo, implementación azul / verde, en la que hay dos entornos de aplicación disponibles para la instalación, uno de los cuales no está actualizado y está en modo de espera. La reversión a la versión anterior en caso de lanzamiento fallido se lleva a cabo mediante un enrutador especial, cuya función hace frente perfectamente a Service Mesh
. Puede usar la
versión canaria para ejecutar en la nueva versión: cambie solo el 10% del tráfico o las solicitudes del grupo de clientes piloto a la nueva versión. El tráfico principal va a la versión anterior, no se rompe nada.
Service Mesh también nos brinda control SLA en tiempo real . El sistema de proxies distribuidos no permitirá inundar el servicio cuando uno de los clientes exceda la cuota emitida. Si el ancho de banda de la API es limitado, nadie podrá estrangularlo con una gran cantidad de transacciones: la malla de servicio está al frente del servicio y no permite tráfico adicional. Simplemente se impondrá en la capa de integración, y los servicios en sí mismos continuarán funcionando sin darse cuenta.
Si la compañía quiere reducir el costo de desarrollar soluciones de integración, Service Mesh también ayuda:
puede cambiar a su versión de código abierto desde productos comerciales . Nuestra Enterprise Service Mesh se basa en la versión de código abierto de Service Mesh.
Otra ventaja es la
disponibilidad de un único conjunto completo de servicios de integración . Dado que toda la integración se construye a través de esta capa intermedia, podemos administrar todo el tráfico de integración y las conexiones entre las aplicaciones que forman el núcleo comercial de la empresa. Es muy conveniente.
Finalmente,
Service Mesh impulsa a la compañía a realizar la transición a una infraestructura dinámica. Ahora muchos están mirando hacia la contenedorización. Aserrar un monolito en microservicios, es hermoso implementarlo todo: el tema está en aumento. Pero cuando intenta transferir a una nueva pista un sistema que ha estado en producción durante muchos años, inmediatamente encuentra una serie de problemas: empujarlo todo en contenedores e implementarlo en la plataforma no es fácil. Y la implementación, sincronización e interacción de estos componentes distribuidos es otro tema difícil. ¿Cómo se comunicarán entre ellos? ¿Habrá fallas en cascada? Service Mesh le permite resolver algunos de estos problemas y facilitar la migración de la arquitectura antigua a la nueva debido al hecho de que puede olvidarse de la lógica del intercambio de red.
¿Por qué personalizar Service Mesh?
En nuestra empresa, coexisten cientos de sistemas y módulos, y el tiempo de ejecución está muy ocupado. Entonces, un patrón simple, cuando un sistema llama a otro y recibe una respuesta, no es suficiente, porque en producción queremos más. ¿Qué más necesitas de una malla de servicio corporativa?
Servicio de procesamiento de eventos
Imagine que necesitamos realizar un procesamiento de eventos en tiempo real, un sistema que analiza en tiempo real las acciones del cliente y puede hacer de él inmediatamente una oferta relevante. Para implementar esta funcionalidad,
se utiliza un
patrón arquitectónico llamado arquitectura controlada por eventos (EDA) . Ninguno de los Service Mesh relevantes admite de forma nativa tales patrones, pero esto es muy importante, ¡especialmente para el banco!
Es extraño que la llamada a procedimiento remoto (RPC) sea compatible con todas las versiones de Service Mesh, y no son amigos de EDA. Debido a que Service Mesh es una apariencia de integración distribuida moderna, y EDA es un patrón arquitectónico muy relevante que le permite hacer cosas únicas en términos de experiencia del cliente.
Nuestro Enterprise Service Mesh debería resolver este problema. Además, queremos ver en él la implementación de entrega garantizada, transmisión y procesamiento integrado de eventos utilizando una variedad de filtros y plantillas.
Servicio de transferencia de archivos
Además de EDA, sería bueno poder transferir archivos: en una escala Enterprise, a menudo solo es posible la integración de archivos. En particular, se utiliza el patrón arquitectónico ETL (Extraer, Transformar, Cargar - "extraer, transformar, cargar"). En él, como regla, todos intercambian archivos exclusivamente: usan big data, lo cual no es práctico para enviar solicitudes separadas. La capacidad de soportar de forma nativa las transferencias de archivos en Enterprise Service Mesh le brinda la flexibilidad que necesita para su negocio.
Servicio de orquestación
En las grandes organizaciones, casi siempre hay equipos diferentes que fabrican productos diferentes. Por ejemplo, en un banco, algunos equipos trabajan con depósitos, mientras que otros trabajan con productos de crédito, y hay muchos de estos casos. Estas son personas diferentes, diferentes equipos que fabrican sus productos, desarrollan sus API y se los proporcionan a otros. Y muy a menudo existe la necesidad de la composición de estos servicios, así como la implementación de la lógica compleja de la llamada secuencial del conjunto de API. Para resolver este problema, se necesita una solución en la capa de integración, que simplificará toda esta lógica compuesta (llamando a varias API, describiendo la ruta de las solicitudes, etc.). Este es el servicio de orquestación en Enterprise Service Mesh.
AI y ML
Cuando los microservicios se comunican a través de una sola capa de integración, Service Mesh, por supuesto, sabe todo acerca de las llamadas de cada servicio. Recopilamos telemetría: quién llamó a quién, cuándo, cuánto tiempo, cuántas veces, etc. Cuando hay cientos de miles de estos servicios y miles de millones de llamadas, todo esto se acumula y forma Big Data. Estos datos pueden analizarse usando IA, aprendizaje automático, etc., y luego hacer algunas cosas útiles en función de los resultados del análisis. Sería apropiado transferir al menos parcialmente a la inteligencia artificial la gestión de todo este tráfico de red y llamadas de aplicaciones integradas en la malla de servicio.
Servicio de puerta de enlace API
Como regla general, Service Mesh tiene servidores proxy y servicios que se acceden entre sí dentro del perímetro de confianza. Pero también hay contrapartes externas. Los requisitos de API para este grupo de consumidores son mucho más serios. Dividimos esta tarea en dos partes principales.
- Seguridad Problemas relacionados con ddos, vulnerabilidad de protocolos, aplicaciones, sistemas operativos, etc.
- La escala Cuando la factura de API que se debe entregar a los clientes llega a miles o incluso cientos de miles, existe la necesidad de algunos medios para administrar este conjunto de API. Debe monitorear constantemente la API: funcionan o no, en qué estado, qué tráfico está pasando, qué estadísticas, etc. La puerta de enlace API debe manejar esta tarea, haciendo que todo el proceso sea manejable y seguro. Gracias a este componente, Enterprise Service Mesh aprende a publicar las API internas y externas sin demasiada dificultad.
Servicio de soporte para protocolos y formatos de datos específicos (pasarela AS)
Actualmente, la mayoría de las soluciones de Service Mesh solo pueden funcionar de forma nativa con tráfico HTTP y HTTP2 o en modo truncado a nivel TCP / IP. Enterprise Service Mesh tiene muchos otros protocolos de transferencia de datos muy específicos. Algunos sistemas pueden usar corredores de mensajes; otros están integrados a nivel de base de datos. Si la empresa tiene SAP, también puede usar su propio sistema de integración. Y todo esto funciona y es una parte importante del negocio.
No puede simplemente decir: "Renunciemos al legado y creemos nuevos sistemas que puedan usar la malla de servicio". Para hacer amigos de todos los sistemas antiguos con los nuevos (en la arquitectura de microservicios), los sistemas que pueden usar Service Mesh necesitarán algún tipo de adaptador, intermediario y puerta de enlace. De acuerdo, sería bueno si se entregara en una caja junto con el servicio. La puerta de enlace AS puede admitir cualquier opción de integración. Imagínese, simplemente instala Enterprise Service Mesh y está listo para interactuar con todos los protocolos que necesita. Para nosotros, este enfoque es muy importante.
Así es como presentamos la versión corporativa de Service Mesh (Enterprise Service Mesh). La personalización descrita resuelve la mayoría de los problemas que surgen cuando se intenta utilizar versiones de código abierto ya preparadas de la plataforma de integración. Habiendo aparecido hace solo un par de años, la arquitectura de Service Mesh continúa evolucionando, y nos complace poder contribuir a su desarrollo. Esperamos que nuestra experiencia le sea de utilidad.