本文探討了JMS消息中間件和Kafka部署的差異、權(quán)衡和架構(gòu)。對(duì)于基于JMS的消息隊(duì)列 (MQ) 基礎(chǔ)架構(gòu)和基于Apache Kafka的數(shù)據(jù)流的比較是一個(gè)廣泛的話題。本文探討JMS消息代理和Kafka部署的區(qū)別、權(quán)衡和架構(gòu)，以及分析如何在JMS代理（如 IBM MQ 或 RabbitMQ）和開(kāi)源Kafka或無(wú)服務(wù)器云服務(wù)（如 Confluent Cloud）之間進(jìn)行選擇。

動(dòng)機(jī)：蘋果與橘子之戰(zhàn)

Kai Waehner在Confluent擔(dān)任技術(shù)布道者，他經(jīng)常在JavaOne、O'Reilly Software Architecture或ApacheCon等國(guó)際會(huì)議上發(fā)表演講，為專業(yè)期刊撰寫文章，分享新技術(shù)方面的經(jīng)驗(yàn)。

Kai幾乎每周都需要在客戶會(huì)議上討論JMS消息代理和Apache Kafka之間的差異和權(quán)衡。他發(fā)現(xiàn)時(shí)下有大量關(guān)于JMS、Kafka的誤解，偶爾也會(huì)看到一些不當(dāng)?shù)牟┛臀恼潞脱葜v，為此感到惱火，并整理了十個(gè)比較準(zhǔn)則，目的是解釋消息隊(duì)列和數(shù)據(jù)流之間的區(qū)別，澄清相關(guān)API或?qū)嵤┎渴鸬囊恍┏Ｒ?jiàn)誤解，并提供相應(yīng)的技術(shù)選型思考。

10個(gè)比較準(zhǔn)則：JMS與Apache Kafka

JMS和Kafka都各自提供一系列產(chǎn)品和云服務(wù)， 例如：JMS API的實(shí)現(xiàn)（包括開(kāi)源和商業(yè)產(chǎn)品）：Apache ActiveMQ、Apache Qpid（使用 AMQP）、IBM MQ（先前是 MQSeries，現(xiàn)在是 WebSphere MQ）、JBoss HornetQ、Oracle AQ、RabbitMQ、TIBCO EMS、TIBCO Cloud Messaging、Solace等等。Apache Kafka產(chǎn)品、云服務(wù)和重寫（不僅使用開(kāi)源 Kafka 的有效選項(xiàng)）：Confluent、Cloudera、Amazon MSK、Red Hat、Redpanda、Azure Event Hubs 等。

下面是比較JMS消息代理與Apache Kafka及其相關(guān)產(chǎn)品/云服務(wù)的標(biāo)準(zhǔn)：1.消息代理與數(shù)據(jù)流平臺(tái)2.API規(guī)范與開(kāi)源協(xié)議實(shí)現(xiàn)3.事務(wù)處理與負(fù)載分析4.推送與拉取消息5.簡(jiǎn)化、強(qiáng)大和復(fù)雜的API6.持久存儲(chǔ)與真正解耦7.服務(wù)器端數(shù)據(jù)處理與解耦持續(xù)數(shù)據(jù)流處理8.復(fù)雜操作與無(wú)服務(wù)器云9.Java/JVM與任何編程語(yǔ)言10.單一部署與多區(qū)域（包括混合和多云）復(fù)制現(xiàn)在逐一探討這十個(gè)比較準(zhǔn)則。

1、JMS與Kafka相差甚巨  

JMS消息代理提供消息收發(fā)功能包括生成和使用消息。Apache Kafka是一個(gè)數(shù)據(jù)流平臺(tái)，綜合了消息傳遞、存儲(chǔ)、數(shù)據(jù)集成和流處理功能。

首先，在Kai看來(lái)，JMS和Apache Kafka的差別相當(dāng)巨大，甚至可以說(shuō)二者就不是同一個(gè)事物。

JMS API（以及IBM MQ、RabbitMQ 等的實(shí)現(xiàn)）JMS（Java 消息服務(wù)）是提供通用消息模型的Java應(yīng)用程序編程接口 (API)。API處理生產(chǎn)者-消費(fèi)者問(wèn)題，為了方便軟件系統(tǒng)之間的消息發(fā)送和接收。因此，JMS消息代理（及實(shí)現(xiàn)JMS API）的核心功能是將消息從源應(yīng)用程序?qū)崟r(shí)得發(fā)送到另一個(gè)目的地程序。所以需要針對(duì)實(shí)際使用需求來(lái)選擇JMS！值得注意的一點(diǎn)是，項(xiàng)目必須使用額外的工具來(lái)完成數(shù)據(jù)集成和高級(jí)數(shù)據(jù)處理任務(wù)。Apache Kafka（開(kāi)源和供應(yīng)商，如 Confluent、Cloudera、Red Hat、Amazon等）Apache Kafka是一種用于數(shù)據(jù)流的開(kāi)源協(xié)議實(shí)現(xiàn)。這包括：

