Close

Como criar microsserviços

Práticas recomendadas para fazer a transição para uma arquitetura de microsserviço

Foto de rosto do Chandler Harris
Sten Pittet

Gerente sênior de produtos


Imagine que o aplicativo seja construído em um código e seja bastante grande e monolítico. Funcionava bem até que não funcionou mais. Você gostaria que ele pudesse evoluir e ser mais resiliente e escalável, além de permitir a implementação independente. Para alcançar esse resultado, você precisa repensar a estrutura do aplicativo em um nível granular de microsserviços.

Microsserviços têm crescido em popularidade à medida que os aplicativos se tornam mais distribuídos e complexos. O princípio norteador dos microsserviços é construir um aplicativo dividindo os componentes de negócios em serviços pequenos que sejam independentes uns dos outros para implementação e operação. A separação de problemas entre serviços é definida como “limites de serviço”.

Os limites de serviço estão intimamente ligados às demandas de negócios e aos limites da hierarquia organizacional. Os serviços individuais podem estar vinculados a equipes, orçamentos e roteiros separados. Alguns exemplos de limites de serviço podem ser serviços de “processamento de pagamento” e “autenticação de usuário”. Os microsserviços diferem das práticas de desenvolvimento de software legadas nas quais todos os componentes foram agrupados.

Este documento vai fazer referência a uma startup imaginária de pizza chamada “Pizzup” para ilustrar a aplicação de microsserviços a uma empresa de software moderna.

Como criar microsserviços


Passo 1: Comece com um monólito

A primeira prática recomendada de microsserviços é que você provavelmente não precisa deles. Se você não tem nenhum usuário para o seu aplicativo, o mais provável é que os requisitos de negócios mudem rápido enquanto você está construindo o MVP. Esse cenário ocorre pela natureza do desenvolvimento de software e pelo ciclo de feedback que precisa acontecer enquanto você está identificando os principais recursos de negócios que seu sistema precisa oferecer. Os microsserviços adicionam sobrecarga exponencial e complexidade para gerenciamento. Por esta razão, manter todo o código e a lógica dentro de uma única base de código reduz a sobrecarga para novos projetos, pois facilita a movimentação dos limites dos diferentes módulos do seu aplicativo.

Por exemplo, com o Pizzup, a gente começou com um problema simples que quer resolver: a gente quer que os clientes possam pedir pizza on-line.

Um usuário Pizzup diz: "Como um usuário eu posso encomendar pizza on-line!
ícone do armazenamento de código
Material relacionado

Microsserviços vs. arquitetura monolítica

ícone de três anéis
Ver solução

Gerencie componentes com o Compass

À medida que a gente começa a pensar na questão do pedido da pizza, a gente identifica as diferentes capacidades necessárias no aplicativo, a fim de atender a essa necessidade. A gente vai precisar gerenciar uma lista das diferentes pizzas que podem ser feitas, permitir que os clientes escolham uma ou várias pizzas, lidar com o pagamento, agendar a entrega e assim por diante. A gente pode decidir que deixar os clientes criarem uma conta vai facilitar novos pedidos da próxima vez que usarem o Pizzup. Depois de conversar com os primeiros usuários, a gente pode descobrir que o rastreamento em tempo real da entrega e suporte para dispositivos móveis seria uma vantagem em relação à concorrência.

Um gráfico que mostra a diferença entre os usos do usuário final e do administrador para o aplicativo Pizzup.

O que era uma necessidade simples no começo logo virou uma lista de novos recursos.

Os microsserviços funcionam bem quando você tem uma boa compreensão dos diferentes serviços exigidos pelo seu sistema. No entanto, eles são muito mais difíceis de lidar se os principais requisitos de um aplicativo não estiverem bem definidos. É bastante caro redefinir interações de serviço, APIs e estruturas de dados em microsserviços, pois, em geral, há muitos outros elementos dinâmicos que precisam ser coordenadas. A gente aconselha a manter a simplicidade até que você tenha coletado feedback suficiente do usuário para lhe dar a confiança de que as necessidades básicas de seus clientes são compreendidas e planejadas.

Um pouco de cautela: construir um monólito pode logo levar a um código complicado que é difícil de dividir em partes menores. É melhor ter módulos claros identificados para que eles possam ser extraídos do monólito mais tarde. Você também pode começar separando a lógica da interface do usuário da Web e verificando se ela interage com seu back-end por meio de uma API RESTful por HTTP. Assim fica mais fácil fazer a transição para microsserviços quando você move recursos de API para serviços diferentes.

