库米云-智慧零售大数据专家
智慧零售解决方案
坚信技术的力量,
以技术驱动高科技商业的扩张。
小程序,并不小 ——从口罩预约小程序谈互联网IT搭建选型
作者:CEO
2020-03-30 10:59

春节过后的十几天,全国各地都在为小小的一方口罩所焦心,济南市借鉴外地先进经验,确定以某药房分布在全市各社区的零售门店为依托,以微信小程序为载体,开发网上预约销售软件系统,在网上开展预约,市民可以通过选择提货门店,就近取货,微信通知提货,防止到店人员集中。 


政府出发点是好的,选择微信小程序作为载体也很方便,即开即用。但实际效果看呢,从2月6日上午10时到2月8日,微信小程序基本是瘫痪状态,一边是大量的市民无法预约到口罩,另一边准备好的口罩无法发放到市民手中,造成了资源的浪费,疫情面前,我帮不上太多的忙,就结合着我的专业给一点建议吧。实际上小程序看起来很简单,但实际上围绕着IT系统建设可以一门大学问,可以说小程序并不小。




官方说1小时有300万访问,济南市2019年人口875万(含莱芜),就算小程序刚发布的时候访问的市民较多,考虑到有70岁以上以及15岁以下的应该不会自主预约,所以此处显然不是指UV(UV:独立访问用户数:即UniqueVisitor,一个时段访问小程序计为一个访客),那此处应该是指PV(PV:页面访问量,即PageView,用户每次对小程序不同页面的访问均被记录,用户对同一页面的多次访问,访问量累计)


考虑这个小程序业务并不复杂,按照每人正常访问点击10次来算,再加上系统崩溃无法登录可能会不断尝试,我们假定为20次尝试,那么实际上的UV应该为300万/30=10万,也就是说1小时有10万人访问,目前每天提供12万只口罩,也就是说正常预约的话,1人可以预约3只,20分钟也就预约完了。


我们再假设口罩一天能够供应120万,按照目前政府协调资源的能力,有可能达到,此时我们按照峰值1小时300万PV的性能指标建设系统,假定1UV=10PV,也就是1小时30万人,按照每人预约3只,2个小时也肯定预约完了。


那么我们就按照峰值1小时300万PV的性能指标来建设系统,来看一下需要关注的几个点,另外考虑这篇文章希望让更多的非专业人士看明白,所以我尽量不写太多的专业术语。



●  系统选型


1)云服务器

评论里有很多人谈到为什么不提供更强大的服务器,这里我解释一下,实际上IT系统建设和很多因素都有关系的:硬件、软件、网络,我们不否认服务器作为硬件部分在系统建设里起到很关键的作用,但很遗憾的说,在这种突发情况下,瓶颈往往不在硬件上,很多时候可能问题出在软件上,因为在“云服务器“大量普及的今天,升级硬件非常简单,往往几分钟就可以完成,技术人员肯定第一时间已经尝试升级过硬件。


这里也给大家科普一下,对于这种民生的预约业务是完全可以放到”云服务器“而不是企业自主的服务器,区别就是”云服务器“可以在第一时间进行弹性升级,甚至不需要停机维护系统,自动生效,而企业自己的服务器受制于硬件,还需要另行采购再去维护系统。

 2)网络 


我们考虑一下按照峰值300PV/小时,需要多大的带宽,我看了一下小程序,预约需要填写的信息不多,假设我们需要提交手机号以及门店信息以及预约数量等等,那么每个人的一次预约产生的提交数据量大约也就不到50个字节(字节英文为Byte,我们简写为B,按照1个汉字两个字节来简单计算一下,这里大致估计就可以,也包括了HTTP协议的大致字节数)


也就是说1小时10万人访问的话,需要10万*50B=500万B=5000KB=5MB, 而我们常说的带宽单位是Mbps,这是啥意思呢, b是bit(比特)的缩写,Mbps是Mb per second的缩写,也就是1秒多少Mb,而1B=8b, 我们假设这个预约平台使用10Mbps的话,10Mb / 8 * 3600 =  4500MB = 4.5GB,也就是1小时有4.5GB的流量, 比10万人需要5MB大900倍,显然带宽也不是这个预约平台的瓶颈。



●  软件


既然系统选型没什么大问题的话,感觉问题很简单啊,程序也不复杂,不就是个预约吗?问题就出在这里,我们再来看一下峰值, 300万PV/小时==833PV/秒, 这个量对我们一般的服务器来讲,提供正常的服务,还是有点吃力的