• Apache Kafka是分布式消息收發(fā)和存儲(chǔ)的核心，具有高吞吐量、低延遲、高可用性和安全性。
• Kafka Connect是一個(gè)用于將外部源/目標(biāo)連接到Kafka的集成框架。
• Kafka Streams是一個(gè)簡(jiǎn)單的Java 庫(kù)，支持在Kafka框架內(nèi)進(jìn)行流式應(yīng)用程序開(kāi)發(fā)。

這種功能組合能夠構(gòu)建端到端數(shù)據(jù)管道和應(yīng)用程序，因而相比消息隊(duì)列而言，Kafka組合的用武之地要更廣。

2、 API規(guī)范與開(kāi)源協(xié)議實(shí)現(xiàn) 

JMS是供應(yīng)商以他們自己的方式實(shí)施和擴(kuò)展的規(guī)范。Apache Kafka是底層指定 Kafka協(xié)議的開(kāi)源實(shí)現(xiàn)。

在評(píng)估對(duì)比JMS和Kafka之前，更重要的是澄清以下這些術(shù)語(yǔ)：

• 標(biāo)準(zhǔn)API：由行業(yè)聯(lián)盟或其他行業(yè)中立（通常是全球性）團(tuán)體或組織指定標(biāo)準(zhǔn) API。需要對(duì)所有功能進(jìn)行合規(guī)性測(cè)試并完成認(rèn)證才能符合標(biāo)準(zhǔn)。示例：OPC-UA標(biāo)準(zhǔn)
• 事實(shí)標(biāo)準(zhǔn)API：源自現(xiàn)有的成功解決方案（開(kāi)源框架、商業(yè)產(chǎn)品或云服務(wù)）。示例：Amazon S3（來(lái)自單一供應(yīng)商的所有權(quán)），Apache Kafka（來(lái)自充滿活力的社區(qū)的開(kāi)源）。
• API規(guī)范：定義供應(yīng)商如何實(shí)現(xiàn)相關(guān)產(chǎn)品的規(guī)范文檔。對(duì)于所有功能的實(shí)現(xiàn)，沒(méi)有完整的合規(guī)性測(cè)試或完整的認(rèn)證。導(dǎo)致的結(jié)果是一個(gè)“標(biāo)準(zhǔn)API”，再各種實(shí)現(xiàn)之間沒(méi)有可移植性。例如：JMS，請(qǐng)注意，為了能夠使用JMS的一系列合規(guī)性組件，供應(yīng)商必須向Oracle簽署非常繁瑣的報(bào)告。

替代類型的標(biāo)準(zhǔn)需要權(quán)衡取舍。如果您想了解更多信息，請(qǐng)查看過(guò)去幾年Apache Kafka如何成為數(shù)據(jù)流的事實(shí)標(biāo)準(zhǔn)。

與過(guò)去幾十年將工作負(fù)載放在單個(gè)數(shù)據(jù)中心相比，可移植性和遷移性在混合和多云環(huán)境中變得更加重要。

JMS是面向消息的中間件的規(guī)范

JMS是目前在Java Community Process下作為JSR 343維護(hù)的規(guī)范。最新（尚未發(fā)布）版本JMS 3.0作為 Jakarta EE 的一部分正在早期開(kāi)發(fā)中，并更名為Jakarta Messaging API。今天，JMS 2.0是流行的消息代理實(shí)施中使用的規(guī)范(沒(méi)有人知道JMS 3.0將走向何方)。因此，這里重點(diǎn)介紹JMS 2.0規(guī)范以解決現(xiàn)實(shí)世界的難題。通常，當(dāng)人們提及JMS時(shí)，他們指的是JMS消息代理實(shí)現(xiàn)，而不是JMS API規(guī)范。下文會(huì)用“JMS消息代理”來(lái)替代JMS（即 API），并沒(méi)有指定JMS實(shí)現(xiàn)中已知的特性。JMS消息代理和JMS可移植性神話

