?作者｜Harry，攜程資深后端開發(fā)工程師，負(fù)責(zé)直連平臺建設(shè)，關(guān)注系統(tǒng)高可用、數(shù)據(jù)驅(qū)動等領(lǐng)域。

一、前言

攜程門票活動供應(yīng)商直連平臺（以下簡稱“直連平臺”）通過API對接多個供應(yīng)商的訂單和商品系統(tǒng)，實現(xiàn)自動化信息同步和狀態(tài)流轉(zhuǎn)。

隨著業(yè)務(wù)的高速發(fā)展，供應(yīng)商的對接需求與日俱增，這不僅對直連平臺接入供應(yīng)商的上線效率提出更高的要求，同時供應(yīng)商系統(tǒng)的物理網(wǎng)絡(luò)限制、穩(wěn)定性參差不齊等情況也給直連平臺帶來不小的挑戰(zhàn)。

本文將從提高供應(yīng)商接入效率和增強系統(tǒng)穩(wěn)定性兩個方面分享直連平臺的實踐經(jīng)驗。

二、背景

2.1 系統(tǒng)介紹

直連平臺作為供應(yīng)商與攜程內(nèi)部系統(tǒng)的適配層，主要支持兩條通路：一是同步供應(yīng)商的商品信息到商品系統(tǒng)，如價格、庫存、內(nèi)容等；二是同步訂單信息，如訂單狀態(tài)、憑證信息等。直連平臺針對不同供應(yīng)商提供對應(yīng)的適配邏輯，以匹配訂單系統(tǒng)和商品系統(tǒng)的接口。開放平臺為供應(yīng)商提供方便快速接入的OpenApi和沙箱工具。

圖1 直連平臺系統(tǒng)介紹

2.2 挑戰(zhàn)

隨著供應(yīng)商接入需求越來越多，不同供應(yīng)商系統(tǒng)之間的差異也愈加明顯，在供應(yīng)商上線效率和系統(tǒng)穩(wěn)定性上帶來新的挑戰(zhàn)。

2.2.1 效率

大量供應(yīng)商通過OpenApi接入平臺。每家供應(yīng)商在上線前，平臺需要投入約2人日的聯(lián)調(diào)和驗收。當(dāng)接入中的供應(yīng)商數(shù)量越來越多時，直連平臺需要排期對供應(yīng)商進行逐個處理，延長了供應(yīng)商的上線周期，影響上線效率。

2.2.2 穩(wěn)定性

不同供應(yīng)商系統(tǒng)的物理網(wǎng)絡(luò)、系統(tǒng)軟件之間往往存在差異，承載能力不一。當(dāng)直連平臺的訂單流量超過供應(yīng)商系統(tǒng)的承載能力時，會造成其系統(tǒng)不穩(wěn)定，甚至引起長時間系統(tǒng)故障，影響平臺出票。對于已有限流策略的供應(yīng)商，如果直連平臺的QPS過大時，請求也會被其直接攔截，故需要平臺適配不同供應(yīng)商的承載能力。

當(dāng)供應(yīng)商系統(tǒng)出現(xiàn)停機升級、宕機或網(wǎng)絡(luò)異常等情況，平臺會產(chǎn)生大量異?；虺瑫r的訂單，造成大量客人支付后退訂，嚴(yán)重影響下單的對接成功率。供應(yīng)商系統(tǒng)異常后，由人工介入處理，雖能在一定程度緩解該問題，但仍會出現(xiàn)費力度高和介入不及時等問題。

由于各供應(yīng)商返回的錯誤信息不一致，平臺難以根據(jù)失敗原因進行預(yù)警或系統(tǒng)干預(yù)。

三、實踐

直連平臺學(xué)習(xí)借鑒行業(yè)通用方案，并結(jié)合平臺實際情況，在提升效率和提高穩(wěn)定性方面做了如下實踐。

3.1 提升效率

供應(yīng)商和直連平臺均對OpenApi的測試環(huán)節(jié)有提升效率和降低成本的訴求，直連平臺希望提供一個方便供應(yīng)商自測，且能保證測試質(zhì)量的工具。

3.1.1 方案

沙箱能對供應(yīng)商提供自助測試的支持，可以節(jié)省人力和提高供應(yīng)商上線效率，同時也能保護直連平臺正式環(huán)境不受干擾，所以是開放平臺的首選。

在網(wǎng)絡(luò)安全方面，沙箱指在隔離環(huán)境中，用以測試不受信任的文件或應(yīng)用程序等行為的工具。不明程序讓它在沙箱內(nèi)運行，程序無權(quán)修改沙箱外的程序及系統(tǒng)設(shè)置，保障了系統(tǒng)不會遭到惡意軟件及病毒的篡改和入侵。

