¿Dónde debe sentarse la lógica de negocios en la arquitectura de microservicios?

Todavía estoy tratando de entender la arquitectura de microservicios ya que estoy acostumbrado a un enfoque monolítico

Supongamos que intentamos construir un sistema de reserva Uber extremadamente simplificado . Para simplificar las cosas que digamos que tienen 3 servicios y un API puerta de entrada para el cliente: Booking, Drivers, Notificationy tenemos el siguiente flujo de trabajo:

Al crear una nueva reserva:

1. Compruebe si el usuario existente ya tiene una reserva
2. Obtenga una lista de los controladores disponibles
3. Enviar notificación a los conductores para recoger la reserva
4. El conductor recoge la reserva.

Digamos que todos los mensajes se realizan a través de una llamada http en lugar de un bus de mensajes como kafka para simplificar las cosas.

Entonces, en este caso, pensé que el Bookingservicio puede verificar las reservas existentes. Pero entonces, ¿quién debería recibir la lista de controladores y notificaciones disponibles? Estoy pensando en hacerlo a nivel de puerta de enlace, pero ahora la lógica está dividida en dos lugares:

• Gateway - obtener una lista de los controladores disponibles + enviar notificaciones
• Booking - verificar reserva existente

Y estoy bastante seguro de que la puerta de enlace no es el lugar adecuado para hacerlo, pero siento que si lo estamos haciendo en el Bookingservicio, ¿está estrechamente acoplado?

Para hacerlo más complicado, ¿qué sucede si tenemos otro proyecto que quiere reutilizar el sistema de reservas pero con su propia lógica de negocios? Es por eso que pensé en hacerlo a nivel de puerta de enlace para que la nueva puerta de enlace del proyecto pueda tener su propia lógica de negocios separada de la existente.

Otra forma de hacerlo, supongo, es que cada proyecto tenga su propio servicio de reserva que hablará con el servicio central de reservas, pero no estoy seguro de cuál es el mejor enfoque aquí :-)

La gente a menudo escucha "microservicio" y piensa "nano servicio", y esto puede causar cierta confusión. Estos son micro -servicios, por lo que no es necesario un servicio separado para cada entidad individual. Todo lo que estamos tratando de hacer debe estar en el bookingy notificationservicios. No necesita el driverservicio (para ninguna de las actividades que describió).

Obtener una lista de controladores disponibles para reservar se bookingincluye en el servicio. Una trampa común es no agrupar actividades relacionadas en el mismo servicio, esto se llama baja coherencia y es muy malo. Recuerde, agrupa las cosas en un servicio por dominio problemático, no por entidad.

Ahora, en cuanto a la reutilización, la ventaja de tener un microservicio separado es que ahora puede tener tres equipos separados que hacen que el consumidor enfrente las aplicaciones. Un equipo para la aplicación web html estándar, una aplicación para Android y una aplicación para iOS. Todas estas aplicaciones diferentes se pueden construir de manera completamente diferente y se ven apropiadas para su plataforma particular (sin repetir el código). Las bookingtres aplicaciones reutilizan el código de servicio, ya que las tres hacen llamadas http al servicio en lugar de tener su propio código de reserva.

Un flujo de reserva típico se vería así:

1. La aplicación de Android llama al bookingservicio para obtener una lista de los controladores disponibles.
2. El servicio de reserva devuelve una lista de controladores a la aplicación
3. Luego, el usuario selecciona su controlador y la aplicación llama al método "libro" del bookingservicio
4. El bookingservicio llama al notificationservicio con los detalles de la reserva.
5. El notificationservicio envía una notificación al conductor, notificándole de la reserva.
6. La aplicación del controlador envía un mensaje al notificationservicio cuando están a una milla del cliente
7. El notificationservicio envía la alerta al cliente de que su conductor está casi allí.

Espero que esto haya ayudado; recuerde, son microservicios, no nano servicios, no intente dividir el mismo dominio problemático. Entonces, para responder el título de su pregunta, cuando mantiene un microservicio del tamaño adecuado, toda o la mayor parte de la lógica comercial para ese dominio problemático puede vivir dentro de ese microservicio.

Todo depende de su requerimiento exacto.

Digamos que tiene dos aplicaciones haciendo la reserva:

1. Primer caso: una aplicación puede permitir que un usuario reserve varias veces, y la otra solo permite una. Esto significa que la restricción de la reserva está en el nivel de la aplicación, por lo que tiene dos puntos de entrada en su sistema de reserva (uno que permite la reserva múltiple, uno que no lo hace) o simplemente lo verifica en los microservicios de los correspondientes solicitud.
2. Segundo caso: es parte de la definición de una "Reserva" que un usuario no puede tener múltiples, sea cual sea la aplicación, esta regla es verdadera para todo el sistema: esto significa que puede colocar el cheque en el microservicio de reserva.

En cuanto al sistema de notificaciones, puede hacer que los microservicios se suscriban a su servicio de reserva para escuchar cualquier nueva reserva. Como tal, el microservicio de reserva notificará a todos los suscriptores y actuarán en consecuencia.

El único problema en este tipo de arquitectura es qué sucede si algo falla después de que se haya publicado la notificación, ya que los dos microservicios no funcionan como dos funciones que se ejecutan en la misma transacción de la base de datos, deberá manejar los errores con gracia y, finalmente, reproducir los procesos que han fallado (automática o manualmente)

La respuesta simple es que los clientes de microservicios son los que administran la lógica de negocios en una arquitectura de microservicios "pura". Para que sea más fácil de entender, considere un ejemplo aún más simple. Un servicio que solo devuelve flujos de bytes basados ​​en un URI. Por sí solo, no es terriblemente útil. Sin saber de alguna manera qué URI tienen qué, solo puedes adivinar dónde sacar las cosas. Ahora suponga que tiene un microservicio diferente que proporciona una capacidad de búsqueda. Envía una solicitud con una cadena de consulta y devuelve URI. Ahora las cosas se ponen más interesantes. Puedo poner referencias a URI para el primer servicio en un índice.

Pero aún así, necesitamos coordinar de alguna manera entre estos dos. Hay una respuesta simple: usa un navegador para recuperar los URI del servicio de índice y luego recupera los datos del servicio de datos. Ninguno de los servicios 'sabe' sobre el otro y no hay absolutamente ningún acoplamiento entre ellos. Puedo usar el servicio de índice con cualquier otro servicio de datos y viceversa.

No es necesariamente el caso de que este sea el mejor enfoque en todos los escenarios, pero hay muchos beneficios para construir cosas de esta manera, especialmente la reutilización en escenarios que actualmente no se conocen.