就算一台服务器能够正常处理所有的服务,风险也是比较大的,如果一台服务器坏了怎么办,我们一定不能存在侥幸心理,就像飞机的双发动机配置一样,我们也应该使用多台服务器提供服务。

这里我有一点担心,有可能该预约平台只是使用了单台服务器,而且系统上线之前没有进行压力测试,因此在系统首日上线被挤爆的情况下,没有任何手段恢复。

我再举一个例子,银行有很多的顾客都在挤着办业务,也没有排队,如果只有一个窗口,肯定忙不过来,而且由于大家都在挤,结果是谁都办不了业务,耗费了更多的时间。这种情况下,银行可以增加窗口,同样我们再提供更多的服务器,但这样就能解决问题吗?

如果只是增加了服务器,每个服务器上放一套预约系统,也是有问题的,因为我们的口罩是统一管理的,就像顾客办理业务的话,选择哪一个窗口都是可以的,因此我们的软件设计就需要有一个统一管理口罩的业务,再加上类似银行排队叫号的方式。


但这样一来系统开发实际上就更加的复杂了。一般来讲分布式系统的开发复杂度有可能会N倍于单服务器的应用(N>=4), 考虑到该预约小程序首页《关于口罩预约购买的说明》中提到系统建设时间较短,从这一点也是我判断该平台只使用了单台服务器的原因,这也客观造成了由于单台服务器服务的客户预约数量有限造成的瓶颈。


●  分布式系统


前面提到了分布式系统开发复杂度非常高,现在互联网IT业务在面对大量访问(这种互联网IT系统也是我们专业人士常说的”高可用和高并发“系统)时,也衍生出很多种形态,现在业界流行的微服务、中台实际上也都基于此,并在各自的体系上形成了方法论。而我们前面说了类似银行排队叫号的方式,实际上也不过是整个分布式系统的一个模块罢了。


这样的系统往往不是一朝一夕建立起来的,需要不断的测试、修改、打磨,才能投产使用,就像我们自主研发的分布式系统,也是历经两年,还在不断完善和修改,但是在这样的分布式系统(中台)上再去建立类似预约口罩这样的业务系统,就会非常轻松,我初步估计了一下,基于我们分布式系统搭建出符合300PV/小时性能指标的预约系统,从开发到压测上线再到小程序审核通过也只需要1周。


再次我也呼吁相关部门领导一定重视IT分布式系统的底层建设,而不是临时抱佛脚。



●  限流


另外在分布式系统下,在面对访问量激增时,比如说超过我们系统设计的300PV/小时的峰值,可以设定限流,也就是说后续访问的用户会看到正在排队或者稍后再试的页面,这样既可以保证已经在队列里的用户能够正常预约,也可以让后面的用户有明确的系统提示, 而不是所有的用户都是白屏或者卡在某一个功能点动弹不得。



●  压测


上线前压测, 根据之前提供几个压测数据,上线前必须进行压测,有条件的话,就要分别模拟1小时100万pv和300万pv,另外至少还要做8个小时的稳定性测试,否则平台系统因为不够稳定在工作时段崩溃的话,基本上就很难恢复了。 就算服务器重启,潮水般的预约访问马上会造成服务器的再次拥堵,无响应。


这里我猜测由于时间短,可能没有做压测,或者相关人员没有这方面的意识;好多企业有研发企业内部业务系统的经验,但这类系统的特点是在线人数不多,往往是企业或者集团内部使用,不需要7*24小时服务,运维人员可能会经常重启服务器维护系统,这在面对互联网IT业务的瞬时大量访问是绝对不可行的,因此需要有更多支持高并发高可用能力、有分布式系统建设能力的公司参与进来。


我们IT的管理者也应该树立”红线“意识,不上线没有压测的系统,谨慎评估系统实施可能存在的风险



以上是我结合我的专业给出的几点建议,政府也应该万分慎重,线上预约购买口罩本意是好的,但是因为系统的各种不稳定引起激发公众负面情绪,得不偿失,也真心希望我们的同胞能够在这场战疫中取胜,我们政府公共事业的IT建设也能够更上一层楼。

一位大学计算机教师兼某IT公司CEO的一点浅见,以期抛砖引玉


<返回
上一条:小程序数据分析 2020-03-30
下一条:流量变现时代,自媒体如何过得更好2020-03-30
库米云-智慧零售大数据专家