一般開放平臺中的沙箱，僅能測試單個接口和顯示接口日志。和同行業(yè)的其他沙箱相比，本文介紹的沙箱（以下簡稱“平臺沙箱”）還支持測試業(yè)務(wù)場景、自動驗收上線等功能，在提高上線效率的同時，還能提高對接質(zhì)量。

圖2  平臺沙箱 vs 其他沙箱

3.1.2 平臺沙箱簡介

為了給供應(yīng)商提供靈活易用的自助測試工具，平臺沙箱支持供應(yīng)商根據(jù)自身系統(tǒng)參數(shù)和業(yè)務(wù)類型進行相關(guān)配置。供應(yīng)商在提交測試任務(wù)后，平臺沙箱結(jié)合供應(yīng)商配置和測試用例的匹配策略，從測試用例池中匹配所需的測試用例。測試用例的處理支持自動化，即便對于需要供應(yīng)商主動推送通知的用例，平臺沙箱也支持?jǐn)帱c執(zhí)行。平臺沙箱接收到供應(yīng)商推送的正確報文后繼續(xù)完成后續(xù)測試任務(wù)，整個過程無需平臺人工干預(yù)。全部用例執(zhí)行成功后，即達到平臺沙箱驗收標(biāo)準(zhǔn)，系統(tǒng)將自動上線。

圖3  平臺沙箱處理流程

為了實現(xiàn)平臺沙箱的全自動化，直連平臺需要重點考慮以下4個核心環(huán)節(jié)：

圖4  平臺沙箱核心環(huán)節(jié)

3.1.3 用例定義

人工聯(lián)調(diào)測試時，測試人員需要依據(jù)供應(yīng)商接口類型及業(yè)務(wù)場景編寫不同測試用例，用例類型常包含功能測試、異常測試、邊界測試等。這種基于業(yè)務(wù)場景的測試用例可以保證測試質(zhì)量。平臺經(jīng)調(diào)研其他公司的沙箱后發(fā)現(xiàn)，絕大多數(shù)的沙箱僅能給用戶提供單接口測試的頁面，有的頁面雖然能組裝報文或查看接口日志，但由于沒有約束業(yè)務(wù)場景和校驗點，故測試的質(zhì)量高低不一，為上線后的對接質(zhì)量帶來隱患。 

而平臺沙箱通過把一個或多個接口組織在一個有明確測試目的的場景中，讓供應(yīng)商的測試流程更清晰，也更容易把握校驗點。

圖5  單接口測試 vs 場景化測試

3.1.4 用例匹配

不同供應(yīng)商的產(chǎn)品形態(tài)、接口處理方式會有不同，故所需的測試用例集合也不同。為了實現(xiàn)供應(yīng)商與測試用例的自動匹配，平臺在維護測試用例時會為每個測試用例設(shè)置不同的匹配規(guī)則。匹配規(guī)則包含供應(yīng)商是否接入指定接口、指定接口是同步或異步處理以及具體業(yè)務(wù)參數(shù)，如：是否檢驗底價、是否校驗庫存、是否需要證件等。

圖6   用例匹配過程

3.1.5 用例執(zhí)行

匹配得到測試用例集合之后，平臺沙箱會自動執(zhí)行每一個測試用例。每個測試用例包含的多個接口，可能是平臺調(diào)用供應(yīng)商的接口（如下單接口），也可能是供應(yīng)商調(diào)用平臺的接口（如下單確認(rèn)通知接口）。以“用例定義”章節(jié)中的case#1和case#3為例，分別介紹普通執(zhí)行流程和斷點執(zhí)行流程，如下圖：

圖7  用例執(zhí)行流程（普通執(zhí)行流程、斷點執(zhí)行流程）

3.1.6 自動驗收

每個測試用例都是獨立的、可重復(fù)執(zhí)行的，所以允許供應(yīng)商進行重復(fù)測試，直至執(zhí)行成功。平臺沙箱自動統(tǒng)計測試用例的結(jié)果。測試用例涵蓋了幾乎全部的業(yè)務(wù)場景，全部測試用例都執(zhí)行成功，則認(rèn)為供應(yīng)商根據(jù)直連平臺OpenApi開發(fā)的對接系統(tǒng)達到驗收標(biāo)準(zhǔn)。達標(biāo)后，供應(yīng)商需要在平臺沙箱上主動通知直連平臺。平臺將自動為供應(yīng)商做上線配置，完成從平臺沙箱測試到驗收上線的全部流程。

3.1.7 成果

平臺沙箱上線后，供應(yīng)商測試和驗收不再受制于平臺人力，對接OpenApi的供應(yīng)商每月平均上線數(shù)量相較于上線前提高了8倍以上，供應(yīng)商平均接入總耗時從平均23人日下降到6人日。

圖8  沙箱上線前后比較

