(七)：C++分佈式實時應用框架 2.0

C++分佈式實時應用框架 2.0

技術交流合做QQ羣：436466587　歡迎討論交流

 

上一篇：(六)：大型項目容器化改造

版權聲明:本文版權及所用技術歸屬smartguys團隊全部，對於抄襲，非經贊成轉載等行爲保留法律追究的權利！

 

　　在C++分佈式實時應用框架(CDRAF)1.0版本發佈後，咱們對整個框架作了大量的改進。在架構層面支持微服務架構、微服務編排。進一步釐清了CDRAF與業務代碼的耦合，全部的分佈式功能均再也不須要業務側關心，而統一由CDRFA內部實現。極致簡化了業務側的配置文件，也許下一步是作一個代碼自動生成功能，根據配置生成相應的業務代碼框架。從新實現如節點時延統計(CDRFA自動實現每一個包的時延統計，業務無需關心)，單號碼日誌跟蹤(改爲消息包染色的方案，CDRFA遇到染色包自動打印日誌)，應用命令功能(經過系統管理模塊的RESTful接口給節點內的應用程序下達指令)等等。提供接口全面展現集羣的節點實時拓撲圖，並支持對集羣節點微服務進行實時編排。增長了新的日誌框架功能，提供高性能、多場景的日誌輸出能力。應對這些改進同步增長了相應的單元測試。由此C++分佈式實時應用框架2.0版本也應運而生！

 

　　1、集羣實時拓撲圖

　　實時拓撲圖展現了集羣的每一個節點(容器實例)，連線表明通信方向，孤立的節點表示未併網的節點。界面實時展現TPS(流量),RTT(時延)兩個數據，點開節點能夠進入容器節點的管理界面，作更多容器節點的管理工做。

　　

 

　　

　　2、微服務編排

 　　按第五篇《微服務架構的演進》的方案，咱們增長了圖形界面支持微服務架構的編排。每一個大圈表示一個類型的節點，小圈表明一個微服務端口。編排的時候從一個節點連線到另外一個節點，而且選擇兩個節點要對接的微服務，便可完成編排。能夠實時在集羣運行過程當中進行編排，完成編排後，集羣狀態也會實時顯示在上面的拓撲圖當中。固然能夠根據業務自身須要，增長新類型的節點，或者爲節點增長新的微服務端口。能夠看到每一個節點都獨立非耦合，節點間的交互徹底是經過微服務端口來進行，而且這些端口生效與否是經過微服務編排來進行控制的。

 

 

 

 

　　3、時延統計功能

 　　時延統計功能是分佈式框架的核心數據之一，用於實時檢測節點的性能，並依此採起相應的解決策略。原來這個功能是在業務側實現的，CDRAF2.0中，咱們將這個功能提到框架中，能夠計算全部節點的時延數據，而且業務無需關心(業務無需作任何事情便可得到這個功能)。

　　CDRAF2.0中咱們統一了節點的通信模型，全部的節點均由Dis(數據分發)和業務處理進程組成。在一個業務包到達Dis後，框架會在這個包的包頭打進當刻時間，在業務進程處理完消息回到Dis後，Dis會計算兩個時間差獲得時延數據。並將每一個包的數據進行平均計算，上報狀態中心，而且能夠在實時拓撲圖中展示出來。全部這些工做都由框架來完成。

 

　　

　　4、單號碼日誌跟蹤（包染色方案）

　　原來的日誌跟蹤方案在收到號碼跟蹤命令後，會通知全部節點的全部進程都來關注這個號碼，遇到這個號碼的包後就把日誌跟蹤打開。這個方案有幾大缺點：

　　a) 全部的業務進程都須要實現一份號碼檢測、開日誌跟蹤的功能，代碼會無比冗餘。

　　b) 當打開這個功能的時候，集羣全部的節點，節點中全部的進程，都會處理監測是否有這個號碼的狀態中。整個集羣處於一個十分不穩定狀態中。

　　c) 業務上可能不支持同時跟蹤多個號碼。

　　爲此咱們調整了單號碼日誌跟蹤的方案，採用包染色的方案。在消息入口的位置檢測號碼，一旦符合條件就將這個消息包進行包頭染色，後面的處理環節框架收到包後會先於業務檢測包頭，若是發現包頭被染色，就會將日誌跟蹤打開，這個包處理完畢後再關閉。每一個環節往下傳的時候，框架都會自動爲下傳的包再次進行染色，以保證處理流程上的每一個環節接收到的都是通過染色的包。新方案的優勢以下：

　　a) 業務上再也不須要爲這個功能實現相應的代碼，只要在入口位置進行一次號碼監測，若是符合就調用框架進行染色，後續全部操做都由框架來完成。

　　b) 打開這個功能的時候集羣再也不處理不穩定狀態，業務層面甚至感受不到這個功能的存在，框架處理了全部的問題。

　　c) 當有新的業務節點加進來的時候，會自動得到這個功能，而無需作任何改造。

　　d) 除了單號碼日誌跟蹤功能，這個方案還能夠應用於其它的業務場景。

　　

　　5、通用指令傳遞方案

　　在CDRAF中，若是外界要給集羣中某個節點的某個進程下達一個指令，會經過系統管理模塊的RESTful接口，而後經過狀態中心，通信平臺最終傳遞到相應的進程。但在咱們以前的方案中，每增長一個這樣的命令都須要給每一個模塊（系統管理、狀態中心、通信平臺）增長相應的代碼來進行支持。

　　新的方案中，咱們設計了通用的消息通路，用來傳遞指令。

　　通信框架自動給SmartAgent 進程增長MonitorMsgInterface 端點，無需配置；SmartAgent 將業務控制消息從自身的MonitorMsgInterface 端點發出， SmartMonitor 從自身的MonitorMsgInterface 端點接收並處理；

　　統一的命令格式

message MONITOR_MSG
{
    string dest = 1;
    bytes msg = 2;
}

　　其中， dest 爲控制消息想要發送的目的地，填具體目的地進程的進程名，如"OLCProxy","OCPro", "OCDis"等；若是須要將命令發送至全部進程，則dest 填成字符串all 。msg字段爲具體的控制命令文本。

　　框架自身提供了若干公共的控制命令，枚舉以下：
調整日誌級別
格式： log 日誌級別
其中， 日誌級別包含off , critical , err , warn , info , debug , trace
例子： log debug
停線程
格式： stop
重載通信鏈路信息
格式： reload
　　除了以上框架提供的公共控制命令外， SmartMonitor 也能夠接收任意消息並傳遞給指定進程，其不關心消息內容，消息內容徹底由業務進程負責解析處理。 原則上SmartAgent 在填寫該字段值的時候，應該直接從ZK讀取；ZK上應該有該控制命令的文本。

 

 　　從上面這些調整能夠看到，CDRAF2.0致力於將分佈式相關功能和業務完全解耦。在咱們的設計與實現中，業務和框架之間有一條明顯的分界線。全部能夠在框架側作到的功能，業務側一行代碼也不用寫，即可自動得到。我想這即是CDRAF2.0向通用型框架邁出的一大步！