简体中文   |   English

15201356601

西安一码通“崩溃”事件思考之一:强化压力测试才是关键

时间:2022-01-18

1月4日,西安一码通又“崩”了,半个月崩溃两次,引发了业界关注,关于事件原因也引起外界诸多猜测。西安一码通的系统建设涉及基础资源层、网络层、应用层等多个专业厂商。

该项目总包为西安电信,然后分包给近十家科技公司的服务,包括开发与运维、安全相关产品与服务、引擎软件产品、短信服务、大数据可视化等项目。在应用层服务中,阿里云提供政务云和短信服务;西安东软系统集成有限公司(以下简称“西安东软”)提供“一码通”软件开发和运营维护服务;安恒信息技术股份有限公司(下称“安恒信息”, 688023.SH)提供“一码通”部分安全项目服务;美林数据股份有限公司(以下简称“美林数据”,831546.NQ)提供引擎软件产品及相关服务;中译语通科技(陕西)有限公司(以下简称“中译语通”)提供大数据可视化服务。

我们在处理这类事务上陷入一种误区,就是把它当成福尔摩斯的探案现场,反复重放事件过程,以期望发现蛛丝马迹。为什么说它是一种误区呢,侦探刑事案件是不可以重复的,而一码通的拥塞故障是完全可以重复出来的。再现故障现场可以帮助我们查找故障原因,了解系统最大用户容量,测试限流效果,最终彻底解决拥塞问题。

所谓拥塞现象,通常是用户同时访问同一资源,而导致资源紧张,让系统无法正常响应请求。关键点在于“同时”和“同一资源”,要想达到这个要求,就需要协调所有访问者实现高度“步调一致”。做个简单的类比,拿破仑入侵西班牙时,一支法国小分队路过铁链悬桥,由于部队整齐的正步步伐导致大桥共振。从此以后,军队过桥都采用便步走。这就是“步调一致”的威力。

传统测试方法通常采用多台主机来模拟流量,这些主机有可能是真实的PC或者服务器,也可以是虚拟主机。这些主机被分配在不同的地方,比如各个IDC机房,或者办公网络。

由于这些主机通常分布在不同地方,采用不同的链路,运行在不同的平台上,集中控制平台需要与它们进行通讯和下发指令。

比如说某个任务是由步骤A、B、C、D组成。当集中管理平台向各个主机下发指令后,指令到达有先后,这些主机本身资源也参差不齐,对指令响应速度也不同,链路质量也不一样,走的路径长度也不一致,最后到达被测设备的时间就会先后不一致。

站在某一时刻来看,发往被测设备的访问,是多个主机发出的不同步骤,如下图所示,某一时刻的访问是“BABCAB”,而我们期望的是“AAAAAA”或者“BBBBBB”。

不同的步骤所访问系统的资源不同,使用的系统进程也不一样,这样就无法制造出拥塞现象所需要的“所有用户同时访问同一资源”的现象。

北京网测采用先进的硬件和软件架构,可以在一台设备里,模拟成千上万个主机,并且可以模拟IP、虚拟路由,实现亿级别的并发。如下图所示,网测以一台测试仪替代了若干个PC,可以直接与被测设备部署于同一个机房。

测试仪发展了Simuser的概念,可以模拟百万虚拟主机同时进行相同操作。如上图所示,测试仪模拟多个虚拟主机同时进行任务中步骤A。步骤A所消耗的是被测设备的同一资源,而可以成功制造资源紧张,也就是拥塞现象。

北京网测的测试方案不仅仅解决了一致性问题,还具有以下特点:

  • 测试简便:不需要协调各种网络资源和云资源,也不用担心链路带宽问题;
  • 分组件进行压测: 因为测试仪可以部署于不同位置,可以分别对LVS、GW、虚拟服务器、Nginx进行测试;
  • 分接口进行测试:对不同URL进行测试,寻找网络瓶颈;
  • 高效的延时统计:测试仪更方便统计延时,寻找延时大的节点,帮助问题定位。

咪咕经常承接国际体育赛事转播,采用的测试方案就是传统的多主机方式,但是一直困扰于拥塞现象。在今年欧洲杯转播中,开幕当天用户投诉率为20%。随后的奥运直播测试改为采用北京网测的测试方案,发现多个拥塞节点,进行了多次整改。其奥运直播网络运行稳定、流畅、清晰,观众体验良好,首日用户反响极佳,投诉率降到零。由此可见,西安一码通的问题也不在于是哪家服务商的责任,而是纯粹的测试技术问题。