共计 5704 个字符，预计需要花费 15 分钟才能阅读完成。
一、背景
随着携程海内酒店业务的倒退，遍布寰球的海内供应商与携程总部 IDC 之间的数据传输量快速增长。技术上，这种日益增长的数据量对跨境网络专线的带宽、提早等提出了更高的要求；业务上，因为以后无限的跨境网络专线资源对业务解决效率及用户体验也造成了肯定的影响；老本上，跨境网络专线作为一种低廉的资源，通过单纯的专线扩容又会给 IT 老本造成微小压力。所以咱们开始思考是否能够通过私有云联合酒店直连的业务个性来解决日益增长的带宽压力和供应商接口提早的问题。
酒店直连零碎次要是应用自动化接口实现供应商或团体与携程之间的零碎对接，实现动态信息、动静信息、订单性能等都通过零碎的形式流转交互。目前携程大量海内酒店业务是通过酒店直连零碎对接。
📢 想要理解更多亚马逊云科技最新技术公布和实际翻新，敬请关注 2021 亚马逊云科技中国峰会！点击图片报名吧～
本文将次要从 携程酒店直连服务迁徙部署至亚马逊云科技过程中所进行的利用架构调整及云原生革新，应用亚马逊云科技后获得的技术和业务收益，在部署过程中对 Amazon EKS（Amazon Elastic Kubernetes Service）、DNS 查问延时和跨 AZ 流量升高所做的老本优化等几方面进行具体介绍。
二、痛点
携程酒店海内直连对接了上千家海内供应商，所有的接口拜访都通过代理进来（见图 1），因为酒店直连的业务个性，当一个用户申请过去时会依据人数、国籍、会员非会员等裂变成多个申请，最多的时候可能一个申请会裂变成数十个申请，而且申请报文非常微小（通常为几十 Kb 到上百 Kb 不等），尽管咱们可能只须要返回报文中的一小部分信息，然而因为目前架构的限度只能将所有报文全副申请回来再解决，这无疑节约了大量的带宽。
图 1
同时因为供应商遍布寰球，所有的申请 / 响应都须要通过团体的代理进口，导致了局部供应商接口响应受到物理间隔的影响提早变高了，会升高用户的体验。
三、云服务抉择及初步计划
本次外围指标之一是为了进步对接寰球供应商的网络传输能力和延时改良，晋升用户体验，必须抉择一个在寰球有宽泛资源散布的云厂商帮忙携程尽量凑近供应商拜访数据。通过与多个私有云厂商的多轮交换，综合思考各厂商技术水平、服务能力、老本价格等多方面因素，咱们认为 亚马逊云科技无论是在寰球笼罩及网络能力 （见图 2）（亚马逊云科技在寰球散布的 25 个区域和 80 个可用区提供宽泛的服务能力，同时数据中心通过其骨干网互联，晋升了将来不同数据中心的数据互访能力）， 云服务的先进性和成熟度、现场团队的服务能力、响应工夫、业余程度都具备显著的劣势，最终咱们抉择亚马逊云科技作为资源部署的云厂商合作伙伴。
图 2
为了更好地与云上资源应用集成，咱们采纳 IDC 的容器化部署计划，最终思考到托管容器平台的高可用性设计及 SLA 保障，及对社区的兼容性，应用亚马逊云科技托管容器平台 Amazon EKS 作为部署的平台。
资源方面咱们对服务进行革新后，大量应用竞价实例作为 Amazon EKS 工作节点，大幅降低成本并提高效率。
同时利用私有云的网络和平台劣势，将本来部署在携程总部 IDC 的相应业务服务部署到离供应商间隔更近的海内私有云站点，实现携程与海内供应商之间高牢靠、低提早的网络直连，并将局部数据预处理逻辑剥离进去前置部署到海内私有云上，实现仅将通过解决的有价值的数据（而非原始、全量的裸数据）压缩后再传输到携程总部数据中心，进而达到 升高对跨境网络专线的压力、晋升业务数据处理效率、降低成本、优化用户体验等指标。
四、酒店直连上云教训
4.1 云业务利用的云原生革新
为了充沛的应用云服务带来的便当和老本优化，通过调研剖析，咱们如果间接将利用迁徙至私有云上，尽管业务上会产生相应的价值，但老本会绝对较高，因而咱们对酒店直连服务进行了相应的云原生架构优化，相干的次要调整如下：
1）拜访供应商模块上云
要节俭带宽须要缩小通过从代理进来的申请同时缩小每个申请的报文大小。咱们的做法是将申请拆分的逻辑搬到亚马逊云科技上，这样每次一个用户申请过去通过代理进来只有一次申请 / 响应。同时咱们在亚马逊云科技上将供应商返回的报文中无用属性剔除，而后再依据业务属性合并相干节点最初再压缩返回，这样就达到了缩减报文大小的目标(见图 3)。从目前运行的数据上看，整个代理的带宽流量只用到了之前的 30%~40%。
图 3
私有云厂商广泛采纳按流量免费的价格策略，在设计网络出入站网络拜访的技术计划过程中，默认状况下会应用亚马逊云科技 NAT 网关，这样网络流量费用绝对较高。思考到酒店直连申请有个个性，通常状况下申请报文不到 1K，而响应报文均匀有 10k 到 100K，利用这个特点，咱们在亚马逊云科技上采纳了基于 Amazon EKS 自建 Squid 代理计划（见图 4），这样只有出站的申请报文会产生流量费用，而大量入站的响应报文不免费，从而大大降低亚马逊云科技上产生的网络流量费用。
图 4
2）升高网络提早，利用亚马逊云科技寰球数据中心对供应商就近拜访
很多海内的供应商服务部署在寰球各地，而咱们所有的海内拜访都对立从代理进来，这样一些服务器部署较远的供应商因为物理间隔上的起因导致网络提早很高。通过亚马逊云科技的在寰球各地的数据中心，咱们能够将服务就近部署在供应商机房左近，同时利用亚马逊云科技的骨干网络升高各数据中心到代理所在地左近的亚马逊云科技数据中心的提早，最初通过专线连贯该亚马逊云科技数据中心与携程 IDC（见图 5），整个过程对那些因物理间隔对网络提早影响较大的供应商性能晋升较显著，最多可升高 50% 的响应工夫。
图 5
4.2 继续的架构革新和性能及老本优化
在目前的计划中，咱们为了上云独自开发了一套全新的利用，这样带来的问题就是，当有业务变更时咱们同时须要调整携程 IDC 和亚马逊云科技上部署的两个利用，进步了系统维护老本。次要起因是原利用中大量依赖携程的根底组件，本次上云尝试应用的是齐全独立的账号和 VPC 网络，如果在云上同样部署一套不太事实，一是老本太大，二是一些敏感数据不能放在在云端存储，所以后续咱们会对适配器架构再进行优化，在不依赖携程根底组件的状况下复用一套利用以适应不同的云环境。
业务上线后为了验证将来更大规模的负载上云的可能性，咱们同时也在对性能，老本，高可用性方面做继续一直的优化。
4.2.1 利用云弹性伸缩能力
以计算资源老本为例：计算实例老本 = 实例运行时长 * 实例价格。如果只是简略粗犷把本地机房的运行模式套用到云上计算，云服务计算资源的费用是高于本地机房的。所以咱们须要充分利用云上按需免费的个性，缩小闲置资源老本。实例的运行时长和 Kubernetes 集群内的服务数量，以及调配给这些服务的计算资源成正比，同时服务的数量又是和流量成正比。
酒店直连业务场景存在不可预测的业务流量，比方邻近节假日颁布的游览政策，或者营销直播流动。云原生的弹性个性很好地利用正当的资源应答突发的流量。
Kubernetes 的 HPA 弹性架构会实时采集集群整体的负载指标，判断是否满足弹性伸缩条件和执行 pod 的伸缩。仅仅是 pod 的伸缩还不够，咱们还须要在集群中应用 Cluster Autoscaler 组件，监控集群中因为资源分配有余无奈被失常调度的 pod，主动从云平台的实例池中申请减少节点，同时在流量降落的时候，Cluster Autoscaler 组件也会检测集群中资源利用率较低的节点，将其中的 pod 调度到其余可用节点上，回收这部分闲置节点。
弹性伸缩案例
云原生的弹性个性不仅帮忙缩小资源应用老本，也进步服务对基础架构故障的容错率，在基础设施局部可用区中断不可用期间，其余可用区域会减少相应数量的节点持续放弃整个集群的可用。
Kubernetes 反对对 pod 容器所需的 CPU 和内存调整，找到一个正当的配额以正当的老本达到最佳的性能。所以咱们在服务上云前会做一些靠近实在环境的负载测试，察看业务流量的变动对集群性能的影响（业务周期性顶峰和低峰的资源使用率，服务的资源瓶颈，适合的余量资源 buffer 应答尖刺流量等等）。既不会因为理论利用率过高导致稳定性问题，比方 OOM 或者频繁的 CPU throttling，也不会因为过低浪费资源（毕竟，即便你的利用只应用了实例的 1%，也要领取该实例 100% 的费用）。
4.2.2 采纳私有云竞价实例
某些云平台会把一些闲置计算资源作为竞价实例，以比按需实例更低的定价出租，顾名思义竞价实例的最终费用是按市场供需出价决定的。依照咱们理论应用的体验，如果不是特地热门的机型定价根本在按需实例费用的 10-30% 左右。高价的竞价实例天然有它的限度，云平台会可能会调整竞价实例池的资源比例回收局部实例，个别回收的概率依据统计通常 <3%, 同时在回收前会提前 2 分钟告诉到这些实例。咱们通过亚马逊云科技提供的 Terminal handler 组件在收到回收告诉后提前把容器调度到其余可用的实例上，缩小了资源回收对服务的影响。下图是某云对竞价实例的资源池划分，咱们能够看到，即便雷同的实例资源，在不同的可用区也是独立的资源池。
图 6
为了能最大限度缩小竞价实例的中断影响，包含实例在多可用区的再均衡影响，咱们在通过 Amazon ASG（Amazon Auto Scaling Group 弹性扩大组）抉择不同实例类型的状况下还将不同的实例资源池独立应用 Amazon ASG 进行治理，这样保障了资源的最大利用效率。
图 7
携程酒店直连应用按需实例和竞价实例的混合部署，保障低成本和高可用。一些零碎要害组件（比方 Cluster Autoscaler)，中断就会失落数据的有状态服务（比方 Prometheus）运行在按需实例。而对谬误容忍度高，应用灵便无状态的业务利用运行在竞价实例上。通过 kubernetes 的节点亲和性管制不同类型的服务调度到对应类型标签的实例上。（见图 8）
图 8
通过 Kubernetes 原生的 HPA 和 Cluster Autoscaler 组件联合 Amazon ASG 及竞价资源的充分利用，能够将老本升高 50%-80%。
4.2.3 DNS 解析性能优化
当服务规模逐步增大的时候，咱们发现服务间的调用延时显著回升，均匀达到 1.5S，顶峰达到 2.5 秒，通过剖析发现，次要是因为 DNS 解析负载过高造成的性能解析瓶颈，最终咱们采纳社区比拟支流的 localdns 形式，对热点解析域名做本地缓存，来升高对外围 DNS 频繁的解析申请从而进步性能：
图 9
如图 9 所示，在每个 Node 部署基于 DaemonSet 的 NodeLocal DNSCache，通过 Node LocalDNS 缓解 CoreDNS 服务的 DNS 查问压力，LocalDNS Cache 会监听所在的 node 上每个 Client Pod 的 DNS 解析申请，通过本地的解析行为配置，Local DNS Cache 会尝试先通过缓存解析申请，如果未命中则去 CoreDNS 查问解析后果并缓存为下一次本地解析申请应用。
如下图，通过应用 LocalDNS 计划咱们将顶峰的延时从 2.5S 升高到 300ms，缩短了 80% 的响应工夫：
未应用 LocalDNS 前，均匀响应在 1.5-2.5S。
未优化前
应用 LocalDNS 计划后，响应申请升高到 300-400ms，延时优化了 80%。
优化后
4.2.4 私有云跨可用区流量优化
在应用竞价实例对资源进行大幅优化后，咱们留神到跨可用区的流量在服务大幅扩大后占比十分高（60%），这是因为在服务之间调用时，咱们将服务单元部署到不同可用区，最大限度进步服务的可用性，同时带来的问题是服务间大量的流量交互带来了跨可用区的流量费用（见图 10）。
图 10
然而为了整个零碎的高可用性，咱们并不想将服务部署在单可用区，升高服务 SLA。咱们须要升高跨可用区流量的同时保障服务的高可用性。
通过不同的计划调研最终咱们应用 Amazon NLB 来裸露服务，通过 Amazon NLB 的 disable cross-az 性能，对同可用区的上下游服务进行流量可用区管控。同时应用之前提到的 local dns 组件，将上游服务拜访 Amazon NLB 不同可用区的域名解析进行固化，保障了上下游的服务流量只能在可用区外部进行互通。革新后如下图：
图 11
后段服务因为会通过 K8s 的 Kube-proxy 进行转发造成跨可用区跨节点，咱们抉择应用 externalTrafficPolicy 本地策略，将转发流量固化在本地节点的服务上，然而同时本地转发策略也带来了一些问题（见图 12）：
图 12
如上图所示，本地转发策略可能因为后端服务散布不平衡导致了流量黑洞和服务负载的不平衡，所以在这个根底上，咱们利用 Amazon EKS 弹性扩大组策略对底层节点资源平衡散布到不同的可用区，同时利用 K8s 反亲和性策略，将服务尽量散布到不同可用区的节点上，最大水平的保障了流量的均衡性，同时保障了服务的跨可用区部署的高可用性。
优化后跨可用区流量升高了 95.4%。（见图 13）
图 13
五、后续的优化改良方向
目前的架构尽管解决了咱们业务上的一些问题，但还是有一些不足之处能够改良。为了能够就近拜访供应商，咱们应用了一个独立的 VPC 网络来部署和测试咱们的集群，所以须要独自在云端部署相干的存储依赖以及日志监控组件，这样无疑减少了运维的难度以及服务在不同云上的迁徙难度。
在最新的架构设计中针对这个问题咱们打算做如下革新，首先 将须要在云端计算并且依赖长久化存储数据的性能迁徙回携程 IDC，这样这部分数据就不必再传到云端。其次因为公司在亚马逊云科技的其余数据中心曾经有一套成熟的环境，所以咱们只须要 配合 OPS 买通两个亚马逊云科技数据中心之间的 VPC 网络，便可应用公司的日志和监控框架，缩小运维老本。
六、总结
本文通过携程酒店直连在云原生的实际，分享了如何疾速在云上搭建一套稳固高效的生产环境实现疾速交付、智能弹性，以及在云上的一些老本优化教训。借助云原生体系实现了基础设施自动化，开释一部分的运维工作，能够更多地投入到业务迭代，更敏捷地响应业务需要迭代，通过监控和日志实现疾速试错和反馈。心愿借此能帮忙到更多想上云的团队，少走弯路，拥抱云原生带来的益处。
本篇作者
微末
携程软件技术专家
关注零碎架构，致力于高可用高性能的撑持业务零碎开发。
