干貨 | 攜程酒店AWS實(shí)踐

一、背景

隨著攜程海外酒店業(yè)務(wù)的發(fā)展，遍布全球的海外供應(yīng)商與攜程總部IDC之間的數(shù)據(jù)傳輸量快速增長(zhǎng)。技術(shù)上，這種日益增長(zhǎng)的數(shù)據(jù)量對(duì)跨境網(wǎng)絡(luò)專線的帶寬、延遲等提出了更高的要求；業(yè)務(wù)上，由于當(dāng)前有限的跨境網(wǎng)絡(luò)專線資源對(duì)業(yè)務(wù)處理效率及用戶體驗(yàn)也造成了一定的影響；成本上，跨境網(wǎng)絡(luò)專線作為一種昂貴的資源，通過單純的專線擴(kuò)容又會(huì)給IT成本造成巨大壓力。所以我們開始思考是否可以通過公有云結(jié)合酒店直連的業(yè)務(wù)特性來解決日益增長(zhǎng)的帶寬壓力和供應(yīng)商接口延遲的問題。

酒店直連系統(tǒng)主要是使用自動(dòng)化接口實(shí)現(xiàn)供應(yīng)商或集團(tuán)與攜程之間的系統(tǒng)對(duì)接，實(shí)現(xiàn)靜態(tài)信息、動(dòng)態(tài)信息、訂單功能等都通過系統(tǒng)的方式流轉(zhuǎn)交互。目前攜程大量海外酒店業(yè)務(wù)是通過酒店直連系統(tǒng)對(duì)接。

本文將主要從攜程酒店直連服務(wù)遷移部署至AWS過程中所進(jìn)行的應(yīng)用架構(gòu)調(diào)整及云原生改造，使用AWS后取得的技術(shù)和業(yè)務(wù)收益，在部署過程中對(duì)EKS（Amazon Elastic Kubernates Service）、DNS查詢延時(shí)和跨AZ流量降低所做的成本優(yōu)化等幾方面進(jìn)行詳細(xì)介紹。

二、痛點(diǎn)

攜程酒店海外直連對(duì)接了上千家海外供應(yīng)商，所有的接口訪問都通過代理出去（見圖1），由于酒店直連的業(yè)務(wù)特性，當(dāng)一個(gè)用戶請(qǐng)求過來時(shí)會(huì)根據(jù)人數(shù)、國籍、會(huì)員非會(huì)員等裂變成多個(gè)請(qǐng)求，最多的時(shí)候可能一個(gè)請(qǐng)求會(huì)裂變成數(shù)十個(gè)請(qǐng)求，而且請(qǐng)求報(bào)文十分巨大（通常為幾十Kb到上百Kb不等），雖然我們可能只需要返回報(bào)文中的一小部分信息，但是因?yàn)槟壳凹軜?gòu)的限制只能將所有報(bào)文全部請(qǐng)求回來再處理，這無疑浪費(fèi)了大量的帶寬。

圖1

同時(shí)因?yàn)楣?yīng)商遍布全球，所有的請(qǐng)求/響應(yīng)都需要經(jīng)過集團(tuán)的代理出口，導(dǎo)致了部分供應(yīng)商接口響應(yīng)受到物理距離的影響延遲變高了，會(huì)降低用戶的體驗(yàn)。

三、云服務(wù)選擇及初步方案

