1.開始之前，請先容許我介紹下華泰證券，華泰證券中全國領先的大型綜合性證券集團，具有龐大的客戶基礎、領先的網際網路平台及靈活協同的全業務鍊體系，股票代碼601688，主營業務主要有經紀及财富管理、投資銀行、投資及交易、資産管理、海外業務，經濟業務多年保持市場第一，去年系統交易總額35萬億元。
2.券商以往系統建設都依賴于服務廠商，是以也造成了各系統之間的多樣異構化，各種類型的系統架構都長期存在，例如集中交易用的恒生系統，主要基于c語言的消息路由架構，自營系統則是恒生系統的tuxdeo架構，管理系統基于esb架構，app服務端則已基本是java化的網際網路化架構
3.随着華泰證券自主研發的大規模投入，迫切需要改變這種煙囪式的系統建設方式，以統一化的服務化架構來建設系統，我們先來看下華泰證券對服務化架構的一些需求：
跨語言，因為原有系統開發語言主要有c、php、java，同時也為了以後能支援更多的語言服務業務系統，是以跨語言是服務化架構的最重要的屬性
服務注冊中心，便于動态的注冊和發現服務，使服務的位置透明，便于服務消費方發現服務，同時注冊中心需要高可用
服務負載均衡，提供服務調用負載均衡機制，友善服務調用請求自動負載均衡至後端服務，同時可以動态設定服務權重，根據權重進行相應服務負載均衡
服務調用鍊，當系統間服務數量衆多時，需要服務化架構自動繪畫出各服務間的依賴關系，便于日後的服務治理
服務授權，衆多的服務涉及資料，需對服務調用進行授權驗證及黑白名單設定，以防止資料及應用安全問題
服務流控，服務提供方需要對各類服務請求流控，當請求超标或失敗時，能拒絕部分請求，進行自我保護，同時優先保證重要的服務調用方請求
服務品質等級協定(sla)，服務消費者和服務提供者約定《服務品質等級協定(sla)》，sla包括消費者承諾每天調用量、請求資料量，提供方承諾響應時間，出錯率等，同時将sla記錄在監控中心，定時與監控資料對比，超标則進行報警
服務審批，當服務衆多時，可能會有不合乎規定的服務上線或未經允許下線，是以服務上線和下線都前需經過審批才能進行
服務版本管理與灰階釋出功能。提供服務版本的管理功能，實作服務版本更新、降級、多版本共存等功能；支援服務更新的灰階釋出功能，實作服務的平滑穩定更新。
服務調用優先級功能。支援調用者優先級配置，實作不同優先級的調用端提供不同的服務品質，確定高優先級調用者能夠獲得較高的服務品質。
服務文檔庫功能。建立服務wiki知識庫，友善服務調用方查找服務所在地
服務編排工具，開發專業的服務編排工具，能根據相應權限自動發現相應類型服務，并可通過圖形化及程式設計形式對多種服務進行編排，進而建立新的服務并釋出
4.在這些需求之下，現在來看下我們對服務化架構的一些設計思考
服務治理架構包括用戶端架構、服務端架構、服務注冊中心、采集器、流處理引擎、pmdb資料庫、監控報警子產品、認證授權子產品、日志分析引擎、服務倉庫、排程器、服務分析引擎、編排與服務網關、控制台。整體架構如圖所示：
5.主要關鍵流程：
服務注冊流程
排程器根據管理者的指令從服務倉庫中讀取服務軟體包和配置資訊，結合管理人員給出的安全配置資訊，根據既定的政策部署到目标環境；等待部署完成後，把服務名稱、版本、上線時間、ttl、狀态、優先級、角色、服務協定、服務ip/port資訊、服務指令及參數資訊、通路路徑、安全acl等注冊到注冊中心中。整個流程如下圖所示：
服務調用流程
其操作流程如下：用戶端從注冊中心擷取注冊服務的清單資訊，緩存到本地記憶體中友善快速查詢；用戶端根據既定的負載均衡政策選取一個服務結點發起服務調用，服務端接收用戶端調用請求；整個過程由資訊采集子產品采集調用資訊，發送到流處理引擎中進行進一步的處理。整個流程如下圖所示：
服務跟蹤流程
服務跟蹤流程分為兩個子過程：采集-處理-存儲子過程和分析-可視化子過程，前者完成資料的采集、流式處理，以存儲到pmdb和日志系統結束。後者基于存儲的資料進行進一步的資料分析，完成容量預測、故障定位、關聯度分析等進階功能，通過可視化界面對外呈現。整個流程如下圖所示：
6.下面我們來看下關鍵技術的選型
目前開源的rpc架構主要有dubbox，grpc，thrift，我們通過對比，目前想法主要是采用thrift技術來實作我們的rpc服務化架構
dubbox确實是一個比較優秀的rpc架構，有很多公司在用，但dubbox社群基本消亡，已基本沒有更新，我們不希望把公司這麼重要級的平台建立在一個已經不前進的技術之上
grpc比較新，剛出來1.0，還有待觀察，根據測試的結果，承載的性能比thrift有較大的差距，未來也許會考慮
thrift社群比較繁榮，且多語言用戶端支援較好，性能也在我們理想範圍内，是以目前選擇定制化thrift做為我們的企業級rpc服務架構
7.目前看，主要可能定制化的内容如下：
1) 擴充tsocket支援從注冊中心擷取服務清單，并根據既定的政策進行負載均衡；（用戶端）
2) 擴充tserviceclient支援逾時熔斷保護及故障時的主備切換等政策；（用戶端）
3) 擴充tprotocol支援調用資訊采集操作；（用戶端）
4) 擴充tnonblockingserver支援多優先級隊列模型；（服務端）
5) 擴充tnonblockingserver支援安全政策模型，引入黑白名單機制；（服務端）
6) 擴充tprocessor支援資訊采集操作；（服務端）
8.服務跟蹤與分析
服務跟蹤與分析技術包括三個部分的内容，分别是服務上下文資訊采集、服務調用關系傳遞和服務調用時間序列分析。
服務上下文資訊采集
服務上下文資訊采集主要采集服務請求從進入服務端到離開服務端的全流程記錄，包括進入服務端、放入隊列、離開隊列、開始執行、結果傳回、執行結束等幾個資訊采集點。同時，要采集的資訊包括伺服器ip、程序/線程id、時間戳、身份id、會話id等資訊，采集後的資訊導入到riemann中進行實時處理。
服務調用關系傳遞
服務調用關系傳遞依賴擴充tserviceclient實作。通過在調用協定裡封裝目前服務id和目前會話id，實作調用依賴向下一級傳遞。依賴于服務上下文資訊采集技術，服務id和會話id會被記錄在調用處理的上下文時間序列時間流中，交給riemann流處理系統進行聚類分析。
服務調用時間序列分析
riemann基于服務上下文資訊采集傳遞過來的事件流進行分析，分析主要操作是從事件流中分離出相同會話id的流和相同服務（ip加上線程id）的流，分别分析其相關性。利用二者綜合分析技術，識别出調用事件流所屬于的調用鍊。
9.其實以券商系統對時延以及各業務系統的系統複雜度，光rpc服務架構可能隻解決了部分的服務調用問題，我們還會有tcp直連/消息中間件/esb等系統互動形式，舊有系統也不可能大範圍的重構，是以也要確定這類系統能納入到我們的服務治理架構下來，當然這類系統沒法做到服務的自動注冊、發現等機制，但我們可以制定相應的服務協定規範，給出相應語言的sdk，自動落下協定日志，通過分析日志生成服務治理平台所需的各類資訊，進而達到服務治理的目标。
10.好了，以上都是華泰證券在服務化道路上的一些探索與思考，有的地方考慮的并不深入，希望大家能多給寶貴意見，謝謝!
分享者簡介：
樊建博士畢業于上海大學計算機應用專業，雲計算、大資料專家，曾任上海大學碩士生導師。主持和參與多項國家幾省級項目，獲上海市科技進步獎1項；共發表三大檢索論文近20篇，專著一本；申請專利近20項；擁有多年上市公司研發、管理及自主創業經驗；現為華泰證券股份有限公司平台架構總監，負責公司整體平台架構規劃、研發工作。
本文轉載自微信公衆号 中生代技術 freshmantechnology