后端开发07-深入浅出rpc框架
1. rpc框架分层设计
01 基本概念
RPC - remote procedure calls
需要解决的问题：
- 函数映射
- 数据转换成字节流
- 网络传输
IDL interface description language文件，接口描述文件
生成代码，用户代码依赖生成的代码
编解码， 序列化和反序列化
通信协议， 源数据
网络传输，tcp/udp
rpc好处：
- 单一职责，不同的模块可以用不同的语言进行开发， 有利于分工协作和运维开发
- 可扩展性强（节日对某些服务扩容），资源利用率更优
- 故障隔离，服务的整体可靠性更高
rpc弊端：
被调用服务宕机比
网络一场，保证消息可达性
流量突增的应急措施？
02 分层设计
编解码层
协议层
网络通信层
二进制编码：Thrift的BinaryProtocal -- TLV编码(tag, length, value)
增加了额外的开销，tag和length
特殊结束符协议：http \r\n作为结束符
变长协议：开头加入长度
网络通信层——socket编程
2. 关键指标分析与企业实践
03 关键指标
稳定性：保障策略
熔断：保护调用方，防止被调用的服务出现问题而影响到整个链路
限流：保护被调用方， 防止大流量把服务压垮
超时限制：避免浪费资源在不可用节点上
稳定性：请求成功率
负载均衡：均匀调用，不要让某个服务器压力过大
重试：重试增加请求成功率
稳定性：长尾请求
明显高于平均请求速度的请求
Tp999
长尾请求的原因比较多：gc、网络抖动
解决策略Backup request：备份请求
设置的t3是99%能返回的请求的时间长度，发现还没返回的话就发送req2作为备份请求
T4 > t1 + t2
稳定性解决方案： 注册中间件（Middleware/拦截器）
易用性：
开箱即用
周边工具：生成代码工具，脚手架工具
观测性
log：日志
metric：监控，比如qps是多少
tracing：链路跟踪，traceid
内置观测性服务：环境变量、线程、协程、服务环境变量
top命令行
高吞吐、低延迟
04 企业实践
字节企业内部的实验
整体框架
自研网络库的背景
原生库：连接池中存在实效连接，并且可能gorutine暴涨
Just in time 即时编译：用到代码的时候再编译
减轻用户维护代码的负担，上下游同时改idl的时候不用同时更新——frugal
合并部署
微服务过于微（字节已经有几万个微服务了），传输和序列化开销越来越大
将亲和性较强的服务实例尽可能调度到同一个物理机，远程rpc调用优化为本地ipc调用
比如开屏服务调用广告服务，将这两个服务放到一起
