为了账号安全,请及时绑定邮箱和手机立即绑定

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

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

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

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

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

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

图片描述

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1 应对高并发的场景

从下面3个方面入手:

首先是资源扩容

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

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

其次是避免单点

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

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

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

最后才是系统优化

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

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

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

2 应对需求变更

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

需求计划管理

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

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

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

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

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

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

释放自己的压力和情绪

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

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

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

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

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

抱怨的时候,不一定就是消极怠工;

抱怨的时候,不一定就是无能无力;

抱怨的时候,不一定就是甩掉包袱;

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

3 应对资源限制

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

说服老板

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

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

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

量化指标

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

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

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

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

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

限时限量,弹性伸缩

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

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

总结

最后的总结,关注一凡老师,实战课程既有《基于GO语言,K8s+gRPC实战云原生微服务开发》,也有《高并发/高性能 Go语言开发企业级抽奖项目》,希望能助你顺利通过大考。更多更全面的知识技能可以来老师的个人网站-壹梵在线看看。

点击查看更多内容
4人点赞

若觉得本文不错,就分享一下吧!

评论

作者其他优质文章

正在加载中
全栈工程师
手记
粉丝
1.7万
获赞与收藏
2253

关注作者,订阅最新文章

阅读免费教程

感谢您的支持,我会继续努力的~
扫码打赏,你说多少就多少
赞赏金额会直接到老师账户
支付方式
打开微信扫一扫,即可进行扫码打赏哦
今天注册有机会得

100积分直接送

付费专栏免费学

大额优惠券免费领

立即参与 放弃机会
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消