基于微服務架構的開放卡券銷售平臺構建

馬歡 符為偉

(交通銀行信用卡中心，上海 200000)

0 引言

隨著微信、支付寶等互聯網金融行業的興起，其對銀行的傳統支付業務造成了極大的沖擊。互聯網服務提供商依托其掌握的大量的生活場景、水電煤賬單繳費、各種會員卡券的充值及銷售等，結合自身的支付能力，構成了完整的業務閉環。傳統的銀行支付工具(如信用卡)，面臨著嚴重的脫媒風險而淪為支付工具。

銀行紛紛推出自己的APP產品，除了包括常規的金融服務，還包括大量生活服務，借此構建完整的業務鏈條，與互聯網金融平臺進行正面競爭。

作為專業的金融機構，銀行通常不會直接建設這類非主營的生活服務類業務，而是通過整合外部供應商以豐富APP的服務能力。基于此，本文介紹一個基于微服務架構的開放卡券銷售平臺構建案例，實現敏捷快速的外部服務能力轉化，助力銀行業務發展。

1 外部服務能力轉化面臨的挑戰

銀行APP在整合外部供應商的各種服務能力時，不可避免地要進行內外部系統之間的集成和互操作，常見做法是：由外部供應商提供各類服務能力API的接口，在銀行內部建設若干個獨立的業務系統集成這些生活服務能力和本行的金融支付能力。該模式面臨以下挑戰。

1.1 建設速度慢

針對每一個新的生活場景和供應商，都可能需要建設對應的業務系統。從達成商務合作意向后開始進行系統建設，設計、開發、測試的一系列流程通常都需要3個月以上的周期，新業務難以快速投入運營。

1.2 建設成本高

針對每個場景建設的新系統，設計開發、測試的人力成本，各種安全、性能的檢測成本，以及系統建成配置的運維成本，使得整體成本高企、投資回報率低。

1.3 配置不靈活

各種場景的重復建設以及趕工期等因素，使得每個場景的業務系統產品成熟度不高，大量的配置信息被硬編碼。在產品的運營過程中，一些業務變化都需要重新開發升級系統，這個過程不僅耗時，還極易造成各類功能、性能、安全的缺陷，影響業務開展。

為了應對上述挑戰，本文探討構建一個統一的開放卡券銷售平臺，通過該平臺承接各種外部卡券銷售類服務，通過少量的配置和調試工作，迅速將外部第三方的服務能力落地轉化為銀行的服務能力。

2 開放平臺技術的發展趨勢

2.1 開放銀行

現代商業銀行的發展歷程大致可以分為以下三個階段：

(1)線下發展階段。該階段完全聚焦于金融業務，以網點的方式進行業務拓展。這種模式下存在的是資金、人力和運營成本之間的矛盾。

(2)線上發展階段。互聯網興起后，銀行業務逐漸線上化，互聯網的無界性極大地化解了之前實體網點模式的挑戰，但仍以金融業務為主。

(3)互聯網金融階段。在該階段面臨互聯網金融的挑戰，存在與客戶脫離的風險。為了化解這一危機，銀行業開始思考銀行和各種非銀機構的跨界融合，實現以銀行為主體的銀行生態重構，這個概念被稱為“開放銀行”，目前頭部大型銀行都已經構建了自己的開放銀行體系。

2.2 開放平臺

實現開放銀行，從業務方向可以分為兩種類型：一種是銀行“走出去”，把自己的金融服務API產品化，由其他第三方把銀行的金融服務整合在自己的服務場景中，用戶無須到銀行即可享受金融服務；另一種是“引進來”，即以銀行為中心，將各種客戶需要的非銀服務能力納入銀行的服務體系，讓用戶在銀行的APP中即可體驗各種便捷的生活服務。

針對這兩種業務模式，都需要開放平臺予以技術支持，才能夠實現業務規模化發展。對外金融能力服務輸出的模式，需要把金融服務API化，然后通過API超市和開放銀行網關平臺對外發布自己的服務能力，由第三方商戶去構建集成金融服務的服務場景。而對內引入各種場景服務能力的模式，同樣需要避免每次一對一的大量重復系統開發建設，要有統一開放平臺承接各種外部服務，將其迅速落地轉化為銀行的服務能力。后者即本文探討的主要內容。

3 開發平臺開發的主要技術

