1. 背景
自從1994年日本的工程師原昌宏發明二維碼以來，微信於2011年引進二維碼，並很快認定了二維碼便是手機上的入口。說不清是二維碼成就了微信，還是微信成就了二維碼，但是到今天，中國的二維碼的使用量已經超過了日本，可以說是移動互聯網時代大放異彩。據2020年微信大會數據，因爲二維碼帶動的碼上經濟規模就達到了8.58萬億，有超過5kw中小商戶使用二維碼。
房產交易是一個典型的重線下產業互聯網市場，由於文化的不同而帶來了不同人興趣的不同，而同一個小區的房子也有非常大的差異，所以如何進行房客匹配是一個非常關鍵的問題。基礎設施的建設可以構築出客戶和經紀人完成交易的全鏈路平臺，而效率的提升可以幫助用戶更快速獲取自己滿意的房子，而這一切在買房上學和市場火熱的時候，變得更加突出和重要。
貝殼所進行的二維碼營銷，就是一條“以房找客”之路。憑藉數十萬龐大的線下經紀軍團，完成數百萬線上用戶的觸達，通過朋友圈二維碼營銷，將優質房源和目標客戶連接在一起，鋪設了新的高質量獲客渠道。
從房源、客源、場景、類型再加上灰度標籤多個維度來說，生成二維碼的差異非常之大，我們很難通過全量預生成的方式，提前將業務所需的二維碼準備好。特別是在推送push的情況下，數量非常龐大，瞬間峯值足以對服務器造成沉重一擊。所以，對碼上營銷來說，二維碼的生成成爲技術上的關鍵點。
在強大的需求背景下，我們接手了貝殼找房小程序的二維碼生成服務，志在高質量完成新房、二手、租房、海外等業務不斷膨脹的生成需求。然而中間並不順利，老服務不斷暴露出來新問題，亟待解決。我們在中間進行了一系列的思考，在這裏跟大家進行交流。
2. 架構演化過程
2.1 參數過長問題
我們知道，URL的完整信息可以包含在二維碼中；長度越長，二維碼就會越密集。當出現類似圖片壓縮，造成展示精度不夠時，就影響了二維碼的掃描使用。在一些小的海報和線下展示位就非常不便。
一般可以採用URL壓縮的方式，先通過短鏈服務，將長URL置換爲短URL，掃碼打開之後，前端支持302的情況下，就可以直接跳到最終URL上。短URL服務一般都具有很高的併發能力，所以不會成爲性能的瓶頸。所以該問題很容易解決。
但是這裏引入了一個新的問題，由於短鏈服務域名往往承接了非常多不同業務，一些業務常常在微信側並不合規。曾經筆者就遇到過因爲微信封殺url.cn，導致我方業務牽連受損的情況。
如果企業內部有短鏈服務，則可以適當降低風險。筆者也遇到了因爲租賃頁面違規，導致貝殼小程序發版無法過審的問題。混用不止，風險永遠都存在。但不可能每個業務都自建一個短鏈服務，短鏈服務也很難對每一個URL的業務進行了解，並及時拒絕有風險的業務方的接入。
另外一種做法是：
將URL的參數部分以request_id的形式，進行單獨存儲；在掃碼時，前端先通過查詢接口獲取request_id的參數部分，然後再根據詳細參數請求數據和渲染頁面，這樣就變向實現了二維碼的URL壓縮。不過缺點可能是：
- 前端多了一次掃碼查詢請求，增加了頁面打開的等待時間
- 二維碼是按個人+房源等信息來區分的，特別分散，複用度不高
- 掃碼用戶不多，緩存又容易過期淘汰，命中率低
- 增加了後臺存儲工作，生成二維碼延遲升高，分享體驗下降
- 如果緩存有抖動，有擊穿數據庫的風險
所以，如果單純實現成這樣，其實並不完善。
2.2 併發量問題
大家知道，微信二維碼生成方式有：
| 類型 | 接口 | 特點 |
|---|---|---|
| 類型一 | /cgi-bin/wxaapp/Createwxaqrcode | 合併總共10w個 |
| 類型二 | /wxa/getwxacode | |
| 類型三 | /wxa/getwxacodeunlimit | 每分鐘5000個 |
10w個二維碼顯然滿足不了貝殼經紀人對不同房源的分享訴求，所以我們只能選擇類型三。微信說沒有總量限制，但按每分鐘5000，其實隱含了每天最多720w個二維碼。一般不用關心總量，只需要關注峯值。如果峯值超出，則實際只能當成失敗處理。
微信建議量級過大走預生成，但是怎麼預生成呢？
二維碼信息=經紀人ID+房源ID+業務類型+……
貝殼平臺擁有數量龐大的經紀人團隊，每天接觸到想要分享的房源更多，而分享的場景類型也有差異化，所以每分鐘5000個很快就達到了瓶頸，在週末高峯期已經捉襟見肘。
a. 不可能要求經紀人提前生成二維碼保存再使用
經紀人本身對平臺提供的碼上營銷就有學習成本，更不用說操作成本這麼高。房源成交隨時都在發生，已經成交的房子的二維碼失去了營銷價值，也是一種浪費。
b. 機器生成很難命中需求
不同的經紀人能夠關注到的房子不同，很難通過機器爲經紀人提前生成，就算是隻針對熱門房源，也命中率很低。如果要通過距離、熱度等因素來計算，則陷入了一個更大的問題裏面。
c. 熱門營銷活動，針對性預生成
如果是營銷活動，一般是有準備的，可以具體的知道需要分享的頁面、推送的目標經紀人羣體，那麼屬於有限提前生成，看起來是技術上可行的。這裏的問題在於：
- 開發成本
貝殼分爲新房、二手、租賃、海外等業務，還有橫向的品質、好房等項目，每個團隊都去預生成，會導致營銷活動開發成本很高。
- 時間成本
如果開發一套通用的預生成機制，提前幾個小時就開始生成二維碼，一個是不一定趕得上業務方的需求上線時間點，二是不一定有這麼多資源給你預生成，因爲實時生成的量級也很大，留給預生成的額度本來就不多了。
- 併發壓力
如果同時在準備的營銷活動比較多，則更加搶手，最後還會因爲要預生成而造成比實際峯值更大的峯值。
- 浪費嚴重
營銷活動的實際參與情況，並不是那麼樂觀，浪費依然很嚴重。
2.3 動態綁定的預生成方式
2.3.1 思路分析
前面的思路里面，一個比較典型的現象是，白天作業高峯不夠用，晚上又無法合理的利用資源。如果我們能夠積累一批二維碼，可以用於任何業務場景，則能夠達到削峯填谷的作用，問題自然迎刃而解。
這就類似於你的舊信用卡到期了，不能換號，只能等廠家製作，完了才能快遞給你，等待週期長。而對於新申請開戶來說，銀行提前製作了大量的有號銀行卡，在你申請時，直接任選一張，跟你的身份證綁定就可以了，等待週期短。
2.3.2 核心設計
現在讓我們重新看一下前文提到的request_id的流程圖。
通過分析發現，要生成二維碼，只需要path和request_id即可。而path對於每個業務方來說，是相對集中的，目前統計有30種。而request_id可以走分佈式唯一ID生成算法，構造一批，這樣就可以滿足生成二維碼的必要條件。等業務方來請求新二維碼的時候，就隨機取一個已有request_id分配，並和params完成後期綁定就可以了。掃碼過程保持查詢request_id的過程不變。
由此，二維碼的囤積方式，分爲三種：
- 夜間生成，白天覆用
- 工作日生成，週末高峯期複用
- 白天撿漏
只要囤積的二維碼足夠多，那麼高峯期的分配就不是問題。我們針對白天撿漏算法進行了針對性的詳細設計，後續有機會再分享。
2.3.3 性能分析
由於預生成二維碼之後，可以完成兩項重操作：
- 上傳到cdn，獲取持久的二維碼URL
- 數據庫生成記錄，進行落地
所以到實際綁定時，只需要將綁定關係存儲到分佈式緩存系統（如redis），則掃碼時則可以直接命中緩存，掃碼和分配都會比較快。爲了防止redis過期，可以加上回寫邏輯。將綁定關係計入日誌流水，或者發送到消息隊列，異步任務批量入庫，性能也會比較高。
而預生成的二維碼可以放入kafka等高性能的消息隊列，需要時取出即可。只要在kafka中放入足夠多的二維碼，應對高峯期的20分鐘過量需求，是完全不成問題的。
所以整體流程改造下來，比實時生成，無論是速度還是併發能力，都能夠提升非常多。瓶頸從微信接口併發能力，轉移到內部服務器的數量，和kafka隊列積累的二維碼總量大小上來。
2.4 頁面多樣性問題
以上方案中，還存在一個問題：path的管理成本。
- path隨着業務方迭代，會不斷申請，需要持續維護
- 按path維度預生成，很難預估下一分鐘的需求量級
- 某個path如果下線，則對應topic下資源全部作廢
- kafka的auto.create.topics.enable開關如果被DBA關閉，那麼新增一個path需要手動提單才能創建新topic
所以固定一個topic的方式則比較好用，而kafka性能可以通過增加partition數量的方式來進行快速的擴容，所以併發能力不是問題。
如何做呢？我們的選擇是前端開發一箇中間頁，將原本的path信息也放入params參數中，所有的預生成二維碼都是用中間頁的固定path，這樣就不用擔心浪費問題，可以進行海量預生成累積了。
性能方面，並未增加更多的接口調用，所以無妨。
有區別的差異是：
-
前端如果能儘早知道最終的path，則可以儘早展示骨架圖
實際上，替換爲loading效果，在產品上也可以接受，所以差異不大。
![]()
-
很難使用微信的掃碼數據預拉取功能
微信能夠在小程序冷啓動的時候通過微信後臺提前向第三方服務器拉取業務數據，當代碼包加載完時可以更快地渲染頁面，減少用戶等待時間，從而提升小程序的打開速度。
由於前面增加了一個公共的掃碼查詢接口，再跳轉各個業務方時，很難通過一個固定接口來知道新房、二手、租賃等業務方的各個頁面都需要什麼具體的數據。
3. 總結
通過以上的逐步分析和方案思考和實踐，我們最終完成了一個轉交項目，二維碼服務的高併發改造，並支持以很低的成本進行維護。中間也有談到一些利弊的思考，以及我們的選擇。如果你有更好的思路，請不吝賜教。如有勘誤，請大力斧正。
本文轉載自公衆號貝殼產品技術（ID：beikeTC）。
原文鏈接：