贝壳找房小程序平台架构演进

贝壳找房小程序至今为止已经拥有了近2亿的用户，团队正在在朝着贝壳人的宗旨迈进，给这个行业创造更多的价值，努力成为一个能够服务2亿家庭的品质居住平台。

经过两年多的发展，为了更好的适应业务发展，贝壳小程序后端从最初的快速搭建到后来由php到golang的转型与优化，到现在微服务的落地和业务网关能力的提升，贝壳小程序平台一直走在蜕变的路上。而贝壳找房小程序和app的上线，也意味着一直在房产行业里深耕的链家，从直营模式到贝壳找房平台化模式的正式转变。

小程序平台同样传承了公司平台化的转变理念和模式，把平台化思路坚决贯彻下去，在完成平台需求的同时，沉淀平台核心能力，赋能各个业务，甚至赋能给整个行业。

1 小程序平台1.0

贝壳找房小程序起始于2018年，1.0时代小程序团队主要是在追赶功能，团队在半年时间内完成了1年应该完成的业务。半年期间小程序产研团队快速扩增，此期间大量的进行API层开发，封装各业务接口，以快速完成第一版的小程序为目标。

1.1 极速上线小程序后台服务

极速上线公司级小程序平台要面对的问题是什么呢？因为贝壳小程序平台的特殊属性，各个业务例如新房、二手、租赁、装修都是分属在各团队维护的，所以需要有平台业务方来整体对小程序的性能做分析和监控。

首先是每日性能监控，团队做了第一版的性能分析日报，把小程序内所有域名的请求量、平均响应时间、499以及5XX状态码的数量占比、并发峰值、qps高峰时间、稳定性百分比等等，以稳定性日报的形式输出给团队所有成员，并且详细的列出了所有接口的情况，做到小程序内所有的服务，平台都能“心中有数”。二是小程序平台自身接口的实时预警，接入了公司Fast监控平台，实时监控各接口的性能指标情况，包括域名错误、SQL异常、第三方请求超时、业务日志ERROR、服务请求异常等等，保证极速上线的小程序能健康的运行。

1.2 如何抗住100倍流量的九宫格？

全部小程序的统一带来的风险就是流量的瞬间上涨，不仅仅是各小程序流量的整合，微信九宫格的流量也会瞬间涌入小程序平台，于是项目组开始了接口的优化和拆分，首先对预估流量进行了一次压测，发现性能瓶颈在redis集群上，内存使用率达到了90%以上，但实际瓶颈并不在于redis本身，在于当前redis集群的内存管控上，这里我提一下为什么DBA需要对redis集群进行内存管控呢？首先是贝壳业务线较多，每个微服务都可以申请独立的redis集群，运维成本是比较大的，另外如果内存超过20G，高可用的切换后，恢复的时长就可能会超过5分钟，一定程度增加了故障发生的概率，所以这个内存的管控上还是有必要的。

那该如何优化呢？第一反应是特定业务场景的扩容，虽然说有20G内存的限制，但是如果业务场景特殊性，这个扩容也是可以支持的，不过如果在应用层面就能优化，何乐而不为？我们通过监控指标发现redis集群的cpu占用和I/O使用都是在正常的范围，唯独内存占用严重超标，经过分析发现是房源详情大json和小程序首页占用了较大的内存，一方面我们选择了合适的压缩算法，对redis大value进行压缩，减少了redis的将近一半以上的内存占用，另一方面，我们对小程序首页的redis使用了pconnet长连接，避免频繁建立短连接的性能损耗。

简单的优化，也给给团队带来了一些思考，以后在对面redis的优化，在平台侧要保持一定的容量buffer可扩容，避免出现容量危机，另一方面，可以利用压缩、切分等来提高性能。

1.3 沉淀核心服务

业务上，团队完成了核心的新房二手业主等业务的功能模块开发，在和app对齐的同时又丰富了微信体系内的消息订阅、推送等场景，此后又开启了小程序体系特有的业务场景开发，微信体系内的分享、渗透、拉新，以及码上有客项目的启动，开始通过小程序为贝壳几十万经纪人提供自我营销能力。