本次核心目標(biāo)之一是為了提高對(duì)接全球供應(yīng)商的網(wǎng)絡(luò)傳輸能力和延時(shí)改進(jìn)，提升用戶體驗(yàn)，必須選擇一個(gè)在全球有廣泛資源分布的云廠商幫助攜程盡量靠近供應(yīng)商訪問數(shù)據(jù)。經(jīng)過與多個(gè)公有云廠商的多輪交流，綜合考慮各廠商技術(shù)水平、服務(wù)能力、成本價(jià)格等多方面因素，我們認(rèn)為AWS無論是在全球覆蓋及網(wǎng)絡(luò)能力（見圖2）（AWS在全球分布的25個(gè)區(qū)域和80個(gè)可用區(qū)提供廣泛的服務(wù)能力，同時(shí)數(shù)據(jù)中心通過其骨干網(wǎng)互聯(lián)，提升了未來不同數(shù)據(jù)中心的數(shù)據(jù)互訪能力），云服務(wù)的先進(jìn)性和成熟度、現(xiàn)場(chǎng)團(tuán)隊(duì)的服務(wù)能力、響應(yīng)時(shí)間、專業(yè)水平都具有明顯的優(yōu)勢(shì)，最終我們選擇AWS作為資源部署的云廠商合作伙伴。

圖2

為了更好地與云上資源使用集成，我們采用IDC的容器化部署方案，最終考慮到托管容器平臺(tái)的高可用性設(shè)計(jì)及SLA保證，及對(duì)社區(qū)的兼容性，使用AWS托管容器平臺(tái)EKS作為部署的平臺(tái)。

資源方面我們對(duì)服務(wù)進(jìn)行改造后，大量使用競(jìng)價(jià)實(shí)例作為EKS工作節(jié)點(diǎn)，大幅降低成本并提高效率。

同時(shí)利用公有云的網(wǎng)絡(luò)和平臺(tái)優(yōu)勢(shì)，將原本部署在攜程總部IDC的相應(yīng)業(yè)務(wù)服務(wù)部署到離供應(yīng)商距離更近的海外公有云站點(diǎn)，實(shí)現(xiàn)攜程與海外供應(yīng)商之間高可靠、低延遲的網(wǎng)絡(luò)直連，并將部分?jǐn)?shù)據(jù)預(yù)處理邏輯剝離出來前置部署到海外公有云上，實(shí)現(xiàn)僅將經(jīng)過處理的有價(jià)值的數(shù)據(jù)（而非原始、全量的裸數(shù)據(jù)）壓縮后再傳輸?shù)綌y程總部數(shù)據(jù)中心，進(jìn)而達(dá)到降低對(duì)跨境網(wǎng)絡(luò)專線的壓力、提升業(yè)務(wù)數(shù)據(jù)處理效率、降低成本、優(yōu)化用戶體驗(yàn)等目標(biāo)。

四、酒店直連上云經(jīng)驗(yàn)

4.1云業(yè)務(wù)應(yīng)用的云原生改造

為了充分的使用云服務(wù)帶來的便利和成本優(yōu)化，經(jīng)過調(diào)研分析，我們?nèi)绻苯訉?yīng)用遷移至公有云上，雖然業(yè)務(wù)上會(huì)產(chǎn)生相應(yīng)的價(jià)值，但成本會(huì)相對(duì)較高，因此我們對(duì)酒店直連服務(wù)進(jìn)行了相應(yīng)的云原生架構(gòu)優(yōu)化，相關(guān)的主要調(diào)整如下：

1）訪問供應(yīng)商模塊上云

要節(jié)省帶寬需要減少通過從代理出去的請(qǐng)求同時(shí)減少每個(gè)請(qǐng)求的報(bào)文大小。我們的做法是將請(qǐng)求拆分的邏輯搬到AWS上，這樣每次一個(gè)用戶請(qǐng)求過來通過代理出去只有一次請(qǐng)求/響應(yīng)。同時(shí)我們?cè)贏WS上將供應(yīng)商返回的報(bào)文中無用屬性剔除，然后再根據(jù)業(yè)務(wù)屬性合并相關(guān)節(jié)點(diǎn)最后再壓縮返回，這樣就達(dá)到了縮減報(bào)文大小的目的(見圖3)。從目前運(yùn)行的數(shù)據(jù)上看，整個(gè)代理的帶寬流量只用到了之前的30%~40%。

圖3

