成都核酸检测系统崩溃，成了这两天的热点。
关键时刻紧急上线，东软称与我无关；官方称对短时超大并发量预估不足，导致系统出现卡顿问题。四川通管局称没有出现网络拥塞和故障。
这件事谁是谁非，局外人说不清楚。就我以往经验来说，如何在高并发场景下，达到高性能，做到高可用，擅长行业应用的传统软件开发商是惰于思考的。一方面可能甲方投入太少，另一方面也不具有互联网应对经验，系统往往停留在单体架构，不支持弹性扩容，没法扩展。
政务信息化项目现在都在上云。但重在建设云资源，资源供给粗放。政务应用系统与云资源缺少协同，系统上云架构未上云，分层设计，资源和应用相互独立，未能充分利用云资源弹性和分布式优势。
一碰到流量上来，就要求甲方扩容，增加网络带宽，增加计算性能、存储性能；出了问题，就是网络故障，服务器性能不够，把问题抛给基础设施服务商，反正他们离用户远嘛。
高并发代表着大流量，一个高并发系统应该靠架构设计，抵抗巨大流量的冲击，带给用户良好的使用体验。
面对高并发，扩容，是最简单粗暴懒惰的方式。
除了扩容，在应对高并发大流量时，一般还有三种方法。
一是分布。分而治之是一种常见的高并发系统设计方法，采用分布式部署的方式对流量分流，让每个服务器都承担一部分并发和流量。
二是异步。在某些场景下，一个用户请求未处理完成之前，可以先反馈请求，在数据准备好处理好之后再通知用户结果，这样可以在单位时间内处理更多的请求。
三是缓存。把一些时效性不强的数据临时存储在用户端或者服务器前端，避免与数据库或服务接口过多交互。使用缓存来提高系统的性能，就好比修个水库抵抗洪水的冲击。
只是，这些方法都需要软件开发商对系统进行改造，甚至是动大手术，远不如一句“扩容”来得简单。
传统软件开发商做行业客户，讲故事的多，面对互联网的极限挑战不多，系统设计很少考虑高并发的场景。因为不同量级的系统有不同的痛点。
淘宝、微信、抖音的系统虽然能够解决同时百万、千万人同时在线的需求，但其内部的复杂程度也远非我们能够想象。盲目追求高并发下的高可用，只能让我们的架构复杂不堪，最终难以维护。这是靠财政资金无力支撑的。
但从单体架构往分布式演进来说，淘宝也是在经历了多年的发展后，发现系统整体的扩展能力出现问题时，开始启动服务化改造项目的。
淘宝当时在业务从 0 到 1 的阶段，通过购买的方式快速搭建了系统。而后，随着流量的增长，阿里做了一系列的技术改造来提升高并发处理能力，比如数据库存储引擎从 MyISAM 迁移到 InnoDB，数据库做分库分表，增加缓存，启动中间件研发等。
当这些都无法满足时，就需要对整体架构做大规模重构。比如说著名的“五彩石”项目，“先花它2000亿”，让淘宝的架构从单体演进为服务化架构。
正是通过逐步的技术演进，淘宝才进化出如今承担过亿 QPS （每秒处理事务数）的技术架构。归根结底一句话：高并发系统的演进应该是循序渐进，以解决系统中存在的问题为目的和驱动力的。
如果都按照百万、千万并发来设计系统，电商一律向淘宝、京东看齐，即时通讯全都学习微信和 QQ，那么这些系统的命运一定不长久。
罗马不是一天建成的，系统的设计也是如此。我们熟知的 12306 网站，也是一步步实现大型高并发系统架构。
一个成熟的系统，在业务流量平稳时就要考虑随时可能出现的高并发需求场景，并在流量和并发不断提升的情况下，一步步地优化它，具备应对能力。一夜之间上线就去应对高并发的需求场景，崩溃是必然的。
源不深而望流之远，根不固而求木之长，不可矣。
