途牛旅游系统架构的优化实践

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

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

嘉宾演讲视频及PPT回顾：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的模式。

架构师的角色

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