Debido a una combinación de requisitos empresariales / empresariales y las preferencias de nuestro arquitecto, hemos llegado a una arquitectura particular que me parece un poco extraña, pero tengo un conocimiento arquitectónico muy limitado y aún menos conocimiento de la nube, por lo que me encantaría un control de cordura para ver Si hay una mejora que se puede hacer aquí:
Antecedentes: estamos desarrollando un reemplazo para un sistema existente que es una reescritura completa desde cero. Esto requiere que obtengamos datos de una instancia de SAP a través de los servicios web BAPI / SOAP, así como que usemos algunas bases de datos propias para datos que no están en SAP. Actualmente, todos los datos que administraremos existen en bases de datos locales en una aplicación distribuida, o en una base de datos MySQL que deberá migrarse. Tendremos que crear un puñado de aplicaciones web que replican la funcionalidad de la aplicación distribuida existente, así como proporcionar funcionalidad relacionada con el administrador sobre los datos que controlamos.
Requisitos empresariales / empresariales:
Cualquier base de datos que controlemos debe implementarse en MS SQL Server
Minimice la cantidad de bases de datos creadas
La fase 1 nos permitirá implementar nuestras aplicaciones en Azure, pero necesitamos la capacidad de llevar estas aplicaciones a las instalaciones en el futuro
Nuestro equipo de operaciones quiere que reduzcamos todo, ya que creen que hará que su gestión del código sea mucho más simple.
Minimizar / eliminar la replicación de datos
La pila de codificación será .NET Core para microservicios y aplicaciones de administración, pero Angular 5 para la aplicación front-end principal.
A partir de estos requisitos, nuestro arquitecto ideó este diseño:
Nuestros front-end se alimentarán de una serie de microservicios (uso ese término a la ligera, ya que son de 'Dominio' y bastante grandes), que se dividirán en Servicios de lectura y Servicios de escritura en cada dominio. Ambos serán escalables y de carga equilibrada a través de Kubernetes. Cada uno también tendrá una copia de solo lectura de su base de datos adjunta dentro de su contenedor, con una única instancia maestra de la base de datos disponible para escrituras que enviará actualizaciones a esas copias de solo lectura.
(Perdón por las imágenes de baja calidad, las estoy rehaciendo de memoria ya que, naturalmente, no hay documentación real para estas cosas, excepto en la cabeza del arquitecto)
La comunicación de servicio a servicio se realizará a través de una cola de mensajes que cada servicio escuchará y procesará los mensajes relevantes. El uso principal de esto será para la generación de correo electrónico, ya que no hay nada más que hayamos identificado que requiera comunicación de servicio a servicio para obtener información. Cualquier cosa relacionada con la "lógica de negocios" que requeriría la participación de múltiples servicios probablemente fluiría desde los front-end, donde los front-end llamarían a cada servicio individualmente y se ocuparían de la atomicidad.
Desde mi punto de vista, lo que me molesta es las instancias de DB de solo lectura que giran dentro de los contenedores de la ventana acoplable para los servicios. El servicio en sí y la base de datos tendrían demandas drásticamente diferentes en términos de carga, por lo que tendría mucho más sentido si pudiéramos equilibrarlas por separado. Creo que MYSQL tiene una forma de hacerlo con las configuraciones maestro / esclavo, donde los nuevos esclavos pueden activarse cada vez que la carga se eleva. Especialmente mientras tenemos nuestro sistema en la nube y estamos pagando por cada instancia, girar una nueva instancia de todo el servicio cuando solo necesitamos otra instancia de db parece un desperdicio (al igual que lo contrario, girar una nueva copia de db cuando realmente solo necesita una instancia de servicio web). Sin embargo, no conozco las limitaciones de MS SQL Server para esto.
Mi mayor preocupación es la implementación de MS SQL Server. Acoplando las instancias de solo lectura tan estrechamente a los servicios se siente mal. ¿Hay una mejor manera de hacer esto?
NOTA: pregunté esto sobre ingeniería de software y me señalaron aquí. Lo siento si este no es el SE apropiado.
Tampoco hay una etiqueta de MS SQL Server