新型航空電商架構平臺建設研究及應用

廖忠濤 許嘉偉 陳川 彭向暉

摘 要 文章主要介紹基于移動互聯網、大數據等新形勢背景下，航空公司電商架構平臺建設所面臨的挑戰，以及通過建設新型航空電商架構平臺去應對挑戰。此電商架構平臺已應用在某航空公司電子直銷平臺，并取得了一定的效果。新型航空電商平臺建設在航空公司電商銷售系統建設中具有較大的借鑒和推廣價值。

關鍵詞 互聯網；電子商務；平臺構建

中圖分類號 TP3 文獻標識碼 A 文章編號 1674-6708（2018）220-0089-05

1 綜述

互聯網二次革命移動互聯網時代、大數據時代，面對國資委“提直降代”要求、高鐵的沖擊、航旅消費人群的變化，如何吸引及留住用戶、提升系統響應、拓展輔加服務，提升用戶體驗及系統銷量，實現“千人千面”營銷，在激烈的競爭中脫穎而出，是各航空公司面臨的重要課題。本文結合新形勢、“互聯網+”環境下，運用先進的互聯網技術，研究新型航空電商平臺的構建，探索這種新型航空電商平臺在航空公司電商銷售平臺建設中的應用。

2 航空公司電商平臺建設面臨的挑戰

2.1 業務需求的急速增長

電商平臺就如同超市，沒有流量就不會有銷量，提升直銷銷量最重要途徑之一，是提升網站及移動端用戶訪問量、活躍度。實現的方式是推出各種營銷活動，吸引大量用戶的關注和參與，并最終轉化成購票行為。例如東航推出的機票秒殺活動、國航推出雙11機票搶購活動、海航每月8號會員日活動等。活動期間必然導致訪問請求量、并發量激增，高峰期可能是平時5～20倍的量級增長。如圖1，某航空公司某次營銷活動日請求量與平時對比。

2.2 業務邏輯日益復雜化

廣告活動、機票銷售等由傳統“千人一面”變成“千人千面”，由B2C模式向C2B模式轉變，后臺基礎服務要支撐包括機票、支付、優惠券營銷、升艙、餐食、付費行李、付費選座、里程兌換、機上WiFi預選等各種業務處理。

2.3 業務數據多樣化、異構化

業務模塊增多，數據源越來越多，接入的數據結構由以前的結構化數據整合轉為銷售訂單數據、訪問大日志數據、網頁訪問行為數據、各種埋點數據等多元化異構數據整合。

2.4 業務的高速發展和迭代

業務高速發展和迭代，新增大量的業務需求，而且業務需求不斷發展變化，部分業務需求有很高的時效性要求。行業數據顯示，航空旅游消費主力群體集中在25歲～40歲之間，這部分人基本出生在改革開放后，較樂于接受新鮮事物，習慣手機網購，不僅僅滿足于航空點到點的運輸服務，期望對出行各環節、全流程全面的服務提供，更注重個性化產品服務體驗，期望得到及時回應的互動式服務體驗。消費群體變化，導致在航空出行全流程涌現各種不同的業務需求，包括個性化運價、線上線下營銷（O2O）、機票打包、微信營銷、機上娛樂等。對項目研發效率、項目管理方式、項目技術架構提出新的更高要求。

在這種新形勢下，傳統航空電商應用架構不得不變，要對系統應用架構的自我重生和涅槃，需要改為大數據及新的高并發架構，來應對業務需求激增及高速迭代帶來的挑戰。

3 應對挑戰的系統架構改造思路

面對這些挑戰，我們的應用系統架構應該如何涅槃？總體思路上從4個方面進行：

3.1 系統的存儲

存儲是航空電商交易的核心，這一點對于整個系統的吞吐量和并發量的提升起到最關鍵的作用，需要結合數據存儲模型和具體應用的場景。

3.2 系統的計算

主要從橫向和縱向考慮：橫向主要是增加并發度，增加并行鏈路及使用集群分布式。縱向拆分就是要求我們找到計算的結合點從而進行分層計算處理，將各層次計算完后的結果整合，盡可能最大化系統整體的處理能力。

3.3 業務層架構

要求系統的良好的模塊化設計，清楚的定義模塊的邊界，模塊自升級和可配置化。在模塊化基礎上，引進最新的微服務架構，并能實現容器部署。

