马蜂窝搜索基于 Golang 并发代理的一次架构升级

本文主要是介绍马蜂窝搜索基于 Golang 并发代理的一次架构升级，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

搜索业务是马蜂窝流量分发的重要入口。很多用户在使用马蜂窝时，都会有目的性地主动搜索与自己旅行需求相关的各种信息，衣食住行，事无巨细，从而做出最符合需求的旅行决策。

因此在马蜂窝，搜索业务交互的下游模块非常多，主要有目的地、POI、热门景点、美食、商场、酒店、问答、攻略、机票火车票等等，通过实时、精准地返回搜索结果，帮助用户做出个性化旅行决策。

面对越来越高的流量，马蜂窝技术团队积极尝试对搜索架构进行优化和升级，来保证搜索业务的稳定和性能。

方案背景

由于历史原因，优化前的搜索服务与下游模块交的互方式主要为调用各下游模块提供的函数，并且采用串行调用。

图 1: 马蜂窝搜索业务架构和技术体系

搜索技术体系

存储——MySQL、Memcache
模块交互——Function Call
检索——Elasticsearch

搜索业务架构

我们将搜索业务抽象为三个功能模块:

1. 决策系统

负责根据用户意图、运营策略、点击日志等数据，结合决策系统相关算法和模型，决策应该展示哪些模块（游记、商品等）及各模块展示顺序。

2. Agent

负责根据决策系统确定要展示的模块，从 Elasticsearch 和业务方获取模块（如游记、商品等）数据。

3. Format

负责根据不同模块的 UI 交互定义格式化数据，补充 UI 交互缺失数据。

串行的函数级调用方式，使之前的搜索服务架构存在一系列问题：

业务间耦合度高。随着交互模块越来越多，导致搜索服务耗时变得很长，平均达到 400-500 ms；
由于与各业务间交互的方式是 Function Call，使上游很难控制下游模块阻塞时间；
下游调用增加响应时间相应呈线性增长，使其很难再叠加新的功能，可扩展性差；
如果下游模块出现故障，会由于接口阻塞引起超时，导致搜索服务整体都受到影响，表现出白页，用户体验严重下降。

图 2:问题分析

因此，我们需要找到一种方式来降低搜索服务对于下游模块的依赖，以及模块间的耦合，从而提升架构的整体可用性和性能。

基于 Golang 的并发代理实现

经过调研，我们开发了基于 Golang 协程实现的并发请求代理工具，将之前函数级调用的方式变为基于 TCP/IP 的 HTTP 接口调用来与下游模块解耦，同时将串行调用变为并发，实现超时控制和异常容错处理。

主要技术选型——协程(Goroutine)

Goroutine 是 Golang 轻量级线程实现，由 Go runtime 管理。它是 Go 并行设计的核心，也是 Golang 最重要的特性之一，相比于进程、线程任务的抢占式调度，需要频繁进行上下文信息的内核和用户空间切换，Goroutine 可以由程序控制，使得它更易用、更高效、更轻便。

Goroutine 维护了一组数据结构和多个线程，任务放在一个待执行队列中，由 Goroutine 维护的线程来拉取执行。当任务执行了操作系统的 IO 操作等需要等待时，Goroutine 利用 Linux IO 多路复用技术 (Epoll、Select) 进行执行队列的任务切换来实现并发。

相比于其他语言的线程，其默认占用内存为 2KB, 远小于其他语言的 M 级别。在性能开销方面，由于任务调度基本有程序控制，开销也远小于线程。

选型的过程中，我们对比了 PHP 的 Swoole、Java 多线程并行处理方案，它们的 CPU 和内存消耗比 Golang 的 Goroutine 要高出很多，并且并行请求数量会受到资源的限制，在高并发的情况下如果控制不当会导致服务崩溃。而使用 Goroutine 实现的并发代理，可以轻松支持千万级别的并发请求。