杭州銀行批量交易平臺(HZBAT)技術內幕

1  概述

杭州銀行批量交易平臺(HZBAT)是我基於DC4C自研的面向批量交易的技術平臺。DC4C是我在2015年完全獨立自研的分散式批量計算框架。

目前HZBAT已用於綜合積分系統(2015年投產)、ECIF系統(2017年投產)，以及在2018年加入同事潘平原一起改造優化後實施於杭州銀行核心業務系統的日終批量交易平臺，穩定執行至今。

2  分散式批量計算框架(DC4C)

2015年4月，我在開發爬蟲專案需要平臺化、配置化的併發排程框架，搜尋了開源社群以及阿里等大廠都沒有對應的技術產品可用，遂自己將排程邏輯抽象出來，借鑑分散式設計思想，充分考慮叢集高可用和敏捷伸縮，花了一個多月完全獨立設計自研了一套分散式批量計算框架，取名為DC4C。

DC4C是一箇中介代理模式、動態自治、高可用易伸縮的分散式批量計算框架，也是業界最早實現有向無環圖任務排程引擎的分散式計算框架之一。

DC4C核心完全用C編寫，版本'1.5.5'時手工程式碼約一萬行，此外大量程式碼使用我的開源工具DirectStruct自動化技術生成，大幅減少了開發量，提高了開發效率，減輕了底層細節編碼壓力。

DC4C不依賴其它任何第三方程式碼、庫和系統，只依賴我開源的極速JSON解析庫fasterjson，已包含在DC4C原始碼內。

2.1. 體系架構

DC4C體系架構包含基礎平臺架構、API包和任務排程引擎庫。

2.1.1. 基礎平臺架構

architecture.png

DC4C提供了一個分散式基礎設施，包含負責中介的註冊節點(rserver)、負責業務邏輯處理的計算節點組(wserver)、負責任務分派和排程的使用者節點API(dc4c_user_api)，構建了分散式叢集管理和批量任務分派排程管理體系。在任務分派API基礎上又封裝了排程引擎庫，自研了有向無環圖任務排程引擎(dc4c_tfc_dag_api)。

DC4C使用者節點API包可用其它語言編寫以適配使用者公司的技術棧，計算節點應用目前只支援裝載可執行程式和動態庫，可擴充套件改造支援其它執行模式。

2.1.1.1. 註冊節點

註冊節點為父子程式結構，父程式負責監控子程式異常時重啟子程式，子程式負責接受計算節點的註冊、狀態變更、登出，接受使用者節點API查詢空閒計算節點資訊，介面支援TCP、HTTP/HTML兩種方式。

註冊節點最多可部署8套，提高計算節點註冊資訊的冗餘性，保證系統高可用。

2.1.1.2. 計算節點

計算節點為三級程式結構，管理程式建立一組工作程式，並監控工作程式異常時重啟工作程式，每個工作程式都有一個唯一的偵聽網路地址（起始埠號+工作程式編號），每個工作程式再建立一個執行程式作為其關聯程式。

工作程式負責向註冊節點註冊、狀態變更、登出，負責接受使用者節點的任務分派請求、聯動下發任務程式、傳遞任務命令給執行程式、反饋任務結果。工作程式與註冊節點保持長連線並週期性交換心跳。工作程式接收到任務時會檢查比較使用者節點的任務程式和本地的是否一致，如果不一致會聯動發起下發任務程式請求，最後再傳遞任務給執行程式執行。工作程式管理同一時間只有一個任務正在執行，如果有額外的使用者節點連線進來則立即響應告知。

執行程式負責接收任務命令列，裝載、執行任務程式。

2.1.1.3. 使用者節點

使用者節點由使用者程式組成，使用者程式碼呼叫使用者節點API包實現向註冊節點查詢空閒計算節點、向計算節點分派任務。

2.1.2. API包

2.1.2.1. 使用者節點API包

使用者節點API包供使用者節點程式呼叫，負責查詢計算叢集中空閒節點、分派任務，並監督任務執行。

使用者節點API包括單任務分派API集、批任務分派API集和多批任務分派API集。

