Header Ads Widget

Ticker

6/recent/ticker-posts

API asincrónicas en microservicios coreografiados

 

microservicios coreografiados-asincrónicos

Al crear microservicios , primero debe tomar una decisión: ¿Cómo voy a administrar la comunicación de servicio a servicio? La mayoría de los desarrolladores responderán de inmediato: llamadas a la API. Pero luego, me vienen a la mente más preguntas:

  • ¿Voy a llamar a servicios directamente?
  • ¿No bloquea el servicio de llamadas?
  • ¿No introduce una dependencia entre ambos servicios?
  • ¿Qué pasa si el servicio llamado no funciona?
  • ¿Qué sucede si tengo varias instancias del servicio llamado y quiero equilibrar la carga de trabajo?

Con suerte, se hará estas preguntas antes de implementar su arquitectura de microservicios, ya que estos son problemas que deben resolverse. Pero, ¿se ha dado cuenta alguna vez de que la causa fundamental de todos estos problemas es solo una? Estamos tratando de hacer cosas asincrónicas sobre un protocolo sincrónico.

Preguntémonos de nuevo: ¿Cómo voy a gestionar la comunicación de servicio a servicio? Déjame responder esta vez: llamadas API asíncronas .

API asincrónicas

No se confunda con las llamadas API sin bloqueo. En el paradigma de las API asincrónicas no hay cliente ni servidor. Todo es de servidor a servidor o de servicio a servicio si lo prefiere, y cualquier servicio en cualquier momento podría ser el iniciador de la comunicación.

Ya lo has estado haciendo durante algunos años: WebHooks.

WebHooks

¿Por qué se inventaron los WebHooks ? Si lo piensa, son solo otra forma de usar las API HTTP. Vinieron a resolver el problema básico de la asincronicidad: "Otro servicio puede tener algo que decirme, pero no sé cuándo, así que no puedo estar preguntando para siempre".

El problema con WebHooks es que hacen llamadas directas, introduciendo una dependencia entre ambos servicios y dificultando que cada servicio administre fallas en caso de que el servicio llamado no funcione. Los WebHooks son esencialmente una solución alternativa a un protocolo sincrónico ampliamente utilizado. Los WebHooks son útiles, pero son exagerados y en gran medida innecesarios cuando se trata de la comunicación interna de servicio a servicio.

Luego intentas encontrar algo mejor. No puede bloquear su servicio, pero debe permitirle tener una comunicación bidireccional lista para usar. ¿Qué pasa con WebSockets?

WebSockets

Admitelo. Te sentiste libre la primera vez que usaste WebSockets . Son realmente fáciles de usar y tiene un canal bidireccional permanente para comunicarse entre sistemas. Sin embargo, nada es perfecto y pronto te diste cuenta de que tienes que definir cómo se hará el intercambio de mensajes. Sintaxis y estructura de mensajes, nombres de canales, etc .; todo lo que ya había definido mediante el uso de API REST se pierde. No existe una metodología estándar para orientar sobre este tipo de trabajo. Además de eso, lo que decida, debe escalar, ser adaptable a cambios futuros y debe ser interoperable.

Si ha utilizado WebSockets en producción, probablemente uno de los primeros problemas que enfrentó fue "demasiadas conexiones abiertas". Sí, estás atacando tu sistema con DDOS. Necesita una forma de decidir cuándo debe cerrarse una conexión o permanecerá allí para siempre.

Los WebSockets son una buena opción porque utilizan una solicitud de actualización HTTP para el protocolo de enlace, por lo que la mayoría de los servidores HTTP lo entenderán. Esto aumenta la interoperabilidad.

Sin embargo, lo que preocupa es cómo los usamos. Lo bueno es que ya no estamos bloqueando y cualquier servicio puede iniciar la comunicación, pero, ¿te vas a conectar directamente al servicio? ¿No está introduciendo una dependencia? ¿Qué pasa si el servicio no funciona? ¿Qué sucede si desea distribuir la carga de trabajo? Aún tienes que solucionar estos problemas.

Dejar que los servicios se comuniquen directamente hace que su infraestructura esté estrechamente acoplada, así que intentemos evitarlo implementando una arquitectura de microservicios coreografiada.

Únase a nosotros para la Cumbre de la Plataforma 2016

Para charlas sobre API asincrónicas y más, ¡asista a la Cumbre de la plataforma!

Microservicios coreografiados

En una arquitectura de microservicios coreografiada , cada servicio es independiente. Al igual que los bailarines que realizan una coreografía, no necesitan hablar entre ellos, sino que escuchan lo mismo: la música. Todos están de acuerdo en seguir el mismo ritmo, tiempos y tempo. Saben qué hacer y cuándo hacerlo, incluso si no realizan los mismos movimientos. El resultado es una actuación de baile perfecta.

Entonces, ¿qué necesitas para poner en marcha tu actuación de baile con microservicios ?

  • Los servicios - los bailarines
  • El corredor de mensajes - la música
  • Los mensajes - las notas
  • Los temas o canales - el sistema de sonido

La pieza más importante en una arquitectura de microservicios coreografiada es el intermediario de mensajes . Los servicios no se comunican entre sí, sino que simplemente se conectan al corredor de mensajes y publican / se suscriben a ciertos temas o canales.

Con esta arquitectura resuelves un problema anterior. Ahora, la dependencia se elimina parcialmente porque los servicios no se comunican entre sí directamente. Sin embargo, todavía tenemos que resolver por completo otro problema: distribuir la carga de trabajo en varias instancias del mismo servicio.

El corredor de mensajes

