Este é um artigo traduzido originalmente publicado dia 12/5/2022 no blog do Kai Waehner: "Comparison: JMS Message Queue vs. Apache Kafka". Assine a newsletter do Kai para se manter atualizado com novas publicações.
A comparação de infraestruturas de fila de mensagens (MQ) baseadas em JMS e fluxo de dados baseado em Apache Kafka é um tópico bastante difundido. Infelizmente, a batalha é uma comparação de maçã para laranja que geralmente inclui desinformação e FUD de fornecedores. Esta postagem de blog explora as diferenças, compensações e arquiteturas de agentes de mensagens JMS e implantações Kafka. Saiba como escolher entre brokers JMS como IBM MQ ou RabbitMQ e Kafka de software livre ou serviços de nuvem sem servidor como Confluent Cloud.
A comparação de infraestruturas de fila de mensagens (MQ) baseadas em JMS e fluxo de dados baseado em Apache Kafka é um tópico bastante difundido. Infelizmente, a batalha é uma comparação de maçã para laranja que geralmente inclui desinformação e FUD de fornecedores. Esta postagem de blog explora as diferenças, compensações e arquiteturas de intermediários de mensagens JMS e implantações Kafka . Saiba como escolher entre brokers JMS como IBM MQ ou RabbitMQ e Kafka de software livre ou serviços de nuvem sem servidor como Confluent Cloud.
Motivação: A batalha das maçãs contra as laranjas
Eu tenho que discutir as diferenças e compensações entre os agentes de mensagens JMS e o Apache Kafka toda semana em reuniões com clientes. O que mais me irrita são os mal-entendidos comuns e (às vezes) FUD intencional em vários blogs, artigos e apresentações sobre essa discussão.
Recentemente, discuti este tópico com Clement Escoffier da Red Hat no Podcast “Coding over Cocktails”: JMS vs. Kafka: Technology Smackdown . Uma ótima conversa com mais concordância do que você poderia esperar de um episódio como esse em que escolhi o “proponente Kafka” enquanto Clement assumia o papel de “proponente JMS”.
Esses aspectos me motivaram a escrever uma série de blogs sobre “JMS, Message Queues e Apache Kafka” (PB: vou linkar as versões traduzidas assim que forem publicadas) :
ESTE POST – 10 critérios de comparação para JMS Message Broker vs. Apache Kafka Data Streaming
Alternativas para uma Dead Letter Queue (DLQ) no Apache Kafka (post original: Error Handling via Dead Letter Queue in Apache Kafka )
Implementando o padrão de solicitação-resposta com o Apache Kafka
PRÓXIMO – Uma árvore de decisão para escolher o sistema de mensagens certo (JMS vs. Apache Kafka)
PRÓXIMO – Do JMS Message Broker ao Apache Kafka: Integração, Migração e/ou Substituição
Vou linkar os outros posts aqui assim que estiverem disponíveis. Por favor , siga minha newsletter para ser atualizado em tempo real sobre novas postagens . (sem spam ou anúncios)
Agradecimentos especiais ao meu colega e especialista em transmissão de dados e mensagens de longo prazo Heinz Schaffner pelo feedback técnico e revisão desta série de blogs. Ele trabalhou para TIBCO, Solace e Confluent por 25 anos.
10 critérios de comparação: JMS vs. Apache Kafka
Esta postagem de blog explora dez critérios de comparação. O objetivo é explicar as diferenças entre filas de mensagens e streaming de dados, esclarecer alguns mal-entendidos sobre o que é uma API ou implementação e fornecer algumas informações técnicas para fazer sua avaliação e encontrar a ferramenta certa para o trabalho.
A lista de produtos e serviços em nuvem é longa para implementações JMS e ofertas Kafka.
Alguns exemplos:
Implementações JMS da API JMS (open source e ofertas comerciais): Apache ActiveMQ, Apache Qpid (usando AMQP), IBM MQ (anteriormente MQSeries, depois WebSphere MQ), JBoss HornetQ, Oracle AQ, RabbitMQ, TIBCO EMS, Solace, etc.
Produtos Apache Kafka, serviços em nuvem e reescritas (além da opção válida de usar apenas Kafka de código aberto): Confluent, Cloudera, Amazon MSK, Red Hat, Redpanda, Azure Event Hubs, etc.
Aqui estão os critérios para comparar os agentes de mensagens JMS com o Apache Kafka e seus produtos/serviços de nuvem relacionados:
Agente de mensagens versus plataforma de streaming de dados
Especificação de API x implementação de protocolo de código aberto
Cargas de trabalho transacionais versus analíticas
Consumo de mensagens push vs. pull
API simples versus poderosa e complexa
Armazenamento para durabilidade versus desacoplamento verdadeiro
Processamento de dados do lado do servidor versus processamento de fluxo contínuo desacoplado
Operações complexas versus nuvem sem servidor
Java/JVM vs. qualquer linguagem de programação
Implementação única versus replicação multirregional (incluindo híbrida e multinuvem)
Vamos agora explorar os dez critérios de comparação.
1. Agente de mensagens versus plataforma de streaming de dados
TL;DR: Os intermediários de mensagens JMS fornecem recursos de mensagens para produzir e consumir mensagens. O Apache Kafka é uma plataforma de streaming de dados que combina recursos de mensagens, armazenamento, integração de dados e processamento de stream.
O aspecto mais importante primeiro: A comparação de JMS e Apache Kafka é uma comparação de maçã para laranja por vários motivos . Eu diria ainda que nem ambos podem ser frutos, pois são tão diferentes um do outro.
API JMS (e implementações como IBM MQ, RabbitMQ, et al)
JMS (Java Message Service) é uma interface de programação de aplicativos (API) Java que fornece modelos genéricos de mensagens. A API trata do problema produtor-consumidor, o que pode facilitar o envio e recebimento de mensagens entre sistemas de software .
Portanto, a capacidade central dos intermediários de mensagens JMS (que implementam a API JMS) é enviar mensagens de um aplicativo de origem para outro destino em tempo real . É isso. E se é isso que você precisa, então JMS é a escolha certa para você! Mas lembre-se de que os projetos devem usar ferramentas adicionais para integração de dados e tarefas avançadas de processamento de dados.
Apache Kafka (código aberto e fornecedores como Confluent, Cloudera, Red Hat, Amazon, e outros)
Apache Kafka é uma implementação de protocolo de código aberto para streaming de dados . Inclui:
O Apache Kafka é o núcleo para mensagens e armazenamento distribuídos. Alta taxa de transferência, baixa latência, alta disponibilidade, seguro.
Kafka Connect é uma estrutura de integração para conectar fontes/destinos externos ao Kafka.
Kafka Streams é uma biblioteca Java simples que permite o desenvolvimento de aplicativos de streaming dentro da estrutura Kafka.
Essa combinação de recursos permite a criação de pipelines e aplicativos de dados de ponta a ponta . Isso é muito mais do que você pode fazer com uma fila de mensagens.
2. Especificação da API JMS versus implementação do protocolo de código aberto Apache Kafka
TL;DR: JMS é uma especificação que os fornecedores implementam e estendem de maneira opinativa. Apache Kafka é a implementação de código aberto do protocolo Kafka especificado subjacente.
É crucial esclarecer os termos antes de avaliar JMS e Kafka:
API padrão : especificado por consórcios do setor ou outros grupos ou organizações neutras do setor (geralmente globais) especificam APIs padrão. Requer testes de conformidade para todos os recursos e certificações completas para se tornar compatível com o padrão. Exemplo: OPC-UA .
API padrão de fato : Origina-se de uma solução bem-sucedida existente (uma estrutura de código aberto, um produto comercial ou um serviço em nuvem). Exemplos: Amazon S3 (proprietário de um único fornecedor). Apache Kafka (código aberto da comunidade vibrante).
Especificação de API : Um documento de especificação para definir como os fornecedores podem implementar um produto relacionado. Não há testes de conformidade completos ou certificações completas para a implementação de todos os recursos. A consequência é uma “API padrão”, mas sem portabilidade entre implementações. Exemplo: JMS. Especificamente para JMS, observe que, para poder usar o conjunto de conformidade para JMS, um fornecedor comercial precisa se inscrever em requisitos de relatórios muito onerosos para a Oracle.
Os tipos alternativos de padrões têm compensações. Se você quiser saber mais, confira como o Apache Kafka se tornou o padrão de fato para streaming de dados nos últimos anos .
A portabilidade e as migrações se tornaram muito mais relevantes em ambientes híbridos e multinuvem do que nas últimas décadas, onde você tinha suas cargas de trabalho em um único data center.
JMS é uma especificação para middleware orientado a mensagens
JMS é uma especificação atualmente mantida no Java Community Process como JSR 343. A versão mais recente (ainda não lançada) JMS 3.0 está em desenvolvimento inicial como parte do Jakarta EE e renomeada para Jakarta Messaging API. Hoje, o JMS 2.0 é a especificação usada nas implementações predominantes do intermediário de mensagens . Ninguém sabe para onde o JMS 3.0 irá. Portanto, este post se concentra na especificação JMS 2.0 para resolver problemas do mundo real hoje.
Costumo usar o termo “corretor de mensagens JMS” nas seções a seguir, pois o JMS (ou seja, a API) não especifica ou implementa muitos recursos que você conhece em sua implementação JMS favorita. Normalmente, quando as pessoas falam sobre JMS, elas se referem a implementações do agente de mensagens JMS, não à especificação da API JMS .
Agentes de mensagens JMS e o mito da portabilidade JMS
A especificação JMS foi desenvolvida para fornecer uma biblioteca Java comum para acessar os brokers de diferentes fornecedores de mensagens. Ele foi planejado para atuar como um wrapper para as APIs proprietárias do fornecedor de mensagens da mesma forma que o JDBC forneceu funcionalidade semelhante para APIs de banco de dados.
Infelizmente, essa integração simples acabou não sendo o caso. A migração do código JMS do broker de um fornecedor para outro é bastante complexa por vários motivos :
Nem todos os recursos JMS são obrigatórios (segurança, rotulagem de tópico/fila, clustering, roteamento, compactação etc.)
Não há especificação JMS para transporte
Nenhuma especificação para definir como a persistência é implementada
Nenhuma especificação para definir como a tolerância a falhas ou alta disponibilidade é implementada
Diferentes interpretações da especificação JMS por diferentes fornecedores resultam em potencialmente outros comportamentos para as mesmas funções JMS
Sem especificação de segurança
Não há especificação para recursos de valor agregado nos corretores (como ponte de tópico para fila, roteamento entre corretores, listas de controle de acesso etc.)
Portanto, migração simples de código-fonte e interoperabilidade entre fornecedores de JMS é um mito! Isso parece loucura, não é?
Os fornecedores fornecem uma grande quantidade de funcionalidades exclusivas dentro do broker (como mapeamento de tópico para fila, roteamento do broker, etc.) que fornecem funcionalidade de arquitetura para o aplicativo, mas fazem parte da funcionalidade do broker e não do aplicativo ou parte do JMS especificação.
Apache Kafka é uma implementação de protocolo de código aberto para streaming de dados
Apache Kafka é uma implementação para fazer streaming de dados confiável e escalável em tempo real. O projeto é de código aberto e está disponível sob a licença Apache 2.0 e é conduzido por uma vasta comunidade.
Apache Kafka NÃO é um padrão como OPC-UA ou uma especificação como JMS . No entanto, Kafka pelo menos fornece a implementação de referência de código-fonte, definições de protocolo e API, etc.
Kafka se estabeleceu como o padrão de fato para streaming de dados. Hoje, mais de 100.000 organizações usam o Apache Kafka. A API Kafka tornou-se o padrão de fato para arquiteturas orientadas a eventos e streaming de eventos . Casos de uso em todos os setores e infraestrutura . Incluindo vários tipos de cargas de trabalho transacionais e analíticas. Edge, híbrido, multinuvem . Coletei alguns exemplos em verticais que usam o Apache Kafka para mostrar a prevalência nos mercados.
Agora, espere. Eu usei o termo API Kafka na seção acima. Vamos esclarecer isso: Conforme discutido, o Apache Kafka é uma implementação de uma plataforma de streaming de dados distribuídos, incluindo o lado do servidor e o lado do cliente e várias APIs para produzir e consumir eventos, configuração, segurança, operações etc. A API do Kafka é relevante, também, como o Kafka reescreve como os Hubs de Eventos do Azure e o Redpanda o usam .
Portabilidade do Apache Kafka – mais um mito?
Se você usa o Apache Kafka como um projeto de código aberto, esta é a implementação completa do Kafka. Alguns fornecedores usam a implementação completa do Apache Kafka e criam um produto mais avançado em torno dela.
Aqui, a migração é super direta, pois o Kafka não é apenas uma especificação que cada fornecedor implementa de forma diferente . Em vez disso, é o mesmo código, bibliotecas e pacotes.
Por exemplo, tenho visto várias migrações bem-sucedidas de Cloudera para implantações do Confluent ou da infraestrutura de código aberto Apache Kafka autogerenciada para o Confluent Cloud sem servidor .
A API Kafka – Kafka reescreve como Hubs de Eventos do Azure, Redpanda, Apache Pulsar
Com o sucesso global do Kafka, alguns fornecedores e serviços em nuvem não criaram um produto sobre a implementação do Apache Kafka. Em vez disso, eles fizeram sua implementação em cima da API Kafka . A implementação subjacente é proprietária (como nos Hubs de Eventos do serviço de nuvem do Azure) ou de código aberto (como a ponte Kafka do Apache Pulsar ou a reescrita do Redpanda em C++).
Tenha cuidado e analise se os fornecedores integram todo o projeto Apache Kafka ou reescrevem a API completa. Ao contrário do projeto Apache Kafka testado em batalha, uma reescrita do Kafka usando a API do Kafka é uma implementação completamente nova!
Muitos fornecedores até excluem completamente alguns componentes ou APIs (como Kafka Connect para integração de dados ou Kafka Streams para processamento de fluxo) ou excluem recursos críticos como semântica exatamente uma vez ou armazenamento de longo prazo em seus termos e condições de suporte.
Cabe a você avaliar as diferentes ofertas do Kafka e suas limitações. Recentemente, comparei fornecedores Kafka, como Confluent, Cloudera, Red Hat ou Amazon MSK e tecnologias relacionadas, como Azure Event Hubs, AWS Kinesis, Redpanda ou Apache Pulsar .
Apenas teste de batalha os requisitos por si mesmo. Se você encontrar uma ponte Kafka-para-XYZ com menos de cem linhas de código ou se encontrar um download do servidor .exe Windows Kafka de um fornecedor de middleware. Seja cético!
Nem tudo que reluz é ouro. Alguns frameworks ou fornecedores parecem bons demais para ser verdade. Apenas dizer que você suporta a API Kafka, fornece uma oferta Kafka sem servidor totalmente gerenciada ou escala muito melhor não é confiável se você for constantemente forçado a fornecer medo, incerteza e dúvida (FUD) no Kafka e que você é muito melhor. Por exemplo, fiquei irritado com o Pulsar sempre tentando ser melhor que Kafka, criando muitos FUDs e mitos na comunidade de código aberto. Eu respondi na minha comparação Apache Pulsar vs. Kafka dois anos atrás. FUD é a estratégia errada para qualquer fornecedor. Não funciona. Por essa razão, a adoção do Kafka ainda cresce como um louco, enquanto o Pulsar cresce muito mais lentamente em termos percentuais (mesmo que os números de download estejam em um nível muito mais baixo).
3. Cargas de trabalho transacionais versus analíticas
TL;DR: Um intermediário de mensagens JMS fornece recursos transacionais para baixos volumes de mensagens. O Apache Kafka oferece suporte a volumes baixos e altos de mensagens com suporte a cargas de trabalho transacionais e analíticas.
JMS – Transações de sessão e confirmação de duas fases (XA)
A maioria dos intermediários de mensagens JMS tem um bom suporte para cargas de trabalho transacionais.
Uma sessão transacionada suporta uma única série de transações . Cada transação agrupa um conjunto de mensagens produzidas e um conjunto de mensagens consumidas em uma unidade atômica de trabalho.
As transações de confirmação de duas fases (transações XA) funcionam em uma escala limitada . Eles são usados para integração com outros sistemas como Mainframe CICS/DB2 ou banco de dados Oracle. Mas é difícil de operar e não é possível escalar além de algumas transações por segundo.
É importante observar que o suporte para transações XA não é obrigatório com a especificação JMS 2.0 . Isso difere da transação de sessão.
Kafka – API de semântica e transação exatamente uma vez
Kafka é um sistema distribuído e tolerante a falhas que é resiliente por natureza (se você o implantar e operar corretamente). Nenhum tempo de inatividade e perda de dados pode ser garantido, como em seu banco de dados favorito, mainframe ou outras plataformas principais.
E ainda melhor: a API de Transação do Kafka, ou seja, Exactly-Once Semantics (EOS) , está disponível desde o Kafka 0.11 (GA'ed há muitos anos). O EOS torna a criação de cargas de trabalho transacionais ainda mais fácil, pois você não precisa mais lidar com duplicatas.
O Kafka suporta gravações atômicas em várias partições por meio da API de transações . Isso permite que um produtor envie um lote de mensagens para várias partições. Todas as mensagens no lote são eventualmente visíveis para qualquer consumidor ou nenhuma delas é visível para os consumidores.
As transações Kafka funcionam de maneira muito diferente das transações JMS. Mas o objetivo é o mesmo: cada consumidor recebe o evento produzido exatamente uma vez. Encontre mais detalhes na postagem do blog " Analytics vs. Transactions in Data Streaming with Apache Kafka ".
4. Consumo de mensagens push vs. pull
TL;DR: os intermediários de mensagens JMS enviam mensagens para aplicativos do consumidor. Os consumidores do Kafka recebem mensagens que fornecem um verdadeiro desacoplamento e manuseio de contrapressão para aplicativos de consumidores independentes.
O envio de mensagens parece ser a escolha óbvia para um sistema de mensagens em tempo real, como intermediários de mensagens baseados em JMS. No entanto, as mensagens baseadas em push têm várias desvantagens em relação à dissociação e escalabilidade .
O JMS espera que o broker forneça pressão de retorno e implemente um recurso de “pré-busca”, mas isso não é obrigatório. Se usado, o corretor controla a contrapressão, que você não pode controlar.
Com Kafka, o consumidor controla a contrapressão. Cada consumidor Kafka consome eventos em tempo real, em lote ou apenas sob demanda – da maneira que o consumidor específico suporta e pode lidar com o fluxo de dados. Esta é uma enorme vantagem para muitos ambientes inflexíveis e não elásticos.
Portanto, embora o JMS tenha algum tipo de contrapressão, o produtor para se a fila estiver cheia. No Kafka, você controla a contrapressão no consumidor. Não há como dimensionar um produtor com JMS (pois não há partições em uma fila ou tópico JMS).
Os consumidores JMS podem ser dimensionados, mas você perde o pedido garantido. A ordenação garantida em intermediários de mensagens JMS funciona apenas por meio de um único produtor, único consumidor e transação .
5. API JMS simples versus API Kafka poderosa e complexa
TL;DR: A API JMS fornece operações simples para produzir e consumir mensagens. O Apache Kafka tem uma API mais granular que traz poder e complexidade adicionais.
Os fornecedores de JMS escondem todas as coisas legais na implementação sob a especificação. Você só recebe os 5% (sem controle, construído pelo fornecedor). Você precisa fazer o resto sozinho. Por outro lado, Kafka expõe tudo. A maioria dos desenvolvedores só precisa de 5%.
Em resumo, esteja ciente de que os intermediários de mensagens JMS são construídos para enviar mensagens de uma origem de dados para um ou mais coletores de dados. Kafka é uma plataforma de streaming de dados que oferece muito mais recursos, recursos, padrões de eventos e opções de processamento; e uma escala muito maior . Com isso em mente, não é surpresa que as APIs sejam muito diferentes e tenham complexidade diferente.
Se o seu caso de uso requer apenas o envio de algumas mensagens por segundo de A para B, o JMS é a escolha certa e simples de usar! Se você precisar de um hub de dados de streaming em qualquer escala, incluindo integração e processamento de dados, isso é apenas Kafka.
Solicitação-resposta assíncrona vs. dados em movimento
Um dos desejos mais comuns dos desenvolvedores JMS é usar a função solicitação-resposta no Kafka . Observe que esse padrão de design é diferente em sistemas de mensagens de um RPC (chamada de procedimento remoto) como você o conhece de ferramentas legadas como Corba ou padrões de serviço da Web como SOAP/WSDL ou HTTP. A solicitação-resposta em agentes de mensagens é uma comunicação assíncrona que aproveita um ID de correlação .
Mensagens assíncronas para obter eventos de um produtor (digamos, um aplicativo móvel) para um consumidor (digamos, um banco de dados) é um fluxo de trabalho muito tradicional. Não importa se você dispara e esquece ou solicita resposta. Você coloca os dados em repouso para processamento adicional. O JMS suporta solicitação-resposta pronta para uso . A API é muito simples.
Dados em movimento com streaming de eventos processam dados continuamente. O log Kafka é durável. O aplicativo Kafka mantém e consulta o estado em tempo real ou em lote. O streaming de dados é uma mudança de paradigma para a maioria dos desenvolvedores e arquitetos. Os padrões de design são muito diferentes. Não tente reimplementar seu aplicativo JMS no Kafka usando o mesmo padrão e API. É provável que isso falhe! Isso é um anti-padrão.
A solicitação-resposta é ineficiente e pode sofrer muita latência dependendo do caso de uso . HTTP ou melhor gRPC é adequado para alguns casos de uso. A solicitação-resposta é substituída pelo padrão CQRS ( Segregação de responsabilidade de comando e consulta) com Kafka para streaming de dados . O CQRS não é possível com a API JMS, pois o JMS não fornece recursos de estado e não possui recursos de origem de eventos.
Um exemplo Kafka para o padrão solicitação-resposta
O CQRS é o melhor padrão de design para muitos casos de uso do Kafka. No entanto, o padrão de solicitação-resposta também pode ser implementado com o Kafka. Mas de forma diferente. Tentar fazer isso como em um agente de mensagens JMS (com filas temporárias etc.) acabará matando o cluster Kafka (porque funciona de maneira diferente).
O projeto Spring mostra como você pode fazer melhor. As bibliotecas Kafka Spring Boot Kafka Template têm um ótimo exemplo do padrão de solicitação-resposta criado com o Kafka.
Confira " org.springframework.kafka.requestreply.ReplyingKafkaTemplate ". Ele cria aplicativos de solicitação/resposta usando a API Kafka facilmente. O exemplo é interessante, pois implementa a solicitação/resposta assíncrona, que é mais complicada de escrever se você estiver usando, por exemplo, a API JMS). Outro bom artigo do DZone fala sobre solicitação/resposta síncrona usando modelos Spring Kafka .
A documentação do Spring para Kafka Templates tem muitos detalhes sobre o padrão Request/Reply para Kafka. Portanto, se você estiver usando o Spring, o padrão de solicitação/resposta é bastante simples de implementar com o Kafka. Se você não estiver usando o Spring, poderá aprender como fazer solicitação-resposta com o Kafka em seu framework.
6. Armazenamento para durabilidade versus desacoplamento verdadeiro
TL;DR: Os intermediários de mensagens JMS usam um sistema de armazenamento para fornecer alta disponibilidade. O sistema de armazenamento do Kafka é muito mais avançado para permitir armazenamento de longo prazo, manuseio de contrapressão e reprodutibilidade de eventos históricos.
O armazenamento Kafka é mais do que apenas o recurso de persistência que você conhece do JMS
Quando explico o sistema de armazenamento Kafka para desenvolvedores JMS experientes, quase sempre recebo a mesma resposta: “Nosso agente de mensagens JMS XYZ também tem armazenamento sob o capô. Não vejo vantagem em usar Kafka!”
O JMS usa um sistema de armazenamento efêmero, onde as mensagens são persistidas apenas até serem processadas. O armazenamento de longo prazo e a capacidade de reprodução de mensagens não são um conceito para o qual o JMS foi projetado.
Os princípios básicos do Kafka de logs somente anexados, deslocamentos, pedidos garantidos, tempo de retenção, tópicos compactados e assim por diante fornecem muitos benefícios adicionais além das garantias de durabilidade de um JMS. O manuseio de contrapressão, a verdadeira dissociação entre consumidores, a reprodutibilidade de eventos históricos e muito mais são grandes diferenciais entre JMS e Kafka.
Verifique os documentos do Kafka para um mergulho profundo no sistema de armazenamento Kafka. Não quero tocar em como o armazenamento em camadas para Kafka está mudando ainda mais o jogo, fornecendo escalabilidade ainda melhor e armazenamento de longo prazo econômico no log do Kafka.
7. Processamento de dados do lado do servidor com JMS vs. processamento de fluxo contínuo desacoplado com Kafka
TL;DR: Os intermediários de mensagens JMS fornecem processamento simples de eventos do lado do servidor, como filtragem ou roteamento com base no conteúdo da mensagem. Os corretores Kafka são burros. Seu processamento de dados é executado em aplicativos/microsserviços desacoplados.
Filtragem e roteamento JMS do lado do servidor
A maioria dos intermediários de mensagens JMS fornece alguns recursos para processamento de eventos do lado do servidor. Esses recursos são úteis para algumas cargas de trabalho!
Apenas tome cuidado para que o processamento do lado do servidor geralmente tenha um custo. Por exemplo:
Problemas de escalabilidade de pré-filtragem JMS : O broker precisa lidar com muitas coisas. Isso pode matar o corretor de forma oculta
Problemas de desempenho de seletores JMS (= roteamento) : mata 40-50% do desempenho
Novamente, às vezes, as desvantagens são aceitáveis. Então esta é uma grande funcionalidade.
Kafka – Dumb pipes e endpoints inteligentes
O Kafka intencionalmente não fornece processamento no lado do servidor . Os corretores são burros. O processamento acontece nos terminais inteligentes. Este é um padrão de design muito conhecido: Dumb pipes and smart endpoints .
A desvantagem é que você precisa de aplicativos/microsserviços/produtos de dados separados para implementar a lógica . Este não é um grande problema em ambientes sem servidor (como usar um processo ksqlDB em execução no Confluent Cloud para processamento de dados). Fica mais complexo em ambientes autogerenciados.
No entanto, o grande benefício dessa arquitetura é a verdadeira dissociação entre aplicativos/tecnologias/linguagens de programação, separação de interesses entre unidades de negócios para construção de lógica de negócios e operações de infraestrutura e a escalabilidade e elasticidade muito melhores .
Gostaria de ver alguns recursos de processamento do lado do servidor no Kafka também? Sim absolutamente. Especialmente para pequenas cargas de trabalho, o impacto no desempenho e na escalabilidade deve ser aceitável! No entanto, o risco é que as pessoas usem mal os recursos. O futuro mostrará se Kafka chegará lá ou não.
8. Operações complexas versus nuvem sem servidor
TL;DR: As operações autogerenciadas de intermediários de mensagens JMS escaláveis ou clusters Kafka são complexas. As ofertas sem servidor (devem) assumir o fardo das operações.
Operar um cluster é complexo – não importa se JMS ou Kafka
Um intermediário de mensagens JMS básico é relativamente fácil de operar (incluindo configurações ativas/passivas). No entanto, isso limita a escalabilidade e a disponibilidade . A API JMS foi projetada para conversar com um único broker ou ativo/passivo para alta disponibilidade. Este conceito abrange o domínio do aplicativo .
Mais do que isso (= clustering ) é muito complexo com intermediários de mensagens JMS . Clusters de intermediários de mensagens mais avançados de fornecedores comerciais são mais poderosos, mas muito mais difíceis de operar.
Kafka é um sistema distribuído poderoso . Portanto, operar um cluster Kafka não é fácil por natureza . Ferramentas nativas da nuvem, como um operador para Kubernetes, assumem alguns encargos, como atualizações contínuas ou manipulação de failover.
Tanto os mediadores de mensagens JMS quanto os clusters Kafka são os mais desafiadores, quanto mais escala e confiabilidade seus SLAs exigem. A API JMS não é especificada para um hub de dados central (usando um cluster). O Kafka foi criado intencionalmente para a arquitetura empresarial estratégica , não apenas para um único aplicativo de negócios.
Nuvem sem servidor totalmente gerenciada para o resgate
Como a API JMS foi projetada para conversar com um único broker, é difícil construir uma oferta de nuvem sem servidor que forneça escalabilidade . Portanto, nos serviços de nuvem JMS, o consumidor precisa configurar o roteamento e o controle de acesso baseado em função para os corretores específicos. Essa oferta de nuvem não é sem servidor, mas de lavagem de nuvem ! Mas não há outra opção, pois a API JMS não é como Kafka com um grande cluster distribuído.
Em Kafka, a situação é diferente. Como o Kafka é um sistema distribuído escalável, os provedores de nuvem podem criar ofertas sem servidor nativas da nuvem . Construir uma infraestrutura tão totalmente gerenciada ainda é muito difícil. Portanto, avalie o produto, não apenas os slogans de marketing!
Todo serviço de nuvem Kafka é comercializado como “totalmente gerenciado” ou “sem servidor”, mas a maioria NÃO é . Em vez disso, a maioria dos fornecedores apenas provisiona a infraestrutura e permite que você opere o cluster e assuma o risco de suporte. Por outro lado, algumas ofertas totalmente gerenciadas do Kafka são super limitadas em funcionalidade (como permitir um número muito limitado de partições).
Alguns fornecedores de nuvem até excluem o suporte Kafka de suas ofertas de nuvem Kafka . Insano, mas verdadeiro. Verifique os termos e condições como parte de sua avaliação.
9. Java/JVM vs. qualquer linguagem de programação
TL;DR: JMS se concentra no ecossistema Java para linguagens de programação JVM. Kafka é independente de linguagens de programação.
Como o nome JMS (=Java Message Service) diz: JMS foi escrito apenas para Java oficialmente. Alguns fornecedores de corretores suportam suas próprias APIs e clientes. Estes são de propriedade desse fornecedor. Quase todos os projetos JMS severos que vi no passado usam código Java.
O Apache Kafka também fornece apenas um cliente Java . Mas os fornecedores e a comunidade fornecem outras ligações de linguagem para quase todas as linguagens de programação, além de uma API REST para comunicação HTTP para produzir/consumir eventos de/para Kafka . Por exemplo, confira a postagem do blog “ 12 Programming Languages Walk into a Kafka Cluster ” para ver exemplos de código em Java, Python, Go, .NET, Ruby, node.js, Groovy etc.
A verdadeira dissociação do backend Kafka permite que aplicativos clientes muito diferentes se comuniquem, não importa quais linguagens de programação sejam usadas . Essa flexibilidade permite a construção de um design orientado a domínio (DDD) adequado com uma arquitetura de microsserviços, aproveitando o Kafka como o sistema nervoso central .
10. Implantação de JMS único versus replicação Kafka multirregional (incluindo híbrida e multinuvem)
TL;DR: A API JMS é uma especificação do cliente para comunicação entre o aplicativo e o broker. Kafka é um sistema distribuído que permite várias arquiteturas para casos de uso híbridos e multinuvem.
JMS é uma especificação do cliente, enquanto a replicação de vários datacenters é uma função do broker. Não vou me aprofundar aqui e simplificar: os agentes de mensagens JMS não são criados para cenários de replicação em regiões, continentes ou ambientes híbridos/multinuvem .
As implantações de vários clusters e centros de dados cruzados do Apache Kafka tornaram-se a norma e não uma exceção. Vários cenários exigem soluções Kafka de vários clusters . Requisitos específicos e trade-offs precisam ser observados.
Tecnologias Kafka como MirrorMaker (código aberto) ou Confluent Cluster Linking (comercial) permitem casos de uso como recuperação de desastres, agregação para análise, migração para a nuvem, implantações estendidas de missão crítica e implantações Kafka globais .
Abordei arquiteturas de nuvem híbrida em várias outras postagens do blog. “ Low Latency Data Streaming with Apache Kafka e Cloud-Native 5G Infrastructure ” é um ótimo exemplo.
JMS e Kafka resolvem problemas distintos!
Os dez critérios de comparação mostram que JMS e Kafka são coisas muito diferentes . Embora ambos se sobreponham (por exemplo, mensagens, tempo real, missão crítica), eles usam diferentes recursos técnicos, recursos e arquiteturas para dar suporte a casos de uso adicionais.
Resumindo, use um broker JMS para mensagens simples e de baixo volume de A para B . Kafka geralmente é um hub de dados em tempo real entre muitas fontes de dados e coletores de dados . Muitas pessoas o chamam de sistema nervoso central em tempo real da arquitetura corporativa.
A integração de dados e os recursos de processamento de dados do Kafka em qualquer escala com real desacoplamento e capacidade de repetição de eventos são as principais diferenças dos sistemas MQ baseados em JMS.
No entanto, especialmente na nuvem sem servidor, não tenha medo de Kafka ser muito poderoso (e complexo) . Os projetos Kafka sem servidor geralmente começam de forma muito barata com um volume muito baixo, sem encargos operacionais . Em seguida, ele pode ser dimensionado com seus negócios em crescimento sem a necessidade de reprojetar o aplicativo.
Entenda as diferenças técnicas entre um agente de mensagens baseado em JMS e o streaming de dados desenvolvido pelo Apache Kafka. Avalie ambas as opções para encontrar a ferramenta certa para o problema . No fluxo de mensagens ou dados, faça avaliações mais detalhadas. Cada agente de mensagens é diferente, embora todos sejam compatíveis com JMS. Da mesma forma, todos os produtos e serviços em nuvem Kafka são diferentes em relação a recursos, suporte e custo.
Você usa intermediários de mensagens compatíveis com JMS? Quais são os casos de uso e limitações? Quando você planeja ou planeja usar o Apache Kafka? Conecte comigo e com o Kai no LinkedIn e vamos discutir isso! Mantenha-se informado sobre as novas postagens do blog assinando a newsletter.
Comments