production issues 汇总

outage
- 服务过载之后, 没有空余连接处理readiness check, 导致k8s重启了pod, 
同时scale up的速度太慢, 导致了cascading failures,大量的pod 过载并被k8s重启, 
而新增加的pod很快被高负载压垮, 也开始不断被重启

临时解决方法:
- 关掉了readiness check，这样pod不会被重启了
- 同时scale up, 可以抗住流量
- 调整autoscaler的策略, 预留更多的pod
- 重新打开readiness check

目前的问题和解决方案
- 为什么会过载?
- 当前单个pod只能同时支持4个并行请求, 当更多的请求被发送过来之后, 会导致服务过载
# 单个pod, 慢速接口的处理能力提升
# 引入本地缓存

- 当前未做快慢分离, 慢的api请求可以拖垮整个服务
# 快接口和慢接口分离
# 快接口和满接口分开scale

- 核心接口和非核心接口
# 开关熔断降级
# fallback策略

- 客户端的重试逻辑, 造成DDOS, 而我们没有限流策略, 任凭流量大量涌入, 直接击垮服务
# 引入限流机制
# 引入消息队列
# 引入异步消息处理

为什么scale up很慢
- 服务启动是, 需要加载大量secret, 这个过程比较慢


traceability
monitor
metric

我们现在还有的问题是
- 功能发布导致的 outage
# 发布新功能时, 如果有bug会影响所有人, 即便做了充分的测试, 也不能100%规避这个问题
# 有些功能只有在生产数据上, 生产的配置, 用户量的情况下才会暴露出来, 所以我们完全可以
# 灰度的时候, 采用1 2 3 4的策略, 逐步放开版本, 遇到问题我们再回滚回去, 这样不会大面积的影响用户

- 热点数据导致的 outage
# 紧急扩容
# 提前扩容 - 需要构建预测系统, 依赖日志上报, 实时数据分析, 发现当前的热点，然后推送热点数据到服务端, 毕竟人多力量大

- 正常的流量导致的 outage
# 需要考虑ROI, 所以针对这种无论如何你都扛不住的请求, 必须要保证核心业务接口可以正常服务, 其它的接口可以关掉或者降级
# 比如实时性要求不高的, 转成异步处理, 能临时用本地数据的, 就用本地数据, 能写日志就不要访问远端数据, 总之就是退而求其次, 把资源都让出来给核心业务

- DDOS导致的 outage
# 需要安全策略, 黑名单, 把这些请求清洗掉

还没有做的
- 读写的分离
- 核心接口和非核心接口的分离
- 快慢分离
- 轻重分离
- 高并发和低并发接口的分离