基于 RabbitMQ 和 Redis,美版“携程”网使用微服务提升搜索扩展性
lastminute.com 的团队将单个服务分解为多个服务,并引入异步集成来重新构建了搜索结果聚合流程。他们的开发人员使用 RabbitMQ 进行消息传递,使用 Redis 存储来自数据供应商的结果。改进后的架构有了更强的可扩展性和可部署性,资源占用率也有所下降。
lastminute.com 平台在平台的旅行解决方案搜索聚合流程中使用的是第三方供应商。过去,他们使用一个称为运输供应商聚合器 (TA) 的单个 Java 组件封装了整个聚合过程。具体来说,该组件在内部生成许多线程来执行对数据供应商系统的 HTTP POST 请求,并随后在可用时收集和处理结果。
初始搜索结果聚合架构(来源:lastminute.com 技术博客)
lastMinute.com 团队发现,之前这个聚合流程架构存在耦合度高、扩展性差、部署复杂、资源利用率高等问题。lastMinute.com 的产品工程师 Giuseppe Pinto 解释了在该架构中观察到的资源利用率挑战:
该系统每天必须处理大约 5000 万个请求 [...],这意味着每秒大约 600 个请求(这里还是按日常流量算出来的数字;但在某些情况下,流量甚至可能会增加一倍)。值得注意的是,每个单独的请求都会生成 N+1 个线程来实现系统的目标。每个线程负责处理来自供应商的完整响应,在某些情况下,一个 HTTP 响应就封装了一个旅行解决方案,大小达到 25 兆字节之多。总之,就线程和内存使用而言,它是高度资源密集型的。
开发人员选择了分解 TA 服务,并将其中的数据提供者集成逻辑移至独立的微服务中,同时让 TA 服务专注于编排和结果聚合工作。新架构引入了 RabbitMQ 作为消息传递服务,它负责将搜索任务分派给数据提供者搜索驱动程序,并将任务完成通知从搜索驱动程序传递回聚合服务。
TA 服务和搜索驱动程序之间的交互采用了远程过程调用(RPC)模式,基于更通用的请求 - 答复模式。该模式需要两个消息队列,第一个用于发送搜索任务请求,包含相关标识符和回复队列的名称;第二队列传送搜索任务完成通知,包含来自搜索任务消息的相关标识符。聚合服务跟踪待处理的搜索任务,并使用相关标识符来匹配分派的搜索任务和接收到的完成通知。
新的搜索结果聚合架构(来源:lastminute.com 技术博客)
在新设计中,搜索驱动程序服务在发送回 TA 服务的通知消息中不包含数据提供商返回的旅行解决方案数据。相反,它们以标准化形式将数据存储在 Redis 缓存中,一旦所有搜索完成通知到达,TA 服务就会从 Redis 获取这些数据。
原文链接:
lastminute.com Improves Search Scalability Using Microservices with RabbitMQ and Redis (https://www.infoq.com/news/2024/01/lastminute-search-rabbitmq-redis/)
声明:本文由 InfoQ 翻译,未经许可禁止转载。
淘宝启动鸿蒙开发,微信会跟进吗?马云抄底阿里;“哄女友挑战”上线即爆火,24 小时用户达 60 万 | Q 资讯
贾扬清新作被某印度创始人内涵借鉴,懒得纠缠:巧了,正准备开源,GitHub 见
微信扫码关注该文公众号作者