ActiveMQ 6.x的特性和路线图

ActiveMQ 6.x的特性和路线图

关键字: [Amazon Web Services re:Invent 2024， 亚马逊云科技， ActiveMQ， Message Broker， Activemq Features， Jms Standards， Message Routing， Message Buffering， Message Filtering， Transaction Handling， Jms 2.0 Support， Jakarta Messaging Compliance， Replicated Message Persistence]

导读

参加本次会议，探索Apache ActiveMQ 6.x在构建强大的消息应用方面的变革性能力。体验来自JMS 2.0和Jakarta 3.1实现的简化API和增强功能，改进的消息处理和传递延迟。了解Apache ActiveMQ 6.x的功能概览，并深入了解开源路线图，重点关注未来在性能、可扩展性和可用性方面的增强。参与者将获得利用这些进步为其业务打造更高效、更可靠的消息传递解决方案所需的知识。

演讲精华

以下是小编为您整理的本次演讲的精华。

在开源软件领域，Apache ActiveMQ被广泛认为是现代时代最广泛使用的消息代理之一。这一享有盛誉的地位归功于Apache软件基金会和行业巨头如亚马逊云科技的不懈努力和协作。在这一努力的前沿，有两位杰出的人物Jules Goebel和JB Onofré，他们的专业知识和远见推动了ActiveMQ的发展。

Jules Goebel是亚马逊云科技的一位资深专业人士，领导着消息服务部门，负责Amazon MQ服务的开发和运营，该服务包括ActiveMQ和RabbitMQ的托管产品。他的角色至关重要，确保客户能够利用这些开源消息代理的强大功能，而无需承担复杂的管理任务，从而能够专注于应用程序开发。

与Jules一起参与这一旅程的是JB Onofré，他是Apache软件基金会的一位知名人士，担任董事会成员。他为20至25个Apache项目做出了贡献，其中包括ActiveMQ，他在该项目中担任项目管理委员会(PMC)成员的重要职位。JB的专业知识和奉献精神对于塑造ActiveMQ的未来、确保其持续创新至关重要。

要全面理解ActiveMQ的重要性，必须掌握消息代理的基本概念。正如JB娓娓道来，消息代理充当中介，促进生产者和消费者之间的无缝消息交换。生产者和消费者的解耦是消息代理架构的基石，支持各种用例，并促进灵活性和可扩展性。

生产者在不知道消费者的身份和位置的情况下，只需将消息传输到代理中的指定目的地。相反，消费者也不知道消息的来源，只从同一目的地接收消息。JB形象地将这种“中间人”模式称为“中间人模式”，它使代理能够对消息应用高级功能和逻辑，将其功能提升到远远超过简单的消息服务器。

消息代理如ActiveMQ的一项关键能力是消息路由。代理可以精确地将传入消息从一个目的地(如队列或主题)路由到另一个复合目的地(单个队列或一组队列)。这种灵活性支持复杂的消息流程编排，可根据每个应用程序的具体需求进行定制。

缓冲或同步传递是ActiveMQ另一项关键功能。通过在代理中累积消息，消费者可以自由地以自己的速度消费消息，确保无缝可靠的传递机制。目的地的性质(队列或主题)决定了消费模式，分别为一对多或多对多。

与路由类似，ActiveMQ还提供了强大的过滤功能。代理可以根据预定义的条件精确地选择性传递或丢弃消息，这一功能称为选择器。这种细粒度控制使消费者只接收与其特定需求相关的消息，优化资源利用率，提高整体系统效率。

然而，JB认为事务和确认是ActiveMQ最关键的用例。通过将代理视为事务资源，生产者可以放心，他们的消息已成功传递并持久化到代理的领域中。在发生故障或中断的情况下，代理的事务功能支持重试和重新发送，确保整个消息生命周期的数据完整性和一致性。

