携程酒店管理系统(酒店管理系统)

一、背景

随着携程海外酒店业务的发展，遍布全球的海外供应商与携程总部IDC之间的数据传输量迅速增加。技术上，这种不断增加的数据量对跨境网络专线的带宽和时延提出了更高的要求。业务方面，目前跨境网络专线资源有限，对业务处理效率和用户体验也有一定影响；事实上，跨境网络专线作为一种昂贵的资源，单纯的扩容专线会给IT成本带来很大的压力。于是我们开始思考，能否将公有云与酒店直连的业务特点相结合，解决日益增加的带宽压力和供应商接口延迟。

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

本文详细介绍了携程直达号服务向AWS迁移部署过程中进行的应用架构调整和云原生改造，使用AWS后获得的技术和业务效益，以及部署过程中EKS(亚马逊弹性库伯那特斯服务)的成本优化、DNS查询延迟和跨AZ流量降低等。

二、痛点

携程对接了上千家海外供应商，所有的接口访问都是通过代理商进行的(见图1)。由于携程的业务特点，当一个用户请求时，会根据人数、国籍、会员和非会员等拆分成多个请求。一个请求最多可能被拆分成几十个请求，请求消息非常大(通常从几十Kb到几百Kb不等)。虽然我们可能只需要在消息中返回少量信息，但目前，我们很难响应请求。

图1图1

同时，由于供应商遍布全球，所有的请求/响应都要经过集团的代理出口，导致部分供应商由于物理距离的原因，接口响应延迟更高，会降低用户体验。

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

这次的核心目标之一是提升对接全球供应商的网络传输能力和时延改善，提升用户体验。需要选择一个在全球有广泛资源的云厂商，帮助携程尽可能接近供应商地访问数据。经过与几家公有云厂商的多轮沟通，考虑到各厂商的技术水平、服务能力、成本和价格，我们认为无论从全球覆盖和网络能力来看，AWS在云服务、现场团队的服务能力和响应时间方面都是先进和成熟的(见图2)(AWS在全球25个地区和80个可用地区提供广泛的服务能力，数据中心通过其骨干网络互联)。

图2图2

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

在资源方面，改革服务后，我们使用大量的投标实例作为EKS工作节点，大大降低了成本，提高了效率。

同时，利用公有云的网络和平台优势，将原来部署在携程总部IDC的相应业务服务，部署到离供应商更近的海外公有云站点，实现携程与海外供应商的高可靠、低时延网络直连，部分数据预处理逻辑剥离，提前部署到海外公有云， 以至于只有经过处理的有价值的数据(而不是原始的、全量的裸数据)才会被压缩后再传输到携程总部的数据中心，从而减轻跨境网络专线的压力并加以改善。

四、酒店直连上云经验

4.1云业务应用的云原生转型

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

1)访问供应商模块上云

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

图3图3

公有云厂商一般采用按流量收费的价格策略。在设计进出站网络接入技术方案的过程中，会默认使用AWS NAT网关，因此网络流量成本比较高。考虑到酒店直连请求有一个特点，通常请求消息小于1K，而响应消息平均在10k到100K。利用这一特点，我们在AWS中采用了基于EKS的自建Squid代理方案(见图4)，这样只有出站的请求消息会产生流量费用，而大量的入站响应消息不会被收费，从而大大降低了AWS中产生的网络流量费用。

图4图4

2)减少网络延迟，利用AWS全球数据中心就近拜访供应商。

很多海外供应商的服务都部署在世界各地，我们所有的海外访问都是通过代理分销的。因此，一些部署了远程服务器的供应商由于物理距离而具有很高的网络延迟。通过AWS在世界各地的数据中心，我们可以在供应商的机房附近部署服务。同时，我们可以利用AWS的骨干网，减少从各个数据中心到代理所在地附近的AWS数据中心的延迟。最后，我们可以通过专线将AWS数据中心与携程IDC连接起来(见图5)。整个过程明显改善了网络延迟受物理距离影响较大的供应商的绩效，最多可减少50%的响应时间。

图5图5

4.2持续的架构转型以及性能和成本优化

