Microservicios autónomos, colas de eventos y descubrimiento de servicios.

Últimamente he estado leyendo mucho sobre microservicios, y aquí están algunas de las conclusiones que obtuve hasta ahora (corríjame si me equivoco en algún momento).

1. La arquitectura de microservicios combina bien con el diseño dirigido por dominios. Por lo general, una MS representa un contexto acotado.
2. Si el microservicio A requiere una funcionalidad que reside en el microservicio B , mi modelo probablemente esté equivocado y A y B en realidad deberían ser un micro servicio / BC.
3. La comunicación sincrónica entre microservicios (solicitudes HTTP directas) es mala, porque desafía el propósito de los microservicios e introduce el acoplamiento entre componentes.
4. La comunicación asincrónica entre servicios es deseable. Los servicios deben publicar eventos en las colas de mensajes, para que otros servicios puedan suscribirse y procesar su parte del evento, o usarlo para replicar una parte de los datos necesarios para su contexto. De esta manera, los servicios pueden procesar solicitudes, incluso otros servicios están inactivos, lo que no sería el caso en la comunicación sincrónica.
5. Si el microservicio A publica un evento, el microservicio B se suscribe a ese evento y produce un nuevo evento como resultado, el microservicio A no debe ser el que procesa el evento recién creado, ya que sería una dependencia circular. En este caso, debemos introducir un tercer microservicio o combinar A y B en el microservicio AB .
6. El microservicio es en realidad un término engañoso. Deberíamos luchar por contextos pequeños, pero ese no tiene por qué ser el caso. El término no debe ser "microservicio", sino "lo suficientemente grande como para hacer el servicio de trabajo ".
7. Los microservicios nos permiten introducir nuevas funcionalidades con más facilidad y sin temor a que rompamos todo el sistema. Se puede hacer introduciendo un nuevo servicio o refactorizando uno de los existentes.
8. Cada microservicio debe tener su propio almacenamiento de datos. La replicación / duplicación de datos es un comportamiento deseable en esta arquitectura.

Además de confirmar mi comprensión de esta arquitectura, mi otra parte de la pregunta está relacionada principalmente con el descubrimiento de servicios. Si los servicios se comunican de forma asíncrona y utilizan una cola de eventos central como Amazon SQS, ¿eso significa que el descubrimiento de servicios no tiene su lugar en una arquitectura como esa?

Los servicios no deben tener ningún conocimiento sobre otros servicios en el sistema. ¿Solo conocen su contexto y los eventos a los que deberían publicar o suscribirse?

Sus conclusiones parecen mayormente fundadas y resumen muy bien el camino a seguir para los microservicios.

Sin embargo, no sería totalmente compatible con 2, 5 y 8:

• 2) Una dependencia simple no debería conducir automáticamente a una fusión. Debe tener en cuenta la frecuencia de tales llamadas dependientes y también la frecuencia de las llamadas de otros servicios.

  Entonces, si un microservicio A requiere funcionalidad en el microservicio B con mucha frecuencia, y el microservicio B rara vez es necesitado por otros microservicios, debe cuestionar la estructura prevista y preguntar si no sería más apropiado agrupar ambos microservicios.

• 5) por supuesto, debe evitar ciclos interminables en el manejo de mensajes.

  Pero agregar un intermediario no lo impedirá: A podría lanzar un mensaje manejado por C que lanza un mensaje manejado por B, quien lanza un mensaje manejado por A y aquí está atrapado en un bucle.

  El problema no puede evaluarse solo considerando el nivel de microservicio: la pregunta es realmente sobre el tipo de mensaje y el contenido que podría conducir al ciclo. Por lo tanto, el gráfico que modela la distribución y el procesamiento de mensajes a través de los servicios debe analizarse como un todo (de hecho, esto puede ser complejo, por lo que puede imaginar un microservicio de monitoreo que detecte dichos ciclos y los rompa).

• 8) sí, cada microservicio tendrá su almacenamiento / base de datos dedicada.

  Se requiere un mínimo de replicación para permitir que los servicios sean independientes. Sin embargo, no iría tan lejos para decir que se desea la replicación: debe mantenerse al mínimo para evitar el acoplamiento oculto a través de procesos de replicación.

  Los microservicios son sobre acoplamiento flojo. Esto a veces se puede lograr de manera más efectiva llamando a otro microservicio para recuperar datos relacionados, en lugar de replicar datos.

Las dos últimas afirmaciones sin numerar son demasiado amplias para ser respondidas con firmeza aquí. Creo que su sugerencia es un buen punto de partida, pero que realmente depende de los requisitos arquitectónicos y las limitaciones.