ActiveMQ坚持遵循行业标准是其设计理念的一个标志。无论是Java消息服务(JMS)规范、事实上的AMQP和MQTT协议，还是其他新兴标准，ActiveMQ都勤勉地实现和支持这些指南，促进了与各种系统和应用程序的互操作性和无缝集成。

ActiveMQ的核心是消息运行时，由两个不同的组件组成:代理和客户端。代理组件可以作为独立实体部署，执行后即可促进消息交换。或者，ActiveMQ可以无缝嵌入应用程序中，利用Java虚拟机(JVM)进行直接消息传递，消除网络通信开销。

ActiveMQ的客户端组件同样灵活，适用于各种编程语言和平台。对于基于JMS的应用程序，ActiveMQ提供了所需的连接工厂，使开发人员能够利用熟悉的JMS API。但是，对于需要替代协议(如STOMP)的场景，ActiveMQ提供了专门为Python或Rust等特定语言量身定制的客户端，确保了全面一致的无缝体验。

ActiveMQ的一个显著特征是其多传输架构。客户端与代理之间的通信，甚至在网络配置中代理之间的通信，都可以通过各种协议进行。从无处不在的TCP和SSL到专门用于STOMP的HTTP和WebSocket，ActiveMQ的灵活性确保了与不同基础设施和应用程序架构的无缝集成。

除了多传输能力，ActiveMQ还具有真正的多平台特性。作为一种基于Java的解决方案，ActiveMQ代理只需要一个JVM即可运行，不需要本机代码依赖。这种可移植性使开发人员能够在任何支持JVM的机器或平台上部署ActiveMQ，最大限度地提高了灵活性，最小化了兼容性问题。

JB Onofré对ActiveMQ演变历史的回顾为我们提供了宝贵的见解，揭示了塑造其当前形态的里程碑。ActiveMQ的起源可以追溯到2004年，当时一家名为LogicBlaze的小公司着手创建一个开源JMS代理，这是由当时IBM MQ和TIBCO等专有解决方案的主导地位所驱动的。

2005年，ActiveMQ 3作为第一个生产级版本问世，标志着该项目的一个重大里程碑。这个版本引入了消息持久性机制，为可靠和持久的消息传递奠定了基础。随后将ActiveMQ 3捐赠给Apache软件基金会，为该项目在开源社区的孵化和进一步发展铺平了道路。

2006年发布的ActiveMQ 4在其前身的坚实基础上进行了增强和新功能的引入，如通过虚拟主题实现消息分组。这个版本获得了广泛的采用和热情，进入了各行各业的生产环境，包括金融行业。

2007年见证了ActiveMQ演进的一个关键时刻，发布了第5版。这个版本标志着代理的完全重写，引入了创新的KahaDB消息存储。KahaDB源于以前消息存储实现的集体经验和教训，承诺提供卓越的性能和可靠性，进一步巩固了ActiveMQ作为强大可扩展消息解决方案的地位。

与ActiveMQ 5的发布同期，该项目实现了一个重大里程碑，从Apache软件基金会的孵化项目过渡到顶级项目。这一提升不仅为ActiveMQ带来了更大的知名度和认可，也标志着该项目的成熟以及社区对其长期可行性的信心。

为了体现项目的包容性和对多样性的承诺，ActiveMQ欢迎Artemis代理(前身为HornetQ)加入其生态系统。经过审慎考虑，决定将Artemis整合为ActiveMQ项目的一部分，而不是将其建立为一个独立的顶级项目。这一战略举措促进了两个代理之间的协作和协同，使开发人员能够在统一的生态系统中利用两种解决方案的优势和功能。

2020年标志着ActiveMQ的另一个重大里程碑，发布了第6版。JB Onofré认为，这个版本的影响和重要性与关键的ActiveMQ 5相当。ActiveMQ 6的主要目标是完全符合JMS 2.0和Jakarta Messaging 3.0规范，这是使代理现代化并与最新行业标准保持一致的关键一步。

