腾讯微服务框架-MSEC（spp-rpc）

第一张：UML图

链接：https://www.processon.com/view/link/5852139ce4b05a02846e5c11

（虚线表示基类）

不是我故意画得那么复杂，而是原本就那么复杂。

核心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)回包逻辑

1. 轮询shm。同样是在 CDefaultProxy 中的realrun方法中，it->second->poll(true)监听回包共享内存；
2. 监听到有回包。CShmCommu的poll方法，如果有mem_queue_pop_nm出来
3. 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