國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
第三章 系統架構及組件之設計
本章節將延續第二章所提出之對稱式多主機的架構、Zookeeper 的特性，MariaDB 的運 用，提出系統架構及系統內部所有組成組件之細部設計。這當中包括了 znode、電子資 料交換格式、處理程序、資料表、通訊介面、API、及模擬器的設計。細節將分別於後 續的章節做詳細的說明。
3.1、對稱式系統架構之設計
根據圖 1.3 對稱式多主機系統架構所示，在對稱式的系統中，每台主機均具有相同的處 理程序及儲存的資料。再運用 Zookeeper 所提供的服務，當成是『資料共享』、『訊息傳 遞』、『程序監控』及『主機遴選』的平台。完整的基於 Zookeeper 服務的對稱式電子交 易系統的宏觀架構圖如 3.1 所示。
圖 3.1 基於 Zookeeper 服務的對稱式電子交易系統宏觀架構圖 各圖示所代表的意義說明如下
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
1、直立長方形虛線：代表對稱式架構下的每一台主機。
2、橫向長方形虛線：代表 Zookeeper ensemble。
3、有陰影效果的長方形：代表外部實體(external entity)。
4、單箭頭或雙箭頭實線：代表資料流，而線上的文字說明，代表資料流傳遞的方式。
5、無陰影效果的長方形實線:代表處理程序。
6、柱狀圖:代表資料庫。
3.2、系統組件之設計
3.2.1、Zookeeper Znode 的階層結構及建立模式
‧
/Election(PERSISTENT)
/Machines(PERSISTENT)
Machine 1(PERSISTENT)
Process 1(PERSISTENT_SEQUENTIAL) Thread 1(EPHEMERAL)
Thread 2(EPHEMERAL)
Thread n(EPHEMERAL) /Shared(PERSISTENT)
Process n(PERSISTENT_SEQUENTIAL) Thread 1(EPHEMERAL)
Thread 2(EPHEMERAL)
Thread n(EPHEMERAL) SerialNumber(PERSISTENT)
EntrustInfo(PERSISTENT)
Machine n(PERSISTENT)
Pid.00000001(EPHEMERAL_SEQUENTIAL) Pid.00000002(EPHEMERAL_SEQUENTIAL) Pid.0000000n(EPHEMERAL_SEQUENTIAL)
圖 3.2 znode 階層架構及其建立模式
接下來，將針對該階層結構、節點的設計用途及模式選定的原因說明如下 1、/：代表根節點
a、用途：Zookeeper 會自動建立一個根節點，所有後續所建立的節點，均屬於這個 根節點的子節點。類似 UNIX(Linux)的檔案階層表示方式。
‧
空節點的形態存在。因此該節點的模式要設計成 PERSISTENT。3、/Election/Pid.00000001~Pid.0000000n：代表參與主機遴選的處理程序。
a、用途：用來代表要參與主機遴選的處理程序。節點的命名規則為 ProcessID.序號。
b、模式選定原因：主機遴選的規則是節點名稱中，序號最小的節點即為 Leader。
而且代表主機的處理程序，不論任何原因，只要跟 Zookeeper 的連線中斷（當然，
包括處理程序的生命週期中止），即代表該主機出現異常情況，已經無發提供原有 子節點，該節點都必須存在,所以必須設計為 PERSISTENT。
5、/Shared/SerialNumber：代表共享全域唯一序號的節點。
a、用途：在對稱式的電子交易系統，所有的主機都必須共享同一個流水序號，此 節點就是存放此一全域流水序號的節點。
b、模式選定原因：此一節點不屬於任何一台主機所有，諱言之，該節點不會因為 主機否存在與否而決定是否存在，所以必須設計為 PERSISTENT。
‧
主機存在與否而決定是否存在，所以必須設計為 PERSISTENT。以下第 7 點至第 10 點，都跟程序監控有關。在說明下列 4 點之前，必須先瞭解處 理程序是如何被監控，如果發生異常，其他處理程序是如何收到通知。在 2.3.4 節，曾 提到監控機制是由內而外的概念，稱之為 Propagation monitor。接下來，就對 Propagation monitor 做說明。
這就像是程式語言中的 Exception handing，將例外訊息一層一層由內往外拋送。所以本 篇論文將此監控機制定名為 Propagation monitor。
在說明了 Propagation monitor 的運作原理後，接下來將繼續針對程序監控的部分，做 節點階層結構、節點的設計用途及模式選定的說明
7、/Machines：代表主機群的父節點。圖 3.3 表示主機群有 3 台主機，主機各為 ubuntu、
‧
節點不會因為主機否存在與否而決定是否存在，所以必須設計為 PERSISTENT。圖 3.3 主機群與主機的關係圖
8、/Machines /Machine 1~Machine n：代表主機群中的每一台機器，見圖 3.3。
a、用途：以主機名稱為其節點名稱。為各處理程序是否存在提供監控機制。每個 處理程序啟動時，就將該程序掛載至此節點下成為其子節點。只要有任何程序從該
節點被移除，監控該節點的處理程序就會收到通知。
b、模式選定原因：此一節點，對處理程序而言，是一父節點，不屬於任何一個處 理程序所有。換言之，要在代表主機發生異常時的處理程序結束前，明確刪除，所 以必須設計為 PERSISTENT。
9、/Machines/Machine 1~Machine n/Process 1~ Process n：代表主機內之處理程序。圖 3.4 代表主機 ubuntu_3 有 3 個處理程序，處理程序的名稱分別為 EntrustProcess-000 00001、
DBManipulator-00000001、TradingGateway00000001。
a、用途：因為處理程序要依附在主機內運作，所以每一個節點都代表是主機內的
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
一個處理程序。命名規則為程序名稱-序號。須要序號的原因在於，如果單一處理 程序是可以多重啟動的話，就必須要有序號來加以區別相同名稱的處理程序，例如 EntrustProcess 被啟動兩次，就會產生 EntrustProcess-00000001 及 Entrust00000002 兩個節點。
b、模式選定原因：此一節點，對執行序而言，是一父節點，不屬於任何一
個執行序所有。換言之，該節點的不能因為某個執行緒的異常而自動消失，因為該 節點之下還有其他執行緒是正常處理。再者，因為有序號的需求，因此必須被設計 為 PERSISTENT_SEQUENTIAL。
圖 3.4 程序與主機的關係圖
10、/Machines /Machine 1~Machine n/Process 1~ Process n/Thread 1~Thread n：代表每個 處理程序下的執行緒。圖 3.5 代表 DBManipulator-000000014 這個處理程序，有兩個執 行緒，執行緒代號分別是 19 及 20。
a、用途：這是監控機制中最小的單位。必須將每個執行緒在執行的時候，都掛載在所 屬的處理程序下，節點名稱是執行緒代號。經由監控處理程序下之執行緒節點的異動，
即可得知處理程序是否發生異常。
b、模式選定原因：執行緒已是監控機制中的最小單位，因此當執行緒發生異常時，就 必須自動從處理程序的節點中刪除，所以該節點必須設計成 EMPHEMERAL。
‧
序，可區分為 big endian 及 little endian[16]。本系統採 little endian。以數值 484 為例，經過轉換後，在 byte array 中所存放的值為
‧
‧
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
25 錯誤代碼 X(4) 141 0000:成功
26 錯誤訊息 X(32) 145
3.2.3、交易處理程序
電子交易系統有兩大的資料流必須處理，一個稱之為『委託』，而另一個稱為之為
『回報』。舉例來說，以國內股票交易為例，『在整股時段，以 123 塊，購買 XX 電子 10 張』，這是一個委託的要求，這個委託的資料流進入交易系統後，交易系統會經由一連 串的處理程序，將該資料流拆解後重新組合，最後送到交易所，而交易所會根據委託及 市場的買賣內容，回覆給使用者委託後的結果，就是所謂的回報。因此，接下來將根據 委託及回報的流程，來說明電子交易系統各處理程序是如何『串接』完成一筆交易。
1、委託
圖 3.6 是委託的流程圖，紅色長方形虛框處所標示的部分，為本論文所討論的系統範圍。
圖 3.6 電子交易委託流程圖
‧
step 1、external entity 透過交易 GUI 將委託輸入，並將委託內容組成一份 XML。
step 2、交易 GUI 將 XML 透過通訊中介平台，也就是圖 3.6 中的 Message Oriented Middleware(MOM)，傳送至本系統的入口處理程序，TradingGateway。
step 3、TradingGateway 將收到的 XML 反序列化(Deserialize)為系統內部操作的物件，再 將該物件根據下個處理程序所需的內容，序列化(Serialize)為 3.2.2 節所提及的委託電文，
並將該電文送至下個處理程序,EntrustProcessor。
step 4、EntrustProcessor 收到來自 TradingGateway 的委託電文後，將該電文根據規格拆 解，之後進行商業邏輯的檢核，產生全域的交易流水序號。
step 5、將檢核的結果、全域流水序號和其他資訊，例如主機 ip，加上原來的委託內容，
重新組合成 3.3.2 節所提的檢核回覆/後台下單/回報電文。如果商業邏輯檢核成功，會將 該電文送往至下述的 a、b、c、d 四個處理程序；但如果商業邏輯檢核失敗，只會將該 電文送往至下述的 a、b、d 三個處理程序。
a、TradingGateway：透過 TradingGateway→MOM→交易 GUI 介面的流程，讓使用者知 道該筆委託已經進入交易系統，也完成商業邏輯之檢核，如果在檢核過程中發生檢核錯 誤，例如：價格超過漲跌幅，使用者也可以透過這個流程得知。
b、DBManipulator：將該筆委的商業邏輯檢核紀錄下來，供使用者後續的查詢使用。
c、BOSConnector：該處理程序主要是負責跟交易所的主機連線，將收到的電文送至交 易所。實務上，在 BOSConnector 和交易所之間，還會存在一套稱為帳務系統的程式負 責對交易所的主機連線，BOSConnector 會將電文送至帳務系統，再由帳務系統將電文 送至交易所。但在本論文所討論的範圍中，帳務系統並不扮演任何角色，因此予以省略。
d、Zookeeper service：用意在於讓其他主機也能收到該委託之商業邏輯檢核結果，並將 該結果紀錄在資料庫中，如此一來，每台主機的資料庫存都保有一致的資料。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
2、回報
圖 3.6 是回報的流程圖，紅色長方形虛框處所標示的部分，為本論文所討論的系統範 圍。
圖 3.7 電子交易回報流程圖
以『在整股時段，以 123 塊，購買 XX 電子 10 張』為模擬的情境，說明委託的步 驟如下。
step 1、交易所將委託回報的電文送至 BOSConnector。
step 2、BOSConnector 將該電文送至 DBManipulator 及 TradingGateway。
step 3、DBManipulator 收到電文後，依據 3.3.2 節所提的檢核回覆/後台下單/回報電文的 格式，將電文拆解，更新資料庫中的委託資料。
step 4、TradingGateway 收到電文後，檢視電文中的下單 IP 欄位，檢核該筆委托是否是 由該本機所下，如果是，則將該電文透過 MOM 傳送至使用者的交易 GUI 介面。如果不 是，則檢核下單 IP 欄位所記錄的下單主機，是否正常運作，如果正常運作，代表原下 單主機會負責回報的處理。如果主機原下單主機已發生異常，無法提供服務，則要再確
‧
1、IPC (Inter-process communication)
IPC 的種類在不同的作業系統下，會有些許支援上的差異。因為本系統是建置在 Linux 上，因此的 IPC 種類計有[17]
a、Signal b、Pipes
c、FIFOs(named pipes) d、Message queue e、Semaphores f、Shared memory
電子交易系統在訊息傳遞方式的設計上，有幾項的考量因素
‧
a、named pipe 實際上是一個存在於硬碟的特殊種類檔案(稱為 FIFO file)，不同於一般的 檔案，FIFO file 不包含任何使用者資訊。在實作 named pipe 就像操作檔案一般，並不困
2、RPC(Remote process communication)
RPC 的部分，已經超出本論文所界定的系統範圍，但因為在概念性驗證(Proof of Concept)的階段，必須要能提供模擬的情境，因此仍有 RPC 之實作上的必要。電子交易
RPC 的部分，已經超出本論文所界定的系統範圍，但因為在概念性驗證(Proof of Concept)的階段，必須要能提供模擬的情境，因此仍有 RPC 之實作上的必要。電子交易