使用者節點API還提供了開始、結束、取消事件鉤子，以便於在批量前後、任務前後自動觸發使用者自定義的程式碼邏輯，比如更新資料庫中的任務狀態。

2.1.2.2. 計算節點API包

計算節點API包用於計算節點執行程式與任務程式之間的資訊互動。

2.1.3. 任務排程引擎庫

任務排程引擎用於使用者節點，是基於使用者節點API包的再高層封裝。

目前引擎庫提供有有向無環圖任務排程引擎。

2.1.3.1. 有向無環圖任務排程引擎API

DAG.png

有向無環圖是一種圖結構，圖中所有圖節點都有前序、後序方向關係，且從開始圖節點開始，期間經歷分拆和合攏，最後匯合至結束圖節點。有向無環圖節點之間都是有向且不能構成環。

dag_task_engine.png

有向無環圖任務排程引擎讀取JSON配置檔案填充中間資料結構，再構造有向無環圖內部結構，然後按有向無環圖節點前序後繼關係，依次執行所有批量，每個批量由一組任務組成，批量內任務呈列表結構，從上到下執行。引擎還提供直接接收中間資料結構介面，以便於使用者自行編寫從自定義配置源（如資料庫）到中間資料結構的邏輯。

有向無環圖任務排程引擎內部做了眾多執行優化，比如執行前處理會對每一條圖節點鏈路計算評分，執行時根據評分均衡每條鏈路的優先權重，實現執行總時間最小化。

2.2. 重要流程

2.2.1. 計算節點註冊流程

compute_node_registe_flow.png

計算節點管理程式建立一組工作程式，工作程式建立自己的關聯執行程式後，與註冊節點建立TCP長連線，附帶伺服器資訊，傳送註冊請求。請求被接受後，週期性交換心跳。

worker_info_strategy.png

註冊節點會把每一個計算節點工作程式的註冊請求都快取起來，掛接成三級連結串列“主機型別”(OS版本號位數)-“主機”(IP)-“工作程式”(PORT)。

當收到登出或者長連線斷開就刪除對應工作程式連結串列節點，如果工作程式連結串列為空則連帶刪除主機連結串列節點，如果主機連結串列為空則連帶刪除主機型別連結串列節點。

當收到使用者節點API的查詢空閒計算節點請求時，根據上送的主機型別條件，挑選若干個工作負載最輕的主機，選擇若干個空閒的計算節點工作程式資訊返回給使用者節點，移動該工作程式連結串列節點到最後，以均衡負載。

2.2.2. 使用者節點分派任務流程

user_node_dispatch_task_flow.png

使用者節點使用者應用要分派一個任務時，呼叫使用者節點API。

API首先與註冊節點建立TCP連線，附帶伺服器資訊，傳送查詢請求到註冊節點，註冊節點根據篩選條件和負載策略返回指定數量的計算節點網路地址資訊給使用者節點API，然後API連線計算節點併傳送執行任務請求，計算節點根據收到的任務程式雜湊值和本地的比較，如果一致則去執行，如果不一致則聯動請求使用者節點API下發任務程式，最後工作程式傳遞任務相關資訊給執行程式執行。

工作程式把任務命令列傳遞給執行程式時，也向註冊節點傳送狀態變更通知，把自己切換為忙碌狀態。

執行程式結束執行後，傳遞結果給工作程式，工作程式把執行結果轉交給使用者節點，也向註冊節點傳送狀態變更通知，把自己切換為空閒狀態。

使用者應用還能通過呼叫使用者節點API分派一批或多批任務，並在超時時間內等待所有任務分派到計算節點執行完成返回，或發生錯誤後根據設定決定是否優雅中斷。

2.2.3. 任務狀態遷徙

可靠性是考驗一個分散式系統架構設計的重要考量，DC4C架構中，一個任務在分派、傳遞、執行、響應的任何過程中都可能發生異常。

由於任務的接收執行和計算節點狀態變更通知是非同步的，有可能使用者節點向註冊節點拿到的計算節點狀態與實際不符，所以使用者節點連線分派任務給計算節點時，可能會收到該計算節點忙碌響應，使用者節點API將迭代再次向註冊節點查詢。

