梦想旅行:高速海外访问与高可用&容灾架构的最佳实践

  1. 云栖社区>
  2. 博客>
  3. 正文

梦想旅行:高速海外访问与高可用&容灾架构的最佳实践

梦想智联 发布时间:2017-02-26 18:05:56 浏览1803 评论0

摘要: 梦想旅行主要是服务于出境自由行的用户,为用户实时体统餐饮、酒店预订、景点查询等基于LBS的服务,用几个词简单概括就是:出国、哪吃、哪玩、哪优惠。我们主要做了这三个方面的事情:全球旅游数据整合与结构化;知识图谱构建和知识实体的挖掘;智能旅行。

本文正在参加“最佳上云实践”评选,来给我们投票吧:https://yq.aliyun.com/activity/158(编号17)

梦想旅行主要是服务于出境自由行的用户,为用户实时体统餐饮、酒店预订、景点查询等基于LBS的服务,用几个词简单概括就是:出国、哪吃、哪玩、哪优惠。

一般出境游的朋友会查攻略、求达人、看路书。在国内可以搜索附近获得旅游信息,而在国外却面临信息不对称的窘境,导致出境游需要非常繁杂的准备工作。

梦想旅行正是为了解决这些问题而生,我们主要做了这三个方面的事情:

  • 全球旅游数据整合与结构化;
  • 知识图谱构建和知识实体的挖掘;
  • 智能旅行。

其中全球旅游数据的整合与结构化是梦想旅行的基础,通过获取海量的异构旅游数据,进行清洗、整合,形成丰富、完善的旅游知识体系,帮助出境游用户更简单的游玩。

梦想旅行的数据概况

梦想旅行爬取并收录全球旅游相关网页超过20亿+,实现全球多地爬取传输存储,存储200个以上的历史版本,实现对原始网页内容的变化的跟踪,热点页面更新时间低于30分钟,自学习智能调度算法、热点和冷门数据的平衡更新,智能嗅探各种旅游的数据来源、模板自动解析与匹配。

这个量级虽然对于大公司来说并不是多大的数字,但对于小微型企业,如何在有限的资源的情况下,支持快速、跨区、可扩展的分布式爬虫系统,就是一个非常值得研究的问题。

这部分也有梦想旅行的一点独特之处,就是异地的爬取,异地爬取并不是为了容灾,而是因为很多有用的网站,尤其是社交类网站,在国内是无法访问的。例如Facebook,该平台除了社交用户外,还有大量的商家自己维护的相关信息,如地点、营业时间、优惠情况,甚至是其他用户对商家的咨询和评价,这些内容可能对行前和行中用户非常有价值。我们目前采用的多地爬取的方式实现,其实中间也引入过VPN进行爬取,但问题是网络带宽首先变成了最大瓶颈,同是防火墙检测速度非常快,一旦流量异常,很快VPN可能就无法使用。

分布式爬虫架构

172b0abbc1dcdd93e1a6bb95346d374af9f5e73d

在整体架构上,我们采用ESC组成Crawler集群,重点网站每个网站都有自己的代理池,原因是针对于A网站封掉的IP,针对B网站是可用的。引入JS渲染引擎,是因为很多的网站核心数据是由Ajax异步填入的,所以通过渲染引擎就可以拿到这些核心数据。

我们的杭州和北美集群都有自己的消息集群,爬取页面后,会写入相应的消息集群,ETS通过抽取、转换并对两个消息集群的数据进行处理和存储,放入网页库和链接库。这里需要说的是,WDB采用OSS实现,这个设计非常实用,因为OSS对于存储小文件十分方便,第一,没有文件数目的上限限制,第二,存储总大小也没有限制,第三,单个文件大小没有限制。由于以上三点,我们用OSS为每个网页存储了200+的历史状态,便于对网页数据历史状态进行快速跟踪。

LinkDB的设计采用MongoDB实现,在url小于3亿之前,我们一直采用MySQL来存储,也比较方便,数据量超过3亿以后,我们采用MongoDB作为LinkDB,非常方便链接库的扩展,能够支持更高量级的网页爬取。

通过智能调度,系统对网页按照网站、网页权重,更新频率,更新时间等对网页进行权重动态调整,让热门网页爬取的更快,并平衡热门和冷门url的爬取速度。爬取队列采用常用的Redis,能够动态的调权。

数据整合和知识发现

在数据爬取完成之后,如何处理爬取来的基础数据,又有困难需要克服。下面4点就是我们在算法层面上面临的艰难挑战:

  • 海量来源,页面结构差异大,语种多,如何有效获取页面内容?
  • 各个来源信息质量参差不齐,如何做好异构数据选取与合并?
  • 旅游信息包罗万象,如何提取有效实体,构建知识图谱?
  • 如何将知识图谱应用实际场景,切实帮助用户完成智能旅游?

c845a54bd1e745060e60f376d47be12de433bba9

梦想旅行的基础数据大都存储在OSS和RDS上,主要是因为E-MapReduce和ODPS对两者都能够支持,可以进行快速的数据计算。