JMS開(kāi)發(fā)規(guī)范提供一個(gè)通用Java庫(kù)來(lái)訪問(wèn)不同的消息供應(yīng)商的代理。它用來(lái)充當(dāng)消息代理供應(yīng)商專有API的包裝器，就像JDBC為數(shù)據(jù)庫(kù)API提供類似功能一樣。然而，這種簡(jiǎn)單的集成結(jié)果并不能實(shí)現(xiàn)。因?yàn)?strong>將JMS代碼從一個(gè)供應(yīng)商的代理遷移到另一個(gè)供應(yīng)商非常復(fù)雜，原因如下：

• 并非所有JMS功能都是必需的（安全性、隊(duì)列標(biāo)簽、集群、路由、壓縮等等）
• 沒(méi)有用于傳輸?shù)腏MS規(guī)范
• 沒(méi)有規(guī)范來(lái)定義如何實(shí)現(xiàn)持久性
• 沒(méi)有規(guī)范來(lái)定義如何實(shí)現(xiàn)容錯(cuò)或高可用性
• 不同供應(yīng)商對(duì)JMS規(guī)范的不同理解可能導(dǎo)致相同JMS功能具有潛在的行為差異
• 沒(méi)有安全規(guī)范
• 代理間中沒(méi)有關(guān)于增值功能的規(guī)范（例如主題到隊(duì)列橋接、代理間路由、訪問(wèn)控制列表等）

因此，JMS供應(yīng)商之間的簡(jiǎn)單源代碼遷移和互操作性就是一個(gè)神話！供應(yīng)商在代理中提供了大量獨(dú)特的功能（例如：主題到隊(duì)列的映射、代理路由等），它們?yōu)閼?yīng)用程序提供架構(gòu)功能，但它們是代理功能的一部分，而不是應(yīng)用程序或JMS的一部分規(guī)格。

Apache Kafka是數(shù)據(jù)流的開(kāi)源協(xié)議實(shí)現(xiàn)

Apache Kafka是一種實(shí)時(shí)數(shù)據(jù)流處理的可靠且可擴(kuò)展的實(shí)現(xiàn)。該項(xiàng)目是開(kāi)源的，在Apache 2.0許可下可用，并由一個(gè)龐大的社區(qū)推動(dòng)發(fā)展。Apache Kafka不是OPC-UA 之類的標(biāo)準(zhǔn)或JMS之類的規(guī)范。但是，Kafka至少提供了源代碼，參考實(shí)現(xiàn)、協(xié)議和API定義等。

Kafka已經(jīng)成為了數(shù)據(jù)流領(lǐng)域的事實(shí)標(biāo)準(zhǔn)。今天，超過(guò)100000個(gè)組織使用 Apache Kafka；Kafka API也已經(jīng)成為事件驅(qū)動(dòng)架構(gòu)和事件流的事實(shí)標(biāo)準(zhǔn)。它在所有行業(yè)和基礎(chǔ)設(shè)施中都有用例，包括各種事務(wù)處理和分析負(fù)載在邊緣、混合、多云環(huán)境中都有用到。

可能有些人對(duì)于Kafka API并不熟悉。這里澄清一下：如前所述，Apache Kafka是分布式數(shù)據(jù)流平臺(tái)的一種實(shí)現(xiàn)，包括服務(wù)器端和客戶端以及用于生產(chǎn)和消費(fèi)事件、配置、安全性、操作等的各種API。Kafka API也是重要的，因?yàn)镵afka可重寫，如Azure Event Hubs和 Redpanda就使用了它們。

Apache Kafka的可移植性：又一個(gè)神話？

Apache Kafka作為開(kāi)源項(xiàng)目，本身就已經(jīng)是非常完整的Kafka實(shí)現(xiàn)。不少供應(yīng)商已經(jīng)使用整個(gè)Apache Kafka方案，并圍繞它構(gòu)建更高級(jí)的產(chǎn)品。Kafka的遷移非常簡(jiǎn)單，因?yàn)橛贙afka而言，不同供應(yīng)商都采用相同的規(guī)范，代碼、庫(kù)和包都是相同的。例如，從Cloudera到Confluent部署或從自我管理的Apache Kafka開(kāi)源基礎(chǔ)架構(gòu)到無(wú)服務(wù)器Confluent Cloud的遷移都非常成功。

Kafka API：Kafka的重寫Like Azure Event Hubs、Redpanda、Apache Pulsar

隨著Kafka在全球的成功，一些供應(yīng)商和云服務(wù)并沒(méi)有在Apache Kafka實(shí)現(xiàn)上構(gòu)建產(chǎn)品。相反，他們通過(guò)Kafka API重新構(gòu)建了自己的產(chǎn)品。底層實(shí)現(xiàn)是特有的（如Azure的云服務(wù)事件中心）或開(kāi)源的（如Apache Pulsar的Kafka橋或Redpanda用C++重寫的）。