task_status_migration.png

每個任務在系統間流轉時都會有一個任務狀態來跟蹤之，當一個任務被選中分派前，其狀態從INIT轉換為USER_EXECUTING，傳送給計算節點且接受任務時，其狀態從USER_EXECUTING轉換為WSERVER_EXECUTING，執行程式執行完傳遞迴工作程式時，其狀態從WSERVER_EXECUTING轉換為WSERVER_FINISHED或WSERVER_FINISHED_WITH_ERROR，響應回使用者節點後，其狀態轉換為USER_FINISHED或USER_FINISHED_WITH_ERROR。

當任務執行中崩潰時，工作程式能在第一時間感知到，代異常結束的執行程式響應回使用者節點，使用者節點API修改狀態為USER_FINISHED_WITH_DOUBT。可疑狀態需要人工介入查證。

當任務執行時間過長或陷入死迴圈，使用者節點API會強行斷開與計算節點的連線，修改狀態為USER_FINISHED_WITH_DOUBT。可疑狀態需要人工介入查證。

任務狀態在流轉中，如果使用者設定了每個任務或每個批量的事件鉤子，將獲得排程中自定義處理狀態的機會，比如更新資料庫。

2.3. 高可用

2.3.1. 當註冊節點崩潰

當註冊節點子程式崩潰時，使用者節點和計算節點立即偵測到與之連線異常，轉而連線其它註冊節點，因其它註冊節點擁有相同的冗餘計算節點註冊資訊，不影響使用者節點和計算節點工作。註冊節點父程式立即偵測到子程式崩潰後會重啟該程式。

當註冊節點父程式崩潰時，子程式也會結束，其它註冊節點擁有冗餘計算節點註冊資訊提供給叢集提供服務。

2.3.2. 當註冊節點僵死

當註冊節點子程式僵死時，計算節點通過心跳發現異常，強制斷開並轉而連線其它註冊節點，使用者節點與之通訊超時，轉而連線其它註冊節點。註冊節點父程式不會偵測到子程式異常，但該節點被孤立，所有錯誤日誌指向該節點，便於手工定位和處置。

當註冊節點父程式僵死時，不影響子程式工作。

2.3.3. 當計算節點崩潰

當計算節點工作程式崩潰時，註冊節點立即偵測到與之連線異常，斷開等待其重啟後重連。使用者節點立即偵測與之連線異常，如果設定了忽略錯誤選項，重新向註冊節點查詢其它空閒計算節點，分派任務，否則進入優雅結束流程，人工介入處理。計算節點管理程式立即偵測到工作程式崩潰，重啟該程式。

當計算節點執行程式崩潰時，工作程式會傳送可疑狀態回使用者節點，然後重啟執行程式，在未重啟完成前拒絕所有使用者節點執行任務請求，因為叢集允許註冊節點裡計算節點狀態與真實計算節點狀態不一致，且註冊節點把查詢過的計算節點資訊移到連結串列最後面並一定時間內不允許再查詢，該計算節點在未準備好執行程式前不會被高頻騷擾。

當計算節點管理程式崩潰時，不影響其它程式工作。

2.3.4. 當計算節點僵死

當計算節點工作程式僵死時，註冊節點通過心跳發現異常，強制斷開並等待重連，使用者節點與之通訊超時，如果設定了忽略錯誤選項，重新向註冊節點查詢其它空閒計算節點，分派任務，否則進入優雅結束流程，人工介入。計算節點管理程式不會偵測到子程式異常，但該節點被孤立，所有錯誤日誌指向該節點，便於手工定位和處理。

當計算節點執行程式僵死時，使用者節點首先會超時，如果設定了忽略錯誤選項，重新向註冊節點查詢其它空閒計算節點，分派任務，否則進入優雅結束流程，人工介入。

當計算節點管理程式僵死時，不影響其它程式工作。

2.3.5. 當使用者節點崩潰

當使用者節點使用者程式程式崩潰時，計算節點工作立即偵測到當前執行任務的使用者節點斷開連線，但不影響執行程式處理，後續需要人工介入。

2.3.6. 當使用者節點僵死