计算层面,在E-MapReduce和ODPS没有大规模采用之前,曾经自己做过一段MPI,后来因为复杂度较高,并且E-MapReduce和ODPS功能更加完善,很快的迁移到两个计算平台。这点需要说明,我们为什么需要两个大数据处理平台支持,由于之前获取的原始页面非常多,数据处理逻辑复杂,经常需要对数据做大规模的修正和处理,因此必须能够加速数据处理速度,刚好这时候阿里云的两个计算平台都能够使用,帮我们更加关心业务的实现,快速的进行业务迭代。

值得一提的是,因为数加平台的逐步完善,很多实用的功能的开放,也大大加快了业务上的进度,例如数加平台的一些实用功能,人脸识别、电商图片、机器翻译等,还有和E-MR和ODPS上的机器学习算法,都大大简化了算法团队的开发难度,更加关心业务指标,而不是忙着搭建平台和算法模型。

通过主题模型、实体发现等基础模块,通过各种算法,对异构数据进行处理合并,形成旅游实体和知识图谱。

梦想旅行使用场景

梦想旅行的使用场景也和其他公司有着比较明显的不同,这些不同主要是由于针对的用户不同导致的。最显著的特点是:

  • 50%的访问来自于海外各地,要求海外图片能够快速上传和被访问
  • 基于LBS即时个性化检索,要求系统高可用以及异地容灾

海外访问的提速

因为App一般是针对一个地区的服务,大到一个国家,小到一个城市,如果是针对全球的服务,经常是数据相对分离的。而梦想旅行的场景是,旅游用户在全球各地,并没有明显的针对性。

这就要求海外图片能够快速上传和访问。很多的同类企业,为了保证访问速度,采用CDN的形式对API做缓存,这就导致大家在海外看到的数据基本是一致的。

旅行的用户多数喜欢自拍和分享,海外的图片上传远比国内的情况要多很多,但是一旦网络访问需要跨国内国外,这个时候就必须经过一座独木桥——海外出口。这条线路因为带宽有限,流量巨大,所以链路状态非常差。尤其是上午9点后和下午6点后的上网高峰期,这条网络经常出现20%以上的丢包,处于完全不稳定的状态。带来的将是极差的用户体验。

我们采用了下图中的几个步骤,来提升了图片上传的速度和API访问的稳定性。即就近部署、单/双边加速、异步拉取/回传。要实现以上的几点,阿里云也有很好的支持,即云解析、OSS和图片服务。

ffaf8f5a9dfade67df92a467ccdd11d657764a44

高可用与容灾的架构优化

梦想旅行希望提供个性化的推荐和检索,就需要快速实时的处理能力。

另外,高可用和异地容灾是每个企业都会考虑的重要问题,我们在北京实现了一个准实时镜像备份,如果一旦主机房出现问题(或者自然灾害)都能够及时的进行数据切换,避免服务长时间无法使用。

下图是梦想旅行的高可用与容灾方案架构图。

fb45a797878ded96f2183b7fe29128b46027ab1b

1. 负载均衡

负载均衡(SLB)是我们的服务中是非常常用的基础功能,以保证每个服务的高可用,同时主备机房准实时同步,也保证了数据安全可靠。

需要一提的是,如果对转发性能要求的非常严格,例如API内部会多次访问,最常见的场景是数据库的访问,此时SLB的转发性能还是损失比较大的,我们的方案是,对于要求不高或访问较少的场景下,采用SLB,同一请求内部,需要多次访问的,采用本机haproxy,实现本机转发,提升转发性能,可以显著的加快访问速度,相比SLB提速400%,因为经典网络下无法实现VIP的方式,所以此处为本机的HAProxy。

2. 消息队列

消息队列是服务模块化,各个业务之间解耦的重要工具,梦想旅行目前采用的是kafka集群,因为之前的工作经验,团队对消息队列的技术积累也比较充足,之前日均处理消息量60亿,在该方面实际经验比较丰富,所以目前自己维护。

3. 数据传输

备份方面,梦想旅行采用Otter作为数据库和文件的传输工具,Otter是由阿里集团开源,最初使用在B2B做中美之间的数据同步,我们采用主要做主备机房见的数据库同步。这里需要说明的是,线上的数据库我们采用的是PXC,原因就是希望访问快速,自主性更强,而一些其它的数据库,如审核系统、CMS等,我们均采用RDS。阿里云的OSS跨区备份前不久上线,也解决了我们文件数据同步依赖于otter的问题,现在数据同步更快更及时。

4. 云监控

系统监控方面,最初的采用是自建的zabbix服务,后来改用云监控,比较方便定制,通过自定义,基本能够解决大部分监控问题,也方便使用。

5. 日志系统

日志系统一方面梦想旅行接了消息队列做实时处理,另一方面接了阿里云的日志系统,通过odps进行数据分析,简化了日志分析流程。

6. 其他

消息集群采用的为Kafka,数据库部分采用的为PXC。

 

【云栖快讯】云栖专辑 | 阿里开发者们的第20个感悟:好的工程师为人写代码,而不仅是为编译器  详情请点击

网友评论