所以，我們要看供應(yīng)商到底是集成了整個(gè)Apache Kafka項(xiàng)目，還是重寫了完整的API。使用Kafka API重寫Kafka是一個(gè)全新的實(shí)現(xiàn)！許多供應(yīng)商甚至在其支持條款和條件中，完全排除了某些組件或API（例如用于數(shù)據(jù)整合的Kafka Connect或用于流處理的 Kafka Streams），或者排除了諸如一次性語(yǔ)義或長(zhǎng)期存儲(chǔ)等關(guān)鍵特性。

目前市面上有各種各樣的Kafka產(chǎn)品，比如：Confluent、Cloudera、Red Hat 或Amazon MSK等Kafka供應(yīng)商，還有Azure Event Hubs、AWS Kinesis、Redpanda或Apache Pulsar等相關(guān)技術(shù)。如何評(píng)估這些呢？首先，應(yīng)該對(duì)需求進(jìn)行專業(yè)測(cè)試。如果Kafka-to-XYZ橋接的代碼少于一百行，或者從中間件供應(yīng)商處下載的是Exe的Windows Kafka服務(wù)器程序，一定要對(duì)上述代碼和程序持懷疑態(tài)度。閃光的不都是金子。某些框架或供應(yīng)商還是有華而不實(shí)的嫌疑的。比如說(shuō)，僅僅支持Kafka API、提供完全托管的無(wú)服務(wù)器Kafka產(chǎn)品，再比如在Kafka 上強(qiáng)推具有不確定性和被懷疑的功能 (FUD)等。例如，Kai就對(duì)Pulsar總是試圖通過(guò)在開(kāi)源社區(qū)中創(chuàng)建大量“不確定性和神話”來(lái)變得比Kafka更好而感到惱火。在Kai看來(lái)，“不確定性”對(duì)供應(yīng)商來(lái)說(shuō)都是錯(cuò)誤的策略。基于這個(gè)原因，Kafka的使用率仍在瘋狂增長(zhǎng)，而Pulsar的百分比增長(zhǎng)要慢得多（當(dāng)然，二者本身的下載量的差距也十分明顯）。

3、事務(wù)性與分析性工作負(fù)載  

JMS消息代理僅支持為低容量消息提供事務(wù)功能。而Apache Kafka更為強(qiáng)大，它支持低容量和高容量的消息，且支持事務(wù)性和分析性工作負(fù)載。JMS：會(huì)話和兩階段提交 (XA) 事務(wù)大多數(shù)JMS消息代理都很好地支持事務(wù)性工作負(fù)載。事務(wù)處理會(huì)話支持單個(gè)事務(wù)系列。每個(gè)事務(wù)將一組產(chǎn)生者消息和一組消費(fèi)者消息組合成一個(gè)原子工作單元。兩階段提交事務(wù)（XA 事務(wù)）在有限的范圍內(nèi)工作。它們適用于與大型機(jī)CICS / DB2或Oracle數(shù)據(jù)庫(kù)等其他系統(tǒng)整合在一起。但操作較難，并且不能擴(kuò)展到每秒幾筆交易。

需要注意的是，與會(huì)話事務(wù)不同，JMS 2.0規(guī)范并不強(qiáng)制支持XA事務(wù)。

Kafka：Exactly-Once Semantics和事務(wù)API

Kafka是一個(gè)分布式的容錯(cuò)系統(tǒng)，天生具有彈性（如果您正確部署和操作它）?？梢源_保沒(méi)有宕機(jī)和數(shù)據(jù)丟失，就像在您最喜歡的數(shù)據(jù)庫(kù)、大型機(jī)或其他核心平臺(tái)中一樣安全可靠。

甚至更好：Kafka的事務(wù)API，即Exactly-Once Semantics (EOS)，從Kafka 0.11開(kāi)始可用。EOS使構(gòu)建事務(wù)工作負(fù)載變得更加容易，因?yàn)槟辉傩枰幚碇貜?fù)項(xiàng)。Kafka通過(guò)事務(wù)API支持跨多個(gè)分區(qū)的原子寫入事務(wù)。這允許生產(chǎn)者將一批消息發(fā)送到多個(gè)分區(qū)。批處理中的所有消息最終對(duì)任何消費(fèi)者都是可見(jiàn)的，或者對(duì)消費(fèi)者不可見(jiàn)。

