降级：
减少工作量，丢弃不重要的请求。
确定具体采用哪个指标作为流量评估和优雅降级的决定性指标：
如 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),以及使用探针方式最小化放量，进行预热。
打分比较低的节点，避免进入 永久 黑名单，而无法恢复，使用统计
衰减的方式，让节点指标逐渐恢复到初始状态(即默认值)