Nos anos 60 e 70, arquitetura monolítica era preferido para o desenvolvimento de aplicações devido aos recursos computacionais limitados, que exigiam combinar todas as funcionalidades em uma única unidade coesa.
Isso mudou no final dos anos 90 e nos anos 2000, quando a arquitetura monolítica começou a mostrar suas limitações conforme as aplicações cresciam em tamanho e complexidade. A internet e os sistemas distribuídos aceleraram essa transformação.
Isso levou ao desenvolvimento de abordagens mais modulares, como arquiteturas orientadas a serviços (SOA) e, depois, arquitetura de microsserviços (MSA), que eventualmente ganhou destaque no início dos anos 2010.
Dito isso, esta é apenas uma explicação breve do conceito básico e do uso de microsserviços. Então, vamos discutir como os microsserviços substituíram a arquitetura monolítica, como os microsserviços funcionam e alguns exemplos de microsserviços. Depois, abordaremos os aspectos-chave da implantação de microsserviços e o que fazer se você quiser implantar microsserviços.
O que São Microsserviços? Como Funcionam?
Como mencionei antes, microsserviços surgiram como solução para a crescente complexidade e tamanho das aplicações, permitindo que empresas dividissem funcionalidades em serviços implantáveis de forma independente.
O termo "microsserviços" foi popularizado por especialistas como Martin Fowler e James Lewis, que o apresentaram formalmente em um artigo de blog em 2014. Seu trabalho definiu os princípios e características centrais da abordagem, incluindo serviços implantáveis de forma independente, gerenciamento descentralizado de dados e neutralidade tecnológica.
Desde então, microsserviços se tornaram a escolha arquitetônica dominante, impulsionada por avanços em tecnologias de containerização como Docker, ferramentas de orquestração como Kubernetes e plataformas de computação serverless. Mas como os microsserviços funcionam?
Como os Microsserviços Funcionam?
No núcleo, uma arquitetura de microsserviços divide uma aplicação grande em serviços menores e distintos, cada um responsável por uma capacidade de negócio específica. Esses serviços se comunicam entre si pela rede, geralmente através de REST APIs, gRPC ou message brokers como RabbitMQ ou Apache Kafka.
De acordo com a definição de Martin Fowler e James Lewis, os microsserviços têm quatro características principais:
- Responsabilidade Única: Cada microsserviço é projetado para executar uma tarefa ou função específica, permitindo especialização e reduzindo a complexidade.
- Independência: Microsserviços podem ser desenvolvidos, implantados e escalados independentemente um do outro, o que proporciona flexibilidade e resiliência.
- Gestão Descentralizada de Dados: Microsserviços geralmente têm seus próprios bancos de dados, eliminando a necessidade de um banco de dados centralizado único.
- Agnóstico em Relação à Tecnologia: Os times podem escolher a melhor tecnologia para cada serviço sem ficar presos às escolhas de outros serviços.
Essa abordagem contrasta com a arquitetura monolítica tradicional, na qual todos os componentes da aplicação estão fortemente integrados em uma única unidade coesiva.
Etapas Principais da Implantação de Microsserviços
Embora uma arquitetura de microsserviços ofereça inúmeros benefícios, como alta escalabilidade, flexibilidade, eficiência e isolamento de falhas, ela exige conhecimento de como implantar microsserviços de forma eficaz e planejamento adequado para ter sucesso.
Por isso, ter uma compreensão abrangente dos conceitos principais, etapas e melhores práticas de microsserviços na implantação é essencial para uma arquitetura de microsserviços bem-sucedida. Então, vamos explorar as etapas principais da implantação de microsserviços e o que cada etapa envolve.
Planejamento e Preparação da Implantação de Microsserviços
Tudo que é feito bem requer planejamento e paciência, e para implantar microsserviços com sucesso, você definitivamente precisará de planejamento e paciência adequados. Por isso é importante seguir as melhores práticas de microsserviços e planejar e preparar tudo o que você precisa ao implantar microsserviços.
Como mencionei antes, um dos princípios e características principais de microsserviços é o Princípio da Responsabilidade Única. Ao manter fidelidade a esse princípio e garantir que cada microsserviço se concentre em e seja responsável por uma função e capacidade, você permite que seu time desenvolva, implante e escale serviços independentemente.
Além disso, uma subcategoria desse princípio é o princípio de design de acoplamento fraco. Isso significa que cada serviço pode funcionar independentemente para comunicação e tem dependência mínima de outros serviços. Por sua vez, isso permite que mudanças ou atualizações em um serviço não afetem outros serviços, permitindo escalabilidade independente de microsserviços.
Isso diminui o risco de falhas em cascata, onde um problema ou falha em uma parte do sistema desencadeia uma reação em cadeia, levando a falhas em todo o sistema e derrubando o serviço inteiro.
Uma prática importante de microsserviços é ter armazenamento de dados dedicado para cada serviço ao implantar microsserviços como uma extensão do princípio de design de acoplamento fraco, pois isso evita conflitos e permite melhor escalabilidade do serviço.
Além disso, você precisará de padrões de comunicação assíncrona entre microsserviços, como message brokers, para garantir que cada serviço se comunique sem dependências diretas.
O último passo é implementar pipelines de Integração Contínua e Entrega Contínua (CI/CD) para microsserviços. Esses pipelines permitem que times façam deploy de novas funcionalidades ou correções através de Ferramentas CI/CD como Jenkins e GitLab, permitindo que organizações mantenham a estabilidade do sistema enquanto lançam novas funcionalidades com frequência.
Agora que você tem uma visão geral do planejamento e preparação necessários para o deploy de microsserviços, vamos falar sobre estratégias de deploy de microsserviços.
Estratégias de Deploy de Microsserviços
Ao fazer deploy de microsserviços, a escolha da estratégia depende da função do serviço, tráfego, infraestrutura, experiência do time e custo. De forma geral, as estratégias de deploy de microsserviços são as seguintes:
- Instância de Serviço por Container: Nessa abordagem, cada microsserviço roda em seu próprio container, oferecendo melhor isolamento do que o modelo de múltiplas instâncias por host. Containers facilitam o dimensionamento e melhoram a alocação de recursos.
- Instância de Serviço por Máquina Virtual: Cada serviço roda em uma máquina virtual (VM) separada, proporcionando isolamento ainda maior do que containers. Embora melhore a segurança e estabilidade, isso normalmente traz mais overhead.
- Lançamentos Faseados: Inicialmente, faça deploy de versões do microsserviço para um pequeno grupo de usuários, testando a estabilidade antes de um rollout completo. Essa abordagem reduz o impacto se problemas surgirem e permite rollbacks rápidos para manter a integridade do sistema.
- Deploy Blue-Green: Esse método usa dois ambientes de produção idênticos. Um ambiente serve o tráfego ativo enquanto o outro é usado para testar o próximo release. O deploy blue-green permite rollbacks simples e atualizações sem downtime, já que o tráfego pode ser redirecionado entre os dois ambientes.
- Lançamentos Graduais: Essa estratégia envolve lançar atualizações gradualmente para diferentes segmentos de usuários ou ambientes. Geralmente começa em ambientes internos antes de chegar à produção, limitando o impacto de qualquer problema potencial e permitindo que times resolvam problemas em etapas.
- Implantação sem servidor: Essa abordagem usa plataformas serverless como AWS Fargate e Google Cloud Run, que automatizam o gerenciamento de infraestrutura ao lidar com dimensionamento e alocação de recursos. Com deploy serverless, não há necessidade de gerenciar servidores subjacentes, permitindo que você se concentre nos microsserviços em si.
Depois de escolher uma das estratégias de deploy de microsserviços acima, você precisará de uma ferramenta de orquestração de microsserviços.
Orquestração de Microsserviços
Depois de escolher uma das muitas estratégias de deploy de microsserviços, você vai precisar de algo como um maestro para a orquestração de microsserviços. Ferramentas de orquestração de microsserviços, como Kubernetes, ajudam a automatizar o deploy, dimensionamento, monitoramento e gerenciamento de microsserviços containerizados.
A Airbnb, por exemplo, usa Kubernetes, permitindo que seus engenheiros façam deploy de centenas de mudanças em seus microsserviços sem intervenção manual. Um recurso importante de ferramentas de orquestração de microsserviços como Kubernetes é o balanceamento de carga integrado.
Ter um recurso competente de balanceamento de carga ajuda a distribuir o tráfego recebido entre múltiplas instâncias de um microsserviço. Isso evita que uma instância se torne um gargalo e melhora a capacidade do sistema de lidar com picos de demanda.
Kubernetes desempenha um papel significativo no gerenciamento de microsserviços através de suas capacidades de auto-recuperação, onde containers que falharam são automaticamente substituídos e reiniciados. O New York Times aproveita esse recurso para manter seus microsserviços sem impactar a experiência do usuário e evitar downtimes.
Além disso, Kubernetes também melhora a segurança de microsserviços ao proteger configurações e secrets, como credenciais de banco de dados ou chaves API, usando ConfigMaps e Secrets. Isso é especialmente importante para empresas e serviços, como Uber, que lidam com informações sensíveis de clientes e usuários.
Por fim, ferramentas de orquestração de microsserviços como Kubernetes são particularmente úteis para estratégias de microsserviços que envolvem atualizações e rollbacks gradualmente, como lançamentos em etapas. Atualizações gradientes permitem que novas versões de microsserviços sejam feitas sem interrupções de serviço ao manter algumas instâncias da versão antiga rodando.
Depois de configurar sua ferramenta de orquestração de microsserviços, você precisará construir e automatizar Pipelines de CI/CD para implantação de microsserviços.
Pipelines CI/CD para Implantação de Microsserviços
Como discutimos anteriormente, pipelines de Integração Contínua e Entrega Contínua para microsserviços são aspectos importantes da implantação de microsserviços. Os pipelines de CD em pipelines CI/CD são responsáveis por implantar automaticamente alterações de código em produção assim que passam pelos estágios de teste e integração do pipeline CI/CD.
Em seguida, a parte de CD dos pipelines CI/CD entra em ação para que sempre que as alterações de código passem pelos estágios de teste e integração, o serviço seja implantado em uma ferramenta de orquestração de microsserviços como um cluster Kubernetes.
Além disso, os estágios de teste e integração são todos realizados automaticamente pelos pipelines CI/CD, pois testes unitários, testes de integração e testes ponta a ponta são incorporados ao pipeline.
Isso permite que os times validem atualizações em cada estágio mantendo a estabilidade do sistema. Além disso, se houver problemas com as alterações de código, apesar dos vários testes, reversões automáticas podem retornar para a versão estável anterior.
Por fim, implementar pipelines CI/CD para microsserviços de acordo com as melhores práticas de microsserviços ajuda as organizações a alcançar desenvolvimento mais rápido, reduzir erros manuais e manter altos padrões de qualidade.
Muitas empresas como Spotify, Expedia, iRobot, Lufthansa, Pandora, etc., usam pipelines CI/CD para microsserviços através de ferramentas CI/CD como CircleCI, AWS CodePipeline e GitLab para automatizar processos de implantação, garantir qualidade consistente de código e entregar novos recursos rapidamente mantendo a estabilidade do sistema.
Padrões de Comunicação de Microsserviços
Como os microsserviços se comunicam entre si depende completamente da função, da arquitetura geral, escalabilidade desejada e confiabilidade dos seus microsserviços. Geralmente, dois tipos principais de padrões de comunicação de microsserviços são utilizados: síncrono e assíncrono padrões de comunicação de microsserviços.
Nos padrões de comunicação de microsserviços síncronos, os serviços interagem em tempo real, significando que um serviço enviará uma solicitação e aguardará uma resposta antes de prosseguir. Os padrões de comunicação de microsserviços síncronos mais comumente utilizados são REST (Transferência de Estado Representacional) APIs, gRPC (GoGoogle Remote Procedure Call), e GraphQL.
Normalmente, esse tipo de padrão de comunicação de microsserviços é usado em indústrias e por empresas que normalmente exigem processamento de dados em tempo real e respostas imediatas. Indústrias como finanças, saúde e e-commerce frequentemente usam padrões de comunicação síncrona para garantir que transações, recuperação de dados ou interações aconteçam instantaneamente, mantendo uma experiência de usuário suave e responsiva.
Dito isto, enquanto os padrões de comunicação de microsserviços síncronos oferecem benefícios como respostas em tempo real e simplicidade, eles também têm certas desvantagens, como possíveis gargalos devido ao seu acoplamento rígido, baixa escalabilidade sob cargas altas, tempos de resposta lentos e alta latência durante períodos de tráfego intenso.
Por outro lado, os padrões de comunicação de microsserviços assíncronos geralmente são mais adequados para microsserviços, pois são baseados no princípio de Acoplamento Solto que discutimos anteriormente.
Esse tipo de padrão de comunicação de microsserviços desacopla os serviços permitindo que eles enviem e recebam mensagens através de um intermediário como Kafka ou RabbitMQ. Ao enviar mensagens para uma fila que atua como um buffer, os serviços se comunicam independentemente em vez de aguardar uma resposta como fariam nos padrões de comunicação síncrona. Esse buffer permite que outros serviços processem mensagens no seu próprio ritmo, permitindo que o remetente continue seu trabalho sem aguardar o destinatário.
O padrão de comunicação de microsserviços assíncrono não apenas oferece uma estrutura desacoplada para implantação de microsserviços, mas também oferece a mesma resposta em tempo real que os padrões de comunicação de microsserviços síncronos oferecem.
Isto se deve à arquitetura orientada por eventos dos padrões de comunicação de microsserviços assíncronos orientados por eventos, pois os serviços se comunicam emitindo eventos quando uma ação específica ocorre. Outros serviços podem se inscrever nestes eventos e reagir adequadamente. Isso permite sistemas altamente responsivos que reagem às mudanças em tempo real sem acoplamento direto entre serviços.
Além disso, em assíncrono Publicação-Subscrição (Pub/Sub) padrões de comunicação de microsserviços, os serviços (publicadores) enviam mensagens para um tópico e outros serviços (assinantes) escutam esse tópico para receber atualizações. Esse modelo oferece suporte a múltiplos assinantes, transmitindo simultaneamente mensagens para muitos serviços.
Por fim, semelhante aos padrões orientados por eventos, assíncrono saga baseada em coreografia padrões de comunicação de microsserviços também usam eventos para se comunicarem entre si; no entanto, neste padrão, uma ordem particular está em vigor, significando que eventos acionam o próximo passo e um serviço particular para ser ativado.
A diferença aqui é que em padrões orientados a eventos, não há uma sequência ou fluxo de trabalho definido, e múltiplos serviços podem reagir a um evento em vez de seguir o processo e ordem específicos do padrão saga baseado em coreografia.
O tipo de padrão de comunicação de microsserviços assíncrono que você usa depende da tarefa e da função geral dos seus microsserviços. Filas de mensagens como RabbitMQ e Amazon SQS são normalmente usadas para agendamento de tarefas, distribuição de carga e e-commerce para processamento de pedidos e sistemas de notificação.
Brokers de mensagens orientados a eventos, como Apache Kafka e AWS EventBridge, são normalmente usados para processar grandes volumes de fluxos de eventos em tempo real e roteamento de eventos entre microsserviços em áreas como serviços financeiros e ambientes AWS.
Quanto aos brokers de mensagens Publish-Subscribe (Pub/Sub) como Google Cloud Pub/Sub e Redis Streams, esses brokers de mensagens são geralmente usados para mensagens escaláveis em sistemas distribuídos, análises em tempo real, ingestão de eventos, notificações em tempo real e aplicações de chat.
Por fim, brokers de mensagens saga baseados em coreografia são principalmente usados para processamento de pedidos em e-commerce, sistemas de reserva de viagens e casos de uso onde transações complexas e multietapas precisam ser coordenadas entre múltiplos serviços sem controle centralizado.
Service Discovery em Microsserviços
Depois de implementar um padrão de comunicação que atenda às suas necessidades, você precisa garantir que seus serviços consigam se localizar mutuamente. Como mencionei antes, ferramentas de orquestração de microsserviços como Kubernetes desempenham um papel importante na descoberta de serviços.
Isso é feito por meio da descoberta de serviços integrada que Kubernetes DNS oferece, que atualiza dinamicamente endereços IP e registros DNS conforme os serviços são escalados ou mudam de localização no cluster.
Esse método de descoberta de serviços em microsserviços é chamado de descoberta do lado do servidor, pois a responsabilidade de roteamento é delegada a um balanceador de carga, que consulta o registro e direciona o tráfego para a instância apropriada.
Por outro lado, também temos o método de descoberta do lado do cliente para descoberta de serviços em microsserviços, onde o serviço ou gateway API consulta um registro de serviços como Consul ou Eureka para encontrar instâncias disponíveis.
Escolher qual método de descoberta de serviços é melhor para sua implantação de microsserviços depende dos requisitos e escala do sistema.
Com descoberta de serviços de microsserviços do lado do cliente, o cliente tem controle total sobre qual instância se comunica. Isso não apenas permite mais personalização, mas também reduz a complexidade, pois não há necessidade de um serviço de descoberta centralizado.
Por exemplo, a implantação de microsserviços da Netflix usa descoberta de serviços do lado do cliente com Eureka e Ribbon para balanceamento de carga, permitindo que o cliente escolha a melhor instância com base em critérios como latência e carga do servidor.
No entanto, a descoberta de serviços de microsserviços do lado do servidor é mais adequada para ambientes maiores, pois uma descoberta de serviços centralizada pode melhorar a eficiência e permitir balanceamento de carga consistente em um sistema distribuído.
Soluções de descoberta de serviços do lado do servidor como Kubernetes, AWS Elastic Load Balancing e API Gateways (Kong, NGINX, etc.) ajudam a rotear tráfego de forma eficiente e manter alta disponibilidade, sendo usadas por empresas como Airbnb, Pinterest, Expedia, Lyft, etc.
Segurança de Microsserviços
Enquanto a arquitetura monolítica é geralmente inferior à MSA, um aspecto em que tinha vantagem era segurança. Como microsserviços são construídos no princípio de Loose Coupling e distribuídos por natureza, uma única medida de segurança geral não pode ser implementada.
Como cada serviço deve ser protegido independentemente, salvaguardas adicionais são necessárias, pois a superfície de ataque é muito maior em microsserviços. Para isso, padrões como OAuth2 e JSON Web Tokens (JWT) são comumente usados para autenticação e autorização, como você pode imaginar.
Além disso, um gateway API também é frequentemente empregado para gerenciar a segurança entre microsserviços, pois enforça autenticação e autorização no ponto de entrada. Além disso, gateways API também podem implementar rate limiting, logging e monitoramento, que fornecem camadas adicionais de segurança em microsserviços.
Embora esses protejam o ponto de entrada principal, mais medidas de segurança em microsserviços são necessárias para cobrir comunicação entre serviços.
É aqui que service meshes entram em jogo, pois adicionam uma camada de segurança de rede em microsserviços e criptografam o tráfego entre serviços e aplicam políticas como mutual TLS. Essas malhas de serviços basicamente configuram criptografia end-to-end abrangente que melhora significativamente a segurança em microsserviços.
Dimensionamento de Microsserviços
Um dos maiores benefícios do MSA, e a razão pela qual foi desenvolvido para substituir a arquitetura monolítica, é sua alta escalabilidade. Normalmente, o escalonamento de microsserviços pode ocorrer de duas maneiras: vertical e horizontal.
Basicamente, escalonamento vertical de microsserviços (scale up) é adicionar mais recursos, como CPU ou memória, a uma instância existente. Alternativamente, escalonamento horizontal de microsserviços (scale out) distribui a carga e aumenta a capacidade.
Em termos de implementação, escalonamento vertical de microsserviços é o mais fácil dos dois, pois você só precisa modificar uma instância ao fazer upgrade para um servidor maior, aumentar memória ou poder de processamento em uma instância na nuvem ou adicionar mais armazenamento.
Esse tipo de escalonamento é normalmente usado em casos em que aumentar poder de RAM ou CPU pode melhorar o desempenho de consultas e processamento de dados, como serviços responsáveis por cache em memória.
Dito isso, embora o dimensionamento vertical de microsserviços seja mais fácil e ofereça um ganho imediato de desempenho, também tem desvantagens. O dimensionamento vertical é limitado pela capacidade de hardware do servidor, então em algum momento você precisará mudar para dimensionamento horizontal para continuar escalando.
Além disso, o dimensionamento vertical tem custos altos, pois hardware e instâncias maiores geralmente têm um preço elevado. Por fim, se a instância escalada falhar, o serviço cai completamente, pois não há instâncias adicionais para lidar com a carga.
Para o dimensionamento horizontal de microsserviços, em vez de aumentar os recursos de uma única instância, você implanta novas instâncias desse serviço. Embora essas instâncias funcionem independentemente, elas ainda lidam com o mesmo serviço e partes da mesma carga de trabalho.
Diferentemente do dimensionamento vertical, o dimensionamento horizontal de microsserviços é ilimitado, o que significa que você pode adicionar quantas instâncias precisar para lidar com cargas crescentes e picos de tráfego, oferecendo maior escalabilidade.
Além disso, como você tem várias instâncias, se uma cair, você não coloca todos os seus ovos na mesma cesta, pois outras instâncias podem continuar lidando com requisições. Por fim, o dimensionamento horizontal é muito mais econômico a longo prazo, pois você pode usar várias instâncias menores e mais baratas para formar um desempenho mais confiável e mais poderoso.
Dito isso, o dimensionamento horizontal e adicionar mais instâncias exigem mais balanceadores de carga, mecanismos de descoberta de serviço de microsserviços e ferramentas de orquestração de microsserviços, tornando sua arquitetura de microsserviços muito mais complexa.
O dimensionamento horizontal é mais adequado para casos de uso como serviços web e aplicações como e-commerce ou plataformas de mídia social, que frequentemente enfrentam tráfego flutuante e um alto volume de requisições.
Dito isso, não é realmente uma questão de um ou outro, pois ambos os tipos de dimensionamento são suportados em microsserviços e são necessários em muitos casos. Normalmente, organizações menores usam dimensionamento vertical por ser muito mais simples de implementar e gerenciar, mas com o tempo e conforme a aplicação cresce, o dimensionamento horizontal é introduzido para lidar com a demanda pesada.
Por fim, plataformas em nuvem oferecem serviços de dimensionamento automático que adicionam ou removem instâncias automaticamente com base na demanda em tempo real, o que ajuda significativamente as organizações a equilibrar o dimensionamento vertical e horizontal.
Monitoramento de Microsserviços
Nesta etapa, você praticamente terminou sua implantação de microsserviços; tudo que resta é garantir que funcione de forma consistente e confiável. É aqui que ferramentas de monitoramento de microsserviços como Prometheus e Grafana entre.
Essas ferramentas fornecem insights em tempo real sobre métricas de serviço, para que os times possam acompanhar o uso de recursos, latência e taxas de erro. Além disso, essas ferramentas também oferecem rastreamento distribuído (Jaeger, Zipkin, etc.), que ajuda a visualizar fluxos de requisição entre serviços e pode ser extremamente útil para diagnosticar problemas.
Por fim, como falhas podem se cascatear entre serviços devido ao design distribuído dos microsserviços, a agregação de logs é uma prática crítica no monitoramento de microsserviços. Consolidando logs em uma plataforma centralizada e configurando alertas em tempo real, você sempre estará um passo à frente dos problemas e pode responder proativamente a eles antes que afetem os usuários.
Pensamentos Finais
Embora o mundo dos microsserviços seja definitivamente difícil de compreender, entender os fundamentos e os principais estágios da implantação de microsserviços pode tornar todo o processo muito mais fácil. Além disso, com o passar dos anos, cada vez mais ferramentas com muito mais recursos estão à sua disposição, tornando a implantação de microsserviços mais simples do que nunca.
Perguntas Frequentes
Quais estratégias de implantação são comumente usadas para microsserviços?
Embora existam muitas estratégias diferentes para implantação de microsserviços, as estratégias mais comumente usadas incluem instâncias de serviço por contêiner, lançamentos faseados, implantação azul-verde e implantação sem servidor, cada uma oferecendo diferentes níveis de isolamento, flexibilidade e escalabilidade.
Qual é o papel do Kubernetes na orquestração de microsserviços?
Microsserviços dependem de ferramentas de orquestração de microsserviços como Kubernetes para automatizar a implantação, escalar e gerenciar serviços em contêineres, fornecendo balanceamento de carga, dimensionamento automático e capacidades de autocorreção para garantir microsserviços resilientes e eficientes.
Como posso garantir segurança em um ambiente de microsserviços?
Devido à sua natureza distribuída, microsserviços são mais complicados em termos de segurança do que a arquitetura monolítica. Segurança em microsserviços envolve autenticação e autorização de requisições, criptografia de comunicação entre serviços e implementação de gateways API e service meshes como Istio para gerenciamento centralizado de segurança.