3.4 開發管理模式轉變

軟件工程管理有自身特點，需求總是在不斷變化，充滿很多不確定性，需要通過不斷的自我調整、不斷迭代、階段交付，與需求不斷碰撞、與用戶頻繁交互等，去適應各種變化。傳統的從上而下的“瀑布模型”已不能適應業務需求的高速發展和迭代，需要用新的快速迭代的方式去適應。

4 應對挑戰的新型航空電商架構平臺設計

面對這些挑戰，航空電商架構平臺如何涅槃？下面參考第三章中的思路，主要從對系統架構設計最重要的5個方面，即存儲的設計、架構層設計、業務計算的設計、敏捷模型、云服務介紹新型航空電商架構平臺設計。

4.1 存儲的設計

馬云曾說：人類正從IT時代走向DT時代。在大數據時代，數據是企業的一種寶貴資源，但最關鍵的是如何存儲、使用和利用好數據。航空公司電商現狀是需要安全存儲海量的數據，高吞吐，并發能力強，同時隨著數據量和請求量的快速增加，能夠通過加節點來快速擴容。另外還需要支持故障轉移，自動恢復，無需額外或只是很低的運維成本。下面以建立航空公司搜索智能庫存緩存平臺為例介紹存儲的設計。

航空公司做電商直銷平臺架構的時候普遍面臨一個問題：即高并發查詢與自身后臺或依賴的第三方接口性能處理能力不足之間的矛盾。如果把航班、艙位、票價當作商品，那么這個商品每時每刻都有用戶高頻的查詢及購買，高峰期可能每秒達數百次查詢，商品庫存時刻在變化。面對庫存的時刻變化，簡單的做數據緩存無法解決用戶查詢緩存數據準確率低、用戶體驗不友好的問題。面對這個問題，我們通過建立倉儲庫存、消息通信機制、被動式+主動式緩存等3個方面設計解決。

建立“倉儲”庫存。建立倉儲庫存平臺，把所有的航線、座位、票價等數據放在“倉庫”，用戶查詢的時候直接從自己的“倉儲”中拿出來返回給用戶。可以根據不同業務數據特點，選擇不同的“倉儲”庫存工具，針對座位、票價高并發訪問數據，可選擇采用MongoDB+Redis的數據存儲方案。

通過消息通信機制保障庫存“供應鏈”管理，實現實時或準實時更新。影響航線、座位、票價數據庫存的因素很多，包括AV、航班計劃、pricing、票價收益、Booking、監控等。通過建立消息隊列通信機制，將每一個環節的變化信息發送給消息隊列，消息隊列則推送給“倉儲”庫存平臺，在消息隊列里面，保證每一個消息都會被處理。可選的消息隊列工具包括RabbitMQ，Apache ActiveMQ，RocketMQ等。

建立被動式+主動式緩存機制。當用戶實時搜索的時候可以做被動式緩存，用戶沒有搜索的時候做主動式緩存。根據各影響因子或環節特點設計主動更新庫存時間表，每天按計劃時間設置不同頻率準時訪問各影響因子或環節，并建立科學監控埋點，第一時間獲取庫存變化信息。

總體上，航空公司可以根據需要存儲的數據大小、數據類型、數據讀寫頻度等不同的業務場景需求，選擇對應的存儲技術。

4.2 架構的設計

1）面向服務的模塊化：很多航空電商平臺還在使用傳統單體式應用架構，所謂單體式應用架構，簡單的說就是將復雜的業務模塊放在一個應用里面，開發、升級、部署都在一起。這種單體式應用架構的缺點是：隨著業務需求不斷增加，單體應用變得越來越臃腫，技術債務不斷堆積，可維護性、可擴展升級性、靈活性逐漸降低，各業務應用模塊相互影響及牽制。針對航空電商業務特點，可將其進行模塊化拆分，將航班票價查詢、機票下單、支付、登錄、訂單管理、優惠券管理、里程兌換、航班動態管理等模塊獨立出來，單獨更新升級、獨立部署。

2）微服務：微服務架構是一種架構風格和設計模式，他提倡將應用分割成一系列細小的服務，每個服務專注于單一業務功能，運行于獨立的進程中，服務之間邊界清晰，采用輕量級通信機制（如HTTP/REST）相互溝通、配合來實現完整的應用[2]。微服務是在模塊化基礎上的升級，是“小而專”，輕量級、組件化、服務化，服務可以細化到每個接口API。微服務架構改造不能生搬硬套，需要從微服務拆分、接口適配、服務治理、微服務的開發管理等進行改造升級。

