反应式系统应该是有弹性，实现这一目标的一种方法是让我们的应用程序彼此相邻地多次部署，如果一个实例出现故障，将会有其他实例负责其任务，从而为系统增加了更多的弹性。如果需要更多处理能力，可以临时调整更多实例，以处理额外的工作量，从而为我们的系统增加弹性。
如今，创建这种架构最流行的方法之一是构建微服务。我们整个系统的代码不再驻留在一个单独的应用程序中，而是将它们分成自然和事务边界上的较小应用程序。这使我们能够根据当前要求部署相同微服务的多个实例。如果我们的营销微服务负载很重，而我们的帐户微服务几乎是空闲运行，我们可以运行更多营销微服务，同时减少帐户微服务实例的数量。
微服务架构中的通信
当然，这些微服务需要一种相互通信的方式。反应宣言表明可以使用异步消息来做到这一点。使用异步消息，我们可以确保当微服务发生故障时消息不会丢失。它还使我们能够在相同类型的多个微服务之间分配工作或事件以实现弹性。
显然，这需要我们系统中的某种组件来处理这种消息传递概念。这称为消息代理。这个经纪人对我们来说就像某种“邮政服务”。它将在我们的微服务生态系统中接收和分发消息，并像消息主干一样行动。我们将在这里研究的消息代理是Apache Kafka。
介绍Apache Kafka
Apache Kafka是一个众所周知的分布式流媒体平台。它旨在实现线性可扩展，容错并支持低延迟，高吞吐量的消息传递。Kafka用于构建实时数据管道和流应用程序。这意味着它可以在事件和数据分布，最终一致性方面提供很多微服务架构，并且可以构成这些微服务所构建的平台。
在反应系统中，每个组件都应具有弹性和弹性。消息系统当然也不应该是这个规则的例外。
Kafka使用可以放置消息的主题Topic，例如可以发送未经证实的事务的主题“未确认的事务”。然后，应用它们的应用程序可以读取这些未经证实的事务。这些主题每个都有许多分区，在主题中有一个细分。
新消息只会追加到分区的日志末端，永远不会更新原来消息。我们可以将Kafka配置为保存这些消息很长时间 。
在Kafka中，消费者被细分为消费者组（通常我们为每个不同的微服务使用一个消费者组）。主题中的每个分区可以被一个消费者访问，这意味着我们在一个分区内能获得消息有序的处理保证。如果我们想要为主题添加更多的消费者，我们只要添加额外的分区即可。
Kafka通过集群实现了伸缩性和弹性。不同的分区可以分布在集群的不同实例上。这意味着主题数量可以以线性方式增长。
Kafka提供了许多API来帮助我们构建将其用作消息传递主干的应用程序。
- 通用Producer和Consumer API，它使应用程序能够通过Kafka主题发布和使用消息。
- 连接器API，可通过拉动和推送机制将数据存储系统链接到Kafka集群，例如，为数据库提供数据。
- Kafka Streams API支持构建转换和分析贯穿Kafka的实时流的应用程序。
- 还有Reactor Kafka库，它可以将Kafka与Project Reactor集成在一起。这意味着我们可以在Kafka主题中运行实时事件流，以在我们的应用程序中用作Reactive Streams。
- Spring Boot和Spring Cloud Stream有专门简化使用方式。