干货 | 携程技术演进之路

作者简介

李小林,携程技术副总裁,平台研发中心负责人。从事IT互联网技术研发工作二十多年,目前负责携程基础设施平台。本文来自李小林在“2018携程技术峰会”上的分享。

作为互联网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%,最终的准确率大家可以想象。

所以怎么去做呢?

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

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

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

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

原文发布于微信公众号 - 携程技术中心(ctriptech)

原文发表时间:2019-02-13

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券