RPC慨念模型：
双方的stub负责打包，RPCruntime负责发送和接收，中间有网络。
RPC 的好处：
1.单一职责，可以使用不同语言开发，有利于分工协作和运维开发
2.可扩展性强，可以独立扩充资源（双11）资源使用率更优
3.故障隔离，服务的整体可靠性更高
RPC 带来的问题
1.服务宕机，对方应该如何处理?
2.在调用过程中发生网络异常，如何保证消息的可达性?
3.请求量突增导致服务无法及时处理，有哪些应对措施?
--这些问题应有rpc框架解决
RPC 框架主要核心有三层: 编解码层、协议层和网络通信层
RPC 关键指标分析：
1. 稳定性
保障策略 ：
-熔断:保护调用方，防止被调用的服务出现问题而影响到整个链路
-限流:保护被调用方，防止大流量把服务压垮
-超时控制:避免浪费资源在不可用节点上
成功率：
-负载均衡
-重试
长尾请求：长尾请求一般是指明显高于均值的那部分占比较小的请求。 业界关于延迟有一个常用的P99标准， 也就是99%的请求延迟要满足在一定耗时以内， 1%的请求会大于这个耗时， 而这1%就可以认为是长尾请求。
-backup request 备份请求
注册中间件
2. 易用性
开箱即用：合理的默认参数选项、丰富的文档
周边工具：生成代码工具、脚手架工具
3. 扩展性
Middleware Option，编解码层 协议层，网络传输层，代码生成工具插件扩展
4. 观测性
Log、Metric、Tracing
内置观测性服务
5. 高性能
场景：单机多机，单连接多连接，单/多client 单/多server， 不同大小的请求包 例如 pingpong， 不同请求类型:streaming 等
目标：高吞吐 低延迟
手段: 连接池 多路复用 高性能编解码协议 高性能网络库
字节RPC实践-kitex
-Kitex Core 核心组件
-Kitex Byted 与公司内部基础设施集成
-Kitex Too 代码生成工具
自研网络库 - Netpoll
-解决无法感知连接状态问题 引入 epoll 主动监听机制，感知连接状态
-解决 goroutine 暴涨的风险建立 goroutine 池，复用 goroutine
-提升性能 引入 Nocopy Buffer，向上层提供 NoCopy 的调用接口，编解码层面零拷贝
合并部署
-微服务过微，传输和序列化开销越来越大
-将亲和性强的服务实例尽可能调度到同一个物理机，远程 RPC 调用优化为本地 IPC 调用
