|
BBPrice
1 系统设计目的
BBPrice系统是一个定位旅游门票价格聚合系统。现在互利网上的旅游订票系统有很多，国内比较出名的有途牛，携程，同城，驴妈妈等等。
有些旅游项目，各大网站的价格相差非常多,给出游造成了不少困扰。本人就有一次被骗的经历，携程和同城之间的票价竟然相差50多元，
而票价也才200多元。票价贵，关键服务也不一定好，所以需要有一个系统来收集用户的反馈，为用户提供更好的服务和售后。
1.1 功能概述
系统主要功能包括门票聚合，酒店费聚合，车票聚合,飞机票聚合,跟团游票价聚合等,第一期先做门票的聚合。
景点门票主要包括景点的基本信息，服务评分，票价排行，评论聚合等。
1.2 非功能约束
抓取引擎的最低更新率为48小时，第一期的景区范围可以限定为浙江省，等引擎稳定后推广至全国。
2 系统部署图与整体设计
2.1 系统部署图
该系统目前第一期主要包括抓取引擎，数据处理引擎，聚合业务API服务，和前端展示系统,后台数据编排系统(前后端)。
底层存储系统是整个架构的保证，其中包括了两部分，第一部分是物理的部分，借助于Mongo的易于横向扩展性，所以我们的架构也能轻易缩放；
第二部分是业务上的部分，也是由于Mongo的无模式化原因，所以数据结构更应该在设计初期进行定义，特别是两个系统明显交界的部分。
3 系统的关键问题
景点的唯一性问题
这个问题其实在所有比价问题的程序中都会存在,比如商品比价程序，他们的商品如何确定是同一件产品？是通过标题么，还是SKU?
如图二和图三对于苏州的周庄，他们的叫法可能不一样，有些是细微的差别，有些差别应该很大，这个时候如何知道他们为同一个景点呢？
可能会说，比如用地点或者经纬度去判断，但这种办法是否足够准确，我觉得存在一定的疑问，因为毕竟不能保证两边的信息都不缺失。
4 领域模型描述
关于用户模块，按我们网站的性质，其实用户是不用的，那为什么还是加入了用户模块呢？主要原因是虽然用户可以不登录就使用我们的网站，
并且不会产生任何的功能缺陷，但是我们还是要积极引导用户到我们系统上，方便我们铺开后面的增值服务。
总之一句话，为大多数的用户提供服务，但也不要阻碍为优质用户提供更进一步的服务。第二点就是比价聚合网站为什么要做攻略？其实现在
很多人不光光看中的价格，更重要的是服务，所以我们不单单聚合进价格，也应该聚合进让用户一切可参考的元素，当然这里存在一个取舍问题，
所以前期也可以导航到第三方服务网站的方式来做，这里只是放一个链接。
5 盈利模式和引流
5.1 盈利的来源
众所周知，盈利的前提是需要找到需求点，就是说我们网站能为我们的客户提供什么。只要找到了服务的客户群，才能针对性的出击，哪怕是一个
两个需求点，也是可以带来利润的，其他的服务可能是带来流量的手段罢了。
带着这个观点，回到我们的项目来看看。第一网站一旦做起来后，广告是肯定有的，一般的网站，都有这个属性。
第二，目前我们BBPrice服务的客户主要是对旅游和周边感兴趣，这个范围主要包括门票，酒店，机票/车票,跟团游。要讨论这个问题之前，我们
先明确几个词语，第一个是C端用户指的是购票人，第二是平台方指的是像携程等类似网络平台，第三票源方就是景区或者服务提供者。
景区门票对于C端用户而言，其实更相信大平台，我们能为他们做的也只是比价的服务。另外一边，对于平台方其实已经和票源方达成一致，
把价格压得很低了，往往比线下购买低得多。所以票源方也更愿意相信大平台，往往也会签署一定的协议。其实这里需要注意的是票源方很多都是
国企单位，票价也更透明。所以这里门票价格真的不会差太多，只是有时候搞活动的时候可能会有一些差异。同样的情况也适用于机票和车票。
说酒店这个行业，一年的盈利非常多，也可以看到很多酒店都是依托旅游区周边发展起来。每年，特别是旅游旺季，基本是一房难求，所以才有了很
多民宿，民房，一方面吹嘘更加亲近自然，一方面价格其实贵的离谱。
图5是说明了酒店其实一年比一年需求大，特别近几年。
酒店其实也分很多档次，比如经济型，高档，中高档，民宿等,参差不齐。但是在中国，目前还是偏经济型多一点。
说了这么多，其实我想说的是，我们为什么不能替酒店做客户引流呢？一方面我们采集全网的数据，告诉客户哪个网站最便宜，另外我们欢迎
酒店和我们合作。如果对于合作的酒店，我们一方面提供显耀的位置和推荐位置，另外一方面我们告诉客户，在我们平台订购酒店更加优惠，
当然也可以另外做一个酒店订购平台，在这里只是把我们的价格放在上面而已。
当然，需要酒店和我们合作，能为他们导流和带来订购服务的生意他们为什么不做呢？
6 系统和展望
疫情之后，旅游业将慢慢复苏。虽然在疫情中，旅游业和很多实体业一样都遭受到重创，但是我相信旅游业是一个朝阳行业，一个可以持续
发展的行业，相信我们团队能做出这个系统，服务这个行业!!!
|