携程技术演进之路

作为互联网 OTA 领头羊，携程在近 20 年的发展历程中，在业务形态和互联网行业整体发展驱动下，经历了三轮技术体系的演进。本文将详述这一技术演进历程，希望能给互联网企业，尤其是早期的互联网企业一些借鉴和启发，帮助大家少走一些弯路。

一、携程当前的技术体系

最新的财报显示携程的 GMV 将近 7000 亿，已经是全球排名第一的在线 OTA。支持如此大业务量背后的技术体系，规模也是巨大的。

携程目前有将近 4000 研发人员，周发布数 8000+，应用数 10000+，主机实例数 80000+。

有多个数据中心，遍布中国大陆，香港，欧洲，美国等。而且在核心数据中心之间，实现了高可用和灾备计划，网站可用性达到 4 个 9。

上面这张图是携程技术体系组成，画的还是比较简单的，远不能反映目前携程体系架构的复杂性。

主要包括三大块：

第一块系统架构，由无线大前端平台、分布式框架与中间件、分布式大数据存储构成。

第二块，建立在基础框架上面的，是非常复杂的业务系统，携程酒店、度假、机票等业务的订单和商品中心产品数据等等，都是根植于这个系统当中。

第三块，赋能系统。比如大数据与人工智能平台，会把海量的大数据收集起来，做深入的数据挖掘和推荐。运维部署保障中心，把整个服务器的资源统一管起来，通过强大的监控中心和运维体系保障系统正常运行。

二、携程技术演进路线

携程技术演进路线，可以大致分成三个阶段：

• 呼叫中心时代，主要是以线下业务驱动为主；

• 互联网+移动互联网时代，产品技术驱动为主；

• 数字化+AI 时代，大数据驱动为主。

三个阶段是很漫长的，也经历了非常复杂的演变过程。总体而言，技术演进取决于业务形态和互联网行业的发展变化。

在这里提一下携程的业务特点，携程算是 O2O 企业的鼻祖，具有和其他 O2O 一样的特点，比如线下重，线上轻；对资源重度依赖；线下流程复杂，像我们常说的三流企业（信息流、物流、资金流）；属于典型的 ERP 形态。所不同的是携程是 Offline To Online 递进，跟现在通常所说的 O2O 递进顺序是相反的，但是殊途同归，大家的最终业务形态是类似的。

2.1 呼叫中心时代

2.1.1 业务场景

呼叫中心时代，是很多老携程人经常会怀念的时代。携程最早的客户业务是从发卡开始的，那个时候，在火车站、汽车站、机场，我们的业务人员拿着携程的会员卡去发放。

会员卡上有两个关键数字，一个是卡号，一个是携程呼叫中心的电话号码。客人想出差订酒店，只需要打携程呼叫中心电话，报卡号，用户关系就建立起来了。

所以那时候的流量入口是电话。

这个业务场景也决定了携程和一般互联网企业有些不太一样的地方。因为流量入口是电话，携程是通过坐席人员代替用户来操作，因此对坐席的操作规范和服务流程，要求是非常严格的。但因为用户不直接接触系统，所以用户体验是很弱的。

2.1.2 技术体系

这个时期的技术体系，具备初创企业典型特点。

首先是架构比较单一，主要的商业逻辑写在数据库层面。当时我们主要采用微软 Windows 平台，ASP+SQLServer 这样的一个体系架构。跟很多互联网公司，刚起步的时候，所采用的 LAMP 体系架构都是类似的，都是通过脚本语言加上数据库，快速搭建一个系统去做。这类体系架构的缺点是高耦合，扩展性不好，优点就是开发和发布快。

那个时候建立新的产品和业务，都是以 C2P（Copy To Paster）模式为主。如果想快速开展新业务，最简单的办法是拷贝粘贴，把原来的代码直接拷过来进行修改。例如携程酒店是我们的第一个业务，机票是第二个，我们就直接把酒店代码拷贝过来，然后再在上面去改。

