基於雲端運算架構之期貨投資策略服務-以高頻交易系統為例 - 政大學術集成

全文

(1)國立政治大學資訊管理研究所碩士學位論文指導教授：劉文卿. 博士. 政治大. ‧. ‧ 國. 學. 立基於雲端運算架構之期貨投資策略服務以高頻交易系統為例. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. 研究生：林承翰. v. 撰. 中華民國一百零三年七月.

(2) 摘要本研究應用雲端分散式的架構來建置與佈署一個處理大量使用者交易需求的高頻交易投資策略服務平台，此平台有以下特色： 1. 系統後端採用雲端 SOA 架構，將整個龐大的交易系統切割佈署到雲端叢集之上，並提供單一的 Façade 介面供外部使用者呼叫；系統前端畫面的設計遵循 Yahoo UI 嚴格的 MVC 架構規範，並保證前端的 View 與 Model 與後端的資料達成同步。. 學. 據。. ‧ 國. 2.. 治政不斷接收來自外部的即時報價訊息，並產生海量的即時市場狀態資訊，包大立含多種技術分析指標、買賣規則…等，以供高頻交易的策略作為買賣的依 ‧. 3. 利用 Java Message Service 將大量的即時市場狀態資訊快速、非同步的派送給分佈在雲端叢集各節點的系統模組，並採取 Publisher-Subscriber 的模式. y. Nat. io. sit. 來維持分散後各系統模組之間的鬆散關係。. n. al. er. 4. 多樣化的統計演算法模型可供使用者作為產生優良的個人化投資策略之. Ch. i n U. v. 依據。產生的新策略可馬上投入即時的模擬交易環境下監控與評估其策略績效。. engchi. 關鍵詞：雲端運算、高頻交易、服務導向架構、技術分析、交易策略評估、MVC 架構. I.

(3) 目錄摘要 ................................................................ I 目錄 ............................................................... II 表目錄 ............................................................. IV 圖目錄 .............................................................. V 第一章緒論 ......................................................... 1 第一節研究背景與動機 ........................................... 1 第二節研究目的 ................................................. 1 第三節研究流程 ................................................. 3 第二章文獻探討 ..................................................... 4. 政治大第一節技術分析 ................................................. 5 立. ‧ 國. 學. 第二節雲端運算 ................................................. 6 一、基本特性 ............................................... 6. ‧. 二、服務模型 ............................................... 三、部署模型 ............................................... 第三節服務導向架構 ............................................. 第四節 JMX（Java Management Extension） ......................... 一、設備層(Instrumentation)： .............................. 二、代理層(Agent)： ........................................ 三、分散層(Distributed Services)： .......................... er. io. sit. y. Nat. al. 7 7 8 8 9 9 9. n. v i n C hService） ............................. 第五節 JMS（Java Message 10 U i e h n g c .......................... 11 一、點對點模型(Point-to-Point)：. 二、發佈/訂閱模型(Publish/Subscribe)： .................... 11 第三章雲端分散式架構研究 .......................................... 14 第一節 JBoss AS 7 叢集管理機制 .................................. 15 第二節 JBoss Cluster 工作分派模型(JBoss Cluster Job Dispatching Model) ............................................................... 一、初始階段(Initial State)： ............................. 二、工作分派階段(Job Dispatching State)： ................. 三、工作操作階段(Job Control State)： ..................... 第三節 JBoss Cluster 管理與工作分派模型之結合 ................... 第四章雲端分散式架構實作 ........................................... 16 19 21 24 27 28. 第一節系統架構 ................................................ 28. II.

(4) 市場狀態室 ............................................ 資料存取室 ............................................ 規劃室 ................................................ 交易室 ................................................. 30 34 35 38. 五、下單機 ................................................ 第二節系統模組切分 ............................................ 第三節系統畫面說明 ............................................ 一、規劃室(PlanRoom) ...................................... 二、交易室(TradeRoom) ..................................... 第五章結論與未來展望 .............................................. 第一節總結 ..................................................... 43 44 49 49 52 54 54. 一、二、三、四、. 第二節未來展望 ................................................ 55 一、提高演算法、統計模型與市場狀態的豐富性 ................ 55. 治政大二、結合平行運算改善運算效能 .............................. 55 立參考文獻 ........................................................... 55 ‧. ‧ 國. 學. 三、英文參考文獻 .......................................... 55 四、中文參考文獻 .......................................... 56. n. er. io. sit. y. Nat. al. Ch. engchi. III. i n U. v.

(5) 表目錄. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. IV. i n U. v.

(6) 圖目錄圖圖圖圖圖圖圖. 1 2 3 4 5 6 7. 研究施行流程圖 .............................................................................................. 3 JMX 管理架構階層圖 ..................................................................................... 9 JMX 分散式系統架構示意圖 ....................................................................... 10 JMS 點對點模型示意圖 .................................................................................11 JMS 發佈/訂閱模型示意圖 ........................................................................... 12 JBoss Cluster 工作指派簡易示意圖-初始狀態 ........................................... 13 JBoss Cluster 工作指派簡易示意圖-啟動新工作 ....................................... 13. 圖圖圖圖圖圖. 8 9 10 11 12 13. JBoss Cluster 工作指派簡易示意圖-控制執行中的工作 ........................... 14 JBoss Domain 模式管理拓墣圖 .................................................................... 15 工作分派者-Class Diagram ........................................................................... 16 工作承接者-Class Diagram ........................................................................... 17 工作承接管理者-Class Diagram ................................................................... 18 JBoss Cluster 工作分派模型-初始階段-訊息流程圖 ................................. 19. 圖圖圖圖圖圖. 14 15 16 17 18 19. JBoss Cluster 工作分派模型-初始階段-Activity Diagram ......................... 20 JBoss Cluster 工作分派模型-工作分派階段-訊息流程圖 ......................... 21 JBoss Cluster 工作分派模型-工作分派階段-Activity Diagram ................. 23 JBoss Cluster 工作分派模型-工作操作階段-訊息流程圖 ......................... 24 JBoss Cluster 工作分派模型-工作操作階段-Activity Diagram ................. 26 JBoss Cluster 工作分派模型實作圖 ............................................................. 28. 圖 20 圖 21 圖 22 圖 23 圖 24. 本研究之系統架構圖 .................................................................................... 29 系統架構-工作分派模型採用圖 ................................................................... 30 市場狀態運算模組之 ClassDiagram............................................................. 31 市場狀態運算模組之 SequenceDiagram ...................................................... 32 市場狀態運算模組採用 JBoss Cluster Job Dispatching Model 之架構示意圖. 圖 25. 33 JBoss Cluster 切分圖-市場狀態室 ............................................................... 34. 圖圖圖圖圖圖. 26 27 28 29 30 31. JBoss Cluster 切分圖-資料存取室 ............................................................... 35 規劃室之 Use Case Diagram ......................................................................... 36 規劃室之簡易 SequenceDiagram .................................................................. 37 JBoss Cluster 切分圖-規劃室之統計模型模組 ........................................... 38 交易室之 Use Case Diagram ......................................................................... 39 交易室之簡易 Sequence Diagram ................................................................. 40. 圖 32. 交易室之代理人模式示意圖 ........................................................................ 41. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. V. i n U. v.

(7) 33 34 35 36. 策略監控模組採用 JBoss Cluster Job Dispatching Model 之架構示意圖 .. 42 JBoss Cluster 切分圖-交易室 ....................................................................... 43 下單機之 Class 與 Event-driven 示意圖 ....................................................... 44 JBoss Cluster Host 佈署圖-Host1-nccu-mgmt .............................................. 45. 圖 37 圖 38 圖 39 圖 40 圖 41 圖 42 圖 43. JBoss Cluster Host 佈署圖-Host2-nccu-n01 .................................................. 46 JBoss Cluster Host 佈署圖-Host3-nccu-n02 .................................................. 47 JBoss Cluster Host 佈署圖-Host4-nccu-n03 .................................................. 47 JBoss Cluster Host 佈署圖-Host5-nccu-n04 .................................................. 48 JBoss Cluster Host 佈署圖-Host6-nccu-n05 .................................................. 49 系統畫面-規劃室-資料前處理 .................................................................... 50 系統畫面-規劃室-資料採掘 ........................................................................ 51. 圖 44 圖 45. 系統畫面-規劃室-資料後處理與策略儲存 ................................................ 52 系統畫面-交易室-啟動策略 ........................................................................ 53. 學 ‧. io. sit. y. Nat. n. al. er. 圖 46 圖 47. 治政大系統畫面-交易室-策略監控 ........................................................................ 53 立系統畫面-交易室-模擬現況 ........................................................................ 54 ‧ 國. 圖圖圖圖. Ch. engchi. VI. i n U. v.

