系统搭建初期,需求简单,架构简单,请求量少,快速原型开发,对rpc要求不高

随便找一个顺手的或者熟悉的rpc框架套进系统中即可

随业务复杂度增高,请求量增高,RPC框架一些致命的问题,比如大扇出问题

每一次请求,上游服务都要获取下游A~Z 26个服务的结果,然后把这26个结果拼装返回给前端

一个业务复杂的系统经过服务拆分,最后拆成一些高内聚低耦合的独立服务,非常容易达到这样一个服务种类数,26还远远不是很多

传统同步的RPC怎么解决?

并行访问各个下游服务(串行请求导致 一次请求的响应时间至少为timeA + timeB + …… + timeZ),只能通过多线程并发

一次请求至多需要 max(timeA, timeB, ……, timeZ),但是实际上要比这个稍多

必须弄一个请求线程池,可是这个池子要多大呢?

前端请求速率为 P,为保证每个请求处理时间尽可能快,需要大小为 26 * P的线程池

初看可能还可以应付,请求线程在发送网络请求后,会阻塞在IO,放弃CPU,使得计算线程获得CPU,不会浪费多少CPU的资源

但P大了后,为100或者1000,线程数过多会造成CPU调度开销增大,线程切换负担

反应器模型(简单举例)可减少请求线程数

Epoll进行后端服务的请求以及数据的接收,无论多少请求,只使用一个线程完成

通过Epoll机制在数据到来或者可发送的情况下通知用户进程,只不过最后需要把接收到的数据返回给计算线程使用

很多开源RPC框架,fbthrift,GRPC都可以应对大扇出