Passo 2: Organize suas equipes da maneira certa

Até agora, podia parecer que a construção de microsserviços é um assunto mais técnico. Você precisa dividir uma base de código em vários serviços, implementar os padrões certos para falha normal e recuperação de problemas de rede, lidar com a consistência dos dados, monitorar a carga de serviço etc. Vai haver vários novos conceitos para entender. Mas, sem dúvida, a coisa mais importante que não deve ser ignorada é que você vai precisar reestruturar a maneira como suas equipes são organizadas.

A Lei de Conway é real e pode ser observada em todos os tipos de equipes. Se uma equipe de software for organizada com uma equipe de back-end, uma de front-end e uma de operações separadas, elas vão acabar entregando monólitos de front-end e back-end separados que vão ser jogados para a equipe de operações, que vai passar para a produção. Esse tipo de estrutura de equipe não é adequado para microsserviços, pois cada serviço deve ser visto como seu próprio produto que precisa de lançamento independente dos outros.

Em vez disso, você deve criar equipes DevOps menores que tenham todas as competências necessárias para desenvolver e manter os serviços pelos quais elas estão encarregadas. Há grandes benefícios em organizar suas equipes dessa maneira. Em primeiro lugar, seus desenvolvedores têm uma compreensão melhor do impacto do código na produção, o que ajuda a produzir versões melhores e reduzir o risco de ver problemas lançados aos seus clientes. Em segundo lugar, as implementações se tornam naturais para cada equipe, pois elas trabalham juntas em melhorias no código, bem como na automação do pipeline de implementação.

Passo 3: Divida o monólito para construir uma arquitetura de microsserviços

Quando você tiver identificado os limites dos serviços e descoberto como reestruturar as equipes, vai poder começar a dividir o monólito para criar microsserviços. A seguir estão os pontos-chave a serem considerados nesse momento.

Mantenha a comunicação entre serviços simples com uma API RESTful

Se você ainda não está usando uma API RESTful, agora seria um bom momento para começar a usar em seu sistema. Como Martin Fowler explica, você quer ter "pontos de extremidade inteligentes e pipes burros". Ou seja, o protocolo de comunicação entre seus serviços deve ser o mais simples possível, apenas responsável pela transmissão (e não pela transformação) de dados. Toda a magia vai acontecer nos próprios pontos de extremidade — eles recebem uma solicitação, processam e emitem uma resposta em troca.

As arquiteturas de microsserviços se esforçam para manter as coisas o mais simples possível para evitar o acoplamento apertado dos componentes. Em alguns casos, você pode estar usando uma arquitetura voltada a eventos com comunicações assíncronas baseadas em mensagens. Porém, mais uma vez, você deve olhar para serviços básicos de fila de mensagens, como RabbitMQ, e evitar adicionar complexidade às mensagens transmitidas pela rede.

Divida os dados em contextos limitados ou domínios de dados

Os aplicativos monolíticos usam um único banco de dados para todos os recursos de negócios do aplicativo. Como um monólito é dividido em microsserviços, esse banco de dados único pode não fazer mais sentido. Um banco de dados central pode se tornar um gargalo para o dimensionamento do tráfego. Se um determinado serviço acessar o banco de dados com alta carga, ele pode interromper o acesso ao banco de dados de outros serviços. Além disso, um banco de dados único pode ser um gargalo de colaboração para várias equipes que tentam modificar o esquema ao mesmo tempo. Essa situação pode exigir a divisão do banco de dados ou a adição de ferramentas extras de armazenamento de dados para dar suporte às necessidades de dados de microsserviço.

Refatorar um esquema de banco de dados monolítico pode ser uma operação delicada. É importante identificar claramente de quais conjuntos de dados cada serviço precisa e quaisquer sobreposições. Esse planejamento de esquema pode ser feito usando contextos limitados, que são um padrão do Domain-Driven Design. Um contexto limitado define um sistema independente, incluindo o que pode entrar e sair desse sistema.

