双11买！买！买！淘宝秒杀，天降红包雨，春运抢火车票这些高并发场景，总会让大部分测试人员觉得不可思议，叹为观止。
当然，笔者对这些性能挑战也是心驰神往。可惜笔者则最多面对几千上万人的抽奖活动性能场景，但这不妨碍笔者对这些高性能场景实现做一些方案性的思考。
1、页面与接口（服务）分离
就是前端页面与接口应该分开独立存放。
具体来讲，应该怎么做呢？
如果是APP，页面可以尽量使用原生来做，而结果采用接口返回。并且，该功能接口尽量不与其他功能产生依赖关系；最好原子化，方便后面进行针对性的性能扩展。
而对于Web页面，则前端与接口应该物理分离（线路分离），并通过前端均衡负载和CDN提高加载性能。同时还可以对页面拆分做负载均衡。
这里以APP中定时抽奖活动为例：
如果我们把APP抽奖活动的页面采用原生做，那用户在整个抽奖活动中，除抽奖结果记录，抽奖结果反馈外，是感受不到性能问题的。
而关于抽奖结果记录和抽奖结果反馈，由独立的接口返回。则可以优化接口服务的性能即可。而且由于该部分服务的独立性，除考虑程序调优、服务器配置调优、网络优化，数据库调优及读写分离等常规的性能优化策略外，还可以考虑CDN、负载均衡、极速部署进行性能优化。
2、任务调度与处理集群
处理好任务调度分配规则，并把处理服务集群化。
当有请求任务时，是按IP分配服务处理节点，还是通过随机平均分配服务处理节点？
有没有更好的策略，比如根据IP+地址属性分配服务器处理节点，而此区域服务处理节点的服务处理能力具体与对应区域用户服务量息息相关。如繁忙的大城市与偏远的小城市，他们的用户量是有巨大差异的，对服务节点的处理能力要求也不一样。
3、请求调度及响应改装
如果没有无限的资源供应，在讲究经济、效益的企业生存原则下，在大并发性能场景下，性能处理能力是很难保证的。
这时，我们可以通过请求调度及响应的改装来进行性能的改造。如上面的抽奖活动，还有现实的商品秒杀，我们都知道是有几率性的，有可能多抽几次奖，多秒杀几次，才能成功。所以，这中间，就给了我们改造性能（体验）的余地。
比如，我们知道每个服务处理节点的最大性能处理能力，当服务超过了最大处理能力，该怎么办？
可以添加一层“请求接收处理服务”实现。如该处理服务根据策略，判断超过了对应节点的处理能力，那么立马丢掉请求，并返回“手气不佳请继续”，“请不要灰心继续秒杀试试”等结果。而当用户某次请求成功杀出重围，进入到服务处理节点后，返回处理结果，比如秒杀到商品。
这样一来，给用户的感受是：响应非常快，根本没有性能问题。至于中间的过程，最多认为是几率问题，比长时间的等待体验好得多。
当然，这对于有抽奖、红包、秒杀等高并发场景有效，对于必须每次精确处理的业务则爱莫能助。
4、前端页面响应策略
当后台的性能处理不过来，实际前端是能捕捉到关键特征错误信息的。如服务HTTP请求接口返回500类似错误。此时，我们可以对捕获到的错误，进行改造。如抽奖，可以直接判为“没抽到奖，手气不佳请继续”；如红包雨，可以直接点开不做反应，知道正确响应后，给出抽奖的结果；如需要精确执行的业务，可给予“因为xxx原因，请稍后再试”。
这样与直接抛出服务异常，从用户体验上有多少差异？
5、备用服务器和极速部署
我们都知道，对于电商购物节，抢火车票，都有很强的时间特性，一年中也就几次会有“非常高”（相对其他时间而言）的性能处理要求，如抢火车票的春运和国庆节。
此时，有两种思路应对：一是备用服务器，具体来讲就是把其它相对次要服务的服务器挪来全力应对该高并发性能业务，这里可以用到服务的极速部署（可以采用docker + saltstack实现）；二是基于目前云服务器按时收费，带有快照和快速新开服务器的功能，可快速完成对服务处理节点的横向快速扩展。