从成都核酸检测系统崩溃说说对高并发系统的理解

成都核酸检测系统崩溃,成了这两天的热点。

关键时刻紧急上线,东软称与我无关;官方称对短时超大并发量预估不足,导致系统出现卡顿问题。四川通管局称没有出现网络拥塞和故障。

这件事谁是谁非,局外人说不清楚。就我以往经验来说,如何在高并发场景下,达到高性能,做到高可用,擅长行业应用的传统软件开发商是惰于思考的。一方面可能甲方投入太少,另一方面也不具有互联网应对经验,系统往往停留在单体架构,不支持弹性扩容,没法扩展。

政务信息化项目现在都在上云。但重在建设云资源,资源供给粗放。政务应用系统与云资源缺少协同,系统上云架构未上云,分层设计,资源和应用相互独立,未能充分利用云资源弹性和分布式优势。

一碰到流量上来,就要求甲方扩容,增加网络带宽,增加计算性能、存储性能;出了问题,就是网络故障,服务器性能不够,把问题抛给基础设施服务商,反正他们离用户远嘛。

高并发代表着大流量,一个高并发系统应该靠架构设计,抵抗巨大流量的冲击,带给用户良好的使用体验。

面对高并发,扩容,是最简单粗暴懒惰的方式。

除了扩容,在应对高并发大流量时,一般还有三种方法。

一是分布。分而治之是一种常见的高并发系统设计方法,采用分布式部署的方式对流量分流,让每个服务器都承担一部分并发和流量。

二是异步。在某些场景下,一个用户请求未处理完成之前,可以先反馈请求,在数据准备好处理好之后再通知用户结果,这样可以在单位时间内处理更多的请求。

三是缓存。把一些时效性不强的数据临时存储在用户端或者服务器前端,避免与数据库或服务接口过多交互。使用缓存来提高系统的性能,就好比修个水库抵抗洪水的冲击。

只是,这些方法都需要软件开发商对系统进行改造,甚至是动大手术,远不如一句“扩容”来得简单。

传统软件开发商做行业客户,讲故事的多,面对互联网的极限挑战不多,系统设计很少考虑高并发的场景。因为不同量级的系统有不同的痛点。

淘宝、微信、抖音的系统虽然能够解决同时百万、千万人同时在线的需求,但其内部的复杂程度也远非我们能够想象。盲目追求高并发下的高可用,只能让我们的架构复杂不堪,最终难以维护。这是靠财政资金无力支撑的。

但从单体架构往分布式演进来说,淘宝也是在经历了多年的发展后,发现系统整体的扩展能力出现问题时,开始启动服务化改造项目的。

淘宝当时在业务从 0 到 1 的阶段,通过购买的方式快速搭建了系统。而后,随着流量的增长,阿里做了一系列的技术改造来提升高并发处理能力,比如数据库存储引擎从 MyISAM 迁移到 InnoDB,数据库做分库分表,增加缓存,启动中间件研发等。

当这些都无法满足时,就需要对整体架构做大规模重构。比如说著名的“五彩石”项目,“先花它2000亿”,让淘宝的架构从单体演进为服务化架构。

正是通过逐步的技术演进,淘宝才进化出如今承担过亿 QPS (每秒处理事务数)的技术架构。归根结底一句话:高并发系统的演进应该是循序渐进,以解决系统中存在的问题为目的和驱动力的。

如果都按照百万、千万并发来设计系统,电商一律向淘宝、京东看齐,即时通讯全都学习微信和 QQ,那么这些系统的命运一定不长久。

罗马不是一天建成的,系统的设计也是如此。我们熟知的 12306 网站,也是一步步实现大型高并发系统架构。

一个成熟的系统,在业务流量平稳时就要考虑随时可能出现的高并发需求场景,并在流量和并发不断提升的情况下,一步步地优化它,具备应对能力。一夜之间上线就去应对高并发的需求场景,崩溃是必然的。

源不深而望流之远,根不固而求木之长,不可矣。