假如目前的系统有100台机器，能够支撑每天1亿的点击量(这个就简单比喻一下)，然后系统流量剧变了要，我如何应对，系统有那些策略可以处理，这里总结了一下之前的一些做法。
1、水平扩展
这个最容易理解，加机器，这样的话对于系统刚刚开始的伸缩性设计要求比较高，能够非常灵活的添加机器，来应对流量的变化。
2、系统分组
假如系统服务的业务不同，有优先级高的，有优先级低的，那就让不同的业务调用提前分组好的机器，这样的话在关键时刻，可以保核心业务。
3、系统限流
系统机器也加了，然后分组也做了，但是就是能力提升不上来，说白了就那样了，这时候，可以设置系统的极限能力阀值，例如QPS最大到多少，或者是同时并发的任务有多少，超过这个阀值之后就拒绝提供服务了。
4、业务引流
这个的话跟多的是业务做的事情，把流量引走，不要来请求系统了，一种简单的做法就是，冗余的业务直接隐藏掉链接，从开源节流的角度来想，就是开源。
5、业务降级
如果一个系统请求，涉及到多个逻辑处理，其中有的是可以没有的，就是类似锦上添花的那种，在高并发的情况下，可以通过系统开关的形式，不去做这个请求，这样就间接的提升了系统的能力，毕竟少做了一件事情。
6、依赖系统的能力扩展
如果单独看应用系统，可能东西要做的还真不多，但是要结合上下游的系统，尤其是下游依赖的存储系统，数据库是否能够支持够，分布式缓存是否能够支持够，都需要做好评估。
7、系统依赖梳理
上一条主要是说存储系统，如果本身是SOA的形式，可能会依赖其他系统，各个系统是否强弱依赖，在那个环节依赖了，都需要评估出来，可以人肉来做，也可以系统分析调用情况，来自动的做出来。
8、系统容量评估
系统到底能够撑多少的量，这个要有个客观数字的评估，需要结合系统的负载以及响应时间等数据，搞出一个模型出来，这样方便数字化出来。
9、数据库的读写分离以及主备按照读写比例进行划分
这个在数据库方面可以做优化
本文作者：iamzhongyong
来源：51CTO