MICROSSERVIÇOS E O PROBLEMA DO GERENCIAMENTO DE DADOS DISTRIBUÍDOS

CENTRO UNIVERSITÁRIO ALVES FARIA

MICROSSERVIÇOS E O PROBLEMA DO GERENCIAMENTO DE DADOS DISTRIBUÍDOS

DARLAN DUTRA MARTINS

FABIO HENRIQUE PIRES

LUCAS FELICIANO DE SOUZA

Orientador: Daniel de Andrade Lemeszenski

Resumo

Com o avanço da tecnologia o mercado está cada vez mais exigente. A nova geração de clientes deseja cada vez mais uma experiência com sistemas com alta disponibilidade e maior performance. Essa necessidade tem pressionado as empresas a evoluir suas aplicações para serem competitivas no mercado. A solução que vem sendo aplicada pelas empresas é a criação de softwares como serviço utilizando a arquitetura de microservices. A utilização desta arquitetura traz consigo uma gama de possibilidades e benefícios, porém também tem seus desafios sendo um deles lidar com a consistência das informações trafegadas em transações distribuídas. Atualmente existe uma grande quantidade de padrões, bibliotecas, frameworks e ferramentas para desenvolvimento de aplicações. O objetivo deste trabalho é explicar sobre microservices, o conceito de atomicidade, apresentar um padrão não recomendado que é o TWO PHASE COMMIT(2PC) e um recomendado que é o SAGA e suas implementações descrevendo como elas podem solucionar o grande desafio que é lidar com as transações distribuídas, também descrever o uso da ferramenta Apache Kafka que tem o papel de intermediador mensageiro da aplicação também conhecido como Message Broker. A fim de aplicar os conhecimentos descritos no trabalho implementamos um pseudocódigo de um sistema de agendamento e pagamento de viagens.

Palavras-chave: Microservices. Message broker. Saga. Distributed Transactions

Abstract

With the advancement of technology the market is increasingly demanding. The new generation of customers increasingly wants an experience with systems with high availability and greater performance. This need has put pressure on companies to evolve their applications to be competitive in the market. The solution that has been applied by companies is the creation of software as a service using the microservices architecture. The use of this architecture brings with it a range of possibilities and benefits, but it also has its challenges, one of which is dealing with the consistency of information transferred in distributed transactions. Currently, there are a lot of standards, libraries, frameworks and tools for application development. The objective of this work is to explain about microservices, the concept of atomicity, to present a non-recommended standard which is the TWO PHASE COMMIT (2PC) and a recommended one which is SAGA and its implementations describing how they can solve the great challenge that is dealing with the distributed transactions, also describe the use of the Apache kafka tool that has the role of messenger intermediary of the application also known as Message Broker. In order to apply the knowledge described in the work, we implemented a pseudocode for a travel scheduling and payment system.

Keywords: Microservices. Message broker. Saga. Distributed Transactions

Introdução

Nos últimos tempos a tecnologia tem avançado acompanhada por uma grande demanda de softwares como serviço, pressionando as empresas a evoluir  suas aplicações para ser competitiva no mercado de negócio, os clientes estão cada vez mais exigentes e desejam poder acessar suas informações do sistema a todo instante onde quer que estejam, não ter essa possibilidade hoje é a receita perfeita para perder clientes (Becker, 2019).

Um estilo arquitetural que vem ganhando bastante destaque ultimamente é o de micro serviços, que permite implementar novos serviços de maneira reaproveitável, rápida permitindo que sejam escaláveis e resilientes. Possibilitando que as empresas mantenham times especialistas cada qual cuidando de um micro serviço específico e suas regras de negócio, podendo ser implementados em diferentes linguagens (Becker, 2019)

Motivação

Apesar de a arquitetura de micro serviços ser bastante vantajosa essa arquitetura traz consigo uma maior complexidade manter funcionado e consistente. Sendo o principal desafio o gerenciamento de transações distribuídas (Grahl, 2018) Em uma arquitetura monolítica seria mais fácil garantir a integridade dos dados, devido ao fato dos componentes de software estarem dentro da mesma aplicação, tornando viável executar todas as ações dentro de uma única transação. Entretanto, em uma arquitetura distribuída não é possível gerenciar todos os componentes em uma única transação (Grahl, 2018). Então surge a grande questão como é possível garantir a atomicidade dos dados?

Segundo Richardson (2020) a solução para a questão é a utilização de um padrão de projetos chamado de Saga. Resumidamente é uma sequência de transações de negócios que comunicam entre si, através de mensagens/eventos, para acionar a próxima transação da saga. Este padrão tem como característica lidar com situações de falhas, executando uma série de compensações para reverter as alterações de dados anteriores.

Objetivos

Este trabalho visa demonstrar de maneira sucinta como podemos resolver o problema das transações distribuídas utilizando o padrão de projetos Saga. Também detalhar às duas implementações deste padrão que são elas:

Coreografia onde cada micro serviço produz e consome mensagens/eventos decidindo assim o que deve fazer para manipular e/ou persistir seus dados sem a necessidade de um intermediador centralizador, ou seja, é uma abordagem em que cada micro serviço é independente e desacoplada (Grahl, 2018).