當使用者節點使用者程式程式僵死時，計算節點工作程式等待執行程式結束，傳送執行完成響應給使用者節點，然後等待其他使用者節點任務。

2.4. 高可靠

DC4C基於任務狀態實現高可靠能力。當排程偵測到系統或應用失敗而引發優雅結束後，再次啟動時會檢查未決任務的狀態：如果使用者節點為中間狀態但計算節點為結束狀態，以計算節點修正使用者節點狀態；明確失敗狀態重置成初始狀態以便重新執行；如果存在可疑狀態，拒絕啟動，等待人工介入查證後修正狀態。

2.5. 敏捷伸縮

2.5.1. 熱擴大叢集

需要新增計算節點，只需在新加入主機或已有主機內，啟動新計算節點組，查詢日誌和查詢註冊節點確認加入成功後，自然有使用者節點會查詢到並分派任務過來。

2.5.2. 熱縮小叢集

當需要刪除計算節點時，只需向目標計算節點組的管理程式傳送中止訊號TERM，管理程式轉發訊號給工作程式組，沒有任務的工作-執行程式組立即結束，有任務執行的工作程式關閉網路服務，等待執行程式任務完成後再結束，整個縮小叢集過程不影響正在處理的任務。

2.6. 功能和優勢

• 對於應用開發人員，無需編寫任何併發控制細節程式碼（如fork、wait）就可輕鬆實現本地或叢集的併發管理，以及本地風格（wait子程式退出值status）的執行反饋。計算節點使用者應用本身就是可執行程式，便於本地除錯。

• 對於系統運維人員，隨時根據當前系統負載熱伸縮（擴大或減小）叢集規模，而不影響系統的功能性，更無需應用開發人員參與。叢集伸縮無需重啟等影響當前正在處理的任務。沒有配置檔案，大大減少運維複雜度，實現高伸縮性。目前熱伸縮只能手工觸發。

• 通過網路連線心跳、父子程式監控、資料冗餘、任務狀態遷徙等實現架構高可靠高可用。

• 使用者API包提供了單任務分派、批量任務分派、多批量任務分派等高層封裝API，也提供了低層API供使用者自己封裝適應自己應用場景的任務分派器。使用者API包也提供了同步、多路複用等分派模式，支援各種場景的使用者程式碼結構。

• 實現了一個有向無環圖任務排程引擎，是業界最早實現該資料結構任務排程引擎的分散式計算框架之一。

• 使用者節點API和計算節點有自動檢查應用版本和自動叢集應用部署機制。

• 支援telnet或網頁查詢、管理叢集狀態。

  

  
  

3 杭州銀行批量交易平臺(HZBAT)

3.1. 與DC4C的關係

hzbat_and_dc4c.png

杭州銀行批量交易平臺HZBAT（下面簡稱HZBAT）是基於分散式批量計算框架DC4C研發而成。

HZBAT建立“階段-批量-任務”三級排程模型，調DC4C用有向無環圖任務排程引擎API實現銀行批量交易排程處理。

主控管理程式hzbat呼叫DC4C排程引擎庫中的有向無環圖排程引擎API，作為使用者節點，向註冊節點查詢空閒計算節點資訊，下發任務程式和分派任務給計算節點，計算節點執行程式裝載、執行任務程式。

HZBAT依靠DC4C實現隨時熱伸縮叢集而不影響正在處理的批量交易，無基礎設施配置檔案模式減輕了運維人員工作，通過連線心跳、程式監控、狀態冗餘（部署多註冊節點）等實現高可靠高可用，基於有向無環圖任務結構大大豐富批量任務併發配置的靈活度，整個框架自帶交易程式自動更新機制。

3.2. “階段”-“批量”-“任務”三級排程物件

HZBAT基於DC4C把排程物件分為“階段”-“批量”-“任務”三級。

任務是最小執行單元，一個任務即一個執行命令列（有直接執行命令列和動態庫加引數兩種模式），即一個執行程式。在DC4C有向無環圖排程引擎中，任務被分發到DC4C分散式叢集（計算節點群組）中空閒的計算節點上，由該計算節點執行程式執行該命令列、監控執行過程、反饋執行結果（程式返回值）回使用者節點（任務分發方）。

