基于微服務的航空電商架構

文/廖忠濤 陳川 許嘉偉

1 綜述

隨著云計算、區塊鏈、人工智能的發展，行業新玩家介入、新模式的出現，航空市場面臨的競爭日趨激烈，各航空公司紛紛在探索數字化轉型、新零售轉型。在轉型過程中系統架構需要支持的業務需求更加紛繁復雜，對原有系統性能、整體架構、以及系統可維護性等帶來愈加嚴峻的挑戰。作為全球化的傳統服務行業，用前沿的互聯網技術打造全新的航空電商架構平臺成為航空公司的當務之急。例如美國航空早在2017年7月就開始構建基于微服務和DevOps 敏捷型應用架構，大韓航空在2018年12月提出建設在aws 云上的、基于容器和無服務器技術的微服務架構，以適應不同規模及復雜性的業務負載。本文基于這種新形勢下，探索微服務架構在航空電商平臺的應用。

2 航空電商架構的現狀及問題

2.1 航空電商架構的發展現狀

航空公司電商平臺主要提供機票銷售、機票退改、會員管理、里程服務、航空附加產品銷售等。軟件建設之初，業務相對簡單，將同類的或相似的業務應用放在一起，便于溝通、數據共享和解決功能依賴。隨著業務的發展，更多新業務功能層出不窮，各系統在原來的基礎上不斷堆砌，各應用系統軟件規模不斷擴大，內部耦合程度增加，頻繁部署，增加維護管理成本，給軟件檢測試也帶來更多不確定性。

2.2 單一巨石型應用及問題

傳統航空公司電商架構在模塊化、微服務化之前，是一個單一的巨石型單體應用。所謂巨石型應用架構，將所有的包括查詢、下單、支付、里程兌換、客票驗真等放在一個應用包，在同一個Web 容器運行。隨著業務的不斷新增和日趨復雜，這個應用包變得越來越“龐大”、“臃腫”。其帶來的后果是：

（1）增加復雜性：隨著系統規模和團隊規模發展到一定階段，代碼量不斷增加，外部依賴越來越多，代碼結構混亂，使團隊成員不能理解整體代碼邏輯，增加代碼復雜度；

（2）增加系統耦合：各業務應用耦合在一起，模塊代碼間相互依賴，例如改了下單模塊，會牽連影響導致航班查詢、支付不可用；

圖1：Spring Cloud 架構圖

（3）交付效率低：系統構建和部署耗時長，開發周期長，代碼修改困難，故障定位困難；

（4）技術債堆積：模塊功能耦合，只能使用固定、相同的技術棧，可擴展性弱。

3 微服務下的航空電商架構

3.1 微服務介紹

微服務最早由MartinFowler 與James Lewis 于2014年共同提出。微服務體系結構風格是一種將單個應用程序拆分為一組小型服務進行開發的方法，每個服務都在自己的進程中運行，并使用輕量級的通信機制。這些服務是圍繞業務功能建立而成，匹配一套最低限度的中央式管理機制，且各服務可通過不同編程語言編寫而成并使用不同的數據存儲技術。其特點是“小而?！?，可以在“自己的程序”中運行，服務組件化，服務之間通過輕量級設備基于Http 的Restful API 進行通信協作，使業務系統徹底組件化和服務化。被拆分成的每一個小型服務都圍繞著系統中的某一項或一些耦合度較高的業務功能進行構建，并且每個服務都維護著自身的數據存儲、業務開發、自動化測試案例以及獨立部署機制。同時，這些微服務可以使用不同的技術棧、多種編程語言來實現。

3.2 基于Spring Cloud微服務架構

Spring Cloud 是一個基于Spring Boot 實現的一些列框架的集合，為開發者提供了在分布式系統的配置管理、服務發現、斷路器、智能路由、微代理、控制總線等一些列微服務架構生態鏈，與Dubbo 框架采用的RPC 通信方式相比，Spring Boot 采用HTTP 的REST 方式，盡管從一定程度上犧牲了服務調用的性能，但也避免了RPC 帶來的服務提供方與調用方在代碼上的強依賴的缺點，REST 相比RPC 更為靈活，服務提供方和調用方的依賴更少，這在強調快速演化的微服務環境下，適用性更強。Spring Cloud 框架集成了一系列強大的微服務基礎設施組件，包括Netflix Zuul、Eureka 等，參見如圖1。

3.3 微服務拆分

微服務拆分之前需要先進行面向服務的模塊化拆分。模塊化簡單來說，就是把單一體應用按照業務特點拆分成多個應用，其特點是各應用高內聚、松耦合、可重用，可分布式部署。針對航空公司業務特點，可將電商機票直銷后臺架構拆分重建包括Shopping、Booking、Login、Payment、Order 等面向服務多模塊化應用（如圖2），各自實現包括查詢、下單、登錄、支付、訂單管理等業務服務，各個服務可被多個應用共享，服務之間可以通信，可獨立升級、可擴展、可維護。

圖2：航空電商機票業務

圖3：公共服務

在面向服務的模塊化拆分基礎上，接著進行微服務拆分。微服務的拆分是微服務架構的重點，需要結合自身業務特點、架構現狀、技術團隊等。業務特點主要是業務量及對應的領域模型，架構現狀主要是對應技術選型（例如基于Spring Cloud 或Dubbo 等），團隊組成主要是團隊的技術組織特點，同時在微服務拆分過程中，團隊組織也要做調整，構建更加靈活、敏捷型的組織。