Orquestração é uma abordagem em que exige a necessidade do papel de um coordenador ou como o próprio nome da implementação diz um orquestrador, este orquestrador tem a função de centralizar e organizar de maneira sequencial a execução das lógicas de negócio delegando para os micro serviços envolvidos o que cada um deve executar. Em caso de algum problema o orquestrador é responsável realizar as chamadas para os micros serviços para que eles executem a reversão das ações corrigindo os dados que ficaram inconsistentes (Grahl, 2018).

Abordaremos posteriormente que a comunicação entre sistemas distribuídos utilizando o padrão de projetos Saga, necessita de um intermediador o chamado message broker que é uma plataforma que permite que as aplicações/serviços se comuniquem através de mensagens/eventos e abordaremos uma dessas plataformas e o nome dela é Apache Kafka.

Fundamentação Teórica

inserir aqui o capítulo sobre a comparação uma arquitetura distribuída convencional e a arquitetura de microserviços.

O que diferencia a arquitetura de microservices das abordagens monolíticas tradicionais é como ela decompõe a aplicação por funções básicas. Cada função é denominada um serviço e pode ser criada e implantada de maneira independente. Isso significa que cada serviço individual pode funcionar ou falhar sem comprometer os demais.

MICROSERVICES

Microservices é um padrão arquitetural para criação de software a qual divide  o domínio de negócio em pequenas partes, no qual cada uma possui o seu próprio contexto (Gonçalves, 2020).

Segundo Gomes (2019) esse padrão pode ser usado ​​para fragmentar uma grande aplicação monolítica em serviços menores e mais simples. Cada microservice é responsável por lidar com seu próprio escopo, sendo especialista no que faz, então o “Micro” em microsserviços refere-se a uma parte pequena do sistema, não a quantidade de linhas do código nem tanto do tamanho em megabytes do monólito.

Com a introdução da arquitetura de microservices, os bancos de dados estão perdendo sua característica ACID (Atomicidade, consistência, isolamento, durabilidade). Devido o possível envio de transações entre muitos microservices e banco de dados é necessário lidar com alguns problemas comuns neste cenário, como por exemplo, manter a atomicidade das transações  (Gonçalves, 2020).

O QUE É UMA TRANSAÇÃO?

O principal objetivo de uma transação é garantir a integridade e a consistência dos dados. Dentro de um contexto de microserviços, é comum que cada microserviço gerencie seus próprios dados. Diante deste cenário como é podemos garantir a consistência dos dados entre microservices? Uma alternativa é transitar dados utilizando transações distribuídas (Amoedo, 2018).

O QUE É UMA TRANSAÇÃO DISTRIBUIDA?

Uma transação distribuída é basicamente uma sequência de operações que tem como objetivo garantir que todas operações sejam executadas com sucesso, ou nenhuma, caso uma das operações falhe. Então garantir a atomicidade entre os microservices significa que, em qualquer transação, todas as etapas podem ser concluídas ou nenhuma (Gonçalves, 2020).

Atomicidade

Quando falamos de atomicidade estamos nos referimos ao princípio que garante que os dados estejam íntegros em todo o ecossistema que envolve a aplicação. 

O que é integridade?

O conceito de integridade é a garantia de precisão dos dados em todo o seu ciclo de vida. Em arquiteturas do tipo monolítico a solução que quase sempre é utilizada é o recurso transacional de banco de dados, que isola o processo de persistência de dados. Caso ocorra algum erro, o SGBD reverte as alterações realizadas (Gonçalves, 2020)

Quando a integridade dos dados não é colocada em risco, o leque de problemas que podem vir a dificultar o funcionamento da aplicação se abre. Falhas de infraestrutura, como comunicação entre ambientes, bugs ou erros de regra de negócio podem gerar quebra em qualquer momento do fluxo de processamento (Gonçalves, 2020).

No contexto de microservices em caso de erro em uma operação, para que continue existindo atomicidade no ecossistema, devem ser realizadas ações compensatórias para a correção dos dados e todos serviços já chamados devem ser invocados novamente para reverter a alteração feita. Assim, todas as bases estarão integras de acordo com seu escopo não onerando a veracidade de seus dados (Gonçalves, 2020).

Uma possível solução para requerer o uso de um protocolo que garanta atomicidade dos dados distribuídas é o conhencido Two Phase Commit (2PC). Apenas para ficar um pouco mais claro, esse protocolo normalmente é implementado e disponibilizado pelo próprio banco de dados distribuído.

Two Phase Commit (2PC)

Existem algumas formas tradicionais para que possamos garantir a atomicidade em banco de dados distribuídos. Como cada microsserviço está conectado a uma base de dados distinta, não existe garantia de atomicidade. Uma possível solução requer o uso de um protocolo que garanta atomicidade na execução de operações distribuídas. O mais conhecido deles é chamado de Two Phase Commit (2PC) (Omar, 2020).

Apenas para ficar um pouco mais claro, esse protocolo normalmente é implementado e disponibilizado pelo próprio banco de dados distribuído. No entanto, os problemas de 2PC são bem conhecidos. Por exemplo, o protocolo tem um custo e uma latência altos. Isso ocorre porque os processos participantes de uma transação distribuída têm que trocar diversas mensagens, antes de chegarem a um consenso sobre o seu resultado (Omar, 2020).