批量由一組任務構成，任務之間平等沒有優先順序，一般按任務列表順序分派和執行。

計劃即有向無環圖批量集合，每個批量是該圖上的一個節點，批量與批量之間有先後依賴關係，只有所有前序批量都執行完成後才能開啟後繼批量。

schedule_list.png

整個銀行日終批量分為五個階段：日終、日切、日結、日初、報表，季末在日初後會有季度結息階段。出於管理需要，每個階段手工觸發。

batch_dag_in_schedule.png

task_list_in_batch.png

每個階段由一棵有向無環圖組成，每個圖節點是一個批量，每個批量由組任務列表組成。

平臺主控管理程式hzbat從資料庫中讀取階段資訊、批量資訊、批量前序後繼關係資訊、靜態任務資訊、批量過濾資訊，填充中間資料結構，呼叫有向無環圖排程引擎API，引擎呼叫DC4C使用者節點API，控制執行階段、批量和任務。當階段開始結束時、批量開始結束時、任務開始結束時，編寫回撥函式掛接到排程引擎事件鉤子中，實現回寫更新狀態、記錄結果等功能。

主控管理程式hzbat還支援單批量、單階段、自動階段組執行，便於本地化除錯。

3.3. 靜態任務和動態任務

預先配置在資料庫任務表中的任務稱為靜態任務，每天不變的任務按靜態任務預置。

每天都可能變化的任務稱為動態任務，動態任務不配置在任務表中，在每個階段開始時，會先執行所有批量的準備任務，準備任務讀入業務資料，拆分並行維度，生成動態任務並登記到任務表中，然後再按有向無環圖結構執行所有批量在任務表中的任務，包括靜態任務。

3.4. 批量過濾

有些批量只有在特定的時間才能執行，hzbat加入資料庫批量過濾表，實現批量過濾機制。

目前過濾型別有每月指定日執行（含自適應月初月末）、按每年指定月日執行、按每週星期幾執行三種型別。同一種型別可配置一個或多個值，如每月的10日、20日執行，如每週的週一、週三、週四執行。

3.5. 主要資料庫表結構

db_schema.png

3.6. 最佳實踐

在長期使用HZBAT中，總結出一套最佳實踐，指導平臺配置管理員、架構師、開發工程師等使用者產生最優使用效果。

3.6.1. 基礎設施規劃

一般部署兩個註冊節點即可實現一定程度的高可用能力，如果有更高要求，可部署更多。

多資料中心可部署多套註冊節點和計算節點，多活工作。唯有使用者節點由使用者保證主備機制。

當叢集過大時，註冊節點的連線和心跳壓力較大，建議註冊節點單獨部署伺服器。

3.6.2. 批量任務顆粒度

批量交易往往數量較少、執行時間較長，交易開發人員在規劃批量交易時要注意任務的顆粒度不能太小，比如生成多幣種報表，不能一個幣種一個任務，時間就大量耗費在的排程中，最佳實踐建議一般來說人民幣按機構拆分任務，外幣整合成一個任務，每個任務儘量耗時均等，總處理時間最小化。

3.6.3. 批量圖結構設計

排程引擎按有向無環圖結構執行階段中的所有批量，規劃圖結構（即批量的前序後繼關係）時儘量發散鏈路，不要設計過多的匯合節點，因為匯合節點會約束下級批量開始，影響系統資源充分利用，導致總時間增加。

3.6.4. 監控

階段、批量、任務表中有開始日期時間和狀態等資訊，可與監控平臺對接，結合歷史資訊進行基準分析，當某個任務執行時間過長時立即告警，人工介入核查。

4  最後

厲華，主手C，寫過效能卓越方便快捷的開源日誌庫，比肩世界最快的JSON、XML、HTTP開源解析器，佔用系統資源極小的開源日誌採集器等，自研銀行核心聯機交易平臺、批量交易平臺、全元件化配置化的前置框架等，分散式系統實踐者，容器技術專研者，目前在杭州銀行資訊科技部負責基礎架構團隊。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31562044/viewspace-2643039/，如需轉載，請註明出處，否則將追究法律責任。