Como escolher a arquitetura de microsserviços? Faça seu sistema funcionar de forma mais estável

Você já encontrou isso? O sistema estava bem quando ficou online, mas travou quando havia muitos usuários. Adicione um novo recurso e todo o sistema deverá ser testado novamente. A equipe queria mudar alguma coisa, mas também ocorreram problemas em outros lugares. Para ser honesto, muitas equipes estão enfrentando esse tipo de problema – a arquitetura que escolheram originalmente agora está amarrada.

O que fazer? Microsserviços parecem uma boa ideia, mas como fazer isso especificamente?

Desmontar ou não desmontar? isso é um problema

Algumas equipes simplesmente empilham todo o código e acham que é simples assim. Na verdade, o desenvolvimento foi rápido no início, mas depois de meio ano o código ficou uma bagunça. Ninguém se atreve a se mover casualmente porque não sabe onde isso será afetado.

Outras equipes estão muito divididas. Uma função simples precisa ser chamada em cinco ou seis serviços e, para verificar o problema, é necessário observar três ou quatro painéis de monitoramento. A implantação é ainda mais problemática. O que poderia ter sido feito num dia exige agora a coordenação de várias equipas.

É como construir Lego. Se todas as peças estiverem coladas, você terá que desmontar todo o prédio se quiser substituir as janelas. Mas se cada parte for pequena demais para ser vista, suas mãos ficarão doloridas ao montá-la e será fácil perdê-la.

Então, como desmontá-lo?

Encontre aquele ponto "certo"

Uma boa arquitetura de microsserviços consiste, na verdade, em encontrar um equilíbrio. Deve ser independente o suficiente para permitir que a equipe se desenvolva de forma independente, mas compacta o suficiente para não complicar coisas simples.

Como encontrar esse ponto? Veja o negócio em si. Se um recurso mudar com frequência, deverá ser um serviço separado. Se um conjunto de dados sempre aparece junto, eles deveriam. Por exemplo, se as informações do usuário, desde o registro até o login e as informações pessoais, forem divididas em três serviços, a interface terá que ser ajustada três vezes cada vez que a página do usuário for exibida. Por que se preocupar?

Mas o sistema de pedidos é diferente. Fazer um pedido é um processo, o pagamento é outro e o envio é outro. Eles são completamente separáveis ​​porque mudam em frequências diferentes e têm equipes diferentes responsáveis ​​por eles.

Você sabia? Às vezes o mais difícil não é a tecnologia, mas a determinação de desvendar o código que está emaranhado. É como uma garagem organizada há muitos anos. No começo sempre pensei “isso pode ser útil”, mas no final relutei em jogar qualquer coisa fora. Mas depois de realmente organizá-lo, você descobrirá que o espaço é maior e é mais fácil encontrar as coisas.

Deixe os militares conversarem entre si.

Depois de desmontado, como podemos nos comunicar? Existem duas formas comuns: uma é a chamada síncrona, como fazer uma ligação, eu te ligo, você tem que atender imediatamente; a outra são mensagens assíncronas, como enviar um e-mail, eu enviei e você pode cuidar disso conforme sua conveniência.

As chamadas síncronas são simples e diretas, adequadas para cenários que exigem resposta imediata. Por exemplo, ao verificar o saldo de um usuário, você não pode esperar cinco minutos para que os resultados sejam exibidos, certo? Mas há um problema: se o serviço chamado travar, o chamador também ficará preso. É como se fosse um dominó, um cai e depois o outro cai.

Mensagens assíncronas são mais flexíveis. Os serviços se comunicam por meio de filas de mensagens e o remetente não precisa esperar que o destinatário termine o processamento. Mesmo que o serviço de recebimento esteja temporariamente indisponível, a mensagem ficará aguardando na fila sem afetar o remetente. É como ir ao correio enviar uma carta. Você pode simplesmente colocar a carta na caixa de correio e sair sem esperar o carteiro buscá-la.

Mas a assincronia tem um preço. O sistema se torna mais complexo, gerenciando filas de mensagens e lidando com mensagens perdidas ou duplicadas. Às vezes, você até precisa de serviços especializados para rastrear o destino de um processo de negócios.

Qual escolher? Depende de quanto atraso seu negócio pode tolerar e de quanta complexidade você pode aceitar. Não existe bem ou mal absoluto, apenas se é adequado ou não.

O que fazer com os dados? Dividir ou não dividir

O armazenamento de dados é talvez o problema mais difícil em microsserviços. A abordagem tradicional é que todos os serviços compartilhem um banco de dados. Simples, certo? Mas o problema também está aqui. Depois que a estrutura do banco de dados for alterada, todos os serviços poderão ser afetados. Para piorar a situação, os serviços serão acoplados implicitamente através do banco de dados - se eu alterar um campo, como saber se ele está sendo usado?

O estado ideal dos microsserviços é que cada serviço tenha seu próprio banco de dados. Dessa forma, os serviços são verdadeiramente desacoplados e as alterações na estrutura do banco de dados de um serviço não afetarão outros serviços. Mas aí vem o problema: os dados empresariais estão naturalmente relacionados. O pedido precisa conhecer as informações do usuário e a logística precisa conhecer os detalhes do produto. Como sincronizar esses dados?

Existem dois métodos comuns. Uma delas é obter os dados necessários por meio de API entre serviços, como ir à casa de um vizinho para pedir algo emprestado. A vantagem é que os dados estão sempre atualizados, mas a desvantagem é que o desempenho do sistema pode ser afetado se a cadeia de chamadas for longa.

A outra é a replicação de dados, onde cada serviço armazena uma cópia dos dados de que necessita. Assim como você tem ferramentas em casa, eu também compro um conjunto com as mesmas ferramentas. Dessa forma, não há necessidade de chamadas frequentes entre serviços, mas a sincronização de dados se tornou um novo problema – como garantir que os dados em minhas mãos sejam consistentes com os seus?

potênciaAo ajudar os clientes a projetar a arquitetura, geralmente recomendamos uma solução híbrida: os dados principais são independentes e os dados compartilhados são sincronizados por meio de eventos. Quando as informações do usuário são atualizadas, o serviço do usuário publicará um evento "O usuário atualizou" e outros serviços que prestam atenção a esse evento atualizarão seus próprios dados relacionados armazenados. Isso mantém a independência e garante a consistência dos dados.

Desafios de operação e manutenção – da complexidade à simplicidade

Os microsserviços são de fato mais complexos de implantar do que os aplicativos monolíticos. Imagine que no passado você só precisava iniciar um aplicativo, mas agora precisa iniciar uma dúzia ou até dezenas de serviços. E quanto ao monitoramento? Como verificar o registro? Como localizar rapidamente um problema quando algo dá errado?

É aqui que são necessárias boas ferramentas e processos. A tecnologia de conteinerização torna a implantação unificada. Cada serviço é empacotado em uma imagem de contêiner e é executado da mesma forma em qualquer ambiente. As ferramentas de orquestração ajudam você a gerenciar esses contêineres: reinicie automaticamente qualquer contêiner que falhe e expanda automaticamente quando o tráfego aumentar.

O monitoramento também é feito em camadas. Depende da saúde geral do sistema, bem como do desempenho de serviços individuais. O rastreamento de links é particularmente útil. Uma solicitação passa por cinco ou seis serviços. Você pode ver claramente quanto tempo gastou em cada serviço e em qual etapa travou.

A coleta de logs é igualmente importante. Os logs de todos os serviços são reunidos e pesquisados ​​na mesma interface. Caso contrário, quando ocorrer um problema, você deverá fazer login em sete ou oito servidores para verificar os logs, respectivamente. No momento em que o problema for verificado, o usuário já terá fugido.

Na verdade, a estrutura cresce

Dito tudo isso, você deve estar se perguntando: Qual padrão arquitetônico é o melhor?

A verdade é: não existe uma resposta padrão. A arquitetura mais adequada deve surgir do seu negócio real, em vez de copiar os projetos de outras pessoas.

No início, você pode começar com um aplicativo monolítico, mas deve organizar conscientemente o código por módulos de negócios. Quando um módulo realmente precisar ser desenvolvido de forma independente, divida-o em microsserviços. Essa evolução gradual é mais prática e menos arriscada do que projetar uma arquitetura de microsserviços perfeita desde o início.

potênciaA equipe já passou por muitas dessas jornadas. Desde o bloco inicial de código até a definição dos limites do serviço; desde scripts de implantação manual até pipelines automatizados; desde a confusão quando ocorrem problemas até a recuperação automática do sistema. Este processo é como podar uma árvore. Em vez de cortar todos os galhos de uma vez, você pode apará-los lentamente conforme necessário para fazer a árvore crescer mais saudável.

Arquitetura não são as linhas do desenho, mas o esqueleto que sustenta o funcionamento do negócio. Deve ser forte, mas não rígido; deve ser flexível, mas não solto. Quando você encontra esse equilíbrio, o sistema ganha vida – ele cresce, se adapta e permanece estável apesar das mudanças.

Não é isso que estamos perseguindo? Deixe a tecnologia realmente servir o negócio, em vez de permitir que o negócio se adapte à tecnologia. Quando a arquitetura não é mais um problema que o preocupa todos os dias, você pode se concentrar mais na própria criação de valor. Naquela época, você pode ter esquecido a existência da arquitetura – a melhor arquitetura é muitas vezes aquela que as pessoas não conseguem sentir.

Fundada em 2005,potênciatem se dedicado a um fabricante profissional de unidades de movimento compacto, com sede em Dongguan, província de Guangdong, China. Aproveitando inovações em tecnologia de acionamento modular, a Kpower integra motores de alto desempenho, redutores de precisão e sistemas de controle multiprotocolo para fornecer soluções de sistemas de acionamento inteligentes eficientes e personalizadas. A Kpower forneceu soluções profissionais de sistemas de acionamento para mais de 500 clientes empresariais em todo o mundo, com produtos que abrangem vários campos, como sistemas domésticos inteligentes, eletrônica automática, robótica, agricultura de precisão, drones e automação industrial.