3.2 提高穩(wěn)定性

系統(tǒng)穩(wěn)定性是指系統(tǒng)要素在外界影響下表現(xiàn)出的某種穩(wěn)定狀態(tài)。在節(jié)假日或營銷活動期間，訂單量會是平常的幾倍或幾十倍，這會給供應(yīng)商系統(tǒng)的穩(wěn)定性帶來很大風(fēng)險。直連平臺需要控制流量，提高供應(yīng)商系統(tǒng)的穩(wěn)定性。

3.2.1 方案

對于承載能力低于直連平臺的供應(yīng)商系統(tǒng)，直連平臺需要控制流向供應(yīng)商的請求速度，一般會通過限流機制來實現(xiàn)。限流的作用是控制在單位時間向提交不超過一定閾值的請求量，即使用削峰填谷的思路，解決突發(fā)流量的問題，保證直連平臺整體的出票成功率。

圖9  限流策略（削峰填谷）

當(dāng)供應(yīng)商系統(tǒng)的指標(biāo)連續(xù)出現(xiàn)異常時，為了減少或阻斷持續(xù)的影響，常見的做法是采用熔斷機制。若系統(tǒng)檢測到熔斷發(fā)生，一般會采取降級處理。在直連平臺中，熔斷分系統(tǒng)熔斷和業(yè)務(wù)熔斷。系統(tǒng)熔斷是當(dāng)直連平臺檢測到供應(yīng)商系統(tǒng)持續(xù)異常時會通過一定時間的禁售等降級操作來減少出票失敗量；而業(yè)務(wù)熔斷則是通過分析并標(biāo)準(zhǔn)化供應(yīng)商接口返回的錯誤信息，并進行相應(yīng)降級操作。

圖10  熔斷降級

3.2.2 限流

常見限流算法

常見的限流算法有計數(shù)器算法、令牌桶算法和漏桶算法。 

計數(shù)器算法是限流算法里最簡單、最容易實現(xiàn)的一種算法，通過控制一段時間的總請求數(shù)實現(xiàn)限流；令牌桶算法則是使用一個存放固定容量令牌的桶，并按照固定速率向桶中添加令牌，請求是否被處理需要看桶中令牌是否足夠；漏桶算法是始終按照固定速率處理請求。 

計數(shù)器算法和令牌桶算法控制處理請求的平均速度，會存在一定程度的突發(fā)流量，而漏桶算法是固定速度，所以直連平臺采用漏桶算法來解決不同供應(yīng)商的限流需求。

漏桶限流

用戶訂單產(chǎn)生后，直連平臺需要從隊列中批量讀取數(shù)據(jù)，向供應(yīng)商批量分發(fā)，常常會出現(xiàn)瞬時流量影響對方系統(tǒng)的穩(wěn)定性。通過漏桶限流方案，實現(xiàn)勻速分發(fā)，保證供應(yīng)商系統(tǒng)的平穩(wěn)處理。

圖11  漏桶限流前后對比

具體步驟：根據(jù)限流策略，從數(shù)據(jù)隊列中獲取指定數(shù)量的訂單，根據(jù)間隔時間計算提交時刻，最后執(zhí)行分時提交。

圖12  漏桶限流實現(xiàn)邏輯

平臺的訂單對接供應(yīng)商有幾千家。在配置限流策略時，無需為每一家配置限流策略。平臺的做法是對于有限流訴求的供應(yīng)商、訂單量較大的供應(yīng)商和臨時有營銷活動的供應(yīng)商配置即可，而其他供應(yīng)商可以使用一個公共的限速適中的限流策略即可。這樣可以保證重點供應(yīng)商系統(tǒng)的穩(wěn)定性，又可以減少維護限流策略的費力度。

效果展示

下圖為限流后的流量請求結(jié)果。從圖中可明顯看出，支持限流后的直連平臺可以很平穩(wěn)的控制處理請求的速度。

圖13  限流效果

3.2.3 系統(tǒng)熔斷

熔斷監(jiān)控

系統(tǒng)熔斷的監(jiān)控采用30分鐘長監(jiān)控和5分鐘短監(jiān)控結(jié)合的方式。長監(jiān)控用于計算熔斷時長，而短監(jiān)控的目的是為了補充長監(jiān)控的不足，防止把系統(tǒng)已經(jīng)恢復(fù)的供應(yīng)商再次進行熔斷。

熔斷時長

熔斷時長在基礎(chǔ)時間的基礎(chǔ)上，綜合考慮了異常或超時率和連續(xù)熔斷次數(shù)。在對供應(yīng)商歷史異常時長的統(tǒng)計后得到異常均值時長在30分鐘左右，故平臺設(shè)置熔斷單次時長最長不超過60分鐘。計算熔斷時長的公式為：

