Kafka JCA 适配器的设计方法为标准企业 Java 解决方案提供了 JMS 与 Kafka 事件处理平台的"即插即用式"集成。此设计支持将 Kafka 与现有企业应用程序无缝集成，而无需实施补偿逻辑。通过该适配器，应用程序服务器还可以提供企业应用程序所依赖的基础架构和运行时环境，以用于建立Kafka 连接并执行事务管理。
Kafka现在是Apache的开源项目之一，但是最初的研发，是由Linkedin公司开发的，主要是针对于日志收集和消息收集等场景下的分布式消息系统。
随着容器和 Kubernetes 的兴起，微服务逐渐受到很多企业客户的关注。与此同时，微服务之间的通信也成为了企业必要考虑的问题。本文将着重分析 ActiveMQ 和 Kafka 这两款优秀的消息中间件的架构以及在 OpenShift 上的实现。在正式介绍之前，我们先简单介绍服务之间的通信机制。
SpringBoot + RocketMQ 发送与处理消息
消息的发送方式有哪几种？存储消息的可靠性面临哪些挑战？消费消息的确认机制是怎样的？本文通过分析消息流转的整个过程，从消息发送、消息存储和消息消费三个阶段介绍RocketMQ是如何保证消息的可靠性的。
在引入RocketMQ之前，快手已经在大量的使用Kafka了，但并非所有情况下Kafka都是最合适的，比如以下场景：业务希望个别消费失败以后可以重试，并且不堵塞后续其它消息的消费。
可以使用消息队列的场景有很多，常见的有以下几种：1.服务解耦：同步变异步，数据最终一致性；2.削峰限流：类似“三峡大坝”，下游服务方被超过服务能力请求压垮；3.广播订阅：发送方不关心谁订阅这个消息，只管发出来，拓展方便；4.流式数据过滤：消费者通过类似SQL语句来筛选自己感兴趣的数据；5.两阶段消息：通过两阶段消息与本地数据库事务相结合达到简单分布式事务。
消息队列已经逐渐成为企业IT系统内部通信的核心手段。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能，成为异步RPC的主要手段之一。
首先来看 RocketMQ 的第一个特性-事务消息，事务消息是 RocketMQ 与一致性相关的特性，也是 RocketMQ 有别于其他消息队列的最具区分度的特性。
RocketMQ 特性详细列表，消息的发布是指某个生产者向某个topic发送消息；消息的订阅是指某个消费者关注了某个topic中带有某些tag的消息，进而从该topic消费数据。
在构建RESTful数据服务过程中，我们定义了controller、repositories，并用一些注解修饰它们，但是到现在为止我们还没执行过对象的转换——将java实体对象转换成HTTP的数据输出流。Spring Boot底层通过HttpMessageConverters依靠Jackson库将Java实体类输出为JSON格式。当有多个转换器可用时，根据消息对象类型和需要的内容类型选择最适合的转换器使用。
部门的开发同学最近在开发一个活动的过程中，需要关注大量的应用后台逻辑，捕捉各种事件的触发。在设计时打算采用Kafka消息队列进行业务逻辑的解耦，这样活动开发和后台开发同学的工作就分离开了。但是使用的同学不是很熟悉其原理，担心以下几个问题：
Spring Boot + WebSocket 实现实时消息推送，商家的后台管理系统实现新订单提醒推送功能，利用Spring Boot + WebSocket实时消息推送的方式进行实现。
RocketMQ作为业务消息的首选，在消息和流处理领域被广泛应用。而微服务生态Spring框架也是业务开发中最受欢迎的框架，两者的完美契合使得RocketMQ成为Spring Messaging实现中最受欢迎的消息实现。本文展示了5种在Spring生态中文玩转RocketMQ的方式，并描述了每个项目的特点和使用场景。文末可以直达在线体验。
Service Mesh 常常被称为下一代微服务，这一方面揭示了在早期 Mesh 化浪潮中微服务是绝对的主力军，另一方面，微服务的 Mesh 化也相对更加便利，而随着消息队列和一些数据库产品也逐渐走向 Service Mesh，各个产品在这个过程中也会有各自的问题亟需解决，RocketMQ 也没有例外。
关注时代Java