(8) 第一章緒論第一節研究背景與動機高頻交易主要是透過自動化的電腦程式在極短時間內快速並且大量的進出交易市場，藉此捕捉快速變化的市場價格波動，穩定的賺取其中的價差。根據市場統計(investoo.com, 2013)，美國證券交易市場的高頻交易活動在 2000 年初時只占總交易量的 10%，到了 2012 年則向上突破了總交易量的 70%。高頻交易的速度也不斷向上提升，從原本「several seconds」的等級進步到「nanosecond」等級。另. 政治大. 外，根據信報 2014 年 1 月的專欄報導(黎永良，2014)，英國與歐洲的證券投資市. 立. 場的高頻交易量也分別占了高達五成與四成之多；亞洲新興市場雖然高頻交易比. ‧ 國. 學. 率仍低，但也已經有投資者開始用高頻交易的方式來買賣金融商品。高頻交易在. ‧. 證券交易市場已儼然成為主流趨勢，而且改變了整個市場的生態，讓證券交易變成了一場速度與演算法的競賽。. y. Nat. io. sit. 在以上敘述的背景底下，本研究之研究動機：由於執行高頻交易的演算法需. n. al. er. 要很強的運算效能還有大量資料的儲存能力，導致從事高頻交易的通常都是規模. Ch. i n U. v. 比較大的證券商與大型投資機構。本研究希望發展一個散戶也能夠使用的雲端高. engchi. 頻交易服務平台，利用雲端運算的技術將較普及的 PC 等級之運算設備統合成雲端叢集，藉此得到足夠負擔高頻交易系統的運算能力與儲存空間。另一方面，也希望能藉由此平台幫助一般投資大眾發展自己的高頻交易策略，並直接在我們建立好的系統環境上作即時測試。. 第二節研究目的通常投資人會使用各種技術指標(如移動平均線、乖離率…等)來預測投資市場的走向，並搭配各種買賣規則來決定買賣的交易點。但是當觀察的技術指標與買. 1.

(9) 賣規則的種類越來越多的情況下，極有可能發生互相矛盾的市場走向預測，這時候通常需要長期的經驗累積，才能做出更精準的買賣預測，而且由人腦主導的投資行為模式很容易受到人的感情、情緒影響而產生偏差。再者，即使找到了合適的交易點，若是下交易單的速度不夠快，極有可能錯過原本預測能獲利的交易時間點。運算速度是高頻交易的決勝關鍵，雲端運算的技術無疑是讓一個高頻交易系統變得更有競爭力的一項利器。綜合以上，本研究的主要目的是以雲端運算為基礎，發展出一套符合服務導向架構特性的高頻交易服務平台。. 政治大. 此平台打算解決以下的問題：. 立. 1. 高頻交易需要高運算效率與海量的資料存取效能，想滿足這些需求需要購. ‧ 國. 學. 置昂貴的資訊設備。. 2. 高頻交易的參與者大部分是具有規模的投資機構，一般的投資散戶比較沒. ‧. 有一個安全可靠的高頻交易投資平台。. Nat. sit. y. 此平台具備以下的特色：. n. al. er. io. 1. 多樣化、易擴充的演算法模組可以幫助投資經驗比較薄弱的投資人利用歷. i n U. v. 史資料建立統計模型來預測未來的市場走勢，用自動化的方式來產生策略，並協助訓練、改善策略的績效。. Ch. engchi. 2. 提供一個讓普羅大眾運行高頻交易策略的環境，並在策略找到適合的買賣點的時候自動化、快速地做買入賣出的動作，並隨著即時回報的累積不斷更新策略的績效報表。 3. 以各式開放原始碼的解決方案建構整個平台的三層式架構，後端的系統邏輯遵循 JMX(Java Management Extension)協定設計系統架構，將系統切分成數組服務單位以利於分散式的佈署；前端畫面則嚴格的遵循 Yahoo UI 的 MVC 架構建置；資料存取層則是採用 Non-SQL 的 Big Data 設計。希望藉此發展出一套適合高頻交易的雲端服務導向架構。. 2.

(10) 第三節研究流程定義問題. 文獻探討. 交易資料蒐集. 建立策略回測與模擬交易平台. 政治大. 立. ‧ 國. 學. 進入即時的模擬交易環境並評估整體效率. y. ‧. Nat. n. al. sit er. io. 結論與未來方向研究. Ch. 圖 1. i n U. 研究施行流程圖. engchi. v. (資料來源：本研究整理) 步驟一：定義問題。針對台灣期貨市場，提供多種以技術指標為基礎的演算法模型幫助投資者發展客製化的投資策略，並提供歷史回測與即時模擬的環境讓使用者得以快速得到策略績效表現的回饋。步驟二：文獻探討。整理證券技術分析的定義與相關理論，並介紹本研究系統平台所採用之雲端運算、服務導向架構與前端介面設計之 MVC 架構之相關技術與細節。步驟三：交易資料蒐集。本研究與外部金融機構合作，接通了來自外部的即時. 3.

(11) 期貨報價資訊源，並以其中的台指期商品之報價來運算產生即時的技術指標、買賣規則…等市場狀態的資料。即時的市場狀態資料將支援即時模擬環境下的投資策略做最佳買賣時機的判斷；批次儲存到資料庫中的歷史市場狀態資料則做為演算法模組的輸入資料，用以幫助使用者產生新的投資策略。步驟四：建立策略回測與模擬交易平台。基於文獻探討中所討論介紹之各項理論與雲端系統之建構技術，設計出符合高頻交易的高運算、高儲存能力需求與遵循雲端運算框架之整合性系統架構，進而實作開發。整個. 政治大. 投資策略平台將依據 SOA 架構切割成多個服務單位並分散佈署在雲. 立. 端環境中，所有的使用者請求將透過單一的 Façade 窗口處理，再由. ‧ 國. 學. Façade 因應需求呼叫對應的 Command，最終才由 Command 來串聯被請求的服務單位之功能，由此整合一個完整的服務流程。. ‧. 步驟五：進入即時的模擬交易環境並評估整體效率。在策略回測與模擬交易平. Nat. sit. y. 台完成後，將進一步整合即時報價資訊源與模擬交易所的下單介面，. n. al. er. io. 最後匯入測試用的高頻投資策略，使其在即時的模擬交易環境下運行. i n U. v. 並記錄策略之績效。本研究在此階段將依據系統各個流程的 LOG 檔. Ch. engchi. 評估系統之設計架構是否能達到高頻交易之運算要求。步驟六：結論與未來方向研究。探討本研究對於高頻交易與雲端技術方面之發現與貢獻，並對於整個研究內容、系統平台所面臨的困難與不足之處，提出可行的改善方案及未來研究方向。. 第二章文獻探討. 4.

(12) 第一節技術分析技術分析（Technical Analysis）可分成兩大類型，分別為圖形分析與指標訊號（Robert D., 1998）。圖形分析是指運用圖表技術，將原始的證券金融市場價格與交易量的趨勢軌跡轉換成容易分析的圖表形式；指標訊號則是設計出一套統計分析的數量指標來呈現特定時段內的投資市場狀態。投資者觀察這些圖表與技術指標的變化模式與走勢規律來預測未來證券市場價格的走向，藉此找出最佳的買賣時機。技術分析不去細究市場價格變動的原因，而是直接觀察市場價格面的變化趨勢。. 政治大. 根據西方技術分析專家 Robert D.與 John Magee 的觀點，技術分析的理論依據. 立. 奠基於以下幾點：. ‧ 國. 學. 1. 市場上的證券價值主要是由商品本身的供給與需求之間的關係決定的。. ‧. 2. 證券交易的價格、成交量、漲跌家數、漲跌時間長短…等市場行為的表現是投資者考量過諸多市場環境因素後進行交易的結果。所以技術分析只需要分析與研. y. Nat. io. sit. 究市場行為，而無須搜尋和分析背後的影響因素。. n. al. er. 3. 證券的價格有其變動的趨勢存在，利用技術指標或者圖形分析可幫助確認目前的價格趨勢與反轉的訊息。. Ch. engchi. i n U. v. 4. 歷史會不斷地重演，投資者會出於追求利潤的目的，不斷的重覆一定模式的交易行為。（Robert D. & John Magee, 1998）本研究採用了移動平均（Moving Average）、平滑移動平均線(Exponential Moving Average，EMA)、乖離率（BIAS）、隨機指標（Stochastic， KD Line）、威廉指標（WMS%R）、趨向指標（Directional Movement Index，DMI）、動量指標（Momentum Index，MTM）、震盪量指標（Oscillator，OSC）及相對強弱指標（Relative Strength Index）、人氣指標(AR)、布林軌道線(Bollinger Band)、價格動量指標(CR). 5.