技术上，也沉淀了一些核心能力，例如第一版小程序的分享能力的建设，经纪人通过小程序进行分享后，可以记录核心的分享链条，包括经纪人用户关系、阅读场景、停留时长等等。

上图是第一版用户分享行为上报的核心链路，当用户扫码以及授权后，会建立经纪人和用户之间的关系，计算出相关的业务指标并落库，经纪人在后台就可以看到用户的访问信息、阅读时长等等，这部分能力随着业务迭代进行过几次比较大的升级，当前也通过大数据等手段完善了原有的分享能力。

可以看到的是核心分享能力的沉淀，对业务可以有较大帮助，业务方可以通过用户与经纪人的行为分析，更精准、更有效的给那些真正有购房需求的用户更大的帮助。分享能力的平台化建设可以拓展的范围也是可以预见的，除了之前核心B2C的场景，C2C也是未来可以深入的一个方向，其中包括用户分享与用户裂变的行为数据链能力的建设。可以沿着平台化思路的方向，和大数据推荐团队合作，做一些定向的营销方案、打包推荐等等。

2 小程序平台2.0

随着业务量的上升，小程序用户数量急剧增长，面对越来越高的QPS，必须要保持敬畏之心，团队准备开启2.0的升级，大胆的尝试从php往golang的跃迁，率先在把之前php api层的流量往golang 网关切换，团队在golang层上也做了很多优化。

首先说下为什么要选择在网关层引入golang。关于php和golang的选择近些年的争议不断，当然了PHP是最好的语言，也得益于PHP的易用性和稳定性，才得以让小程序能够在这么短的时间内完成1.0的上线。但是PHP在安全性、并发性等方面也有一些不足之处，那golang有什么自身的优势呢？首先是goruntine协程，它作为golang的主要代表成员之一，是golang中的并发执行单位，它也是轻量级的线程，由Go（runtime）管理，Go程序会智能的将goroutine中的任务合理的分配给每个CPU。在面对高额QPS的请求，golang会更适合做网关。

2.1 golang改造，突破高并发瓶颈

在传统golang项目中，团队做了第一次的压测，效果并不理想，当时我们进行了pprof的性能分析。

上图是cup的性能分析，发现高QPS下，系统GetLocalIp获取函数占用了4.91s的大性能消耗，这个性能消耗是比较可怕的，另外Log的写入也有一定程度的性能消耗，占用了1.92s，同时大家也分析了一下高QPS下的内存分配情况。

从上图也可以看出。对于ip的获取，使用内存达到了20M，而分配的累计值达到了29G之多，所以采取了一些优化方案，改变了获取本地ip的方式，从缓存中获取，一次写入多次读取，并且把log的写入方式改成异步写入。之后，整体的性能和效果得到了一个较大的提升。

上图可以看到单机下，golang网关的抗压QPS可以达到11000QPS，而CPU的使用率还不到40%，而相同机器配置的PHP服务已在4000+QPS压测的时候，机器CPU已经达到80%，逼近极限，网关的改造达到了我们的心里预期。这也是为什么使用golang作为小程序网关的原因之一。

2.2 整体架构-沉淀小程序平台核心架构

上图是小程序平台2.0时代的架构图，相比1.0，我们在API层之上加入了golang“网关”，这里的网关我加了引号，主要原因是在2.0时代，它只参与了其他业务的代理透传，没有网关的实际能力，其中直播、贝壳金服、内容的业务完全经过代理层转发。API层、服务层则和1.0保持一致。

2.3 争当业务线“保卫官”

这里要提一下网关层在小程序平台的必要性，微信对原生小程序内的HTTP请求是有域名限制的，因此新业务已经没有办法再分配更多的域名，故而新的业务方想要接入小程序的话，只能接入小程序的网关，走统一域名。而小程序的网关自然而然的成为了接入小程序平台的“必经之路”，我们接下来要开启网关能力建设了，因为网关的能力也是真正能够赋能给业务方的，让大家放心的接入，小程序平台可以成为业务线的“保卫官”。

3 小程序平台3.0

完成2.0时代的优化之后，要更多关注的是清晰的系统架构，关注数据量大之后系统瓶颈的解决、以及关注系统稳定性的建设。

3.1 整体架构-边界清晰，能力健全

