Uma vez que a sociedade aderiu à mobilidade constante, aplicações devem disponibilizar dados em tempo real — não apenas o resultado final em uma tabela armazenada em um banco de dados, mas também todas as ações executadas por um usuário da solução. Qualquer informação compartilhada, como cliques, log data ou sensor data, é utilizada para aprimorar a experiência, gerar relatórios, alimentar sistemas de machine learning e por aí vai. Hoje, desenvolvedores devem voltar suas atenções a sistemas baseados no fluxo de eventos em tempo real.
A imagem a seguir mostra um exemplo de uma arquitetura baseada no processamento do fluxo de eventos:
IBM Event Streams é uma instância gerenciada Kafka para sua empresa.
Apache Kafka é uma solução indicada para a criação de sistemas escaláveis de eventos complexos. A ferramenta proporciona recursos constantemente aprimorados para plataformas de streaming de eventos que desenvolvedores podem usar em soluções avançadas de negócios. Contudo, eles frequentemente precisam integrar soluções Java empresariais baseadas em tecnologias como IBM MQ ou IBM WebSphere Application Platform às novas arquiteturas.
Considere o seguinte exemplo. Uma loja virtual possui um aplicativo que utiliza Kafka para enviar dados de pagamento a um sistema de pagamento distribuído implementado em Java empresarial. A solução deve fornecer garantia absoluta de processar uma solicitação de pagamento uma única vez (para evitar cobranças múltiplas do comprador). Contudo, falhas são inevitáveis em um sistema distribuído, então a solução precisa lidar com os problemas da melhor maneira possível.
Implementando messaging com Apache Kafka
Apache Kafka é um sistema distribuído utilizado para processamento de fluxo de eventos amplamente utilizado em arquiteturas de microsserviços e ambientes baseados em nuvem. Ele fornece mensagens, armazenamento e processamento de eventos — tudo na mesma plataforma.
A imagem abaixo mostra uma topologia básica dos componentes do Apache Kafka, formados por produtores e consumidores que trocam mensagens por meio da infraestrutura do cluster Kafka:
Mesmo que traga muitas vantagens, Kafka enfrenta problemas como:
- Lógica de compensação manual nos casos de falhas de processamento de mensagens, o que pode resultar no não processamento dos dados.
- Falta de suporte de processamento para transações XA.
- Garantia de somente um processamento de entrega nas aplicações do consumidor.
- Esforço extra de desenvolvimento e manutenção para a integração da ferramenta a soluções empresariais.
Para resolver essas questões, é possível aplicar os conceitos topológicos tradicionais de messaging, como logs de transação, logs de recuperação e transações XA, assim como implementar um adaptador de recursos baseado no Java EE Connector Architecture (JCA). Com essa alternativa, você pode fornecer recursos ACID ao servidor, visando implementar o processamento de mensagens Kafka. O JCA então fornece uma integração adequada de suas aplicações com soluções JAVA EE.
Implementando o adaptador de recursos JCA
O Java EE Connector Architecture define uma série de mecanismos transacionais escaláveis e seguros. É possível instalar o adaptador JCA em qualquer aplicação compatível com Java EE, como IBM Websphere Application Server, IBM Business Process Manager, JBoss, WebSphere Liberty, Glassfish ou Weblogic.
Suas especificações também trazem uma série de contratos padronizados que possibilitam a comunicação entre aplicações empresariais e sistemas de informação, como o Kafka. Além disso, o JCA pode funcionar como um plugin no servidor, habilitando a integração com Kafka e gerenciando todos os níveis dos mecanismos do sistema (transações, gerenciamento de conexão, recuperação de falhas, detecção de erros e logging). Além disso, o adaptador esconde qualquer lógica de comunicação pertencente ao Kafka necessária à integração de aplicações empresariais. Ao implementar o adaptador de recursos JCA, o provedor pode se voltar à estruturação de estratégias e lógicas de apresentação relacionadas ao Kafka — mesmo as mais avançadas. Portanto, o adaptador é desenvolvido uma única vez e pode ser reutilizado em diferentes aplicações.
Vamos relacionar a solução ao nosso cenário de pagamentos observando o seguinte diagrama, que mostra o contexto do sistema da estratégia planejada:
A aplicação mobile envia os dados da solicitação de pagamento para o Kafka, que está integrado à aplicação da empresa por meio do adaptador. Além disso, notificações de pagamento são enviadas por meio da solução. O adaptador, então, inicia uma transação XA, enviada ao sistema empresarial e também ao sistema de notificações. Portanto, todas as tarefas relacionadas ao processamento da solicitação do pagamento vão ser executadas na mesma transação global e poderão ser concluídas com sucesso ou falhar todas juntas. A estrutura exige configurações de tópicos de novas tentativas, dead letters e log de transações no Kafka, bem como aqueles já criados para leitura ou escrita.
Vamos explorar, agora, mais detalhadamente o processamento de mensagens enviadas da e para a aplicação mobile.
Fluxo de entrada
Em nosso cenário de pagamento, o fluxo de entrada diz respeito à comunicação iniciada pela aplicação mobile da loja online, que envia os dados de pagamento solicitados para o Kafka. O adaptador fornece conectividade e entrega mensagens assincronamente para os endpoints existentes no servidor da aplicação. Isso pode ser feito por meio de um contrato inflow determinado pela especificação JCA.
O adaptador de recursos Kafka JCA implementa uma especificação de ativação JavaBean com uma série de propriedades utilizadas para a configuração de ativação do endpoint. Os detalhes dessas configurações são definidos como parte de uma configuração do servidor da aplicação.
O adaptador de recursos consulta periodicamente um lote de solicitações de pagamento no tópico inbound do Kafka. Depois disso, ele itera pelo lote de dados e entrega mensagens assincronamente às instâncias endpoint. Múltiplas instâncias endpoint podem existir para cada endpoint de mensagem, o que possibilita consumo concorrente de mensagens e proporciona alta taxa de transferência.
O offset consumidor do Kafka é confirmado logo após o agendamento de entrega de mensagem, para evitar problemas com lotes bloqueados. Essa estrutura é viável porque o adaptador implementa procedimentos de tolerância a falhas por meio de novas tentativas, dead letters e tópicos log de transações que precisam ser configurados no Kafka. Em nosso caso, o endpoint precisa suportar transações XA, e o contexto de transação tem de ser criado antes do envio de dados para o endpoint, proporcionando assim um alto consumo de mensagens.
Caso a transação fosse recusada pelo servidor da aplicação, todo o trabalho realizado pela instância endpoint teria de ser revertido e a mensagem precisaria ser encaminhada ao tópico de nova tentativa do Kafka.
O adaptador consome mensagens do tópico de novas tentativas do Kafka e as processa novamente. Depois que o número de definido de novas tentativas é excedido, o adaptador transfere a mensagem ao tópico de dead letters do Kafka. Pelo fato de essas mensagens possuírem dados valiosos, é importante monitorar o tópico.
Fluxo de saída
Esse fluxo diz respeito à comunicação iniciada pela aplicação da empresa. Em nosso caso, esse sistema é utilizado para enviar confirmações de pagamento para a aplicação mobile. A especificação JCA define o contrato de gerenciamento de conexão, que ativa um servidor de aplicativos para agrupar conexões Kafka. Dessa maneira, proporciona um ambiente escalável que suporta um grande número de clientes.
Os detalhes da configuração de uma conexão outbound Kafka são definidos por meio de Managed Connection Factory JavaBean. Se valendo desses detalhes, o adaptador permite a administradores e desenvolvedores configurar o produtor Kafka e aproveitar recursos como confiabilidade, disponibilidade, taxa de transferência, latência e suporte de transação. Tais especificações são definidas como parte da configuração do servidor da aplicação.
O adaptador de recursos Kafka JCA expõe o Kafka Connection Factory e o Kafka Connection que implementam o CCI (Common Client Interface), assim como as interfaces do JMS (Java Message Service). Um componente do aplicativo procura uma connection factory utilizando o nome JNDI (Java Naming and Directory Interface). Depois de obtê-la, a aplicação a usa para conseguir uma conexão e acessar o Kafka. Dessa maneira, é possível adicionar uma integração Kafka ao aplicativo do sistema de notificação, que atualmente envia dados para provedores de sistemas de mensagens JMS, como IBM MQ ou Active MQ.
O fluxo de saída do adaptador de recursos encapsula lógica de comunicação low-level Kafka e faz o seguinte:
- Pool de conexão.
- Usa mecanismos transacionais Kafka para garantir entrega única.
- Cuida da identificação, do registro e do manuseio de falhas do Kafka normalmente.
- Implementa transações XA e, portanto, fornece processamento confiável de mensagens com Kafka em sistemas distribuídos.
Para gerenciar transações dentro do fluxo de saída, o adaptador de recursos utiliza o contrato de gerenciamento de transações definido pela JCA Specification.
No nosso exemplo, a connection factory precisa ser ajustada para suportar transações XA, e o adaptador precisa iniciar a transação Kafka quando o cliente obtém a conexão. A transação Kafka deve ser cancelada se o servidor reverter a conexão. No caso de uma confirmação de transação XA, o gerenciador de transações executa um protocolo de confirmação de duas etapas em todos os recursos que participam da transação em execução. Isso garante que todo acesso de leitura/escrita aos recursos gerenciados seja confirmado ou revertido.
Por fim, o adaptador de recursos mantém o rastreamento de transações em andamento registrando dados no tópico de log de transação Kafka. Os dados registrados são utilizados em processos de reembolso, pois fornecem processamento confiável de mensagens em um sistema distribuído.
Conclusão
A estratégia de configurar um adaptador JCA Kafka garante uma integração “plug and play” entre JMS e processamento de eventos complexos para soluções com padrões empresariais Java. Esse design permite integrar perfeitamente o Kafka aos aplicativos corporativos existentes, sem a necessidade de implementar a lógica de compensação. Além disso, o adaptador possibilita que um servidor forneça a infraestrutura, o ambiente de tempo de execução para conectividade Kafka e o gerenciamento de transações necessário à estabilidade do sistema da empresa.
...
Quer ler mais conteúdo especializado de programação? Conheça a IBM Blue Profile e tenha acesso a matérias exclusivas, novas jornadas de conhecimento e testes personalizados. Confira agora mesmo, consiga as badges e dê um upgrade na sua carreira!
Categorias