(13) 等十多種常見的技術指標作為系統內部產生市場狀態資料之依據，系統上運行的交易策略將視市場狀態的變化決定是否產生買賣的交易訊號。. 第二節雲端運算根據美國國家標準局(NIST)所訂定之雲端運算的標準定義：雲端運算是一種無所不在、方便、隨需即取的網路，運算資源可以以低管理成本被快速地供應與釋出。消費者在雲端網路上共享運算資源(ex:網路、伺服器、儲存空間、應用程式、服務...等) ，且過程中不需要與雲端服務供應者有互動。美國國家標準局對雲端運算更細部分類後，分為有五項基本特性、三種服務模式以及四種部署模型並且分述如下。. 立. 學. ‧ 國. 一、基本特性. 政治大. （一）隨需即取服務 (On-demand self-service)：. 互動行為。. ‧. 使用者可自由地隨需求使用雲端服務，而過程中不需要與雲端服務提供者有. y. Nat. io. sit. （二）廣泛的網路可及性(Broad network access)：. n. al. er. 無論連結裝置的規格大小，只要透過標準機制便可隨時隨地透過網路使用雲端網路服務。. Ch. engchi. i n U. v. （三）資源彙整(Resource pooling)：. 雲端服務供應者可透過多重租賃模式服務多個消費者，並根據需求指派或者重新分派實體與虛擬的運算資源。消費者通常不知道運算資源的實際存放位置，只可能掌握國家、州或資料中心等區域範圍。（四）高度彈性(Rapid elasticity)：雲端資源可以被快速與自動地根據需求調整規模大小。對消費者而言，雲端似乎是永無止盡的，可以隨時調整雲的大小。. 6.

(14) （五）計算服務(Measured service)：雲端服務各層次均由雲端供應者掌控與監管，雲端資源的使用可以被監控、計量，這提高了消費者與服務提供者之間的服務透明性。. 二、服務模型（一）軟體即服務(Software as a Service, SaaS)：此服務模型讓消費者可以直接透過各種連接裝置來使用服務供應者建置在雲端基礎建設上的應用軟體，消費者無需管理作業系統、硬體或運作的網絡基礎架. 政治大（二）平台即服務(Platform as a Service, PaaS)：立構。. ‧ 國. 學. 此服務模型是由服務提供者提供程式語言、函式庫、工具程式與雲端平台... 等支援，讓消費者可以便利與快速地將自行開發或取得之程式佈署於雲端之上。. ‧. 消費者管理運作應用程式的環境也擁有主機部分掌控權，但並不掌控作業系統、. io. er. （三）基礎建設即服務(Infrastructure as a Service, IaaS)：. sit. y. Nat. 硬體或運作的網絡基礎架構。. al. 此服務模型直接提供消費者處理器、儲存空間、網路、....等「基礎運算資源」，. n. v i n Ch 讓消費者可利用這些資源佈署或者執行任意軟體(包含作業系統與應用程式)。消費 engchi U 者不掌控雲端基礎架構，但能掌控作業系統、儲存空間、已部署的應用程式及網絡元件（如防火牆、負載平衡器等）。. 三、部署模型（一）私有雲(Private Cloud)：在該模型下，雲端基礎建設為非公開的，且只供特定單一組織下的成員使用，且可能被該組織、或者第三方組織、或以上兩者同時管理。. 7.

(15) （二）社群雲(Community Cloud)：在該模型下，雲端基礎建設的使用者為特定社群之成員，社群成員在共同的目標下共用雲端資料及應用程式。（三）公有雲(Public Cloud)：在公有雲的模型下，雲端資源被開放給公眾客戶使用，並由服務提供者做使用者權限控管。（四）混合雲(Hybrid Cloud)：混合雲模型綜合了多種的雲模型(私有雲、社群雲或者公有雲)。其中，組合的. 政治大. 雲之間仍然保持其原有特性，並依照標準化或者專屬的技術相互結合。. 第三節服務導向架構. 立. ‧ 國. 學. 服務導向架構(Service Oriented Architecture, SOA)可以被視為一種架構典範或. ‧. 者架構風格，且提供一種設計框架來整合不同的應用程式，並將整合的功能以網路服務的形式展現給使用者。再者，SOA 可以將一個規模龐大的系統打散成為不. y. Nat. io. sit. 同的服務集合再以各式的功能模組來實作這些服務集合，實作的過程並不侷限於. n. al. er. 特定的技術，而是透過標準化的溝通介面將各模組功能串聯起來，用以解決使用. Ch. i n U. v. 者的問題。SOA 幫助企業根據作業需求設計出有互用性的軟體程式架構，並專注. engchi. 在創造可重複利用的服務單位來結合異質與同質的系統。. 第四節 JMX（Java Management Extension） Java 管理延伸(Java Management Extension, JMX)是一種 Java 平台為應用程式、硬體設備…等資源加上管理功能的框架，專門為了「分散式系統管理」而設計。在 JMX 的定義之下，管理的架構由下到上可分為設備層、代理層與分散層此三階層：. 8.

(16) 政治大. 立. ‧. JMX 管理架構階層圖. Nat. (資料來源：IBM 2014). sit. n. er. io. 一、設備層(Instrumentation)：. al. y. ‧ 國. 學. 圖 2. i n U. v. 設備層為整個管理架構的最底層。每個可管理資源之特徵(包含資源的屬性、. Ch. engchi. 可執行的作業以及收發的通知訊息)會被 JMX 的管理介面所描述。JMX 定義這樣的管理資源為 Management Beans，也就是圖中所顯示的 MBeans。二、代理層(Agent)：代理層為整個管理架構的中間層。每台機器的 JVM 環境底下都包含一個 JMX Agent Layer，而 JMX Agent Layer 底下會有一個 MBean server。MBean server 負責管理底層 MBean 的註冊以及連接點。任何管理客戶端都必須透過 MBean server 才能與特定已註冊的 MBean 做溝通。三、分散層(Distributed Services)：分散層為管理架構的最頂層。分散層的主要功能是提供可以連到 JMX Agent. 9.

(17) Layer 的遠端接口，分別有 Connector 與 Protocol Adaptor。Connector 提供一個協定獨立(protocol-independent)、位置透明(location-transparent)的 MBean server 客戶端連結介面，如 Remote Method Invocation (RMI) connector；而 Protocol Adaptor 則提供了一個與協定相依的 MBean server 伺服器端介面，如 HTTP adapter。本研究採用了遵循 JMX 與 SOA 架構的 JBoss Application Server 作為建置整個雲端分散式運算架構的管理與佈署環境。在 JBoss 底下，MBean 為基本的管理單位。本研究將整個龐大的雲端高頻交易平台依照功能切分成數組 MBean，並將之掛載在由 JBoss Application Server 所建構的雲端叢集之上，這些 MBean 可以被視. 政治大. 為 SOA 架構底下定義的「Service」。. 立. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. 圖 3. Ch. engchi. i n U. v. JMX 分散式系統架構示意圖 (資料來源：本研究整理). 第五節 JMS（Java Message Service） Java 訊息服務(Java Message Service, JMS)是一種可以讓 Java 應用程式創造、傳送、接收以及閱讀訊息的 Java API。JMS 由 Sun 與其他的中介軟體提供商共同設計，並提供了通用的訊息交換介面讓不同的 JMS 實作產品可以互相溝通。JMS 提供 Java 程式非同步與可靠的訊息交換能力，並進一步讓程式之間的互動可以達到鬆散耦合(loosely coupled)關係。. 10.