Nesse sistema, quando um usuário acessa um pedido, você pode visualizar as informações do cliente na tabela, que também podem ser usadas para preencher a fatura gerenciada pelo sistema de faturamento. Pode parecer lógico e simples, mas, com microsserviços, os serviços devem ser dissociados para que as faturas possam ser acessadas mesmo se o sistema de pedidos estiver inativo. Além disso, permite otimizar ou evoluir a tabela de faturas independentemente de outras. Cada serviço pode acabar tendo seu próprio armazenamento de dados para acessar os dados de que precisa.

Assim você vai enfrentar novos problemas, pois alguns dados vão ser duplicados em bancos de dados diferentes. Contextos limitados podem identificar a melhor estratégia para lidar com dados compartilhados ou duplicados. Você pode adotar uma arquitetura voltada a eventos para ajudar a sincronizar dados em vários serviços. Por exemplo, seus serviços de rastreamento de faturamento e entrega podem estar ouvindo eventos emitidos pelo serviço de conta quando os clientes atualizam suas informações pessoais. Após a recepção do evento, esses serviços vão atualizar seu armazenamento de dados de acordo. Essa arquitetura voltada a eventos permite que a lógica do serviço de conta seja mantida simples, pois não precisa conhecer todos os outros serviços dependentes. Ele simplesmente diz ao sistema o que ele fez e outros serviços ouvem e agem de acordo.

Você também pode optar por manter todas as informações do cliente no serviço de conta e manter apenas uma referência de chave estrangeira em seu serviço de faturamento e entrega. Em seguida, esses serviços interagem com o serviço de conta para obter dados relevantes do cliente, em vez de duplicar os registros existentes. Como não existe uma solução universal para esses problemas, você vai precisar examinar cada caso específico para determinar a melhor abordagem.

Crie sua arquitetura de microsserviços para falhas

Vimos como os microsserviços podem lhe proporcionar grandes benefícios em relação a uma arquitetura monolítica. Eles são menores em tamanho e especializados, o que os torna fáceis de entender. Eles são dissociados, o que significa que você pode refatorar um serviço sem temer quebrar os outros componentes do sistema, ou retardar o desenvolvimento das outras equipes. Eles também oferecem mais flexibilidade a seus desenvolvedores, pois eles podem escolher tecnologias diferentes, se necessário, sem serem limitados pelas necessidades de outros serviços.

Em suma, ter uma arquitetura de microsserviços facilita o desenvolvimento e a manutenção de cada capacidade de negócios. Mas as coisas se tornam mais complicadas quando você olha para todos os serviços juntos e como eles precisam interagir para concluir ações. Seu sistema agora está distribuído com vários pontos de falha e você precisa lidar com essa situação. Você precisa levar em conta não apenas os casos em que um serviço não está respondendo, mas também ser capaz de lidar com respostas de rede mais lentas. A recuperação de uma falha também pode ser complicada às vezes, pois você precisa ter certeza de que os serviços que voltam a ficar on-line não sejam inundados por mensagens pendentes.

À medida que você começa a extrair recursos de seus sistemas monolíticos, faça com que seus projetos sejam criados para falhas desde o início.

Enfatize o monitoramento para facilitar o teste de microsserviços

O teste é outra desvantagem dos microsserviços em comparação com um sistema monolítico. Um aplicativo criado como uma única base de código não precisa de muito para ter um ambiente de teste em execução. Na maioria dos casos, você vai ter que iniciar um servidor de back-end junto com um banco de dados para poder executar seu conjunto de testes.

No mundo dos microsserviços, as coisas não são tão fáceis. Em relação aos testes unitários, ainda vai ser bastante semelhante ao monólito, e você não deveria ter mais problemas nesse nível. No entanto, quando se trata de integração e testes de sistema, as coisas vão ser muito mais difíceis. Você pode precisar iniciar vários serviços juntos e ter diferentes armazenamentos de dados em funcionamento, e a configuração pode precisar incluir filas de mensagens que não seriam necessárias com o monólito. Nesta situação, fica muito mais caro executar testes funcionais, e o número crescente de elementos dinâmicos torna muito difícil prever os diferentes tipos de falhas que podem acontecer.

O monitoramento pode identificar problemas com antecedência e permitir que você reaja de acordo. Você precisa entender os padrões de diferentes serviços e reagir não apenas quando eles ficam inativos, mas também quando apresentam comportamento inesperado. Uma vantagem de adotar uma arquitetura de microsserviço é que seu sistema deve ser resistente a falhas parciais. Portanto, se você começar a ver anomalias no serviço de rastreamento de entrega do aplicativo Pizzup, não vai ser tão ruim como se fosse um sistema monolítico. O aplicativo deve ser projetado para que todos os outros serviços apresentem as respostas adequadas e permitam que os clientes encomendem pizzas enquanto a gente restaura o rastreamento em tempo real.

