一、整体设计

考虑到框架的跨语言性，RPC借助了Service Mesh的思想，即主体为一个Proxy Agent作为Sidecar单独部署，同时提供一个特别轻量的SDK以进行流量劫持。

类似于：

etcd为注册中心，可以自己替换为自己的实现或者其他的开源实现。

主体部分的Agent部分除了最普通的消费服务、注册服务、进行Rpc调用外同时还要负责服务治理，包括熔断、限流、服务降级等功能。

通信协议：

字段	作用
magic	魔数
version	版本
type	类型：req or res
id	请求id
serializableType	序列化类型
compressType	压缩类型
messageType	消息类型：心跳、异常、正常
dataLength	数据长度

通信方式：

• Agent与应用程序之间通过Http交互，Agent提供 http2.0和 http3.0 API。(采用异步的方式)
• Agent与Agent之间交互提供TCP(基于Netty，复用EventLoop)、RDMA(用于局域网)两种
• Agent与注册中心，由于注册中心使用的是自己写的，所以使用TCP来通信
• Agent与配置中心，监控平台通过 Http2.0 进行通信

• Agent与Agent 通过 tcp 维持长链接，且provider向consumer发送心跳
• Agent与应用之间不维持长链接，Agent 使用一个定时线程以固定的时间间隔向应用发起http请求，检查其是否存活
• 应用通过Agent传递Rpc调用参数时，参数列表通过json串的方式来传递，返回结果同理，json解析为双重嵌套Map，即Map< String,Map< String,String>>的类型，key为参数名，内层Map为该参数的属性，每个都有的一条为该参数是否是复杂对象，如果是的话，内层Map的key为该复杂对象的字段名，value为字段值，如果是简单对象，则内层Map除了标记其是否为复杂参数的属性外，只有一个元素，则该元素的value为该简单属性的值

二、Agent模块设计

模块：

• 配置模块，负责对Agent进行配置，比如选择Agent之间的通信方式(TCP or RDMA)
• 核心模块，负责提供消费者端代理，发起rpc请求、向Provider调用对应的服务、服务的熔断、限流、降级
• 注册模块，负责服务发现与注册
• 集群模块，负责负载均衡
• 监控模块，将Agent的一些必要信息定时发送给监控中心
• 协议模块，负责编解码、序列化
• 通信模块，负责提供与应用的通信交互、与Agent的通信、与监控中心、配置中心的通信

三、详细设计

配置

通用配置：

• 代理类型：consumer or provider
• 默认心跳间隔
• 网络传输方式
• I/O线程池的大小
• 工作线程池的大小
• Agent工作端口：应用注册时，通过Agent来进行注册，Agent将端口更改为自己的服务端口，这样当Consumer进行rpc调用时，会将请求发到provider Agent，provider agent再根据服务名等信息发向对应的服务

服务端配置：

• 降级策略：异常数、异常比例、慢比例调用，降级与熔断的不同是，降级为整体级别的，如果总体的异常数超过阈值，则该机器进入降级模式，在降级模式中，设置了降级的服务会进行降级处理，未设置的正常处理
• 熔断策略：异常数、异常比例、慢比例调用，此处设置的是通用的，每个服务实例可以通过请求设置自己具体的熔断策略
• 限流策略：漏桶、令牌桶、限制单位时间内调用量
• 服务权重

消费端配置：

• 负载均衡策略：随机、加权随机、一致性hash、负载最小
• 序列化方式：pb、json、hessian
• 压缩方式：zip、gzip
• 检查服务端是否存在
• 容错策略：失效切换、快速失败、重试
• 重试次数

注册中心配置：

• 注册中心类型
• 注册中心地址
• 连接超时时间
• 请求超时时间
• 失败重试时间间隔
• 重试次数

配置中心配置：
todo…

四、代码

todo列表：

• PA对服务健康检查
• 服务下线后，PA取消注册，CA可以自动切换
• CA端容错
• PA端的熔断、限流实现
• PA与配置中心交互

熔断：

• 每个服务对应一个熔断器，熔断器包含三种状态：close、half-open、open。
• 当该服务在规定时间内失败N次或者失败次数的比例超过某个阈值(根据熔断策略决定)则熔断器进入open状态M秒，在这N秒之内，服务直接返回错误或者Mock默认数据，之后进入half-open状态，判断是否在S秒内成功的调用次数或者比例超过阈值，超过则关闭熔断器，服务正常调用，否则继续进入熔断状态M秒