昨天早上，天津和深圳两个进行全员核酸检测的城市，健康码都崩了一次，服务在几小时后恢复，但是我想说，健康码在一天内进行全员核酸检测的大背景下，因为流量洪峰而发生崩溃的事，其实挺正常的。
因为流量洪峰带来的高并发压力，是小公司无法承受的。非IT人士，可能对流量洪峰的力量一无所知，我举几个例子说明一下就能感受了。
1、对于双十一来说，压力最大的是什么？是流量洪峰，以及随之而来的海量订单以及支付结算的任务。
对于流量洪峰，大家可以回忆一下春晚的盛况。微信红包在2015年初次在春晚亮相，结果流量洪峰直接打爆了微信的服务，0点到1点，红包根本发不出去；
然后在2018年春晚，阿里抢五福给全国人民发红包的时候， 准备了三倍于“双11”的服务器资源。
2019年春晚，百度发红包的时候，按照每秒峰值流量5000万，准备了10万台服务器，其中采购了5万台服务器，资源不足的部分，甚至让自己的现金牛业务——凤巢系统（广告）熄火，把服务器资源让出来给春晚红包。
然而，就在8点半前后，在春晚主持人口播大家可以下载百度APP领红包之后，连苹果的软件商店也被流量洪峰瞬间打爆了；其他安卓应用商店也纷纷跪倒在流量洪峰下，绝无例外。所以大家可以体验到流量洪峰的威力。
我们刚刚说的还仅仅是服务器端的资源消耗量；为了给大家提供服务，互联网公司还要采购大量的带宽资源，比如腾讯为了给10亿用户提供游戏、视频和公有云服务，在全球采购了超过100TB的带宽。
但一码通的实际情况比这复杂得多，解决流量洪峰的难度也会更大。就以粤康码自己发布的，在1月10日最高峰值流量达到140万/分钟来简化分析，问题可能出在接入网关上（我尽量说得浅显易懂，所以请专家轻喷）。
1、粤康码每分钟140万次访问请求经过微信小程序，第一步会抵达腾讯RIO智能网关，智能网关作为公网到政务网的第一道入口，就像医院的分诊台一样，实现流量控制、负载均衡等功能。
根据广州日报的报道，因为2021年5-6月的广州疫情，粤康码进行了系统调优升级，将「网关每分钟可承载的访问量从原来的10万+提升至60万+，每天的调用量从原来的10亿+提升至80亿+。」
打个简单的比方，我们在银行排队的时候，如果取钱的人多，哪怕银行金库里有足够的现金，也需要银行多开几个窗口，才能尽快给所有用户办完业务。
而粤康码的智能网关承载量是每分钟60万，突然涨到140万，怎么可能不卡呢？而且作为终端用户来说，如果健康码刷新失败，那一定会反复刷新，也会带来新的用户请求。
当网关的承载量超出设计值的时候，就像在高速公路收费站入口处排起了长龙一样，除非能够瞬间变出一排收费站，否则堵车就无法避免，就像下图的2019年广东高速收费站堵车一样。
腾讯RIO智能网关的硬件，包括逻辑服务器和存储服务器两部分，虽然支持横向扩展的，但是横向扩展智能网关硬件资源同样需要时间。
需要哪些时间呢？我们看看下面这张图就能明白了。
运维团队突然发现服务卡顿甚至崩溃，他们首先需要定位问题，到底是流量洪峰的问题，应用服务器宕机，还是后端数据库读写故障，这需要时间。
当问题定位出来，是因为移动设备访问量突然暴增，流量经过互联网区的防火墙到达接入网关后，接入网关被流量洪峰打爆，这才找到了问题的解决方案——急需扩容。
但是扩容并不是领导下个命令就能一分钟搞定的，运维人员需要先协调出可以使用的DMZ区服务器资源（很可能没有现成的，需要硬挤出来），然后在上面开通智能网关服务，所以安装部署需要时间，10分钟左右。
新的服务器需要开通防火墙策略，按照政务网的安全要求，防火墙策略需要由政府侧的安全团队负责，并且完成一个申请-审批-开通的流程，最后由某个网络管理员开通防火墙策略，这需要时间，15分钟左右。
现在的业务应用前端大多采用微服务架构，支持弹性伸缩，但是弹性伸缩同样需要时间，比如1分钟左右；
现在的业务应用后端仍然有一个支持高并发的关系型数据库，比如腾讯的TDSQL，数据库可能需要做实例升级（扩容分片、实例分片），升级完成后还需要校验，确保数据一致。这大约需要10分钟左右。
在这个过程中，还会有各级领导打来电话询问情况，关心进度；操作人员忙里出错，敲错代码；关键时刻电脑卡顿重启；硬件资源协调不到位等各种问题——倒霉事绝对不会只发生一件的。
所以如果一码通因为流量洪峰导致宕机，需要扩容的话，能在两个小时里恢复服务的，背后都肯定有一支召之即来来之能战的靠谱运维团队，一个各级负责人能快速反应审批的政府机构，一批相对冗余的硬件和带宽资，还有性能稳定可快速横向扩展的软件系统，比如腾讯里约RIO智能网关和TDSQL分布式数据库这种。
为什么不多准备一点资源？
因为面对千万量级的用户，开发者必须在用户体验（可用性、响应速度、一致性）和服务成本（带宽、服务器、交换机、防火墙、运维人员）之间去做平衡。
根据CAP理论，这种面对互联网海量用户的分布式系统，是不可能同时满足一致性、可用性和容错性的；一码通这种使用政府预算建设，又要求容错性的，开发者只能在一致性和可用性中做平衡。
而一个城市突如其来的疫情，会导致城市管理者快速做出「全员核酸检测」、「全员亮码」、「全员展示核酸检测结果」这样的决策，这样的决策必然会带来流量洪峰，而且是无法预测的——建设者和开发者没法为了无法预测的事情去无限制的申请预算。
开发者只能采用一些变通的方式。比如2020年阿里的双十一，订单峰值为6100万/秒，但是整体的购物感受却比较顺滑，原因就是技术人员用时间换取了空间。
比如2020双十一，所有预付定金的商品都要等到1点后才能付款，这就有效地降低了0点开始时的支付和结算的数据处理洪峰。
零点，工程师先把大部分计算资源分配给交易等应用，让大家愉快地清空购物车；过了1点后，再把这部分资源空出来，重新拉起交易和结算的微服务，供预付定金的用户下单结算，这样就有效分担了压力。
另外，通过双十一二十多天的预热，很多用户领了优惠券，预付了定金，收藏好了购物车，这就有了预测的一句，工程师可以有预见性地准备足量的前端计算资源、缓存资源、消息队列、数据库等资源，并做好一定的冗余。
在零点之前，工程师已经进行了数据库、缓存、消息、前端的预热，有效避免零点大量流量涌入时，前端、中台和后端之间还要浪费2ms握手建立连接，以免用户体验到卡顿。
可阿里能做得好的原因，是因为双十一是一场在固定时间固定地点开打的战役，整个团队在之前就做好了充足的演练。
阿里会在10月进行3次全链路压测验证；每次全链路压测，都会有跨多个事业群的技术人员参加，保底1000人。阿里的全链路压测技术已经成熟，压测可以在影子系统中进行全天候的测试，而不会影响核心系统。
可对于一个城市的一码通来说，是不具备这样的海量资源的。所以，随着春节带来的人流量，很可能在某些城市爆发疫情，然后政府仍然会进行全员核酸全员亮码，那时候也一定会有健康码被流量洪峰打爆。
友情建议各大中型城市赶紧升级一下一码通的软硬件配置，天津（直辖市）和西安（独立一码通）的硬件配置就是最好的参考指标，粤康码支持整个广东，其实参考性不大。
毕竟，如果能花一两千万避免一码通在关键时刻码不亮，其实也是蛮值得的。
春节快到了，祝各位读者大大都能过上一个安定、祥和、阖家欢乐的新年！