Adote a entrega contínua para reduzir o atrito da implementação

O lançamento manual de um sistema monolítico para produção é um esforço tedioso e arriscado, mas possível. É claro que a gente não recomenda essa abordagem e incentiva todas as equipes de software a adotar a entrega contínua para todos os tipos de desenvolvimento; porém, no início de um projeto, você mesmo pode fazer suas primeiras implementações através da linha de comando.

Essa abordagem não é sustentável quando você tem um número crescente de serviços que precisam ser implementados várias vezes ao dia. Assim, como parte de sua transição para microsserviços, é fundamental que você adote a entrega contínua para reduzir os riscos de falha de lançamento, além de garantir que sua equipe esteja focada na criação e execução do aplicativo, em vez de ficar preso na implementação dele. Praticar a entrega contínua também significa que seu serviço passou nos testes de aceitação antes de ir para a produção. É claro que os bugs vão ocorrer, mas, ao longo do tempo, você vai construir um conjunto de testes robusto que deve aumentar a confiança de sua equipe na qualidade das versões.

Executar microsserviços não é um sprint


Os microsserviços são uma prática popular e de adoção ampla no setor. Para projetos complexos, eles oferecem maior flexibilidade para construir e implementar software. Eles também ajudam a identificar e formalizar os componentes de negócios de seu sistema, o que é útil quando você tem várias equipes trabalhando no mesmo aplicativo. Mas também há algumas desvantagens claras no gerenciamento de sistemas distribuídos, e a divisão de uma arquitetura monolítica só deve ser feita quando há uma compreensão clara dos limites de serviço.

A construção de microsserviços deve ser vista como uma jornada em vez de um objetivo imediato para uma equipe. Comece aos poucos para entender os requisitos técnicos de um sistema distribuído, como fazer a falha normal e como escalar componentes individuais. Então você pode extrair mais serviços à medida que ganha experiência e conhecimento.

A migração para uma arquitetura de microsserviços não precisa ser feita em apenas um esforço holístico. Uma estratégia iterativa para fazer a migração sequencial de componentes menores para microsserviços é uma aposta mais segura. Identifique os limites de serviço mais bem definidos dentro de um aplicativo monolítico estabelecido e use iterações para serem separados em microsserviços próprios.

Conclusão…


Para recapitular, os microsserviços são uma estratégia benéfica tanto para o processo de desenvolvimento de código técnico bruto quanto para a estratégia geral da organização de negócios. Os microsserviços ajudam a organizar equipes em unidades que se concentram no desenvolvimento e na propriedade de funções específicas de negócios. Esse foco granular melhora a comunicação e a eficiência gerais dos negócios. Existem compensações para os benefícios dos microsserviços. É importante que as definições dos limites de serviço estejam claras antes de migrar para uma arquitetura de microsserviços.

Embora uma arquitetura de microsserviços tenha vários benefícios, ela também aumenta a complexidade. A Atlassian desenvolveu o Compass para ajudar as empresas a gerenciar as complexidades das arquiteturas distribuídas que vêm com a escalabilidade. É uma plataforma de experiência de desenvolvedor extensível que reúne informações desconectadas sobre todos os resultados de engenharia e colaboração da equipe em local central e pesquisável.

Sten Pittet
Sten Pittet

Estou no ramo de software há 10 anos, em diversas funções, de desenvolvimento a gerenciamento de produto. Depois de passar os últimos 5 anos na Atlassian trabalhando em Ferramentas de Desenvolvimento, agora escrevo sobre como compilar software. Fora do trabalho, estou aprimorando minhas habilidades como pai de uma criancinha maravilhosa.


Compartilhe este artigo

Leitura recomendada

Marque esses recursos para aprender sobre os tipos de equipes de DevOps ou para obter atualizações contínuas sobre DevOps na Atlassian.

Ilustração DevOps

Comunidade do Compass

ilustração de superação de obstáculos

Tutorial: criar novo componente

Ilustração do mapa

Comece a usar o Compass de graça

Inscreva-se para receber a newsletter de DevOps

Thank you for signing up