Em uma situação de limite, pode-se chegar a uma situação de impasse, isto é a transação pode ficar bloqueada por um tempo indeterminado no caso de queda do processo coordenador do protocolo. Por isso, alguns autores recomendam explicitamente que microserviçes não devem usar 2PC. Com isso, começou-se a procurar alternativas mais viáveis para consistência dos dados de microserviçes . Uma delas é o conceito de sagas, que descreveremos a seguir (Omar, 2020).

 MICROSSERVICES E ARQUITETURA DISTRIBUÍDA CONVEVIONAL

A arquitetura de microserviçes deve separar as responsabilidades de dados para entender o gerenciamento de atualizações separadamente, sem a necessidade de transações distribuídas atomicamente (transações ACID).

Todos os escopos de transação são controlados pelo supervisor de microserviçes dentro de seu contexto e limites de transação apropriados, e as etapas de limpeza devem ser consideradas do início ao fim do processo.

Os microserviçes têm muitos benefícios, mas esses benefícios, seja na fase de desenvolvimento ou na fase de implantação, têm um preço.

Complexidade operacional relacionada a sistemas distribuídos, compreensão geral do sistema (natureza distribuída), dificuldade de depuração (solução de problemas), registro e rastreamento distribuído, etc.

Obriga-nos a abandonar o conceito de transações atômicas, amplamente utilizadas em aplicações monolíticas, que irão transcender toda a cadeia de processamento, bloqueando todas as comunicações e recursos do início ao fim, o que obviamente se torna inviável em sistemas distribuídos. Antecessores dos microserviçes 

O conceito de microserviçes não é novo, ele teve sua origem nos sistemas distribuídos na década de 1970.

Usamos os principais conceitos por trás da arquitetura de microserviçe, como arquitetura orientada a serviços (SOA), modelos de participantes ou mesmo ideias do modelo orientado a objetos original por mais de 50 anos.

Service Oriented Architectures (SOA) é, em tradução livre, Arquitetura Orientada a Serviços. Esse conceito de arquitetura busca disponibilizar as funcionalidades de um sistema como um serviço.

Desta forma, essas funcionalidades podem ser compartilhadas e reutilizadas entre aplicações. Seu principal objetivo é ser mais flexível em atender às necessidades do mercado.

Todos esses modelos anteriores (principalmente SOA) já possuem os principais aspectos relacionados à arquitetura de microserviçe que vemos hoje, trazendo os aspectos bons dos microserviçe que foram previstos em SOA.

Além disso, do ponto de vista conceitual envolvendo SOA (o predecessor direto dos microserviçes), criando um serviço e hospedando-o no mesmo servidor, adicionando várias funções consistentes dentro do mesmo componente e implantando o serviço no mesmo processo de forma errada.

Vantagens de Arquitetura Distribuída 

Ao usar microservices , a divisão da equipe pode incluir menos membros (pertencentes a uma pequena equipe), resultando em maior agilidade. Essas equipes podem trabalhar em diferentes contextos restritos e são responsáveis pela entrega de microservices relacionados a um determinado contexto. Ao adotar um formato de implantação mais contínuo, além de desvincular a equipe e sua entrega, também podemos aumentar a produtividade com mais rapidez. Portanto, vimos várias vantagens em componentes de software entregues usando uma arquitetura de microservices distribuída.

Desvantagens de Arquitetura Distribuída 

Por outro lado, existe uma grande diferença entre os aplicativos monolíticos de escalonamento horizontal, pois este tipo de escalabilidade envolve uma instância do servidor de aplicação.

Como em qualquer movimento que envolva decisões arquitetônicas, há vantagens e desvantagens em todas as direções, que inevitavelmente levam a compensações. De modo geral, o estilo de comunicação na arquitetura de microsevices é muito complexo, pode envolver padrões diferentes, como REST e HTTP ou AMQP, e pode ser síncrono ou assíncrono por natureza. eventos). Além disso a rastreabilidade dos serviços é mais complexa.

Padrão SAGA

Existe um padrão de projeto chamado SAGA que conta com duas estratégias de utilização: coreografia e orquestração. As duas possuem suas particularidades, mas trabalham para resolver esse problema apresentado de transações distribuídas (Richardson, 2020).

Implementar cada transação de negócios que abrange vários serviços é uma saga. Esse padrão é uma sequência de transações locais, cada transação atualiza seu banco de dados e publica uma mensagem ou evento para acionar a próxima transação local da saga. Se uma transação falhar porque viola uma regra de negócios, será executado uma série de transações de compensação que desfazem as alterações feitas pelas transações locais anteriores (Dashora, 2019).

Nem sempre o SAGA vai resolver esse problema de transações distribuídas, mas pode ser considerado um padrão bem utilizado para tal (Dashora, 2019).

Há duas abordagens comuns de implementação do padrão SAGA, coreografia e orquestração. Cada abordagem tem seu próprio conjunto de desafios e tecnologias para coordenar o fluxo de trabalho como será descrito a seguir (Dashora, 2019).

