背景：
位于阿里云的kubernetes集群，通过ingress svc暴露，类型为ClusterIP。某天在对集群内大量缩容节点时，马上出现了大量的502、504报警

以为外部密集请求导致后端服务受影响，从监控观察并无异常，联想到最近的变更，怕不是缩容导致？正在排查的过程中，服务恢复。事后通过工单确认
ClusterIP类型的SLB后端的rs被移除时，SLB的操作就是静默丢包，也就是该SLB对任何发过来的tcp包都会默认丢弃，DROP并不会响应

• 如果此时此链接是空闲链接，就会等待SLB设置的空闲链接超时时间，超过这个时间后，SLB断开链接
• 如果此时此链接还有请求，由于SLB不会回ack包，客户端就会超时重传，重传的时间就取决于客户端或者内核的超时设置，比如内核ack默认会进行15次重传(net.ipv4.tcp_retries2=15),累加起来大概是924秒，JDBC URL支持设置SocketTimeout、ConnectTimeout,会在这个超时时间后断开重连

文档描述
https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/add-annotations-to-the-yaml-file-of-a-service-to-configure-clb-instances

最终解法

• 代码中判断，失败重新建立连接
• 在ingress中开启上述注解，缩短时间。并在谷值时缩容

某日读写分离中间件报警，有大量非业务IP连接涌入，新连接无法建立。查询数据库连接有大量的”unauthenticated user 1.2.3.4:37414 NULL Connect NULL Reading from net NULL”。一时间大量用户报障，“登录失效”、“设备断连”、“影响产线生产”等等
解决过程倒不复杂，跳过中间件恢复。售后工程师承认是中间件设计问题，释放连接逻辑bug，也提到了有大量连接时可能触发！

反观自身，架构设计阶段把过多的压力放在主库，19年上线的读写分离中间件就是“业务迭代优先，没时间基础设施改造”、“历史包袱”背景下的缓兵之计。阿里云的问题有几点
1.中间件控制台无法显示真实IP，故障后对方研发回复“日志因升级规格消失？”
2.假死后控制台无法重启
3.控制台监控不准确，使用者无法准确选择
4.1.2版本释放连接逻辑bug
主因是内部某服务突然建立了大量连接，进而引发的故障。

• 开发阶段的考虑对运维阶段的影响：

开发阶段把更多的重点放在功能实现和业务迭代上，而忽略了基础设施的可扩展性。这可能会造成短期内的业务顺利进行，但长期看来，如果基础设施不能跟上业务的发展，最终可能会形成技术债务，导致在运维阶段遇到无法解决或者处理复杂度高的问题。

• 对云服务商SLA的信任问题：

云服务提供商的SLA（服务等级协议）是我们选择使用其服务的一个重要依据，但是是否100%信任SLA，我们需要结合自身的业务情况和对服务提供商的了解来决定。在应急情况下，我们可能需要更具备自主的故障应对能力，而不是完全依赖服务提供商的SLA。