Esta questão é um pouco antiga, quando a arquitetura orientada a serviços (doravante denominada "arquitetura SOA") ainda era muito popular. Atualmente, existem mais arquiteturas de microsserviços domésticas e menos arquiteturas SOA. Nos últimos anos, tem havido menos arquiteturas de microsserviços. Pode ser por causa da "redução de custos e aumento de eficiência" das empresas. Todos reinvestiram no abraço de uma arquitetura única…
Mas é inegável que a arquitetura SOA ainda tem seu lado avançado (já se passaram 27 anos desde que o Gartner Group propôs pela primeira vez o conceito de "arquitetura orientada a serviços" em 1996), e pode-se dizer que os microsserviços que se tornaram populares em nos últimos anos A arquitetura também é ampliada em sua base.
Meu entendimento da diferença entre a arquitetura SOA e a arquitetura de microsserviços é que a arquitetura SOA é adequada para sistemas grandes e complexos, o que pode melhorar a flexibilidade, escalabilidade e capacidade de reutilização do sistema. A arquitetura de microsserviços é adequada para rápido desenvolvimento e implantação de sistemas, o que pode melhorar a agilidade e a capacidade de manutenção do sistema. Outra frase mais fácil de entender é que a arquitetura SOA é distribuída com serviços independentes de “aplicação”, enquanto a arquitetura de microsserviços é distribuída com serviços independentes “funcionais”.
PS: Existem tantos sistemas grandes e complexos no mundo. Principalmente no mercado dos últimos anos, todo mundo tem uma ideia e quer entrar online o mais rápido possível para conquistar o mercado, e a arquitetura de microsserviços é sem dúvida a melhor escolha. Depois de se tornarem maiores e mais fortes, aqueles com grande força continuarão a se expandir cada vez mais, e aqueles com menos força poderão prestar serviços de forma independente, desde que primeiro façam fortuna…
Afastando-se, voltando ao assunto.
Hmm... Embora a arquitetura SOA nunca tenha sido usada, a arquitetura de microsserviços é frequentemente usada, mas com o aumento dos microsserviços, a governança de serviços é um grande problema (há muitas armadilhas nela, e os deuses online deveriam ter dito isso ), então acho que se uma empresa é uma empresa start-up e a escala da empresa pode gradualmente se desenvolver positivamente, então a estrutura de negócios deve evoluir assim:
-
Arquitetura monolítica : neste momento, todo o sistema é um aplicativo, usando diretamente a versão comunitária dos dados de inventário do banco de dados relacional MySQL e usando Redis como cache e uma fila de mensagens simples.
Depois disso, compre um ou dois servidores em nuvem para hospedagem e use o Nginx como proxy reverso para implantar diretamente nele um nível de alta disponibilidade, que basicamente pode atender aos requisitos.
O fluxo de capital na fase inicial do empreendedorismo é mais importante e não há necessidade de adicionar demasiadas pilhas de tecnologia para complicar o sistema. Tem que pensar que tem muita coisa que precisa ser feita além do sistema, como promoção, operação, planejamento, etc., são os lugares onde o dinheiro vai ser queimado. Desde que o ajuste do desempenho da infra-estrutura seja bem feito, a forma de conquistar rapidamente o mercado é rei (a maioria das empresas iniciantes estão sempre congeladas nesta fase, sejam problemas técnicos ou de gestão).
-
Arquitetura de serviço : Quando UV, PV e outros dados surgirem, 99% sentirão que os recursos não são suficientes, o desempenho irá deteriorar-se, a rede irá flutuar... e acontece de ganhar algum dinheiro, e o coração começará a bater coceira. Assim que encontrar um problema, você pensará em expansão horizontal =_= ||
Não é que essa abordagem esteja errada. Afinal, do ponto de vista empresarial, ainda há muitas coisas que precisam ser prestadas atenção no desenvolvimento da empresa. Basta gastar dinheiro para resolvê-las. O tempo é o custo. Mas do ponto de vista técnico, essa abordagem pode ser feita em caso de emergência, mas depois que a pressão for aliviada, ainda precisamos revisar o jogo para encontrar a causa raiz.
Na verdade, este é o melhor momento para classificar e revisar o código de forma abrangente para ver quais outros problemas podem ser resolvidos juntos. É melhor que o problema de desempenho possa ser resolvido através do reparo de código.Se não for possível, podemos apenas considerar a divisão de alguns serviços que consomem recursos em várias instâncias e usar a carga para criar uma arquitetura orientada a serviços com recursos inclinados.
De modo geral, você pode "lutar por mais alguns anos" através dos métodos acima, mas se ainda ocorrerem gargalos de desempenho, você realmente precisa investigar em profundidade (afinal, a combinação de volume de negócios, visitas, dados de tráfego e outros dados pode inferir aproximadamente a situação de pressão. A análise de despejo deve ser capaz de conhecer a ideia geral). Se não for um problema de processamento lógico, a alta probabilidade é o problema de desempenho de IO da estrutura de armazenamento.Se for esse o caso, você pode considerar adicionar NoSQL para processar dados não estruturados e usar algum MQ poderoso para realizar comunicação assíncrona entre serviços ( como: RabbitMQ, Kafka etc.).
Neste momento, não há necessidade de mudar completamente para uma arquitetura de microsserviços, porque o grau não é sério e não há necessidade de entrar em guerra. Mais uma coisa a acrescentar, no meu entendimento, apenas arquiteturas de serviços que seguem o modelo de referência SOA proposto pela IBM podem ser consideradas arquiteturas SOA. Infelizmente, as arquiteturas de serviço das empresas que encontrei até agora não podem ser chamadas de arquiteturas SOA. No máximo, elas fazem divisão horizontal de cluster devido a problemas de recursos...
-
Arquitetura de microsserviços : Quando a arquitetura de serviços não consegue atender aos requisitos de recursos, ela só pode ser analisada e desmontada posteriormente (alguns parceiros podem dizer que adicionar recursos é suficiente, mas os recursos precisam de "dinheiro", pense novamente no seu chefe, não posso continue adicionando a amostra de pesquisa, certo?), pessoalmente acho que podemos considerar duas etapas neste momento, a primeira etapa é limpar o código Shishan e a segunda etapa é o microsserviço.
Nesse momento, alguns amigos dirão: "Onde está o código da montanha de merda e o código ancestral tão fácil de limpar? Você acha que não custa nada limpar? " Na verdade, a revisão de código (revisão de código) não é feita quando há é um problema. Esta peça de execução regular deve ser incluída no trabalho. Atualmente, a nova versão do Gitlab possui uma função de revisão de código, e outras ferramentas como SonarQube e Spotbugs podem fazer bem a varredura automática de código, mas isso ainda depende da situação de cada empresa, mas não é um grande problema de implementação.
A essa altura, os dados devem ter uma certa magnitude. Para cálculo de dados em tempo real, você não precisa usar MySQL para suportá-lo. Você pode considerar usar a estrutura de processamento de fluxo Apache Flink para fazer isso (é bom usá-lo). Em termos de operação e manutenção, inicialmente você pode usar alguns contêineres virtualizados, como Docker e K3s, etc., e o uso de ferramentas de orquestração e gerenciamento será muito eficaz.
-
Arquitetura de microsserviços supergrandes : nunca fui exposto a esse nível de arquitetura. Pelo que eu sei, o número de microsserviços nesta escala ultrapassou centenas ou mesmo milhares e adotará expansão horizontal em larga escala de dezenas de centenas de instâncias para serviços essenciais, com autonomia de serviço, recursos de autorrecuperação e nuvem -sistema de arquitetura nativa etc. Nunca tive contato com isso, então não me atrevo a dizer isso casualmente...
Depois disso, deveria haver modelos arquitetônicos como arquitetura responsiva, arquitetura sem servidor, computação de ponta, etc., mas as capacidades limitadas ainda não atingiram esses níveis.