公有云廠商普遍采用按流量收費(fèi)的價(jià)格策略，在設(shè)計(jì)網(wǎng)絡(luò)出入站網(wǎng)絡(luò)訪問的技術(shù)方案過程中，默認(rèn)情況下會(huì)使用AWS NAT網(wǎng)關(guān)，這樣網(wǎng)絡(luò)流量費(fèi)用相對(duì)較高?？紤]到酒店直連請(qǐng)求有個(gè)特性，通常情況下請(qǐng)求報(bào)文不到1K，而響應(yīng)報(bào)文平均有10k到100K，利用這個(gè)特點(diǎn)，我們?cè)贏WS上采用了基于EKS自建Squid代理方案（見圖4），這樣只有出站的請(qǐng)求報(bào)文會(huì)產(chǎn)生流量費(fèi)用，而大量入站的響應(yīng)報(bào)文不收費(fèi)，從而大大降低AWS上產(chǎn)生的網(wǎng)絡(luò)流量費(fèi)用。

圖4

2）降低網(wǎng)絡(luò)延遲，利用AWS全球數(shù)據(jù)中心對(duì)供應(yīng)商就近訪問

很多海外的供應(yīng)商服務(wù)部署在全球各地，而我們所有的海外訪問都統(tǒng)一從代理出去，這樣一些服務(wù)器部署較遠(yuǎn)的供應(yīng)商因?yàn)槲锢砭嚯x上的原因?qū)е戮W(wǎng)絡(luò)延遲很高。通過AWS的在全球各地的數(shù)據(jù)中心，我們可以將服務(wù)就近部署在供應(yīng)商機(jī)房附近，同時(shí)利用AWS的骨干網(wǎng)絡(luò)降低各數(shù)據(jù)中心到代理所在地附近的AWS數(shù)據(jù)中心的延遲，最后通過專線連接該AWS數(shù)據(jù)中心與攜程IDC（見圖5），整個(gè)過程對(duì)那些因物理距離對(duì)網(wǎng)絡(luò)延遲影響較大的供應(yīng)商性能提升較明顯，最多可降低50%的響應(yīng)時(shí)間。

圖5

4.2持續(xù)的架構(gòu)改造和性能及成本優(yōu)化

在目前的方案中，我們?yōu)榱松显茊为?dú)開發(fā)了一套全新的應(yīng)用，這樣帶來的問題就是，當(dāng)有業(yè)務(wù)變更時(shí)我們同時(shí)需要調(diào)整攜程IDC和AWS上部署的兩個(gè)應(yīng)用，提高了系統(tǒng)維護(hù)成本。主要原因是原應(yīng)用中大量依賴攜程的基礎(chǔ)組件，本次上云嘗試使用的是完全獨(dú)立的賬號(hào)和VPC網(wǎng)絡(luò)，如果在云上同樣部署一套不太現(xiàn)實(shí)，一是成本太大，二是一些敏感數(shù)據(jù)不能放在在云端存儲(chǔ)，所以后續(xù)我們會(huì)對(duì)適配器架構(gòu)再進(jìn)行優(yōu)化，在不依賴攜程基礎(chǔ)組件的情況下復(fù)用一套應(yīng)用以適應(yīng)不同的云環(huán)境。

業(yè)務(wù)上線后為了驗(yàn)證未來更大規(guī)模的負(fù)載上云的可能性，我們同時(shí)也在對(duì)性能，成本，高可用性方面做持續(xù)不斷的優(yōu)化

4.2.1利用云彈性伸縮能力

以計(jì)算資源成本為例：計(jì)算實(shí)例成本=實(shí)例運(yùn)行時(shí)長(zhǎng)*實(shí)例價(jià)格。如果只是簡(jiǎn)單粗暴把本地機(jī)房的運(yùn)行模式套用到云上計(jì)算，云服務(wù)計(jì)算資源的費(fèi)用是高于本地機(jī)房的。所以我們需要充分利用云上按需收費(fèi)的特性，減少閑置資源成本。實(shí)例的運(yùn)行時(shí)長(zhǎng)和Kubernetes集群內(nèi)的服務(wù)數(shù)量，以及分配給這些服務(wù)的計(jì)算資源成正比，同時(shí)服務(wù)的數(shù)量又是和流量成正比。