伴随着公司微服务理念的推进，小程序平台也逐渐往微服务方向发展，把臃肿的大单体拆分为边界明确、功能模块清晰的一个个微服务，不仅仅在代码层面解耦，部署环境、数据库、redis等都进行了拆分和解耦，让小程序平台慢慢变成一个更为健壮的体系。    

上图是小程序平台3.0的整体架构图，从上至下，分了5层结构：

• 平台网关层：主要接收来自小程序前端的请求，经过路由转发给各业务api

• 业务API层：负责接收网关转发的请求，处理自己的业务逻辑

• 平台服务层：小程序平台核心能力，包括多端用户&Token管理、多端消息、小程序搜索等

• 存储层：包括了Mysql、Redis以及3.0后新增的TIDB和Hive，下文会对存储的改进做一个介绍

• 中台支撑层：公司级中台能力，用来支撑整个系统的基础能力，包括房源、客源、人力中台等

3.2  微服务落地

关于微服务的理念，本文不再详情的描述，近些年来微服务已经是炙手可热的话题了，相比传统单体架构，程序的组件是相互依赖的，二不是松散耦合。对微服务架构而言，每个模块都是独立的，可以在不影响其他模块的情况下对单独的模块进行修改，避免了大单体带来的影响，如下图所示。

3.0架构里的平台服务层，就是小程序平台具体的微服务落地场景了，进入到3.0时代，贝壳小程序已经不仅仅只是微信小程序了，百度小程序、快手小程序、快应用、QB小程序也先后加入到了小程序平台的行列里，之前多端小程序的处理方式基本上就是在各个函数里做兼容，代码越发的臃肿，更为可怕的是开发和测试过程要覆盖的场景也是越来越多，不断的在鞭策我们做出改变。

首先是把小程序生态内特有的服务划分出来，于是多端用户体系和多端消息体系和小程序搜索服务成为第一批需要下沉的微服务，从之前的purist项目中拆分出来，每个微服务都拥有新的服务器和redis资源，相互隔离、边界清晰。

当然了，不仅仅只是做了领域边界的拆分，更重要的是领域边界拆分过程中的一些优化和升级。例如在下沉多端用户服务的同时，我们还做了小程序Token自动化整合，原本针对每一个小程序都进行了一次token刷新的开发，这无形之中是在不停的浪费开发资源和效率，而这些小程序或者公众的Token失效机制大同小异，于是我们在落地多端用户微服务的同时，还进行了token的管理自动化，一旦有新的小程序或者公众号引入的时候，只需要在appllo配置即可，避免了重复的开发的同时还能更好的赋能业务。下图是小程序Token自动化刷新方案。

微信搜索服务是小程序平台的另一个微服务，这个服务也是微信生态内特有的，所以他是属于平台的另一个核心服务，早期的微信搜索做的比较简单，以贝壳房价服务为例，贝壳房价指数数据目前存储于HIVE底表中，大数据工具的查询效率往往是比较低的，不适合C端用户直接查询，这样就导致了用户微信内搜索召回不了贝壳的服务数据，无疑是贝壳的损失。

这次微服务下沉的过程中，团队对微信搜索也做了优化，我们打算对城市、城市+小区/楼盘、小区/楼盘/商圈，三个维度对微信的请求数据做了缓存预热，但是小区、楼盘的数据量其实是非常大的，全量的预热不太现实，所以我们采取了热点词的缓存预热方案，首次搜索的时候以贝壳检索热词预热，落地微信请求后获取微信热词服务，后续可以直接用微信的热点词来做缓存预热，如下图所示：

3.3 mysql大数据瓶颈优化

小程序平台业务数据也在剧增，不少核心表的数据量已经过亿，慢查询、慢响应越来越多。数据库的优化势在必行，我们想到了分库、分表等方案，还有一点非常重要的就是引入了新的工具TIDB。

为什么要选用TIDB呢？

