本地函数调用 压栈弹出
RPC调用 网上购物 {（付款操作）
远程调用 中间隔着网路 不能用函数指针了 是两个进程 机器id找到函数运行
解决问题 1. 函数映射
- 数据转换成字节流 （客户端转换成字节流 传送给 服务端）
- 网络传输（高效稳定传输数据）
}
过程：User本地调用 打包参数 -》 RPC -》 对端-》解压-》调用真正业务逻辑 然后在返回 整个流程
IDL文件（接口描述文件）
Caller（调用段）和 生成代码 -》 encoder编码 -》字节流 -》打包传送给对端
好处
编解码层：
二进制编码
左侧是IDL中写的统一的 -》字节流 有额外的内存开销 ：length tag
多路复用：同一个链接内 可以有多个请求流通过
协议解析：
SCOEKT API （ip+端口）
一端关闭套接字 如果另一端如果尝试去读 可能就会返回（End Of File）也就是 EOF 在项目中我好像遇到过这个问题 用postman测试的时候返回了EOF错误和nil
网络库
稳定性 易用性 扩展性 观测性 高性能
稳定性：
**过程：**a调用b b调用c c如果响应慢 b就会一直等待 a也就超时了 a就会频繁调用b b堆积大量请求就会宕机
熔断起保护作用
稳定性：请求成功了率
1.均匀调用服务的每个节点
- 重试几次
备份请求： 左侧正常 1失败 2是重试请求 总时间 t1＋t2
右侧 t3 tct99（这个值 在这个时间内应该可以返回值）如果在时间内没返回 就发送2请求 总时间就是 t4
自动生成代码工具 ： 减少重复性工作
用户请求 经过中间件处理-》和远端交互 -》 也通过中间件处理-》服务器
日志观察 监控面板qbs 链路跟踪（服务通过请求为什么超时了 耗费的时间是多少）
linux的top工具类似原理
高吞吐：在单位时间内尽可能多的处理更多请求
低延迟： 一次请求发出去延迟尽可能地低（重要）
字节实践：
组件 结构 远端交互层 网络库 代码生成工具 （最左侧）
为什么自研网络库？
gonet
Netpoll
交互方式pingpang（一发一回） 编解码 应用层协议
优化：
你应该想这些是怎么实现的？
HTTP 超文本传输协议
http协议将人话以计算机语言传输过去
请求行
：分隔 原数据
包的字节数
大空行
我们想说的话
下面是回复
![image-20241108133725032](C:\Users\30413\AppData\Roaming\Typora\typora-user-images\image-20241108133725032.png
上述功能代码：
处理流程wwwwwwww333333：
H1的不足 H2也没完全解决 UDP解决对头阻塞
高内聚 低耦合 易复用 高扩展性
应用层
中间件层 预处理
路由层
协议层
中间件设计：
洋葱模型
路由设计： map[string]handlers 静态路由有效 动态不太行
前缀匹配树构建路由：
啊啊啊啊：前两天刚看 7_days_golang 构建动态路由的方法
这里就讲解了 啊啊啊
参数路由：
协议层设计
网络层设计
为什么做成一个问题
服务发布（难题）： 服务升级运行新的代码的过程（升级后的代码（服务发布）本地很简单 ）
服务不可用：
服务抖动：
服务回滚：
蓝绿部署： 升级服务b 把b的实例分成 绿色 和 蓝色两个集群
一个一个升级 断开b升级b导入a
再导入b关闭a升级a
蓝绿部署 流量低的时候部署
金丝雀发布：
放一只金丝雀 确保没有瓦斯（探险）
一点点发布查看是不是有很大的问题
一点点探测危险 （%1~%100）
租用了一台公网ip
现状 找一个物理机 ifconfig将网卡配上这个ip 起server监听即可
应用多 起多个server监听不同的端口
基于ip＋端口 基于某种算法 将报文转发给后端服务器
RR轮询：
加权RR轮询：
最小连接
五元组hash
一致性hash
FULLNAT
纯用户态协议栈
无缓存 零拷贝 大页内存 （减少 cache miss）
7层负载均衡
NGINX：
最灵活的高性能Web 7层反向代理
：
七层负载均衡
配置https访问