go 进阶训练营 微服务可用性（下）笔记

降级：

减少工作量，丢弃不重要的请求。

确定具体采用哪个指标作为流量评估和优雅降级的决定性指标：

如 CPU、延迟、队列长度、线程数量、错误等

当服务进入降级时，需要执行什么动作？

流量抛弃或者优雅降级应该在服务的哪一层实现？是否需要在整个服务的每一层都实现，还是可以选择某个高层面的关键节点来实现？

优雅降级不应该被经常出发，通常触发条件是容量规划的失误，或者是意外的负载

内部参与的项目，聚合多个部门的接口进行展示，配置了降级逻辑，设计的足够简单，因为平常是不怎么使用的，如果特别复杂等到需要使用的时候操作比较复杂。

应该足够简单 -- 演练

重试：

当请求返回错误，对于backend部分节点过载的情况下，倾向于立刻重试，但是需要留意重试带来的流量放大

限制重试次数和基于重试分布的策略(重试比率：10%)

随机化、指数型递增的重试周期：exponential ackoff+jtter

client 测记录重试次数直方图，传递到server，进行分布判断，交由server判定拒绝

只应该在失败的这层进行重试，当重试仍然失败，全局预定错误码，过载，无须重试，避免级联重试

503 逐层放行，往上抛

负载均衡：

数据中心内部的负载均衡

理想情况下，某个服务的负载回完全均匀地分发给所有后端任务。

在任何时刻，最忙和最不忙的节点永远消耗同样数量的CPU.

目标：

均衡的流量分发

可靠的识别异常节点

scale-out,增加同质节点扩容

减少错误，提高可用性

backend 之间的load差异比较大：

每个请求的处理成本不同

物理机环境的差异：

服务器很难强同质性

存在共享资源争用（内存缓存、带宽、IO等）

性能因素：

FullGc

JVM JIT

负载均衡算法：缺乏的是服务端全局视图，负载+可用性

选择backend:CPU,client:health、inflight、latency,

使用一个简单的线性方程进行打分

p2c 算法：本质就是根据服务器的各种资源进行打分计算，然后选择合适的节点进行请求。

https://github.com/go-kratos/kratos/blob/v1.0.x/pkg/net/rpc/warden/balancer/p2c/p2c.go

对新启动的节点使用常量惩罚值(penalty),以及使用探针方式最小化放量，进行预热。

打分比较低的节点，避免进入 永久 黑名单，而无法恢复，使用统计

衰减的方式，让节点指标逐渐恢复到初始状态(即默认值)