architecture - microservice - Microservicios y SOA utilizando mensajería.
microservices vs soa (5)
He estado muy interesado en probar microservicios / SOA como una arquitectura y me cuesta mucho conceptualizar cómo se llevaría a cabo realmente la integración entre servicios.
Me gusta la idea de usar la mensajería para separar a los clientes de los servicios, pero no entiendo cómo un sistema podría utilizarlo exclusivamente. Obviamente, las operaciones asíncronas típicas y las cosas de pub / sub tienen sentido: escenarios como la creación de un nuevo pedido, la transmisión de datos para informes, etc. Lo que no entiendo es si las personas intentan usar la mensajería para escenarios comunes de solicitud / respuesta, por ejemplo , un usuario accede a su página de "perfil" y parte de los datos que deben procesarse en la página son de un servicio de usuario.
Sé que las implementaciones de mensajería comunes proporcionan una funcionalidad de respuesta / solicitud similar a REST, pero ¿se utiliza a menudo para solicitudes de datos simples? Parece más probable que los microservicios expongan los puntos finales de REST y también se registren con un intermediario de mensajes para los diferentes tipos de comunicación en los que participarán, pero todas estas presentaciones que veo de SOA y la arquitectura de microservicios parecen sugerir que solo usan una u otra. .
Gracias por cualquier elaboración / experiencias!
Lo que no entiendo es si las personas normalmente intentan usar la mensajería para situaciones comunes de solicitud / respuesta, por ejemplo, un usuario accede a su página de "perfil" y parte de los datos que deben procesarse en la página son de un servicio de usuario. .
La clave es evitar la solicitud / respuesta por completo. Técnicamente, esto es posible si toda la pila permite el envío de mensajes asíncronos, incluso para el front-end web mediante el uso de algo como un WebSocket en una aplicación de una sola página (SPA). Para ver un ejemplo práctico, puede consultar la plantilla de mapas reactivos de Typesafe ( https://www.typesafe.com/activator/template/reactive-maps-java ).
Acabo de comenzar a aprender microservicios, así que esta no es una respuesta perfecta. Sin embargo, es mi opinión basada en mi comprensión actual.
Si está creando microservicios basados en eventos, entonces un intermediario de mensajes jugará un papel muy importante. Digamos que tiene un servicio llamado CreateUserService que solo es responsable de recopilar los datos necesarios para crear un usuario que no persista en los datos. Estos datos se publican luego en una cola.
Los suscriptores a la cola createUser DuplicateUserService, UserDataStore, etc ... pueden reaccionar de acuerdo con los datos dentro de cada servicio.
Al final, el cliente recibe datos de otro servicio con información relevante sobre el evento intentado.
Creo que cuando se pregunta con qué frecuencia se utiliza la "mensajería" en la solicitud / respuesta, probablemente se refiere a la comunicación asíncrona.
Tomaré una perspectiva diferente (opuesta) que algunas de las respuestas aquí, y diré que casi siempre debe usar async, incluso en la solicitud / respuesta. Esto se debe a que async significa que no está bloqueando su programa a la espera de una respuesta, y su programa puede continuar realizando otro procesamiento mientras espera una respuesta.
Por ejemplo, imagina que estás implementando la página de inicio de Twitter. Usted dispara un montón de solicitudes a diferentes microservicios ("consígame seguidores recomendados", "consígame la última línea de tiempo", etc. "). No desea bloquear y serializar todas estas solicitudes. Quiere despedirlas async y eso crea una experiencia de usuario mucho mejor, porque a medida que las respuestas regresan, actualizan la interfaz de usuario en tiempo real.
Twitter utiliza Finagle ( http://twitter.github.io/finagle/guide/index.html ) para exactamente esto (RCP asíncrono). No hace algunas de las cosas que haría un sistema de mensajería (en particular, está realmente vinculado a la JVM, y no implementa control de flujo o colas), pero sí implementa una solicitud / respuesta asíncrona.
He publicado sobre esto before , pero en general, las operaciones síncronas (por ejemplo, un usuario que hace clic en un botón y esperan que algunos datos se devuelvan) son síncronas por una razón.
Es decir, síncrono, no debido a la tecnología utilizada para procesar su llamada, sino debido a una expectativa incorporada y generalmente inflexible por parte del usuario de que las cosas deben suceder en tiempo real y no "fuera de línea" (incluso si no hay diferencia material la mayor parte del tiempo).
Por lo tanto, generalmente es imprudente colocar cualquier tipo de pila de tecnología sin conexión o asíncrona entre un usuario y su respuesta esperada.
Al igual que con todas las cosas, las excepciones abundan (y podrían generar una conversación completamente nueva), pero ciertos tipos de llamadas de usuarios pueden y deben manejarse "off-line" dependiendo de la situación.
Sin embargo, siento que el enfoque de su afirmación:
Me gusta la idea de usar la mensajería para desacoplar a los clientes de los servicios
pierde el punto un poco. En realidad no queremos desacoplar a los clientes (o consumidores) y los servicios.
Esperamos que un cliente para, digamos, la capacidad comercial de Cuentas por Pagar esté altamente acoplado al microservicio de cuentas por pagar.
De manera similar, esperaríamos un alto grado de acoplamiento entre una firma de punto final de servicio bool ProcessTransaction(Transaction transaction) y el consumidor de dicha operación.
Donde el desacoplamiento se vuelve realmente importante es el desacoplamiento entre servicios que soportan diferentes capacidades de negocios.
Y es aquí donde los beneficios de los mensajes realmente marcan la diferencia. Déjame saber lo que piensas y si esto te ha ayudado en algo.
No he usado REST, pero uso WSDL para permitir la comunicación entre las capas. La integración entre servicios es muy simple: se comunican entre sí como funciones anidadas en el back-end o simplemente utilizan XML y JSON si las solicitudes van de un servidor a otro.
Aquí el servidor es el anfitrión de los servicios web internos. Y en función de los requisitos, la cola se puede proporcionar a los servicios individuales. Pero al final, solo se envía una respuesta a la persona que llama desde el servidor.