Neste artigo, iremos examinar um cenário inicial de uma solução de comércio eletrônico em .NET, propondo uma nova arquitetura de microsserviços e avaliando os desafios inerentes a esse tipo de abordagem.
Vamos considerar possíveis padrões de arquitetura, tecnologias e ferramentas necessárias para realizar a comunicação entre os serviços, e ao final iremos demonstrar uma solução de exemplo, que pode ser baixada e executada, e na qual foram aplicados os conceitos que abordamos aqui.
O assunto “microsserviços” é extremamente vasto, portanto vamos nos focar aqui apenas na comunicação entre serviços.
Por que microsserviços?
Depois de uma estratégia de marketing bem-sucedida, as vendas em nosso website disparam. Temos uma multidão de clientes acessando simultaneamente e o desempenho do nosso servidor cai consideravelmente.
Os clientes, até então fiéis à plataforma, começam a reclamar nas redes sociais e criar memes sobre a lentidão e os erros constantes do website.
Então a empresa começa a contratar profissionais de desenvolvimento e de suporte, porém a estrutura da aplicação, monolítica, torna difícil para vários profissionais trabalharem ao mesmo tempo no mesmo projeto e mesma base de código.
Para dar conta do grande volume de usuários, a equipe hospeda a aplicação na nuvem, acrescentando novos servidores ou mais memória conforme necessário. Porém, a aplicação monolítica não é modular, e tanto o processo de “escalar para cima” (acrescentar memória RAM aos servidores) como “escalar para fora” (instanciando novos servidores) aumentam muito o custo da hospedagem em nuvem.
Os desenvolvedores reclamam do tempo excessivo que a aplicação leva para carregar e iniciar em suas máquinas. Com isso, os bugs e novas funcionalidades se acumulam e o “lead time” (tempo entre um chamado do cliente e a implantação) se torna cada vez maior.
Desenvolvedores começam a criar muitos hot-fixes com pouca padronização e sem os testes de unidade adequados, introduzindo novos erros potenciais. Implantar novas tecnologias se torna muito complexo, pois frameworks afetam o aplicativo inteiro aumentando o custo de suporte.
Também fica difícil de entender o impacto de cada mudanças, o que exige um cansativo teste manual. Bugs em qualquer módulo, como vazamento de memória, podem derrubar a aplicação inteira e levar o website a ficar indisponível. O resultado: clientes insatisfeitos e vendas caindo.
Arquitetura de Comunicação de Microsserviços
Criar uma arquitetura que suporta aplicativos baseados em microsserviços traz benefícios para a gestão do ciclo de vida do projeto:
ela promove as práticas de integração e entrega contínua, graças à modularidade e alta granularidade dos serviços.
Também podemos contar com menor custo de manutenção e maior agilidade na entrega de novas funcionalidades, já que as melhorias e correções de bugs em um dado serviço não afetarão os demais. Porém, há o outro lado da moeda: quebrar uma aplicação monolítica em múltiplas aplicações e processos traz diversos desafios técnicos e operacionais.
Aqui, vamos considerar apenas alguns padrões de arquitetura de comunicação que podem ser usados em uma solução com microsserviços.
Um dos padrões mais comumente encontrados é o Bounded Context (Contexto Delimitado), que normalmente é associado ao conjunto de padrões conhecido como DDD (Domain Driven Design). Com o contexto delimitado, cada serviço tem seu próprio modelo de dados, que é independente do modelo de outros serviços.
Com isso, o modelo de um serviço pode ser refinado continuamente, sem afetar outros serviços. Os dados do modelo de cada serviço podem ser persistidos em uma base de dados diferente.
Por exemplo, um serviço pode gravar registros em tabelas de banco de dados relacional, enquanto outros serviços da mesma solução salvam informações em bancos de dados não relacional.
As requisições realizadas entre microsserviços são diferentes das chamadas entre componentes dentro de uma aplicação monolítica, pois cada serviço é executado em seu próprio processo.
Por isso, novos desafios surgem quando a comunicação é feita entre aplicações distribuídas: o que acontece quando é feita uma requisição a um serviço está indisponível, ou que leva muito tempo para responder?
Para atender essas necessidades, as aplicações se comunicam com outros processos através de protocolos adequados para aplicações distribuídas:
Com HTTP resiliente, os componentes podem realizar requisições a serviços REST com possibilidade de retentativas, caso a chamada tenha falhado na primeira vez.
Para sistemas orientados a mensagem, o protocolo AMQP possibilita pub-sub (publicação/assinatura) e enfileiramento de mensagens assíncronas. Quando a comunicação entre serviços precisa ser bidirecional e feita em tempo real, os WebSockets são a melhor opção.
Conhecendo a aplicação
Vamos falar um pouco sobre nossa pequena solução de e-Commerce de exemplo que utiliza o ASP.NET Core para implementar microsserviços.Ela pode ser baixada do GitHub e executada em sua máquina, seguindo as instruções que estão descritas na página do projeto.
Essa solução foi criada inicialmente como um projeto monolítico ASP.NET Core MVC, e progressivamente dividida em múltiplos serviços ASP.NET Core que desempenham tarefas distintas. Assim, no diagrama acima podemos ver uma aplicação WebApp MVC e 4 serviços WebAPI: Catálogo, Carrinho, OrdemDeCompra e IdentityServer.
Podemos descrever a navegação do usuário nesse e-Commerce da seguinte maneira:
um cliente acessa a aplicação MVC, escolhe os produtos e é convidado a fazer o login ou se registrar na aplicação. Em seguida, já autenticado, ele continua adicionando produtos ao seu carrinho e alterando as quantidades.
Após escolher os produtos, nosso cliente preenche seu cadastro e finaliza o pedido recebendo uma mensagem dizendo, que o pedido será gerado e confirmado através de um e-mail.
Como esses serviços lidam com dados?
Respeitando o princípio da arquitetura com microsserviços, cada um deles possui sua própria base de dados:
O serviço de catálogo mantém os produtos num arquivo de banco de dados SQLite. O Carrinho armazena os itens escolhidos por cada cliente num cache Redis em memória. O serviço de Ordem de Compra salva os pedidos gerados numa base SQL Server. O serviço IdentityServer mantém o cadastro num arquivo SQLite.
Ao contrário dos serviços WebAPI, a aplicação MVC não armazena dados.
Cada aplicação também mantém seu próprio modelo de dados, que é independente dos outros serviços, seguindo o princípio de Bounded Context (Contexto Delimitado) do DDD (Domain-Driven Design). Isso garante que o modelo de um serviço possam ser modificado sem introduzir erros em outros serviços.
Como os serviços rodam em aplicações e processos separados, a comunicação entre eles é feita de forma assíncrona e desacoplada:
Em vez de dependências e chamadas diretas, a comunicação é feita através de mensagens. Isso permite que uma aplicação possa delegar uma tarefa a outro serviço, sem ter que esperar pelo término da sua execução.
Como os serviços se comunicam, exatamente?
Quando a página inicial de produtos é carregada, a WebApp MVC conta com a biblioteca Polly para fazer uma requisição HTTP resiliente do serviço de CasaDoCodigo.Catalogo, solicitando a lista de produtos.
Nesse caso, resiliente significa que a requisição se torna tolerante a falhas:
caso o serviço de catálogo esteja indisponível no momento em que a requisição é feita, a aplicação MVC não produzirá uma exceção imediatamente.
Em vez disso, o middleware Polly entra em ação e realiza novas tentativas de requisição até que o serviço responda ou até que o número máximo de tentativas (chamado de Circuit Breaker) seja alcançado. Esses parâmetros são definidos por configuração.
Ou seja, cada vez que um produto é adicionado, removido ou alterado, a aplicação CasaDoCodigo.MVC realiza requisições HTTP resilientes ao serviço CasaDoCodigo.Carrinho, que por sua vez mantém uma cache Redis em memória com os dados do carrinho de cada cliente.
Em um certo momento, o cliente irá preencher os dados e fechar o carrinho de compras. Isso é feito quando a aplicação MVC solicita o fechamento da compra ao serviço de Carrinho
Isso deverá provocar tanto a gravação de um novo pedido quanto a possível alteração do cadastro do cliente. Porém, a base de dados de pedidos está no serviço OrdemDeCompra, e a tabela de cadastro de usuários está no serviço IdentityServer.
Em vez de acessar esses dois serviços diretamente por requisição HTTP, o serviço de carrinho cria duas mensagens (uma com dados do carrinho, outra com dados de cadastro) e as publica numa fila RabbitMQ, que implementa o protocolo AMQP e transporta as mensagens entre os serviços através do Rebus(event bus, ou barramento de eventos).
Essas mensagens assíncronas são destinadas e recebidas pelos serviços que fizeram a assinatura (no padrão pub-sub, ou “publicação e assinatura”) OrdemDeCompra e IdentityServer, que irão tratar de gravar os dados do novo pedido e da alteração de cadastro do usuário, respectivamente.
Quando o serviço OrdemDeCompra lê a mensagem de novo pedido, o componente que recebe a mensagem (handler) do evento não é o mesmo que grava o pedido no banco de dados: esse papel é representado por outra classe, o repositório de pedidos.
Porém, em vez de invocar um método na classe de repositório diretamente, o manipulador do evento envia um comando, que é tratado por um componente intermediário o mediator implementado pela biblioteca MediatR
Esse manipulador cria uma instância do repositório e invoca o método de criação de novo pedido. Esse processo é feito para permitir o desacoplamento entre o manipulador de evento do event bus e a classe de repositório de pedidos.
Podemos pensar nesses comandos como um tipo de mensagem síncrona, que é processada dentro de um mesmo serviço. A biblioteca MediatR implementa dois padrões de projeto: Command e Mediator.
No final, quando o pedido é gravado no banco de dados, o serviço OrdemDeCompra publica uma mensagem em tempo real, feita através de WebSockets com o SignalR.NET, notificando o cliente JavaScript da aplicação MVC, indicando que o novo pedido foi gerado.
Essa indicação de “novo pedido” aparece num contador de notificações na parte superior da página do website, como é comum em diversos aplicativos hoje em dia:
Conclusão
A arquitetura de microsserviços não deve ser usada indiscriminadamente e nem deve ser vista como panaceia para todos os males da tecnologia. Dito isto, microsserviços é um conjunto de técnicas bastante vasto e riquíssimo para o exercício de boas práticas e padrões de arquitetura de serviços, programação de componentes e operações na nuvem.
Felizmente, a plataforma .NET está pronta para oferecer as tecnologias necessárias para vencermos os obstáculos no desenvolvimento de soluções nessa arquitetura. Neste artigo, vimos como usar aplicar esses padrões de arquitetura com a ajuda de algumas tecnologias de comunicação entre serviços.
Agora, que tal você mesmo praticar um pouco a comunicação entre serviços usando ASP.NET Core? Baixe o código-fonte da aplicação de exemplo de e-commerce .NET que acompanha este artigo, e veja como funciona o código para comunicação entre os serviços!
Para saber mais sobre aplicações web e serviços com .NET e ASP.NET Core, dê uma olhada na nossa Formação .NET aqui da Alura! Tem também o curso de microservices com Java e Spring.