然而，ActiveMQ 6不仅仅是一个合规性练习，它还引入了一系列其他增强和改进。添加了对最新JVM版本(从JDK 17到Java 23)的支持，确保与最新Java版本的兼容性。此外，ActiveMQ 6还更新了关键依赖项，包括Spring、GT和Apache Camel 4，确保代理利用了这些广泛使用的框架和库的最新版本。

云部署是ActiveMQ 6的一个重点领域，在DockerHub上提供了现成的Docker镜像。这一举措促进了ActiveMQ代理在云环境中的无缝部署和扩展，满足了对云原生应用程序和基础设施日益增长的需求。

认识到安全性和可观察性的重要性，ActiveMQ 6在这些领域进行了重大改进。新增了MBean、Prometheus导出器和OpenTelemetry支持，为管理员和开发人员提供了对代理内部操作和性能指标的增强可见性。虽然ActiveMQ本身并不旨在提供全面的用户界面或仪表板，但这些新增功能使用户能够与现有的监控和可观察性工具集成，实现主动管理和故障排除。

ActiveMQ 6还将安全性增强作为一个优先事项，引入了新的插件和机制来支持基于角色的访问控制和其他安全最佳实践。KahaDB和事务管理等领域的性能优化进一步巩固了ActiveMQ 6作为一个健壮高效的消息传递解决方案。

ActiveMQ 6引入的最重大变化之一，也是JB演讲的重点，是采用了JMS 2.0规范，也称为GMS 2(通用消息服务2)。这一消息API的演进带来了急需的简化，解决了JMS 1.0应用程序中冗长和样板代码的问题。

JB用一个令人信服的代码示例说明了这种简化。在JMS 1.0世界中，向代理发送一条简单的文本消息需要一系列复杂的步骤，包括创建连接工厂、连接、会话、生产者，最后才是消息本身。这种冗长的过程与JMS 2.0方法的优雅形成鲜明对比，后者只需两行代码就能完成同样的任务:创建一个GMS上下文，并直接通过生产者发送消息负载。

异常处理是JMS 1.0应用程序中一个长期存在的痛点，在JMS 2.0中也得到了简化。之前版本中JMS异常的检查性质需要在整个代码库中使用try-catch块，导致代码杂乱且可读性差。然而，在JMS 2.0中，引入了非检查型JMSRuntimeException，简化了异常处理，允许开发人员更高效地捕获和处理异常。

除了简化之外，JMS 2.0还对消息API进行了细微但影响深远的改变。其中一个改变是在发送消息时可以直接发送负载，无需将负载包装在特定的消息类型(如TextMessage或ByteMessage)中。这种精简的方法进一步减少了样板代码，提高了开发人员的生产力。

消息消费在JMS 2.0中也发生了重大转变。开发人员现在有两种不同的选择来接收消息:阻塞式的receive方法或使用消息监听器。虽然JMS 1.0需要实现专用接口和onMessage方法来处理消息监听器，但JMS 2.0则采用了优雅的lambda表达式。这一改变允许开发人员使用简洁的lambda表达式内联定义消息监听器，进一步提高了代码的可读性和可维护性。

从JMS过渡到Jakarta Messaging 3.0引入了另一个值得注意的变化:命名空间从javax.jms转移到jakarta.jms。虽然这一变化看似微不足道，但它需要更新整个现有代码库，这可能是一个耗时且容易出错的过程。为了缓解这一负担，ActiveMQ 5.18引入了对两个命名空间的支持，为开发人员从JMS 1.0过渡到JMS 2.0和Jakarta Messaging 3.0提供了一个平稳的迁移路径。然而，ActiveMQ 6专门支持jakarta.jms命名空间，反映了该项目致力于采用最新标准和API的承诺。

Jakarta Messaging 3.0还对API进行了精简，删除了某些方法并引入了新功能。其中一个新增功能是在消息生产者上实现延迟传递，允许开发人员指定消息发送前的延迟时间，实现高级调度和编排场景。