(18) JMS 支援點對點與發佈/訂閱的訊息交換模型：一、點對點模型(Point-to-Point)：點對點是屬於一對一關係的訊息交換模型，多個訊息接收者可以同時監聽同一個訊息佇列(Queue)，但特定的訊息只會被一個訊息接收者得到。訊息傳送者會先將訊息傳送到 JMS Server 下的特定訊息佇列，接著再由 JMS Server 連續地將佇列中的訊息傳送給正在監聽該佇列的訊息接收者。假如同時有多個接收者在監聽該佇列，則 JMS Server 會依照「先來者優先」的原則來決定將訊息傳送給哪個接收者；假如沒有接收者監聽該佇列，則訊息會被保留在佇列中，直到有訊息接收者來監聽該訊息佇列為止。. 立. 政治大. ‧. ‧ 國. 學 er. io. sit. y. Nat. n. al. Ch. 圖 4. engchi. i n U. v. JMS 點對點模型示意圖. (資料來源：本研究整理) 二、發佈/訂閱模型(Publish/Subscribe)：在發佈/訂閱模型中，訊息訂閱者需要事先訂閱有興趣的主題(Topic)，然而當訊息發佈者傳送訊息到該主題的時候，所有訂閱該主題的訊息訂閱者都會接收到同樣的訊息。主題與訊息訂閱者之間是一對多的關係，且存在於主題中的訊息會. 11.

(19) 被保留到所有訂閱該主題的訂閱者都收到該訊息為止。. 學. 圖 5. JMS 發佈/訂閱模型示意圖 (資料來源：本研究整理). Nat. io. sit. y. ‧. ‧ 國. 立. 政治大. n. al. er. 本研究於系統架構中應用發佈/訂閱模型來完成系統各模組之間的鬆散訊息交. Ch. i n U. v. 換，並採用了遵循 JMS 框架、開源、支援多協定、且可內嵌的非同步訊息交換系. engchi. 統的訊息交換系統-HornetQ。HornetQ 在訊息交換的工作上有非常高的效率與彈性，同時支援叢集的訊息交換模式，讓叢集內的各個節點只透過訂閱特定的訊息主題，就可以非同步、鬆散地接收到跨機器的訊息。除了資訊交換的議題，本文亦應用了 HornetQ 的 Point-to-Point 訊息交換模式來控制雲端叢集內的工作流程，以下為簡易示意圖(詳細的工作指派模型請參閱本文的第四章內容。)：. 12.

(20) 立. 政治大. ‧ 國. 學 JBoss Cluster 工作指派簡易示意圖-初始狀態. 圖 6. ‧. (資料來源：本研究整理). n. er. io. sit. y. Nat. al. 圖 7. Ch. engchi. i n U. v. JBoss Cluster 工作指派簡易示意圖-啟動新工作 (資料來源：本研究整理). 13.

(21) 立. ‧ 國. JBoss Cluster 工作指派簡易示意圖-控制執行中的工作. 學. 圖 8. 政治大. (資料來源：本研究整理). ‧. er. io. sit. y. Nat. 第三章雲端分散式架構研究. 就原本設計的目的來看， JBoss Application Server 的主要用途是做為分散式的. n. al. i n U. v. 系統管理之用，讓系統開發者可以簡單、便利的將系統遵循 SOA 架構拆散並將 JBoss Application Server 作為佈署分散程式的容器。然而，JBoss Application Server 並沒有將分散式運算的概念納入其設計之中，對於在整個雲端叢集上大量的動態. Ch. engchi. 增加、減少運算用節點的功能沒有足夠的支援度，同時也欠缺對分散運算工作散與收斂運算結果的管理功能。為了彌補 JBoss Application Server 於分散式運算管理之不足，本研究將在 JBoss 的 Cluster 管理功能之上再建置一層工作分派的模型架構，希望能在原來的 JBoss Cluster 管理架構之下衍生出可行、易用的分散式運算管理架構。在這個章節，我們將依序提到 JBoss 的叢集管理機制、叢集中的工作與訊息派送機制與工作分派模型之實作..等雲端分散式運算架構的管理議題來做介紹。. 14.

(22) 第一節 JBoss AS 7 叢集管理機制 JBoss 支援兩種啟動模式-standalone 與 domain 模式。在 standalone 模式下，每個 JBoss Application Server 的 Instance 都是一個獨立運行的 Process；而在 domain 模式下，多個 JBoss Application Server Instance 被歸納在一個 Domain(應用程式範疇)之下集中管理，此模式適合用來建置跨機器的雲端叢集。本研究利用 JBoss 的 domain 模式為基礎來建置高頻交易策略服務平台。domain 模式的運作機制如下圖所示：. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. 圖 9. i n U. v. C h eDomain JBoss hi n g c模式管理拓墣圖 (資料來源：本研究整理). ●Host：代表一台實體或者虛擬的機器。 ●Server Instance：代表一個獨立的 JBoss Application Server 的 Process，可以將 MBean 程式佈署於其上執行。Server Instance 可以視為 Cluster 概念中的 Node。 ●Server Group：是一個跨機器的抽象管理概念，可以依照工作性質將 Server Instance 分類成多組 Server Group。同一 Server Group 底下的 Server Instance 都運行相同的 MBean 程式。 ●Host Controller：負責管理 Host 上所有 Server Instance 的管理 Process。 ●Application Domain：整個應用程式的系統管理範疇，同個 Domain 下的 Host Controller 都遵循相同的管理政策。 ●Domain Controller：Domain 底下特別且唯一的 Host Controller，扮演集中管理者. 15.

(23) 的角色，並與其他 Host Controller 溝通，確保它們之下的 Server Instance 都遵循相同的管理政策。. 第二節 JBoss Cluster 工作分派模型(JBoss Cluster Job Dispatching Model) JBoss Application Server 的叢集管理機制讓我們得以將龐大的系統切割成 MBean 並分散佈署在多台機器之上，但分散的 MBean 也增加了系統工作流程的管理與資料分享的難度。針對此一議題，本研究將 HornetQ 的 Point-to-Point 的訊息交換模式加以搭配應用，進而設計出一套專屬於 JBoss 分散式叢集的工作分派模型。在此分派模型之下，每一項系統的工作都會有三種角色：工作分派者(Job Dispatcher，在後文將會以 JD 簡稱之。)、工作承接者(Job Handler，在後文將會以 JH 簡稱之。) 與工作承接管理者(Job Handler Manager，在後文將以 JHManager 簡稱之。)。 JD 與 JH 之間以 Point-to-Point 的方式利用訊息 Queue 來傳遞工作請求、工作. 政治大相關資訊與工作回報。一個立JH 可以同時運行、管理多個相同性質的 Job，系統管. ‧ 國. 學. 理者可以為 JH 設定所能管理的最大 Job 數量。而 JHManager 則是控制要在一個 Host 上動態產生多少個 JH 實體來作為分散運算用的節點，JHManager 能控制其所產生之 JH 物件實體的初始化、啟動…等流程，並保存、管理 JH 物件的實體參考。. ‧. er. io. sit. y. Nat. 以下為 JD、JH 與 JHManager 的類別圖與說明(JD、JH 與 JHManager 三者之間的關係請參照本文 P. 13 圖 6 所示。)：. n. al. Ch. 圖 10. engchi. i n U. v. 工作分派者-Class Diagram. (資料來源：本研究整理) ●memberToJobRelations：用來儲存 Member 與 Job 物件之間的關係。Key 值為使用者帳號-MemberID；. 16.

(24) Value 值為 Job 物件的 ID-JobID。 ●nsjrqProducer： nsjrq 指得是「非特定處理對象工作請求佇列」(Non-Specific Job Request Queue，在後文將以 N-SJRQ 簡稱之。)。nsjrqProducer 為一個專門將訊息發佈到 SJRQ 的 JobMessageProducer。 ●sjrqProducers： sjrq 指得是「特定對象工作請求佇列」(Specific Job Request Queue，後文將以 SJRQ 簡稱之。)。sjrqProducers 用來紀錄 Job 物件與其專用之 JobMessageProducer 之間的關係。Key 值為 JobID；Value 值為 JobMessageProducer 物件的實體。 ●responseConsumer： jrq 指得是「工作回報佇列」(Job Response Queue，在後文將以 JRQ 簡稱之。)。 responseConsumer 是一專門監聽 JRQ 的 JobResultConsumer。. 立. 政治大. ‧. ‧ 國. 學 er. io. sit. y. Nat. n. al. Ch. 圖 11. engchi. i n U. v. 工作承接者-Class Diagram. (資料來源：本研究整理) ●nsjrqListener：每個 JH 物件皆有一個 nsjrqListener 用以接收來自 N-SJRQ 的非特定對象之工作請求訊息。 ●sjrqListeners： sjrqListeners 存放所有 Job 物件專用的 JobQueueListener，每個 JobQueueListener 都監聽一專用的 SJQR。Key 值為 JobID；Value 值為 JobQueueListener 的物件實體。 ●responseProducer：每個 JH 物件皆有一個 responseProducer 統一將 JH 物件所有欲回報給 JD 的訊. 17.