Los microservicios tratan de desacoplar diferentes dominios de funcionalidad. Cada servicio puede ser desarrollado a un ritmo diferente, por un equipo diferente, usando una pila de tecnología diferente. Esto crea flexibilidad organizacional. La compensación es la complejidad operativa, donde cada servicio adicional crea una cosa más que debe administrarse en un entorno operativo. Por lo tanto, la compensación fundamental del monolito frente al microservicio no se trata de evitar dependencias, se trata de evitar el desarrollo y la implementación de pasos de bloqueo donde todo debe enviarse de una vez, sino a costa de tener que enviar más a menudo porque hay Más partes móviles.

Los servicios no deben tener ningún conocimiento sobre otros servicios en el sistema. ¿Solo conocen su contexto y los eventos a los que deberían publicar o suscribirse?

El problema de evitar la dependencia es una pista falsa. Siempre tendrá dependencias entre las piezas de su producto, y si están en un servicio separado o parte del mismo código no altera el hecho de que las dependencias pueden romperse. Pueden romperse a nivel operativo, porque un servidor clave se cae, y usted lo gestiona a través de prácticas de redundancia operativa y de conmutación por error. También pueden romperse en el nivel de integración, porque las partes cambian de manera incompatible, lo que detecta a través de las pruebas de integración. Mezclar código entre servicios no resuelve el problema de dependencias potencialmente rotas. Las soluciones para evitar dependencias interrumpidas son la redundancia operativa y las pruebas de integración, que no tienen nada que ver con el tamaño de sus servicios.

Si los servicios se comunican de forma asíncrona y utilizan una cola de eventos central como Amazon SQS, ¿eso significa que el descubrimiento de servicios no tiene su lugar en una arquitectura como esa?

Para responder a esa pregunta, primero responda esta: ¿por qué desea comunicarse de forma asincrónica? ¿Es para facilitar el desarrollo independiente de componentes separados? ¿Es para mejorar la disponibilidad operativa de un sistema 24/7? Digamos que es lo último y desea utilizar colas para replicar datos en bases de datos locales. Bueno, ahora sus datos pueden estar obsoletos. En algún momento será demasiado rancio. ¿Cómo lidias con eso? Además, ¿cómo se asegura la disponibilidad operativa de la cola, que es otro componente de tiempo de ejecución? ¿Y cómo se asegura la disponibilidad de esas bases de datos locales? En lugar de administrar un clúster de base de datos, ahora tiene varios. ¿Puede su equipo de operaciones manejar esta carga de trabajo? Y realmente, ¿vale la pena la complejidad, cuando quizás sus usuarios estarían más felices con más funciones y unas pocas horas de tiempo de inactividad cada mes si construyera un monolito simple?

Creo que entiendes mi punto. El diseño del sistema no se trata de lo correcto o incorrecto, se trata de elegir entre una amplia variedad de compensaciones. Todo lo que está mal puede estar bien, y viceversa, si solo lo ves en el contexto correcto. Su contexto es exclusivo para usted, por lo que si bien podemos darle una respuesta, no será la respuesta. Recuerde quién es su audiencia, cuáles son sus necesidades y se revelará el diseño correcto.

1. La arquitectura de microservicios combina bien con el diseño dirigido por dominios. Por lo general, una MS representa un contexto acotado.

Discrepar. DDD tiende a ser muy OO. se entrega un pedido? Order.Deliver () mientras que los microservicios tendrían DeliveryService.Deliver (orden)

2. Si el microservicio A requiere una funcionalidad que reside en el microservicio B, mi modelo probablemente esté equivocado y A y B en realidad deberían ser un micro servicio / BC.

En desacuerdo, debe intentar mantener sus micro servicios micro. dividirlos aún más pequeños!

3. La comunicación sincrónica entre microservicios (solicitudes HTTP directas) es mala, porque desafía el propósito de los microservicios e introduce el acoplamiento entre componentes.

Discrepar. los servicios no deberían preocuparse por quién los está llamando y las personas que llaman no deberían preocuparse de que la lógica se implemente en un microservicio.

4. La comunicación asincrónica entre servicios es deseable. Los servicios deben publicar eventos en las colas de mensajes, para que otros servicios puedan suscribirse y procesar su parte del evento, o usarlo para replicar una parte de los datos necesarios para su contexto. De esta manera, los servicios pueden procesar solicitudes, incluso otros servicios están inactivos, lo que no sería el caso en la comunicación sincrónica.

