千億級攜程酒店AWS實(shí)踐
[導(dǎo)讀]作者簡介?微末，攜程軟件技術(shù)專家，關(guān)注系統(tǒng)架構(gòu)，致力于高可用高性能的支撐業(yè)務(wù)系統(tǒng)開發(fā)。一、背景隨著攜程海外酒店業(yè)務(wù)的發(fā)展，遍布全球的海外供應(yīng)商與攜程總部IDC之間的數(shù)據(jù)傳輸量快速增長。技術(shù)上，這種日益增長的數(shù)據(jù)量對跨境網(wǎng)絡(luò)專線的帶寬、延遲等提出了更高的要求；業(yè)務(wù)上，由于當(dāng)前有限的...
作者簡介
?微末，攜程軟件技術(shù)專家，關(guān)注系統(tǒng)架構(gòu)，致力于高可用高性能的支撐業(yè)務(wù)系統(tǒng)開發(fā)。
一、背景
隨著攜程海外酒店業(yè)務(wù)的發(fā)展，遍布全球的海外供應(yīng)商與攜程總部IDC之間的數(shù)據(jù)傳輸量快速增長。技術(shù)上，這種日益增長的數(shù)據(jù)量對跨境網(wǎng)絡(luò)專線的帶寬、延遲等提出了更高的要求；業(yè)務(wù)上，由于當(dāng)前有限的跨境網(wǎng)絡(luò)專線資源對業(yè)務(wù)處理效率及用戶體驗(yàn)也造成了一定的影響；成本上，跨境網(wǎng)絡(luò)專線作為一種昂貴的資源，通過單純的專線擴(kuò)容又會給IT成本造成巨大壓力。所以我們開始思考是否可以通過公有云結(jié)合酒店直連的業(yè)務(wù)特性來解決日益增長的帶寬壓力和供應(yīng)商接口延遲的問題。
酒店直連系統(tǒng)主要是使用自動化接口實(shí)現(xiàn)供應(yīng)商或集團(tuán)與攜程之間的系統(tǒng)對接，實(shí)現(xiàn)靜態(tài)信息、動態(tài)信息、訂單功能等都通過系統(tǒng)的方式流轉(zhuǎn)交互。目前攜程大量海外酒店業(yè)務(wù)是通過酒店直連系統(tǒng)對接。
本文將主要從攜程酒店直連服務(wù)遷移部署至AWS過程中所進(jìn)行的應(yīng)用架構(gòu)調(diào)整及云原生改造，使用AWS后取得的技術(shù)和業(yè)務(wù)收益，在部署過程中對EKS（Amazon Elastic Kubernates Service）、DNS查詢延時和跨AZ流量降低所做的成本優(yōu)化等幾方面進(jìn)行詳細(xì)介紹。
攜程酒店海外直連對接了上千家海外供應(yīng)商，所有的接口訪問都通過代理出去（見圖1），由于酒店直連的業(yè)務(wù)特性，當(dāng)一個用戶請求過來時會根據(jù)人數(shù)、國籍、會員非會員等裂變成多個請求，最多的時候可能一個請求會裂變成數(shù)十個請求，而且請求報(bào)文十分巨大（通常為幾十Kb到上百Kb不等），雖然我們可能只需要返回報(bào)文中的一小部分信息，但是因?yàn)槟壳凹軜?gòu)的限制只能將所有報(bào)文全部請求回來再處理，這無疑浪費(fèi)了大量的帶寬。 ?
圖1
同時因?yàn)楣?yīng)商遍布全球，所有的請求/響應(yīng)都需要經(jīng)過集團(tuán)的代理出口，導(dǎo)致了部分供應(yīng)商接口響應(yīng)受到物理距離的影響延遲變高了，會降低用戶的體驗(yàn)。
本次核心目標(biāo)之一是為了提高對接全球供應(yīng)商的網(wǎng)絡(luò)傳輸能力和延時改進(jìn)，提升用戶體驗(yàn)，必須選擇一個在全球有廣泛資源分布的云廠商幫助攜程盡量靠近供應(yīng)商訪問數(shù)據(jù)。經(jīng)過與多個公有云廠商的多輪交流，綜合考慮各廠商技術(shù)水平、服務(wù)能力、成本價(jià)格等多方面因素，我們認(rèn)為AWS無論是在全球覆蓋及網(wǎng)絡(luò)能力（見圖2）（AWS在全球分布的25個區(qū)域和80個可用區(qū)提供廣泛的服務(wù)能力，同時數(shù)據(jù)中心通過其骨干網(wǎng)互聯(lián)，提升了未來不同數(shù)據(jù)中心的數(shù)據(jù)互訪能力），云服務(wù)的先進(jìn)性和成熟度、現(xiàn)場團(tuán)隊(duì)的服務(wù)能力、響應(yīng)時間、專業(yè)水平都具有明顯的優(yōu)勢，最終我們選擇AWS作為資源部署的云廠商合作伙伴。
圖2
為了更好地與云上資源使用集成，我們采用IDC的容器化部署方案，最終考慮到托管容器平臺的高可用性設(shè)計(jì)及SLA保證，及對社區(qū)的兼容性，使用AWS托管容器平臺EKS作為部署的平臺。
資源方面我們對服務(wù)進(jìn)行改造后，大量使用競價(jià)實(shí)例作為EKS工作節(jié)點(diǎn)，大幅降低成本并提高效率。
同時利用公有云的網(wǎng)絡(luò)和平臺優(yōu)勢，將原本部署在攜程總部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á)到降低對跨境網(wǎng)絡(luò)專線的壓力、提升業(yè)務(wù)數(shù)據(jù)處理效率、降低成本、優(yōu)化用戶體驗(yàn)等目標(biāo)。?
為了充分的使用云服務(wù)帶來的便利和成本優(yōu)化，經(jīng)過調(diào)研分析，我們?nèi)绻苯訉?yīng)用遷移至公有云上，雖然業(yè)務(wù)上會產(chǎn)生相應(yīng)的價(jià)值，但成本會相對較高，因此我們對酒店直連服務(wù)進(jìn)行了相應(yīng)的云原生架構(gòu)優(yōu)化，相關(guān)的主要調(diào)整如下：
1 ）訪問供應(yīng)商模塊上云
要節(jié)省帶寬需要減少通過從代理出去的請求同時減少每個請求的報(bào)文大小。我們的做法是將請求拆分的邏輯搬到AWS上，這樣每次一個用戶請求過來通過代理出去只有一次請求/響應(yīng)。同時我們在AWS上將供應(yīng)商返回的報(bào)文中無用屬性剔除，然后再根據(jù)業(yè)務(wù)屬性合并相關(guān)節(jié)點(diǎn)最后再壓縮返回，這樣就達(dá)到了縮減報(bào)文大小的目的(見圖3)。從目前運(yùn)行的數(shù)據(jù)上看，整個代理的帶寬流量只用到了之前的30%~40%。
圖3
公有云廠商普遍采用按流量收費(fèi)的價(jià)格策略，在設(shè)計(jì)網(wǎng)絡(luò)出入站網(wǎng)絡(luò)訪問的技術(shù)方案過程中，默認(rèn)情況下會使用AWS NAT網(wǎng)關(guān)，這樣網(wǎng)絡(luò)流量費(fèi)用相對較高?？紤]到酒店直連請求有個特性，通常情況下請求報(bào)文不到1K，而響應(yīng)報(bào)文平均有10k到100K，利用這個特點(diǎn)，我們在AWS上采用了基于EKS自建Squid代理方案（見圖4），這樣只有出站的請求報(bào)文會產(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ù)中心對供應(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ī)房附近，同時利用AWS的骨干網(wǎng)絡(luò)降低各數(shù)據(jù)中心到代理所在地附近的AWS數(shù)據(jù)中心的延遲，最后通過專線連接該AWS數(shù)據(jù)中心與攜程IDC（見圖5），整個過程對那些因物理距離對網(wǎng)絡(luò)延遲影響較大的供應(yīng)商性能提升較明顯，最多可降低50%的響應(yīng)時間。
圖5
在目前的方案中，我們?yōu)榱松显茊为?dú)開發(fā)了一套全新的應(yīng)用，這樣帶來的問題就是，當(dāng)有業(yè)務(wù)變更時我們同時需要調(diào)整攜程IDC和AWS上部署的兩個應(yīng)用，提高了系統(tǒng)維護(hù)成本。主要原因是原應(yīng)用中大量依賴攜程的基礎(chǔ)組件，本次上云嘗試使用的是完全獨(dú)立的賬號和VPC網(wǎng)絡(luò)，如果在云上同樣部署一套不太現(xiàn)實(shí)，一是成本太大，二是一些敏感數(shù)據(jù)不能放在在云端存儲，所以后續(xù)我們會對適配器架構(gòu)再進(jìn)行優(yōu)化，在不依賴攜程基礎(chǔ)組件的情況下復(fù)用一套應(yīng)用以適應(yīng)不同的云環(huán)境。???????業(yè)務(wù)上線后為了驗(yàn)證未來更大規(guī)模的負(fù)載上云的可能性，我們同時也在對性能，成本，高可用性方面做持續(xù)不斷的優(yōu)化?
以計(jì)算資源成本為例：計(jì)算實(shí)例成本 = 實(shí)例運(yùn)行時長 * 實(shí)例價(jià)格。如果只是簡單粗暴把本地機(jī)房的運(yùn)行模式套用到云上計(jì)算，云服務(wù)計(jì)算資源的費(fèi)用是高于本地機(jī)房的。所以我們需要充分利用云上按需收費(fèi)的特性，減少閑置資源成本。實(shí)例的運(yùn)行時長和Kubernetes集群內(nèi)的服務(wù)數(shù)量，以及分配給這些服務(wù)的計(jì)算資源成正比，同時服務(wù)的數(shù)量又是和流量成正比。
酒店直連業(yè)務(wù)場景存在不可預(yù)測的業(yè)務(wù)流量，比如臨近節(jié)假日頒布的旅游政策，或者營銷直播活動。云原生的彈性特性很好地利用合理的資源應(yīng)對突發(fā)的流量。
Kubernetes的HPA彈性架構(gòu)會實(shí)時采集集群整體的負(fù)載指標(biāo)，判斷是否滿足彈性伸縮條件和執(zhí)行pod的伸縮。僅僅是pod的伸縮還不夠，我們還需要在集群中使用Cluster Autoscaler組件，監(jiān)控集群中由于資源分配不足無法被正常調(diào)度的pod，自動從云平臺的實(shí)例池中申請?jiān)黾庸?jié)點(diǎn)，同時在流量下降的時候，Cluster Autoscaler組件也會檢測集群中資源利用率較低的節(jié)點(diǎn)，將其中的pod調(diào)度到其他可用節(jié)點(diǎn)上，回收這部分閑置節(jié)點(diǎn)。?彈性伸縮案例
云原生的彈性特性不僅幫助減少資源使用成本，也提高服務(wù)對基礎(chǔ)架構(gòu)故障的容錯率，在基礎(chǔ)設(shè)施部分可用區(qū)中斷不可用期間，其他可用區(qū)域會增加相應(yīng)數(shù)量的節(jié)點(diǎn)繼續(xù)保持整個集群的可用。?Kubernetes支持對pod容器所需的CPU和內(nèi)存調(diào)整，找到一個合理的配額以合理的成本達(dá)到最佳的性能。所以我們在服務(wù)上云前會做一些接近真實(shí)環(huán)境的負(fù)載測試，觀察業(yè)務(wù)流量的變化對集群性能的影響（業(yè)務(wù)周期性高峰和低峰的資源使用率，服務(wù)的資源瓶頸，合適的余量資源buffer應(yīng)對尖刺流量等等）。既不會因?yàn)閷?shí)際利用率過高導(dǎo)致穩(wěn)定性問題，比如OOM或者頻繁的CPU throttling，也不會因?yàn)檫^低浪費(fèi)資源（畢竟，即使你的應(yīng)用只使用了實(shí)例的1%，也要支付該實(shí)例100%的費(fèi)用）。
某些云平臺會把一些閑置計(jì)算資源作為競價(jià)實(shí)例，以比按需實(shí)例更低的定價(jià)出租，顧名思義競價(jià)實(shí)例的最終費(fèi)用是按市場供需出價(jià)決定的。按照我們實(shí)際使用的體驗(yàn)，如果不是特別熱門的機(jī)型定價(jià)基本在按需實(shí)例費(fèi)用的10-30%左右。低價(jià)的競價(jià)實(shí)例自然有它的限制，云平臺會可能會調(diào)整競價(jià)實(shí)例池的資源比例回收部分實(shí)例，一般回收的概率根據(jù)統(tǒng)計(jì)通常<3%, 同時在回收前會提前2分鐘通知到這些實(shí)例。我們通過AWS提供的Terminal handler組件在收到回收通知后提前把容器調(diào)度到其他可用的實(shí)例上，減少了資源回收對服務(wù)的影響。下圖是某云對競價(jià)實(shí)例的資源池劃分，我們可以看到，即使相同的實(shí)例資源，在不同的可用區(qū)也是獨(dú)立的資源池。
圖6
為了能最大限度減少競價(jià)實(shí)例的中斷影響，包括實(shí)例在多可用區(qū)的再平衡影響，我們在通過ASG（AWS auto scaling Group 彈性擴(kuò)展組）選擇不同實(shí)例類型的情況下還將不同的實(shí)例資源池獨(dú)立使用ASG進(jìn)行管理，這樣保證了資源的最大利用效率。
圖7
攜程酒店直連使用按需實(shí)例和競價(jià)實(shí)例的混合部署，保證低成本和高可用。一些系統(tǒng)關(guān)鍵組件（比如Cluster Autoscaler)，中斷就會丟失數(shù)據(jù)的有狀態(tài)服務(wù)（比如Prometheus）運(yùn)行在按需實(shí)例。而對錯誤容忍度高，使用靈活無狀態(tài)的業(yè)務(wù)應(yīng)用運(yùn)行在競價(jià)實(shí)例上。通過kubernetes的節(jié)點(diǎn)親和性控制不同類型的服務(wù)調(diào)度到對應(yīng)類型標(biāo)簽的實(shí)例上。（見圖8）
圖8
通過 kubernates 原生的 HPA 和 ClusterAutoscaler 組件結(jié)合 AWS ASG 及競價(jià)資源的充分利用，可以將成本降低50%-80%。
當(dāng)服務(wù)規(guī)模逐漸增大的時候，我們發(fā)現(xiàn)服務(wù)間的調(diào)用延時明顯上升，平均達(dá)到1.5S，高峰達(dá)到2.5秒，經(jīng)過分析發(fā)現(xiàn)，主要是因?yàn)?DNS 解析負(fù)載過高造成的性能解析瓶頸，最終我們采用社區(qū)比較主流的 localdns 方式，對熱點(diǎn)解析域名做本地緩存，來降低對核心 DNS 頻繁的解析請求從而提高性能：
圖9
如圖9所示，在每個Node部署基于DaemonSet的NodeLocal DNSCache，通過Node LocalDNS緩解CoreDNS服務(wù)的DNS查詢壓力，LocalDNS Cache 會監(jiān)聽所在的 node上每個 Client Pod 的 DNS 解析請求，通過本地的解析行為配置，Local DNS Cache 會嘗試先通過緩存解析請求，如果未命中則去 CoreDNS 查詢解析結(jié)果并緩存為下一次本地解析請求使用。
如下圖，通過使用 LocalDNS 方案我們將高峰的延時從 2.5S 降低到 300ms，縮短了80%的響應(yīng)時間：
未使用LocalDNS前，平均響應(yīng)在1.5-2.5S。
未優(yōu)化前
使用LocalDNS 方案后，響應(yīng)請求降低到300-400ms，延時優(yōu)化了80%。
優(yōu)化后
在使用競價(jià)實(shí)例對資源進(jìn)行大幅優(yōu)化后，我們注意到跨可用區(qū)的流量在服務(wù)大幅擴(kuò)展后占比非常高（60%），這是因?yàn)樵诜?wù)之間調(diào)用時，我們將服務(wù)單元部署到不同可用區(qū)，最大限度提高服務(wù)的可用性，同時帶來的問題是服務(wù)間大量的流量交互帶來了跨可用區(qū)的流量費(fèi)用（見圖10）。
圖10
但是為了整個系統(tǒng)的高可用性，我們并不想將服務(wù)部署在單可用區(qū)，降低服務(wù)SLA。我們需要降低跨可用區(qū)流量的同時保證服務(wù)的高可用性。
經(jīng)過不同的方案調(diào)研最終我們使用 AWS NLB 來暴露服務(wù)，通過 NLB 的 disable cross-az 功能，對同可用區(qū)的上下游服務(wù)進(jìn)行流量可用區(qū)管控。同時使用之前提到的 local dns 組件，將上游服務(wù)訪問NLB不同可用區(qū)的域名解析進(jìn)行固化，保證了上下游的服務(wù)流量只能在可用區(qū)內(nèi)部進(jìn)行互通。改造后如下圖：
圖11
后段服務(wù)因?yàn)闀ㄟ^ K8s 的 Kube-proxy 進(jìn)行轉(zhuǎn)發(fā)造成跨可用區(qū)跨節(jié)點(diǎn)，我們選擇使用 externalTrafficPolicy 本地策略，將轉(zhuǎn)發(fā)流量固化在本地節(jié)點(diǎn)的服務(wù)上，但是同時本地轉(zhuǎn)發(fā)策略也帶來了一些問題（見圖12）：
圖12
如上圖所示，本地轉(zhuǎn)發(fā)策略可能因?yàn)楹蠖朔?wù)分布不均衡導(dǎo)致了流量黑洞和服務(wù)負(fù)載的不均衡，所以在這個基礎(chǔ)上，我們利用 EKS 彈性擴(kuò)展組策略對底層節(jié)點(diǎn)資源均衡分布到不同的可用區(qū)，同時利用 K8s 反親和性策略，將服務(wù)盡量分布到不同可用區(qū)的節(jié)點(diǎn)上，最大程度的保證了流量的均衡性，同時保證了服務(wù)的跨可用區(qū)部署的高可用性。?優(yōu)化后跨可用區(qū)流量降低了95.4%。（見圖13）?圖13
目前的架構(gòu)雖然解決了我們業(yè)務(wù)上的一些問題，但還是有一些不足之處可以改進(jìn)。為了可以就近訪問供應(yīng)商，我們使用了一個獨(dú)立的VPC網(wǎng)絡(luò)來部署和測試我們的集群，所以需要單獨(dú)在云端部署相關(guān)的存儲依賴以及日志監(jiān)控組件，這樣無疑增加了運(yùn)維的難度以及服務(wù)在不同云上的遷移難度。
在最新的架構(gòu)設(shè)計(jì)中針對這個問題我們計(jì)劃做如下改造，首先將需要在云端計(jì)算并且依賴持久化存儲數(shù)據(jù)的功能遷移回?cái)y程IDC，這樣這部分?jǐn)?shù)據(jù)就不用再傳到云端。其次因?yàn)楣驹贏WS的其他數(shù)據(jù)中心已經(jīng)有一套成熟的環(huán)境，所以我們只需要配合OPS打通兩個AWS數(shù)據(jù)中心之間的VPC網(wǎng)絡(luò)，便可使用公司的日志和監(jiān)控框架，減少運(yùn)維成本。?
本文通過攜程酒店直連在云原生的實(shí)踐，分享了如何快速在云上搭建一套穩(wěn)定高效的生產(chǎn)環(huán)境實(shí)現(xiàn)快速交付、智能彈性，以及在云上的一些成本優(yōu)化經(jīng)驗(yàn)。借助云原生體系實(shí)現(xiàn)了基礎(chǔ)設(shè)施自動化，釋放一部分的運(yùn)維工作，可以更多地投入到業(yè)務(wù)迭代，更敏捷地響應(yīng)業(yè)務(wù)需求迭代，通過監(jiān)控和日志實(shí)現(xiàn)快速試錯和反饋。希望借此能幫助到更多想上云的團(tuán)隊(duì)，少走彎路，擁抱云原生帶來的好處。
?微末，攜程軟件技術(shù)專家，關(guān)注系統(tǒng)架構(gòu)，致力于高可用高性能的支撐業(yè)務(wù)系統(tǒng)開發(fā)。
一、背景
隨著攜程海外酒店業(yè)務(wù)的發(fā)展，遍布全球的海外供應(yīng)商與攜程總部IDC之間的數(shù)據(jù)傳輸量快速增長。技術(shù)上，這種日益增長的數(shù)據(jù)量對跨境網(wǎng)絡(luò)專線的帶寬、延遲等提出了更高的要求；業(yè)務(wù)上，由于當(dāng)前有限的跨境網(wǎng)絡(luò)專線資源對業(yè)務(wù)處理效率及用戶體驗(yàn)也造成了一定的影響；成本上，跨境網(wǎng)絡(luò)專線作為一種昂貴的資源，通過單純的專線擴(kuò)容又會給IT成本造成巨大壓力。所以我們開始思考是否可以通過公有云結(jié)合酒店直連的業(yè)務(wù)特性來解決日益增長的帶寬壓力和供應(yīng)商接口延遲的問題。
酒店直連系統(tǒng)主要是使用自動化接口實(shí)現(xiàn)供應(yīng)商或集團(tuán)與攜程之間的系統(tǒng)對接，實(shí)現(xiàn)靜態(tài)信息、動態(tài)信息、訂單功能等都通過系統(tǒng)的方式流轉(zhuǎn)交互。目前攜程大量海外酒店業(yè)務(wù)是通過酒店直連系統(tǒng)對接。
本文將主要從攜程酒店直連服務(wù)遷移部署至AWS過程中所進(jìn)行的應(yīng)用架構(gòu)調(diào)整及云原生改造，使用AWS后取得的技術(shù)和業(yè)務(wù)收益，在部署過程中對EKS（Amazon Elastic Kubernates Service）、DNS查詢延時和跨AZ流量降低所做的成本優(yōu)化等幾方面進(jìn)行詳細(xì)介紹。
二、痛點(diǎn)
攜程酒店海外直連對接了上千家海外供應(yīng)商，所有的接口訪問都通過代理出去（見圖1），由于酒店直連的業(yè)務(wù)特性，當(dāng)一個用戶請求過來時會根據(jù)人數(shù)、國籍、會員非會員等裂變成多個請求，最多的時候可能一個請求會裂變成數(shù)十個請求，而且請求報(bào)文十分巨大（通常為幾十Kb到上百Kb不等），雖然我們可能只需要返回報(bào)文中的一小部分信息，但是因?yàn)槟壳凹軜?gòu)的限制只能將所有報(bào)文全部請求回來再處理，這無疑浪費(fèi)了大量的帶寬。 ?
圖1同時因?yàn)楣?yīng)商遍布全球，所有的請求/響應(yīng)都需要經(jīng)過集團(tuán)的代理出口，導(dǎo)致了部分供應(yīng)商接口響應(yīng)受到物理距離的影響延遲變高了，會降低用戶的體驗(yàn)。
三、云服務(wù)選擇及初步方案
本次核心目標(biāo)之一是為了提高對接全球供應(yīng)商的網(wǎng)絡(luò)傳輸能力和延時改進(jìn)，提升用戶體驗(yàn)，必須選擇一個在全球有廣泛資源分布的云廠商幫助攜程盡量靠近供應(yīng)商訪問數(shù)據(jù)。經(jīng)過與多個公有云廠商的多輪交流，綜合考慮各廠商技術(shù)水平、服務(wù)能力、成本價(jià)格等多方面因素，我們認(rèn)為AWS無論是在全球覆蓋及網(wǎng)絡(luò)能力（見圖2）（AWS在全球分布的25個區(qū)域和80個可用區(qū)提供廣泛的服務(wù)能力，同時數(shù)據(jù)中心通過其骨干網(wǎng)互聯(lián)，提升了未來不同數(shù)據(jù)中心的數(shù)據(jù)互訪能力），云服務(wù)的先進(jìn)性和成熟度、現(xiàn)場團(tuán)隊(duì)的服務(wù)能力、響應(yīng)時間、專業(yè)水平都具有明顯的優(yōu)勢，最終我們選擇AWS作為資源部署的云廠商合作伙伴。
圖2為了更好地與云上資源使用集成，我們采用IDC的容器化部署方案，最終考慮到托管容器平臺的高可用性設(shè)計(jì)及SLA保證，及對社區(qū)的兼容性，使用AWS托管容器平臺EKS作為部署的平臺。
資源方面我們對服務(wù)進(jìn)行改造后，大量使用競價(jià)實(shí)例作為EKS工作節(jié)點(diǎn)，大幅降低成本并提高效率。
同時利用公有云的網(wǎng)絡(luò)和平臺優(yōu)勢，將原本部署在攜程總部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á)到降低對跨境網(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ù)上會產(chǎn)生相應(yīng)的價(jià)值，但成本會相對較高，因此我們對酒店直連服務(wù)進(jìn)行了相應(yīng)的云原生架構(gòu)優(yōu)化，相關(guān)的主要調(diào)整如下：
1 ）訪問供應(yīng)商模塊上云
要節(jié)省帶寬需要減少通過從代理出去的請求同時減少每個請求的報(bào)文大小。我們的做法是將請求拆分的邏輯搬到AWS上，這樣每次一個用戶請求過來通過代理出去只有一次請求/響應(yīng)。同時我們在AWS上將供應(yīng)商返回的報(bào)文中無用屬性剔除，然后再根據(jù)業(yè)務(wù)屬性合并相關(guān)節(jié)點(diǎn)最后再壓縮返回，這樣就達(dá)到了縮減報(bào)文大小的目的(見圖3)。從目前運(yùn)行的數(shù)據(jù)上看，整個代理的帶寬流量只用到了之前的30%~40%。
圖3公有云廠商普遍采用按流量收費(fèi)的價(jià)格策略，在設(shè)計(jì)網(wǎng)絡(luò)出入站網(wǎng)絡(luò)訪問的技術(shù)方案過程中，默認(rèn)情況下會使用AWS NAT網(wǎng)關(guān)，這樣網(wǎng)絡(luò)流量費(fèi)用相對較高?？紤]到酒店直連請求有個特性，通常情況下請求報(bào)文不到1K，而響應(yīng)報(bào)文平均有10k到100K，利用這個特點(diǎn)，我們在AWS上采用了基于EKS自建Squid代理方案（見圖4），這樣只有出站的請求報(bào)文會產(chǎn)生流量費(fèi)用，而大量入站的響應(yīng)報(bào)文不收費(fèi)，從而大大降低AWS上產(chǎn)生的網(wǎng)絡(luò)流量費(fèi)用。
圖42）降低網(wǎng)絡(luò)延遲，利用AWS全球數(shù)據(jù)中心對供應(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ī)房附近，同時利用AWS的骨干網(wǎng)絡(luò)降低各數(shù)據(jù)中心到代理所在地附近的AWS數(shù)據(jù)中心的延遲，最后通過專線連接該AWS數(shù)據(jù)中心與攜程IDC（見圖5），整個過程對那些因物理距離對網(wǎng)絡(luò)延遲影響較大的供應(yīng)商性能提升較明顯，最多可降低50%的響應(yīng)時間。
圖54.2 持續(xù)的架構(gòu)改造和性能及成本優(yōu)化
在目前的方案中，我們?yōu)榱松显茊为?dú)開發(fā)了一套全新的應(yīng)用，這樣帶來的問題就是，當(dāng)有業(yè)務(wù)變更時我們同時需要調(diào)整攜程IDC和AWS上部署的兩個應(yīng)用，提高了系統(tǒng)維護(hù)成本。主要原因是原應(yīng)用中大量依賴攜程的基礎(chǔ)組件，本次上云嘗試使用的是完全獨(dú)立的賬號和VPC網(wǎng)絡(luò)，如果在云上同樣部署一套不太現(xiàn)實(shí)，一是成本太大，二是一些敏感數(shù)據(jù)不能放在在云端存儲，所以后續(xù)我們會對適配器架構(gòu)再進(jìn)行優(yōu)化，在不依賴攜程基礎(chǔ)組件的情況下復(fù)用一套應(yīng)用以適應(yīng)不同的云環(huán)境。???????業(yè)務(wù)上線后為了驗(yàn)證未來更大規(guī)模的負(fù)載上云的可能性，我們同時也在對性能，成本，高可用性方面做持續(xù)不斷的優(yōu)化?
4.2.1 利用云彈性伸縮能力
以計(jì)算資源成本為例：計(jì)算實(shí)例成本 = 實(shí)例運(yùn)行時長 * 實(shí)例價(jià)格。如果只是簡單粗暴把本地機(jī)房的運(yùn)行模式套用到云上計(jì)算，云服務(wù)計(jì)算資源的費(fèi)用是高于本地機(jī)房的。所以我們需要充分利用云上按需收費(fèi)的特性，減少閑置資源成本。實(shí)例的運(yùn)行時長和Kubernetes集群內(nèi)的服務(wù)數(shù)量，以及分配給這些服務(wù)的計(jì)算資源成正比，同時服務(wù)的數(shù)量又是和流量成正比。
酒店直連業(yè)務(wù)場景存在不可預(yù)測的業(yè)務(wù)流量，比如臨近節(jié)假日頒布的旅游政策，或者營銷直播活動。云原生的彈性特性很好地利用合理的資源應(yīng)對突發(fā)的流量。
Kubernetes的HPA彈性架構(gòu)會實(shí)時采集集群整體的負(fù)載指標(biāo)，判斷是否滿足彈性伸縮條件和執(zhí)行pod的伸縮。僅僅是pod的伸縮還不夠，我們還需要在集群中使用Cluster Autoscaler組件，監(jiān)控集群中由于資源分配不足無法被正常調(diào)度的pod，自動從云平臺的實(shí)例池中申請?jiān)黾庸?jié)點(diǎn)，同時在流量下降的時候，Cluster Autoscaler組件也會檢測集群中資源利用率較低的節(jié)點(diǎn)，將其中的pod調(diào)度到其他可用節(jié)點(diǎn)上，回收這部分閑置節(jié)點(diǎn)。?
彈性伸縮案例云原生的彈性特性不僅幫助減少資源使用成本，也提高服務(wù)對基礎(chǔ)架構(gòu)故障的容錯率，在基礎(chǔ)設(shè)施部分可用區(qū)中斷不可用期間，其他可用區(qū)域會增加相應(yīng)數(shù)量的節(jié)點(diǎn)繼續(xù)保持整個集群的可用。?Kubernetes支持對pod容器所需的CPU和內(nèi)存調(diào)整，找到一個合理的配額以合理的成本達(dá)到最佳的性能。所以我們在服務(wù)上云前會做一些接近真實(shí)環(huán)境的負(fù)載測試，觀察業(yè)務(wù)流量的變化對集群性能的影響（業(yè)務(wù)周期性高峰和低峰的資源使用率，服務(wù)的資源瓶頸，合適的余量資源buffer應(yīng)對尖刺流量等等）。既不會因?yàn)閷?shí)際利用率過高導(dǎo)致穩(wěn)定性問題，比如OOM或者頻繁的CPU throttling，也不會因?yàn)檫^低浪費(fèi)資源（畢竟，即使你的應(yīng)用只使用了實(shí)例的1%，也要支付該實(shí)例100%的費(fèi)用）。
4.2.2 采用公有云競價(jià)實(shí)例
某些云平臺會把一些閑置計(jì)算資源作為競價(jià)實(shí)例，以比按需實(shí)例更低的定價(jià)出租，顧名思義競價(jià)實(shí)例的最終費(fèi)用是按市場供需出價(jià)決定的。按照我們實(shí)際使用的體驗(yàn)，如果不是特別熱門的機(jī)型定價(jià)基本在按需實(shí)例費(fèi)用的10-30%左右。低價(jià)的競價(jià)實(shí)例自然有它的限制，云平臺會可能會調(diào)整競價(jià)實(shí)例池的資源比例回收部分實(shí)例，一般回收的概率根據(jù)統(tǒng)計(jì)通常<3%, 同時在回收前會提前2分鐘通知到這些實(shí)例。我們通過AWS提供的Terminal handler組件在收到回收通知后提前把容器調(diào)度到其他可用的實(shí)例上，減少了資源回收對服務(wù)的影響。下圖是某云對競價(jià)實(shí)例的資源池劃分，我們可以看到，即使相同的實(shí)例資源，在不同的可用區(qū)也是獨(dú)立的資源池。
圖6為了能最大限度減少競價(jià)實(shí)例的中斷影響，包括實(shí)例在多可用區(qū)的再平衡影響，我們在通過ASG（AWS auto scaling Group 彈性擴(kuò)展組）選擇不同實(shí)例類型的情況下還將不同的實(shí)例資源池獨(dú)立使用ASG進(jìn)行管理，這樣保證了資源的最大利用效率。
圖7攜程酒店直連使用按需實(shí)例和競價(jià)實(shí)例的混合部署，保證低成本和高可用。一些系統(tǒng)關(guān)鍵組件（比如Cluster Autoscaler)，中斷就會丟失數(shù)據(jù)的有狀態(tài)服務(wù)（比如Prometheus）運(yùn)行在按需實(shí)例。而對錯誤容忍度高，使用靈活無狀態(tài)的業(yè)務(wù)應(yīng)用運(yùn)行在競價(jià)實(shí)例上。通過kubernetes的節(jié)點(diǎn)親和性控制不同類型的服務(wù)調(diào)度到對應(yīng)類型標(biāo)簽的實(shí)例上。（見圖8）
圖8通過 kubernates 原生的 HPA 和 ClusterAutoscaler 組件結(jié)合 AWS ASG 及競價(jià)資源的充分利用，可以將成本降低50%-80%。
4.2.3 DNS 解析性能優(yōu)化
當(dāng)服務(wù)規(guī)模逐漸增大的時候，我們發(fā)現(xiàn)服務(wù)間的調(diào)用延時明顯上升，平均達(dá)到1.5S，高峰達(dá)到2.5秒，經(jīng)過分析發(fā)現(xiàn)，主要是因?yàn)?DNS 解析負(fù)載過高造成的性能解析瓶頸，最終我們采用社區(qū)比較主流的 localdns 方式，對熱點(diǎn)解析域名做本地緩存，來降低對核心 DNS 頻繁的解析請求從而提高性能：
圖9如圖9所示，在每個Node部署基于DaemonSet的NodeLocal DNSCache，通過Node LocalDNS緩解CoreDNS服務(wù)的DNS查詢壓力，LocalDNS Cache 會監(jiān)聽所在的 node上每個 Client Pod 的 DNS 解析請求，通過本地的解析行為配置，Local DNS Cache 會嘗試先通過緩存解析請求，如果未命中則去 CoreDNS 查詢解析結(jié)果并緩存為下一次本地解析請求使用。
如下圖，通過使用 LocalDNS 方案我們將高峰的延時從 2.5S 降低到 300ms，縮短了80%的響應(yīng)時間：
未使用LocalDNS前，平均響應(yīng)在1.5-2.5S。
未優(yōu)化前使用LocalDNS 方案后，響應(yīng)請求降低到300-400ms，延時優(yōu)化了80%。
優(yōu)化后4.2.4 公有云跨可用區(qū)流量優(yōu)化
在使用競價(jià)實(shí)例對資源進(jìn)行大幅優(yōu)化后，我們注意到跨可用區(qū)的流量在服務(wù)大幅擴(kuò)展后占比非常高（60%），這是因?yàn)樵诜?wù)之間調(diào)用時，我們將服務(wù)單元部署到不同可用區(qū)，最大限度提高服務(wù)的可用性，同時帶來的問題是服務(wù)間大量的流量交互帶來了跨可用區(qū)的流量費(fèi)用（見圖10）。
圖10但是為了整個系統(tǒng)的高可用性，我們并不想將服務(wù)部署在單可用區(qū)，降低服務(wù)SLA。我們需要降低跨可用區(qū)流量的同時保證服務(wù)的高可用性。
經(jīng)過不同的方案調(diào)研最終我們使用 AWS NLB 來暴露服務(wù)，通過 NLB 的 disable cross-az 功能，對同可用區(qū)的上下游服務(wù)進(jìn)行流量可用區(qū)管控。同時使用之前提到的 local dns 組件，將上游服務(wù)訪問NLB不同可用區(qū)的域名解析進(jìn)行固化，保證了上下游的服務(wù)流量只能在可用區(qū)內(nèi)部進(jìn)行互通。改造后如下圖：
圖11后段服務(wù)因?yàn)闀ㄟ^ K8s 的 Kube-proxy 進(jìn)行轉(zhuǎn)發(fā)造成跨可用區(qū)跨節(jié)點(diǎn)，我們選擇使用 externalTrafficPolicy 本地策略，將轉(zhuǎn)發(fā)流量固化在本地節(jié)點(diǎn)的服務(wù)上，但是同時本地轉(zhuǎn)發(fā)策略也帶來了一些問題（見圖12）：
圖12如上圖所示，本地轉(zhuǎn)發(fā)策略可能因?yàn)楹蠖朔?wù)分布不均衡導(dǎo)致了流量黑洞和服務(wù)負(fù)載的不均衡，所以在這個基礎(chǔ)上，我們利用 EKS 彈性擴(kuò)展組策略對底層節(jié)點(diǎn)資源均衡分布到不同的可用區(qū)，同時利用 K8s 反親和性策略，將服務(wù)盡量分布到不同可用區(qū)的節(jié)點(diǎn)上，最大程度的保證了流量的均衡性，同時保證了服務(wù)的跨可用區(qū)部署的高可用性。?優(yōu)化后跨可用區(qū)流量降低了95.4%。（見圖13）?
圖13五、后續(xù)的優(yōu)化改進(jìn)方向
目前的架構(gòu)雖然解決了我們業(yè)務(wù)上的一些問題，但還是有一些不足之處可以改進(jìn)。為了可以就近訪問供應(yīng)商，我們使用了一個獨(dú)立的VPC網(wǎng)絡(luò)來部署和測試我們的集群，所以需要單獨(dú)在云端部署相關(guān)的存儲依賴以及日志監(jiān)控組件，這樣無疑增加了運(yùn)維的難度以及服務(wù)在不同云上的遷移難度。
在最新的架構(gòu)設(shè)計(jì)中針對這個問題我們計(jì)劃做如下改造，首先將需要在云端計(jì)算并且依賴持久化存儲數(shù)據(jù)的功能遷移回?cái)y程IDC，這樣這部分?jǐn)?shù)據(jù)就不用再傳到云端。其次因?yàn)楣驹贏WS的其他數(shù)據(jù)中心已經(jīng)有一套成熟的環(huán)境，所以我們只需要配合OPS打通兩個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è)施自動化，釋放一部分的運(yùn)維工作，可以更多地投入到業(yè)務(wù)迭代，更敏捷地響應(yīng)業(yè)務(wù)需求迭代，通過監(jiān)控和日志實(shí)現(xiàn)快速試錯和反饋。希望借此能幫助到更多想上云的團(tuán)隊(duì)，少走彎路，擁抱云原生帶來的好處。
下載文檔