(25) 息都發佈到 JRQ 之上。 ●handlingJobs： handlingJobs 存放目前在該 JH 物件實體上運行的所有 Job 物件。Key 值為 JobID； Value 值為 Job 物件的實體。 ●jobCounts： jobCounts 紀錄目前在該 JH 物件實體上運行的總 Job 數量。 ●capability： capability 代表該 JH 物件所能容納運行的 Job 物件最大數量。. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. 圖 12. i n U. v. 工作承接管理者-Class Diagram. Ch. engchi. (資料來源：本研究整理). ●jhPool： jhPool 為集中存放此 JHManager 所動態產生的所有 JH 物件實體的一資料結構。 Key 值為 JHID；Value 值為 JobHandler 的物件實體。 ●jhCount： jobCount 代表此 JHManager 在啟動之初將會動態產生的 JH 物件實體的數量。在 JHManager 啟動時，將讀取外部的設定檔來指派 jhCount 實際的數值。 JBoss Cluster 工作分派模型有以下三個階段：初始階段(Initial State)、工作分派階段(Job Dispatching State)與工作操作階段(Job Control State)。. 18.

(26) 一、初始階段(Initial State)：在初始階段，工作分派模型主要用到兩個訊息交換佇列-非特定處理對象工作請求佇列(Non-Specific Job Request Queue，在後文將以 N-SJRQ 簡稱之。)與工作回報佇列(Job Response Queue，在後文將以 JRQ 簡稱之。)。N-SJRQ 的主要用途是暫存並轉送 JD 所分派出來的工作請求，由於是採用 HornetQ 的 Point-to-Point 訊息交換模式，一件系統工作只會給唯一的一個 JH 來處理。JRQ 的用途則是讓所有的 JH 將欲回報的工作結果或者狀態資訊統一集中回傳給 JD。一開頭，JHManager 將讀取外部設定檔的資料並依據設定內容建立特定數量的 JH 物件實體。而 JD 與 JH 在初始階段的工作，就是先初始化其用來與 HornetQ 交換資訊的 Producer 與 Consumer 成員，以準備好處理下一階段的工作分派流程。. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. 圖 13. Ch. engchi. i n U. v. JBoss Cluster 工作分派模型-初始階段-訊息流程圖 (資料來源：本研究整理). 19.

(27) 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. 圖 14. Ch. engchi. i n U. v. JBoss Cluster 工作分派模型-初始階段-Activity Diagram (資料來源：本研究整理). 20.

(28) 二、工作分派階段(Job Dispatching State)：在工作分派階段，使用者藉由外部 Client 發出的工作請求會透過 Façade 轉送給對應工作性質的 JD，JD 將工作請求轉換成 Job Message 後，再透過 N-SJRQ 將 Job Message 分派出去，由眾多事先監聽 N-SJRQ 的 JH 程式的其中一者接收到訊息後開始整個工作的流程。. 立. 政治大. ‧. ‧ 國. 學 y. Nat. io. sit. JBoss Cluster 工作分派模型-工作分派階段-訊息流程圖. n. al. (資料來源：本研究整理). (1-1)：. Ch. engchi. er. 圖 15. i n U. v. JD 接收到來自 Façade 的工作請求，開始執行啟動工作的操作，將外部工作請求轉換成相對應的 Job Message。 (1-2)： JD 透過 JobMessageProducer 將 JobMessage 發佈到 N-SJRQ 上。 (1-3)：由於採用的是 Point-to-Point 的訊息交換模式，多個事先監聽 N-SJRQ 的 JH 程式，最終只會有其中一者接收到 JobMessage。 (1-4)：接收到 JobMessage 的 JH 依據訊息的內容，建立新的 Job 物件的實體，並開始執行整個工作流程。 (1-5)： JH 在啟動一個新的 Job 物件後，為因應未來 JD 可能會有針對特定 Job 的操作請求，所以同時會建立並監聽一個 Job 物件專用的「特定對象工作請求佇. 21.

(29) 列」(Specific Job Request Queue，後文將以 SJRQ 簡稱之。) (1-6)： JH 啟動新的 Job 物件實體並監聽 SJRQ 後，會將啟動的 Job 物件之相關訊息，例如：Job 的 ID、Job 狀態…等包裝成 ResponseMessage，再透過 JH 底下的 JBossResultProducer 成員將 ResponseMessage 發佈到 JRQ 之上。 (1-7)： JD 底下的 JobResultConsumer 成員接收到來自 JRQ 的 ResponseMessage，並上呈給 JD 處理。 (1-8)： JD 接收到 ResponseMessage 後，將以訊息內部包含的 JobID 與 MemberID 為依據，來配對運行中的 Job 物件與系統的使用者，用以確認 Job 物件的請求者是哪一個系統使用者。這層配對關係將以一個 HashMap 的形式保存，Key 是工作物件的 JobID；Value 則是使用者的 MemberID。 (1-9)：. 立. 政治大. ‧ 國. 學. 由於使用者可能會有以運作中、已啟動的工作物件為對象的系統操作需求，所以 JD 在紀錄 JobID 與 MemberID 的配對關係後，將為新啟動的 Job 物件建立一個專用的 JobMessageProducer。於此之後，凡是使用者想要對該 Job. ‧. 物件做出操作請求時， JD 都將透過專用的 JobMessageProducer 發送 JobMessage 到特定的 SJRQ。 (1-10)： JD 將接收到的 Job 相關資訊回傳給 Façade，再由 Façade 端回報給使用者端。. n. er. io. sit. y. Nat. al. Ch. engchi. 22. i n U. v.

(30) 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. 圖 16. Ch. engchi. i n U. v. JBoss Cluster 工作分派模型-工作分派階段-Activity Diagram (資料來源：本研究整理). 23.

(31) 三、工作操作階段(Job Control State)：在工作操作階段，工作請求的對象是已經運行中的 Job 物件，而請求的項目通常是要終止、查詢或者調整 Job 的工作流程。不過由於 JD 並沒有記錄每個既有的 Job 是在哪些 JH 上執行，所以需要先提供 JobID 作為索引，讓 JD 可以找到特定 Job 物件專用的 JobMessageProducer 後再透過 SJRQ 將工作請求傳達給特定的 JH 與其底下運作中的 Job 物件。. 立. 政治大. ‧. ‧ 國. 學 sit. y. Nat. er. JBoss Cluster 工作分派模型-工作操作階段-訊息流程圖. io. 圖 17. n. a l(資料來源：本研究整理) i v n Ch U engchi. (1-1)：. JD 接收到來自 Façade 端的工作操作請求(包含 JobID)，開始執行對應的操作函數，將外部工作請求轉換成相對應的 Job Message。 (1-2)： JD 透過 JobID 找到該 Job 專用的 JobMessageProducer，並藉由它傳遞 JobMessage 到對應 JobID 的 SJRQ 之上。 (1-3)：運行該 Job 之 JH 將會透過 JobQueueListener 接收到來到 SJRQ 的 JobMessage，並通知 JH 對找出指定的 Job 物件。 (1-4)： JH 找出對應的 Job 物件，並依據 JobMessage 內中的設定資訊來執行對應的操作方法。 (1-5)：. 24.

(32) 當 JH 執行完 JobMessage 所要求的特定 Operation 後，將結果轉換成 ResponseMessage 的形式，再透過 JobResultProducer 將之發佈到 JRQ 之上。 (1-6)： JD 端的 JobResultConsumer 收到來自 JRQ 的 ResponseMessage，並上呈訊息給 JD 物件。 (1-7)： JD 在得到此次工作操作請求的 ResponseMessage 之後，更新 JD 端所記錄的 Job 相關訊息，例如：執行停止 Job 的操作的情況，則在收到 ResponseMessage 後，將 JD 端所紀錄的該 Job 與 Member 之間的關連移除掉。 (1-8)： JD 將本次操作之最後結果回傳給 Façade，再由 Façade 回報給使用者端。. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. 25. i n U. v.

(33) 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. 圖 18. Ch. engchi. i n U. v. JBoss Cluster 工作分派模型-工作操作階段-Activity Diagram (資料來源：本研究整理). 26.

