¿Está el uso de un intermediario de mensajes alineado con los microservicios de construcción de Sam Newman?

7

En uno de los proyectos, el CTO ha elegido utilizar un intermediario de mensajes para conectar microservicios. ¿Está el uso de dicho software alineado con la teoría de los microservicios?

Intente responder la pregunta

EnMicroserviciosdeconstruccióndeSamNewman,capítulo12:Reuniéndolotodo,elautormencionasieteprincipios,incluidoDescentralizartodaslascosas.Elúltimopárrafodeesaparteeselsiguiente:

  

Esteprincipiopuedeaplicarsetambiénalaarquitectura.Eviteenfoquescomo  Serviciodebusdeempresaosistemasdeorquestación,quepuedenconducira  Centralizacióndelalógicaempresarialyserviciostontos.Ensulugar,prefiero  coreografíasobreorquestaciónymiddlewaretonto,consmart  puntosfinalesparagarantizarquemantienelalógicaylosdatosasociadosdentrode  Límitesdeservicio,ayudandoamantenerlascosascohesionadas.

Busdeserviciosempresariales

  

implementa un sistema de comunicación entre interacciones mutuas   aplicaciones de software en una arquitectura orientada a servicios (SOA)

Sistemas de orquestación

  

la organización, coordinación y gestión automatizadas de   sistemas informáticos, middleware y servicios

Choreography

  

el arte o la práctica de diseñar secuencias de movimientos físicos   cuerpos (o sus representaciones) en los que el movimiento, la forma o ambos son   especificado

Dumb middleware

  

Estoy bastante seguro de que existen buses de servicios empresariales que   están manejando escenarios similares y esos son lo opuesto a lo simple   "Tontos" marcos de paso de mensajes similares a ZeroMQ.

Puntos finales inteligentes

  

P: Y con respecto a los puntos finales inteligentes .. si lo hago bien,   Microservice = punto final, una especie de algo que puede enviar / recibir   mensajes La razón por la que el punto final es inteligente, porque tiene una lógica   en el interior, no en el middleware (por ejemplo, ESB). ¿Derecha?    A: Exactamente, los puntos finales tienen la lógica y en realidad hice un proyecto en   un equipo de código abierto que usó JMS como la comunicación subyacente para   un ESB, por lo que debería ser bastante tonto

Preguntas

  1. ¿Cuál es la definición de coreografía en TI?
  2. ¿Cuáles son ejemplos de middleware tonto ?
  3. ¿Los microservicios son puntos finales inteligentes ?
  4. Es el uso de intermediarios de mensajes, por ejemplo, kafka, rabbitmq, zeromq y qpid en Microservices, ¿una mala práctica?
pregunta 030 20.04.2017 - 12:47

1 respuesta

11

Está bien, lo intentaré aquí.

En primer lugar, la opinión de Sam se considera la forma normal de "hacer" los microservicios, pero hay compensaciones.

Entonces:

  1. La coreografía significa que los actores actúan de manera independiente pero de acuerdo con un conjunto de instrucciones compartido. Esto es opuesto a la orquestación donde hay un conductor central que le dice a los jugadores qué hacer y cuándo hacerlo.

    La orquestación se asocia comúnmente con los ESB, que contienen gran parte de la lógica empresarial (piense en los scripts y las opciones) y distribuyen el trabajo a los servicios.

    La coreografía es más comúnmente asociada con los sistemas controlados por eventos, donde los servicios transmiten eventos al mundo, y las partes interesadas actúan en esos eventos de manera independiente.

  2. El middleware mudo implica que el middleware no reacciona activamente al contenido de los mensajes que transporta. Las rutas de "cosas" de A a B se basan en la dirección del sobre. La mayoría de middleware de mensajería es tonta a este respecto, aunque a menudo se agrega un grado de inteligencia para proporcionar garantías de entrega, por ejemplo. Exactamente una vez. Podría decirse que esto no es inteligencia en sí misma, pero sigue siendo, en mi opinión, un poco demasiado inteligente debido a las preocupaciones transaccionales y la semántica de manejo de fallos, pero no vamos a eso todavía. Confíe en mí cuando digo que los arquitectos discuten sobre estas cosas todo el tiempo, y Sam se pone del lado de la luz y la verdad aquí, si no la conveniencia y la simplicidad.

  3. Si tiene middleware tonto, entonces los microservicios tienen que ser puntos finales inteligentes, de lo contrario, tendrá un sistema frágil (que se rompe fácilmente) del peor tipo. La cantidad de inteligencia depende de cómo se quiere tratar con la sobrecarga y el fracaso. Eche un vistazo a todas las ventajas que utiliza Netflix para agregar estos conocimientos a los microservicios de forma reutilizable, por ejemplo. Hystrix.

  4. No. Tanto como el middleware no debería ser demasiado inteligente, no debería ser estúpido. Kafka, ZeroMQ, etc., son subsistemas altamente sofisticados cuando se desea realizar correctamente los sistemas controlados por eventos. Eso no significa que tengas que usarlos, pero tienen algunas características útiles. La mayoría de los sistemas a gran escala hacen ambas cosas. Las cosas síncronas se realizan mediante la solicitud / respuesta http. Las cosas asíncronas utilizan la mensajería. La mensajería puede ser centralizada (Kafka) o distribuida (ZeroMQ local), pero las centralizadas pueden aislarlo fácilmente de la falla / recuperación del servicio.

respondido por el emperorz 20.04.2017 - 14:55

Lea otras preguntas en las etiquetas