Kafka事務(wù)的工作方式與JMS事務(wù)非常不同。但目標(biāo)是相同的：每個(gè)消費(fèi)者只接收一次生成的事件?？梢栽诓┛臀恼隆笆褂肁pache Kafka的數(shù)據(jù)流中的分析與事務(wù)”中查找更多詳細(xì)信息。

4、Push vs. Pull 消息消費(fèi)  

JMS消息代理將消息推送到消費(fèi)者應(yīng)用程序。Kafka消費(fèi)者拉取消息，為獨(dú)立的消費(fèi)者應(yīng)用程序提供真正的解耦和背壓處理。

對(duì)于像基于JMS的消息代理這樣的實(shí)時(shí)消息系統(tǒng)來(lái)說(shuō)，推送消息似乎是顯而易見(jiàn)的選擇。但是，基于推送的消息傳遞在解耦和可擴(kuò)展性方面存在各種缺點(diǎn)。

JMS希望代理提供背壓并實(shí)現(xiàn)“預(yù)取”功能，但這不是強(qiáng)制性的。如果使用，代理將控制您無(wú)法控制的背壓。

使用Kafka，消費(fèi)者可以控制背壓。每個(gè)Kafka消費(fèi)者實(shí)時(shí)、批量或僅按需消費(fèi)事件——以特定消費(fèi)者支持和處理數(shù)據(jù)流的方式。對(duì)于許多不靈活和非彈性的環(huán)境來(lái)說(shuō)，這是一個(gè)巨大的優(yōu)勢(shì)。

因此，雖然JMS有某種背壓，但如果隊(duì)列已滿，生產(chǎn)者就會(huì)停止。在Kafka中，您可以控制消費(fèi)者的背壓。無(wú)法使用JMS擴(kuò)展生產(chǎn)者（因?yàn)镴MS隊(duì)列或主題中沒(méi)有分區(qū)）。

JMS消費(fèi)者可以擴(kuò)展，但會(huì)失去有保證的排序。JMS消息代理中的保證排序僅通過(guò)單個(gè)生產(chǎn)者、單個(gè)消費(fèi)者和事務(wù)起作用。

5、二者的API復(fù)雜度不同 

JMS API提供了簡(jiǎn)單的操作來(lái)生成和消耗消息。Apache Kafka有一個(gè)更細(xì)粒度的API，它帶來(lái)了額外的功能和復(fù)雜性。

JMS供應(yīng)商在規(guī)范下的實(shí)現(xiàn)中隱藏了所有很酷的功能。你只得到5%（無(wú)控制，由供應(yīng)商提供的功能）。你需要自己實(shí)現(xiàn)剩下的功能。相反，Kafka暴露了一切功能，而大多數(shù)開(kāi)發(fā)人員只需要5%?？傊?，請(qǐng)注意JMS消息代理的構(gòu)建是為了將消息從數(shù)據(jù)源發(fā)送到一個(gè)或多個(gè)數(shù)據(jù)接收器。Kafka是一個(gè)數(shù)據(jù)流平臺(tái)，提供更多功能、特性、事件模式和處理選項(xiàng)；并且平臺(tái)規(guī)模更大。考慮到這一點(diǎn)，二者的API非常不同并且具有不同的復(fù)雜性也就不足為奇了。如果您的用例只需要每秒從A向B發(fā)送幾條消息，那么JMS是正確的選擇并且使用簡(jiǎn)單！如果您需要任意規(guī)模的流數(shù)據(jù)中心，包括數(shù)據(jù)整合和數(shù)據(jù)處理，那只有Kafka。

異步請(qǐng)求-回復(fù)與動(dòng)態(tài)數(shù)據(jù)JMS開(kāi)發(fā)人員的一個(gè)初衷是使用Kafka中的請(qǐng)求-響應(yīng)功能。請(qǐng)注意，這種設(shè)計(jì)模式在消息傳遞系統(tǒng)中與RPC（遠(yuǎn)程過(guò)程調(diào)用）不同，消息代理中的請(qǐng)求-回復(fù)是一種利用相關(guān)ID的異步通信。