一個服務的邊界最好是由業務和領域模型決定。為了保證服務功能的單一內聚和獨立布署，要參考領域驅動設計的思路去決定一個微服務的大小和邊界。比如很多航空公司推出“低價日歷”，對于低價日歷這種業務模型單一的功能，可以直接使用一個服務就實現；而對于shopping 云庫存緩存系統（緩存航班票價信息），就要組織相關的服務，結合數據的組成方式和功能，整理出監控、庫存數據、緩存數據、查詢等不同的微服務。

3.4 微服務的開發和管理

在開發和管理過程中，微服務突出表現在“小”這一方面，具體表現在開發周期和團隊都變小。所以，原有的開發方式要做相應的調整，開發周期控制也采用敏捷迭代的方式，通過敏捷迭代加快開發進度和適應變更，更具靈活性。敏捷開發是一種以人為核心、迭代、循序漸進的開發方法。在敏捷開發中，軟件項目的構建被切分成多個子項目，各個子項目的成果都經過測試，具備集成和可運行的特征。對于快速增長變化的航空業務需求，“敏捷模型”可以很好的解決需求不斷變化的問題，實現快速迭代、快速交付。

微服務方案對于各部門而言是一種不同于以往的且以業務功能為核心的服務拆分及組織途徑。根據康威定律：任何組織在設計一套系統（廣義層面的系統）時，其設計成果都會直接體現該組織所使用的溝通結構。當著眼于將單一大型應用程序拆分成多個組成部分時，管理人員通常更重視技術層，其中具體包括UI 團隊、服務器端邏輯團隊以及數據庫團隊。當這些團隊據此進行拆分時，即使是最簡單的變更也將給項目造成跨團隊協作負擔，并因此導致時間與預算的雙重支出。因此，需要改變傳統的煙囪型職能組織，變成扁平的矩陣型及項目型組織，各團隊成員將擁有跨職能特性，包括開發過程當中要求的全部技能組合：用戶體驗、數據庫以及項目管理等等。例如鎮針對航空公司行程中心中間庫項目，建議配置了1個PM 和2 個開發作為主體進行開發管理，同時對CMC（統一配置管理中心）和監控功能再配置2 名開發人員輔助，整體5 個人團隊可以完成相關項目。

3.5 接口適配

圖4：行程中心微服務

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

3.6 Docker容器部署

當傳統的單體服務被拆分為微服務后，實例數量由原來一個變成了多個，彼此獨立部署，對項目的部署和啟動帶來了挑戰，所以需要引入容器化方法部署微服務項目，擴展靈活，已于管理。Docker 是一個開源的應用容器引擎，可以讓開發者打包他們的應用以及依賴包到一個可移植的容器中，然后發布到任何流行的linux 服務器上。Docker 本質上是一種輕量級虛擬化技術，提供和虛擬機相同的功能但又更加強大，簡單易用，輕快便捷。Docker 還使用名稱空間完全隔離應用程序對底層操作環境的視圖，包括進程樹網絡用戶id和文件系統。

3.7 微服務治理

微服務去中心化治理。在項目初期，中心化的API 網關統一了所有API 的入口，隨著業務的發展，API 網關開始暴露問題，每個用戶請求經過機房時只要有服務之間的交互，則都會從API 網關進行路由，服務上量以后，由于內部服務之間的交互都會疊加在API 網關的調用上，所以在很大程度上放大了API 網關的調用TPS，API 網關很快就遇到了性能瓶頸。微服務架構倡導去中心化的服務管理和治理，盡量不設置中心化的管理服務，最差也需要在中心化的管理服務宕機時有替代方案和設計，這樣當出現故障時可進行降級處理。

微服務的注冊和發現是服務治理重要部分，基于Spring Cloud 下的Netflix Eureka 就是服務注冊和發現的一個很好的現成解決方案，并且提供了相應的java 封裝。在Eureka運行過程中，節點之間是相互平等的，部分注冊中心的節點掛掉也不會對集群造成影響，即使集群只剩一個節點存活，也可以正常提供發現服務。哪怕是所有的服務注冊節點都掛了，Eureka Clients 上也會緩存服務調用的信息。

因為微服務是一個個獨立部署運行的單元，必然涉及到一些公共服務的調用，需要把微服務運行中的各公共服務獨立出來，例如建立基于redis 分布式緩存服務，基于Kafka 消息服務，基于ElasticSearch+Logstash+kibana的日志服務等，如圖3。

4 應用案例：“蜂巢”微服務架構

基于上述微服務的航空電商架構建設研究分析結果，某航空公司針對旅客行程中心領域建設“蜂巢”六邊形微服務架構，將一個完整的行程中心應用拆分成多個不同的微服務，每個微服務都有明確的邊界，彼此之間既相對獨立，每個服務都能獨立部署，獨立維護，獨立擴展。服務之間按照“蜂巢”六邊形架構與外部服務進行交互，這些六邊形架構的微服務就像蜂巢里面的巢房，不同的巢房具有不同的功能，各自分隔又緊密結合，共同組成了行程中心的整個微服務架構系統，如圖4。

5 結束語

進行數字化轉型、提升直銷比例、構建信息化電商平臺是未來航空公司的發展方向，本文分析了目前我國航空公司在信息化建設、業務發展壯大過程中，電商架構平臺存在的問題。針對單體結構應用復雜性高、系統耦合、交付效率低、技術債堆積的問題，提出了基于微服務的航空電商架構。本文提出的微服務架構方案基于Spring Cloud 框架，并從微服務開發和管理、接口適配、Docker 容器部署、微服務治理等方面提出航空電商微服務架構平臺構建方法，該方法在某航空公司運用并取得良好的效果。國內航空公司電商平臺的發展雖然有各自特點，但其發展歷程及面臨的問題有很多類似和可以借鑒的地方。所以，基于這套微服務的航空電商架構平臺建設，在國內航空中具備一定的普遍性。