sistema de gestión de fondo springboot-plus v2.7.18

springboot-plus es un sistema backend de administración basado en SpringBoot 2, que incluye administración de usuarios, administración de organizaciones, administración de roles, administración de puntos de función, administración de menús, asignación de permisos, asignación de permisos de datos, generación de código y otras funciones.

El sistema se basa en la tecnología Spring Boot2 y el front-end utiliza Layui2. La base de datos utiliza MySQL como ejemplo y, en teoría, es una plataforma entre bases de datos.

Plus es una plataforma de desarrollo rápido de Java adecuada para sistemas monolíticos y división de sistemas. También se puede transformar en una plataforma de microservicios (solía crear una, pero sentí que Plus debería centrarse en el núcleo del sistema en lugar de simplemente apilar funciones). así que me di por vencido)

Las siguientes son las diferencias entre sistemas monolíticos, sistemas pequeños y microservicios.

El sistema monolítico es un método de diseño de sistemas común y también es el método de diseño más importante de los últimos diez años. Todas las funciones de un único sistema están en un proyecto, empaquetadas en un paquete de guerra y desplegadas. Esto tiene los siguientes beneficios obvios:

1. El método de desarrollo del sistema único es simple. Cuando aprendemos a programar desde el principio, el desarrollador solo necesita concentrarse en desarrollar el proyecto actual.

2. Fácil de modificar Si necesita modificar alguna función, es muy conveniente. Solo necesita modificar el código dentro del alcance del proyecto.

3. La prueba es simple. No es necesario considerar otros sistemas al probar un solo sistema y evitar las diversas llamadas REST y MQ mencionadas en el segundo volumen de este libro.

4. La implementación también es muy fácil: no es necesario considerar la relación con otros sistemas, simplemente empaquete el paquete war e impleméntelo en el servidor web.

5. El rendimiento es fácil de ampliar y una aplicación se puede implementar en varios servidores a través de Nginx.

Con el desarrollo y la reconstrucción empresarial, hay cada vez más sistemas monolíticos. Al desarrollar un sistema monolítico enorme, se presentarán las siguientes desventajas:

1. El sistema único es enorme y cada vez es más difícil entender el sistema único. Los pequeños cambios involucran una amplia gama de aspectos, lo que hace que el equipo de desarrollo sea cauteloso y la velocidad de desarrollo sea cada vez más lenta. Además, iniciar un sistema único grande puede tardar 3 minutos o más.

2. Se desarrollan múltiples funciones en el mismo sistema único, lo que resulta en pruebas cada vez más lentas. Por ejemplo, las pruebas deben programarse y realizarse en serie.

3. Si desea actualizar la tecnología de un solo sistema, el costo será muy alto. Si se trata de un sistema pequeño, puede elegir un sistema pequeño para probar primero. Es casi imposible actualizar técnicamente un único sistema grande.

4. Todas las funciones de un solo sistema se ejecutan en la misma JVM y las funciones se afectarán entre sí. Por ejemplo, una función que cuenta los números de página de los documentos de Word cargados consume una gran cantidad de CPU, por lo que todo el sistema se ejecutará temporalmente. no disponible debido a la llamada a la función de estadísticas, aparece el fenómeno de la animación suspendida.

Por lo tanto, al diseñar un sistema, cada vez más arquitectos considerarán dividir el sistema en múltiples sistemas pequeños individuales o incluso microservicios. Para las aplicaciones empresariales tradicionales, es más apropiado dividirlas en sistemas pequeños. Para los sistemas de Internet, es más apropiado utilizar microservicios.

1. Los sistemas de TI tradicionales siguen utilizando esencialmente una base de datos, mientras que los microservicios abogan por un servicio y una base de datos.

2. Los sistemas de TI tradicionales rara vez necesitan llamar a otros servicios de módulos. Los sistemas de TI tradicionales conectan otros subsistemas a través de flujos de trabajo. Los microservicios de comercio electrónico interactúan a través de RPC y otros métodos, que es un protocolo ligero. Los sistemas de TI tradicionales también pueden interactuar con otros sistemas (que no son subsistemas) a través de SOA y JMS, utilizando protocolos pesados.

3. Los microservicios tienen requisitos muy altos en cuanto a la infraestructura del sistema, como la gobernanza de microservicios, bibliotecas elásticas, etc. Solo los sistemas de comercio electrónico tienen la mano de obra y los recursos materiales para hacer este tipo de cosas, mientras que los sistemas de TI tradicionales, incluso si tienen mucho dinero. , no tienen las capacidades de los microservicios por el momento como infraestructura de TI.

Por lo tanto, para la mayoría de las aplicaciones de TI tradicionales, no existe ningún riesgo técnico al dividir un único sistema pequeño y es una arquitectura que se puede implementar de inmediato. La siguiente es la arquitectura física de un solo sistema después de dividirlo.

Para los usuarios, acceder a diferentes funciones del menú ubicará diferentes subsistemas y brindará servicios.