具体原理：按照每个GDS服务器稳定性（通过轮休方式，不断Check它们的可用性）和查询性能，我们算出一个合理的权重，给它分配对应的一组虚拟的Node节点，这些Node节点由一个Node池统一管理。这样，不同的GDS系统都抽象成了资源池里面的一组相同的Node节点。
那么它具体如何运转的呢？
当缓存系统相关航班数据过期后，前台搜索告知MQ有实时搜索任务，MQ统一把异步任务交给Router，这个时候Router并不会直接请求GDS数据，而是去找Node池。Node池会动态分配一个Node节点给Router，最后Router查找Node节点映射的GDS，然后去请求数据，最后异步更新对应的缓存数据。通过技术的实现，我们把哪些不稳定的，甚至半瘫痪的GDS充分利用了起来（包含付费的一种黑屏终端，我们把它用成了免费模式，这里用到了某些黑科技，政策原因不方便透露），同时满足了前台上亿次搜索查询！
监控系统
鉴于机票系统的复杂度和大业务量，完备监控是很必要的：
1、整个Qunar系统架构层级复杂，第三方服务调用较多（譬如GDS），早期监控系统基于CACTI+NAGIOS，CACTI有很丰富的DashBoard，可以多维度的展示监控数据。除此以外，公司为了保证核心业务快速响应，埋了很多报警阈值。而且Qunar还有一个NOC小组，是专门24小时处理线上报警：记得当时手机每天会有各种系统上百条的报警短信。
当然，我还是比较淡定了。因为系统太多，报警信息也不尽是系统bug，它可能是某些潜在的问题预警，所以，系统监控非常至关重要。
2、复杂系统来源于复杂的业务，Qunar除了对服务器CPU、内存、IO系统监控以外，远远是不够的。我们更关心，或者说更容易出问题是业务的功能缺陷。所以，为了满足业务需要，我们当时研发了一套业务监控的插件，它的核心原理如下图：
它把监控数据先保存到内存中，内部定时程序每分钟上传数据到监控平台。同时它作为一个Plugin，可以即插即用。接入既有的监控系统，它几乎实时做到监控，设计上也避免了性能问题。后期，产品、运营还基于此系统，做数据分析和预测:比如统计出票正态分布等。因为它支持自定义统计，有很方便DashBoard实时展示。对于整个公司业务是一个很有力的支撑。
到今天，这种设计思路还在很多监控系统上看到相似的影子。
机票销售系统
机票另一个重要系统TTS：TTS(TotalSolution)模式，是去哪儿网自主研发的交易平台，是为航空公司、酒店在线旅游产品销售系统。
TTS有大量商家入驻，商家会批量录入航班价格信息。
为了减少大量商家同时录入海量数据带来的数据库并发读写的问题，我们会依据每个商家规模，通过数据库动态保存服务器IP，灵活的切换服务器达到负载均衡的效果。这里不再细说了。
最后，回顾整个搜索架构的设计，核心思想体现了服务的一种解耦化。设计的系统虽然数量看起来很多，但是我们出发点都是把复杂的业务拆解成简单的单元，让每一个单元专注自己的任务。这样，每个系统的性能调优和扩展性变得容易。同时，服务的解耦使整个系统更好维护，更好支撑了业务。
作者介绍
蒋志伟，前美团、Qunar架构师，先后就职于阿里、Qunar、美团，精通在线旅游、O2O等业务，擅长大型用户的SOA架构设计，在垂直搜索系统领域有丰富的经验，尤其在高并发线上系统方面有深入的理论和实践，目前在pmcaff担任CTO。