C++分布式實時應用框架 2.0
技術交流合作QQ群：436466587 歡迎討論交流
上一篇：(六)：大型項目容器化改造
版權聲明:本文版權及所用技術歸屬smartguys團隊所有，對於抄襲，非經同意轉載等行為保留法律追究的權利！
在C++分布式實時應用框架(CDRAF)1.0版本發布后，我們對整個框架做了大量的改進。在架構層面支持微服務架構、微服務編排。進一步厘清了CDRAF與業務代碼的耦合，所有的分布式功能均不再需要業務側關心，而統一由CDRFA內部實現。極致簡化了業務側的配置文件，也許下一步是做一個代碼自動生成功能，根據配置生成相應的業務代碼框架。重新實現如節點時延統計(CDRFA自動實現每個包的時延統計，業務無需關心)，單號碼日志跟蹤(改成消息包染色的方案，CDRFA遇到染色包自動打印日志)，應用命令功能(通過系統管理模塊的RESTful接口給節點內的應用程序下達指令)等等。提供接口全面展示集群的節點實時拓撲圖，並支持對集群節點微服務進行實時編排。增加了新的日志框架功能，提供高性能、多場景的日志輸出能力。應對這些改進同步增加了相應的單元測試。由此C++分布式實時應用框架2.0版本也應運而生！
一、集群實時拓撲圖
實時拓撲圖展示了集群的每個節點(容器實例)，連線代表通訊方向，孤立的節點表示未並網的節點。界面實時展示TPS(流量),RTT(時延)兩個數據，點開節點可以進入容器節點的管理界面，做更多容器節點的管理工作。
二、微服務編排
按第五篇《微服務架構的演進》的方案，我們增加了圖形界面支持微服務架構的編排。每個大圈表示一個類型的節點，小圈代表一個微服務端口。編排的時候從一個節點連線到另一個節點，並且選擇兩個節點要對接的微服務，即可完成編排。可以實時在集群運行過程中進行編排，完成編排后，集群狀態也會實時顯示在上面的拓撲圖當中。當然可以根據業務自身需要，增加新類型的節點，或者為節點增加新的微服務端口。可以看到每個節點都獨立非耦合，節點間的交互完全是通過微服務端口來進行，並且這些端口生效與否是通過微服務編排來進行控制的。
三、時延統計功能
時延統計功能是分布式框架的核心數據之一，用於實時檢測節點的性能，並依此采取相應的解決策略。原來這個功能是在業務側實現的，CDRAF2.0中，我們將這個功能提到框架中，可以計算所有節點的時延數據，並且業務無需關心(業務無需做任何事情即可獲得這個功能)。
CDRAF2.0中我們統一了節點的通訊模型，所有的節點均由Dis(數據分發)和業務處理進程組成。在一個業務包到達Dis后，框架會在這個包的包頭打進當刻時間，在業務進程處理完消息回到Dis后，Dis會計算兩個時間差得到時延數據。並將每個包的數據進行平均計算，上報狀態中心，並且可以在實時拓撲圖中展現出來。所有這些工作都由框架來完成。
四、單號碼日志跟蹤（包染色方案）
原來的日志跟蹤方案在收到號碼跟蹤命令后，會通知所有節點的所有進程都來關注這個號碼，遇到這個號碼的包后就把日志跟蹤打開。這個方案有幾大缺點：
a) 所有的業務進程都需要實現一份號碼檢測、開日志跟蹤的功能，代碼會無比冗余。
b) 當打開這個功能的時候，集群所有的節點，節點中所有的進程，都會處理監測是否有這個號碼的狀態中。整個集群處於一個十分不穩定狀態中。
c) 業務上可能不支持同時跟蹤多個號碼。
為此我們調整了單號碼日志跟蹤的方案，采用包染色的方案。在消息入口的位置檢測號碼，一旦符合條件就將這個消息包進行包頭染色，后面的處理環節框架收到包后會先於業務檢測包頭，如果發現包頭被染色，就會將日志跟蹤打開，這個包處理完畢后再關閉。每個環節往下傳的時候，框架都會自動為下傳的包再次進行染色，以保證處理流程上的每個環節接收到的都是經過染色的包。新方案的優點如下：
a) 業務上不再需要為這個功能實現相應的代碼，只要在入口位置進行一次號碼監測，如果符合就調用框架進行染色，后續所有操作都由框架來完成。
b) 打開這個功能的時候集群不再處理不穩定狀態，業務層面甚至感覺不到這個功能的存在，框架處理了所有的問題。
c) 當有新的業務節點加進來的時候，會自動獲得這個功能，而無需做任何改造。
d) 除了單號碼日志跟蹤功能，這個方案還可以應用於其它的業務場景。
五、通用指令傳遞方案
在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向通用型框架邁出的一大步！