騰訊微服務框架-MSEC（spp-rpc）
阿新 • • 發佈：2019-02-20
第一張：UML圖
（虛線表示基類）
不是我故意畫得那麼複雜，而是原本就那麼複雜。
核心class介紹：
兩個基類：
- CFrame:框架公共類,主要包括框架日誌物件、框架監控日誌物件、框架統計物件；
- CServerBase:伺服器程式基礎類，包含執行環境初始化、日誌、統計、監控物件
三個程序，都繼承以上兩個基類：
- controller程序：CDefaultCtrl類，主要負責controller，通過訊息佇列來監控proxy和worker的健康度
- proxy程序：CDefaultProxy類，負責接受使用者請求，講請求資料寫入到共享記憶體
- worker程序: CDefaultWorker類，業務處理邏輯，從共享記憶體中讀取請求資料，進行業務處理完成後，寫回到共享記憶體。
其他核心class
- CTCommu（通訊類抽象介面）
- CTSockCommu(網路通訊類)：網路監聽，接收網路請求，epoll操作
- CShmCommu(共享記憶體操作類)：共享記憶體相關操作類，和
CTSockCommu都繼承於CTCommu,也實現了poll方法,這裡的poll只是從共享記憶體中獲取資料，和unix底層的poll不同,比較容易誤導.
- CMQCommu（訊息佇列通訊類）：controller程序通過訊息佇列**監控**proxy程序和worker程序.
啟動後的程序：
第二張: proxy接收客戶端請求的流程是怎樣的？
程序啟動後，會生成有兩個共享記憶體（shm），一個儲存網路請求資料，另一個儲存處理後的回包資料。
proxy程序主要的任務是兩塊：接收客戶端請求 和 從共享記憶體取出處理完的資料回包給客戶端：
(1)接收請求邏輯
proxy程序起來後，執行 CDefaultProxy 中的realrun方法， CDefaultProxy有兩個核心成員變數：
CTCommu* ator_;//接受者
map
(2)回包邏輯
- 輪詢shm。同樣是在
CDefaultProxy中的realrun方法中，it->second->poll(true)監聽回包共享記憶體； - 監聽到有回包。
CShmCommu的poll方法，如果有mem_queue_pop_nm出來 - sendto回客戶端。ctor_recvdata中
CTSockCommu中的CTSockCommu
第三張: worker是如何處理業務請求的？
如果理解了proxy的處理邏輯，那麼再來看worker的邏輯就稍微簡單了：
1. 從shm讀取請求資料。
2. 呼叫執行業務程式碼。
3. 回寫shm。
4. proxy從shm讀取資料，響應給客戶端。
轉自： https://blog.csdn.net/qq_35440678/article/details/53749462