西安一碼通「1M圖片優化到100KB」這種壓縮技術難度如何？

二更說明：

針對有些同學認為這個系統就沒有事務，沒有TPS，只有QPS的不正確觀點，華為出身的本老師，再在文章最后做點概念普及。

一更說明：

從評論看，各位朋友對壓測的相關概念疑問很多，在文章的最后，我更新一點壓測概念普及，準確的說應該是性能測試的概念普及。

性能測試包含容量、穩定性、負載和穩定性，大家平時通俗口語化所說的壓測，在軟件公司里一般是測容量和穩定性的。

一碼通這兩次崩潰，根本不是技術難度的事，我來跟大家諞點其他的

前言：

作為一個自愿被封在家里吃不到肉肉的西安人、一個曾在華為西研所做過云產品研發的偽技術人員，對于西安一碼通半月內丟人得奔潰了兩次的事情，站在希望自己城市能越來越好的角度，說幾句自己的觀點：

圖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才能掙點錢！

作者：啄木鳥學院的老板榮老師，寫于2022年1月6號，轉載請注明出處。

溫馨提醒：本論斷所引用的數據均來源于網絡，本人推論有因為被引用數據的不準確而不準確的風險，所以，本人無法對推論的準確性負責。

作為一個測試職業教育機構的校長兼其中一名老師，對這個帖子中的性能測試概念做一點普及，讓大家在看帖同時，能學到一點點東西

一更（2022.1.7）：

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”

二更（2022.1.7）：

Jmeter聚中的TPS = 事務數/運行時間；如果沒有定義事務，會把每個請求作為一個事務

QPS是Queries Per Second，是數據庫中的概念，每秒執行條數（查詢），被引申到壓測中來了，但不包括插入、更新、刪除操作，所以不建議用QPS來描述系統整體的性能

建議用TPS，這個T，你可以理解成一個接口，也可以理解成一個業務流程等

結論：

有完整前后端的項目，一定會完成接口前后臺的通信，一定會有TPS，世界上不存在沒有TPS的完整前后端項目