异步消息生产是ActiveMQ和Jakarta Messaging 3.0规范中引入的另一个重大增强功能。传统上，消息生产者上的send方法是一个阻塞操作，导致应用程序必须等待从代理收到确认后才能继续。通过引入sendAsync方法，这种阻塞行为被消除，将确认处理委托给了一个单独的线程。这种异步方法有望提高吞吐量和响应能力，进一步增强了消息应用程序的性能和可扩展性。

正如JB Onofré总结的那样，采用JMS 2.0和Jakarta Messaging 3.0，以及各种JDK版本更新和依赖项升级，代表了ActiveMQ 6引入的核心重点和重大进步。

转移话题，Jules Goebel提供了关于Amazon MQ for ActiveMQ服务的见解，这是亚马逊云科技提供的一项托管服务，旨在简化ActiveMQ的部署和运营。该服务于2017年推出时最初支持ActiveMQ，2020年又增加了对RabbitMQ的支持。这种托管服务的主要优势在于拥有一支专门的专家团队，他们专门负责以安全、补丁、可靠性和健壮性的最佳实践来运行和操作ActiveMQ。通过将这些运营任务外包给亚马逊云科技，客户可以将精力集中在应用程序开发上，利用开源消息代理的强大功能，而无需承担相关的管理开销。

Jules深入探讨的一个特别值得注意的功能是ActiveMQ的跨区域数据复制。这一功能使客户能够将整个消息传递基础设施(包括配置、数据和状态)从主区域克隆到复制区域。引入这一功能的主要动机是为了应对灾难恢复场景，客户可以无缝地将工作负载转移到新区域，而不会造成数据丢失或状态不一致。

Jules提供了一个具体的示例来说明跨区域数据复制的概念。在这个场景中，主区域是us-east-1，所有生产者、消费者、数据库和其他应用程序组件都部署在那里。目标是将整个设置复制到复制区域us-west-2，创建配置的精确副本并持续在两个区域之间复制数据。

Amazon MQ服务采用的是热备用复制方式，这意味着虽然数据会持续复制到复制区域，但没有生产者或消费者应用程序可以直接连接到复制代理。所有应用程序流量仍然限制在主区域，确保了一致且可预测的消息传递流程。

在开发这一功能的过程中，他们意识到传统的复制方法(如流式传输事务日志或数据库日志)并不适合消息代理。消息代理的固有特性，即生产者竞相入队消息，消费者快速出队和确认，带来了独特的挑战。通常情况下，消息会被消费和删除的速度比复制到新区域的速度还快，导致潜在的数据丢失。

为了解决这一挑战，亚马逊云科技引入了一种滑动窗口机制，有意在复制过程中引入了轻微的延迟。通过允许在复制消息之前留出一个短暂的时间窗口供消息被消费和确认，复制引擎就能以比传统方法更快的速度有效捕获和复制消息。这种创新技术确保了即使在高吞吐量场景下也不会在复制过程中丢失任何消息。

一旦复制区域建立并开始数据复制，客户就可以根据优先级和具体场景执行切换或故障转移。

切换是一种计划内的事件，适用于那些将数据一致性置于可用性之上的客户。在这种情况下，客户发起一个命令将复制区域提升为新的主区域。当前的主区域将停止接受新连接，并完成任何剩余数据的复制到复制区域。一旦数据同步完成，复制区域就会被提升为主角色，开放自身接受新连接，并接管作为活动的消息传递基础设施。

这种切换过程确保了在过渡期间不会丢失任何数据，因为所有消息和状态在切换之前都已完全复制。客户可以自信地在区域之间来回切换，始终保持数据一致性。事实上，Jules提到，有几个客户会定期练习在区域之间切换，以验证其灾难恢复程序并确保无缝故障转移能力。

然而，在这个过程中的一个关键挑战是防止出现脑裂(split-brain)情况，即主代理和复制代理都认为自己是活动的主代理，导致消息队列无法调和，并可能造成数据损坏。Jules将其比作分布式系统中的“两位将军问题”，在网络故障或分区的情况下，无法确保两方之间的通信是一致的。