La forma más simple de un intermediario de mensajes es un sistema que enruta mensajes entre servicios. Por suerte hoy en día podemos encontrar brokers de mensajes con muchas más funcionalidades: RabbitMQ , Apache Kafka , NATS , etc.

Una de las funciones más útiles son las colas de mensajes . Siempre que se conecta al agente de mensajes, en realidad se está conectando a una cola de mensajes. Entonces, si un servicio envía un mensaje a otro y el último está inactivo, el mensaje se pondrá en cola y estará disponible una vez que el servicio vuelva a estar activo. Eso resuelve el problema de tener que lidiar con fallas en el servicio.

Otra característica interesante son los intercambios . Los intercambios actúan como pequeños agentes de mensajes dentro del agente de mensajes. Entonces, por ejemplo, un intercambio puede tener muchas colas conectadas y, dependiendo de su tipo, puede poner el mensaje en cola en el menos ocupado. Esto nos permite resolver nuestro problema sobre la distribución de la carga de trabajo en varias instancias del mismo servicio.

Observe cómo hemos evitado el uso de las siguientes palabras: "solicitud", "respuesta", "evento" y "acción". El corredor de mensajes se ocupa precisamente de eso; mensajes.

Los mensajes

Los mensajes son solo una información y no tienen un significado implícito. Un mensaje puede contener cualquier cosa en cualquier formato. Por lo general, tienen encabezados y un cuerpo o carga útil, sin embargo, cambiará según el protocolo que elija.

Lo que ponga en un mensaje puede tener un gran impacto en su arquitectura. Antes dijimos que usar un corredor elimina parcialmente la dependencia entre servicios. Es cierto que la dependencia se ha eliminado a nivel de infraestructura, sin embargo, puede que no sea cierto a nivel de lógica de programa.

Si sigue usando los mensajes como una imitación de solicitud / respuesta, la lógica de su programa tendrá una dependencia porque de alguna manera está esperando la respuesta. Si bien esto está bien en algunos casos, lo invito a pensar en los problemas de una manera diferente. Siempre que sea posible, no piense en enviar pedidos (como GETPOSTen HTTP), intente enviar eventos . Dígale al sistema lo que pasó y no lo que debe hacer . Por ejemplo, después de que un usuario se registre en su aplicación, envíe un mensaje que diga: "un usuario acaba de registrarse" e información sobre él. Al hacerlo, el servicio de correo electrónico será notificado y enviará un correo electrónico de bienvenida al usuario. Pero también se notificará al servicio de Métricas y se registrará el registro en Intercom, Google Analytics u otro lugar.

Pensar en eventos en lugar de acciones nos permite desacoplar de manera efectiva nuestra lógica. Sin embargo, a veces será imposible o demasiado complicado modelar su sistema simplemente usando eventos. En ese caso, se recomienda que utilice un intercambio diferente con una estructura de tema diferente, de modo que pueda diferenciar instantáneamente entre acciones y eventos .

Firme siempre los mensajes con una clave única , especialmente con acciones. Esto te ayudará a depurar tu sistema y emitir un mensaje como respuesta de otro, usando un tema diferente. Cuán cuidadosamente defina sus temas es tan importante como lo que ponga en sus mensajes.

Los temas

Comparables a las URL hasta cierto punto, los temas son como canales o rutas. Cuando envías un mensaje, lo envías a un tema determinado, y cuando creas un intercambio puedes enrutarlo a ciertos temas.

Si está creando API asincrónicas en microservicios coreografiados, se recomienda encarecidamente utilizar los protocolos AMQP y / o MQTT . Aparte de muchas características interesantes que obtendrá de inmediato, la estructura de sus temas es realmente poderosa.

Sin embargo, debería usar una convención de nomenclatura para ordenar las cosas. Al final, son como rutas en una API HTTP: si sigue las convenciones REST, serán más legibles y predecibles. Puede definir la convención de nomenclatura que prefiera, pero recomendaría que tenga al menos 2 cosas:

  • Utilizar versiones : v1.user.signupSi la estructura del mensaje cambia, no tiene que romper nada. Los mensajes con la nueva estructura usarán v2 y los antiguos usarán v1. Te permitirá migrar los servicios sin problemas.
  • Utilice el tiempo presente para las acciones y el tiempo pasado para los eventos : v1.user.signupcuando desee registrar al usuario en su sistema. v1.user.signedupcuando el proceso haya terminado. De esa manera, a primera vista, sabrá instantáneamente si fue una acción o un evento.

Conclusión

En los últimos años hemos visto un gran crecimiento en el campo de los microservicios; sin embargo, la mayoría de los ingenieros no querían reemplazar el protocolo HTTP para la comunicación de servicio a servicio, incluso cuando resultó ser más difícil de mantener y escalar el toda la arquitectura. La falta de conocimiento, información o herramientas hace que comenzar con un nuevo protocolo sea abrumador.

Hitch , por ejemplo, decidió apostar por esta arquitectura, y están intentando ser completamente asincrónicos entre bastidores. Está demostrando ser más fácil de mantener y desarrollar nuevas funciones.

¿Su organización está utilizando este enfoque? Asista a la próxima Cumbre de la Plataforma para ver una charla sobre este tema a cargo de Francisco Méndez Vilas, ingeniero jefe de Hitch hq. Discutirá cómo empezar con API asíncronas en microservicios coreografiados.

Recursos adicionales

  • HermesJS - Marco de mensajería en tiempo real
  • Runnable - Ponos
  • Microservicios controlados por eventos con RabbitMQ
  • MQTT Essentials
  • Tutoriales de RabbitMQ

Publicar un comentario

0 Comentarios