Organización de Microservicios Spin

Owned by Edgar Guadalupe Manrique Martinez (Unlicensed)
Oct 26, 2022
3 min read

El backend Spin está bajo una arquitectura de microservicios implementados en Java con SpringBoot y desplegados en contenedores Docker y orquestados por Kubernetes.

Los microservicios están organizados en cuatro capas:

  • Capa de orquestación (OSL Orchestration Service Layer) aka capa canal

  • Capa de datos (DSL Data Service Layer) aka core.

  • Capa de consulta

  • Capa de gateway

Capa OSL

Esta capa es conocida también como “capa de canal” refiriéndose a al canal de comunicación e.g. canal mobile, canal de soporte, canal web. La capa de orquestación OSL contiene los servicios que se comunican directamente con algún cliente e.g. el app mobile, la página web de Spin, alguna UI de un proveedor. Son servicios que no consultan base de datos, únicamente orquestan peticiones a servicios de la capa inferior (DSL aka core) para poder cumplir con su responsabilidad funcional. Si necesitan datos de base de datos, hacen la petición(es) a los microservicios dueños de esa información. Si necesitan ejecutar acciones o consultar información de un proveedor, igualmente hacen el llamado al servicio correspondiente.

 

Capa DSL

La capa DSL contiene los servicios core que consultan directamente la base de datos y cada uno tiene su propio dominio de datos, es decir, cada microservicio se conecta a su propia base de datos que está alineada con su funcionalidad. Es posible y válido que exista más de un microservicio que se conecte a una misma base de datos, siempre y cuando compartan funcionalidad sobre el mismo dominio de datos. También es posible que existan microservicios que se conectan a la misma base de datos, pero operan en colecciones o tablas exclusivas. Los microservicios de esta capa no se integran con proveedores, si necesitan de una funcionalidad de algún proveedor la comunicación es a través de la capa gateway.

Capa de consulta

Los servicios en esta capa tienen como única responsabilidad el exponer datos de su dominio, ya sea desde la base de datos o algún proveedor. Nacen de la implementación del patrón CQRS. Tienen únicamente APIs GET y se conectan a nodos secundarios de la base de datos, dejando a los primarios para inserts, updates y deletes.

Pueden existir servicios que no están en esta capa y hacen consultas directas a la base de datos para obtener datos y poder cumplir con su responsabilidad funcional

Capa Gateway

Son servicios que se integran con algún proveedor para recibir peticiones (webhooks) o hacer peticiones a los proveedores. Son servicios proxy cuya única función es abstraer la integración y funcionalidad de un proveedor y exponerla al ecosistema interno de microservicios. No deben tener lógica de negocio ni conectarse a base de datos a menos que sea estrictamente necesario por diseño.

 

Capas de organización

 

En el diagram se puede apreciar cada capa, grupo e interacciones. Nótese lo siguiente:

  • Servicios de consulta y de core pueden conectarse a la misma base de datos si el dominio de datos de su funcionalidad es el mismo.

  • Más de un microservicio DSL puede conectarse a la misma base de datos para cumplir con su funcionalidad.

  • Los servicios OSL NO se comunican directamente con proveedores o bases de datos.

  • Los servicios DSL NO se comunican directamente con proveedores pero sí con base de datos.

  • Un servicio OSL puede hacer una o más llamadas a servicios DSL para cumplir con su responsabilidad.

  • Servicios de capa OSL no se comunican entre sí.

  • Servicios de capa DSL nunca llaman a servicios OSL, sino al revés.

  • Servicios gateway NO se comunican con base de datos.

  • Los proveedores no hacen peticiones directamente a los servicios de capa DSL.