总结下来就是： 快速迭代、快速开发、快速发布，非常契合业务的高速发展需要，但是耦合高，扩展性差，体系结构没有经过优化，也为后面挖了不少坑。

2.2 互联网和移动互联网时代

2.2.1 业务场景

1999 年差不多到 2005、2006 年，携程都是以呼叫中心模式去做的。

2006 年开始，伴随着早期电商网站的起步，很多用户的行为习惯已经逐步转向互联网了，他们更习惯在网上买商品。因此伴随着用户行为的改变，这时候携程的流量入口也从电话转向到 Online，再到后来的移动端 APP。

2.2.2 技术体系

这个阶段的技术体系，跟大型互联网公司类似，以支持大流量并发访问和稳定性，扩展性为主，各个应用都是分层的。

分层有多个优势，第一通过分层把每一层的业务进行隔离和透明化，更多地进行解耦，也能很方便的部署。这样当有大流量的时候，可以很快扩充，把流量分担，做负载均衡。

第二，能做高可用。每一层应用都部署在多个服务集群上，当其中一个集群挂了，另一个集群可以很快顶上来。

另外一个就是可以通过服务化进行子系统之间的解耦。我们把所有以前的两层架构变成三层架构，三层架构变成四层架构。同时由于拆分了不同的子系统，子系统之间的相互调用通过 SOA 基于服务的方式去做。

这样能够非常快速的搭建基于核心服务体系之外的业务系统，给各个前端去使用，包括 Online、手机、Offline，统一的接口，统一的规范。那个时候提出的口号是：open API everywhere.

它带来的好处，就是现在大型互联网站所必须具备的，我们称之为的“3+1”模式，高并发+高性能+高可用，再加一个高扩展。

2.2.3 转型痛点

在这个阶段，可以说是携程整个技术体系转型最大，也是最痛的阶段。这里列出的一些痛点，现在看可能不算什么，但在当时还是比较困扰我们的。

例如：

1）业务快速发展跟不上

我们早期的拷贝黏贴的模式，在快速应对业务发展的前期起了非常好的作用。但是后来，随着业务快速发展和流量倍增，这种模式就不适合了。之前的技术体系本身就是两层架构，应用只能部署在单台服务器上，高并发能力有限。扩展性很差，不能进行大型应用之间的分层和部署，也就无法支持应用隔离和应用多集群部署。

痛点在于，前期越快，到后期必然会越来越慢，而应用架构和物理架构必须要重构，花费成本很高；

2）子系统的拆分边界不清

和很多互联网公司在进行技术改造的时候一样，携程早期拷贝粘贴了很多个垂直的像烟囱式的独立系统，这些独立系统中有很多重复的部分。

以支付为例，我们当时是把支付收集信息放到系统当中，酒店放到酒店集群，机票放到机票集群，支付完成之后，再把信息收集到一个数据库中。

这种情况下，如果银行需要改一个信用卡授权码，每个系统都需要重新做一遍，新的功能上线协调、沟通成本很高。系统的边界不清，你中有我，我中有你。

后来我们做了一个 SOA 子系统拆分的项目，重新梳理业务流程，把一些重复的子系统拆分出来。其实不论酒店还是机票、度假业务，有些流程是类似的，比如预订，都是先查询，然后下单、支付、发消息通知。

重复的子系统拆分出来之后，就变成了后来的携程公用系统，比如支付平台、消息平台、物流配送平台等等。这个项目整整进行了两年时间，为携程平台的转型打下了坚实的基础。

3）流程拆分复杂

过程非常复杂，牵扯到流程改变，流程重新划分，系统再改造的过程。这块不做过多阐述，总结下来就是：是公司的业务复杂度，决定了流程复杂度，从而决定了系统复杂度，一环一环传递下来的。因此系统的改造必须先从优化业务流程入手，而不是相反。

4）分层体系架构的复杂

不同的系统拆分之后，你会发现，原来很简单的事情，变得很复杂。

