Rompiendo la aplicación ASP .NET MVC en microservicios

7

Tengo una gran aplicación ASP .NET MVC que consta de varios widgets diferentes. Todos muestran algún tipo de datos relacionados con los mercados de valores, pero en realidad están bastante separados unos de otros. Me gustaría dividir la gran aplicación monolítica en varios servicios más pequeños que deberían ser más fáciles de mantener.

Sería bastante simple si solo tuviera el código del lado del servidor escrito en C #, pero en realidad también tengo bastantes componentes de javascript y algunos estilos y otros recursos. No sé dónde se deben poner. Desde la perspectiva de la separación, si algunos archivos javascript solo son utilizados por un widget específico, deberían ser parte de su servicio. Por otro lado, no sé cómo integrar posteriormente todos los widgets y sus recursos, especialmente cuando puede haber algunos scripts comunes utilizados por todos los componentes.

Hasta ahora he tenido dos ideas, ninguna de las cuales parece ideal:

  1. Separe solo el código del lado del servidor y deje todos los componentes del lado del cliente en un proyecto común. La integración, la minimización y la administración de Js serían más fáciles, pero los desarrolladores aún tendrían que trabajar en dos proyectos diferentes al actualizar un servicio específico.
  2. Cree paquetes nuget para cada microservicio con código del lado del servidor y del cliente. ¿Qué pasa con los scripts comunes y los archivos que dependen de ellos? Si hiciera un cambio importante en la infraestructura común, necesitaría actualizar manualmente todo el código dependiente. Sería mucho más difícil actualizar los archivos cuando todos residen en el mismo proyecto.

¿Hay mejores soluciones?

    
pregunta syntax_error 08.02.2015 - 09:30

2 respuestas

5

Separaría solo el código del lado del servidor y dejaría todos los componentes del lado del cliente en un proyecto común. No me molesta su afirmación de que los usuarios tendrían que trabajar en múltiples proyectos; Cada solución de Visual Studio en la que he trabajado tiene múltiples proyectos, y algunos tienen muchos.

La única vez que crearía paquetes de Nuget sería si está utilizando los microservicios en varias soluciones.

    
respondido por el Robert Harvey 08.02.2015 - 20:16
2

Podría considerar fusionar su lógica de UI con la lógica del lado del servidor y segmentar los resultados en contextos limitados que encapsulan microservicios. Aquí hay un tutorial para comenzar .

Aquí está el resumen:

La lógica de la interfaz de usuario debe centrarse en representar, pero no administrar, los datos. La migración de la lógica de la interfaz de usuario al servidor le permite agrupar todo su conjunto de características dentro del mismo nivel de aplicación. Resumen y cubren suficientemente la lógica de las características del núcleo en términos de pruebas unitarias. Esto debería producir un conjunto bien definido de API que sus microservicios puedan aprovechar. Luego divida el conjunto de características en microservicios.

Crea una plantilla de microservicio reutilizable. Esta debe ser una estructura de placa de caldera que permita la rápida implementación de microservicios. La lógica de la función principal debe estar alojada en las plantillas de microservicio.

Implemente el concepto de agrupación de colas para garantizar una entrega de mensajes confiable. Este es un concepto más avanzado para garantizar la entrega confiable de mensajes. Recuerde: es probable que aproveche un bus de servicio para establecer una interfaz con sus microservicios.

    
respondido por el Paul Mooney 01.09.2015 - 14:53

Lea otras preguntas en las etiquetas