这里首先要提一下，2020年TIDB已经被越来越多的国人所知，它是云原生的分布式数据库，存储引擎是FaceBook开源的高性能存储引擎RocksDB，不仅支持OLTP也支持OLAP，更重要的是它高度兼容Mysql协议，也就是说我们可以在不分表的基础上，实现Mysql的弹性扩容，极大的减小了我们的业务代码变动，此外TIDB支持灵活和弹性扩展，数据按Region分片，有自带的调度管理组件，同时TIDB还提供了TISpark这样的OLTP工具，满足了我们实时、准确的大数据查询服务。我们首先在SLA要求不超过99.99%的非核心业务场景率先做了迁移，平滑迁移的非常顺利，后续我们又在一些新业务场景上使用了TIDB。

带来的收益也是比较明显的：

• 解决了单点问题，架构更加清晰，可维护性、可扩展性也增强了。
• 底层数据库切换，应用无感知，并且切换成本低。
• 能够满足高性能OLTP的业务场景
  例如分享服务的实时的PV和UV计算，如果是通过传统大数据方案，大多数只能满足T+1的场景，而TIspark满足了业务OLAP的需求。

3.4  系统稳定性建设

系统稳定性建设的原则包括了大系统小做、被依赖服务的稳定性、用户体验的容错性以及有非常强健的稳定性处理方案等等。

系统稳定性架构设计的一大原则是大系统小做，怎么理解呢？举个简单的例子，比如上述提到的用户登录服务，如果公司要求加入风控逻辑，在没有微服务拆分之前，这个逻辑是要涉及到整体发版的，然后就会把所有代码都带着发版了，但是这样可能会造成用户消息功能受影响，所以说微服务的落地和系统稳定性的建设就遥相呼应了，把子服务拆开，做独立的服务。

二是被依赖服务的稳定性就要求我们做的服务和平台能够让所以业务方用的放心、用的可靠，强健的稳定性处理方案就包括了一些及时止损和保护用户体验的方案。所以首先，如何成为一个可靠的小程序平台，是我们要做的重要的事情。

在2.0时代golang项目引入平台，但它并不是真正意义上的网关，严格说来，它只是做了业务透传. 因为并没有网关的实际能力，3.0后在网关层做了一些优化，为了保证业务系统跑在平台网关上更为安全和稳定，团队在golang网关层引入了go-sentinel、API管理和路由管理，完成了核心的限流、熔断功能，变成了真正意义上的网关层。相比传统的计数器、令牌桶限流算法等，sentinel显得更为强大，它是面向分布式服务架构的轻量级流量控制，不仅能够解决固定窗口算法流量激增超过临界点的问题，也解决了令牌桶漏出速率必须是固定参数的问题，在保证平台能够有秒杀场景的支撑能力的同时，也有了更完备的实时监控能力。

经过平台网关的请求，会在Header里带上微信生态的用户信息，例如open_id、union_id等等，屏蔽业务方和微信侧的直接交互，在业务方快速接入小程序平台的同时也避免了多业务方同时请求微信、百度或者快手等小程序带来的接口失效等问题。

上图是小程序平台网关的一些能力，有一些是还在建设中的，比如熔断、降级方案，触发到熔断后如何做用户体验更好的产品呢？或者说如果做一个更为稳定的系统呢？

上图是我们的一个api降级方案，有一个降级中间件和降级服务来完成api降级策略，当用户请求的时候，即使是请求的服务异常触发到了熔断的策略，也能够让用户无感，返回给前端上一次正确的请求结果，当然了这个使用成本也是有的，因为这里的数据一致性就不能完全保证了，所以说熔断降级方案还要和具体的业务场景结合起来，千万不要为了降级而降级。

4 未来展望

1. 微服务领域的细化

   
   

   不难看出，我们在微服务上只是简单的做了一些大模块的拆分，其实大模块内的领域我们并没有做精细化的划分，这是未来我们要做的事情，我们更希望通过领域驱动的模型来协助我们做更深入且合理的设计

   
   

2. 系统稳定性建设-流量预警

   
   

   我们现在接入了很多监控，服务异常、响应时长的监控等等，不过还缺乏一些流量的监控体系，例如流量环比剧增或者剧降等等，之前发生了不少的问题都是由于没有流量监控导致问题发生了很久之后才被人工发现，显然代价是比较高的，流量预警能帮助我们更快的发现一些未知的问题。

   
   

3. 更多核心服务能力的整合

   
   

   平台化的道路漫长而艰巨，我们也需要不停的成长，相信未来一定能看到一个更为健康强壮的小程序平台。