背景
对于项目，owner意识很重要，有些紧急的必须将兜底方案上上去。流量太大时，系统接口响应时间特别慢，设置超时当时一群人束手无策，CPU、内存波动不明显，唯一相关的数据库亦是如此，连慢数据也没有。只能先通过压测来复现当时的根因。并且要趁早将问题修复，以免造成更大的影响。
我的局限思维
反正后续流量也没有那天大，没有上兜底方案，以及扩容等等措施，也没啥问题啊。经过一周的性能压测，得到扩充实例对于接口响应能力并没有实质性的作用。那么只剩兜底方案，根据剩余的时间，要快速开发出一个旁路限流网关还是有一定难度的，不然这次再等一等。应该是上不了这个补丁的。
应该有的owner思维
消费者流量是不可预测的，要对所有最坏情况做出应急方案。如果有兜底方案就必须应急的上。这样才能减少消费者对产品乃至于整个品牌的观感。
补丁必须上，赶紧评估出工作量、分析可行性，端午就算加三天，也要把它赶出来。
此时才发现，我是这个项目的owner，居然想法这么逃避和不负责任。实属不应该，还好老大用了自己的行动给我上了一课。思维不能僵死固化。这才是正确的思路。
tip
- 可以上云服务提供的APM，探针等功能 直接分析各种应用接口级别链路
- Tomcat 最大连接数、最大线程数、接收数
- 进容器看看连接数 netstat -nat | grep -i "端口号" | wc -l
网友评论