система управления фоном Springboot-Plus v2.7.18

Springboot-plus — это серверная система управления, основанная на SpringBoot 2, которая включает в себя управление пользователями, управление организацией, управление ролями, управление функциональными точками, управление меню, распределение разрешений, распределение разрешений на данные, генерацию кода и другие функции.

Система основана на технологии Spring Boot2, а интерфейс использует Layui2. В качестве примера база данных использует MySQL и теоретически является межбазовой платформой.

Plus — это платформа быстрой разработки Java, подходящая для монолитных систем и разделения систем. Ее также можно преобразовать в платформу микросервисов (я раньше создавал такую, но чувствовал, что Plus должен сосредоточиться на ядре системы, а не просто накладывать функции). поэтому я сдался)

Ниже приведены различия между монолитными системами, небольшими системами и микросервисами.

Монолитная система — это распространенный метод проектирования систем, а также самый важный метод проектирования за последние десять лет. Все функции единой системы собраны в одном проекте, упакованы в боевой пакет и развернуты. Это имеет следующие очевидные преимущества:

1. Метод разработки единой системы прост. Когда мы изучаем программирование с самого начала, разработчикам остается только сосредоточиться на разработке текущего проекта.

2. Легко изменить. Если вам нужно изменить какую-либо функцию, это очень удобно. Вам нужно изменить код только в рамках проекта.

3. Тест прост. Нет необходимости учитывать другие системы при тестировании одной системы и избегать различных вызовов REST и MQ, упомянутых во втором томе этой книги.

4. Развертывание также очень простое: нет необходимости учитывать взаимосвязь с другими системами, достаточно просто упаковать военный пакет и развернуть его на веб-сервере.

5. Производительность легко расширить, а приложение можно развернуть на нескольких серверах через Nginx.

По мере развития и реконструкции бизнеса монолитных систем становится все больше. При разработке огромной монолитной системы будут возникать следующие недостатки:

1. Единая система огромна, и становится все труднее понять ее. Небольшие изменения затрагивают широкий спектр аспектов, что заставляет команду разработчиков проявлять осторожность, а скорость разработки становится все медленнее и медленнее. Кроме того, запуск большой одиночной системы может занять 3 минуты и более.

2. В одной системе разрабатывается несколько функций, что приводит к все более медленному тестированию. Например, тестирование должно быть запланированным и последовательным.

3. Если вы хотите обновить технологию одной системы, стоимость будет очень высокой. Если это небольшая система, вы можете сначала попробовать небольшую систему. Технически модернизировать одну большую систему практически невозможно.

4. Все функции одной системы выполняются в одной JVM, и функции влияют друг на друга. Например, функция, подсчитывающая номера страниц загруженных текстовых документов, потребляет много ресурсов ЦП. недоступен из-за вызова функции статистики, появляется явление анабиоза.

Поэтому при проектировании системы все больше и больше архитекторов рассматривают возможность разделения системы на несколько отдельных небольших систем или даже микросервисов. Для традиционных корпоративных приложений более целесообразно разбивать их на небольшие системы. Для Интернет-систем более целесообразно использовать микросервисы. Это связано с тем, что.

1. Традиционные ИТ-системы, по сути, по-прежнему используют базу данных, тогда как микросервисы поддерживают один сервис и одну базу данных.

2. Традиционным ИТ-системам редко требуется вызывать другие сервисы модулей. Традиционные ИТ-системы соединяют другие подсистемы посредством рабочих процессов. Микросервисы электронной коммерции взаимодействуют посредством RPC и других методов, которые представляют собой облегченный протокол. Традиционные ИТ-системы также могут взаимодействовать с другими системами (не подсистемами) через SOA и JMS, используя тяжеловесные протоколы.

3. Микросервисы предъявляют очень высокие требования к системной инфраструктуре, такой как управление микросервисами, эластичные библиотеки и т. д. Только системы электронной коммерции имеют человеческие и материальные ресурсы для выполнения подобных задач, в то время как традиционные ИТ-системы, даже если у них глубокие карманы. , пока не имеют возможностей микросервисов, таких как сервисы.

Таким образом, для большинства традиционных ИТ-приложений нет технического риска при разделении одной небольшой системы, и эту архитектуру можно реализовать немедленно. Ниже представлена ​​физическая архитектура единой системы после разделения.

Для пользователей доступ к различным функциям меню позволит найти различные подсистемы и предоставить услуги.