在 trivago 后端，我们使用反应式编程模式用于从广告商获取价格并更新我们的缓存。这有助于我们提高后端的响应能力（即可扩展性和弹性）。因此，我们的后端系统可以减轻内部组件和广告商的高响应时间，同时保持响应，即使下游组件完全失败。下面是我们如何使用 Java 库反应堆核心为确保这些保证：
首先，让我们看一下用于获取价格的后端架构是什么样的。trivago 后端由多个微服务以及两个具有不同用途的缓存。中期缓存将广告商的价格存储多个小时（具体取决于广告商的更新政策），以减少广告商的下游负载。短期缓存存储类似搜索的进一步细化价格，以缩短响应时间并减少后端组件的负载。
最近，我们将一个负责为用户选择最佳价格的组件（称为拍卖服务）从后处理转移到反应式价格获取过程（参见上图中的蓝色箭头）。拍卖服务批量处理价格，通过迁移该组件，我们可以优化短期缓存的利用率，以进一步减少其他组件的负载，并通过覆盖更多价格来完善我们的价格选择算法。迁移过程中最具挑战性的部分之一是，需要按照到达顺序处理和返回给定的批次，以确保我们将每个住宿的最新价格存储在短期缓存中。我们通过将拍卖服务完全集成到建立双向流/的反应式管道中解决了这个问题通量每次搜索的价格处理器和拍卖服务之间。通量保证事件的顺序（如果不转换为并行通量）。然而，通过发送大量请求和响应，人们无法在一个操作中访问请求和相应的响应。
反应式编程模式需要链接运营商每个操作者都应该避免副作用。这意味着操作员不应访问另一个操作员的数据。然而，我们需要从请求中获取价格，以丰富响应。该问题的一种解决方案是在响应中提供所有请求数据，但这会增加网络带宽，并且我们希望避免实现定义 API。我们通过将请求通量转换为热门出版商并连接到它两次。一个通量被发送到拍卖服务，另一个通量与拍卖服务的响应压缩在一起。这提供了一个带有请求和响应数据的 POJO（普通旧 Java 对象）（参见上图）。重放操作符确保重放连接到通量之前发出的元素。
private Flux<AuctionResult> callAuctionAndZipRequestsWithResponses(
final Flux<AuctionRequest> auctionRequestFlux) {
final var hotSource: auctionRequestFlux.replay().autoConnect(2);
return Flux.zip(fireRequests(hotSource), hotSource, AuctionResult::new);
}这只是对反应式编程模式以及它如何解决许多有关可靠性和可扩展性的问题的简要介绍，但同时也让您面临以前从未想过的问题。将反应式编程集成到您的架构中需要思维方式转变和入门时间，这对任何企业来说都是真正的成本因素。但是，谨慎使用它的好处是可以使组件保持解耦。
