实例分析途牛网站的无线架构变迁实践之路

途牛从一开始的单机系统，发展到现在已拥有数百个分布式部署的系统。本文主要将途牛网站无线系统在从小到大的过程中，遇到的问题以及解决方法与大家分享，希望为大家带来一定借鉴。文章将从服务化推进、南北京机房之痛、性能提升实践、App客户端技术演进四个方面进行介绍。
　　服务化推进
　　途牛的服务化始于2011年，当时我们主要进行了会员的服务化，2012年进行了搜索2.0的服务化，2013年是服务化大举前进的时刻，主要进行了搜索3.0、价格中心、订单中心、产品基础数据等系统的服务化，2014年将TSP（途牛服务治理平台）、业务公共系统、资源搜索系统等进行服务化，2015年对产类目、开放API进行服务化。
　　从上面的过程可以看出，我们的服务化不是一蹴而就的，而是经历了一个漫长的过程，每一次拆分都相当于为高速行驶的汽车更换轮胎的过程。可以注意到，在2012年我们拆分了一个搜索2.0，之后很快又在2013年推出了搜索3.0。
　　这两个版本的区别是：做搜索2.0一开始没有什么经验，虽然采用了Solr这样非常成熟的开源搜索引擎来搭建搜索平台，但是没有明确界定搜索平台和业务系统之间的关系，导致搜索平台的逻辑非常重，被当成一个数据聚合的平台来使用，网站列表页数据和详情页数据都从搜索中出来，导致搜索获取数据源部分的逻辑非常复杂，搜索开发人员将70%的时间都放在和业务系统对接逻辑的处理上，索引效率也比较低，从而导致性能不稳定，逐渐退役。吸取教训后，我们搭建了搜索3.0的平台，仅仅提供列表搜索，统一列表字段，将数据推送逻辑移到搜索外部，由各个产品系统来进行数据推送，搜索本身专注于性能的提升与稳定性，并逐步加入智能排序、人工干预搜索结果功能。迄今为止，搜索3.0是我们公司最为稳定的系统。
　　接下来是服务化过程中，技术层面做得比较好的两个服务：价格计算服务和服务治理平台。
　　价格计算服务
　　从技术上，价格计算服务有两个难点：一个是团期价格依赖的因素较多，并且依赖路径较深；另一个是这些因素价格变动的频率较高，尤其在旺季。因此从设计上，价格计算服务必须要有较大的容量要求，同时具有实时性。
　　价格计算服务从13年开始构建，架构上也经历了四个阶段：同步架构、异步架构、并发架构和分布式架构，如图1所示。
　　
　　图1 服务化的推荐 - 价格计算服务
　　同步架构：系统间主要通过接口进行交互，其他系统通过调用接口通知价格中心发起运算，价格中心通过接口获取其他系统价格依赖的所有资源。整个计算流程采用串行模型行，效率低仅能满足小规模的计算需求。
　　异步架构：系统间通过MQ进行交互，价格中心通过依赖数据库获取其他系统的数据，加快了数据读取的效率，并将计算价格变成两段：先针对一个资源多个供应商的情况，将资源的最低成本价计算好，然后再算产品最低价。这种架构比同步架构数据读取的效率更高，并能通过预先生成数据，加快计算的速度，提升3倍整体性能。
　　并发架构：首先将价库自身的数据（资源的成本价，产品团期起价）进行了分库分表，提升了系统的数据容量，然后再根据产品的访问频度区分冷热数据的计算频率，冷数据降低计算频率，热数据增加计算频率——并通过在内存中建立团期、行程、资源这三个维度的数据结构，提升计算过程中数据的读写效率。整体上性能比异步架构提升了3.5倍，每次每个团期的价格计算时间控制在200ms以下。
　　分布式架构：通过解析依赖数据库的Binlog，将依赖数据库的数据转换成适合使用的内存数据库结构，进一步提升数据读取效率，从而解决计算过度依赖数据库的问题，通过使用Sharding MQ，实现本地访问、本地计算；通过使用Unix域通信的机制，实现本地通信，将每个计算实例所依赖的资源和通信尽量限制在本地服务器上，最大化提升I/O能力，降低I/O损耗。整体性能比并发架构提升2倍，每次每个团期的价格计算时间控制在100ms以下。