Gerenciamento de dados distribuídos
Normalmente, os aplicativos monolíticos são apoiados por um grande banco de dados relacional, que define um único modelo de dados comum a todos os componentes do aplicativo. Em uma abordagem de microsserviços, esse banco de dados central seria um obstáculo para o objetivo de criar componentes descentralizados e independentes. Cada componente de microsserviços deve ter a sua própria camada de persistência de dados.
No entanto, o gerenciamento de dados distribuído traz novos desafios. Em consequência do teorema CAP, as arquiteturas de microsserviços distribuídos comprometem inerentemente a consistência para ganhar performance e precisam adotar a consistência final.
Em um sistema distribuído, as transações empresariais podem abranger vários microsserviços. Como eles não podem executar uma única transação ACID, você pode ter de lidar com execuções parciais. Nesse caso, precisaríamos de alguma lógica de controle para executar novamente transações já processadas. Normalmente, o padrão Saga distribuído é usado para essa finalidade. No caso de falha de uma transação empresarial, o Saga orquestra uma série de transações de compensação que desfazem as alterações realizadas pelas transações anteriores. O AWS Step Functions facilita a implementação de um coordenador de execução do Saga, como mostrado na próxima figura.
Coordenador de execução do Saga
A criação de um armazenamento centralizado de dados de referência essenciais que é selecionado por meio de ferramentas e procedimentos de gerenciamento de dados principais oferece aos microsserviços uma forma de sincronizar os dados essenciais e, possivelmente, reverter o estado. O uso do Lambda com eventos programados do Amazon CloudWatch Events permite criar um mecanismo simples de limpeza e eliminação de duplicidades.
É muito comum as mudanças de estado afetarem mais de um microsserviço. Nesses casos, a origem de eventos demonstrou ser um padrão útil. O principal conceito da origem de eventos é representar e manter todas as mudanças de aplicativos como um registro de eventos. Em vez de persistir o estado do aplicativo, os dados são armazenados como um stream de eventos. Os sistemas de registro de transações de banco de dados em log e de controle de versões são dois exemplos conhecidos de origem de eventos. A origem de eventos oferece alguns benefícios: o estado de qualquer point-in-time pode ser determinado e reconstruído. Além disso, ela gera naturalmente uma trilha de auditoria persistente e facilita a depuração.
No contexto de arquiteturas de microsserviços, a origem de eventos permite desacoplar partes diferentes de uma aplicação usando um padrão de publicação/assinatura. Além disso, ela alimenta os mesmos dados de eventos em diferentes modelos de dados para microsserviços separados. Muitas vezes, a origem de eventos é usada em conjunto com o padrão Command, Query, Responsibility, Segregation (CQRS – comando, consulta, responsabilidade, segregação) para desacoplar workloads de leitura das de gravação e otimizar a performance, a escalabilidade e a segurança de ambas. Em sistemas de gerenciamento de dados tradicionais, os comandos e consultas são executados usando o mesmo repositório de dados.
A figura a seguir mostra como o padrão de origem de eventos pode ser implementado na AWS. O Amazon Kinesis Data Streams atua como o componente principal do armazenamento de eventos centralizado, que captura alterações nas aplicações como eventos e os conservam no Amazon S3. A figura retrata três microsserviços diferentes constituídos dos serviços Amazon API Gateway, AWS Lambda e Amazon DynamoDB. As setas indicam o fluxo de eventos: quando o Microsserviço 1 experimenta uma alteração de estado de evento, ele publica um evento gravando uma mensagem no Kinesis Data Streams. Todos os microsserviços executam sua própria aplicação do Kinesis Data Streams no AWS Lambda, que lê uma cópia da mensagem, filtra essa mensagem com base na relevância para o microsserviço e possivelmente a encaminha para processamento posterior. Se sua função retornar um erro, o Lambda tentará executar novamente o lote até que o processamento ocorra com êxito ou os dados expirem. Para evitar fragmentos paralisados, você pode configurar o mapeamento da origem do evento para uma nova execução com um tamanho de lote menor, limitar o número de novas tentativas ou descartar os registros muito antigos. Para reter eventos descartados, você pode configurar o mapeamento da origem do evento para enviar detalhes sobre lotes com falha a uma fila do Amazon Simple Queue Service (Amazon SQS) ou a um tópico do Amazon Simple Notification Service (Amazon SNS).
Padrão de origem de eventos na AWS
O Amazon S3 armazena de forma resiliente todos os eventos de todos os microsserviços e é a única fonte de verdade para fins de depuração, recuperação do estado da aplicação ou auditoria de alterações na aplicação. Há dois principais motivos pelos quais os registros podem ser entregues mais de uma vez à sua aplicação do Kinesis Data Streams: novas tentativas de produtor e novas tentativas de consumidor. Sua aplicação precisa prever e tratar devidamente o processamento de registros individuais várias vezes.