（1）微服務拆分：主要從業務和領域模型、技術及業務量、團隊組成等幾個方面進行微服務拆分。一個服務的邊界最好是由業務和領域模型決定，為了保證服務功能的單一內聚和獨立布署，我們參考領域驅動設計的思路去決定一個微服務的大小和邊界。例如對于航空公司航班票價查詢Shopping云庫存緩存系統，就要組織相關的服務，結合數據的組成方式和功能，整理出監控、整合庫存數據、緩存數據、查詢等服務；而對于低價日歷這種業務模型單一的功能，我們可以直接使用一個服務就實現。

（2）接口適配：在開放的底層接口中，客戶端的接入五花八門，為了減少對客戶端的嵌入，在微服務應用架構的過程中需考慮許多種通訊方式的支持，因此微服務的架構需考慮“六邊形架構”的模式（見圖3），搭建和外部服務交互的端口和適配器。每個微服務都有明確的上下文邊界，微服務間通過消息或者http請求進行交互。

（3）服務治理：為了更好的引入微服務，需要進行服務治理解決服務依賴問題。設計微服務時對顆粒度進行把控，減少多重依賴，使服務盡量扁平化；同時，需要將各公共服務獨立出來，例如建立基于redis緩存服務，基于rocketMQ消息服務，基于flume+ElasticSearch+kibana的日志服務等。

（4）微服務的開發及管理：在微服務開發和管理過程中，微服務突出表現在“小”這一方面，具體表現在開發周期和團隊都變小。開發周期控制采用敏捷開發的方式，通過迭代加快開發進度和適應變更，更具靈活性。團隊的規模，根據康威定律，微服務的團隊組織結構相比以前的項目就小很多。例如針對航空公司行程中心中間庫系統，可以配置1個PM和2個開發作為主體，同時對配置管理平臺CMC和監控功能再配置2名開發人員輔助，整體5個人團隊就完成了相關項目。

實現微服務之后，可以將航空公司眾多的業務功能點分散在各個微服務中實現，可以支撐快速響應開發，快速部署。

4.3 計算的設計

4.3.1 在線計算

橫向擴展。應對訪問量、銷售量快速增長，使用增加并發鏈路、分布式部署方式，增加橫向計算能力。例如針對移動端訪問量新增，可擴大移動平臺并發鏈路，對Redis集群部署等。

縱向擴展。拆分業務模塊，對原來只有一層的單一應用，拆分成多層，例如把航班票價查詢接口拆分成票價獲取、航班獲取、票價航班組合處理；針對機票下單拆分成票價校驗、訂座生成PNR、訂單入庫等。對存儲拆分，對查詢頻率高的熱數據放到緩存中，對冷數據則基于下一級存儲，例如Mysql。

業務層推薦策略。根據用戶搜索、用戶點擊瀏覽、用戶曾經購買記錄等，推測用戶意圖，推薦策略生成的產品數據集合，接著按照場景規則，業務邏輯重新過濾，聚合、排序。例如分析發現某用戶對“廣州-三亞”關注度很高，且根據其曾經購票行為判斷為價格敏感型用戶，則提前緩存近1～2個月“廣州-三亞”“廣州-海口”航線最低價數據，有針對性的推薦給用戶。

4.3.2 離線計算

主要分4個階段：

1）數據收集階段：在網站、手機、觸屏前端、應用端、接口端建立起各種“埋點”，收集各種用戶數據。

2）預處理階段：這塊主要為后續數據挖掘做一些數據的準備工作，數據去重，過濾，對缺失信息的補足。舉例來說用戶打開APP，系統采集定位到該用戶所在城市為北京，通過連接后臺會員庫、銷售庫獲取該用戶為銀卡用戶，過兩天飛“北京-悉尼”，系統主動為其推送機上WiFi、機上餐食等。

3）數據挖掘階段：主要運用一些常用的數據挖掘算法進行模型訓練和推薦數據的輸出。

4）數據導入展示階段：對挖掘結果數據進行導入存儲，并界面化、圖形化進行展示。

4.4 敏捷模型

