辟謠！扒了一下西安一碼通的接口,這才是崩潰的真實(shí)原因！
上一篇：你見過(guò)最垃圾的代碼長(zhǎng)什么樣？（來(lái)長(zhǎng)長(zhǎng)見識(shí)）
最近西安一碼通二次崩潰這個(gè)事情，實(shí)在是太頂了。
第一次看到這個(gè)消息的時(shí)候，我是抱有懷疑態(tài)度的。畢竟大家都知道這種大的政府項(xiàng)目都是要招標(biāo)的，能中標(biāo)到項(xiàng)目的公司也肯定不會(huì)差，怎么會(huì)犯這么低級(jí)的錯(cuò)誤呢？
今天又在知乎上看到了知友 “盧興民” 的回答，別人是真的去分析了二維碼接口數(shù)據(jù)的，證明并不是在服務(wù)器生成圖片。
真正的二維碼數(shù)據(jù)是 /person/app/refreshQRCode這個(gè)接口
這位知友表示：
看下這個(gè)接口返回，設(shè)計(jì)上也沒有太大的問(wèn)題。?
主要問(wèn)題集中在所有的js/css/img這些靜態(tài)資源全都從從一個(gè)出口進(jìn)行提供，沒上CDN
粗略估算了一下，js/css/img數(shù)據(jù)總共約500kB
按照從某個(gè)群里得到的數(shù)據(jù)，暫且認(rèn)為是準(zhǔn)的，健康碼的請(qǐng)求量峰值達(dá)到了3.3w qps
搜索公眾號(hào)互聯(lián)網(wǎng)架構(gòu)師回復(fù)“2T”，送你一份驚喜禮包。
到寫這個(gè)回答時(shí)，西安健康碼還是沒有將靜態(tài)資源上CDN，之后看看訪問(wèn)量再起飛的時(shí)候，能不能扛得住吧。
想直接抓 HTTP 包
具體步驟
把它們拷到電腦上，用一個(gè)叫「wxappUnpacker」的東西解包，拿到微信小程序源代碼，搜索公眾號(hào)互聯(lián)網(wǎng)架構(gòu)師回復(fù)“2T”，送你一份驚喜禮包。
從源碼的 pages\index\index.wxml 中找到了個(gè)人電子碼，及其綁定的點(diǎn)擊事件「onElectronCode」，進(jìn)而跟蹤到「onYmtLogin」->「toYmtLink」-> 「toElectronCode」
找到了一碼通的地址，原來(lái)是小程序打開外部網(wǎng)頁(yè)
其中
N = getApp(),
function?qrcodeColour(e,?t,?a,?o)?{????var?s?=?baseUrl?+?"/view/login.html?code="?+?t??????,?i?=?300??????,?r?=?300??????,?n?=?i??????,?d?=?r??????,?p?=?80??????,?l?=?80??????,?c?=?(i?-?p)?/?2??????,?u?=?(r?-?l)?/?2??????,?m?=?$(e).qrcode({????????render:?"canvas",????????text:?s,????????width:?i,????????height:?r,????????background:?"transparent",????????foreground:?a????})??????,?g?=?m.find("canvas").get(0)??????,?C?=?new?Image;????C.src?=?g.toDataURL("image/png"),????C.onload?=?function()?{????????g.width?=?n,????????g.height?=?d;????????var?e?=?g.getContext("2d");????????e.fillStyle?=?"#ffffff",????????e.fillRect(0,?0,?g.width,?g.height),????????e.drawImage(C,?0,?0);????????var?t?=?new?Image(p,l);????????t.src?=?o,????????t.onload?=?function()?{????????????e.drawImage(t,?c,?u,?p,?l)????????}????}}
最終結(jié)果：沒有服務(wù)端生成二維碼圖片！
相關(guān)鏈接
?https://www.zhihu.com/question/509914161/answer/2299099095?
?https://www.zhihu.com/question/509914161/answer/2299646933?