酒店直連業(yè)務(wù)場(chǎng)景存在不可預(yù)測(cè)的業(yè)務(wù)流量，比如臨近節(jié)假日頒布的旅游政策，或者營銷直播活動(dòng)。云原生的彈性特性很好地利用合理的資源應(yīng)對(duì)突發(fā)的流量。

Kubernetes的HPA彈性架構(gòu)會(huì)實(shí)時(shí)采集集群整體的負(fù)載指標(biāo)，判斷是否滿足彈性伸縮條件和執(zhí)行pod的伸縮。僅僅是pod的伸縮還不夠，我們還需要在集群中使用Cluster Autoscaler組件，監(jiān)控集群中由于資源分配不足無法被正常調(diào)度的pod，自動(dòng)從云平臺(tái)的實(shí)例池中申請(qǐng)?jiān)黾庸?jié)點(diǎn)，同時(shí)在流量下降的時(shí)候，Cluster Autoscaler組件也會(huì)檢測(cè)集群中資源利用率較低的節(jié)點(diǎn)，將其中的pod調(diào)度到其他可用節(jié)點(diǎn)上，回收這部分閑置節(jié)點(diǎn)。

彈性伸縮案例

云原生的彈性特性不僅幫助減少資源使用成本，也提高服務(wù)對(duì)基礎(chǔ)架構(gòu)故障的容錯(cuò)率，在基礎(chǔ)設(shè)施部分可用區(qū)中斷不可用期間，其他可用區(qū)域會(huì)增加相應(yīng)數(shù)量的節(jié)點(diǎn)繼續(xù)保持整個(gè)集群的可用。

Kubernetes支持對(duì)pod容器所需的CPU和內(nèi)存調(diào)整，找到一個(gè)合理的配額以合理的成本達(dá)到最佳的性能。所以我們?cè)诜?wù)上云前會(huì)做一些接近真實(shí)環(huán)境的負(fù)載測(cè)試，觀察業(yè)務(wù)流量的變化對(duì)集群性能的影響（業(yè)務(wù)周期性高峰和低峰的資源使用率，服務(wù)的資源瓶頸，合適的余量資源buffer應(yīng)對(duì)尖刺流量等等）。既不會(huì)因?yàn)閷?shí)際利用率過高導(dǎo)致穩(wěn)定性問題，比如OOM或者頻繁的CPU throttling，也不會(huì)因?yàn)檫^低浪費(fèi)資源（畢竟，即使你的應(yīng)用只使用了實(shí)例的1%，也要支付該實(shí)例100%的費(fèi)用）。

4.2.2采用公有云競(jìng)價(jià)實(shí)例

某些云平臺(tái)會(huì)把一些閑置計(jì)算資源作為競(jìng)價(jià)實(shí)例，以比按需實(shí)例更低的定價(jià)出租，顧名思義競(jìng)價(jià)實(shí)例的最終費(fèi)用是按市場(chǎng)供需出價(jià)決定的。按照我們實(shí)際使用的體驗(yàn)，如果不是特別熱門的機(jī)型定價(jià)基本在按需實(shí)例費(fèi)用的10-30%左右。低價(jià)的競(jìng)價(jià)實(shí)例自然有它的限制，云平臺(tái)會(huì)可能會(huì)調(diào)整競(jìng)價(jià)實(shí)例池的資源比例回收部分實(shí)例，一般回收的概率根據(jù)統(tǒng)計(jì)通常<3%,同時(shí)在回收前會(huì)提前2分鐘通知到這些實(shí)例。我們通過AWS提供的Terminal handler組件在收到回收通知后提前把容器調(diào)度到其他可用的實(shí)例上，減少了資源回收對(duì)服務(wù)的影響。下圖是某云對(duì)競(jìng)價(jià)實(shí)例的資源池劃分，我們可以看到，即使相同的實(shí)例資源，在不同的可用區(qū)也是獨(dú)立的資源池。

