Service Mesh es un patrón arquitectónico bien conocido para integrar microservicios y migrar a la infraestructura de la nube. Hoy en día, en el mundo de los contenedores en la nube, es bastante difícil prescindir de ellos. Ya están disponibles en el mercado varias implementaciones de mallas de servicios de código abierto, pero su funcionalidad, confiabilidad y seguridad no siempre son suficientes, especialmente cuando se trata de los requisitos de las grandes empresas financieras de todo el país. Es por eso que en Sbertech decidimos personalizar Service Mesh y queremos hablar sobre lo bueno de Service Mesh, lo que no es tan bueno y qué vamos a hacer al respecto.
La popularidad del patrón Service Mesh está creciendo con la popularidad de las tecnologías 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 constan de cientos o incluso miles de servicios de este tipo, cada uno de los cuales puede tener miles de copias.
La interacción y la gestión de estos servicios es una tarea clave de Service Mesh. De hecho, este es un modelo de red de muchos proxies, administrado 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.
- Recopilación de telemetría, generación de métricas de seguimiento.
- Integración con infraestructura de seguridad y monitoreo.
A nivel del plano de control:
- Aplicar políticas de enrutamiento y equilibrio de tráfico
- Gestionar reintentos y tiempos de espera, detectar nodos "muertos" (ruptura de circuito), gestionar la inyección de fallos y garantizar la resiliencia del servicio a través de otros mecanismos.
- Autenticación/autorización de llamadas
- Dejar caer métricas (observabilidad)
El espectro de usuarios interesados en el desarrollo de esta tecnología es muy amplio: desde pequeñas empresas emergentes hasta grandes corporaciones de Internet, por ejemplo PayPal.
¿Por qué se necesita Service Mesh en el sector corporativo?
Hay muchos beneficios claros al utilizar Service Mesh. En primer lugar, es simplemente conveniente para los desarrolladores: para escribir código aparece una plataforma tecnológica, lo 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 API acordar interfaces y contratos por su cuenta, sin involucrar a un intermediario y árbitro de integración especial: el bus de servicios empresariales. Este enfoque afecta significativamente a dos indicadores. La velocidad de llevar nueva funcionalidad al mercado (time-to-market) aumenta, pero al mismo tiempo aumenta el coste de la solución, ya que la integración debe realizarse de forma independiente. El uso de Service Mesh por parte de los equipos de desarrollo de funcionalidades empresariales ayuda a mantener el equilibrio en este sentido. 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 la integración estará lista para producción y no requerirá un solo línea de código adicional.
La siguiente ventaja es que el desarrollador, que utiliza Service Mesh, se centra únicamente en la funcionalidad empresarial — en el producto más que en el componente tecnológico de su servicio. Por ejemplo, ya no tiene que pensar en el hecho de que en una situación en la que se llama a un servicio a través de la red, puede ocurrir una falla en la conexión en algún lugar. Además, Service Mesh ayuda a equilibrar el tráfico entre copias del mismo servicio: si una de las copias "muere", el sistema cambiará todo el tráfico a las copias activas restantes.
Malla de servicio - esta es una buena base para crear aplicaciones distribuidas, que oculta al cliente los detalles de la prestación de llamadas a sus servicios tanto interna como externamente. Todas las aplicaciones que utilizan Service Mesh están aisladas a nivel de transporte tanto de la red como entre sí: no hay comunicación entre ellas. En este caso, el desarrollador recibe control total sobre sus servicios.
se debe notar que Actualizar aplicaciones distribuidas en un entorno de malla de servicios se vuelve más fácil. Por ejemplo, una implementación azul/verde, en la que hay dos entornos de aplicaciones disponibles para su 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 un lanzamiento fallido se realiza mediante un enrutador especial, cuya función cumple bien Service Mesh.. Para probar la nueva versión, puede utilizar liberación canaria — cambiar a la nueva versión sólo el 10% del tráfico o solicitudes de un grupo piloto de clientes. El tráfico principal va a la versión anterior, nada se rompe.
también Service Mesh nos brinda control SLA en tiempo real. El sistema de proxy distribuido no permitirá que el servicio falle cuando uno de los clientes supere la cuota que le ha sido asignada. Si el rendimiento de la API es limitado, nadie podrá abrumarla con una gran cantidad de transacciones: Service Mesh se sitúa delante del servicio y no permite tráfico innecesario. Simplemente contraatacará en la capa de integración y los propios servicios seguirán funcionando sin darse cuenta.
Si una empresa quiere reducir costes para el desarrollo de soluciones de integración, Service Mesh también ayuda a: Puede cambiar 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 - disponibilidad de un único conjunto completo de servicios de integración. Debido a que toda la integración se construye a través de este middleware, podemos gestionar todo el tráfico de integración y las conexiones entre las aplicaciones que forman el núcleo comercial de la empresa. Es muy cómodo.
Y finalmente Service Mesh anima a una empresa a pasar a una infraestructura dinámica. Ahora muchos están mirando hacia la contenedorización. Cortar un monolito en microservicios e implementar todo esto de manera hermosa: el tema va en aumento. Pero cuando intentas transferir un sistema que ha estado en producción durante muchos años a una nueva plataforma, inmediatamente te encuentras con una serie de problemas: meterlo 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 muy complejo. ¿Cómo se comunicarán entre sí? ¿Habrá fallos en cascada? Service Mesh le permite resolver algunos de estos problemas y facilitar la migración de la arquitectura antigua a la nueva debido a que puede olvidarse de la lógica de intercambio de red.
¿Por qué necesita la personalización de Service Mesh?
En nuestra empresa conviven cientos de sistemas y módulos y el tiempo de ejecución está muy cargado. Entonces, un patrón simple en el que un sistema llama a otro y recibe una respuesta no es suficiente, porque en producción queremos más. ¿Qué más necesita de una red de servicios empresariales?
Servicio de procesamiento de eventos
Imaginemos que necesitamos crear un procesamiento de eventos en tiempo real: un sistema que analice las acciones del cliente en tiempo real y pueda hacerle inmediatamente una oferta relevante. Para implementar una funcionalidad similar, utilice patrón arquitectónico llamado arquitectura basada en eventos (EDA). Ninguna de las Service Meshes actuales admite de forma nativa tales patrones, pero esto es muy importante, ¡especialmente para un banco!
Es bastante extraño que la llamada a procedimiento remoto (RPC) sea compatible con todas las versiones de Service Mesh, pero no son compatibles con EDA. Porque Service Mesh es un tipo 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.
Nuestra Enterprise Service Mesh debería resolver este problema. Además, queremos ver en él la implementación de entrega garantizada, transmisión y procesamiento de eventos complejos utilizando una variedad de filtros y plantillas.
Servicio de transferencia de archivos
Además de EDA, sería bueno poder transferir archivos: a escala empresarial, muy a menudo sólo es posible la integración de archivos. En particular, se utiliza el patrón arquitectónico ETL (Extract, Transform, Load). En él, por regla general, todos intercambian archivos exclusivamente: se utilizan big data, por lo que no es práctico enviar solicitudes separadas. La capacidad de admitir de forma nativa transferencias de archivos en Enterprise Service Mesh le brinda la flexibilidad que su negocio necesita.
Servicio de orquestación
Las grandes organizaciones casi siempre tienen diferentes equipos que fabrican diferentes productos. Por ejemplo, en un banco, algunos equipos trabajan con depósitos, mientras que otros trabajan con productos crediticios, y hay bastantes casos de este tipo. Se trata de personas diferentes, equipos diferentes que fabrican sus productos, desarrollan sus API y se las proporcionan a otros. Y muy a menudo existe la necesidad de componer estos servicios, así como implementar una lógica compleja para llamar secuencialmente a un conjunto de API. Para resolver este problema, necesita una solución en la capa de integración que simplifique toda esta lógica compuesta (llamar a varias API, describir la ruta de solicitud, etc.). Este es el servicio de orquestación en Enterprise Service Mesh.
IA y aprendizaje automático
Cuando los microservicios se comunican a través de una única capa de integración, Service Mesh naturalmente sabe todo sobre las llamadas de cada servicio. Recopilamos telemetría: quién llamó a quién, cuándo, durante 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 se pueden analizar mediante inteligencia artificial, aprendizaje automático, etc., y luego se pueden hacer algunas cosas útiles en función de los resultados del análisis. Sería apropiado ceder, al menos parcialmente, el control de todo este tráfico de red y llamadas de aplicaciones integradas en Service Mesh a la inteligencia artificial.
Servicio de puerta de enlace API
Normalmente, una Service Mesh tiene servidores proxy y servicios que se comunican entre sí dentro de un perímetro confiable. Pero también existen contrapartes externas. Los requisitos para las API expuestas a este grupo de consumidores son mucho más estrictos. Dividimos esta tarea en dos partes principales.
- seguridad. Cuestiones relacionadas con ddos, vulnerabilidad de protocolos, aplicaciones, sistemas operativos, etc.
- La escala. Cuando la cantidad de API que deben entregarse a los clientes llega a miles o incluso cientos de miles, se necesita algún tipo de herramienta de administración para este conjunto de API. Es necesario monitorear constantemente las API: si están funcionando o no, cuál es su estado, qué tráfico fluye, qué estadísticas, etc. Una puerta de enlace API debería encargarse de esta tarea y al mismo tiempo hacer que todo el proceso sea manejable y seguro. Gracias a este componente, Enterprise Service Mesh aprende a publicar fácilmente API tanto internas como externas.
Servicio de soporte para protocolos y formatos de datos específicos (AS gateway)
Actualmente, la mayoría de las soluciones Service Mesh pueden funcionar de forma nativa sólo con tráfico HTTP y HTTP2 o en modo reducido a nivel TCP/IP. Enterprise Service Mesh está surgiendo con muchos otros protocolos de transferencia de datos muy específicos. Algunos sistemas pueden utilizar intermediarios de mensajes, otros están integrados a nivel de base de datos. Si la empresa tiene SAP, también puede utilizar su propio sistema de integración. Además, todo esto funciona y es una parte importante del negocio.
No se puede simplemente decir: "Abandonemos el legado y creemos nuevos sistemas que puedan usar Service Mesh". Para conectar todos los sistemas antiguos con los nuevos (en una arquitectura de microservicio), los sistemas que pueden usar Service Mesh necesitarán algún tipo de adaptador, intermediario o puerta de enlace. De acuerdo, sería bueno que viniera en una caja junto con el servicio. La puerta de enlace de CA 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. Este enfoque es muy importante para nosotros.
Así es más o menos como imaginamos la versión corporativa de Service Mesh (Enterprise Service Mesh). La personalización descrita resuelve la mayoría de los problemas que surgen al intentar utilizar versiones listas para usar de código abierto de la plataforma de integración. Introducida hace apenas un par de años, la arquitectura Service Mesh continúa evolucionando y estamos entusiasmados de poder contribuir a su desarrollo. Esperamos que nuestra experiencia te sea de utilidad.
Fuente: habr.com