为防止分裂脑情况的风险， 亚马逊云科技 采用了一个跨多个区域运行的专用流程，远远超出了 Amazon MQ 本身运行的区域。这个流程专门负责管理哪个代理是主代理，哪个是副本代理。通过集中管理这一关键信息并确保其在各个区域的一致性， 亚马逊云科技 可以有效防止分裂脑情况的发生，即使在网络中断或故障的情况下也是如此。

代理本身被设计为在无法确认其主代理状态时，默认采用副本角色。这种故障安全方法与专用的分裂脑防止流程相结合，为确保数据完整性提供了保障。

Amazon MQ 服务提供的第二种切换模式是故障转移，旨在应对可用性优先于严格数据一致性的场景。故障转移是一种非计划事件，通常由主区域和副本区域之间的完全网络分区触发。在这种情况下，副本代理会立即晋升为主代理，而之前的主代理则使用前面描述的分裂脑防止系统降级为副本。

在故障转移期间，有可能某些消息在切换发生之前尚未复制到新的主区域。这些消息将保留在前一个主区域，可以通过后续切换回该区域来检索。然而，这种情况会带来复杂性，例如处理消费者试图确认新的主代理尚未收到的消息的情况。

为了解决这些复杂的边缘情况， 亚马逊云科技 采用了正式的验证方法，以确保在故障转移场景中不会丢失任何消息、数据或状态，即使在切换发生时数据同步尚未完成。虽然单凭思维过程无法解决所有可能的场景，但这些严格的验证技术可以确保在故障转移过程中保持数据完整性。

Jules 承认，虽然客户可以使用开源 ActiveMQ 产品实现类似的跨区域复制和故障转移机制，但所涉及的复杂性使其成为一项艰巨的任务。他强调，像 亚马逊云科技 这样的云提供商凭借其全球规模和专门的工程资源，更有能力应对这些挑战，并为大规模消息代理部署提供健壮、企业级的解决方案，满足严格的灾难恢复需求。

转向 Amazon MQ for ActiveMQ 服务的更广泛功能， Jules 强调了目前对 ActiveMQ 5.17 和 5.18 版本的支持。5.17 版本专注于 JMS 1.1 兼容性，而 5.18 则提供了一种混合方法，以促进迁移到 JMS 2.0 和 Jakarta Messaging 3.0。到 2024 年中期， 亚马逊云科技 计划引入对 ActiveMQ 6 的支持，使使用 JMS 2.0 工作负载的客户能够无缝过渡到托管服务。

指导 Amazon MQ 团队的核心原则之一是回馈开源 ActiveMQ 项目。随着他们从大规模运营 ActiveMQ 并处理各种工作负载中获得见解和经验，该团队将优先将这些经验贡献给开源社区。跨区域数据复制功能，特别是消息压缩和滑动窗口技术，就是 亚马逊云科技 正在努力集成到 ActiveMQ 核心代理中的此类贡献的例子。

此外， 亚马逊云科技 积极参与客户表达需求的特定功能领域。JMS 2.0 和 Jakarta Messaging 3.1 支持以及增强的身份验证和授权机制都是最受欢迎的功能。客户希望与企业级身份提供商(如 LDAP、OAuth 和 Amazon Identity and Access Management (IAM))无缝集成，后者适用于完全在 亚马逊云科技 生态系统中运行的客户。

亚马逊云科技 与 ActiveMQ 社区合作的另一个领域是为分布式 ActiveMQ 部署开发原生集群功能。Jules 对 亚马逊云科技 参与这一努力表示兴奋，旨在提高 ActiveMQ 安装的可扩展性和可用性。

回到 JB Onofré，他提供了 ActiveMQ 的高级路线图，概述了计划发布及其各自的重点领域。需要注意的是，虽然路线图代表了社区当前的讨论和意图，但具体的时间表和功能可能会根据持续的开发和共识建设工作而发生变化。

下一个主要版本 ActiveMQ 6.5 暂定于 2024 年第一或第二季度发布。该版本将专注于完成全面的 JMS 和 Jakarta Messaging 支持，解决 Jakarta Messaging 规范中任何尚未包含在 ActiveMQ 6.3 中的剩余缺失功能或特性。

在 6.5 之后，ActiveMQ 6.6 将集中于增强身份验证和授权功能。目标是提供开箱即用的插件和配置，以实现与各种身份验证和授权后端(如 OAuth 2.0、OpenID Connect (OIDC) 和其他行业标准协议)的无缝集成。这项工作是 ActiveMQ 社区与 Amazon MQ 团队通力合作的成果，利用他们的集体专业知识提供健壮、灵活的安全解决方案。

路线图上最受期待的功能之一是复制 KahaDB 的引入，计划在 ActiveMQ 6.7 中发布预览版。复制 KahaDB 旨在通过跨多个代理实例复制消息和确认来解决高可用性和故障转移场景。JB 提供了当前架构的见解，其中代理网络可以负载均衡消息，但如果代理发生故障，该代理中任何待处理的消息或事务都将丢失，直到它重新启动。

使用复制 KahaDB，愿景是拥有一个指定的主代理，将每个消息和确认复制到跟随者代理。如果主代理发生故障，跟随者代理上的复制数据可确保客户端能够无缝重新连接并继续生产和消费消息，而不会丢失任何事务或确认。这一功能有望显著提高 ActiveMQ 部署的可靠性和可用性，尤其是在云环境中，动态扩展和故障转移是关键需求。

JB 承认实现复制 KahaDB 存在挑战，特别是在性能和事务管理方面。因此，ActiveMQ 6.7 中的初始版本将是一个测试版，允许社区彻底测试和完善该功能，然后再将其提升为生产就绪状态。

展望未来，ActiveMQ 7.0 代表了该项目演进的重要里程碑。这个版本的主要目标之一是从代理代码库中移除对 Spring 框架的依赖。目前，ActiveMQ 严重依赖 Spring 进行依赖注入、命名空间管理和其他核心功能。虽然 Spring 为该项目提供了良好的服务，但这种依赖也带来了挑战，例如需要及时解决 Spring 生态系统中出现的任何安全漏洞或问题。

ActiveMQ 7.0 的计划是用替代方案取代 Spring，尽管具体细节仍在社区内讨论中。潜在选择包括轻量级依赖注入框架、利用 Apache Caraf 项目嵌入 ActiveMQ 的方法，或探索与较新框架(如 Quarkus)的集成。

除了移除 Spring 依赖项之外，ActiveMQ 7.0 还将标志着复制 KahaDB 的生产就绪版本发布。根据 JB 的估计，ActiveMQ 7.0 不太可能在 2025 年底之前发布，这凸显了交付这一重大架构变革所需的复杂性和努力。

在整个演讲过程中，Jules 和 JB 都向观众发出了开放邀请，邀请他们参与 ActiveMQ 开源项目和 Apache ActiveMQ 社区。他们鼓励有兴趣的人访问项目网站 activemq.apache.org 或直接与他们联系，以获取指导和指导机会。

最后，Jules 重申了客户反馈的重要性，并鼓励与会者完成会议调查。从这些调查中收集的见解对于塑造未来的内容并确保 亚马逊云科技 和 ActiveMQ 社区继续解决用户社区最紧迫的需求和关注点至关重要。