(34) 第三節 JBoss Cluster 管理與工作分派模型之結合介紹完 JBoss Cluster 工作分派模型的細節後，本節將敘述本研究如何在 JBoss Cluster 管理架構之上實作工作分派模型的流程。在 JBoss Cluster 的管理規範之下，相同工作性質的程式單位都必須被歸類在同一 Server Group 之下，並被佈署在 Server Instance 之上才能在 JBoss Cluster 的框架之下被執行與管理。然而，本研究所提出的 JBoss Cluster Job Dispatching Model 的三個角色：工作分派者(JD)、工作承接者(JH)與工作承接管理者(JHManager)，可依據「工作分派」與「工作承接」這兩種工作性質而被歸類到兩個 Server Group 之下。從工作分派的角度來看，在整個 Cluster 之下，對於一特定種類的工作只需要唯一的一個 JD 來掌管整個雲端叢集內部該種類工作的工作分派。而從工作承接的角度來看，JHManager 負責於單一 Host 之上動態產生並管理多個 JH 物件實體，所. 治政大 JHManager 物件負責以對於一特定種類的工作而言，在每個 Host 之上應各有一個立JBoss Cluster 的管理架構之上實作 JBoss Cluster Job 產生 JH。於此，我們可以在 ‧ 國. 學. Dispatching Model 的結構，以下圖為例，圖中表示一個由三個 Host 所組成的小型 Cluster，host1 之上佈署了一個執行 JD 的 Server Instance，host2 與 host3 之上則各. ‧. 佈署了一個執行 JHManager 的 Server Instance，JHManager 之下又管理了多個 JH 的物件實體，而 JD 與 JH 之間透過 HornetQ 跨機器的訊息通道來交換 Job 的請求與執行結果。. n. er. io. sit. y. Nat. al. Ch. engchi. 27. i n U. v.

(35) 圖 19. JBoss Cluster 工作分派模型實作圖 (資料來源：本研究整理). 第四章雲端分散式架構實作第一節系統架構本研究之系統遵循服務導向設計結構，將整體系統依據五個主要的服務功能分類切分為五個服務模組，分別為規劃室、交易室、市場狀態室、資料存取室、下單機，其中前四者都是以 Java 語言撰寫，並被包含在 JMX 的管理範疇之內；下單機則以 C#語言撰寫，並引用了外部的下單介面。而這組主要服務模組還會再依據更細部的功能往下切割成適合重覆使用與管理的服務單位。如下圖：. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. 28. i n U. v.

(36) 政治大. 立. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. 圖 20. engchi. i n U. v. 本研究之系統架構圖. (資料來源：本研究整理) 而其中市場狀態室、規劃室以及交易室之下有部分的子模組採用了 JBoss Cluster Job Dispatching Model，如下圖所示：. 29.

(37) 立. 政治大. ‧. ‧ 國. 學. n. al. er. io. sit. y. Nat 圖 21. 系統架構-工作分派模型採用圖. Ch. i n U. (資料來源：本研究整理). engchi. v. 以下將對這五大系統服務模組逐一做介紹：一、市場狀態室市場狀態室是我們整個系統資料流程的進入點，由即時報價接收器於期貨市場開市的期間不斷接收即時期貨市場報價，並將原來 Tick 單位的市場報價轉換成常用的秒、分、小時、天、月…單位的 K 線資料。接下來在市場狀態室中的市場狀態模組會以非同步的方式接收這些即時產生的 K 線資料，同時計算出各種技術指標與買賣規則…等市場狀態資料，再將這些資料透過 HornetQ 分享給其他需要的系統模組。整體來說，市場狀態室的 InputData 是外部傳入的即時報價資料， OutputData 是 K 線資料、技術指標與買賣規則的資料。市場狀態運算模組的架構設計採用了策略模式(Strategy Pattern)，請參考以下兩張圖：. 30.

(38) 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. 圖 22. Ch. engchi. i n U. v. 市場狀態運算模組之 ClassDiagram (資料來源：本研究整理). 31.

(39) 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. 圖 23. Ch. engchi. i n U. v. 市場狀態運算模組之 SequenceDiagram (資料來源：本研究整理). 這樣的設計讓程式的結構變得非常有彈性，同時也讓程式更容易維護與更新。每個市場狀態運算模組的 MBean 同時包含了所有市場狀態運算的邏輯，到了實際被啟動執行的時候才會被動態地指派實際負責的市場狀態運算邏輯。另外，由於市場狀態運算模組必須同時運算產生各種期貨商品於各種時間粒. 32.

(40) 度之下的各種市場狀態之資料，所以非常適合採用本研究所提出的 JBoss Cluster Job Dispatching Model 將之變成分散式運算的結構，讓多種市場狀態的運算可以同時處理而不用互相等待。對市場狀態運算模組而言，我們透過五種屬性來決定一個市場狀態的運算工作，分別為區域(Region，如 Taiwan，台灣)、市場(Market，如 future，期貨)、投資商品名稱(Symbol，如 TXN4，台指期)、時間粒度(Time Granularity，如 1s，以秒為單位 ) 以及市場狀態名稱 (Market State ，可以是任何技術指標 ) 。以「taiwan_future_TXN4_1s MA」為例，就是敘述一個針對台灣期貨市場的 TXN4 商品、時間單位為一秒的情況下，計算其價格之移動平均線的市場狀態運算工作。以下為採用了 JBoss Cluster Job Dispatching Model 改良後的市場狀態運算模組之示意圖：. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. 圖 24. Ch. engchi. i n U. v. 市場狀態運算模組採用 JBoss Cluster Job Dispatching Model 之架構示意圖 (資料來源：本研究整理). 若將整個市場狀態室依照 JBoss Cluster 的管理規範與 JBoss Cluster Job Dispatching Model 的結構來表現，將會如下圖所示(以下為抽象的結構表現，實際的佈署結構請詳見本章第二節-「系統模組切分」之內容)：. 33.

(41) 立. 政治大. ‧. ‧ 國. 學 sit. y. Nat. JBoss Cluster 切分圖-市場狀態室. er. io. 圖 25. n. a l(資料來源：本研究整理) i v n Ch U engchi. 二、資料存取室. 在過去的經驗中，磁碟 IO 的動作往往是造成系統整體效能瓶頸的原因之一，若是能將系統處理商業邏輯與磁碟 IO 的程式分開並佈署在雲端分散式的環境下將有助於我們改善商業邏輯的處理效能。根據三層式系統架構的設計，系統的商業邏輯會盡量與系統的資料存取做切割。在本研究中，資料存取室扮演整個系統中唯一的資料存取接口，所有與資料庫互動的動作都必須透過資料存取室來執行，這樣的設計有助於降低系統模組之間的依賴性，也減少了直接接觸到資料庫的進入點，藉此提高系統的資料安全性。若將資料存取室依照 JBoss Cluster 的管理規範與 JBoss Cluster Job Dispatching Model 的結構來表現，將會如下圖所示(以下為抽象的結構表現，實際的佈署結構請詳見本章第二節-「系統模組切分」之內容)：. 34.

(42) 立. ‧ 國. 學. 圖 26. JBoss Cluster 切分圖-資料存取室. ‧. (資料來源：本研究整理). sit. y. Nat. 三、規劃室. 政治大. n. al. er. io. 規劃室的主要目的是透過從資料存取室取得資料庫中累積的歷史市場狀態資料，並將這些歷史資料做為策略產生器的 Input Data，策略產生器將依據使用者選. i n U. v. 擇的演算法或者統計模型來運行一段資料處理流程，並產出一組經過歷史資料訓練與測試的投資策略。經過策略產生器產出策略後，使用者可以選擇再將投資策略匯入歷史回測模組之中，觀察產出的策略在歷史市場的各種時段中的投資表現，這有助於讓投資者再針對策略的內容設定進行微調。簡而言之，規劃室的功能是希望透過歷史資料幫助使用者建立一組優秀的投資策略，規劃室的相關圖解如下：. Ch. engchi. 35.

(43) 圖 27. 規劃室之 Use Case Diagram. 學. (資料來源：本研究整理). ‧. ‧ 國. 立. 政治大. n. er. io. sit. y. Nat. al. Ch. engchi. 36. i n U. v.

(44) 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. 圖 28. Ch. engchi. i n U. v. 規劃室之簡易 SequenceDiagram (資料來源：本研究整理). 目前規劃室的演算法模組中我們提供了基因演算法(Genetic Algorithm)、統計模型模組中提供羅吉斯回歸(Logistic Regression)、SVM(Support Vector Machine)與後向傳導類神經網路(Backward Propagation Neural Network)的統計模型供使用者選用，未來希望能再動態的增添新的演算法與統計模型以增加投資策略生產的豐富性。由於本研究專注於雲端系統架構之構建，故不在本文中描述各種演算法與統計模型之運算流程。我們在統計模型模組之下應用了 JBoss Cluster Job Dispatching Model 來改善其運算效率。在統計模型模組底下，一個 Job 的單位是一個統計模型從資料前處理、資料探勘、資料後處理三階段的完整運算過程。若將統計模型模組依照 JBoss. 37.

