基于云服務的架構設計

文/田延杰

近年來證券行業的經營模式有了巨大的改變，從營業部到網絡金融，從經紀業務到財富管理，從通道業務到信用業務，從資管、投資銀行到資本中介，從產品發行商到服務供應商等等。這些發展過程的背后都離不開數字化能力的輔助。

1 存在的問題

公司在經營工作會議強調“積極擁抱金融科技，加速向智能化、數字化券商轉型”。金融業的未來與金融科技的進步息息相關，公司應主動順應時代潮流，全面加快金融科技的創新步伐，努力建設智能化、數據化、精準化和專業化的金融服務體系。公司在積極應對的過程中，主要存在的問題：

公司內系統眾多，而部分系統之間由于建設管理部門不同等原因呈分散狀態，如需同時調用幾個系統間的信息或對信息進行綜合管理，難度較大，系統間未互聯互通，易形成信息孤島；由于歷史原因，公司的系統中涉及大量外購系統，供應商紛雜，造成技術規范不一致，數據標準不統一的現象。創新性、差異化競爭很難落地，整個技術架構相對笨重，難以敏捷、快速地響應數字化時代的需求。

業務與技術知識結構和工作視角不同，尚未形成業務、技術、管理互相成就的合理機制，難以實現跨條線、跨職能的深度協同。券商的組織架構多以牌照為中心，組織靈敏度相對較低，流程復雜冗余，效率低，協同差，尤其是經紀業務與其他業務間的協同作戰能力低，浪費了券商稟賦，如部分流程未得到固化和規范，部分流程尚有冗余，業務板塊間存在割裂，跨部門職責邊界不清晰等等。

圖1

2 云服務架構設計理解

云技術是指在廣域網或局域網內將硬件、軟件、網絡等系列資源統一，從而實現數據的計算、儲存、處理和共享的一種托管技術。在證券行業，可將業務、財務、風控等系統數據在云平臺進行整合存儲計算，進行集約化的數據管理，進而提升企業的運作效率。在云計算環境下的架構設計思想對我們提出了新的挑戰，云服務架構設計則在更大角度考慮實現軟件元素的虛擬化、結構的動態可擴展，支持部件深層對應用的支撐能力、連接按照應用場景靈活的按需分配和部署能力、整體架構的高可靠性和高性價比。

圖2

圖3

面向云服務架構設計主要從系統業務設計、系統數據設計、系統產品設計、系統應用設計和系統技術設計五個方面考慮。通過對戰略的理解展開對業務的熟悉，梳理出系統的業務，再根據設計出的業務架構分解，設計與業務架構相適應的應用和數據架構，最終通過技術架構落地。其中應用架構是中間層，起著承上啟下的作用。

3 云服務架構設計原則

3.1 兼容設計原則

企業的公有云和私有云建設進入了快車道，有很多企業數據和應用需求都在往公有云遷移，其中私有云開發建設企業的關鍵業務、內部數據、交易平臺，公有云部門開發交互類應用、創新和數字化應用。兩者逐步可以進行平滑遷移。

3.2 高可靠設計原則

根據具體的業務需求、按照地理位置、不同機房、不同服務器的同一個服務具有可持續性的服務提供能力，防范各種級別的故障隔離，圍繞訪問控制、網絡安全、數據冗余、系統并發等各方面展開，當一個故障出現，另一節點能夠實時運行，最大限度的確保業務服務的連續性，實現相同標準、相同服務、統一管理。

3.3 服務標準化原則

云服務設計體系架構是分層的，層與層之間、用戶用服務之間、服務與服務之間都應該遵循相應的接口規范和標準，而且應具備對外部服務標準進行擴展的支持能力。再者，引入微服務、云計算等業界標準，例如docker、Hadoop、NewSQL等服務標準，保證平臺的先進性。

4 具體云服務架構設計實踐

首先，業務架構設計需要從業務的需求出發，需求的產生有可能是一個部門提出的需求，也可能是總裁的一段語言描述或者一句話，列出需要解決的核心需求、未來待要解決，且具備迭代和優化的問題域。例如：

（1）公司有哪些方面的交易風險？

（2）如何識別這些交易風險？

（3）怎么樣處置這些風險？

如圖1所示，根據這些問題論證解決這些問題實現的業務目標，在解決這些問題的過程中，整理出初步答案，形成一個不太成熟的對產品的理解。

然后，對初步形成的問題域得到模糊的產品方向和功能范圍，找出所核心目標、依賴的系統、產品用戶，并且畫出業務流程圖。通過對業務流程進行分析，分析出業務功能矩陣，把具有獨立功能職責的需求進行垂直拆分，通過對業務功能矩陣進行分層，拆解成用戶層、功能層、數據層，明確不同信息層級的邊界和同一層模塊之間的邊界，通過業務間的關系明確系統間的邊界，把關于信息流動的路徑標示出來，最終整理出產品架構圖翻譯成在公司交易模式中的工作閉環。在產品架構過程中，模塊功能邊界劃分要清晰、標準化、獨立化抽象后的功能模塊、各層之間也要邊界清晰且分層合理，具備優化迭代能力。如圖2所示。

之后，從領域模型提取數據架構，數據架構的重要輸出交付就是E-R圖，它包含了數據的實體對象、關系和屬性等重要內容，可以通過ER圖建立業務對應的數據模型，數據模型的建立有賴于業務架構的輸出，通過對業務域的模型分析逐步提取出云服務的數據架構。在這個過程中首先在原流程圖基礎上把涉及到的角色、業務對象、業務規則、模型、異常事件和事務等內容整合進來，定義出領域模型的骨干模型，并且對骨干模型進行豐富和迭代，整理出領域四色模型。

技術框架設計具體考慮以下幾方面的內容，包括服務化的演進、服務的拆分、消息隊列、異構系統和數據、緩存設計、服務降級、快速回滾等幾個方面的內容。如圖3所示。

5 結論

本文從金融行業特點和存在問題出發，講述了對云服務架構的理解，然后對云服務框架的設計提出了云服務設計的三原則，通過具體系統業務架構、系統產品架構、系統產品架構、系統數據架構、系統應用架構、系統技術架構五部分的實踐設計，并通過具體的框架圖描述整個框架設計過程。通過我們的設計發現，架構的預先規劃和框架在之后的迭代演化同樣重要，沒有好的規劃就很難有一個演化的空間，沒有演化，再好的規劃也會慢慢被淘汰。在整個軟件生命周期中就要不斷的調整自己的設計，優化和迭代自己的框架體系，兼顧考慮系統各老舊、異構系統，通過各個分層之間資源、組件、框架、服務的池化，做到云架構中快速進行擴容、軟件資源的復用。