從生產(chǎn)者（比如移動(dòng)應(yīng)用程序）到消費(fèi)者（比如數(shù)據(jù)庫(kù)）獲取事件的異步消息傳遞是一種非常傳統(tǒng)的工作流程。無(wú)論是執(zhí)行發(fā)后即忘還是請(qǐng)求回復(fù)，數(shù)據(jù)都將置于靜止?fàn)顟B(tài)以供進(jìn)一步處理。JMS支持開(kāi)箱即用的請(qǐng)求-回復(fù)，非常簡(jiǎn)單。Kafka日志是持久的，帶有事件流的動(dòng)態(tài)數(shù)據(jù)會(huì)持續(xù)處理數(shù)據(jù)。Kafka應(yīng)用程序?qū)崟r(shí)或批量維護(hù)和查詢狀態(tài)。對(duì)于大多數(shù)開(kāi)發(fā)人員和架構(gòu)師來(lái)說(shuō)，數(shù)據(jù)流是一種范式轉(zhuǎn)變。這種設(shè)計(jì)模式非常不同。千萬(wàn)不要嘗試使用相同的模式和API在Kafka中重新實(shí)現(xiàn)JMS應(yīng)用程序。這種反模式極可能失敗。

請(qǐng)求-響應(yīng)模式的效率低下可能會(huì)導(dǎo)致非常多的延遲，而HTTP或gRPC適用于某些特定的用例。CQRS（命令查詢職責(zé)隔離）將“請(qǐng)求-響應(yīng)”替換為流數(shù)據(jù)的Kafka。但JMS API則無(wú)法實(shí)現(xiàn)CQRS，因?yàn)镴MS不提供狀態(tài)功能并且缺乏事件溯源功能。請(qǐng)求-響應(yīng)模式的Kafka示例對(duì)于許多Kafka用例，CQRS是更好的設(shè)計(jì)模式。盡管如此，請(qǐng)求-響應(yīng)模式也可以用Kafka來(lái)實(shí)現(xiàn)，但注意：嘗試像在JMS消息代理中那樣做（帶有臨時(shí)隊(duì)列等）最終會(huì)宕機(jī)Kafka集群（因?yàn)樗墓ぷ鞣绞讲煌?。Kafka Spring Boot Kafka模板庫(kù)有大量的實(shí)例，其使用Kafka構(gòu)建的請(qǐng)求-回復(fù)模式。

Kafka模板的Spring文檔有很多關(guān)于Kafka的請(qǐng)求/回復(fù)模式的詳細(xì)信息。因此，如果使用Spring，那么使用Kafka實(shí)現(xiàn)請(qǐng)求/響應(yīng)模式非常簡(jiǎn)單。

6、持久性存儲(chǔ)與真正的解耦  

JMS消息代理使用存儲(chǔ)系統(tǒng)來(lái)提供高可用性。Kafka的存儲(chǔ)系統(tǒng)更先進(jìn)，可以實(shí)現(xiàn)歷史事件的長(zhǎng)期存儲(chǔ)、背壓處理和可重放功能。

Kafka存儲(chǔ)遠(yuǎn)不止JMS的持久性功能

當(dāng)Kai向經(jīng)驗(yàn)豐富的JMS開(kāi)發(fā)人員解釋Kafka存儲(chǔ)系統(tǒng)時(shí)，幾乎總是得到相同的回應(yīng)：“我們的JMS消息代理XYZ也有存儲(chǔ)。Kafka的好處在哪里？”JMS使用臨時(shí)存儲(chǔ)系統(tǒng)，其中消息僅在被處理之前被持久化。

消息的長(zhǎng)期存儲(chǔ)和可重放性功能就不是為JMS設(shè)計(jì)的概念

附加日志、偏移量、排序保證、保留時(shí)間、壓縮主題等Kafka的核心原則提供了許多超出JMS的持久性保證的額外好處。背壓處理、消費(fèi)者之間的真正解耦、歷史事件的可重放性等等是JMS和Kafka之間的巨大差異。翻閱Kafka文檔，深入了解Kafka存儲(chǔ)系統(tǒng)。Kafka的分層存儲(chǔ)，通過(guò)在Kafka日志中提供更好的可擴(kuò)展性和具有成本效益的長(zhǎng)期存儲(chǔ)，也是值得深究的技術(shù)細(xì)節(jié)。

7、數(shù)據(jù)處理方式不同 

JMS消息代理提供簡(jiǎn)單的服務(wù)器端事件處理，例如基于消息內(nèi)容的過(guò)濾或路由。Kafak消息代理是不夠智能的。它的數(shù)據(jù)處理在解耦的應(yīng)用程序/微服務(wù)中執(zhí)行。

JMS服務(wù)器端過(guò)濾和路由

大多數(shù)JMS消息代理都為服務(wù)器端事件處理提供了一些功能。這些功能對(duì)于某些工作負(fù)載很方便！請(qǐng)注意，服務(wù)器端處理通常是有代價(jià)的。例如：

• JMS預(yù)過(guò)濾可伸縮性問(wèn)題：代理必須處理很多事情。這可以用隱藏的方式宕掉JMS服務(wù)。
• JMS選擇器（路由）性能問(wèn)題：它會(huì)消耗掉集群40-50% 的性能

