springboot-plus é um sistema de back-end de gerenciamento baseado em SpringBoot 2, que inclui gerenciamento de usuários, gerenciamento de organização, gerenciamento de funções, gerenciamento de pontos de função, gerenciamento de menu, alocação de permissão, alocação de permissão de dados, geração de código e outras funções.
O sistema é baseado na tecnologia Spring Boot2 e o front-end usa Layui2. O banco de dados usa MySQL como exemplo e, teoricamente, é uma plataforma de banco de dados cruzado.
Plus é uma plataforma de desenvolvimento rápido Java adequada para sistemas monolíticos e divisão de sistema. Ela também pode ser transformada em uma plataforma de microsserviços (eu costumava fazer uma, mas achei que Plus deveria focar no núcleo do sistema em vez de simplesmente empilhar funções, então eu desisti)
A seguir estão as diferenças entre sistemas monolíticos, pequenos sistemas e microsserviços
O sistema monolítico é um método comum de projeto de sistema e também o método de projeto mais importante nos últimos dez anos. Todas as funções de um único sistema estão em um projeto, empacotadas em um pacote de guerra e implantadas. Isso tem os seguintes benefícios óbvios:
1. O método de desenvolvimento do sistema único é simples. Quando aprendemos a programar desde o início, é o sistema único completo. Os desenvolvedores só precisam se concentrar no desenvolvimento do projeto atual.
2. Fácil de modificar. Se você precisar modificar alguma função, é muito conveniente modificar o código dentro do escopo do projeto.
3. O teste é simples. Não há necessidade de considerar outros sistemas ao testar um único sistema e evitar as várias chamadas REST e MQ mencionadas no segundo volume deste livro.
4. A implantação também é muito fácil: não há necessidade de considerar o relacionamento com outros sistemas, basta empacotar o pacote war e implantá-lo no servidor web
5. O desempenho é fácil de expandir e um aplicativo pode ser implantado em vários servidores por meio do Nginx.
Com o desenvolvimento e reconstrução de negócios, existem cada vez mais sistemas monolíticos. Ao desenvolver um enorme sistema monolítico, haverá as seguintes desvantagens:
1. O sistema único é enorme e está se tornando cada vez mais difícil entendê-lo. Pequenas mudanças envolvem uma ampla gama de aspectos, fazendo com que a equipe de desenvolvimento seja cautelosa e a velocidade de desenvolvimento se torne cada vez mais lenta. Além disso, iniciar um sistema único grande pode levar 3 minutos ou mais.
2. Múltiplas funções são desenvolvidas no mesmo sistema único, resultando em testes cada vez mais lentos. Por exemplo, os testes devem ser agendados e os testes em série.
3. Se você deseja atualizar a tecnologia de um único sistema, o custo será muito alto. Se for um sistema pequeno, você pode escolher um sistema pequeno para experimentar primeiro. É quase impossível atualizar tecnicamente um único grande sistema.
4. Todas as funções de um único sistema são executadas na mesma JVM e as funções afetarão umas às outras. Por exemplo, uma função que conta o número de páginas de documentos Word carregados consome muita CPU, portanto, todo o sistema será temporariamente. indisponível devido à chamada à função estatística, aparece o fenômeno da animação suspensa.
Portanto, ao projetar um sistema, cada vez mais arquitetos considerarão dividir o sistema em vários pequenos sistemas individuais ou até mesmo em microsserviços. Para aplicações empresariais tradicionais, é mais apropriado dividi-los em pequenos sistemas. Para sistemas de Internet, é mais apropriado usar microsserviços.
1. Os sistemas de TI tradicionais ainda usam essencialmente um banco de dados, enquanto os microsserviços defendem um serviço e um banco de dados.
2. Os sistemas de TI tradicionais raramente precisam chamar outros serviços de módulo. Os sistemas de TI tradicionais conectam outros subsistemas por meio de fluxos de trabalho. Os microsserviços de comércio eletrônico interagem por meio de RPC e outros métodos, que é um protocolo leve. Os sistemas de TI tradicionais também podem interagir com outros sistemas (não subsistemas) através de SOA e JMS, utilizando protocolos pesados.
3. Os microsserviços têm requisitos muito elevados em infraestrutura de sistema, como governança de microsserviços, bibliotecas elásticas, etc. Somente os sistemas de comércio eletrônico têm mão de obra e recursos materiais para fazer esse tipo de coisa, enquanto os sistemas de TI tradicionais, mesmo que tenham bolsos fundos , não possuem os recursos de microsserviços por enquanto, como serviços de infraestrutura de TI.
Portanto, para a maioria das aplicações de TI tradicionais, não há risco técnico em dividir um único sistema pequeno e é uma arquitetura que pode ser implementada imediatamente. A seguir está a arquitetura física de um único sistema após a divisão
Para os usuários, o acesso a diferentes funções de menu localizará diferentes subsistemas e fornecerá serviços.