【文/科工力量专栏作者 余鹏鲲】
西安的疫情牵动着全国人民的心，人们在表达关心关切的同时，也对西安应急抗疫工作提出了批评和责备。西安“一码通”是被集火的对象，作为抗击疫情最重要的数字资产和信息基础设施，西安“一码通”几度瘫痪，为本就心情郁闷的群众添了堵。由于类似的情况并不多见，人们不禁要问西安“一码通”（以下简称“一码通”）有什么技术上克服不了的问题？为什么不能够在疫情面前持续提供服务？
“一码通”再度宕机后，西安市委组织部1月5日公布：因履职不力，西安市大数据资源管理局党组书记、局长刘军停职检查。刘军此前分管的工作正是“一码通”工作专班，这一事件标志着行政问责的开始，同时也充满了尴尬。
此前“一码通”崩溃后，工信部已经派员指导“一码通”工作，也将这一工作的重要性提升到“政治站位”的高度。然而几天之后，“一码通”又崩了。
尽管有西安市民表示，这次崩溃恢复得很快，只用了近5小时就通了，比第一次好多了。但这一事件本身，仍然暴露出西安数字政务体系的严重问题，5小时才修复已经是严重落后于时代了。
此外，“一码通”工作是由西安大数据管理局负责监管的，但是“一码通”不是大数据业务。如果说“一码通”崩溃时第一次的访问量是一笔糊涂账，那么第二次就很清晰了。
1月4日，西安封城管控，“一码通”只用来做核酸和查核酸检测结果。由于崩溃时，核酸检测只是初步开始，因此查核酸检测结果的人并不多。同时，核酸检测是分批进行的，并且在同一批中还是排队进行。这么一算，当时同时访问“一码通”的人数，高峰期充其量也就是5分钟50万人。
“一码通”又没有什么复杂的交互，以查询为主。5分钟内50万人对不超过4000万人（2021年西安常住人口1295万，这里是从高估计的结果）的数据进行访问，这怎么能算是大数据业务呢？
因此，尽管是大数据资源管理局局长被问责，但是“一码通”就是一个常规业务。这一事件也说明，地方政府对信息产业的监管，目前还是合规性监管和价值观监管，在技术性监管方面乏善可陈。
那么我们就从技术角度出发看一看，常规业务“一码通”需要哪些保障，又是怎么崩溃的。
“一码通”的问题出在软件上
作为常规业务的“一码通”，存在很多先天优势，本该坚如磐石。全国类似平台这样崩溃的几乎没有，也证明了这一点。
首先是访问局限在城域网内，“一码通”是西安用户访问西安服务器，跨城市访问的流量可以忽略不计。这样的业务可以很容易地采取一些激进的优化措施，并且不会造成稳定性问题。
同时，“一码通”是权威平台。即使出现了崩溃，只要十分钟之内重整了，群众就会很自然的以为是自己信号有问题，或者网络卡了，根本不会产生舆情波动。
因此“一码通”的问题，实质是崩溃临界访问量太小，以及重整修复速度太慢叠加造成的。
大型电子商务网站系统架构，来源CSDN
上图是常见的商务网站系统架构，代表了目前主流网站的技术架构和先进生产力，“一码通”业务的架构虽未公布，但也应该大同小异。类似架构的网站，数据送入用户手中，要经过发送请求、数据查询、服务器响应、服务器分发、网络传输和接收等过程（如下图所示）。
主流网站查询业务流程
这些过程中，可能出现的硬件问题是服务器过载，以及网络阻塞。
由于响应“一码通”应用的请求、分发数据、负载均衡都需要消耗服务器资源，因此访问量的增大必然带来服务器过载，目前服务器资源几乎都是以云的形式提供，服务器资源可实时增加。
疫情封城时，陕西本地其他云资源访问量下降。如果陕西的云提供商下决心保通“一码通”，甚至跨区域协调资源，“一码通”所需的服务器资源是有保证的。
网络阻塞，又分为上行阻塞和下行阻塞。上行阻塞就是用户向服务器发送的信息过多，占满了上行带宽。下行阻塞就是服务器向用户发送的信息太多，占满了下行带宽。如果是合理的网络占用，主要看陕西云服务提供商以及网络业务开发者的对接工作。从全国来看，云资源比陕西少的省也是没有任何问题的。
资源没有问题，云服务商愿意配合，网络业务开发时，有自动化的应对方案，那么“一码通”就不会出现网络阻塞的问题。换句话说，“一码通”的问题主要是软件问题。
业务逻辑不合理是硬伤
按照查询业务流程，负载均衡、数据库、服务器业务和应用端业务都有可能造成这个问题。具体地来说，是个别服务器压力过大、数据库访问延迟增加、服务器业务处理时间过长、应用端发送内容过大等问题。这里面除了负载均衡，都可通过增加业务资源和合理改变业务逻辑的方式去解决。
负载均衡问题目前还未完全解决，继续深入也非常困难。但这里说的困难，是大型互联网企业要考虑的。“一码通”的访问量，哪怕是用免费开源的Nginx和Apache也不难解决。
“一码通”的业务逻辑恰恰不合理，“一码通”的核心是健康码，然而“一码通”还融合了政务二维码扫描、公民电子证件、健康码、公积金、城市新闻、政务地图、幼儿托管、停车数据查询、天气、空气质量等等业务，是一个复杂的系统。
根据相关媒体的报道，至少有六家企业参与了“一码通”开发运营。
从数据库的角度讲，怕的是锁（数据库软件中的一种机制，用于防止意外写入）太多。12306系统的访问量比淘宝“双十一”期间的访问量要小好几倍，依然无法自如地应对春运，根源就在于火车票务业务的锁太多。
将各种业务集合为“一码通”，本身并不意味着锁更多。但将业务融合在一起后，就会催生出数据库联合查询的需求，以及更多需要锁的需求。有从事软件开发行业的西安网友，结合使用“一码通”的经历，指出：“一码通”在崩溃之前，疑似默认联合查询核酸检测结果以及健康码状态。
由于健康码状态和核酸检测结果的查询密度存在数量级的差异，如果网友反映的问题是真的，这种安排的合理性属实值得商榷。