Lecciones prácticas sobre microservicios

Si estás planeando un proyecto basado en la nube, debes considerar seriamente la posibilidad de convertirte en nativo de la nube para utilizar de forma eficiente todos los recursos disponibles en la nube. Nativo en la nube significa hacer uso de microservicios y DevOps como los bloques de creación fundamentales. Los equipos de DevOps crean microservicios y API y, a continuación, orquestan estos servicios en plataformas de contenedores administrados.

A continuación, se presentan algunas notas sobre lecciones de vida real de un proyecto en vivo donde el equipo de Capgemini Cloud construyó más de 60 servicios.

Diseño de los microservicios:

• Comienza con el enfoque empresarial para cada servicio
  • Diseña estos como servicios pequeños con operaciones CRUD en una sola función empresarial o dominio.
  • Utiliza el enfoque de diseño de API-first para asegurarte de que los servicios reutilizables se construyen en todos los LOB y estos se ajustan al consumo de toda la empresa y cumplen con los requisitos de seguridad y gobernanza.
  • El diseño controlado por dominio (también conocido como DDD) es el patrón de arquitectura de factor para microservicios. Esto ayuda a dividir el complejo sistema en microservicios controlados por datos que reflejan el problema empresarial.
  • El desafío clave en DDD es decidir dónde definir los límites de cada contexto delimitado. Esto requerirá varias iteraciones: comienza con contextos únicos y rediseña para evitar el chat entre los servicios.
  • Utiliza una comunicación ligera basada en REST (cliente a servicio y servicio a servicio) donde sea necesario comunicarse entre servicios. Esto, sin embargo, debe tenerlos acoplados libremente y debes asegurarte de que sean sin estado.
  • Divide los servicios en síncronos y asincrónicos, prefiriendo async en la medida en que el proceso empresarial lo permita. Esto se inserta en la filosofía favorita de “puntos finales inteligentes y tuberías de volcado”. Esto básicamente significa que el microservicio se crea mediante comunicaciones asincrónicas, manteniendo así el servicio autónomo y no dependiendo de otros servicios.
  • Normalmente se utilizan patrones de diseño adecuados, como patrones de agregador, proxy y rama.
  • En casos inevitables, habrá transacciones distribuidas y la necesidad de diseñar para ellas. La solución común a esto es el patrón saga, que ayuda a diseñar fallos en caso de distribuido según las ejecuciones parciales.
  • Ve más allá del diseño de doce factores para microservicios. Capgemini Cloud Native utiliza principios de diseño de quince factores para lograr agilidad, escalabilidad y eficiencia operativa.
• Resistencia
  • Los microservicios deben diseñarse para errores de red y del sistema, por ejemplo, retrasos, errores o indisponibilidad de otro servicio o sistema de terceros.
  • Como se mencionó anteriormente, mantener la comunicación asincrónica permite una arquitectura que es resistente cuando algunos servicios fallan.
  • Deben proporcionar una funcionalidad predeterminada en caso de errores de un servicio. Esto podría ser un mensaje de error o si el caso de que el negocio lo permita, un valor predeterminado que sea aceptable hasta que el servicio externo esté disponible.
  • Incluso si los servicios se crean para que una pantalla de interfaz de usuario se consuma, se debe ser responsable de toda la validación de entrada de datos (cliente a servicio y servicio a servicio). Hay marcos comunes para hacer esto mediante lenguaje de expresión y anotaciones en lugar de código.
• Observancia
  • El registro y la supervisión centralizados son imprescindibles en los microservicios distribuidos junto con los mecanismos de seguimiento y alertas
  • Registrar eventos para tiempos de espera y cierres
  • El registro debe incluir el nivel, el nombre de host (nombre de instancia), el mensaje
  • Los eventos de registro se pueden utilizar para la planificación y el escalado de la capacidad, por ejemplo, qué servicios necesitan instancias más altas
  • Métricas relacionadas con los datos empresariales, como el número de reservas o el tiempo necesario para rellenar el formulario.
• Automatización
  • Utiliza las herramientas de prueba para la integración de servicios, tanto en pruebas unitarias del servicio como en pruebas de contrato para garantizar que las API funcionen, aunque el servicio se trate como una caja negra.
  • Los comentarios rápidos sobre las protecciones y los errores en la compilación y la canalización de CI/CD son posibles a través de pruebas de automatización tan pronto como se confirma y compila el código.

¿Deseas obtener más información sobre el diseño de quince factores o nuestro punto de vista sobre las opciones de la plataforma de contenedorización para microservicios, ponte en contacto con nosotros para obtener más información.