引入Spring Cloud技术，遇到每秒上万的并发，该怎么抗？

 写在前面

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

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

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

 

# 场景引入，问题初现

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

朋友A的公司做互联网类的创业，组建了一个小型研发团队，上来就用了Spring Cloud技术栈来构建微服务架构的系统。

 

一段时间没日没夜的加班，好不容易核心业务系统给做出来了，平时正常QA测试没发现什么大毛病，感觉性能还不错，一切都很完美。

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

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

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

这是为啥呢？

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

如果大家对微服务框架有点了解的话，应该知道，比如Feign + Ribbon组成的服务调用框架，是有接口调用超时这一说的，有一些参数可以设置接口调用的超时时间。

如果你调用一个接口，好几秒刷不出来，人家就超时异常返回，用户就刷不出来页面了。

# 扬汤止沸，饮鸩止渴

一般碰到这种事情，一大坨屎一样的SQL摆在那儿，写SQL的人过一个月自己都看不懂了，80%的工程师看着都不愿意去花时间重写和优化。

一是修改的人力成本