一、背景

随着携程海外酒店业务的发展,遍布全球的海外供应商与携程总部IDC之间的数据传输量快速增长。技术上,这种日益增长的数据量对跨境网络专线的带宽、延迟等提出了更高的要求;业务上,由于当前有限的跨境网络专线资源对业务处理效率及用户体验也造成了一定的影响;成本上,跨境网络专线作为一种昂贵的资源,通过单纯的专线扩容又会给IT成本造成巨大压力。所以我们开始思考是否可以通过公有云结合酒店直连的业务特性来解决日益增长的带宽压力和供应商接口延迟的问题。

酒店直连系统主要是使用自动化接口实现供应商或集团与携程之间的系统对接,实现静态信息、动态信息、订单功能等都通过系统的方式流转交互。目前携程大量海外酒店业务是通过酒店直连系统对接。

本文将主要从携程酒店直连服务迁移部署至AWS过程中所进行的应用架构调整及云原生改造,使用AWS后取得的技术和业务收益,在部署过程中对EKS(Amazon Elastic Kubernates Service)、DNS查询延时和跨AZ流量降低所做的成本优化等几方面进行详细介绍。

二、痛点

携程酒店海外直连对接了上千家海外供应商,所有的接口访问都通过代理出去(见图1),由于酒店直连的业务特性,当一个用户请求过来时会根据人数、国籍、会员非会员等裂变成多个请求,最多的时候可能一个请求会裂变成数十个请求,而且请求报文十分巨大(通常为几十Kb到上百Kb不等),虽然我们可能只需要返回报文中的一小部分信息,但是因为目前架构的限制只能将所有报文全部请求回来再处理,这无疑浪费了大量的带宽。

同时因为供应商遍布全球,所有的请求/响应都需要经过集团的代理出口,导致了部分供应商接口响应受到物理距离的影响延迟变高了,会降低用户的体验。

三、云服务选择及初步方案

本次核心目标之一是为了提高对接全球供应商的网络传输能力和延时改进,提升用户体验,必须选择一个在全球有广泛资源分布的云厂商帮助携程尽量靠近供应商访问数据。经过与多个公有云厂商的多轮交流,综合考虑各厂商技术水平、服务能力、成本价格等多方面因素,我们认为AWS无论是在全球覆盖及网络能力(见图2)(AWS在全球分布的25个区域和80个可用区提供广泛的服务能力,同时数据中心通过其骨干网互联,提升了未来不同数据中心的数据互访能力),云服务的先进性和成熟度、现场团队的服务能力、响应时间、专业水平都具有明显的优势,最终我们选择AWS作为资源部署的云厂商合作伙伴。

为了更好地与云上资源使用集成,我们采用IDC的容器化部署方案,最终考虑到托管容器平台的高可用性设计及SLA保证,及对社区的兼容性,使用AWS托管容器平台EKS作为部署的平台。

资源方面我们对服务进行改造后,大量使用竞价实例作为EKS工作节点,大幅降低成本并提高效率。

同时利用公有云的网络和平台优势,将原本部署在携程总部IDC的相应业务服务部署到离供应商距离更近的海外公有云站点,实现携程与海外供应商之间高可靠、低延迟的网络直连,并将部分数据预处理逻辑剥离出来前置部署到海外公有云上,实现仅将经过处理的有价值的数据(而非原始、全量的裸数据)压缩后再传输到携程总部数据中心,进而达到降低对跨境网络专线的压力、提升业务数据处理效率、降低成本、优化用户体验等目标。

四、酒店直连上云经验

4.1 云业务应用的云原生改造

为了充分的使用云服务带来的便利和成本优化,经过调研分析,我们如果直接将应用迁移至公有云上,虽然业务上会产生相应的价值,但成本会相对较高,因此我们对酒店直连服务进行了相应的云原生架构优化,相关的主要调整如下:

1 )访问供应商模块上云

要节省带宽需要减少通过从代理出去的请求同时减少每个请求的报文大小。我们的做法是将请求拆分的逻辑搬到AWS上,这样每次一个用户请求过来通过代理出去只有一次请求/响应。同时我们在AWS上将供应商返回的报文中无用属性剔除,然后再根据业务属性合并相关节点最后再压缩返回,这样就达到了缩减报文大小的目的(见图3)。从目前运行的数据上看,整个代理的带宽流量只用到了之前的30%~40%。

公有云厂商普遍采用按流量收费的价格策略,在设计网络出入站网络访问的技术方案过程中,默认情况下会使用AWS NAT网关,这样网络流量费用相对较高。考虑到酒店直连请求有个特性,通常情况下请求报文不到1K,而响应报文平均有10k到100K,利用这个特点,我们在AWS上采用了基于EKS自建Squid代理方案(见图4),这样只有出站的请求报文会产生流量费用,而大量入站的响应报文不收费,从而大大降低AWS上产生的网络流量费用。