Arquitetura de microsserviços com ASP.NET Core
Para implementar o padrão de arquitetura de microsserviços, nós construímos uma coleção de APIs com responsabilidades específicas que trabalham em conjunto e se comunicam através de eventos. Vamos ver como podemos fazer isso.
Antes de iniciarmos, é importante saber porque estamos implementando esse padrão. Para saber mais sobre a arquitetura de microsserviços e seus benefícios, você pode ler os artigos de Chris Richardson. Há também um artigo sobre microsserviços na documentação da Microsoft.
Para apresentar e aprender como podemos implemetar a arquitetura de microsserviços, eu trabalharei em uma solução focada no negócio de varejo de alimentos. Essa solução é um projeto de código aberto chamado Storefront Community.
O objetivo de negócio é reduzir o tempo de espera e oferecer comodidade para os clientes dos restaurantes. Como solução iremos entregar um totem de autoatendimento (self-order kiosk) onde os clientes podem realizar seus pedidos por conta própria. Tecnicamente, para construir um backend para essa solução adotando a arquitetura de microsserviços, eu vou essencialmente seguir esses três passos:
Mas para garantir o desenvolvimento do projeto de forma sustentável, os seguintes processos são muito importantes e devem ser considerados:
- Testes automatizados: Testes automatizados nos permite testar eficientemente todas as funcionalidades de nossos serviços antes de lançarmos uma nova versão. Isso minimiza consideravelmente a incidência de bugs em novas e antigas funcionalidades (teste de regressão). Publicarei um post sobre como podemos escrever testes automatizados para ASP.NET Core API com xUnit.
- CI/CD: Uma ferramenta de integração contínua (CI - continuous integration) e entrega contínua (CD - continuous delivery) executa tarefas automatizadas após alterações realizadas no código fonte e submetidas pela equipe para o versionamento. Essas ferramentas fornecem automação de testes e podem armazenar artefatos (ex. versões compiladas, relatório de testes, etc) e podem também publicar novas versões automaticamente. Escreverei um post sobre como podemos configurar o ASP.NET Core no CircleCI.
- Log de erros: É muito importante monitorar nossas aplicações contra falhas. Há bibliotecas e ferramentas de log (SaaS) que podemos usar para capturar, rastrear, gerenciar erros e notificar a equipe automaticamente. Assim, erros serão reportados pela ferramenta e não pelos usuários, com possibilidade de corrigir esses erros antes mesmo deles notarem o problema. Escreverei um post sobre log de erros em ASP.NET Core com Sentry.
Criar uma API gateway
Uma vez que decidimos implementar o padrão de arquitetura de microsserviços, nós precisaremos de uma API gateway que atuará como um único ponto de entrada responsável por rotear todas as requisições para os outros serviços (outras APIs).
Para realizar essa tarefa você pode consultar um post que escrevi sobre a implementação de uma API gateway com ASP.NET Core e Ocelot. Você também pode encontrar informações sobre esse tema na documentação da Microsoft.
Configurar um event bus
Os serviços destinam-se a desempenhar uma parte específica do negócio e encapsulam sua lógica de implementação e estratégia de persistência. Contudo, eles precisam se comunicar uns com os outros a fim de trabalharem em conjunto para atender às necessidades do negócio.
A comunicação entre os serviços será realizada por meio de eventos e, para que seja estabelecida, são necessários três agentes:
- Event bus (barramento): O canal por onde os eventos serão transmitidos.
- Publisher: O serviço que irá emitir os eventos para o event bus quando seus dados forem atualizados.
- Subscriber: O serviço que escutará um ou mais eventos através do event bus e será notificado quando esses eventos forem disparados.
Publicarei um post sobre como podemos implementar um event bus com RabbitMQ e ASP.NET Core. Também sugiro que você leia o artigo da Microsoft sobre implementação de comunicação entre microsserviços baseada em eventos (eventos de integração) e artigos relacionados com o RabbitMQ.
Construir APIs baseadas em responsabilidade
Nós planejaremos nossos serviços para ter uma única responsabilidade, dessa forma, as equipes poderão focar em desenvolver, manter e publicar cada um de maneira independente.
Entender e definir uma única responsabilidade para cada serviço é uma tarefa delicada e nós devemos fazer isso de forma planejada. Tenha em mente que nós iremos refatorar e continuamente melhorar nossa estratégia com base nos requisitos do negócio.
Esse projeto visa atender uma necessidade do negócio de varejo de alimentos. Tecnicamente, eu irei construir um backend para um totem de autoatendimento e também para um menu board digital. Esses dois aplicativos nos dão uma boa ideia do que pretendemos alcançar.
Nos próximos posts eu escreverei sobre a arquitetura de microsserviços planejada e como ela será construída.