圖6

為了能最大限度減少競(jìng)價(jià)實(shí)例的中斷影響，包括實(shí)例在多可用區(qū)的再平衡影響，我們?cè)谕ㄟ^ASG（AWS auto scaling Group彈性擴(kuò)展組）選擇不同實(shí)例類型的情況下還將不同的實(shí)例資源池獨(dú)立使用ASG進(jìn)行管理，這樣保證了資源的最大利用效率。

圖7

攜程酒店直連使用按需實(shí)例和競(jìng)價(jià)實(shí)例的混合部署，保證低成本和高可用。一些系統(tǒng)關(guān)鍵組件（比如Cluster Autoscaler)，中斷就會(huì)丟失數(shù)據(jù)的有狀態(tài)服務(wù)（比如Prometheus）運(yùn)行在按需實(shí)例。而對(duì)錯(cuò)誤容忍度高，使用靈活無狀態(tài)的業(yè)務(wù)應(yīng)用運(yùn)行在競(jìng)價(jià)實(shí)例上。通過kubernetes的節(jié)點(diǎn)親和性控制不同類型的服務(wù)調(diào)度到對(duì)應(yīng)類型標(biāo)簽的實(shí)例上。（見圖8）

圖8

通過kubernates原生的HPA和ClusterAutoscaler組件結(jié)合AWS ASG及競(jìng)價(jià)資源的充分利用，可以將成本降低50%-80%。

4.2.3 DNS解析性能優(yōu)化

當(dāng)服務(wù)規(guī)模逐漸增大的時(shí)候，我們發(fā)現(xiàn)服務(wù)間的調(diào)用延時(shí)明顯上升，平均達(dá)到1.5S，高峰達(dá)到2.5秒，經(jīng)過分析發(fā)現(xiàn)，主要是因?yàn)镈NS解析負(fù)載過高造成的性能解析瓶頸，最終我們采用社區(qū)比較主流的localdns方式，對(duì)熱點(diǎn)解析域名做本地緩存，來降低對(duì)核心DNS頻繁的解析請(qǐng)求從而提高性能：

圖9

如圖9所示，在每個(gè)Node部署基于DaemonSet的NodeLocal DNSCache，通過Node LocalDNS緩解CoreDNS服務(wù)的DNS查詢壓力，LocalDNS Cache會(huì)監(jiān)聽所在的node上每個(gè)Client Pod的DNS解析請(qǐng)求，通過本地的解析行為配置，Local DNS Cache會(huì)嘗試先通過緩存解析請(qǐng)求，如果未命中則去CoreDNS查詢解析結(jié)果并緩存為下一次本地解析請(qǐng)求使用。

如下圖，通過使用LocalDNS方案我們將高峰的延時(shí)從2.5S降低到300ms，縮短了80%的響應(yīng)時(shí)間：

未使用LocalDNS前，平均響應(yīng)在1.5-2.5S。

未優(yōu)化前

使用LocalDNS方案后，響應(yīng)請(qǐng)求降低到300-400ms，延時(shí)優(yōu)化了80%。

優(yōu)化后

4.2.4公有云跨可用區(qū)流量?jī)?yōu)化

在使用競(jìng)價(jià)實(shí)例對(duì)資源進(jìn)行大幅優(yōu)化后，我們注意到跨可用區(qū)的流量在服務(wù)大幅擴(kuò)展后占比非常高（60%），這是因?yàn)樵诜?wù)之間調(diào)用時(shí)，我們將服務(wù)單元部署到不同可用區(qū)，最大限度提高服務(wù)的可用性，同時(shí)帶來的問題是服務(wù)間大量的流量交互帶來了跨可用區(qū)的流量費(fèi)用（見圖10）。

圖10

但是為了整個(gè)系統(tǒng)的高可用性，我們并不想將服務(wù)部署在單可用區(qū)，降低服務(wù)SLA。我們需要降低跨可用區(qū)流量的同時(shí)保證服務(wù)的高可用性。

