TOP100summit：【分享实录-途牛】价格中心系统的优化之路

本篇文章内容来自2016年TOP100summit途牛旅游网高级架构师，技术委员会开发组长赵国光的案例分享。
编辑：Cynthia

导读：价格中心系统是途牛网众多系统中很重要的一个，几乎全部的售卖价格计算都由此系统产生。初期因为缺少合理设计，没法及时知足业务高速增加的需求，出现价格计算速度慢、系统不稳定、增长功能困难等问题，系统面临巨大压力，在这种状况下咱们启动了系统优化。通过优化系统的稳定性获得巨大提高，特殊场景下的性能提高为原来的几十倍，平均性能提高为原来的几倍。本文将就途牛价格中心系统的优化实践做深刻分享。

1、旅游产品的特色

旅游产品是各类资源的整合，包括机票、酒店、门票、签证等全部旅行过程当中使用到的各类服务。以三亚五日游产品为例，第一天飞到三亚并入住酒店，而后各类玩，第五天飞走，其中涉及到不少种服务。

在计算过程当中须要处理这些场景:

● 产品的每一个团期都须要排列选出最低价格的资源组成；
● 同一资源在不一样的团期下价格可能不一样(淡旺季,不一样供应商报价不一样,资源库存影响)；
● 须要考虑同行程下的酒店连住天数,选出连住多天总价最便宜的酒店资源；
● 某些资源只有计算时经过多个条件筛选才知道其价格(如飞机散客票)；
● 某些产品配置不少资源,如上千酒店。

所以，获得一个产品的价格须要不少的数据和计算。另外，资源的价格会频繁变化，好比机票的价格；或者因一批低价格的库存卖光了那么这个资源就没法再以低价售卖，价格就要涨。这些状况就会使价格发生变化。这种变化的频率很高，加上资源的数量较多，天天达到几百万次，且每一个资源会被多个产品使用，因此每一个资源变化都会引发多个产品的价格计算。这些因素形成价格中心面临两大难点：计算复杂、计算量大。

2、重构实践

在整个系统优化重构的过程当中咱们遇到了不少问题，正是这些问题获得了很好的解决，才使得系统优化成功。

2.1 系统最关注什么？

系统最关注的是响应时间？吞吐量？并发数？功能正确？仍是稳定性？这些都是咱们关注的，但当鱼和熊掌不可兼得的时候，咱们更关注什么？这个问题关系到咱们的技术选型以及更深刻地理解系统。

举个例子，假设是一个对响应时间要求很高的系统，一个请求要求当即获得响应，那么就不太适合过多的异步处理方式。价格中心系统更专一吞吐量，即资源的价格变化必须可以反映到产品的价格上。在响应时间方面不是强制要求必须毫秒级或秒级，事实上只要几秒内能够变过来就能够，由于客人在价格变化的一瞬间预约产品的几率是很低的。某些场景下响应时间能够更长，好比夜里刷价格，因此咱们彻底能够采用异步处理的方式。

2.2 系统的瓶颈在哪里？

系统的性能优化每每落到CPU/IO/内存这三个里面。那咱们的系统瓶颈在哪里？这个问题决定着系统优化该往哪走。拿价格中心系统举例，假如CPU很低、IO时间很长、内存使用量很大，就能得出一个结论：速度上不去，时间都消耗在IO上了，CPU得不到有效利用。进而得出对策：提高并发线程数，把CPU打上去。可是这样作会带来内存的消耗增长，因此不合适。

通过分析就会有疑问：这么多IO读取出来的数据占用了内存，而CPU较低，是否是有冗余的数据读取？带着这个疑问再次检查发现确实存在，这只是一个附带的发现，通过分析咱们基本肯定的方向是降IO，经过控制计算规模下降内存使用量。

2.3 抽象领域模型

抽象领域模型为了解决什么问题？

● 原系统中的功能逻辑混乱，耦合严重；
● 你们对一个功能如何实现缺少统一的认识；
● 产品和开发之间的沟通缺少统一的语言。

领域模型凝聚了领域知识的元素，是系统运行不可或缺的成员，但领域模型不具有系统总体运行所具备的知识，只负责模型内部的逻辑。

系统至少要有领域层和应用层，领域模型在领域层完成各自的逻辑实现，应用层再将这些领域模型关联起来。咱们通过抽象将系统提炼出大的领域模型为资源、产品、促销、交通、基础等。

2.4 微服务的划分

划分微服务是为了解决如下问题：
● 功能耦合；
● 数据耦合，即没有划分和保护的数据被多个功能模块依赖，致使一处数据的改动将波及大面积的功能模块；
● 升级的影响范围，因某个功能须要扩充实例将致使全部实例都从新部署，某一个小功能引发的上线也将是整个应用的上线。

具体作法是：经过抽象，基于以前创建的领域模型划分出符合系统特色的微服务，每一个服务应对系统的一类复杂度。不一样的微服务之间在逻辑功能、被调用频率、依赖的数据、实例个数等方面都是不同的。咱们的系统通过提炼划分为资源管理服务、产品价格管理服务、计算控制服务、促销计算服务、价格查询服务。

微服务之间的配合推荐采用异步消息队列的方式，这样服务只关心本身的处理逻辑，而不用关心本身产生的数据被谁以哪一种方式处理，服务之间是互相不感知的。

固然这是这个系统的特色决定的，由于能够稍微牺牲一点响应时间。经过RESTFUL接口的方式调用也是不错的选择，这时服务提供方必定是提供通用的服务，即不会在自身逻辑里出现“当调用者是XX的时候如何处理”这种判断。

2.5 控制每次计算的粒度