(45) Cluster 的管理規範與 JBoss Cluster Job Dispatching Model 的結構來表現，將會如下圖所示(以下為抽象的結構表現，實際的佈署結構請詳見本章第二節-「系統模組切分」之內容)：. 立. 政治大. ‧. ‧ 國. 學 sit. y. Nat. er. io. 圖 29 JBoss Cluster 切分圖-規劃室之統計模型模組. n. a l(資料來源：本研究整理) i v n Ch U engchi. 四、交易室. 交易室主要的功能是提供使用者一個即時的策略執行環境，並隨時回報策略的執行現況與交易績效報告。一旦投資策略在交易室中被啟動，投資策略物件會被置入策略監控模組中，並不斷接收市場狀態資料以判斷是否在當下的時間點做買賣的動作。當策略物件確認要交易下單時，會將下單請求統一傳遞給交易報告匯總模組，由該模組管理並轉交給遠端的下單機。而下單之後所產生的交易報告也會先經由交易報告匯總模組接收後，再轉發回給策略監控模組中的投資策略物件。. 38.

(46) 學. 圖 30. 交易室之 Use Case Diagram. ‧. ‧ 國. 立. 政治大. (資料來源：本研究整理). n. er. io. sit. y. Nat. al. Ch. engchi. 39. i n U. v.

(47) 立. 政治大. y. ‧. ‧ 國. 學. io. (資料來源：本研究整理). n. al. Ch. engchi. sit. 交易室之簡易 Sequence Diagram. er. Nat. 圖 31. i n U. v. 交易報告匯總模組的設計採用了代理人模式(Proxy Pattern)，事實上，交易報告匯總模組扮演了另一個系統模組-下單機的遠端代理人。下單機因為引用外部第三方的 C#下單 API 的關係，在撰寫上使用了與其他的系統模組不同的語言，也被佈署在不同的遠端環境之上。為了簡化程式的複雜度、提高下單功能的安全性，並讓流動於策略監控模組與下單機之間的交易單與交易報告可以被有效率地集中管理，我們在交易室的設計中增加了交易報告匯總模組作為下單機的遠端代理人，讓代理人利用 Http 協定轉交所有策略監控模組的 Request 給下單機，同時也利用 HornetQ 的 Topic 訂閱/傳播機制將下單機的 Response 傳遞給策略監控模組底下對應的投資策略物件。. 40.

(48) 學. 圖 32. 交易室之代理人模式示意圖. y er. io. sit. Nat. (資料來源：本研究整理). ‧. ‧ 國. 立. 政治大. 由於策略監控模組時常需要同時監控多個在即時環境下測試的交易策略，當. n. al. i n U. v. 系統的使用者越多、啟動的即時策略越多的時候，此一模組的運算需求量越高，故本研究在策略監控模組也採用 JBoss Cluster Job Dispatching Model 的架構。在策略監控模組，一個 Job 的單位為在即時環境下啟動的交易策略。由五種屬性可以決定策略監控模組的一個 Job，分別為區域(Region，如 Taiwan，台灣)、市場(Market，如 future，期貨)、投資商品名稱(Symbol，如 TXN4，台指期)、時間粒度(Time Granularity，如 1s，以秒為單位)以及交易策略(Strategy，有可能是各種. Ch. engchi. 可以判斷買賣時機的統計模型或者演算法物件)。以下為採用了 JBoss Cluster Job Dispatching Model 改良後的策略監控模組之示意圖與整個交易室於 JBoss Cluster 上佈署之結構示意圖(以下為抽象的結構表現，實際的佈署結構請詳見本章第二節-「系統模組切分」之內容)：. 41.

(49) 立. ‧ 國. 學. 策略監控模組採用 JBoss Cluster Job Dispatching Model 之架構示意圖. ‧. (資料來源：本研究整理). io. sit. y. Nat. n. al. er. 圖 33. 政治大. Ch. engchi. 42. i n U. v.

(50) 立. 政治大. ‧. ‧ 國. 學 JBoss Cluster 切分圖-交易室. er. io. sit. y. Nat. 圖 34. n. a l(資料來源：本研究整理) i v n Ch U engchi. 五、下單機. 下單機是整個策略交易平台與外部模擬交易所系統的接口。下單機整合了模擬交易所的溝通介面，可以轉送交易室的下單請求給模擬交易所，同時也轉送來自模擬交易所的各種事件回報到交易室，讓整個策略交易平台因應回報的內容做出反應。由於高頻交易非常要求下單的執行速度，下單機特別以事件驅動(Event Driven) 的方式來做內部程式的流程控制，讓模組內的各個系統流程免於因互相等待而拖慢了整體的執行效率。. 43.

(51) 立. 政治大. ‧. 下單機之 Class 與 Event-driven 示意圖. sit. Nat. (資料來源：本研究整理). y. ‧ 國. 學. 圖 35. er. io. 第二節系統模組切分. al. v i n 高頻交易策略服務平台的系統結構依據各功能模組的切分成數組 Server Group，並 Ch U i e h n gc 依照功能的運算複雜程度、運行條件…等因素來決定各個 Server Group 之 Server n. 綜合上述 JBoss Cluster 管理機制與本研究提出的工作分派模型，本文將整個. Instance 要如何妥善配置在各個 Host 之上。我們接下來將以一個以六部實體機器(每台實體機器對應到一個 Host)組成的 JBoss Cluster 環境來展示本研究如何實際利用 JBoss Cluster 結構與工作分派模型將整個完整的系統佈署到分散式的雲端環境之上。以下的圖例將依序詳列每個 Host 之上的 Server Group 與 Server Instance 的分布情況(這裡所展示的系統配置並不代表考量各種最佳化因素的配置組合，最佳的系統配置還是應以實際所擁有的硬體資源、系統應用條件…等因素來調整。)：. 44.

(52) 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. 圖 36. Ch. engchi. i n U. v. JBoss Cluster Host 佈署圖-Host1-nccu-mgmt (資料來源：本研究整理). 45.

(53) 立. 政治大. ‧ 國. 學 JBoss Cluster Host 佈署圖-Host2-nccu-n01. 圖 37. ‧. (資料來源：本研究整理). n. er. io. sit. y. Nat. al. Ch. engchi. 46. i n U. v.

(54) JBoss Cluster Host 佈署圖-Host3-nccu-n02. 圖 38. (資料來源：本研究整理). 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. 圖 39. Ch. engchi. i n U. v. JBoss Cluster Host 佈署圖-Host4-nccu-n03 (資料來源：本研究整理). 47.

(55) 立. 政治大. ‧. ‧ 國. 學 er. io. sit. y. Nat. JBoss Cluster Host 佈署圖-Host5-nccu-n04. al. n. 圖 40. Ch. i n U. (資料來源：本研究整理). engchi. 48. v.

(56) 立. 政治大. ‧ 國. 學 JBoss Cluster Host 佈署圖-Host6-nccu-n05. 圖 41. ‧ sit. y. Nat. 第三節系統畫面說明. n. al. er. io. 本研究之高頻交易平台提供了 Web 的操作介面讓投資者可使用「規劃室」與「交易室」的功能。一、規劃室(PlanRoom). Ch. engchi. i n U. v. 規劃室的介面希望能引領使用者依照「資料前處理」、「資料採掘」、「資料後處理」的順序來完成投資策略的建置、歷史模擬測試與策略儲存的目標。（一）資料前處理畫面：做為產生投資策略的第一步，使用者必須在這個階段透過 Web 介面所提供的參數設定來決定規劃室如何將來自投資市場的各種原始的市場狀態資料加以處理、轉換成後續演算法、統計模型可以接受的資料形式。在 CommonConfig 的參數區塊，使用者需要設定欲產生之策略所針對的投資市場、產品類型、投資標的與訓練時間的區間；而在剩餘的參數區塊，使用者需要選擇欲使用的自變數群組、資料前處理的方式與其他相關的參數設定。在做完了資料前處理全部的參數設定後，按下按鈕開始資料前處理的過程。. 49.