还是以支付举例，如果在一个系统里，下单、支付，支付成功之后，返回一个订单状态——交易完成。如果不成功，事务回滚。当订单和支付都在一个系统中时，我们只要写在中间件模块里，用微软的 transaction server 机制， 把代码嵌进去，成功了就 commit，失败了就 rollback，结束了。

但当拆成不同的子系统之后，支付平台和订单下单流程不在一个系统中，甚至不在一个物理服务集群中，如何去保证事务提交的完整性？这时只能通过类似状态机回调和消息队列的方式进行解耦，来保证最终状态的一致性，复杂度大大增加。

再比如缓存，本来在一个体系当中，每台服务器中，缓存数据都是独立和一致的。当分成不同集群之后，如何保证每台服务器中的缓存数据的一致性？

当然随着技术的发展，后面有很多系统，像 Redis 这种中间缓存数据中间件，就可以通过 hashcode 算法，较好的解决了分布式缓存的问题。但在当时，这也是个难题。

2.3 大数据和人工智能时代

2.3.1 业务场景

这个阶段，则是依托海量用户和海量数据，发展平台个性化和数字化，以及通过 AI 赋能。 在我看来，所有的电商平台系统，最终都会演变为这种形式。

2.3.2 技术体系

携程在这个阶段，技术体系主要是“ABC 战略”。由下至上依次是：

C——Cloud（云），计算、网络、存储云化；

B——Bigdata（大数据），在云上做整个集团数据集成、共享、交换、打通；

A——AI（人工智能），在 B 之上，做个性化、数字化和人工智能；

目前携程 AI 赋能主要体现在两块：

第一块是营收增长方面，做精准化的营销，个性化推荐，提升转化率。

最近刚看到一个消息，就是淘宝宣布双 11 期间，通过点击淘宝个性化推荐商品页面进来的用户所成交的订单数，已经超过主动搜索进来的用户。这里面节省的用户费力度成本，订单转化率成本，都是很可观的。由此也更进一步证明了，基于海量数据发展出的个性化、数字化特性对电商平台的重要性。

这将是电商以后发展的一个大方向，其实像今日头条、抖音等内容信息类平台，就是通过大数据的个性化驱动和分发的方式，大大提升了用户黏性，从而后发先至，将对手远远抛在身后的。

第二块则是通过人工智能做客服机器人和 AI 数据挖掘。

携程有一个很大的呼叫中心，座席一万多人，为我们的客人提供服务。而通过客服机器人，可以部分代替座席，降低成本，提高效率，并加快服务响应，这是携程可以深挖的地方。

过程中也遇到了很多问题，比如语音识别的准确性，可能还不能很好的支持进行多轮的人机对话。如果我们语音识别率每次可以达到 90%的话，一轮对话下来 90%，两轮对话下来就只有 81%，最终的准确率大家可以想象。

所以怎么去做呢？

可以想象下，你到了海外，语言不通，如果点菜只通过语言去讲的话，效率是比较低的。而这时候，如果商家拿出一个菜单，你只需要点击菜单，告诉商家“这个，这个”就结束了。

所以我们的智能客服，同用户的信息交流方式也要多样。不仅仅通过文本和语音，还可以通过其它图文并茂的方式，最短时间内，让用户和机器人可以达到信息交流的目的，提高效率。

关于携程的技术演进之路，简单介绍到这里。现在回头看来，携程走过的这些历程，跟其它大型电商平台，都是非常类似的，所谓殊途同归。大家都是通过不断的迭代，重构，引进和吸收新的技术和理念，一步一步走到今天。

我们现在还在路上，相信以后也会一直在路上。

作者介绍：

李小林，携程技术副总裁，平台研发中心负责人。从事 IT 互联网技术研发工作二十多年，目前负责携程基础设施平台。

本文转载自公众号携程技术（ID：ctriptech）。

原文链接：

https://mp.weixin.qq.com/s/24-0KSmB40K_E9yiwAh5VA