业务高速增长，途牛旅游系统架构的优化实践

内容来源：2017 年 12 月 2 日，途牛首席架构师赵国光在“IAS2017互联网架构峰会”进行《途牛系统架构优化实践》演讲分享。IT 大咖说（微信id：itdakashuo）作为独家视频合作方，经主办方和讲者审阅授权发布。

阅读字数：2391 | 6分钟阅读

摘要

本分享介绍途牛在业务高速增长同时的系统架构发展过程，以及这过程中总结下来的经验和架构实例。

嘉宾演讲视频及PPT回顾：http://suo.im/5j0Pik

途牛业务与系统整体介绍

途牛是以出游度假为主的综合类的在线旅游入口，在进入正题之前，这里先介绍下旅游产品的几大特点或者说难点。

首先是产品构成复杂，呈现组合性而不是独立的。其次价格波动大，众所周知机票的波动幅度很大，相对的与机票关联的旅游产品价格也就会随之浮动。另外由于途牛对应的供应商众多，这些供应商对数据的描绘以及交互方式都不一样，所以我们要对这些数据进行计算匹配变成途牛内部的规则化描述形式呈现给客人。

在了解了旅游产品的难点之后，接下看下途牛的整体架构，这套架构目前还在不断演化过程中。系统的最上层是前端应用，App、web、M站等入口，中间是数据适配层和接口代理以及一些独立的应用，再往下是两层业务层，主要的业务逻辑都发生在这里，最下层是基础设施。

系统的构建过程中我们的原则是把公共的抽象的事务都落到下层。

系统演化过程中的经验

垂直架构

垂直架构其实很好理解，比如一个公司内部每个业务部门都有自己的应用系统和服务器，互相之间相互独立，这样的形式就是垂直架构。

能够确定一点的就是垂直架构架构并不适用于所有情况，如果有足够的人力和资金但是没有充足时间的情况下，选择垂直架构快速堆建业务可能会比较便捷。

而当公司发展到一定程度的时候，垂直架构的问题就凸显出来了，主要有三个问题。首先就是重复建设，不同的组织之间独立工作就一定会有重复的部分，这就造成了人力的损失。另一方面系统间的数据流难以打通，资源无法共享，这是因为垂直架构下每个业务的系统设计都是针对本身的，数据结构和交互方式都存在差异，因此很难打通两个业务。最后就是缺少业务沉淀，平台能力丧失了。

微服务化过程

在谈论微服务之前首先要明确一点，就是服务化技术框架不等于服务化，充其量只是披上微服务化的技术外衣。服务化追求的是解耦和复用，要做服务化得从问题域上思考，从概念层理解服务化然后再思考如何实现。

服务化中如果对系统拆分过细又管理不善的话，至少会带来三个问题。第一个问题是服务管理，无法理清众多服务之间的逻辑。其次是问题排查，通常一个业务链会串多个服务系统，一旦出现问题很难判断哪个系统出错。最后是沟通协同的问题，拆散的服务由不同的团队负责，那么团队之间的步调就很难保证。所以说微服务化是有成本的，而我们要做的就是让收益大于成本。

而服务化面临的第一个问题是重复，比如在一个系统架构中A调用b，而此时有需求要在b系统内实现某个功能，该功能和b原来的功能大部分相近，同时要求该功能尽快上线并且不影响原来的业务。对此最直接的做法就是拷贝一份b作为b1，然后在b1上实现新功能，这样就实现了隔离以及尽快部署的需求。

一般正常来说追求隔离是没问题的，但是不能以重复作为代价，重复所带来的问题长期下来会拖垮团队的开发能力，使得维护的系统越来越多而且还有些相似。

在分布式系统下本来就会造成数据一致性的问题，微服务下这个问题则会更加明显或容易出现，因此要小心避免，不要再人为的增加数据一致性的问题。

上图中a调用b，b调用c，最后b对c返回的数据进行加工然后返回给a，b为了加快对a的响应速度，调用完c后会将c的数据缓存到自身的系统内。这样的好处在于加快了对a的响应时间同时减轻了c的压力，但是同时带来了一个问题，c的数据发送变化无法通知给b，因为b缓存数据c是不知情的。面对这样的情况我们要做出权衡，是要追求多级缓存带来的性能提升还是将缓存放在c上减少系统一致性问题。

微服务化原则

以下为我们总结的微服务化原则。

- 面向业务，围绕领域模型

- 隐藏实现细节

- 聚焦用户和API

- 去中心化

- 独立、自动化部署

架构实例

不同场景下企业应用面对的复杂性是不同的，大致可分为三类。第一类是量的问题，大用户量，大流量，高并发等，第二类是业务逻辑复杂，第三类是业务功能的快速变化。

应用架构案例：订单平台项目

途牛有很多的业务品类，不同品类的订单人机交互逻辑不同，状态流转不完全相同，另一方面资源类型多，每种资源的处理方式又不同。

直观看来我们现在面临的是业务逻辑复杂并且品类较多的问题，这种问题最好的解决方案是在领域模型上寻找答案。

上图是应用领域模型的软件架构，可以看到所有的资源都被抽象出来变成了领域模型，虽然不同的资源操作方式不同，但可以将资源委托给具体的资源，这样新增资源时就不会产生任何影响。

不同的订单在价格、合同、资源管理器等方面都存在不同，而我们可以将这些部分抽象出不同的角色用不同的品类去实现，在订单生成时通过品类将不同的职责注入进去。

从大体上看整个架构采用的是CQS的模式。

架构师的角色

做为架构师首要目标是理解业务，需要注意的是清楚实现细节和理解业务是不同的，理解业务是要明白业务形态、商务模式。另外要能够定义问题并能提出解决方案，同时还要关注人的因素，毕竟要和不同职位上的人沟通，每个人的处理方式都是不同的。最后就是权衡，比如我们经常会需要在运行表现、工作量和功能上做权衡，那么如何做权衡呢，我认为必须要基于对业务的理解出发。

有问题可以在评论区讨论，以上为所有分享内容，谢谢大家！ 推荐文章

• 华为资深架构师：Cloud Native架构一致性问题及解决方案
• MySQL高可用架构案例篇：UCloud最佳实践
• 一场由React引发的前后端分离架构的思考