在目前的方案中，我们独立开发了一套新的上云应用，带来的问题是当有业务变化时，需要同时调整部署在携程IDC和AWS上的两个应用，增加了系统维护成本。主要原因是原应用严重依赖携程的基础组件。这一次，我们试图在云上使用完全独立的账户和VPC网络。如果我们也在云上部署一套，那就不现实了。首先，这将花费太多，其次，一些敏感数据不能存储在云中。所以后续会优化适配器架构，复用一套应用来适应不同的云环境，不依赖携程的基础组件。

业务上线后，为了验证未来更大规模上云的可能性，我们也在不断优化性能、成本、高可用。

4.2.1利用云的弹性可伸缩性

以资源成本计算为例:计算实例成本=实例运行时间*实例价格。如果把本地机房的运营模式简单粗暴地套用到云计算上，云计算资源的成本比本地机房要高。因此，我们需要充分利用云的按需收费特性，降低闲置资源的成本。实例的运行时间与Kubernetes集群中的服务数量和分配给这些服务的计算资源成正比，而服务数量与流量成正比。

酒店直连业务场景中存在不可预测的业务流，例如临近节假日发布的旅游政策或现场营销活动。云的原始弹性很好的利用了合理的资源来应对突发流量。

Kubernetes的HPA弹性架构会实时收集整个集群的负载指标，判断是否满足弹性伸缩条件，进行pod的伸缩。豆荚的膨胀和收缩是不够的。我们还需要使用集群中的Cluster Autoscaler组件来监控集群中因资源分配不足而无法正常调度的pod，并自动从云平台的实例池中申请添加节点。同时，当流量下降时，集群自动缩放组件还会检测集群中资源利用率低的节点，将pod调度到其他可用节点，并回收这些空闲节点。

弹性伸缩案例弹性膨胀箱

云的原生弹性不仅有助于降低资源使用成本，还能提高服务对基础设施故障的容错率。在基础设施的一些可用区域中断和不可用期间，其他可用区域将增加相应的节点数量，以保持整个集群可用。

Kubernetes支持调节pod容器所需的CPU和内存，找到合理的配额，以合理的成本达到最佳的性能。所以在服务上云之前，我们会做一些接近真实环境的负载测试，观察业务流量的变化对集群性能的影响(业务周期性高峰和低谷的资源利用率，服务的资源瓶颈，以及适当的余量资源缓冲处理尖峰等。).不会因为实际利用率太高而导致稳定性问题，比如OOM或者频繁的CPU节流，也不会因为太低而浪费资源(毕竟即使你的应用只使用了1%的实例，你也要付出100%的实例成本)。

4.2.2公共云招标示例

有些云平台会把一些闲置的计算资源作为竞价实例，以低于按需实例的价格出租。顾名思义，投标实例的最终成本由市场供求投标决定。根据我们的实际经验，如果不是特别热门的机型，定价基本在点播实例成本的10-30%左右。低价竞标的例子自然有其局限性。云平台可能会调整竞价样本池的资源比例，以回收部分样本。据统计，一般回收概率通常为

图6图6

为了最大限度地减少投标案例的中断效应，包括案例在多个可用区域的再平衡效应，我们在选择不同案例类型的情况下，通过使用ASG(AWS auto scaling Group Elastic Extension Group)独立管理不同的案例资源池，从而保证资源的最大利用效率。

图7图7

携程采用按需实例和竞价实例混合部署，保证低成本和高可用性。系统的一些关键组件(如集群自动缩放器)和有状态服务(如Prometheus)在被中断时会丢失数据，它们运行在按需实例中。然而，灵活的无状态业务应用程序运行在投标实例上，对错误有很高的容忍度。通过kubernetes的节点亲和性，控制不同类型的服务被分派到相应类型标签的实例中。(参见图8)

图8图8

通过kubernates的原生HPA和ClusterAutoscaler组件，结合AWS ASG，充分利用竞价资源，成本可降低50%-80%。

4.2.3 DNS解析性能优化

