微服务(二) | 青训营笔记
这是我参与「第五届青训营 」伴学笔记创作活动的第 7 天,本文是课程「微服务框架 - 不变的基建」的学习笔记第二部分。
服务注册及服务发现
-
基本问题
- 服务间调用中,如何指定下游服务实例的地址?
-
简单方案
-
直接指定 ip:port?
- 没有任何动态能力
- 有多个实例下游实例怎么办?
-
使用 DNS?
- 本地 DNS 存在缓存,导致延迟
- DNS 没有负载均衡
- 不支持服务探活检查
- DNS 不能指定端口
-
-
服务注册发现
- 新增一个统一的服务注册中心,用于存储服务名到服务实例之间的映射关系
- 旧服务实例下线前,从服务注册中心删除该实例,下线流量
- 新服务实例上线后,在服务注册中心注册该实例,上线流量
-
微服务流量特征
- 统一网关入口
- 外网通信多数采用 HTTP,内网通信多数采用 RPC(Thrift, gRPC)
流量治理
-
流量控制
- 在微服务架构中,可以从各个维度对端到端的流量在链路上进行精确控制
-
控制维度
- 地区维度
- 集群维度
- 实例维度
- 请求维度
稳定性治理
-
限流
- 限制服务处理的最大 QPS,拒绝过多请求
-
熔断
- 中断请求路径,增加冷却时间从而让故障实例尝试恢复
-
过载保护
- 在负载高的实例中,主动拒绝一部分请求,防止实例被打挂
-
降级
- 服务处理能力不足时,拒绝低级别的请求,只响应线上高优请求
字节跳动服务治理实践
-
请求重试的意义
-
本地函数调用
- 通常没有重试意义
-
远程函数调用
- 网络抖动、下游负载高、下游机器宕机......
- 重试是有意义的,可以避免偶发性的错误,提高 SLA
-
重试的意义
- 降低错误率
- 降低长尾延时
- 容忍暂时性错误
- 避开下游故障实例
-
-
请求重试的难点
-
幂等性
- POST 请求可以重试吗?
-
重试风暴
- 随着调用链路的增加,重试次数呈指数级上升
-
超时设置
- 假设调用时间一共1s,经过多少时间开始重试?
-
-
重试策略
-
限制重试比例
- 设定一个重试比例阈值(例如 1%),重试次数占所有请求比例不超过该阈值
-
防止链路重试
- 返回特殊的 status code,表示“请求失败,但别重试”
-
Hedged Requests
- 对于可能超时(或延时高)的请求,重新向另一个下游实例发送一个相同的请求,并等待先到达的响应
-
-
重试效果验证
- 字节跳动重试组件能够极大限制重试发生的链路放大效应