思维导图挺好的, 我们也用这个评审
方便看测试点和测试逻辑

可以收集一下反馈, 为啥产品研发没怎么投入
是听不懂看不明白, 还是用例太乱逻辑理不清, 还是又臭又长没重点

机械是真的苦...., 996 都是毛毛雨

最高点上车, 30% 左右

靓仔到时候拉我

听说不咋地, 还在上海苟

请问页面 ui 的设计也是 Kiro 或 trae 吗, 需要先搭建脚手架不, 我建空目录 ai 生成的页面就几个输入框和按钮, 没有任何设计

「我已经配置了弹性伸缩，也就是内存达到 80% 就应该要新启动一个实例」这个策略 k8s 应该只会申请资源, 不会启动新 pod
故障转移一般是 k8s 通过探针检测到 pod 不可用才会启动, 如果探针接口不受数据库影响那么 k8s 看来 pod 是可用的.
针对长连接的问题, 一般在服务层上接一个网关, 简单点就是加个 nginx(或者 ingress-inginx) 并配置负载均衡算法, 避免 http 长连接都发到一个后端 pod.

非常感谢~

有个问题比较好奇
既然是 db 连接数不够, 为啥要改负载均衡, 不应该是调整 mysql 连接池配置、优化 sql/索引/锁, 及时释放连接, 避免长期占用
pod 再多也 db 还是连接数不足, 拥堵不更严重了吗