Coreografia

Coreografia é uma maneira de coordenar sagas em que os participantes trocam eventos sem um ponto de controle centralizado. Com a coreografia, cada transação local publica eventos de domínio que disparam transações locais em outros serviços (Microsoft, 2021).

Na coreografia cada passo é implementado por um microservices, ao final de cada etapa uma chamada de forma assíncrona é realizada ao próximo, finalizando seu processamento com sucesso. O próximo serviço da coreografia então recebe os dados do serviço anterior, faz seu processamento e chama o próximo serviço e assim por diante (Microsoft, 2021).

Um dos pontos fortes dessa estratégia é não haver um ponto único de falha, mas, em contrapartida, entramos em outros desafios da arquitetura de microservices, como por exemplo, logues distribuídos, rastreio e assincronia.

Um ponto de atenção é observar que cada serviço deve conhecer o próximo até não haver um próximo, resultando no fim do fluxo (Microsoft, 2021).

Como explicado anteriormente, por se tratar de transações independentes respondendo de forma assíncrona, qualquer falha resulta em um evento de cancelamento para todos os serviços envolvidos que participaram do fluxo (Microsoft, 2021).

Figura 1 — Arquitetura Saga "Coreografia"
Arquitetura Saga "Coreografia"Os autores (2021)

Vantagens e Desvantagens

Vantagens 

  • Recomendado para contextos mais simples não exigindo o papel de um o coordenador que gerencie.
  • Não é necessário implementação adicional de controle de falhas.
  • Por ser descentralizado não possui um ponto único de falha (Microsoft, 2021).

Desvantagens

  • Na medida que o fluxo de trabalho cresce pode ficar confuso adicionar novas etapas, tornando difícil gerenciar a resposta dos participantes da saga.
  • Por haver falha no consumo devido à referência cíclica entre os participantes da saga porque eles precisam consumir os comandos uns dos outros.
  • Existe uma dificuldade para realizar testes de integração pois todos os serviços devem estar ativos para ser feito o teste (Microsoft, 2021).

Orquestração

Outra implementação do padrão SAGA é a orquestração que trabalha de forma síncrona, delegando a um "responsável" o poder de organizar esse fluxo de entrega, centralizando as chamadas dos microsserviços e separando por passos ou pequenos fluxos.

Cada chamada é feita de forma sequencial, aguardando sempre a finalização de uma para começar outra. Ao falhar qualquer chamada, seja por erros sistêmicos ou regras de negócio o próprio orquestrador faz ações compensatórias, chamando novamente cada serviço que completou sua ação para reverter sua parte.

Uma boa prática e recomendação é evitar adicionar lógica de negócio nesse “orquestrador”, para que ele seja somente um proxy das chamadas das atividades.

Na abordagem de orquestração, definimos um novo serviço com a responsabilidade exclusiva de dizer a cada participante o que fazer e quando. O orquestrador de padrões saga se comunica com cada serviço em um estilo de comando / resposta informando qual operação deve ser executada. Order Saga Orchestrator sabe qual é o fluxo necessário para executar uma transação de “criação de pedido”. Se algo falhar, ele também é responsável por coordenar o rollback, enviando comandos a cada participante para desfazer a operação anterior. Uma maneira padrão de modelar um orquestrador de saga é uma máquina de estado em que cada transformação corresponde a um comando ou mensagem. As máquinas de estado são um excelente padrão para estruturar um comportamento bem definido, pois são fáceis de implementar e particularmente ótimas para teste. As reversões são muito mais fáceis quando você tem um orquestrador para coordenar tudo. O serviço responde ao Orquestrador de Saga de Pedidos (OSO) com uma mensagem Out-Of-Stock. Orquestrador de Saga de Pedidos (OSO) reconhece que a transação falhou e inicia o rollback. No caso de apenas uma única operação ter sido executada com sucesso antes da falha o OSO envia um comando Refund client é define o estado do pedido como falhado.

Figura 2 — Arquitetura Saga "Orquestração"
Arquitetura Saga "Orquestração"Os autores (2021)

Vantagens e Desvantagens

Vantagens/


  • Não existe o risco de referência cíclica devido ao fato de orquestrador ser o responsável por realizar chamadas aos microservices, não sendo permitido o contrário.
  • Simplifica o contexto dos microservices, fazendo com que eles apenas enviem e recebam comandos.
  • Diminui a possibilidade de criar complexidade ao adicionar novas ações.
  • É mais facil reverter ações.
  • Cada transação é enfileirada pelo orquestrador.

Desvantagens

  • Existe a possibilidade de escrever muita lógica no orquestrador se tornando a inteligência do negócio.

  • Aumenta um pouco a complexidade da sua infraestrutura, pois você precisará gerenciar um serviço extra. 
  • A desvantagem de ter essa centralização do fluxo de transações distribuídas é que pode resultar no ponto único de falha, dependência que pode ser custosa. 

Recapitulando, o principal benefício do padrão SAGA é que ele ajuda a manter a consistência dos dados em vários serviços sem um acoplamento rígido. Este é um aspecto extremamente importante para uma arquitetura de microsserviços.

