系统负载剧变下的管控策略

假如目前的系统有100台机器，能够支撑每天1亿的点击量（这个就简单比喻一下），然后系统流量剧变了要，我如何应对，系统有那些策略可以处理，这里总结了一下之前的一些做法。

1、水平扩展

这个最容易理解，加机器，这样的话对于系统刚刚开始的伸缩性设计要求比较高，能够非常灵活的添加机器，来应对流量的变化。

2、系统分组

假如系统服务的业务不同，有优先级高的，有优先级低的，那就让不同的业务调用提前分组好的机器，这样的话在关键时刻，可以保核心业务。

3、系统限流

系统机器也加了，然后分组也做了，但是就是能力提升不上来，说白了就那样了，这时候，可以设置系统的极限能力阀值，例如QPS最大到多少，或者是同时并发的任务有多少，超过这个阀值之后就拒绝提供服务了。

4、业务引流

这个的话跟多的是业务做的事情，把流量引走，不要来请求系统了，一种简单的做法就是，冗余的业务直接隐藏掉链接，从开源节流的角度来想，就是开源。

5、业务降级

如果一个系统请求，涉及到多个逻辑处理，其中有的是可以没有的，就是类似锦上添花的那种，在高并发的情况下，可以通过系统开关的形式，不去做这个请求，这样就间接的提升了系统的能力，毕竟少做了一件事情。

6、依赖系统的能力扩展

如果单独看应用系统，可能东西要做的还真不多，但是要结合上下游的系统，尤其是下游依赖的存储系统，数据库是否能够支持够，分布式缓存是否能够支持够，都需要做好评估。

7、系统依赖梳理

上一条主要是说存储系统，如果本身是SOA的形式，可能会依赖其他系统，各个系统是否强弱依赖，在那个环节依赖了，都需要评估出来，可以人肉来做，也可以系统分析调用情况，来自动的做出来。

8、系统容量评估

系统到底能够撑多少的量，这个要有个客观数字的评估，需要结合系统的负载以及响应时间等数据，搞出一个模型出来，这样方便数字化出来。

9、数据库的读写分离以及主备按照读写比例进行划分

这个在数据库方面可以做优化，跟进系统的读写情况，划分，读写分离，全力保证写，然后如果读的压力太大，可以增加备库来提供读服务。

 

大体想到了几个点，简单的罗列一下。