这次咱们从根源聊：16招搞定高并发架构设计(14)_：这次咱们从根源聊：16招搞定高并发架

在稳定性和弹性方面同样需要做很多工作，否则依赖系统的抖动可能一下子把自己搞死。

1、压测

个人认为关键链路上做的任何变更，包括代码修改，网络变更，按道理都需要在准生产或灰度进行压测后才能正式上线。之前也遇到过几次这样的案例：

因为系统多执行了一条SQL导致方法执行时间多了10ms，导致MQ消费速度变慢形成队列堆积，队列越积越多，最后MQ扛不住崩溃了因为内部网关开启了验签增加了几毫秒的处理时间，所有服务的调用都经过网关，累计的调用时间累计增加了几百毫秒导致业务系统的处理线程一下子多起来然后OOM了在非生产压测往往结果和生产差异很大，在生产压测需要考虑对业务的影响以及测试数据的清理。

而且压测需要考虑依赖服务是否可以参与一起压测，要真正在生产实现全链路压测的落地需要整个公司技术资源的协同，还是非常考验管理执行力，这往往不是技术问题。

2、隔离

隔离说的是在设计的时候需要考虑不同业务、不同SLA的服务在共享同一套资源的时候是不是会因为产生性能问题导致相互影响，如果会影响，并且我们不能接受这样的影响的话就需要考虑各种层次的隔离，比如：