本文將對Summit系統的實現進行一個概述性的介紹。Summit系統從架構上來說是很優秀的,我的認爲其架構師的想法很是好,固然也設計出來了。但在實現的時候就沒那麼美好了,Summit系統的實現比較複雜,比較麻煩,感受跟架構師的想法有很大出入。若是你作過Summit項目,再深刻到細節,你就會感受到噁心了,由於Summit實現細節真的很爛。但我是站上如今的技術基礎上開了上帝視角看一個存在了30年系統,有點站着說話不腰疼。我的而言,仍是比較佩服Summit架構師的,爲它的實現感到可惜。當前,筆者認爲Summit系統的架構正在向分佈式方向演進,由於它開始大量採用MQ、Web Service這些下降耦合的方式來優化架構了。數據庫
筆者今天要介紹的內容,是Summit系統實現的各個模塊,以及模塊之間的交互方式。本文站在架構師角度描述各個模塊之間的關係,不會涉及具體細節,所以,仍是能夠感覺到Summit系統架構的優秀之處:後端
Summit系統按照MVC來劃分的話,能夠分紅View層即客戶端/表單;Control層包含負責通信的Web Service、負責業務邏輯的動態庫/程序;Model層包含數據抽象層及持久化層。session
Summit系統通過多年的架構優化,在V6.0及以後的版本中,將以前版本採用的CORBA模塊替換成Web Service(aixs2實現)。這是Summit系統向分佈式架構演進的體現之一。架構
進一步劃分的話,能夠分紅如下模塊:分佈式
序號工具 |
分層性能 |
模塊優化 |
說明設計 |
13d |
View |
Summit FT |
Summit系統客戶端 |
2 |
Control |
ETK Web Service |
建立、銷燬會話(HTTP會話) |
3 |
Middle Web Service |
負責HTTP會話報文與Web Service Soap報文之間的轉換 |
|
4 |
Naming Web Service |
負責Web Service的註冊、查找;負責客戶端會話與後臺etkservice進程之間的註冊、查找(會話保持) |
|
5 |
Generate ID Web Service |
產生全局惟一ID的Web Service |
|
6 |
MQ |
消息中間件(服務之間的鬆耦合) |
|
7 |
etkservice |
用戶HTTP請求後臺服務進程 |
|
8 |
Model |
database |
持久化數據庫 |
9 |
N/A |
STP Service |
Summit系統事件處理服務 |
10 |
N/A |
BVS Service |
Blotter View Server,即實時刷新服務 |
1 |
N/A |
Sequencer |
Summit系統事件發佈服務 |
12 |
N/A |
SMT |
Service Management Tool,即STP/BVS服務管理工具 |
前文提到,Summit系統先後端通信協議是HTTP。首先,HTTP協議是無狀態的,所以Summit系統須要提供一套相似於Web Server的會話服務。這個就是Summit Naming Service的做用。Summit Naming Service提供服務的註冊和查詢功能,Summit利用此服務來提供會話服務;其次,Summit後端功能都是用C/C++開發的,如何利用後端的C/C++提供HTTP服務呢?Summit採用的是Web Service的方式。Summit後端提供了etkservice,這是一個Web Service服務端程序,啓動進程後,會經過一個端口服務某個用戶會話。Summit會爲每一個客戶端鏈接啓動一個etkservice進程來提供服務,利用Middle Web Service將HTTP請求內容轉換成SOAP(Web Service)請求並轉發給相應的etkservice進程。etkservice進程處理完成後,結果經過SOAP報文能加給Middle Web Service,進而轉換成HTTP報文返回給客戶端。不只如此,Middle Web Service負責全部前、後端交互的HTTP報文 <-> SOAP報文之間的轉換工做。
Summit系統不只提供了用戶操做的基石,同時提供工做流和數據的生命週期管理的功能。這些功能是由STP服務來完成,STP服務即事件處理服務。STP服務會訂閱系統事件,每當Sequencer發佈系統事件時,訂閱了相應事件的STP服務即會工做,完成自動化的處理任務。常見的STP服務如現金流產生服務、支付報文產生服務、額度計算服務、頭寸計算服務、合規檢查服務等。
Summit系統將Generate ID獨立出來做爲一個Web Service也是其架構向分佈式演進的體現。Generate ID服務用來生成全局惟一的ID。Summit會爲其保存或管理的數據分配一個全局惟一的ID,其內部包括事件生成、分發、存/取,都是以此ID做爲標識,這些ID所有由Generate ID來生成。所以,Generate ID會向Naming Service註冊本身,而且全部Generate ID服務註冊名是同樣的,以此來保證只有一個實例提供服務。
MQ做爲消息中間件來處理STP訂閱、BVS消息發佈和Sequencer的事件發佈。當前,Summit通常採用Active MQ實現。當STP服務啓動時,會首先在ActiveMQ對應的隊列訂閱相應的事件;Sequencer服務檢索到事件發生時,會向MQ發佈事件。MQ將事件廣播到對應隊列,供相關的STP服務處理。BVS服務啓動後,會監聽BVS請求隊列,當Summit FT中,用戶打開Blotter view時,會發送一個BVS請求。BVS服務根據訂閱數據篩選條件,將篩選的數據不斷推向BVS響應隊列。
最後,Summit系統提供了一個用來管理全部的STP服務及Sequencer服務。STP因爲是監聽器的角色,所以其是長時間運行的,這就須要提供一個管理工具,來監控各個STP服務的。Service Management Tool(SMT)就是這樣一個管理工具。提供了基本的服務啓動、中止、新建、刪除的功能。
上文靜態地介紹了Summit系統的各個模塊,接下來,筆者將會介紹在Summit系統運行時,各個模塊之間的交互協議以及方式,對於不一樣的操做,調用的模塊不一樣,交互的方式也不一樣,所以,筆者選取了如下幾個典型場景,來講明交互過程:
操做過程是指用戶登錄成功後,在Summit FT客戶端進行相關的操做,好比點擊按鈕、訂閱實時消息操做。此時的交互方式與登錄有所差異。
筆者將Summit系統的事件分紅2個大類,第一類由Sequencer服務產生,產生後推向MQ隊列並由STP服務來處理;第二類由用戶產生自Summit FT,好比打開了Blotter View來訂閱實時數據,此類事件由BVS服務處理。所以,筆者將分紅2個部分來講明Summit的事件處理過程。注:爲使交互圖清晰,省略了前文提到的部分步驟及相關服務。
Sequencer事件使用黑底白色表示:
Summit系統架構在不斷地演進,從6.0開始大量引入分佈式的架構和組件,好比使用MQ去除服務耦合;將服務作成WebService;引入Naming Service等。相信隨着架構演進,Summit系統會愈來愈優秀,性能會逐漸提升、部署更加方便、開發也也更加靈活。