No entanto, a principal desvantagem deste padrão é a complexidade inicial de desenvolvimento. Além disso, os desenvolvedores não estão tão acostumados a desenvolver sagas em relação as transações tradicionais. Outro desafio é que as transações de compensação também precisam ser planejadas para fazer as sagas funcionarem.

Um dos facilitadores para implementação do padrão é inserir orquestrador um broker. O broker mais adotado e utilizado pelo mercado é o Apache Kafka. Ele tem sido usado por empresas como Netflix, Spotify, Uber, LinkedIn e Twitter, como veremos a seguir.

Quando falamos de solução em TI sempre chegamos a mesma resposta: “Tudo depende”. Cada abordagem tem seus pontos fortes e fracos, um bom resultado é gerado de acordo com cada situação e seu ambiente. 

Apache Kafka

O Apache Kafka foi criado como uma solução interna de infraestrutura na LinkedIn para lidar com os dados como um fluxo contínuo e crescente de informação para aplicações. Externamente ele se comporta como um sistema de mensageria onde mensagens são publicadas e consumidas, similar a soluções como ActiveMQ, RabbitMQ, IBM’s MQSeries e outros, mas internamente foi desenhado para ser um sistema distribuível, escalável e confiável (Queiroz, 2017).

Por que usar Mensagem?

Uma técnica bastante importante e utilizadas nos dias atuais, para que possamos deixar nossos sistemas/microserviços desacoplados são a necessidade de comunicação entre os serviços por mensagem, basicamente o apache Kafka encaminha qualquer tipo de mensagem que chega até ele. O sistema de mensagens permite desacoplar a geração dos dados do seu processamento de forma assíncrona, assim, uma aplicação pode continuar funcionando sem esperar a outra terminar seu processamento (Queiroz, 2017).

Vantagens de utilizar Sistema de mensagem

Serviço orientado a mensagem tem o potencial de diminuir a necessidade de leitura, por exemplo, no banco de dados. Sistemas de mensagem podem ser usados em qualquer área. Viagem, finanças, logística, mapas, transporte público e varejo. Então podemos dizer que o Apache Kafka é um sistema de streaming de mensagens bastante robusto. O Apache Kafka é um sistema de mensagens usado para criar aplicações de streaming, ou seja, aquelas com fluxo de dados contínuo. O Kafka é baseado em logs, algumas vezes chamado de write-ahead logs, commit logs ou até mesmo transaction logs (BritoCostaAlves, 2019).

O que é um log?