當(dāng)然，如果可以容忍這些缺點(diǎn)，那么它也不失為一個(gè)很棒的功能。

Kafka：弱管道和強(qiáng)終端

Kafka 有意不提供服務(wù)器端處理，這處理發(fā)生在智能端點(diǎn)。這是一個(gè)非常著名的設(shè)計(jì)模式：弱管道和強(qiáng)終端

缺點(diǎn)是您需要分別在應(yīng)用程序/微服務(wù)/數(shù)據(jù)產(chǎn)品中實(shí)現(xiàn)相關(guān)邏輯。這在無(wú)服務(wù)器環(huán)境中不是大問(wèn)題。它在自我管理的環(huán)境中變得更加復(fù)雜。

然而，這種架構(gòu)一個(gè)非常大的好處在于：應(yīng)用程序/技術(shù)/編程語(yǔ)言之間可以做到真正解耦，用于構(gòu)建業(yè)務(wù)邏輯和基礎(chǔ)設(shè)施操作的業(yè)務(wù)單元之間的關(guān)注點(diǎn)分離，以及更好的可擴(kuò)展性和彈性。

Kafka未來(lái)是否會(huì)有一定的服務(wù)器端處理能力？Kai認(rèn)為當(dāng)然會(huì)有。特別是對(duì)于少量工作負(fù)載，性能和可擴(kuò)展性的影響都應(yīng)該是可以接受的！不過(guò)，風(fēng)險(xiǎn)在于開(kāi)發(fā)者是否會(huì)濫用這些功能。未來(lái)將會(huì)證明Kafka是否具有此項(xiàng)功能。

復(fù)雜操作與無(wú)服務(wù)器云  

可擴(kuò)展JMS消息代理或Kafka集群的自我管理操作很復(fù)雜。無(wú)服務(wù)器產(chǎn)品（應(yīng)該）擔(dān)負(fù)起運(yùn)營(yíng)重?fù)?dān)。

不管是JMS還是Kafka，操作集群都很復(fù)雜

一個(gè)基本的JMS消息代理相對(duì)容易操作（包括主動(dòng)/被動(dòng)設(shè)置）。但是，這限制了可擴(kuò)展性和可用性。JMS API旨在與單個(gè)代理或主動(dòng)/被動(dòng)通信以實(shí)現(xiàn)高可用性。這個(gè)概念涵蓋了應(yīng)用領(lǐng)域。對(duì)于 JMS 消息代理來(lái)說(shuō)操作集群是非常復(fù)雜。來(lái)自商業(yè)供應(yīng)商的更高級(jí)的消息代理集群更強(qiáng)大，但是也更難操作。Kafka是一個(gè)強(qiáng)大的分布式系統(tǒng)。

完全托管的無(wú)服務(wù)器云救援

在Kafka中，這情況就不同了。由于Kafka是一個(gè)可擴(kuò)展的分布式系統(tǒng)，云提供商可以構(gòu)建云原生無(wú)服務(wù)器產(chǎn)品。構(gòu)建這樣一個(gè)完全托管的基礎(chǔ)設(shè)施仍然非常困難。因此，評(píng)估相關(guān)云產(chǎn)品，而不僅僅是看其外在的營(yíng)銷口號(hào)！

每個(gè)Kafka云服務(wù)都標(biāo)榜為“完全托管”或“無(wú)服務(wù)器”，但大多數(shù)不是。一些云供應(yīng)商甚至從他們的Kafka云產(chǎn)品中排除了對(duì)Kafka的支持。瘋狂，但夠真實(shí)。所以檢查條款和相關(guān)條件可以作為評(píng)估的一部分。

9、Java/JVM 與任何編程語(yǔ)言  

JMS專注于JVM編程語(yǔ)言的Java生態(tài)系統(tǒng)。而Kafka獨(dú)立于編程語(yǔ)言。

正如名稱JMS（及Java 消息服務(wù)）所說(shuō)：JMS是專門為Java編寫的。一些代理供應(yīng)商支持他們自己的API 和客戶端。這些是該供應(yīng)商專有的。我過(guò)去見(jiàn)過(guò)的幾乎所有重要的JMS項(xiàng)目都使用Java代碼。

Apache Kafka也只提供了一個(gè)Java客戶端。但是供應(yīng)商和社區(qū)為幾乎所有編程語(yǔ)言提供了其他語(yǔ)言綁定，以及用于HTTP通信的REST API，用于生成/消費(fèi)來(lái)自Kafka的事件。

