前段时间想在网上找一些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文档建议先读一下，然后看一段时间代码再来阅读一下文档。