前段時間想在網上找一些grpc c/c++的源碼分析來看，發現除了官方doc裡帶的文檔外寥寥無幾（也可能是自己沒找到？）。只能自己捋起袖子“啃一啃”grpc的源碼。

在進入正題之前，有必要簡短的說一下我的分析思路，以免給一些讀者帶來困惑。

1. 先整體後部分。框架結構、線程模型一開始就會說明。閱讀一份陌生的代碼，就像破解一個複雜案件，如果已經有人把大體走向和結果都告訴了你，你只需要根據主要線索去補充細節，想必會容易很多
2. 這不是一份源碼細節分析的文章，更側重流程分析，這會幫助你更快的學習源碼細節
3. 代碼選取的是grpc當前的master分支

1 普適性的rpc網絡模型

上面的圖是一個極簡的網絡模型圖，當前大部分rpc的網絡庫都要經歷上面的部分。

1. bind常規操作
2. listen描述符建立成功後會註冊到epoll模型，等待鏈接接入
3. accept成功建立
4. accept描述符註冊到epoll模型，等待請求
5. 請求到來，描述符可讀，處理請求，一般包括的協議的解析
6. 請求送到邏輯模塊或者叫做業務模塊進行處理
7. 邏輯處理完成等待發送
8. epoll調度完成結果發送

2 grpc網絡模型

grpc會啟動多個線程的epoll來處理描述符。

• 得益於SO_REUSEPORT參數，同一個listenfd可以被放到多個epoll中進行監聽
• 當一個鏈接成功建立後會生成acceptfd，這個acceptfd會被隨機的分配到現有的epoll中，目前grpc的分配策略是輪詢（round-robin）

3 grpc線程模型

接著從線程模型的角度再來認識grpc。先上圖

• 圖中綠色的方框代表線程
• 紅色虛線表示新線程的創建
• 紅色方框是公共的list
• 藍色字體的方框是“關鍵字”，標示了第一章網絡模型中出現的關鍵字，方便一一對應
• DoWork是邏輯處理模塊

1. main是主線程，完成了描述符的bind和listen。創建了兩個執行線程default-excutor和reslover-excutor，創建了一個epoll_wait線程SyncRequestThreadManager，SyncRequestThreadManager數量是可配置的
2. default-excutor線程等待紅框grpc_closure_list中的任務，main線程通過GRPC_CLOSURE_SCHED方法將任務放到grpc_closure_list中來激活default-excutor執行任務。default-excutor完成了listenfd和epoll的創建，並將listenfd註冊到了epoll中
3. SyncRequestThreadManager線程用來epoll_wait，處理讀、寫操作。同時處理請求的具體邏輯
4. 暫時沒發現resolver-executor的很具體的用處。歡迎各路同學前來補充

後續的文章會以上圖為基礎，介紹每個線程中的關鍵環節的處理流程。

ps: 看到這兒，如果有跟我一樣“喪心病狂”想“受虐”的同學，可以直接跳轉https://github.com/grpc/grpc網站開始擼代碼了。對了，https://github.com/grpc/grpc/tree/master/doc下面的doc文檔建議先讀一下，然後看一段時間代碼再來閱讀一下文檔。

閱讀更多 路小飯 的文章

關鍵字: 源碼 C語言 前段時間