【性能优化之道】每秒上万并发下的Spring Cloud参数优化实战

欢迎关注个人微信公众号：石杉的架构笔记（id：shishan100）

周一至周五早八点半！精品技术文章准时送上！！

 

往期文章

1. 拜托！面试请不要再问我Spring Cloud底层原理！

2.【双11狂欢的背后】微服务注册中心如何承载大型系统的千万级访问？

 

目录

一、写在前面

二、场景引入，问题初现

三、扬汤止沸，饮鸩止渴

四、问题爆发，洪水猛兽

五、追本溯源，治标治本

六、总结全文，回眸再看

---

 

一、写在前面

相信不少朋友都在自己公司使用Spring Cloud框架来构建微服务架构，毕竟现在这是非常火的一门技术。

如果只是用户量很少的传统IT系统，使用Spring Cloud可能还暴露不出什么问题。

如果是较多用户量，高峰每秒高达上万并发请求的互联网公司的系统，使用Spring Cloud技术就有一些问题需要注意了。

---

 

二、场景引入，问题初现

先不空聊原理、理论，来讲一个真实的例子，这是我的一个朋友在创业互联网公司发生过的真实案例。

朋友A的公司做互联网类的创业，组建了一个小型研发团队，上来就用了Spring Cloud技术栈来构建微服务架构的系统。一段时间没日没夜的加班，好不容易核心业务系统给做出来了，平时正常QA测试没发现什么大毛病，感觉性能还不错，一切都很完美。

然后系统就这么上线了，一开始用户规模很小，注册用户量小几十万，日活几千用户。

每天都有新的数据进入数据库的表中，就这么日积月累的，没想到数据规模居然慢慢吞吞增长到了单表几百万。

这个时候呢，看起来也没太大的毛病，就是有用户反映，系统有些操作，会感觉卡顿几秒钟，会刷不出来页面。

这是为啥呢？

• 核心原因是单表数据量大了一些，达到了几百万。
• 有个别服务，跑的SQL比较复杂，一大堆的多表关联
• 并且还没有设计好索引，或者是设计了索引，但无奈一些小弟写了上百行的大SQL，SQL实在太复杂了，那么一个SQL跑出来好几秒肯定是正常的。

如果大家对微服务框架有点了解的话，应该知道，比如Feign &