一码通这两次崩溃，根本不是技术难度的事，我来跟大家谝点其他的。 前言： 作为一个自愿被封在家里吃不到肉肉的西安人、一个曾在华为西研所做过云产品研发的伪技术人员，对于西安一码通半月内丢人得奔溃了两次的事情，站在希望自己城市能越来越好的角度，说几句自己的观点： 图1：一码通注册用户4695.2万，每分钟扫码量120万，也就是2万TPS（次每秒） 图2：全员核酸一码通每秒访问量是平时的10倍 假定，以上“以往峰值10倍以上”的说辞正确，推算新的峰值访问量将达到20万TPS，按每秒处理1000个事务则必须打开1万个并发连接的经验来判断，一码通按照每秒200万的峰值请求来设计才会保险点。 图3图4：东软2020年3月用46万中标一码通项目的系统总体开发（主要为前后端架构设计、代码开发） 图5：2021年12月又以为539万中标一码通二期项目 图6：一码通带宽竟然扩容到了惊人的700G 以上说明： 2020年3月，东软竟然只用46万的白菜价中标了一个最大要承载200万并发的项目，2021年12月又只以539万中标这个项目的二期工程！ 一码通带宽700G，大概率这次崩溃事件跟带宽是没关系的，那么只可能是软件架构设计问题和硬件部署方案问题了。 百万量级并发的系统，先不说东软技术实力能不能做，用46万、539万的成本能做出来就见鬼了。 图7：有网友建议向12306优秀案例学习 呵呵，要知道设计并发1700万的12306花了上10个亿！ 咱西安一码通这种低端并发场景虽然完全跟12306不在一个量级上，但峰值百万并发的一整套完整软硬件解决方案也不是几百万能搞定的呀！ 既然咱全国著名贫困城市大西安缺钱，为啥还要单独弄一个一码通，和陕西公用一个健康码不好么？ 非要单独做，为啥不找华为、阿里、腾讯、百度做？非找个连软通都比不上的东软做项目总体，再分包给8个其他莫名其妙的公司？ 结论： 看来，好好写代码是挣不来钱的，不得不写点Bug才能挣点钱！ 作为一个测试职业教育机构的校长兼其中一名老师，对这个帖子中的性能测试概念做一点普及，让大家在看帖同时，能学到一点点东西，准确的说应该是性能测试的概念普及。性能测试包含容量、稳定性、负载和稳定性，大家平时通俗口语化所说的压测，在软件公司里一般是测容量和稳定性的。 QPS：Queries Per Second，是“每秒查询数”，是后台服务每秒能响应的查询次数。 TPS：Transactions Per Second，是后台服务每秒能处理的事务数。一个事务是指一个客户端向服务器发起一个交易，然后后台服务对这个交易做出响应。 再用通俗的语言对这两个概念进行下区分： 1、TPS即每秒处理事务数，包括了： 1）用户在客户端发起交易的请求到服务器 2）服务器上的后台服务进行内部处理 3）后台服务把处理结果返回给客户端 比如：这三个过程，每秒能够完成N个这三个过程，TPS就是N 2、QPS跟TPS完全两个概念： 1）用户在客户端的某个页面发起一次交易，形成一个TPS 2）这一次TPS，一定会在服务端产生多次查询的请求 比如：扫一码通后，发起一个TPS，后台接收到交易报文，开始查用户状态、查身份证号、查疫苗接种信息、查上次核酸结果，一个TPS的多个查询请求，都可以计入QPT之中 结论： 用户在客户端上的一个登录、注册、支付之类的交易，会形成一个TPS，但是这个TPS会在后台形成N次查询请求，所以，一次交易，产生一个“T”，N个“Q” Jmeter聚中的TPS = 事务数/运行时间；如果没有定义事务，会把每个请求作为一个事务。 QPS是Queries Per Second，是数据库中的概念，每秒执行条数（查询），被引申到压测中来了，但不包括插入、更新、删除操作，所以不建议用QPS来描述系统整体的性能 建议用TPS，这个T，你可以理解成一个接口，也可以理解成一个业务流程等 结论： 有完整前后端的项目，一定会完成接口前后台的通信，一定会有TPS，世界上不存在没有TPS的完整前后端项目。

分享本篇文章给更多人: