Quando seu sistema começa a “tossir”: algumas reflexões aleatórias sobre a arquitetura de microsserviços Java

Lembro-me da última vez que conversei com um velho amigo, ele administrava uma pequena fábrica de equipamentos de automação. Naquela tarde, ele se apoiou no corrimão do segundo andar da oficina, apontou para uma fileira de braços robóticos sendo depurados abaixo e disse: “Olha, todo servo é muito obediente.

O cenário que ele descreveu pode ser familiar para você: um único aplicativo que foi usado por vários anos funcionou muito rápido no início, mas gradualmente ficou inchado. Cada vez que atualizo, fico apavorado, com medo de que o menor movimento afete todo o meu corpo. Novos recursos demoram para ficar online e a solução de problemas é como encontrar a saída em um labirinto. Os desenvolvedores da equipe gastam cada vez mais tempo remendando em vez de criar coisas novas.

É provavelmente por isso que mais e mais pessoas começaram a falar sobre microsserviços nos últimos anos.

Microsserviços não são “separação”, mas permitem que o sistema aprenda a “colaborar”

Imagine uma linha de produção em sua oficina. Se houver apenas uma chave mestre de controle para toda a linha e um equipamento falhar, toda a linha terá que parar. Mas e se cada equipamento – alimentação, montagem e inspeção – tivesse seu próprio sistema de controle independente, com peças e informações comunicadas através de interfaces claras entre eles? Quando um equipamento é mantido, outros equipamentos podem operar normalmente; quando um determinado link é atualizado, não há necessidade de desligar toda a linha.

O que a arquitetura de microsserviços Java faz são coisas semelhantes. Divida um grande aplicativo único em um conjunto de serviços pequenos e independentes. Cada serviço é construído em torno de funções de negócios específicas, usa seu próprio banco de dados e é implantado e dimensionado de forma independente. Eles conversam por meio de um mecanismo de comunicação leve (geralmente HTTP ou fila de mensagens).

Algumas pessoas podem perguntar: isso não é apenas dividir meu grande programa original em muitos programas pequenos? O que há de tão especial?

A diferença está na palavra “independente”. Em verdadeiros microsserviços, cada serviço pode ser desenvolvido, implantado e expandido de forma independente. Assim como aquele robô parafusador em sua oficina, você pode atualizar sua visão sozinho, sem precisar mexer na programação do robô de soldagem. O que esta independência traz é a resiliência do sistema como um todo.

Por que Java? E aqueles "mas" que precisam ser ditos

Java parece ser uma escolha natural neste campo. É maduro e possui um ecossistema rico. Do Spring Boot a várias cadeias de ferramentas nativas da nuvem, existem muitos suportes. Assim como a chave inglesa mais fácil de usar em sua caixa de ferramentas, ela pode não ser necessariamente a mais chamativa, mas você sabe que será confiável na maioria das situações.

Mas o caminho para os microsserviços nem sempre é fácil.

Após a divisão em serviços, a comunicação em rede tornou-se inevitável. Os serviços ligam entre si e, se não forem bem gerenciados, tornar-se-ão uma teia de aranha pouco clara. Um problema se espalha como uma onda, tornando seu rastreamento uma dor de cabeça. Há também consistência de dados – transações que poderiam ser tratadas em um banco de dados no passado podem agora envolver vários serviços. Como garantir que os dados sejam precisos?

Isso leva ao coração da arquitetura: o design. Os microsserviços não devem ser desmantelados por desmantelar; eles precisam de limites claros. É baseado na capacidade de negócios? Ou é baseado em contexto limitado em design orientado por domínio? Se você dividir isso de maneira muito grosseira, não poderá desfrutar da flexibilidade; se você dividir muito detalhadamente, a complexidade da operação e manutenção aumentará exponencialmente. Não há uma resposta padrão aqui. Assim como projetar uma linha de produção, depende do que você produz especificamente.

Alguns fragmentos de prática fragmentados e não lineares

