大型活动，是商家和消费者的狂欢节，却是程序员的大考

又是一年一度的618购物节，许许多多的商家又开始忙碌起来了。

不仅仅是电商平台面临大型活动的巨大考验，各大互联网公司也会在同时开展各自的大大小小的活动。而且，伴随着购物节而来的也有增加的广告投放。

所以，无论你所在的公司是否有自己的商城或者商品，无论你所开发和维护的系统是否和电商有关系，只要是直接面向用户的产品，都会或多或少的被卷入到这场购物狂欢节中来。

在这些平台、系统、产品的背后，有着无数的程序员为之忙碌不止，甚至通宵达旦。

那么，为什么这类大型活动，会成为程序员的大考呢？又要怎么顺利通过这场大考呢？

[文章指引]

1 活动期间，陡增的用户量和访问量

要搞好一个活动，如果和平时的用户量、访问量不相上下，那就不是活动，而是日常了。

一个好的活动，意味着可以带来平时的十倍、甚至百倍的用户量和访问量。

比如：集中的特价商品，各种折扣，优惠卷，抽奖，赠送和返利等等。

都可以在短时间内，刺激和带来很多的新老用户，也就会带来更大的访问量。

这就给程序员提出一个极大的挑战，系统的并发能力、系统的稳定性和伸缩性等等极致的考验。

就像最开始的一两次京东618和天猫双十一购物节，强如京东、阿里的程序员也没能幸免在活动中出现各种问题和故障。虽然他们都在活动之前经历过无数次的演习和压力测试，但是，在现实的场景中，总会有那么一两个盲点被击破，引发更大面积的问题。

虽然，到今天，京东618和天猫双十一购物节已经进行过很多次，已经非常有经验了，但同样，每一次都不会那么轻松，依然需要程序员24小时轮流值班，为各种可能、不可能出现的故障时刻准备着。

如果你没有经历过这样的活动，这样的系统，或者正准备要加入这样的活动，上线这样的系统，那么，这一次大考可能会有极大的压力。

程序员的压力之所以大，是因为所有人都认为不出问题是理所当然，出了问题就要兴师问罪了。

2 新的花样百出，需求千奇百怪

如果每次的活动都一模一样，用户都会觉得很无聊(低价除外)。

于是，哪怕是经历过多次考验的系统，在活动开始之前，甚至活动进行中，都会迎来很多新的需求。总之，就是要不一样。

新的需求，意味着要重新研发，不断变化的需求，意味着要不断地重新研发。

你是程序员，就问你怕不怕。

老板和产品经理们最多会象征性的问候一句：辛苦啦。而你却要吭哧吭哧不断地改不断地调。

如果你的工作平时都有条不紊的按计划执行，那么，在活动期间，恐怕计划的再周密也难免被突然打断和重排。

程序员的压力之所以大，是因为所有人都觉得按时交付是理所当然，出现延期就要秋后算账了。

3 预算有限，服务器和带宽捉襟见肘

平时只有几十万用户，几百万的访问量，现有的十几二十台台服务器运行还算稳定。

“活动期间怎么就要10倍的预算呀？是不是太过分了。”老板一定会给你的资源预算大砍一刀。甚至会觉得，如果技术好一些，现有的资源就足够了。

总之，就是不想为短期的活动增加大量的资源投入。

这时候怎么办？作为程序员的你，只能是对系统进行优化，甚至重构。

Java太费资源，并发能力不够高，用Golang重构一遍性能提升十倍以上，岂不是美滋滋。

以为找到银弹的程序员却又掉入了另一个陷阱，没日没夜的重构和测试，可能因为某个功能的缺失或者缺陷，反而祸从天降。

程序员的压力之所以大，是因为所有人都觉得改写代码而已，就是日常工作嘛，程序再优化优化，是不是可以减少一些服务器等资源呀。

面对上面的3座大山：并发压力、需求变更、资源限制，要怎么应对呢？

之所以说这类大型活动，是程序员的大考，下面就是交出答卷的时候了。

1 应对高并发的场景

从下面3个方面入手：

首先是资源扩容

对分布式系统进行资源扩容，2台服务器扩充到10台服务器。

这个过程并没有那么轻松，必须要解决系统瓶颈，不能因为某一两个关键点卡住而无法进行系统扩容。

其次是避免单点

不论是子系统还是数据库、缓存、队列，都不能出现单点问题，一定要有备份和冗余方案。

一套系统出现问题，一个地区的机房有问题，可以立即启动另外一套应急方案。

多一个预案就是多一条活路，不要跟自己的前途过不去。

最后才是系统优化

提升性能、提升并发能力、提高稳定性等等，这是一个长期且艰苦的过程。

而且随着产品的发展和变化，这个过程也会永远伴随左右，不可能一蹴而就。

这个优化的过程，一定要全程做好记录，每一个优化的细节都不能遗漏。优化之前的指标数值是怎样的，优化之后的指标数值是怎样的。只有这些量化的指标才可以证明你的成果。

2 应对需求变更

可以考虑从下面3个方面入手：

需求计划管理

心急吃不了热豆腐，越是忙越是累，越是要抓紧需求计划管理不能放松。

很多程序员会觉得需求计划管理是老板和产品经理的鞭子，却不成想过，它也可以成为程序员的挡箭牌。

你没有把新需求和变更需求详细记录和管理起来，那么你的功劳很可能会被人窃取，你的苦劳很可能无人问津。那么，你图啥啊，难道真的是为了提升技术吗？

需求细化之后再做时间评估

只要是存在模糊地带，就单独把一个未确认需求空留出来，只给明确了的需求做时间评估。

具体的评估时间，还需要把系统的方案选型、设计、技术验证、开发、测试、验证、上线等完整的过程全部计算进去。如果你都觉得这么评估太麻烦，那么最后，开心的一定是老板和产品经理，因为，他们一定会给你的评估时间砍一刀，比活动特价还要狠的那种。

释放自己的压力和情绪

最后的大招，压力大时，不要一个人扛着，不值得。

让老板和身边人都感受到你的压力，才有可能让更多人关注到你、关注到你的困难。

有人说，一个总是抱怨的人，不会是一个好员工。

说这句话的人，多半是老板或者是有病的员工。

如果在程序员的终极大考面前，都不会都不敢抱怨，难不成要等到最后的自爆、核爆吗？

抱怨的时候，不一定就是消极怠工；

抱怨的时候，不一定就是无能无力；

抱怨的时候，不一定就是甩掉包袱；

抱怨的时候，同样可以积极努力、寻求帮助、上下左右通力合作，目标清晰且一致。

3 应对资源限制

下面的一些方法应该会有帮助：

说服老板

时间就是金钱，能用钱解决问题就是最快最有效的方法。

不论是优化还是重构，改的代码越多，可能的bug就会越多，未验证的地方也会越多，风险也就越大。

风险就意味着巨大的损失，恐怕老板也不想承担这些风险。

量化指标

给出明确的资源预算，多少资源可以支撑多大的访问量。

如果活动的规模有限，那么申请少量的资源也可以。

这里，把活动的规模预估交给老板和产品经理，程序员只做自己分内的决定。

如果因为活动规模远超预估，超过了系统承载极限而引发事故，那就要决策者来担责了。

又回到风险问题，结局和上面类似。

限时限量，弹性伸缩

需要多少用多少，不需要因为预估不足而担心系统过载，也不需要因为预估太多而浪费。

这时候，使用K8S和云服务就具有天然的优势了。

总结

最后的总结，关注一凡sir，欢迎来我的个人网站。