經(jīng)過不同的方案調(diào)研最終我們使用AWS NLB來暴露服務(wù)，通過NLB的disable cross-az功能，對(duì)同可用區(qū)的上下游服務(wù)進(jìn)行流量可用區(qū)管控。同時(shí)使用之前提到的local dns組件，將上游服務(wù)訪問NLB不同可用區(qū)的域名解析進(jìn)行固化，保證了上下游的服務(wù)流量只能在可用區(qū)內(nèi)部進(jìn)行互通。改造后如下圖：

圖11

后段服務(wù)因?yàn)闀?huì)通過K8s的Kube-proxy進(jìn)行轉(zhuǎn)發(fā)造成跨可用區(qū)跨節(jié)點(diǎn)，我們選擇使用externalTrafficPolicy本地策略，將轉(zhuǎn)發(fā)流量固化在本地節(jié)點(diǎn)的服務(wù)上，但是同時(shí)本地轉(zhuǎn)發(fā)策略也帶來了一些問題（見圖12）：

圖12

如上圖所示，本地轉(zhuǎn)發(fā)策略可能因?yàn)楹蠖朔?wù)分布不均衡導(dǎo)致了流量黑洞和服務(wù)負(fù)載的不均衡，所以在這個(gè)基礎(chǔ)上，我們利用EKS彈性擴(kuò)展組策略對(duì)底層節(jié)點(diǎn)資源均衡分布到不同的可用區(qū)，同時(shí)利用K8s反親和性策略，將服務(wù)盡量分布到不同可用區(qū)的節(jié)點(diǎn)上，最大程度的保證了流量的均衡性，同時(shí)保證了服務(wù)的跨可用區(qū)部署的高可用性。

優(yōu)化后跨可用區(qū)流量降低了95.4%。（見圖13）

圖13

五、后續(xù)的優(yōu)化改進(jìn)方向

目前的架構(gòu)雖然解決了我們業(yè)務(wù)上的一些問題，但還是有一些不足之處可以改進(jìn)。為了可以就近訪問供應(yīng)商，我們使用了一個(gè)獨(dú)立的VPC網(wǎng)絡(luò)來部署和測(cè)試我們的集群，所以需要單獨(dú)在云端部署相關(guān)的存儲(chǔ)依賴以及日志監(jiān)控組件，這樣無疑增加了運(yùn)維的難度以及服務(wù)在不同云上的遷移難度。

在最新的架構(gòu)設(shè)計(jì)中針對(duì)這個(gè)問題我們計(jì)劃做如下改造，首先將需要在云端計(jì)算并且依賴持久化存儲(chǔ)數(shù)據(jù)的功能遷移回?cái)y程IDC，這樣這部分?jǐn)?shù)據(jù)就不用再傳到云端。其次因?yàn)楣驹贏WS的其他數(shù)據(jù)中心已經(jīng)有一套成熟的環(huán)境，所以我們只需要配合OPS打通兩個(gè)AWS數(shù)據(jù)中心之間的VPC網(wǎng)絡(luò)，便可使用公司的日志和監(jiān)控框架，減少運(yùn)維成本。

六、總結(jié)

本文通過攜程酒店直連在云原生的實(shí)踐，分享了如何快速在云上搭建一套穩(wěn)定高效的生產(chǎn)環(huán)境實(shí)現(xiàn)快速交付、智能彈性，以及在云上的一些成本優(yōu)化經(jīng)驗(yàn)。借助云原生體系實(shí)現(xiàn)了基礎(chǔ)設(shè)施自動(dòng)化，釋放一部分的運(yùn)維工作，可以更多地投入到業(yè)務(wù)迭代，更敏捷地響應(yīng)業(yè)務(wù)需求迭代，通過監(jiān)控和日志實(shí)現(xiàn)快速試錯(cuò)和反饋。希望借此能幫助到更多想上云的團(tuán)隊(duì)，少走彎路，擁抱云原生帶來的好處。