成都、贵州核酸检测系统“崩溃”背后的技术原因

9月3日“成都发布”消息称,9月2日晚,核酸检测系统出现异常,导致采样排队时间过长,核酸检测进度缓慢,给市民群众带来困扰和不便。

无独有偶,9月3日12时许,贵州省核酸检测系统出现异常,导致用户无法登录。当日16时起,贵州省核酸检测系统逐步恢复。云上贵州大数据公司发布信息表示歉意,并将以此为鉴,全力改进工作。

顶象业务安全专家认为,核酸检测系统崩溃的技术原因很多,网络带宽、云服务稳定性和资源扩展性、应用系设计、数据库性能以及运维能力都可能影响系统服务。“用户最能直观感受到的一个服务节点。当服务页面出问题后,最先想到的就是应用系统,其实像网络带宽、负载均衡、CDN、数据库性能、运维系统等基础设施和运维能力,都会影响到用户的直接体验。”

顶象业务安全专家建议,应用上线前,企业和单位需要做好应用的容量评估和规划、性能压测以及全链路压测,并制定好故障应急处理流程机制。同时,在运维服务上,尽量选择原厂背后的研发和架构团队做支持。

核酸检测系统的加载过程

成都、贵州等地核酸检测系统频陷崩溃,背后的技术原因会有多种可能。因为应用系统上线运行后,影响系统性能的环节会非常的多。从技术视角看,用户的一个url请求到后台服务,中间要经过多个环节,过程非常复杂。

1、请求发起。浏览器发起url请求、DNS解析、和服务端建立TCP链接、HTTPS协议认证、压缩数据并进行网络传输、接收到结构进行页面渲染

2、网络传输。网络节点路由、数据包封包/拆包、安全防火墙规则和限制、负载均衡/代理服务

3、系统服务。身份验证/权限控制、业务系统、其他依赖的各类应用服务

4、数据存储。缓存、数据库、消息队列、文件等。

可以看到,用户的请求要到达业务系统要经过多个环节,每一个环节都涉及性能上的问题,每一个环节又都有各自可优化的点。

例如,前端发起请求的优化,从浏览器发起url请求,涉及浏览器对域名请求并发数限制、js/css/图片等请求文件大小、请求内容的CDN加速、请求内容的浏览器缓存等。现在大多浏览器都自带开发者诊断工具,可以有针对性的去做性能定位,下图展示了用户的请求情况和单个请求的timing耗时。

核酸检测系统“崩溃”的技术原因分析

上面提到的四个流程环节都涉及性能优化,每个环节的快与慢都可能影响到用户的直接体验。核酸检测应用系统出现访问慢、崩溃等情况,可以在以下几方面查找原因。

1、网络带宽。可以类比请求数据传输的高速公路,碰到国庆/春节假期高速免费通行,就可能出现堵车的情况,影响出行速度。对应用系统来说,用户访问量激增,如果网络带宽不够,也会出现网络拥堵,影响页面的加载速度,表现出来的就是页面加载不出来或页面加载出错。

2、云服务平台/基础设施的稳定性和性能。现在云计算服务大范围普及,应用都运行在公有云或私有云上,会使用到云服务器、负载均衡、CDN、云存储、流量带宽等云服务。云服务平台作为基础设施的提供方,提升了应用开发部署和运维的效率和降低了运营成本。

3、一方面,云服务提供方要保障基础设施的稳定性,基础设施出现问题,会影响的业务系统的稳定性;另一方面,云服务使用方也要合理地采购云服务资源,避免资源不足影响业务系统的正常使用。

4、应用系统自身设计和性能。系统的设计的大框架,决定了应用系统的性能和稳定性。例如,技术上调侃的二维码扫描,如果请求响应传输的就是二维码图片,这种设计就必然限制了接口的性能(一般传输文本即可,文本的数据报文大小远远小于图片)。还有就是应用的部署结构,分布式集群部署的稳定性必然好于单点部署应用,应用系统上线前也要做好性能测试。

5、数据库的性能。数据库的性能会影响到应用系统的性能,应用系统的数据查询、写入会依赖下面的数据库,比如数据库出现慢查询就会导致页面查询变慢。数据库技术比较成熟,一般都会配合缓存使用,提升数据查询的性能。

6、运维系统和能力。运维在应用系统的生命周期中会占到70%以上的时间,高质量的运维系统和服务,能保障应用系统的性能和稳定性。例如故障前的容量管理、预警、巡检、演练、日志管理,故障中的处理机制、oncall、告警、定位和预案执行,故障后的复盘总结、改进措施的落地闭环。相信只有在日常运维上做好了充分的准备,在面对故障问题时才能做到及时快速地处理。

应用系统性能和稳定性能力要求

可以看到,应用系统只是用户最能直观感受到的一个服务节点。页面出问题后,最先想到的就是应用系统,其实像网络带宽、负载均衡、CDN、数据库性能、运维系统等基础设施和运维能力,都会影响到用户的直接体验。

以顶象风控系统(实时决策引擎)为例,看下顶象风控系统在设计和实施时,对系统性能和稳定性上的能力要求(PS:顶象风控系统在性能和稳定性上,支持TPS>5w的集群部署,平均rt<100ms,采用分布式集群部署,支持分钟级系统预警和在线水平扩展)。

设计原则

应用系统的架构设计,要采用分布式设计、集群化部署。

采用微服务架构,无状态设计。

功能内聚,模块化、组件化设计。

面对大流量高并发场景下,要具备一定容错性,有降级保护机制。

动态内容和静态内容分离,静态内容放到CDN,加速访问。

具备可扩展性、可运维性。

部署结构

支持DMZ区、业务区、数据库区、内网区的部署结构,满足网络隔离要求。

支持多机房容灾备份。

支持动态请求代理转发、静态内容CDN托管。

应用系统部署,无状态化,可随时增减节点。

可扩展性

支持配置化、脚本化对接消息队列(kafka、rabbitmq),无需开发,配置即生效。

支持配置化、脚本化对接其他系统api接口,便于在策略中使用。

支持配置化、脚本化对原始业务参数进行转换处理。

支持自定义策略和规则、自定义外部关联数据等各种衍生变量。

日志格式化,支持同步到业务系统或大数据平台。

支持sso对接和二次开发。

支持自定义角色、权限、背景图和LOGO的替换。

支持请求由业务系统路由转发。

可运维性

容器化部署和集群管理,支持快速在线水平扩缩容。

具备系统监控告警功能和机制,对服务器资源、网络状况、API调用、中间件等性能情况进行监控告警。

具备灰度发布功能和机制,分别从应用级、功能级进行灰度发布管理。支持策略灰度上线、上线前进行真实数据试跑和调优。

具备安全管理机制,可针对不同渠道、部门和人员进行权限控制,实现风控策略和运行数据的隔离,并且对策略的变更有版本记录和审核控制。

最后,关于运维,有几点需要特别强调:

1、尽可能采用原厂运维,在运维服务支持上,原厂人员更熟悉,处理技术问题有原厂背后的研发和架构团队支持。

2、上线前评估和压测,任何应用系统上线,都需要做好上线前容量评估和规划(预估请求量和并发量,准备相应机器资源,留足冗余量)、性能压测(稳定性压测和极限压测,为应对短时大并发量做好极限压测,了解系统的性能上限),以及全链路压测(评估整个业务链路上的性能短板)。

3、故障问题处理闭环,定制好故障应急处理机制,从问题预警、进展同步、定位处理,到事后复盘、措施的落地和验证,整个处理闭环做到位,避免问题重复出现。