我正在参与掘金创作者训练营第6期，点击了解活动详情
序
昨天下午 看到东软的 之前朋友 群发朋友圈，把我朋友圈刷屏了。。。。这是发生了什么，看这个截图 是东软 解释 健康码 核酸系统的问题 和自己无关。。。哎
去看看怎么回事，可是我不在成都啊，问问朋友 发生了什么，走起
声明
纯从 百度的来的消息，一切都是猜想 具体事情请看官方通知，本文章主要说 健康码技术的猜想, 不涉及其他的
目前了解到的
消息来源不一定正确
百度信息
9月2日晚间，成都“天府健康通”的核酸系统出现“卡死”情况，导致信息登记、核酸检测采集等无法正常进行。现场的医护人员尝试各种办法，试图解决“网络信号”或“核酸检测系统”的问题。
据悉，成都市的“全场景疫情病原体检测信息系统”由东软集团股份有限公司开发上线。
9月3日，东软集团及时发布官方声明称，成都疫情以来，为应对成都大规模检测并发的系统稳定性问题，东软核酸检测系统紧急上线并于9月2日凌晨4时投入使用。系统上线后，发现有响应延迟、卡顿等现象。据技术专家研判，上述现象与核酸检测系统软件无关。东软集团称，具体网络故障的原因，相关部门正在排查。
核酸检测系统异常处置应对情况
核酸检测系统异常处置应对情况——专访成都市疫情防控指挥部相关负责人
9月1日，成都市新型冠状病毒肺炎疫情防控指挥部发布《关于在全市开展全员核酸检测的通告》，决定自2022年9月1日至9月4日在全市范围内开展全员核酸检测。9月2日晚，核酸检测系统出现异常，导致采样排队时间过长，核酸检测进度缓慢，给市民群众带来困扰和不便。今日，记者就市民关心的问题，采访了成都市新型冠状病毒肺炎疫情防控指挥部相关负责同志。
1、昨晚全员核酸检测期间，核酸检测系统为什么出现异常情况？采取了哪些处置措施？
答：昨天下午至晚上，全市核酸检测系统出现异常情况，导致检测进度缓慢。雨夜风凉，群众长时间排队，一线检测人员辛苦坚守 ，我们感同身受、焦急万分、深感愧疚，诚恳接受社会批评，向全市人民表示最真诚的歉意，也感谢市民群众的充分理解和大力支持。
9月2日17时30分左右，成都市核酸检测系统因对短时超大并发量预估不足，导致系统出现卡顿问题。故障发生后，我们立即组织专业技术团队与承建商一起排查原因，积极抢修，系统在增加多台服务器、优化关键参数设置后逐步恢复，但还存在不确定性，我们正在努力加以解决。下一步，我市将采取错峰核酸检测采样、强化系统运行监控、加强问题响应等措施，努力保障核酸检测平稳顺利进行。
东软声明
和我们无关 ，是网络的事
总结下
因为 对短时高并发预估不足，没做好系统稳定性，没有应对临时高并发的承载能力导致的问题？
没有nginx 弹性扩容？
扩容 提高承载能力 解决的问题？
一切是猜想，毕竟我们不是 现场的人，没有调查就没有发言权
整理下
其实 上面看下来 主要是2点
- 网络的事
- 应对短时高并发的能力
思考的时候 大概花了个图
网络的事
干开发的都知道 有的时候系统临时上线，可能系统环境 都需要从头搭建，中间件也要搭建，网络不通 都是会发生的。
这个很正常，临时情况嘛
应对短时高并发的能力
弹性扩缩容
- 流量削峰
- 限流 通过减少请求频率来减轻服务器压力
- 容错
- 降级 把不重要的服务暂时关闭，节省服务器资源，从而保证核心服务的正常运行
- 异步：客户抢购成功后立即返回响应，之后通过消息队列，异步处理后续步骤，如发短信、更新数据库等，从而缓解服务器峰值压力。
- 弹性扩缩容
1 - 4 其实公司都应该有现成的解决方案，第6点 结合运维也ok。 对于码代码的可能 第五点 可能因为 我们是高并发的读，不是说链路太长，可以通过消息队列 减少响应时间，提高吞吐量。
异步 可以是 非阻塞异步的框架，
这里就不细说 响应式编程，只是给出一个大概的概念 和 性能比较 让大家有一个简单的了解
响应式编程之 Project Reactor
传统服务端程序一般采用同步阻塞模型，通过分配更多线程来支撑更多请求，这符合常人思维模式，但在突发流量的情况下，同步模型可能会导致线程池耗尽，基于一个请求一个线程的服务模式无法做到动态伸缩。
而异步编程的做法是基于一个共享的线程池，所有操作都是回调。如果遇到耗时的操作，线程并不会阻塞等待操作完成，而是会被释放回线程池中继续接受新的请求。等到耗时操作完成后（一般都是IO操作），通过消息机制重新向线程池申请线程恢复之前的请求代码。
我们可以简单写个程序简单实验一下，实现相同逻辑：1. 查询 db 2. 查询外部系统 3. 组装信息返回。唯一区别是一个是同步调用的实现，另一个是采用完全异步的方式实现。
本地使用相同的 jmeter 参数模拟并发测试，得到结果如下，从左到右每列的含义分别为：请求名称、请求数目、失败请求数目、错误率(本次测试中出现错误的请求的数量/请求的总数)、平均响应时间、最短响应时间、最大响应时间、90%用户响应时间、95%用户响应时间、99%用户响应时间、吞吐量。
总体测试结果如下：
同步代码测试结果
异步代码测试结果
同步代码总共完成了 260 次请求，平均响应时间约 5 秒，因为阻塞程序耗尽了线程池导致程序出现了拒绝服务的情况，产生了 13% 的错误率。
异步代码整体吞吐量有明显提升，相同时间内完成了 3000 次请求。错误率为 0 ，并且整体没有出现拒绝服务的情况。
可以看到基于消息驱动机制的异步系统能极大提高资源利用率，提高系统的吞吐量。而响应式系统则在消息驱动的基础上增加了三个要求：及时响应性、回弹性和可扩展性。
简单来说具备以下四个特点的系统可以称为一个响应式系统：
- 即时响应性，这个是响应式系统的核心目标。一个具有响应性的系统就是一个无论在什么情况下都能快速对客户的操作做出反馈的系统，包括事件、用户请求、失败场景，最终目的是保证客户良好的体验。
- 回弹性，指的是系统从故障灾难中恢复的能力。主要分两部分，一个是系统需要考虑失败的情况，二是系统要能从失败中恢复回来。
- 扩展性（弹性），指的是系统在不断变化的工作负载之下依然保持即时响应性。可扩展分为单机纵向扩展和横向线性扩展。这里主要指的是系统可以通过分片、复制等方式进行横向扩展，从而避免系统产生明显的性能瓶颈。
- 消息驱动的，这是响应式系统的基础。从上面异步系统的优势和原理分析可以看到，基于消息驱动的程序能最大化利用机器资源，同时松散耦合的设计创建了一个能让业务逻辑保持清洁的环境，显式的隔离失败有利于系统自动恢复。
和 西安健康码 的思考
（西安 健康码当时的 主要问题
1.限流问题：市民在长时间无法刷出健康码的情况下，多次退出刷新重试，新的流量到达服务器，导致服务器压力变大、承受负载增加，说明“西安一码通”系统没有做好限流措施。\
2. 服务器问题：无论是企业和个人在租用服务器的时候都会受到峰值承受限制的，一旦超过服务器的承受能力，就会导致服务器瘫痪，应用程序暂停，网站无法访问。服务器是有峰值限制的，不可能承受无上限的并发能力。而造成服务器瘫痪的原因就是在同一段时间内，访问人数多，造成高流量的突进，超出了服务器的承受范围。
3. 架构问题：“西安一码通”功能影响“核酸检测”服务，说明模块间从界面到数据调用互相影响，可能不是微服务架构。
4. 性能过载：典型的性能过载场景，不论内部根因是数据库瓶颈点，还是网络链接数瓶颈点等等，外因都是因为过载导致。
共性的问题
都是 短时高并发导致的
页面优化：友好提醒用户耐心等待 ; 当出现不能显示查询结果的时候，为避免社会恐慌和公众猜测，应当在页面做出友好提示为宜，而不是“繁忙、无响应”等。
访问节流：
- 短时间内多次请求可做防抖机制；
- 核酸结果是24小时(或更长或更短)内不变，建议做缓存机制，24小时候间隔后再次访问强制刷新，接口可带时间戳参数；
- 非关键渲染数据延迟请求，即发起一个聚合接口请求来获取主体模块的数据，而非主体模块的数据则从另一个接口获取，通过拆分的手段来降低主接口的调用时延；静态页面使用 CDN
- 接口聚合，请求合并，减少并发；
- 减少接口通讯数据，传输的数据量越多，线程间通信的耗时越长，渲染速度就越慢；
- 剥离并建立异步无关联性并发请求；
压测要做好
总结
开发可能会遇到各种问题，其实时间和质量 真的没办法兼得 当然了具体事情我也不清楚，只是猜想
思考题
如果让你做一个省的健康码，你会怎么做，可以结合画图 看看你的落地能力，每个点需要什么资源？能支持多少并发？如果你想测试并发，你可以把代码写出来，我给你提供服务器，给你出性能测试报告。
都是一个 互相学习 一起成长的过程，慢慢完善，欢迎加入。wx yuyezhiji