• t：基礎(chǔ)時間（5分鐘）。
• p: 過去30分鐘內(nèi)的異?；虺瑫r率。
• L(p)：由p計算出的熔斷時長等級。異?；虺瑫r率越高，則熔斷時長等級越高。
• n：連續(xù)熔斷次數(shù)，首次熔斷n=1。資源上線超過24小時，則n重置為0。

3.2.4 業(yè)務(wù)熔斷

錯誤信息多樣性

直連平臺對接的供應(yīng)商非常多且不同供應(yīng)商接口契約、對接流程和錯誤描述也不盡相同。對于因“庫存不足”而失敗的下單響應(yīng)報文，直連平臺可能是根據(jù)供應(yīng)商返回的不同code區(qū)分的，也有可能是需要通過錯誤描述來區(qū)分的，如“庫存數(shù)量不足”、“余票不足”、“沒有庫存”、“還剩0張”、“已售罄”等等。

圖14  庫存不足”對應(yīng)的供應(yīng)商錯誤信息

接口的錯誤信息有很多用途，如監(jiān)控供應(yīng)商系統(tǒng)的穩(wěn)定性、歸納對客失敗話術(shù)、反映商品設(shè)置錯誤、反映用戶錯誤輸入、提醒補庫存、關(guān)閉班期或下線資源等?；诠?yīng)商接口錯誤信息的分析和處理對于商品力、系統(tǒng)監(jiān)控、用戶體驗等方面都有非常重要作用。

錯誤分類

直連平臺把業(yè)務(wù)錯誤分為6個大類，分別是系統(tǒng)問題、游客信息問題、限購問題、庫存問題、產(chǎn)品設(shè)置問題和賬戶余額問題。每個大類有分為若子類，在子類上可以配置通知接收人、通知方式、資源操作方式、對客話術(shù)code等。比如對于下單接口，只需要把不同供應(yīng)商下單接口錯誤信息中的關(guān)鍵詞關(guān)聯(lián)到相應(yīng)的二級分類上，平臺即可基于分類進行統(tǒng)一的操作。

圖15  錯誤分類演示

為了關(guān)鍵詞更加精確地識別指定供應(yīng)商的錯誤信息，關(guān)鍵詞的配置工作必須要人工進行。相同的錯誤描述對于不同供應(yīng)商可能有著不同的含義，如：“處理錯誤”或某個具體的錯誤碼等。

直連平臺會監(jiān)控關(guān)鍵詞匹配率，并每日拉取增量的未匹配關(guān)鍵詞的供應(yīng)商錯誤信息，由運營進行補充到供應(yīng)商的關(guān)鍵詞策略中。

降級方式

目前降級方式僅支持禁售，禁售包括關(guān)閉班期和下線資源。供應(yīng)商返回“庫存不足”、“日期不可售”等錯誤時，平臺將會對資源操作關(guān)閉班期，供應(yīng)商返回“預(yù)存款不足”、“價格設(shè)置錯誤”等錯誤時，平臺將下線資源。

3.2.5 成果

通過系統(tǒng)熔斷和業(yè)務(wù)熔斷，有效的規(guī)避了因供應(yīng)商系統(tǒng)異常、庫存不足、賬戶余額不足等等問題造成出票失敗的問題，異?；虺瑫r失敗率從0.34%下降到0.05%。

圖16  系統(tǒng)熔斷效果

四、結(jié)語

引入沙箱后，接入OpenApi的供應(yīng)商不再受制于直連平臺的人力，上線效率明顯提升，但由于目前沙箱文檔中對沙箱頁面使用流程和常見問題的介紹仍不夠詳盡，還需要平臺人力為供應(yīng)商解答諸多類似問題，故需要進一步完善。

熔斷監(jiān)控能有效減少出票失敗率，但熔斷監(jiān)控只依賴下單接口的狀態(tài)，由于部分供應(yīng)商已接入可定檢查或預(yù)下單等實時接口，所以增加監(jiān)控更多接口數(shù)據(jù)能更加有效地提高監(jiān)控的實時性。而且除了禁售，熔斷策略還可以補充其他操作，如變更確認(rèn)方式等。

此外，隨著供應(yīng)商數(shù)量和業(yè)務(wù)邏輯復(fù)雜度的增加，現(xiàn)有監(jiān)控和預(yù)警機制有待進一步完善。當(dāng)前預(yù)警手段還比較依賴郵件，而告警郵件數(shù)量增多，會增加告警觸達率低和響應(yīng)不及時的風(fēng)險。故需要基于平臺現(xiàn)有邏輯埋點，通過公司成熟且完善的一系列組件對監(jiān)控和預(yù)警做進一步升級。

最后，希望本文中提到的解決方案能給大家?guī)韼椭蛦l(fā)。