Um log é uma forma básica de armazenamento, porque cada nova informação é adicionada no final do arquivo. Este é o princípio de funcionamento do Kafka. O Kafka é adequado para soluções com grande volume de dados ( porque uma das suas características é a alta taxa de transferência (BritoCostaAlves, 2019).

O que é Stream?

Um dos métodos muito importante utilizado pelo apache Kafka é o data streaming, basicamente um fluxo de dados constante e sem controle é chamado de data streaming. Sua principal característica é que os dados não tem limites definidos, assim, não é possível dizer quando começa ou acaba o fluxo (stream). Os dados são processados à medida  que chegam no destino. Alguns autores chamam de processamento em tempo real, ou on-line. Uma abordagem diferente é o processamento em bloco, batch, ou off-line, nos quais blocos de dados são processados em janelas de tempo de horas ou dias. Muitas vezes o batch é um processo que roda a noite, consolidando os dados daquele dia. Há casos de janelas de tempo de uma semana ou mesmo de um mês, gerando relatórios desatualizados (Queiroz, 2017).

Porque usar serviço de stream?

Já que o mundo tem gerado um volume cada vez maior de informações se torna imprescindível a utilização do apache Kafka, pois a demanda de dados simultâneo para ser processado a cada dia vem aumentado. Um cenário comum é que estes dados, uma vez gerados, precisam ser transportados para diversas aplicações. Por exemplo, quando fazemos uma compra com cartão de crédito a operadora precisa avisar várias aplicações diferentes para contabilizar a compra, os benefícios e até a análise contra fraudes. Neste caso, é desejável que cada aplicação seja responsável pela implementação das regras do negócio, e apenas isso, uma aplicação não deveria se preocupar com a entrega ou captura dos dados (Queiroz, 2017).

Funcionalidade do Kafka.

  • Sistema de mensagem do tipo publish/subscribe;
  • Sistema de armazenamento: as mensagens ficam armazenadas por um período de tempo pré-definido. 
  • Por padrão, as mensagens duram 7 dias, mas podem até mesmo ficar indefinidamente;
  • Processamento de stream: é possível transformar a mensagem imediatamente após o seu recebimento.

Basicamente, o Kafka é um intermediário que coleta os dados da fonte e entrega para uma aplicação que consumirá esses dados, como visto na imagem abaixo:

Figura 3 — Detalhes Funcionamento Kafka
Detalhes Funcionamento KafkaOs autores (2021)

Segundo Brito, Costa e Alves (2019) os sistemas de mensagem podem ser de dois tipos: point-to-point e publish-subscribe. O Apache Kafka é do segundo tipo, no qual uma aplicação que publica (publish) e uma aplicação que se inscreve (subscribe) para receber as mensagens. O tempo entre publicar e receber a mensagem pode ser de milissegundos, assim, uma solução Kafka tem baixa latência. A arquitetura do Apache Kafka, vista com mais detalhe na seção a seguir, combina diversas outras características, como:

  • Escalabilidade: o cluster pode ser facilmente redimensionado para atender ao aumento ou diminuição das cargas de trabalho;
  • Distribuído: o cluster Kafka opera com vários nós, dividindo o processamento;
  • Replicado, particionado e ordenado: as mensagens são replicadas em partições nos nós do cluster na ordem em que chegam para garantir segurança e velocidade de entrega;
  • Alta disponibilidade: o cluster tem diversos nós (brokers) e várias cópias dos dados, assim. 

Arquitetura do Apache Kafka

Sua arquitetura é composta por producers, consumers e o próprio cluster. O producer é qualquer aplicação que publica mensagens no cluster. O consumer é qualquer aplicação que recebe as mensagens do Kafka. O cluster Kafka é um conjunto de nós que funcionam como uma instância única do serviço de mensagem. Um cluster Kafka é composto por vários brokers (BritoCostaAlves, 2019).

O que é um broker?

Um broker é um servidor Kafka que recebe mensagens dos producers e as grava no disco. Cada broker gerencia uma lista de tópicos e cada tópico é dividido em diversas partições.

Depois de receber as mensagens, o broker as envia para os consumidores que estão registrados para cada tópico. Veja a imagem:

Figura 4 — Arquitetura Apache Kafka
Arquitetura Apache KafkaOs autores (2021)

As configurações do Apache Kafka são gerenciadas pelo Apache Zookeeper, que armazena os metadados do cluster, como localização das partições, lista de nomes, lista de tópicos e nós disponíveis. Assim, o Zookeeper mantém a sincronização entre os diversos elementos do cluster. Isso é importante porque o Kafka é um sistema distribuído, ou seja, as gravações e leituras são feitas por diversos clientes simultaneamente. Quando há uma falha, o Zookeeper elege um substituto e recupera a operação (BritoCostaAlves, 2019).

Onde o kafka persiste as mensagens?

Uma curiosidade é que o Apache Kafka persiste a mensagem no disco e não na memória, como se imagina ser mais rápido. De fato, o acesso à memória é mais rápido na maioria das situações, principalmente quando consideramos acesso a dados que estão em posições aleatórias na memória. Contudo, o Kafka faz acesso sequencial e, neste caso, o disco é mais eficiente. Há outras ferramenta de big data que trabalham da mesma forma, como por exemplo o Hadoop Distributed File System (HDFS). No acesso sequencial o disco sabe onde começa e termina o bloco de dados, enquanto que no acesso aleatório o disco precisa procurar e se mover para a posição dos blocos de dados. É como se os dados estivessem ordenados. Pensando assim, o Kafka lê os dados como se fosse um livro, da primeira para a última página. Quando temos leitura/gravação aleatória seria como ler o mesmo livro, mas com as páginas misturadas. Por se tratar de um projeto bastante otimizado o apache Kafka tem ótima performance, mesmo com hardware limitado. Ainda assim é necessário otimizar o clusterquando temos grandes cargas de dados. Para escalar usamos várias estratégias, geralmente testando as combinações de configuração, por exemplo, alterando o número de produtores, consumidores dos tópicos (Adiviseu, 2020).

CARACTERÍSTICAS DO APACHE KAFKA

As empresas veem usado cada vez mais o Apache Kafka para implementar a arquitetura de microserviçes. Tradicionalmente, a comunicação entre microservices é feito pelo protocolo HTTP com REST, à medida que a quantidade de microservices aumenta, amplia a complexidade para integração. A seguir listaremos as principais características do Kafka.

  • Desacoplamento entre o produtor e o consumidor da mensagem: isso aumenta até a velocidade de desenvolvimento;
  • Alta disponibilidade: mesmo quando um microservice fica indisponível, o sistema continua funcionando;
  • Baixa latência: a transferência é imediata.

O projeto de novas arquiteturas costuma levar em consideração o uso de ferramentas de troca de mensagens, especialmente com o envio de dados assíncronas, centralizando a integração de dados em um broker. Podemos então constatar como o apache Kafka vem crescendo rapidamente, fornecendo um conjunto de serviços escaláveis que possibilitam a integração dos dados em tempo real, com vários benefícios chaves, entre eles podemos citar:

  • Baixa latência e alto throughput:

Pode agir como um bufferpara que os sistemas não travem. Baixo acoplamento entre os microservices. Tornando-se então  uma plataforma de streaming de eventos distribuídos de código aberto muito robusto (BritoCostaAlves, 2019).


DESENVOLVIMENTO DE UM CASO DE USO

Vamos utilizar a arquitetura abaixo como modelo para o desenvolvimento do caso de uso.

Figura 5 — Arquitetura Projeto vendas
Arquitetura Projeto vendasOs autores (2021)

O caso de uso selecionado para mostrar o funcionamento de uma solução Kafka será a integração entre um sistema de agendamento e pagamento de viagens. A ideia é explorar várias possibilidades, mesmo que nem todas sejam usadas na sua realidade. Entre os sistemas está o Apache Kafka, que funciona como o integrador dos dados em tempo real. Vamos criar diversos tópicos para alimentar cada uma das fontes de dados da solução, registrando desde a navegação no site até a conclusão da venda. Os tópicos que definimos para atender a esta demanda foram:

TOPICO_NOVA_VENDA: o site de vendas notifica cada nova venda;

TOPICO_NAVEGACAO_USUARIO: O servidor web notifica cada nova navegação do usuário; 

TOPICO_AGENDAMENTO_TRAVEL: o site de vendas notifica cada nova venda;

TOPICO_NOVO_USUARIO: O site de vendas notifica cada novo usuário;

TOPICO_AGENDAMENTO_FLY: O site de vendas notifica cada nova agendamento de voo;

TOPICO_DEVOLUCAO: O site de vendas notifica cada nova devolução de produto;

TOPICO_NOTIFICA_USUARIO: O site de vendas notifica o usuário;

TOPICO_AGENDAMENTO_HOTEL: O site de vendas notifica cada novo agendamento de hotel

TOPICO_AGENDAMENTO_CAR: O site de vendas notifica cada novo agendamento de carros

TOPICO_AGENDAMENTO_PAY: O site de vendas notifica cada novo pagamento

O TOPICO_NOVA_VENDA receberá uma mensagem cada vez que uma venda for realizada. Com o suporte do Kafka Streams esta mensagem será transformada em um registro de banco de dados para ser gravado no BI. Isso garante atualização em tempo real do BI. Além do BI, pode-se gravar os registros consolidados de vendas na a ferramenta de visualização de dados utiliza uma versão consolidada deste conjunto de dados, como o Tableau ou Qlik. Para coletar os dados diretamente do banco podemos usar um CDC , ou alterar a aplicação para enviar a mensagem quando gravar a venda.

O TOPICO_NOVO_USUARIO receberá uma mensagem para cada novo usuário cadastrado. Essa informação será usada futuramente pelo analytics, por exemplo, para receber ofertas personalizadas a partir do seu histórico de navegação.

O TOPICO_RECLAMACAO receberá uma mensagem para cada nova reclamação. Essa informação será usada também pelo analytics, para minimizar o customer churn, que é o percentual de clientes que param de usar seus produtos. É sempre bom saber o motivo de insatisfação dos clientes.

O TOPICO_DEVOLUCAO receberá uma mensagem para cada devolução de produto, uma informação importante para avaliar a qualidade dos produtos e a satisfação do cliente.

O TOPICO_NOTIFICA_USUARIO receberá uma mensagem para cada notificação a ser enviada para os clientes. Essa notificação é criada pelo analytics, no módulo de machine learning que identifica as ofertas mais adequadas àquele perfil.

O TOPICO_AGENDAMENTO_TRAVEL receberá uma mensagem para cada notificação a ser enviada para a viagem. Nesse microserviços será responsável por notificar cada cliente de suas viagens marcada, caso de ocorra problema em algum agendamento de carro, hotel ou voo o cliente será notificado também através desse tópico.

O TOPICO_AGENDAMENTO_HOTEL receberá uma mensagem para cada notificação a ser enviada para o hotel. Nesse microserviços será responsável por realizar agendamento, consulta é ate exclusão do agendamento de hotel.

O TOPICO_AGENDAMENTO_CAR  receberá uma mensagem para cada notificação a ser enviada para o aluguel de carro. Nesse microserviços será responsável por realizar agendamento, consulta é ate exclusão do agendamento de carros.

O TOPICO_AGENDAMENTO_PAY receberá uma mensagem para cada notificação de pagamento realizado com sucesso. Nesse microserviços será responsável por notificar a todos os envolvidos que o pagamento da viagem foi realizado com sucesso ou não. Esse microservices notificará também a falta de pagamento caso haja.

Conclusão

Todo o estudo apresentado foi de grande valia para certificamos a importância do uso de arquitetura distribuída, claro que nem tudo são flores, contudo conseguimos provar que os benefícios dessa arquitetura são maiores que as desvantagem. Apresentamos assuntos pertinentes no que se diz microservices, contextualizamos o uso de um designer pattern bastante usado pela comunidade de desenvolvedores é arquitetos que é o SAGA, nesse padrão conseguimos explicar diversos conceitos que apoia a tecnologia como a coreografia, orquestração, que são conceitos que permite a implementação de acordo com os requisitos. Demonstramos um conceito muito importante que é o message broker que seria o orquestrador do conceito SAGA. Para chegar em todos esses conceitos foi explicado de forma bem clara tudo que rodeia esses conceitos, como integridade, atomicidade, contextualizo o que é mensagem é o seu funcionamento, streams, logs, apache kafka, com isso tivemos uma boa base de estudo para certificar a importância do uso de arquitetura de microservices é como resolver seu principal desvantagem o gerenciamento de dados distribuídos.

Após, o surgimento da demanda nos últimos tempos, a arquitetura distribuída trouxe importância para a solução e evolução de suas aplicações no mercado de negócios, uma estrutura de arquitetura que vem aumentando na década atual. Beneficiando empresas e negócios a manterem seus sistemas com qualidade e rapidez de ambas as partes do lado do usuário e da empresa de software atuante no mercado.

Neste trabalho, buscamos demonstrar algumas soluções para se trabalhar com gerenciamento de transações distribuídas, foi utilizado como uma solução para esse problema o padrão saga e o poderoso message broker apache kafka, que é responsável por orquestrar todo o envio de mensagem entre os microservices. A utilização do pattern SAGA trouxe grandes benefícios as empresas que a utilizam, como a garantia a consistência dos dados em um sistema distribuído sem acoplamentos rígidos, uma transação será dividida em um conjunto de transações menores, conectadas por mensagens, que devem ser commitadas ou realizadas roll back individualmente, serviços independentes respondendo de forma assíncrona, qualquer falha resulta em um evento de cancelamento para todos os serviços integrados que participaram do fluxo até então, enfim os benefícios são grandes.

Para fundamentar ainda mais todos os conceitos abordados uma possivel solução para tornar todas as tecnologias ainda mais conectadas seria o estudo de uma api gateway para realizar o balanceamento de cada chamada de microservices deixando assim toda a arquitetura de forma autônoma. 

Referências

Adiviseu. Conceitos básicos do Apache Kafka. Adiviseu. 2020. Disponível em: https://www.adviseu.com.br/conceitos-basicos-do-apache-kafka/. Acesso em: 24 fev. 2021.

AmoedoRaphael . Transações distribuídas em microserviços. Medium. 2018. Disponível em: https://medium.com/olxbrasiltech/transações-distribuídas-em-microserviços-345243925da5. Acesso em: 4 mar. 2021.

BeckerAlex Malmann. O Impacto do Uso de Micro Serviços na Evolução de uma Linha de Produto de Software. 2019. 89 p. Disponível em: https://repositorio.ufscar.br/handle/ufscar/11978. Acesso em: 15 fev. 2021.

BritoRodrigo; CostaMarcelo; AlvesMárcio. Uma introdução ao Apache Kafka, lições aprendidas em um ambiente de varejo. Infoq. 2019. Disponível em: https://www.infoq.com/br/articles/apache-kafka-licoes/. Acesso em: 1 mar. 2021.

Chris Richardson. Managing data consistency in a microservice architecture using Sagas part 2 - coordinating sagas. Microservices. 2019. Disponível em: https://chrisrichardson.net/post/sagas/2019/08/04/developing-sagas-part-2.html. Acesso em: 5 mar. 2021.

DashoraSaurabh. Microservices Using the Saga Pattern. DZone. 2019. Disponível em: https://dzone.com/articles/microservices-using-saga-pattern. Acesso em: 7 fev. 2021.

GomesDaniel . Introdução a Microsserviços. Medium. 2019. Disponível em: https://medium.com/@danieldggomes. Acesso em: 4 mar. 2021.

GonçalvesMarcelo M. Arquitetura de Microsserviços. Medium. 2020. Disponível em: https://medium.com/@marcelomg21. Acesso em: 7 fev. 2021.

GrahlCarlos Augusto . Transações distribuídas em micro-serviços. 2018. Disponível em: https://medium.com/senior/transações-distribuídas-em-micro-serviços-70568b378d77. Acesso em: 15 fev. 2021.

Microsoft. Transações distribuídas do saga. Microsoft. 2021. Disponível em: https://docs.microsoft.com/pt-br/azure/architecture/reference-architectures/saga/saga. Acesso em: 5 mar. 2021.

OmarSaurav. 2PC: Two-phase commit protocol. Medium. 2020. Disponível em: https://sauravomar01.medium.com/2pc-two-phase-commit-protocol-4ba47e441cdf. Acesso em: 4 fev. 2021.

QueirozGabriel. O que é esse tal de Apache Kafka?. Medium. 2017. Disponível em: https://medium.com/@gabrielqueiroz/o-que-é-esse-tal-de-apache-kafka-a8f447cac028. Acesso em: 1 mar. 2021.

RichardsonChris . Pattern: Saga. microservices. 2020. Disponível em: https://microservices.io/patterns/data/saga.html. Acesso em: 11 dez. 2020.

RosaDenis Wilson Souza. Saga Pattern : Application Transactions Using Microservices – Part I. Couchbase. 3250 Olcott Street Santa Clara, CA 95054 United States, 2018. Disponível em: https://blog.couchbase.com/saga-pattern-implement-business-transactions-using-microservices-part/. Acesso em: 14 dez. 2020.

RosaDenis Wilson Souza. Saga Pattern: How to Implement Business Transactions Using Microservices – Part II. COUCHBASE. 3250 Olcott Street Santa Clara, CA 95054 United States, 2018. Disponível em: https://blog.couchbase.com/saga-pattern-implement-business-transactions-using-microservices-part-2/. Acesso em: 14 dez. 2020.

RosaDenis. Saga Pattern | How to Implement Business Transactions Using Microservices – Part II. Couchbase. 2018. Disponível em: https://blog.couchbase.com/saga-pattern-implement-business-transactions-using-microservices-part-2/. Acesso em: 7 fev. 2021.

Use agora o Mettzer em todos
os seus trabalhos acadêmicos

Economize 40% do seu tempo de produção científica