Em relação à seleção de tecnologia, as pessoas costumam dizer “a certa é a melhor”. Isso é verdade, mas como saber se é adequado? Às vezes, você pode começar com um pequeno ponto. Não há necessidade de refatorar ambiciosamente todo o sistema desde o início. Escolha um módulo com limites relativamente claros e funções relativamente independentes e separe-o em um serviço independente. Veja como ele funciona quando implantado de forma independente e dimensionado de forma independente. Sinta as mudanças no processo CI/CD provocadas por isso. Experimente os ajustes necessários para monitoramento e coleta de logs.

É um pouco como depurar um servo motor recém-chegado. Você não chega e apenas conecta-o a toda a linha e o executa a toda velocidade. Primeiro você testará sua velocidade, torque e curva de resposta individualmente. Depois de descobrir seu temperamento, deixe-o integrar-se a todo o sistema.

Em termos de métodos de comunicação, as chamadas síncronas (como REST) ​​são simples e diretas, mas aumentarão o acoplamento; mensagens assíncronas (por meio de filas de mensagens) podem dissociar e melhorar a resiliência, mas a arquitetura e a depuração serão mais complexas. Não existem soluções mágicas, apenas compensações.

Quanto à implantação, a conteinerização (como o Docker) quase se tornou o padrão para microsserviços. Ele empacota o aplicativo e seu ambiente de execução para garantir que "ele possa ser executado em meu lugar e em seu lugar". Combinado com ferramentas de orquestração de contêineres, o serviço on-line, a reversão, a expansão e a contração podem se tornar tão intuitivos quanto o ajuste dos parâmetros do dispositivo.

Então, o que isso traz? uma breve pergunta e resposta

Pergunta: Qual é o sentido de percorrer todo esse caminho? Resposta: A imagem é que o sistema pode acompanhar as mudanças nos negócios. Hoje você pode precisar adicionar um novo canal de pagamento ao serviço de pedidos e amanhã poderá precisar conectar novos métodos de autenticação de identidade ao gerenciamento de usuários. Se todos forem códigos entrelaçados em um único corpo, cada alteração deverá ser feita com cuidado. Com um serviço independente, você pode ser mais focado e responsivo.

P: A estrutura da equipe mudará? Resposta: Tende a mudar de acordo. No passado, as equipes podiam ser divididas em equipes de front-end, back-end e de banco de dados. Agora é mais provável que seja dividido por áreas de negócios, como “equipe de pedidos” e “equipe de estoque”. Cada equipe tem maior autonomia sobre os serviços pelos quais é responsável, sendo responsável por todo o ciclo de vida, desde o desenvolvimento até a operação e manutenção. Isso reduz a espera e as discussões entre as equipes.

P: Qual é o custo? Resposta: A complexidade é transferida de dentro do código para entre serviços. Você precisa de um monitoramento mais poderoso para observar todo o link do sistema, melhor coleta de logs para rastrear problemas e manipulação de consistência de dados e falhas de rede em um ambiente distribuído. Os requisitos de habilidade para operação e manutenção passaram do gerenciamento de servidores para o gerenciamento de clusters de serviços.

Escrito em: Sobre confiabilidade vs.potênciaescolha

Assim como a escolha de um núcleo de potência para máquinas de precisão, a pedra angular arquitetônica do sistema também precisa ser absolutamente confiável. No mundo dos microsserviços, o funcionamento estável de cada serviço independente está relacionado com a situação geral. Não se trata apenas de implementação técnica, mas também de compreensão profunda e controle contínuo da complexidade.

Quando você começa a considerar esse caminho de evolução, o que você precisa não é apenas de ferramentas e código, mas também de um parceiro que possa entender profundamente o contexto do seu negócio e implementar soluções técnicas de forma sólida. Nesse caminho, práticas robustas e confiabilidade comprovada são muitas vezes mais importantes do que uma pilha de tecnologia deslumbrante.

Em última análise, todas as evoluções da arquitetura têm o mesmo objetivo: tornar o sistema um impulso para os negócios, em vez de um empecilho. Deixe-o funcionar de forma estável, precisa e confiável, como o melhor equipamento de automação da oficina, e seja capaz de ajustar e expandir com flexibilidade quando necessário. Quando a tecnologia apoia silenciosamente o funcionamento dos negócios, ela pode ser o seu maior valor.

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,potênciaintegra 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.