做rpc选型时候,有人说到grpc,想在网上找一些grpc c/c++的源码分析来帮助理解,发现除了官方doc里带的文档外寥寥无几(也可能是自己没找到?)。只能自己捋起袖子“啃一啃”grpc的源码。
在进入正题之前,有必要简短的说一下我的分析思路,以免给一些读者带来困惑。
- 先整体后部分。框架结构、线程模型一开始就会说明。阅读一份陌生的代码,就像破解一个复杂案件,如果已经有人把大体走向和结果都告诉了你,你只需要根据主要线索去补充细节,想必会容易很多
- 这不是一份源码细节分析的文章,更侧重流程分析,这会帮助你更快的学习源码细节
- 代码选取的是grpc当前的master分支
1 普适性的rpc网络模型
![213e64b18e89d687e3b580b3ddfe7f38.png](https://i-blog.csdnimg.cn/blog_migrate/79b76d8e734f04b92ff9002bcf4acf46.jpeg)
上面的图是一个极简的网络模型图,当前大部分rpc的网络库都要经历上面的部分。
- bind常规操作
- listen描述符建立成功后会注册到epoll模型,等待链接接入
- accept成功建立
- accept描述符注册到epoll模型,等待请求
- 请求到来,描述符可读,处理请求,一般包括的协议的解析
- 请求送到逻辑模块或者叫做业务模块进行处理
- 逻辑处理完成等待发送
- epoll调度完成结果发送
2 grpc网络模型
grpc会启动多个线程的epoll来处理描述符。
![7f0b1e96bd931f9b99b7dca83c2e4579.png](https://i-blog.csdnimg.cn/blog_migrate/65de416b03b21732ee4dfff76b82a33d.jpeg)
- 得益于SO_REUSEPORT参数,同一个listenfd可以被放到多个epoll中进行监听
- 当一个链接成功建立后会生成acceptfd,这个acceptfd会被随机的分配到现有的epoll中,目前grpc的分配策略是轮询(round-robin)