Las colas son buenas. Pero tu razonamiento está mal. La única diferencia entre las respuestas de sincronización y las asíncronas es que espera la sincronización. Puede implementar llamadas de estilo RPC con colas y múltiples trabajadores sin problemas.

5. Si el microservicio A publica un evento, el microservicio B se suscribe a ese evento y produce un nuevo evento como resultado, el microservicio A no debe ser el que procesa el evento recién creado, ya que sería una dependencia circular. En este caso, debemos introducir un tercer microservicio o combinar A y B en el microservicio AB.

Discrepar. No es una dependencia circular porque sus microservicios no están acoplados. También desea atender reenviar senarios, SendEmail, EmailFailed, SendAgain no necesita 3 microservicios

6. El microservicio es en realidad un término engañoso. Deberíamos luchar por contextos pequeños, pero ese no tiene por qué ser el caso. El término no debe ser "microservicio", sino "lo suficientemente grande como para hacer el servicio de trabajo".

Discrepar. Echa un vistazo a los nano-servicios.

7. Los microservicios nos permiten introducir nuevas funcionalidades con más facilidad y sin temor a que rompamos todo el sistema. Se puede hacer introduciendo un nuevo servicio o refactorizando uno de los existentes.

Discrepar. Sí, se desacopla, pero la orquestación de microservicios puede ser tan desalentadora como cualquier proyecto monolítico.

8. Cada microservicio debe tener su propio almacenamiento de datos. La replicación / duplicación de datos es un comportamiento deseable en esta arquitectura.

Discrepar. Aunque no debería compartir el almacenamiento, sus microservicios deberían tratar de no tener estado cuando sea posible. no duplique datos a menos que esté en vuelo

Sus conclusiones son buenas reglas generales, pero no universales. Habrá casos en que la mejor opción es romper estas reglas, incluso en un proyecto greenfield. En algunos casos, la comunicación sincrónica es la mejor opción. En algunos casos, no es bueno fusionar dos servicios en uno, incluso si están acoplados por comunicación sincrónica.

Y a su otra pregunta, el descubrimiento de servicios no es necesario para la comunicación basada en la cola.

Um, solo estás hablando de programación orientada a objetos. O al menos, lo que originalmente fue concebido para ser: piezas independientes de código en ejecución que se comunican entre sí mediante mensajes.

Alan Kay concibió la OOP como un modelo de sistemas biológicos, donde las células son relativamente independientes entre sí y solo se comunican a través de mensajes que se conectan a interfaces externas en otras células.

Entonces, ¿por qué dejamos de pensar en ello como OOP solo porque todos los objetos no se ejecutan en la misma computadora? En todo caso, eso es aún más orientado a objetos. a que si están en la misma computadora y parte de la misma aplicación, porque si todos los objetos están en la misma aplicación, los desarrolladores a menudo rompen OOP al usar variables globales compartidas por todas las clases y incluyendo los mismos encabezados en cada archivo, etc. Cuando todos los objetos dependen de las mismas cosas, no están tan encapsulados como si fueran completamente independientes entre sí, y la encapsulación es el objetivo de OOP.

Por ejemplo, casi todo lo que se dice en las otras respuestas son declaraciones de libros de texto sobre OOP.

Dado que a menudo encuentro una comprensión errónea de un concepto tan importante como Contexto acotado y Dominio central, me gustaría dar un poco más de detalles.

Me pareció extremadamente rentable pensar en subdominios como en capacidades empresariales. La capacidad empresarial es algo que hace su organización. Es una de sus funciones comerciales. Dado que nuestro objetivo es la alineación entre negocios y TI , definitivamente quiero que tengan una relación 1: 1 con mis servicios técnicos .

Entonces este proceso se reduce a lo siguiente. Primero, defino las capacidades empresariales de nivel superior. Debe tomar la forma de sustantivo y verbo (o alguna forma derivada). Por lo general, hay menos de 10 capacidades comerciales. Luego, soy inmensamente más profundo, identificando capacidades anidadas. Y así sucesivamente, hasta que no haya nada que dividir. Las capacidades que utilizó para utilizar este enfoque reflejan el dominio real, la forma real en que funciona su organización. Estas capacidades se acoplarán de manera innata y flexible, por lo que si asigna sus servicios técnicos a estas capacidades, serán autónomas y estarán basadas en eventos. Este proceso se denomina mapeo de capacidad empresarial , pero hay otras formas de encontrar sus servicios, la más importante de las cuales es probablemente el Análisis de la cadena de valor .

Aquí hay un ejemplo de identificación de límites de servicio utilizando este enfoque.