web applications - orientada - Arquitectura de una aplicación web basada en microservicio.

microservicio crud (4)

Actualmente estamos implementando una arquitectura similar a su segunda opción. Nos encontramos con las siguientes complejidades mientras lo hacíamos: (siéntase libre de que cualquiera pueda participar en esto, ya que todavía es un trabajo en progreso)

Todavía hay técnicamente una aplicación monolítica en su sistema (la aplicación orientada al usuario). Cada vez que se realiza un cambio en la API REST, tendrá que cambiar la aplicación frontal para manejar esos cambios nuevos. Ni siquiera me refiero a cómo introduces un nuevo microservicio detrás de él. Así que, en esencia, cuanto más microservicios pongas detrás de él, más grande será la API Gateway. ( https://www.nginx.com/blog/building-microservices-using-an-api-gateway/ )

La puerta de enlace API también tiene algunos inconvenientes. Es otro componente altamente disponible que debe ser desarrollado, implementado y administrado. También existe el riesgo de que la puerta de enlace API se convierta en un cuello de botella en el desarrollo. Los desarrolladores deben actualizar la puerta de enlace API para exponer los puntos finales de cada microservicio. Es importante que el proceso para actualizar la puerta de enlace API sea lo más ligero posible. De lo contrario, los desarrolladores se verán obligados a esperar en línea para actualizar la puerta de enlace. Sin embargo, a pesar de estos inconvenientes, para la mayoría de las aplicaciones del mundo real tiene sentido utilizar una puerta de enlace API.

Para la reutilización, diseñé una capa de abstracción que define un comportamiento único para la comunicación con cada microservicio. Una implementación concreta para cada microservicio. Esto introdujo otra capa de complejidad porque ahora teníamos que mantener lo que llamamos "conectores RPC" junto con su microservicio correspondiente. Personalmente, esto le tomó mucho tiempo al desarrollador ya que, además de mantener su microservicio respectivo, tenían que mantener el conector. Si alguno de esos estuviera desactualizado, la aplicación pública fallaría. Además, los cambios en el conector requerirían una reconstrucción de la aplicación pública (actualmente definimos los conectores como dependencias jar).
Si bien esto se menciona en otra publicación y en un blog, la relación de clave externa se convierte en un desastre cuando se trata de microservicios múltiples que manejan su propia db. (Base de datos por patrón de servicio) Su aplicación frontal se enfrenta ahora al problema de tener que unirlos. ("Necesito estos datos, pero tengo que buscar estas claves en cada microservicio para ver quién tiene qué"). No estoy diciendo que esta sea la forma correcta de hacerlo, pero si estamos tratando con varias filas devueltas cada uno de los identificadores debe resolverse individualmente desde un microservicio. No estoy seguro de cuán eficiente es esto. Me encantaría escuchar sugerencias.

Estoy confundido sobre el punto en el que una aplicación web se desvía en microservicios: ¿es a nivel de URL o a nivel de modelos? Como ejemplo, supongamos que tengo una aplicación monolítica que sirve 3 páginas. Digamos que cada página tiene una base de datos separada y quiero respaldarlas con sus propios microservicios. Ahora, cuál de estos es la forma correcta de implementar una arquitectura basada en microservicio:

Creo tres aplicaciones diferentes (microservicios), cada una de las cuales contiene (ruta, controlador, modelos, plantillas) para una de las páginas. Y luego, en función de la página solicitada, dirijo la solicitud a esa aplicación en particular. Esto significa que toda la página de la base de datos a HTML es servida por una aplicación separada. Básicamente, diferentes aplicaciones en el mismo sitio web están siendo completamente servidas por diferentes aplicaciones en el backend.
Los 3 microservicios no manejan el contenido de la interfaz de usuario, sino solo los datos de sus casos de uso (modelos, controlador, sin plantillas) y los exponen a través de una API REST. Tengo una aplicación orientada al público. Esta aplicación consulta las tres aplicaciones diferentes (microservicios) solo para los datos y luego construye las páginas html para devolverlas al navegador. En este caso, todas las páginas de una aplicación web están siendo atendidas por una sola aplicación que hace uso interno de tres microservicios diferentes.

Como es habitual en Ingeniería de Software, la respuesta es que depende. No puedo imaginar una razón en este momento, pero la opción 1 podría ser útil en algunos escenarios particulares.

Sin embargo, considerando la definición formal de microservicios, la opción 2 lo ilustra mejor. Una de las principales ventajas de tener microservicios es poder reutilizarlo. Diferentes aplicaciones tienen diferentes requisitos y necesidades en la presentación de la información. Hacer que sus microservicios devuelvan una representación JSON de sus datos le dará más flexibilidad sobre cómo formatear esta información.

El patrón de puerta de enlace Api de Microservice apigateway es el primer punto desde donde puede comenzar a distribuir o reenviar las llamadas a diferentes servicios

Tu problema es cómo modelar tus microservicios.

En términos de microservicios, el segundo enfoque es el más apropiado, que expone su lógica a través de la API.

Siempre cuando modeles tus microservicios ten en cuenta los siguientes hechos.

Acoplamiento flojo : cuando los servicios se acoplan de manera flexible, un cambio a un servicio no debe requerir un cambio a otro. El punto central de este Microservicio es poder cambiar un servicio e implementarlo, independientemente de la necesidad de cambiar cualquier otra parte del sistema. Esto es realmente muy importante.
Cohesión fuerte : queremos que el comportamiento relacionado se siente junto, y el comportamiento no relacionado se siente en otro lugar. ¿Por qué? Bueno, si queremos cambiar el comportamiento, queremos poder cambiarlo en un lugar y liberar ese cambio lo antes posible.