咱们的系统还面临一个特殊的问题：一个旅游产品由多种资源构成，好比酒店/门票/机票等，正如前文所说，一个产品的价格计算可能有多种资源和选择。

好比一个三亚5日游的产品，能够从北京/南京/上海/西安等多个城市出发，这些城市的航班都不同，会有许多航班线路可供选择，数量与能够去三亚的城市数量成正比。而这种城市数量会有多少，程序事先没法知道，彻底由业务人员的产品设计决定。

这种状况带来的问题就是：计算一个产品的价格时，不容易预先知道计算量大小，有时城市不多那么计算量就小，而有时出发去目的地的城市不少那么计算量就很大。

这至少会带来两个麻烦：
● 一是系统的能力不容易评估，由于每次技术的粒度都不得而知，没有统一的衡量标准；
● 二是内存会有很大的浪费。

通过分析，咱们认为从北京出发到三亚的产品价格和从上海去三亚的产品价格不要求在同一个时间产生，因此能够分开计算。这样就能够缩小每次计算的粒度，使每次计算的粒度控制在一个相对原子的大小上。这就大大下降了内存的使用，同时也加速了计算速度。

2.6 无缝升级

每次升级都要考虑如何作到对外无感知、同时可回滚的设计，将风险控制在最低。通常若是涉及到数据库结构变化，能够选择双写，新结构数据库稳定以后再将老库做废。

但咱们遇到一个问题：但愿改变输入规则，将配置方式由蓝色方式改成绿色方式，由于绿色的方式更灵活，更符合业务需求，但问题是线上已经有大量的蓝色方式数据配置，把这些数据全删掉再按照绿色方式配置上去是不可能的。

那么怎么作到平滑切换？除非找到一个算法将蓝色配置映射成为绿色，遗憾的是没有这种方法。

咱们的作法是将蓝色数据配置和绿色数据配置都向一个固定的模型去映射，把它们所有视为规则，那么蓝色和绿色就是四种规则。这样就作到了新老数据共存和平滑升级。

3、技术实现

3.1 扩展立方体

随着业务对计算资源、存储资源的需求不断增长，另外一方面摩尔定律失效，人们没法找到拥有巨大资源又价格合适的计算机来支撑本身的业务，因此转而经过大量廉价的小型计算机一块儿工做来达到超级计算机的目的。当计算需求增长，只要增长小型机的数量，就能够近似线性地增长系统性能。扩展性，是分布式系统的重要考量因素。

在图所示的扩展立方体中：
● X轴表明每一个结点同质（同类型、同功能），只要增长结点数就能够增长系统处理能力；
● Y轴表明基于不一样业务的扩展；
● Z轴表明不一样用户类型（优先级、地域等）的扩展。

目前咱们的系统主要是基于X轴和Y轴的扩展。

咱们的存储水平扩展方式是分表分库，但分库容易带来跨库Join的问题。咱们是基于产品ID做为分表关键字的，基本上没有产品之间须要关联计算价格的场景，因此基本规避了跨库Join的问题。

3.2 RESTFUL调用组件

在服务治理上咱们开发了一个RESTFUL的调用组件，经过它来解决服务发现/调用管理的问题。服务提供者将自身标识注册到注册中心，服务消费者经过注册中心得到可提供服务的列表。

3.3 消息队列

咱们在较多场景下使用了消息队列。消息队列的一个好处是解耦，在发送端看只须要将消息送到队列，send and forget，不须要关注消息会被谁以哪一种方式处理。

另外，负载均衡能够在消费侧完成，发送方无感知。这样就能够动态地增长或减小消费者数量。固然这样作也基本上要求业务的设计是无状态、异步化的。

4、案例总结

4.1 架构是为业务服务的。

评价架构的优劣要看是否更好地支撑业务发展，而不是使用了什么技术。只有最适合本业务特色的架构和技术选型才是好的。因此只有深入理解业务自己才有好的架构。

诸多开源中间件的出现，减小了业务人员须要本身实现的功能（除非开源的项目不知足要求），而架构师也从设计实现更多地转向对业务需求的判断，从而进行架构决策和技术选型与模式的运用。

本案例是百亿次计算量的系统优化，其实第一个应该讨论的话题就是这100亿次是不是必要的。事实上咱们确实经过优化下降了计算量，也下降了单次计算规模，这些都是创建在对业务的理解之上的。因此架构永远是从业务出发。

4.2 服务之间的边界要清晰，尽可能耦合小。

DDD的思想能够帮助咱们找到服务边界。

4.3 尽可能异步化设计,这样的耦合很小，逻辑上更清晰。

异步的系统要稳定得多，某一个系统出现瓶颈的时候还有消息中间件帮助缓冲。同步的调用在等待时(线程会阻塞）会间接影响并发和吞吐量。另外，异步的系统在升级时会更容易，系统之间的限制要小一些，能够在队列里面积压一些。

4.4 无状态省去了不少负载均衡的烦恼, 不须要作黏性。

能够很容易地作到水平扩展.有状态系统在水平扩展时是很是痛苦的。

4.5 小步迭代，可回滚低风险。

咱们作到了每一次上线都是可回滚的，数据库的设计在上线后的一段时间内都是向下兼容的。并且新老数据是能够并存的。

11月9-12日，北京国家会议中心，第六届TOP100全球软件案例研究峰会，刘晓涛：途牛研发总监将分享《天下武功惟快不破－微服务实践快速响应瞬息万变的市场》。

TOP100全球软件案例研究峰会已举办六届，甄选全球软件研发优秀案例，每一年参会者达2000人次。包含产品、团队、架构、运维、大数据、人工智能等多个技术专场，现场学习谷歌、微软、腾讯、阿里、百度等一线互联网企业的最新研发实践。大会开幕式单天体验票申请入口