贝壳找房二维码生成服务架构的演进与思考_架构_吴强



 写点什么

自从 1994 年日本的工程师原昌宏发明二维码以来，微信于 2011 年引进二维码，并很快认定了二维码便是手机上的入口。说不清是二维码成就了微信，还是微信成就了二维码，但是到今天，中国的二维码的使用量已经超过了日本，可以说是移动互联网时代大放异彩。据 2020 年微信大会数据，因为二维码带动的码上经济规模就达到了 8.58 万亿，有超过 5kw 中小商户使用二维码。

房产交易是一个典型的重线下产业互联网市场，由于文化的不同而带来了不同人兴趣的不同，而同一个小区的房子也有非常大的差异，所以如何进行房客匹配是一个非常关键的问题。基础设施的建设可以构筑出客户和经纪人完成交易的全链路平台，而效率的提升可以帮助用户更快速获取自己满意的房子，而这一切在买房上学和市场火热的时候，变得更加突出和重要。

贝壳所进行的二维码营销，就是一条“以房找客”之路。凭借数十万庞大的线下经纪军团，完成数百万线上用户的触达，通过朋友圈二维码营销，将优质房源和目标客户连接在一起，铺设了新的高质量获客渠道。

从房源、客源、场景、类型再加上灰度标签多个维度来说，生成二维码的差异非常之大，我们很难通过全量预生成的方式，提前将业务所需的二维码准备好。特别是在推送 push 的情况下，数量非常庞大，瞬间峰值足以对服务器造成沉重一击。所以，对码上营销来说，二维码的生成成为技术上的关键点。

在强大的需求背景下，我们接手了贝壳找房小程序的二维码生成服务，志在高质量完成新房、二手、租房、海外等业务不断膨胀的生成需求，然而中间并不顺利，老服务不断暴露出来新问题，亟待解决。我们在中间进行了一系列的思考，在这里跟大家进行交流。

架构演化过程

参数过长问题

我们知道，URL 的完整信息可以包含在二维码中；长度越长，二维码就会越密集。当出现类似图片压缩，造成展示精度不够时，就影响了二维码的扫描使用。在一些小的海报和线下展示位就非常不便。

一般可以采用 URL 压缩的方式，先通过短链服务，将长 URL 置换为短 URL，扫码打开之后，前端支持 302 的情况下，就可以直接跳到最终 URL 上。短 URL 服务一般都具有很高的并发能力，所以不会成为性能的瓶颈。所以该问题很容易解决。

但是这里引入了一个新的问题，由于短链服务域名往往承接了非常多不同业务，一些业务常常在微信侧并不合规。曾经笔者就遇到过因为微信封杀 url.cn，导致我方业务牵连受损的情况。

如果企业内部有短链服务，则可以适当降低风险。笔者也遇到了因为租赁页面违规，导致贝壳小程序发版无法过审的问题。混用不止，风险永远都存在。但不可能每个业务都自建一个短链服务，短链服务也很难对每一个 URL 的业务进行了解，并及时拒绝有风险的业务方的接入。

另外一种做法是：

将 URL 的参数部分以 request_id 的形式，进行单独存储；在扫码时，前端先通过查询接口获取 request_id 的参数部分，然后再根据详细参数请求数据和渲染页面，这样就变向实现了二维码的 URL 压缩。不过害处可能是：

前端多了一次扫码查询请求，增加了页面打开的等待时间
二维码是按个人+房源等信息来区分的，特别分散，复用度不高
扫码用户不多，缓存又容易过期淘汰，命中率低
增加了后台存储工作，生成二维码延迟升高，分享体验下降
如果缓存有抖动，有击穿数据库的风险

所以，如果单纯实现成这样，其实并不完善。

并发量问题

大家知道，微信二维码生成方式有：

10w 个二维码显然满足不了贝壳经纪人对不同房源的分享诉求，所以我们只能选择类型三。微信说没有总量限制，但按每分钟 5000，其实隐含了每天最多 720w 个二维码。一般不用关心总量，只需要关注峰值。如果峰值超出，则实际只能当成失败处理。

微信建议量级过大走预生成，但是怎么预生成呢？

二维码信息=经纪人 ID+房源 ID+业务类型+……

贝壳平台拥有数量庞大的经纪人团队，每天接触到想要分享的房源更多，而分享的场景类型也有差异化，所以每分钟 5000 个很快就达到了瓶颈，在周末高峰期已经捉襟见肘。

（1）不可能要求经纪人提前生成二维码保存再使用

经纪人本身对平台提供的码上营销就有学习成本，更不用说操作成本这么高。房源成交随时都在发生，已经成交的房子的二维码失去了营销价值，也是一种浪费。

（2）机器生成很难命中需求

不同的经纪人能够关注到的房子不同，很难通过机器为经纪人提前生成，就算是只针对热门房源，也命中率很低。如果要通过距离、热度等因素来计算，则陷入了一个更大的问题里面。

（3）热门营销活动，针对性预生成

如果是营销活动，一般是有准备的，可以具体的知道需要分享的页面、推送的目标经纪人群体，那么属于有限提前生成，看起来是技术上可行的。这里的问题在于：

开发成本
贝壳分为新房、二手、租赁、海外等业务，还有横向的品质、好房等项目，每个团队都去预生成，会导致营销活动开发成本很高。
时间成本
如果开发一套通用的预生成机制，提前几个小时就开始生成二维码，一个是不一定赶得上业务方的需求上线时间点，二是不一定有这么多资源给你预生成，因为实时生成的量级也很大，留给预生成的额度本来就不多了。
并发压力
如果同时在准备的营销活动比较多，则更加抢手，最后还会因为要预生成而造成比实际峰值更大的峰值。
浪费严重
营销活动的实际参与情况，并不是那么乐观，浪费依然很严重。

动态绑定的预生成方式

思路分析

前面的思路里面，一个比较典型的现象是，白天作业高峰不够用，晚上又无法合理的利用资源。如果我们能够积累一批二维码，可以用于任何业务场景，则能够达到削峰填谷的作用，问题自然迎刃而解。

这就类似于你的旧信用卡到期了，不能换号，只能等厂家制作，完了才能快递给你，等待周期长。而对于新申请开户来说，银行提前制作了大量的有号银行卡，在你申请时，直接任选一张，跟你的身份证绑定就可以了，等待周期短。

核心设计

现在让我们重新看一下前文提到的 request_id 的流程图。

通过分析发现，要生成二维码，只需要 path 和 request_id 即可。而 path 对于每个业务方来说，是相对集中的，目前统计有 30 种。而 request_id 可以走分布式唯一 ID 生成算法，构造一批，这样就可以满足生成二维码的必要条件。等业务方来请求新二维码的时候，就随机取一个已有 request_id 分配，并和 params 完成后期绑定就可以了。扫码过程保持查询 request_id 的过程不变。

由此，二维码的囤积方式，分为三种：