(57) 立. 政治大. ‧. ‧ 國. 學系統畫面-規劃室-資料前處理. sit. y. Nat. 圖 42. er. io. （二）資料採掘畫面：. al. v i n 使用者必須選擇一個演算法或者是統計模型做為後續運作資料採掘流程的運算邏 Ch engchi U 輯，Web 介面會依照使用者選擇不同的運算邏輯而顯示出該運算邏輯的設定參數。 n. 在規劃室結束了資料前處理的流程後，會進入到資料採掘的設定畫面，在此處，. 在使用者選定了資料採掘的運算邏輯並且做完參數設定後，按下開始 Mining 的按鈕啟動資料採掘的流程。. 50.

(58) 圖 43. 立. 治政大系統畫面-規劃室-資料採掘. ‧ 國. 學. （三）資料後處理與策略儲存畫面：. ‧. 規劃室完成了資料採掘的過程後，將引導使用者到最後的資料後處理與資料儲存的畫面。在此一階段，規劃室將就上一階段產生之投資策略模型做歷史回測的動作，使用者必須設定好歷史回測設定商品類型、區域、市場、測試時間區間….等參數，並在按下按鈕後開始最後的資料後處理的歷史回測流程。執行完歷史回測後將會在畫面下方 Result 之區塊顯示最後投資策略測試之結果，使用者可依照結果的好壞決定是否要將此次規劃室產生之投資策略存放入資料庫中，假如是，則在下方空格為產生之策略命名後，按下「儲存策略」的按鈕；若否，則按下「放棄策略」之. er. io. sit. y. Nat. al. n. v i n 按鈕讓系統釋放相關的系統資源。到此，規劃室的責任就告一段落，再來則是需進 Ch engchi U 入交易室，將投資策略投入即時的交易環境中來做模擬測試。. 51.

(59) 立. 政治大. 系統畫面-規劃室-資料後處理與策略儲存. 學. ‧ 國. 圖 44 二、交易室(TradeRoom). ‧. 交易室的介面讓使用者可以將過去已經儲存的優秀策略置放到即時的交易環境上做模擬交易測試，並提供即時的監控畫面供使用者觀察各個策略的模擬現況。. n. al. er. io. sit. y. Nat. （一）策略啟動畫面：. i n U. v. 假如使用者打算將規劃室所產生之策略納入交易室的即時交易環境之下做測試，可以進入交易室的「策略啟動」畫面，畫面將顯示該名使用者過去使用規劃室產生並儲存之所有策略清單，使用者可以選擇要在交易式啟動一個或多個投資策略。在確認啟動策略之前，需要先設定好目標之即時測試環境的相關參數。. Ch. engchi. 52.

(60) 圖 45. 學. ‧ 國. 立. 政治大系統畫面-交易室-啟動策略. ‧. （二）策略監控畫面：. n. al. er. io. sit. y. Nat. 使用者可以於此頁面觀察所有已經於即時交易環境啟動之投資策略。測試中之投資策略列表提供各個在即時環境測試之策略的即時交易訊息與交易績效報告，使用者可以依報告來決定是否要終止某些效果不彰的投資策略。. 圖 46. Ch. engchi. i n U. v. 系統畫面-交易室-策略監控. （三）策略模擬現況畫面：使用者可以在此畫面觀察一特定之投資策略於即時交易環境中的即時模擬現況，每當有任何委託或者成交之訊息報告都會即時更新到此畫面之上，讓使用者. 53.

(61) 可以隨時監控該策略之交易實況。. 學. 圖 47. ‧. ‧ 國. 立. 政治大. 系統畫面-交易室-模擬現況. y. Nat. sit. n. al. er. io. 第五章結論與未來展望第一節總結. Ch. engchi. i n U. v. 為了確保高頻交易的速度與準確性，運算效能與海量資料的處理與存取能力為兩大最需要解決的重要議題。本研究為了以較低成本的解決方案滿足此兩大需求，以開源的 JBoss Application Server 作為整個高頻交易平台之建置框架，將系統的各個功能模組根據其功能複雜度切割成容易被重複利用、分散佈署的管理單元 -MBean，並利用 HornetQ 讓分散在雲端各節點上的 MBean 得以互相交換訊息。在這樣的設計框架之下，本研究得以將一龐大的高頻交易平台分散佈署在多台普通的 PC 之上，藉此將多台機器的運算效能與資料存取能力整合起來，同時也保留了整體系統功能擴充與硬體擴充的彈性。然而，JBoss Application Server 所採行的 JMX 框架雖達到了分散式架構的管理，但對於分散式運算的支援程度卻有限，故本研究於 JBoss Application Server 的 Cluster 管理概念之上，提出了一套利用 HornetQ 來分散工作並收斂分散工作結果的 JBoss Cluster Job Dispatching Model，希望能彌補 JBoss Application Server 於這方. 54.

(62) 面的不足。從雲端運算的角度來看，本研究所建置之基於 JBoss Cluster Job Dispatching Model 的高頻交易系統屬於一種 PaaS(Platform as a Service)的社群雲，系統的使用者皆屬於有興趣利用高頻交易來獲利之投資者。我們的平台提供歷史、即時的市場狀態資料、演算法與統計模型讓使用者自助式地產生自己的投資策略，也提供模擬交易環境讓使用者運行已產生的投資策略，並做為測試與下單之用。而且隨著使用者的使用量增加、對於新功能的需求增加，此平台也可以高度彈性地透過增加 Host 與 Server Group 來做雲端叢集於水平(增加運算效能、儲存空間)與垂直(增加系統功能)兩方向之擴充。. 第二節未來展望一、提高演算法、統計模型與市場狀態的豐富性. 政治大交易程式判斷買賣時機點的準確度也非常的重要。本研究希望能在未來陸續增加立. 除了以雲端分散式架構與服務導向架構解決高頻交易的兩大需求之外，提高. ‧ 國. 學. 更多樣化的統計演算法模組、技術指標與買賣規則組合，讓平台的使用者可以用更多元的方式設計出個人化的投資策略。二、結合平行運算改善運算效能. ‧. n. al. er. io. sit. y. Nat. 在運算效能方面，目前本研究的系統架構主要採行混用 JMX 框架與 JBoss Cluster Job Dispatching Model 的分散式運算，將複雜的功能切分成更小的單位以利於分散佈署並利用工作分派模型將工作於整個雲端叢集內分散與收斂，但這樣的做法卻沒有充分發揮到目前運算設備多俱備的多運算核心的優勢。本研究希望未來能引入平行運算的解決方案，在切分的 MBean 單位之下，再將一個工作平行交. i n U. 給多個 CPU 處理，以進一步提升整體的系統效能。. Ch. engchi. v. 參考文獻三、英文參考文獻 [1] Adam（2013）. The History of HFT (Infographic). investoo.com. Retrieved from http://www.investoo.com/high-frequency-trading-hft-infographic/ [2] Kevin Kelly（2006）. Moving markets Shifts in trading patterns are making technology ever more important. The Economist. Retrieved from. 55.

(63) http://www.economist.com/node/5475381?story_id=E1_VQSVPRT. [3] National Institute of Standards and Technology(NIST)（2011）. The NIST Definition of Cloud Computing . Retrieved from http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf [4] Adnan Gohar（2010）.Analyzing Service Oriented Architecture (SOA) in Open Source Products. Student thesis. Mälardalen University, School of Innovation, Design and Engineering [5] IBM（2014）. Java Management Extensions overview. Retrieved from. 政治大. http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=%2Fcom.ibm.w. 立. ebsphere.nd.doc%2Finfo%2Fae%2Fae%2Fcjmx_overview.html.. ‧ 國. 學. [6] Oracle（2013）. The Java EE 6 Tutorial. Retrieved from http://docs.oracle.com/javaee/6/tutorial/doc/bncdr.html. ‧. [7] RedHat（2014）. What is HornetQ?. Retrieved from http://www.jboss.org/hornetq. n. al. er. io. sit. y. Nat. 四、中文參考文獻. i n U. v. [8] Robert D. Edwards, & John Magee（1998）。股價趨勢技術分析(上)。寰宇出版股份有限公司。. Ch. engchi. [9] Robert D. Edwards, & John Magee（1998）。股價趨勢技術分析(下)。寰宇出版股份有限公司。 [10] 陳進忠（2005）。股票聖經：技術分析寶典。中經社文化有限公司。 [11] 黎永良（2014，1 月 14 日）。高頻交易與未來股市發展的關係。信報財經新聞。取自 http://www2.hkej.com/wm/article/id/343415。 [12] Eric Freeman & Elisabeth Freeman（2005）。深入淺出設計模式。碁峰資訊股份有限公司。. 56.

(64)