从服务化推进、南北京机房之痛、性能提升实践、App客户端技术演四个方面来讲途牛服务器部署及架构演进

　　途牛从一开始的单机系统开发到现在有数百个分布式系统。本文主要与大家分享途牛网站无线系统在从小到大过程中遇到的问题和解决方案，希望能给大家带来一些参考。本文将从服务推广、南北京机房痛苦、性能提升实践、App客户端技术演进四个方面进行介绍。　　服务化推进　　途牛的服务始于2011年。当时途牛主要服务会员，2012年搜索2.0服务。2013年是服务大进步的时刻，主要搜索3.0、2014年，TSP(途牛服务治理平台)将服务于价格中心、订单中心、产品基础数据等系统。、服务于业务公共系统和资源搜索系统，服务于2015年的生产类别和开放API。　　从以上过程可以看出，途牛的服务不是一蹴而就的，而是经历了一个漫长的过程。每次拆分都相当于为高速汽车更换轮胎的过程。　　从以上过程可以看出，途牛的服务不是一蹴而就的，而是经历了一个漫长的过程，每一次拆分都相当于为高速汽车更换轮胎的过程。可以注意到，2012年途牛拆分搜索2.0，2013年迅速推出搜索3.0。　　两个版本的区别是：搜索2.0一开始没有经验，虽然使用非常成熟的开源搜索引擎建立搜索平台，但没有明确定义搜索平台和业务系统之间的关系，导致搜索平台逻辑非常重，作为数据聚合平台，网站列表页面数据和详细页面数据从搜索，导致搜索数据源部分的逻辑非常复杂，搜索开发人员花70%的时间处理与业务系统对接的逻辑，索引效率相对较低，导致性能不稳定，逐渐退休。吸取教训后，途牛建立了搜索3.0平台，只提供列表搜索、统一列表字段、数据推送逻辑到外部搜索，由各产品系统数据推送，搜索本身专注于性能改进和稳定性，并逐步增加智能排名、人工干预搜索结果功能。经过教训，途牛建立了搜索3.0平台，只提供列表搜索、统一列表字段、数据推送逻辑到外部搜索，由各产品系统数据推送，搜索本身专注于性能改进和稳定性，并逐步增加智能排名、人工干预搜索结果功能。到目前为止，搜索3.0是途牛最稳定的系统。　　下一步是在服务化过程中，在技术层面上做得更好的两项服务：价格计算服务和服务治理平台。　　价格计算服务　　从技术上讲，价格计算服务有两个困难：一是团期价格依赖因素多，依赖路径深；二是价格变化频率高，尤其是旺季。因此，在设计上，价格计算服务必须具有较大的容量要求和实时性。　　价格计算服务从13年开始建设，架构也经历了四个阶段:同步架构、异步架构、并发架构和分布式架构，如下图所示。　　同步架构：系统之间主要通过接口进行交互，其他系统通过呼叫接口通知价格中心，价格中心通过接口获取所有其他系统所依赖的价格资源。整个计算过程采用串行模型行，效率低，只能满足小规模计算的需要。　　异步架构：系统通过MQ交互，价格中心依靠数据库获取其他系统的数据，加快数据读取效率，将计算价格转换为两个部分：首先计算资源的最低成本价格，然后计算产品的最低价格。该架构比同步架构数据读取更有效，可以提前生成数据，加快计算速度，提高整体性能的三倍。　　并发架构：首先对价格库本身的数据（资源成本价格、产品集团起价）进行分库表，提高系统的数据容量，然后根据产品访问频率区分冷热数据的计算频率，降低冷数据的计算频率，增加热数据的计算频率，通过在内存中建立集团期、行程和资源的数据结构，提高计算过程中数据的读写效率。整体性能是异步架构的3.5倍，每个团期的价格计算时间控制在200ms以下。　　分布式架构：通过分析依赖数据库的Binlog，将依赖数据库的数据转换为合适的内存数据库结构，进一步提高数据读取效率，解决过度依赖数据库的计算问题，利用ShardingMQ实现本地访问和计算；利用Unix域通信机制实现本地通信，尽量将每个计算实例所依赖的资源和通信限制在本地服务器上，最大限度地提高I/O能力，减少I/O损耗。整体性能是并发架构的两倍，每组价格计算时间控制在100ms以下。整体性能是并发架构的两倍，每组价格计算时间控制在100ms以下。　　通过上述阶段的优化，价格计算服务的整体结构如下图所示。分发节点中的计算成本节点是一些预处理节点，主要计算资源成本价格，物理机中的计算节点是实际执行价格计算的单元节点。通过一定的路由规则，调度节点将价格计算分成不同的机器。当Binlog同步时，数据将按照类似的规则同步到不同的存储节点物理机器，从而实现本地存储和本地计算。　　截至2015年5月，价格计算服务的日计算量约为9亿次，每组平均每天计算两次以上。在I/O能力和计算效率方面，价格计算服务一直在不断迭代和提高，预计未来会有更好的架构。　　服务治理平台　　随着服务的深入，各系统提供了越来越多的接口，整个系统逐渐出现了网络接口呼叫、循环依赖、雪崩效应、缺乏监控、硬件负载平衡、维护差等问题。为了解决这些问题，途牛迫切需要一个服务治理平台来管理所有的服务。　　途牛以开源服务治理平台为基础，部分定制，很快搭建了适合途牛的服务治理平台，结构如下图所示。其中，注册中心采用主从模式进行集群部署，“主”改变服务地址，保持心跳，“从”提供查询服务。建立主从之间的长连接，保持心跳。“主”停机后，“从”接替，变更自己的身份标志。只有获得“主”身份，注册中心各部署的实例才能接受客户端长的连接请求。各服务提供商、服务消费者感知“主”停机，尝试连接“从”，建立长连接，使用SQLite数据库持久服务列表，使用高可用内存缓存保存可用服务地址列表，与服务提供商、服务消费者建立长连接，保持心跳。　　服务提供商启动后，通过通用组件将提供的服务告知注册中心，注册中心更新可用服务地址列表。若该服务无审核记录，则作为新服务待审核。新服务提交注册中心后，注册中心不会更新到可用服务列表，只有在管理页面手动审核通过后才能进入使用，被服务消费者感知。　　注册中心将更新可用服务地址列表，删除提供商的所有服务，并发出变更通知。心跳有重连保持机制。在断开连接之前，一定时间内没有心跳。服务提供商使用连接池来控制长连接的数量，并设置最高连接数。如果连接数最高限制，则拒绝新的连接接入，以确保当前系统的可用性。　　在管理页面上，您可以查询服务、服务细节和可用服务地址列表，查看服务消费者列表，审查新的在线服务，禁止离线服务，实时调整服务负载平衡策略，减少、倍增、禁止和允许服务提供商的操作。　　南北机房之痛　　本节主要介绍途牛的机房部署策略。2014年以前，途牛基本保持了南北京机房的结构。当时这个策略基本合理。但是随着应用量的增加，问题逐渐出现，途牛成为2015年南京单机房的战略。未来途牛将向两地三中心这种更稳定、更可用的结构演变。　　在设计之初，南北京单机房的战略很好地满足了业务需求。2010年以前，途牛70%以上的订单都是电话订单，旅游订单的预订流程比较复杂，需要客服人工参与的环节很多。途牛需要在南京机房部署订单系统，为途牛的客服提供良好的用户体验。同时，为了为互联网用户提供更好的机房条件，途牛需要在北京部署网站。途牛在这种机房架构下进行了大量的系统优化，主要是为了解决异地机房之间的数据同步问题。　　首先，根据网站数据“读多写少”的特点，途牛对每个子系统采用以下典型系统设计，如图4所示。南京和北京之间的数据同步是通过数据库的主同步机制进行的。北京机房的应用程序读取北京的数据库，并通过专线写入南京的数据库，以确保两侧数据的一致性。　　当系统容量小时，设计方案可以很好地运行，但当专线不稳定时，会出现更多的问题。最常见的是数据同步延迟。例如，用户在网站注册后不能立即登录。针对这个问题，途牛采用了保险丝的设计方案，并使用特定的过程监控数据库同步延迟。如果延迟达到上限，尝试使用公共网络VPN进行同步，然后在专线情况改善时切换。　　此外，为了控制数据同步的数据量，所有数据同步都采用压缩机制，以最大限度地减少同步数据量。与此同时，途牛也在扩大专线容量。　　随着业务的不断增长和同步数据的增加，这种部署架构面临着越来越大的挑战。最后，途牛在2015年初合并了两个机房。中途最大的挑战是南京机房的网络条件。当时，南京没有具有良好接入条件的多线BPG机房。为了为全国用户提供更好的网络服务，途牛最终采用了动态CDN方案，南京机房出口仅提供电信出口IP。通过动态域名分析，对联通和移动用户进行分析，然后通过中转服务器优化访问南京的电信线路。该方案可为全国用户提供良好的网络服务。　　途牛至少降低了整个服务器部署成本的30%。一是避免在南京和北京部署两个相同的系统，二是节省了大量的专线成本。　　目前的单机房战略是一种过渡方案。为了保证系统的进一步高可用性和数据的安全性，途牛将在后期向标准的两地三中心机房部署战略迈进。　　性能优化　　性能优化主要介绍了途牛在优化过程中总结的几种工具。途牛的想法是：首先，不断推进结构演变，系统划分，提前扩大资源，确保整体承载能力。然后，不断完善监控，具体化性能指标，发现问题，解决问题，确保整体稳定性。这三种工具主要由这三种工具实现：CODIS、BWT、OSS。　　Codis是利用Go和C语言开发豌豆荚的Redis分布式集群解决方案，与Twemproxy完全兼容。Codis底层将处理转发请求、不停机数据迁移等工作。对于客户端来说，所有的底层处理都是透明的。简而言之，可以简单地认为背景连接是一个内存无限的Redis服务。从无缓存到文件缓存，再到Memcache缓存，再到今天的Codis缓存，缓存是大架构的必然。　　使用Codis后，应用程序不需要关心缓存的具体存储，缓存扩展和数据迁移，缓存数据的一致性，大大提高了应用程序开发和维护的效率。　　BWT是途牛自主开发的主动缓存更新服务。为了进一步提高页面的生成效率，当应用程序系统发生数据变更时，将更新的数据请求发送到BWT。BWT根据设置的更新策略更新缓存。应用程序系统推送的数据通常会延迟3分钟进行更新。同时，BWT也会根据设定的时间自动更新日志分析的热点数据。在更新过程中，如果目标机器负载较高，则会自动停止更新。　　OSS也是途牛自主开发的网站运营监控系统，其初始目标是监控和管理网站的性能、可用性和安全性。后期将独立成为一个单独的运行监控系统，为所有系统提供监控服务。图5是OSS的系统结构。　其主要特点是使用UPD将日志从应用系统中发送出来，尽量减少发送日志对应用系统的性能消耗。通过NSQ队列接收日志，用Go语言编写的消费过程汇总日志，存储在DB中，最后通过页面呈现各种统计报表。　　通过错误和性能图表，可以快速发现网站的各种故障。主要依靠接口监控、SQL监控、Memcache监控、Redis监控和单页性能监控。　　App客户端技术演进　　这里主要介绍途牛app在开发过程中的实践经验，重点介绍线热补丁和前端资源静态化。　　1.在线热补丁　　由于App采用客户端发布的方案，一旦发布的包裹有bug，修复就是一个非常头疼的问题。传统的修复方法主要包括:服务器端屏蔽技术，即暂时屏蔽有问题的功能；跳转H5页面，直接将有问题的页面跳转到相应的H5页面；紧急发布新版。这些方法都有一定的局限性。对于服务器屏蔽技术，服务器代码的复杂性会增加，局部功能会隐藏；跳转到H5会降低用户体验；紧急发布新版本会增加运营成本，降低用户体验。　　为此，途牛引进了阿里的在线热补丁技术，以便在问题发生时能够快速发布补丁包来解决问题。　　二、前端资源静态化　　由于H5开发周期短，易于部署，途牛app中有大量H5页面，但对于H5页面，用户体验的损失也很明显。为了更快地渲染页面中的元素并呈现给用户，途牛采用了前端资源的静态解决方案。主要思路是提前加载H5页面中的静态资源，重点如下：　　静态资源异步加载，用户打开App时异步下载或更新静态文件。优化渲染，减少不必要的开支。通过优化DO