Kafka后端的真正解耦使不同的客戶端應(yīng)用程序能夠相互交流，無(wú)論使用哪種編程語(yǔ)言。這種靈活性允許構(gòu)建適當(dāng)?shù)念I(lǐng)域驅(qū)動(dòng)設(shè)計(jì) (DDD)，其中微服務(wù)架構(gòu)利用Kafka作為中樞神經(jīng)系統(tǒng)。

10、單 JMS 部署與多區(qū)域（包括混合云和多云）Kafka 復(fù)制  

JMS API是應(yīng)用程序和代理之間通信的客戶端規(guī)范。Kafka是一個(gè)分布式系統(tǒng)，可為混合云和多云用例提供各種架構(gòu)。

JMS是客戶端規(guī)范，而多數(shù)據(jù)中心復(fù)制是代理功能。這里不再深入講解，簡(jiǎn)單地說(shuō)：JMS消息代理不是為跨區(qū)域、洲際或混合/多云環(huán)境的復(fù)制場(chǎng)景而構(gòu)建的。

Apache Kafka的多集群和跨數(shù)據(jù)中心部署已成為常態(tài)而非例外。各種場(chǎng)景需要多集群Kafka解決方案?？梢愿鶕?jù)實(shí)際情況進(jìn)行考慮具體要求和權(quán)衡取舍。諸如MirrorMaker（開(kāi)源）或Confluent Cluster Linking（商業(yè)）等Kafka技術(shù)都支持災(zāi)難恢復(fù)、聚合分析、云遷移、任務(wù)關(guān)鍵延伸部署和全域Kafka部署等用例。

11、JMS 和 Kafka對(duì)比總結(jié)  

以上這10個(gè)比較維度，表明JMS和Kafka是有著非常大差異的。雖然兩者也有重疊的領(lǐng)域（例如，消息傳遞、實(shí)時(shí)、關(guān)鍵任務(wù)），但它們使用不同的技術(shù)能力、特性和架構(gòu)來(lái)支持其他功能用例。

簡(jiǎn)而言之，使用JMS代理進(jìn)行從A到B的簡(jiǎn)單和低容量的消息傳遞。而Kafka通常是許多數(shù)據(jù)源和數(shù)據(jù)接收器之間的實(shí)時(shí)數(shù)據(jù)中心（許多人稱其為企業(yè)架構(gòu)的中心實(shí)時(shí)組織系統(tǒng)）。

Kafka在任意規(guī)模的數(shù)據(jù)集成和數(shù)據(jù)處理能力、真正的解耦、事件可重放性是與基于JMS的MQ系統(tǒng)的主要區(qū)別。但是，尤其是在無(wú)服務(wù)器云中，不要擔(dān)心Kafka太強(qiáng)大（太復(fù)雜）。無(wú)服務(wù)器Kafka項(xiàng)目通常以非常低的容量、非常便宜的方式進(jìn)行，沒(méi)有運(yùn)營(yíng)負(fù)擔(dān)。然后它可以隨著您不斷增長(zhǎng)的業(yè)務(wù)而擴(kuò)展，而無(wú)需重新構(gòu)建應(yīng)用程序。

12、選擇與評(píng)估要考慮哪些？ 

了解基于JMS的消息代理和由Apache Kafka提供支持的數(shù)據(jù)流之間的技術(shù)差異。評(píng)估這兩個(gè)選項(xiàng)以找到解決問(wèn)題的正確工具。在消息傳遞或數(shù)據(jù)流中，進(jìn)行更詳細(xì)的評(píng)估。每個(gè)消息代理都是不同的，即使它們都符合JMS。同樣，所有Kafka產(chǎn)品和云服務(wù)在功能、支持和成本方面都不同。

所以開(kāi)發(fā)者應(yīng)針對(duì)實(shí)際需求和二者的用例及限制來(lái)進(jìn)行適當(dāng)?shù)倪x擇。

?譯者介紹

田小保，51CTO社區(qū)編輯，資深云計(jì)算架構(gòu)師，互聯(lián)網(wǎng)老兵，擁有15年以上互聯(lián)網(wǎng)軟件開(kāi)發(fā)和架構(gòu)經(jīng)驗(yàn)，具有多年的項(xiàng)目管理經(jīng)驗(yàn)。熟悉云計(jì)算、大數(shù)據(jù)等的互聯(lián)網(wǎng)開(kāi)發(fā)技術(shù)。

原文鏈接：

https://dzone.com/articles/comparison-jms-message-queue-vs-apache-kafka?fromrel=true