敏捷開發是一種以人為核心、迭代、循序漸進的開發方法。在敏捷開發中，軟件項目的構建被切分成多個子項目，各個子項目的成果都經過測試，具備集成和可運行的特征。對于快速增長變化的航空業務需求，“敏捷模型”可以很好的解決需求不斷變化的問題，實現快速迭代、快速交付。圖4為敏捷的一個模型圖，以2周為一個迭代周期。

4.5 云服務

阿里巴巴2017年“雙11”交易峰值達到32.5萬筆/秒，支撐如此高并發處理的正是阿里“電商云化”架構。隨著航空公司大規模營銷活動、促銷活動深入開展，國際化戰略的深入，越來越需要得到一種可以彈性伸縮、可擴展的基礎架構服務IaaS、平臺服務PaaS、軟件服務SaaS，并能夠解決海外信息數據平臺建設的問題。云服務部署能很好的解決上述問題。

5 應用案例

根據上述新型航空電商架構建設研究分析結果，某航空公司針對航班票價搜索、基于“倉儲”庫存+“供應鏈”管理架構設計、使用MongoDB+Redis存儲及RocketMQ消息隊列技術完成建設Shopping智能云庫存緩存平臺，日均處理消息1 500萬+，庫存數據庫實現對該航空公司國內國際全年150萬左右航班約3 900萬個艙位的準實時更新，準確率達到98%，平均搜索響應時間只需要0.03秒。又比如該航空公司基于Spring cloud技術構建起包括航班搜索、機票預訂、行程中心、用戶登錄、最低價日歷等幾十個微服務的“蜂巢”微服務架構平臺，其中登錄模塊微服務改造之后，性能提升80%；旅客行程中心進行微服務改造并實現分布式集群部署，在整體數據量超過3億條情況下，平均查詢響應時間低于500毫秒。

基于此構建的新型航空電商平臺，支撐其直銷平臺每年超過50%的增長，電子直銷單日破億的夢想變成現實，并漸趨常態化；移動商旅平臺年銷售額突破45億元，同比提高超過100%，單日銷售額突破3 000萬元；電商平臺年訪問量近1.4億人次，同比增長60%，支撐單日最高超過100萬用戶訪問，App單日活躍用戶數超過25萬，社交媒體粉絲量超過1 000萬；并初步構建起精準營銷、一站式全流程服務電商架構支撐體系。

6 結論

本文研究的航空電商平臺建設，主要基于中國南方航空的實際業務特點及對應的發展現狀。國內航空公司電商平臺的發展雖然也有各自特點，其發展歷程及面臨的問題跟南航有很多類似和可以借鑒的地方。所以，基于南航的這套新型航空電商架構平臺建設，在國內航空中具備一定的普遍性。

目前，中國移動互聯網用戶11.2億，移動寬帶用戶9.78億，手機用戶13.3億，互聯網上市企業市值近9萬億，2017年全國電子商務交易額達到29.16萬億元。在航空機票領域，國際上的在線旅游網站EXPEDIA＼ORBITZ等，國內的攜程、藝龍、淘寶旅行，在線搜索企業KAYAK、國內的QUNAR等公司，紛紛進軍航空旅游，不斷沖擊航空旅游企業。國內航空企業如果能積極應對，在航空電商平臺架構建設上進行創新，利用“互聯網+”構建自己新型電商架構平臺，將大大提升航空公司效益，提升競爭力。

參考文獻

[1]Andrew Ryan. Under the Hood：Hadoop Distributed Filesystem reliability with Namenode and Avatarnode（Z）. Facebook Blog， 2012.6.

[2] Kristina Chodorow，Michael，Dirof. MongoDB：The Definitive Guide， 2nd Edition（M）. OReilly Media，2013.5.ISBN： 978-1-4493-4468-9.

[3]Eric Siegel. Predictive Analytics： The Power to Predict Who Will Click， Buy， Lie， or Die（M）. Wiley， 2013.2. ISBN： 978-1-4571-6194-0.

[4]戴國良.C2B模式電子商務的產生、發展與展望[J].電子商務，2013（9）：25.

[5]孫海洪，微服務架構和容器技術應用[J].金融電子化，2016（5）：63-64.

[6]阿里巴巴雙11技術團隊，不一樣的技術創新——阿里巴巴2016雙11背后的技術[Z]，2016，12.