構建統一的開放平臺主要涉及微服務和云計算平臺兩方面的技術。

3.1 微服務

微服務是基于SOA(面向服務的架構)的一種用于構建應用系統的架構解決方案。通過微服務的方式，可以實現松散耦合的分布式架構。

一個應用系統可以由多個微服務組成。例如，一個傳統的在線商城系統，所有的商品展示、搜索、用戶、下單等功能都是一個服務程序，經過微服務改造，可以把系統拆分為商品中心、用戶中心、訂單中心等幾個微服務模塊，各個微服務獨立部署，聯合組成整個商城系統。

這種架構的優勢是可以獨立部署每個微服務，有自己的應用服務器和數據庫服務等資源。一個微服務的更改不會破壞整個應用系統，每個微服務都可以作為一個成熟的組件模塊，快速用于搭建新的應用，以滿足不斷變化的業務需求。

3.2 云計算平臺

云計算平臺也稱云平臺，是指基于硬件資源和軟件資源的服務，提供計算、網絡和存儲功能。相比傳統服務器的管理方式，基于云的管理方式可以把企業中與自己主營業務無關的IT基礎運營解放出來，只需要向云服務提供商按需購買自己的計算和存儲能力即可。云服務提供商可以把所有的計算和存儲資源池化管理，按租戶提供給多個用戶，確保在高質量服務的基礎上實現更低的運營成本。

根據集中管理的程度，云計算平臺通常分為基礎設施即服務(IaaS)、平臺即服務(PaaS)和軟件即服務(SaaS)。在IaaS模式下，云平臺僅提供安裝好操作系統、具備網絡能力的虛擬機，用戶有很高的自由度，但對用戶的技術要求也很高。在PaaS模式下，云平臺會安裝好常見的中間件軟件，用戶只要負責專注開發自己的應用程序即可。在SaaS模式下，云平臺直接提供各種標準應用服務，如客戶管理服務、財務服務等，SaaS的用戶僅需通過一些配置操作即可滿足自己的需求。

4 開放卡券平臺的架構設計

為解決引入大量第三方服務商時面臨的各種挑戰，本文探討一種基于微服務的開放權益平臺。新簽約的服務商戶只需經過簡單的配置調試和驗證，即可快速投入生產運營。

4.1 整體介紹

圖1展示了組成開放平臺的微服務組件，以及開放平臺在組織內部和其他微服務以及外部商戶服務之間的關系。基于微服務的模式，無須從零做起，組織中現存的微服務組件可以直接用于新平臺的構建。本次新平臺的構建用到的微服務包括用戶中心、訂單中心、風控中心等。

4.1.1 用戶中心微服務

用戶微服務提供用戶的注冊、登錄、登錄日志查詢、修改密碼等與用戶相關的操作。組織中的任何對外服務，都可以通過整合用戶微服務實現一戶暢通。

4.1.2 訂單中心微服務

終端用戶和組織的所有交易行為，均通過訂單微服務進行集中管理。該微服務不提供圖形用戶界面(GUI)，全部通過API的方式與其他各個業務系統進行交互，具體包括下訂單、已購訂單列表、待支付訂單列表等API功能。

4.1.3 風控中心微服務

終端用戶購買的行為數據都會傳遞到風控中心，包括用戶的信息、購買的商品信息、頻率、頻次、價格等，通過在風控中心設置的風險控制策略，可以對購買行為進行阻斷或報警。

為了實現開放平臺的能力，本次新開發了5個微服務組件，分別為：內容與商品服務、交易服務、訂單服務、運營服務和充值路由服務。

開放平臺中的卡券充值服務，都是在用戶支付后由合作方商戶在線發放，這個過程不可避免地涉及平臺和外部權益提供商戶的在線實時交互，平臺和外部的交互全部由微服務通過接出網關和第三方商戶對接。

所有的微服務均部署在PaaS云平臺上，每個微服務都有自己獨立的容器，可以按需進行擴展部署，并彼此進行隔離以減少相互的影響。

4.2 平臺微服務介紹

從上面的整體介紹可以看出，新的系統構建不再是簡單地把所有的功能設計實現在一個大的服務中，也沒有將系統功能簡單地分為用戶端、運營端等幾個部分，而是根據可復用、易擴展的原則拆分為多個微服務。為了實現開放平臺的核心功能，本次新構建開放平臺的幾個微服務能力，如圖2所示。