当服务规模逐渐增大时，我们发现服务之间的调用延迟明显增大，平均为1.5S，峰值为2.5s，经过分析发现，性能解析瓶颈主要是由于DNS解析负载过高造成的。最后，我们采用社区主流的localdns方式，对热点解析域名进行本地缓存，以减少对核心dns的频繁解析请求，提高性能:

图9图9

如图9所示，在每个节点部署基于DaemonSet的NodeLocal DNSCache，通过Node LocalDNS缓解CoreDNS服务的DNS查询压力。LocalDNS缓存将在其所在的节点上监控每个客户端Pod的DNS解析请求，并通过本地解析行为对其进行配置。本地DNS缓存会先尝试通过缓存解析请求，如果解析失败，会去CoreDNS查询解析结果并缓存，以备下一次本地解析请求。

如下图所示，通过使用LocalDNS方案，我们将峰值延迟从2.5毫秒减少到300毫秒，将响应时间缩短了80%:

在使用LocalDNS之前，平均响应时间为1.5-2.5S

未优化前优化前

使用LocalDNS方案后，响应请求减少到300-400ms，延迟优化80%。

优化后优化后

4.2.4公共云跨可用区域流量优化

使用竞价实例大幅优化资源后，我们注意到服务大幅扩展后，跨可用区域的流量占比非常高(60%)。这是因为当在服务之间调用时，我们将服务单元部署到不同的可用区域，以最大化服务的可用性。与此同时，问题是服务之间的大量流量交互带来了可用区域的流量费用(参见图10)。

图10图10

但是为了整个系统的高可用性，我们不希望在单个可用区域部署服务，降低服务SLA。我们需要减少可用区域的流量，同时确保服务的高可用性。

经过对不同方案的考察，我们最终使用AWS NLB来暴露服务，并通过NLB的disable cross-az功能，将上下游服务控制在同一个可用区域内。同时，利用前面提到的本地dns组件，固化了访问NLB不同可用区域的上游业务的域名解析，保证了上下游业务流只能在可用区域内进行通信。改造后，如下图所示:

图11图11

后端服务会通过K8s的Kube-proxy进行转发，导致跨可用区域、跨节点。我们选择使用externalTrafficPolicy本地策略来固化本地节点服务上的转发流量，但同时本地转发策略也带来了一些问题(见图12):

图12图12

如上图所示，本地转发策略可能会因为后端服务分布不均衡而导致流量黑洞和服务负载不均衡。因此，在此基础上，我们使用EKS弹性扩展组策略将底层节点的资源平均分配到不同的可用区域，同时使用K8s反亲和策略将服务尽可能分配到不同可用区域的节点，最大程度地保证了流量均衡和跨可用区域部署的服务的高可用性。

优化后，通过可用区域的流量减少了95.4%。(参见图13)

图13图13

动词 （verb的缩写）后续优化改进的方向虽然目前的架构已经解决了我们业务中的一些问题，但是还有一些不足之处可以改进。为了就近接入供应商，我们使用独立的VPC网络来部署和测试我们的集群，所以我们需要在云端单独部署相关的存储依赖和日志监控组件，这无疑增加了运维的难度和服务在不同云端的迁移。

针对最新架构设计中的这个问题，我们计划做如下改造。首先，我们会把需要在云端计算、依赖持久存储数据的功能迁移回携程IDC，这样这部分数据就不需要传输到云端。其次，由于公司在其他AWS数据中心已经有了成熟的环境，我们只需要和OPS合作，打通两个AWS数据中心之间的VPC网络，然后就可以使用公司的日志和监控框架，降低运维成本。

六、总结

本文通过携程直连云的实践，分享了如何在云上快速搭建稳定高效的生产环境，实现快速交付、智能化和柔性化，以及在云上的一些成本优化经验。借助云原生系统，实现基础设施自动化，释放部分运维工作，使业务迭代投入更多，业务需求迭代更敏捷，通过监控和日志实现快速试错和反馈。希望这能帮助更多想上云的团队，少走弯路，拥抱原云带来的好处。

【作者简介】

最后，携程软件技术专家，关注系统架构，致力于开发高可用、高性能的支撑业务系统。