cenário de negócios real
- Com a popularidade dos frameworks de microsserviços (SpringCloud, SpringCloud Alibaba), parece que estou com vergonha de sair para uma entrevista sem escrever código na arquitetura de microsserviços.
- Nas duas empresas em que trabalhei recentemente, ambas adotaram a arquitetura de microsserviços, e a equipe de P&D não passava de 20 pessoas, o que é azedo e gostoso.
- No caso de negócios pouco claros no estágio inicial, para acompanhar a nova onda de tecnologia, adotei resolutamente a arquitetura de microsserviços (parece que não sei o que escolher).
A arquitetura de microsserviços é legal?
- A existência é razoável, na minha opinião no momento, mas o uso de meus próprios microsserviços realmente não é muito bom.
- Alguns negócios foram divididos à força em dois serviços, mas foi descoberto no desenvolvimento posterior que eles eram na verdade um negócio, e a demolição forçada foi eliminada.
- Na verdade é uma consulta simples, na empresa precisa puxar muitos serviços para ligar, o link é muito longo e o grau de acoplamento é alto. . .
- A consulta entre bancos de dados também não é fácil de lidar. Claro, usamos o melhor método (redundância). Claro, a sincronização é um grande problema.
Desafios que os microsserviços precisam enfrentar
Consulta cruzada de banco de dados
Sob a arquitetura de microsserviços, as informações do usuário (cenários de negócios específicos, nome real, apelido do WeChat etc.) são chamadas por vários sistemas. Neste momento, como projetar o banco de dados e como interagir com os serviços.
- A mais simples: redundância. Desvantagens: Se o sistema principal mudar, como sincronizar todos os subsistemas
- Preparado com antecedência: sincronizado com o subsistema com antecedência. Desvantagens: A probabilidade de sincronização em tempo real é pequena, o tempo é assíncrono e síncrono e o desempenho em tempo real do subsistema não é alto
- Tempo real: chamadas múltiplas, aquisição em tempo real. Desvantagens: grande quantidade e baixa eficiência
- Informação de referência
transação distribuída
- Transformação de transações simples locais para transações multissistema distribuídas
Solução fortemente consistente:
- Protocolo de Compromisso da Fase Dois
- Protocolo de Compromisso Trifásico
solução eventualmente consistente
- Modo TCC
- modo de compensação
- Documento de referência de padrão de evento confiável
, beneficia muito
Microsserviços - a existência é razoável
lógica clara
- Esse recurso é gerado pelo requisito de responsabilidade única dos microsserviços. Um microsserviço que é responsável apenas por um negócio muito claro é definitivamente mais fácil de entender logicamente do que um sistema complexo.
- A lógica clara traz a manutenibilidade dos microsserviços.Quando modificamos um microsserviço, é mais fácil analisar o impacto que a modificação terá, de modo a garantir a qualidade da modificação por meio de testes completos.
Simplifique a implantação
- Em um sistema monolítico, desde que uma linha de código seja modificada, todo o sistema precisa ser reconstruído, testado e implantado. Os microsserviços podem implantar um microsserviço.
- Um dos benefícios disso é que podemos alterar nosso software com mais frequência e lançar novas funções rapidamente com custos de integração muito baixos.
Escalável
- O método para lidar com o crescimento dos negócios do sistema geralmente adota direção horizontal (Scale out) ou vertical (Scale up) para expandir. Em um sistema distribuído, a expansão geralmente é usada para expansão. Como funções diferentes enfrentarão mudanças de carga diferentes, um sistema que usa microsserviços tem melhor escalabilidade do que um sistema monolítico.
- referências
Meu sistema deve usar microsserviços?
- Os microsserviços significam a divisão do sistema e um grande número de middleware será introduzido para a colaboração do sistema.
- Não é recomendado usar microsserviços quando o negócio não está claro e o negócio ainda está conduzindo o sistema.
- Após o sistema estar em execução por um período de tempo, o negócio se torna maduro e os membros da equipe estão familiarizados com o negócio e conhecem várias armadilhas antes de dividir o serviço.
- Divida os microsserviços até que a lógica estável possa ser identificada, para evitar o retrabalho causado pelo reparticionamento devido a limites pouco claros
- A estrutura que sai do negócio está jogando hooligans, e é um tipo muito sem vergonha. . .