Open upan opened 4 years ago
去哪儿机票搜索架构实践(一) 整体架构 https://www.sohu.com/a/206825911_505779
朱仕智，去哪儿网高级架构师，国际机票技术总监。90后，2013年加入去哪儿，先后参与过公共业务、国际机票搜索系统的研发。围绕高可用、高性能、大数据量、高扩展构建了支持业务快速发展的实时搜索报价系统，在系统和程序设计方面积累了较多经验。
用户诉求和挑战 用户的诉求
对于使用 Qunar 平台的用户来说，诉求其实很简单，就是能很愉快的买到价格低的飞机票，主要包含几个方面：
报价全：航线、航班的覆盖要足够全，所想即可得 价格低：价格要有优势，不能薅用户血汗钱 价格准：实时性好，可预订 产品多：满足多样化差异化需求，商旅用户和低价敏感用户的目标是不一样的
面临的挑战
用户诉求虽然简单，但是从构建系统角度去看就不简单了，机票报价搜索不同于其他搜索，更像是一个实时计算系统。航司运价规则、代理商调价规则、库存信息都在频繁变更，海量的数据变动让报价计算复杂度急剧上升，更恐怖的是其中一些基础资源没有掌握在 Qunar 平台内，而是在 GDS （全球分销系统）手里，需要支付一定的费用才能获取。
一个机票价格到底是怎么产生的呢？航空公司购买飞机用于某个航线的飞行后，会对这个航线制定运价；然后把运价和仓位库存信息发布到 GDS 中。最后航空公司会找代理商帮它买票，给予代理商一定的优惠。
所以一个最基本的机票销售报价产生需要几个步骤：航司制定运价+库存情况+分销代理商调整价格。
然后再组合必要的相关信息，如退改签、税费、过境签信息等；最后还会基于机票报价的基础上，搭售各种附加产品，比如 WIFI、值机服务等。
可以看出整个报价计算链路是比较长的，各个环节的数据变更比较频繁，而且量也都比较大。具体有多大呢？来看看几个直观的数据：
系统架构
在这样的背景下，就需要我们对系统做一定的设计来满足海量的数据计算。
系统设计考虑
主要有两种思路：全量预计算和按需实时计算，各有优劣。
全量预计算：在用户搜索之前，就把所有的报价提前计算好，然后感知所有影响报价的变更，一旦发现变更，重新计算对应的报价。所以这种方式的响应速度和报价准确性较好。但是需要消耗的资源量非常大。而且在变更频繁的场景下，需要重复计算的量也非常大。
按需实时算：用户搜索触发计算，而且配合报价结果的缓存，可以进一步减少计算量。所以这种方式对资源要求很低，而且扩展性较好。但是由于实时计算所以响应速度很慢一些，而且缓存也一定程度的影响了报价的有效性。
最后基于资源和扩展性考虑，只能选择按需实时计算，然后再想其他的方案来优化响应速度和准确性。
系统结构
基于前面的问题和考量点，我们设计了一套搜索系统，实时地计算报价，配合报价结果缓存，并且对缓存数据进行闭环刷新，如下图：
可以看到整套系统是水平分层的，垂直上是按照报价引擎划分的。分层在计算机领域里面是复杂问题简单化的一个行之有效的经验，使得我们可以针对每一层做特殊的处理和优化。
最上层是各种终端渠道，APP、WWW、低价等，都会使用到报价搜索的能力。
然后是报价聚合层，聚合层有维护一个报价结果的全局缓存，并且使用 cache manager 对这些缓存进行管理，所有影响报价的变更，都收拢到这个系统内。报出缓存报价之前，都会检查其有效性。
再往下是报价的计算引擎层，聚合层和引擎层之间采用了消息驱动的交互方式，redis 作为数据交换区，这样可以比较好的解耦系统之间的依赖，新增或减少报价引擎，都不会对聚合层产生影响。
报价引擎层内，会细分为两个小层，一层是更宽泛的非绝对意义的机票业务，如航路规划、产品包装、大交通等。另一层则是基础机票报价计算，有 TTS、旗舰店、抓取等多个渠道，各个渠道的报价引擎之间是并行计算的，并形成互补优势。
最底层是基础数据层，有运价、调价规则、航班数据等数据。其中部分是数据存储查询服务、部分则是实时计算；比如运价，就是实时计算而不是提前算好上亿个运价数据。
需要特别说明的是，MQ+redis 的交互方式，除了可以解耦之外，其实也节省了大量的网络流量。其实我们分析报价的计算过程，可以发现它其实是一个单向的计算流，航路规划 -> 运价计算 -> 匹配调节规则、库存等 -> 包装、大交通等业务。但是一般的分层系统是树状结构，下层的计算结果需要回溯到上层。而通过 MQ，可以把这个过程展开，不需要一层层的回调，只在最后结果时通知到聚合层就可以。并且其他系统也可以监听这个结果消息来收取报价结果。
在下一篇中，我们将详细的分析一个报价引擎的设计和优化过程，敬请期待。
去哪儿机票搜索架构实践(一) 整体架构 https://www.sohu.com/a/206825911_505779
朱仕智，去哪儿网高级架构师，国际机票技术总监。90后，2013年加入去哪儿，先后参与过公共业务、国际机票搜索系统的研发。围绕高可用、高性能、大数据量、高扩展构建了支持业务快速发展的实时搜索报价系统，在系统和程序设计方面积累了较多经验。
用户诉求和挑战 用户的诉求
对于使用 Qunar 平台的用户来说，诉求其实很简单，就是能很愉快的买到价格低的飞机票，主要包含几个方面：
面临的挑战
用户诉求虽然简单，但是从构建系统角度去看就不简单了，机票报价搜索不同于其他搜索，更像是一个实时计算系统。航司运价规则、代理商调价规则、库存信息都在频繁变更，海量的数据变动让报价计算复杂度急剧上升，更恐怖的是其中一些基础资源没有掌握在 Qunar 平台内，而是在 GDS （全球分销系统）手里，需要支付一定的费用才能获取。
一个机票价格到底是怎么产生的呢？航空公司购买飞机用于某个航线的飞行后，会对这个航线制定运价；然后把运价和仓位库存信息发布到 GDS 中。最后航空公司会找代理商帮它买票，给予代理商一定的优惠。
所以一个最基本的机票销售报价产生需要几个步骤：航司制定运价+库存情况+分销代理商调整价格。
然后再组合必要的相关信息，如退改签、税费、过境签信息等；最后还会基于机票报价的基础上，搭售各种附加产品，比如 WIFI、值机服务等。
可以看出整个报价计算链路是比较长的，各个环节的数据变更比较频繁，而且量也都比较大。具体有多大呢？来看看几个直观的数据：
系统架构
在这样的背景下，就需要我们对系统做一定的设计来满足海量的数据计算。
系统设计考虑
主要有两种思路：全量预计算和按需实时计算，各有优劣。
全量预计算：在用户搜索之前，就把所有的报价提前计算好，然后感知所有影响报价的变更，一旦发现变更，重新计算对应的报价。所以这种方式的响应速度和报价准确性较好。但是需要消耗的资源量非常大。而且在变更频繁的场景下，需要重复计算的量也非常大。
按需实时算：用户搜索触发计算，而且配合报价结果的缓存，可以进一步减少计算量。所以这种方式对资源要求很低，而且扩展性较好。但是由于实时计算所以响应速度很慢一些，而且缓存也一定程度的影响了报价的有效性。
最后基于资源和扩展性考虑，只能选择按需实时计算，然后再想其他的方案来优化响应速度和准确性。
系统结构
基于前面的问题和考量点，我们设计了一套搜索系统，实时地计算报价，配合报价结果缓存，并且对缓存数据进行闭环刷新，如下图：
可以看到整套系统是水平分层的，垂直上是按照报价引擎划分的。分层在计算机领域里面是复杂问题简单化的一个行之有效的经验，使得我们可以针对每一层做特殊的处理和优化。
最上层是各种终端渠道，APP、WWW、低价等，都会使用到报价搜索的能力。
然后是报价聚合层，聚合层有维护一个报价结果的全局缓存，并且使用 cache manager 对这些缓存进行管理，所有影响报价的变更，都收拢到这个系统内。报出缓存报价之前，都会检查其有效性。
再往下是报价的计算引擎层，聚合层和引擎层之间采用了消息驱动的交互方式，redis 作为数据交换区，这样可以比较好的解耦系统之间的依赖，新增或减少报价引擎，都不会对聚合层产生影响。
报价引擎层内，会细分为两个小层，一层是更宽泛的非绝对意义的机票业务，如航路规划、产品包装、大交通等。另一层则是基础机票报价计算，有 TTS、旗舰店、抓取等多个渠道，各个渠道的报价引擎之间是并行计算的，并形成互补优势。
最底层是基础数据层，有运价、调价规则、航班数据等数据。其中部分是数据存储查询服务、部分则是实时计算；比如运价，就是实时计算而不是提前算好上亿个运价数据。
需要特别说明的是，MQ+redis 的交互方式，除了可以解耦之外，其实也节省了大量的网络流量。其实我们分析报价的计算过程，可以发现它其实是一个单向的计算流，航路规划 -> 运价计算 -> 匹配调节规则、库存等 -> 包装、大交通等业务。但是一般的分层系统是树状结构，下层的计算结果需要回溯到上层。而通过 MQ，可以把这个过程展开，不需要一层层的回调，只在最后结果时通知到聚合层就可以。并且其他系统也可以监听这个结果消息来收取报价结果。
在下一篇中，我们将详细的分析一个报价引擎的设计和优化过程，敬请期待。