总之，亚马逊云科技 re:Invent 2024 上的“ActiveMQ 6.x 的特性和路线图”会议全面概述了 Apache ActiveMQ 项目的当前状态和未来路线图。它强调了 ActiveMQ 6 中引入的重大进展，特别是采用 JMS 2.0 和 Jakarta Messaging 3.0 规范，以及云部署、安全性和可观察性方面的增强。该会议还深入探讨了 Amazon MQ for ActiveMQ 托管服务提供的创新跨区域数据复制功能，展示了 亚马逊云科技 致力于为客户提供健壮、可扩展的消息代理解决方案的决心。 展望未来，路线图勾勒出令人兴奋的发展，包括改进的身份验证和授权支持、引入用于高可用性的复制KahaDB，以及最终在ActiveMQ 7.0中移除对Spring的依赖。在这一旅程中，亚马逊云科技、Apache软件基金会和更广泛的开源社区之间的合作将继续成为推动力，促进创新、知识共享，以及这种强大且广泛采用的开源消息代理的持续发展。

下面是一些演讲现场的精彩瞬间：

Jules Goebel是亚马逊云科技消息服务的负责人，他介绍了ActiveMQ，这是一款流行的开源消息代理，亚马逊正积极参与其开发。

他还重点介绍了Amazon MQ服务，该服务为ActiveMQ和RabbitMQ提供托管服务。

演讲者宣布将Artemis(前身为HornetQ)加入ActiveMQ生态系统，为用户提供两种代理选择:Artemis和经典ActiveMQ。

他强调了在GMS 2中使用lambda表达式简化了消息消费过程，减少了与JMS 1相比的样板代码。

亚马逊云科技推出了Amazon MQ for ActiveMQ，这是一项托管服务，简化了运行开源ActiveMQ消息代理的过程，允许开发人员专注于他们的应用程序，而亚马逊云科技负责安全性、补丁程序和可靠性。

亚马逊为ActiveMQ提供跨区域数据复制功能，可以实现跨区域无缝数据和状态复制，确保业务连续性和灾难恢复。

介绍了ActiveMQ 6.7中的新功能复制Kardi，它通过跨代理复制消息提供高可用性和容错能力，防止代理发生故障时数据丢失。

总结

在这个引人入胜的叙述中，我们探索了ActiveMQ这个广泛应用于各行业的开源消息代理。来自Apache软件基金会的著名人士JB Onofré带领我们追溯ActiveMQ的演进历程，从2004年诞生到2020年里程碑式的ActiveMQ 6版本发布。他详细阐述了构成消息代理的核心特性，包括消息路由、缓冲、过滤和事务管理。

ActiveMQ 6的发布成为一个关键里程碑，实现了对JMS 2和Jakarta Messaging 3规范的全面支持，支持现代JVM版本，并增强了云部署能力。JB揭示了JMS 2中API的简化，利用lambda表达式和异步消息传递来简化消息生产和消费。此外，他还阐述了ActiveMQ的路线图，包括改进身份验证和授权的计划，以及备受期待的ActiveMQ 6.7版本中的复制KahaDB功能，实现跨代理无缝消息复制。

来自亚马逊云科技的消息服务负责人Jules Goebel加入了这一叙述，展示了ActiveMQ在云端的强大功能，即Amazon MQ。他揭示了跨区域数据复制功能，这是一项突破性的解决方案，确保了跨区域的数据一致性和可用性。Jules深入探讨了防止脑裂和故障转移机制背后的复杂工程，凸显了亚马逊云科技将所学所得和增强功能反馈回开源社区的承诺。

在叙述的结尾，JB揭示了雄心勃勃的ActiveMQ 7路线图，包括移除Spring依赖项，以及复制KahaDB的生产就绪版本。JB和Jules向社区发出开放邀请，鼓励大家共同协作，为这个非凡的开源消息代理贡献力量，共同塑造它的未来。

亚马逊云科技（Amazon Web Services）是全球云计算的开创者和引领者。提供200多类广泛而深入的云服务，服务全球245个国家和地区的数百万客户。做为全球生成式AI前行者，亚马逊云科技正在携手广泛的客户和合作伙伴，缔造可见的商业价值 – 汇集全球40余款大模型，亚马逊云科技为10万家全球企业提供AI及机器学习服务，守护3/4中国企业出海。