système de gestion d'arrière-plan springboot-plus v2.7.18

springboot-plus est un système backend de gestion basé sur SpringBoot 2, qui comprend la gestion des utilisateurs, la gestion de l'organisation, la gestion des rôles, la gestion des points de fonction, la gestion des menus, l'attribution des autorisations, l'attribution des autorisations de données, la génération de code et d'autres fonctions.

Le système est basé sur la technologie Spring Boot2 et le front-end utilise Layui2. La base de données utilise MySQL comme exemple et est théoriquement une plate-forme multi-bases de données.

Plus est une plate-forme de développement rapide Java adaptée aux systèmes monolithiques et au fractionnement du système. Elle peut également être transformée en une plate-forme de microservices (j'en avais créé une, mais je pensais que Plus devrait se concentrer sur le cœur du système au lieu de simplement empiler des fonctions. donc j'ai abandonné)

Voici les différences entre les systèmes monolithiques, les petits systèmes et les microservices

Le système monolithique est une méthode de conception de système courante, et c'est également la méthode de conception la plus importante des dix dernières années. Toutes les fonctions d'un système unique sont regroupées dans un seul projet, regroupées dans un package de guerre et déployées. Cela présente les avantages évidents suivants :

1. La méthode de développement d'un système unique est simple. Lorsque nous apprenons la programmation dès le début, il suffit aux développeurs de se concentrer sur le développement du projet en cours.

2. Facile à modifier. Si vous devez modifier une fonction, c'est très pratique. Il vous suffit de modifier le code dans le cadre d'un projet.

3. Le test est simple. Il n'est pas nécessaire de prendre en compte d'autres systèmes lors du test d'un seul système et d'éviter les différents appels REST et MQ mentionnés dans le deuxième volume de ce livre.

4. Le déploiement est également très simple : il n'est pas nécessaire de prendre en compte la relation avec d'autres systèmes, il suffit de conditionner le package war et de le déployer sur le serveur Web.

5. Les performances sont faciles à étendre et une application peut être déployée sur plusieurs serveurs via Nginx.

Avec le développement des affaires et la reconstruction, il existe de plus en plus de systèmes monolithiques. Lors du développement d'un énorme système monolithique, il y aura les inconvénients suivants :

1. Le système unique est énorme et il devient de plus en plus difficile de comprendre le système unique. Les petits changements impliquent un large éventail d'aspects, ce qui oblige l'équipe de développement à être prudente et la vitesse de développement deviendra de plus en plus lente. De plus, le démarrage d’un grand système peut prendre 3 minutes ou plus.

2. Plusieurs fonctions sont développées sur le même système, ce qui entraîne des tests de plus en plus lents. Par exemple, les tests doivent être planifiés et les tests en série.

3. Si vous souhaitez mettre à niveau la technologie d'un seul système, le coût sera très élevé. S'il s'agit d'un petit système, vous pouvez choisir un petit système à essayer en premier. Il est presque impossible de mettre à niveau techniquement un seul grand système.

4. Toutes les fonctions d'un seul système s'exécutent dans la même JVM et les fonctions s'influenceront mutuellement. Par exemple, une fonction qui compte les numéros de page des documents Word téléchargés consomme beaucoup de CPU. Par conséquent, l'ensemble du système sera temporairement désactivé. indisponible du fait de l'appel à la fonction statistiques, le phénomène d'animation suspendue apparaît.

Par conséquent, lors de la conception d’un système, de plus en plus d’architectes envisagent de diviser le système en plusieurs petits systèmes individuels, voire en microservices. Pour les applications d'entreprise traditionnelles, il est plus approprié de les diviser en petits systèmes. Pour les systèmes Internet, il est plus approprié d'utiliser des microservices.

1. Les systèmes informatiques traditionnels utilisent encore essentiellement une base de données, tandis que les microservices préconisent un service et une base de données.

2. Les systèmes informatiques traditionnels ont rarement besoin d'appeler d'autres services de modules. Les systèmes informatiques traditionnels connectent d'autres sous-systèmes via des flux de travail. Les microservices de commerce électronique interagissent via RPC et d'autres méthodes, qui sont un protocole léger. Les systèmes informatiques traditionnels peuvent également interagir avec d'autres systèmes (non-sous-systèmes) via SOA et JMS, en utilisant des protocoles lourds.

3. Les microservices ont des exigences très élevées en matière d'infrastructure système, comme la gouvernance des microservices, les bibliothèques élastiques, etc. Seuls les systèmes de commerce électronique disposent des ressources humaines et matérielles nécessaires pour faire ce genre de choses, tandis que les systèmes informatiques traditionnels, même s'ils ont des poches profondes. , ne disposent pas pour le moment des capacités des microservices comme les infrastructures informatiques.

Par conséquent, pour la plupart des applications informatiques traditionnelles, il n’y a aucun risque technique à diviser un seul petit système et il s’agit d’une architecture qui peut être mise en œuvre immédiatement. Ce qui suit est l'architecture physique d'un système unique après la division

Pour les utilisateurs, l'accès à différentes fonctions de menu permettra de localiser différents sous-systèmes et de fournir des services.