4.2.1 內容和商品微服務

用于展示面向用戶的商戶、商品、服務、活動、廣告、公告等信息，每個新的商戶上線后，即可生成自己的商戶首頁，該首頁面向終端用戶，用戶可以進行查看及選購商品和服務。

4.2.2 交易微服務

交易微服務用戶在選購好商品和服務后的支付過程，完成權益平臺和訂單中心之間的交互，包括終端用戶下單過程的訂單確認頁、支付結果頁、訂單詳情頁等用戶界面，以及系統之間交互的下單、訂單查詢等API。交易微服務和前述的內容和商品微服務共同完成了用戶客戶端的功能。

4.2.3 充值路由微服務

充值路由微服務主要完成整個系統和外部商戶之間的充值權益的實時獲取交互操作。此處也是開放平臺中每個新商戶上線需要進行代碼級別調試和驗證的環節，但是任何新商戶的投產都不會影響存量已投產的商戶功能，各個商戶之間實現隔離，每次開發只關注第三方接口的聯調，代碼開發量大幅下降，極大地提升了業務需求投產的時效。

4.2.4 運營微服務

運營微服務主要完成系統級的項配置工作，以及新商戶服務權益的各項配置能力。考慮到運營端的工作用戶數量有限、工作負債很低，故運營端功能全部設計在一個微服務內實現，包括以下管理能力：

(1)商戶管理包括新建商戶，商戶審核，商戶查詢，商戶信息的修改、刪除、停權、恢復啟用，審核歷史等功能。

(2)商品管理提供每家商戶可售商品或服務的管理能力，具體包括商品的新建、批量上傳導入、商品審核、商品詳情展示、商品上架、商品下架、渠道價格等功能。

(3)品牌管理主要完成整個系統的品牌、一級類目、二級類目等新增、修改、刪除，以及審核、審核日志查詢等功能。

(4)廣告管理完成開放權益平臺廣告位的查詢、新增、修改、啟用、禁用、送審、審核、審核日志查詢等功能。

(5)公告管理功能完成開放權益平臺公告信息的新建、刪除、列表查詢、詳情查詢、送審、審核等功能。

(6)審核管理功能完成開放權益平臺各項配置活動的審核操作，所有培訓功能的新建、刪除和修改，必須經過送審、審核等功能后才能生效。

(7)訂單管理主要完成系統的訂單查詢功能、可以支持商戶、用戶、品牌、商品、日期、品類、訂單金額、商品名稱等多個維度進行訂單查詢展示，其訂單實際存儲在組織級的訂單微服務數據庫中，由訂單管理功能通過訂單微服務獲取展示。針對每一筆訂單，可以展示訂單詳情，并執行退款操作。

4.2.5 訂單微服務

訂單微服務包括一些定時執行的批量程序，主要處理訂單中心和開放平臺之間在訂單上的一些狀態同步功能。

(1)自動退款管理。用戶支付訂單后，從商戶處獲取權益發放給客戶，如果該過程中發生錯誤，獲取權益失敗，無法按預期發放購買的權益，就會按約定自動進行退款處理。

(2)支付狀態同步。開放平臺的訂單微服務和組織級的訂單微服務之間的訂單狀態應保持一致，但在實際運轉過程中有時會產生兩邊狀態不一致的情況，需要進行對賬處理，確保狀態一致。

(3)退款狀態同步。在開放平臺執行退款操作后，需要把該筆訂單的退款狀態同步到組織級的訂單未付，確保訂單狀態一致。

5 結語

采用微服務的設計模式，直接復用已經開發好的組件，不僅能節約開發成本和時間、提高質量，還能滿足組織中用戶統一、訂單統一、風控策略統一等要求，極大地提升軟件開發的成熟度。基于微服務的技術架構對開發和運維的要求較高，更多的微服務需要部署更多的資源、提高運維要求，在確認拆分微服務時要平衡好開發和運維的矛盾，合理、適度地拆分。

通過構建開放卡券銷售平臺，對所有卡券類服務均在一個平臺進行管理，降低了運營成本，極大地提升了運營效率，新場景能力的構建和發布頻率從原來的至少3個月縮短到目前的2周，顯著降低了開發周期和開發成本，具有良好的經濟效益。