architecture - example - Microservicios de versión de producto
net core ddd (2)
Entro en la arquitectura de microservicios basada en la ventana acoplable y tengo 3 microservicios, que juntos crean un producto, por ejemplo, "sistema CRM".
Ahora quiero que mi cliente pueda actualizar su producto, cuando quiera. Tengo 3 versiones diferentes de mis microservicios, ¿cuál debería ver el cliente? Supongo que la versión del producto debería ser independiente de los microservicios, porque copiar uno de los microservicios me haría tener más problemas que no tener ninguna versión.
Entonces, ¿hay algún patrón, idea para manejar tal situación?
Lo único que me viene a la mente es tener otro repositorio que se versionará cada vez que uno de los microservicios produzca un paquete listo para la producción. Sin embargo, ahora tengo una versión que ninguno de mis Product Owners (PO) sabría.
Versiones de micro servicio
En primer lugar, asegúrese de que los microservicios sigan estrictamente las versiones semánticas (SemVer) . No hacerlo tarde o temprano llevará a problemas de incompatibilidad.
Capture solo los cambios de la API en esa versión, no lo mezcle con las versiones internas de microservicios (por ejemplo, las versiones de esquemas de base de datos para un servicio que tiene una base de datos).
Versión del producto
Introduce una versión para el producto como ya sugeriste. Seguir a SemVer también tiene sentido aquí, pero es posible que deba aflojarse para satisfacer las necesidades de marketing (por ejemplo, permitir un incremento importante de la versión, aunque SemVer solo requiera un incremento menor de la versión). En casos extremos, utilice "versiones técnicas" y "versiones de marketing" dedicadas. Sin embargo, esto también es más complicado para los clientes.
También tenga en cuenta que necesitará definir qué significa la versión de SemVer en términos de su aplicación, ya que la aplicación en su conjunto no tiene "API".
Gestión de la dependencia
Ahora, una versión específica del producto es una lista de microservicios de versiones específicas. Tenga en cuenta que esto es esencialmente la gestión de dependencias en el mismo sentido que npm apt , npm , npm , etc. Es difícil decir qué tan sofisticada debe ser su solución, pero recomiendo al menos apoyar la noción de "versiones mínimas requeridas". Si la ventana acoplable tiene un mecanismo incorporado, intente usar ese (no sé muy bien la ventana acoplable, así que no puedo decirlo).
Con esto, por ejemplo, puede especificar que su producto en la versión 4.8.12 requiere el servicio A en la versión 1.12.0 y el servicio B en 3.0.4 .
El mecanismo de actualización debe seguir una estrategia que se adhiere a SemVer. Esto significa que la instalación de una versión específica del producto instala automáticamente los servicios más nuevos con la misma versión principal . En el ejemplo anterior, esto podría, por ejemplo, instalar 1.12.2 del servicio A y 3.3.0 del servicio B. Proporcionar un mecanismo para mantener los servicios ya instalados que cumplan con el requisito de dependencia puede ser una buena idea, para que los usuarios no se molesten Por el mecanismo de actualización.
La literatura utiliza un modelo de 5 dimensiones para esto:
- versión (queriendo cambiar)
- estado (ciclo de vida: crear, probar, desplegar, retirar)
- ver (fuente, despliegue, documentación)
- jerarquía (producto, microservicio)
- variante (en gran parte similar, describiendo las diferencias, familias de productos)
La mayoría de los sistemas solo manejan algunas de estas dimensiones. Para manejar los cinco, debe describir (arreglar) su proceso de desarrollo.
Cuando solo mira la versión más jerarquía, como lo hace aquí con el producto y el microservicio versionados por separado: la versión del producto debe cambiar tan pronto como los usuarios del producto puedan notar algo diferente. Es posible que desee señalar que desde la versión del microservicio mediante la numeración mayor-menor: la menor no debe afectar a la versión del producto, la mayor debería. O podrías usar rangos de versión / versionamiento semántico.
La referencia:
Gestión de datos de diseño: las cinco dimensiones de los marcos CAD, la gestión de la configuración y la gestión de datos del producto. van den Hamer, P. Lepoeter, K. Philips Res., Eindhoven;
Este documento aparece en: Actas del IEEE Fecha de publicación: enero de 1996 Volumen: 84, Número: 1 En la (s) página (s): 42-56 ISSN: 0018-9219 Referencias citadas: 26 CÓDIGO: IEEPAD Número de registro INSPEC: 5175049 Identificador de objeto digital : 10.1109 / 5.476025 Versión actual Publicado: 2002-08-06