标准化思想及组装式架构在后端 BFF 中的实践

1. 前言

在本地生活服务领域，面向 C 端的信息展示类功能存在着类生物系统的复杂性，具体体现在以下三个方面：功能多，为了帮助用户高效找店、找服务，信息会在尽可能多的地方展示；差异大，同样的信息，在不同客户端、不同页面及模块下的展示逻辑会存在一些差异；功能易变，产品逻辑经常调整。以上三个方面的特点给研发同学带来了很大的挑战，比如当我们面临数千个功能模块，数十个行业产品的持续需求时，如何快速响应呢？

进入互联网 “下半场”，靠 “堆人力” 的研发方式已经不再具备竞争力了，真正可行且有效的方式是让系统能力变得可沉淀、可组合复用、可灵活应对各种变化。在多业态、大规模定制需求的背景下，本文分享了如何通过组装式开发的方法来提升业务的竞争力。

2. 背景与问题

2.1 业务背景

先来讲一下我们的业务和产品，美团到店是一个生活服务平台，通过 “信息” 连接消费者和商家，帮助用户降低交易成本，这是信息产品功能的业务价值。当我们打开美团 / 点评 App，搜索 “美发”，就可以看到一个搜索结果页，展示着基于关键词召回的美发商户（如下图左所示）。商户下面挂着当前门店所提供的团购、会员卡概要信息，我们选择一家门店进入商户详情页，自上而下滑动，可以看到商户的地址模块、营业信息模块等基础模块（如下图右所示）。继续往下还能看到商品货架模块、会员卡模块、发型师信息等等，以上就是信息展示产品的具体形态。

前文我们提到过本地生活服务行业信息类产品功能的核心特点是功能多、差异大、功能易变，为了帮助读者更好地了解相关的业务背景，针对这几个特点我们进一步补充：

• 功能多：在多业态背景下，信息展示功能总体上表现为功能模块非常多。主要是因为同样的内容会在多个地方展示，比如某个行业的商品信息会在 App 的首页、搜索结果页、频道页、详情页、订单页、运营页等多个页面进行展示。并且当新行业新内容出现的时候，又会全面铺开，进而导致增加更多的功能。截至目前，我们已有上千个展示功能，呈规模化势态。
• 差异大：差异化主要体现在相同的内容，在不同行业、不同客户端、不同模块、不同版本甚至是不同用户条件下，都会有不同展示逻辑。比如商户详情页货架的商品标题这个字段，有的行业展示的规则是 “服务类型 + 商品名字”，如 “[玻璃贴膜] 龙膜全车车窗隔热膜套餐”。有的行业的展示规则是 “服务特性 + 商品名字”，如 “[洗吹] 单人明星洗吹 + 造型”。再比如跳转链接这个字段，H5、小程序和 App 内的跳转链接的拼接规则都不一样。诸如此类的差异几乎贯穿所有的功能。
• 功能易变：主要体现在产品逻辑会经常发生迭代。分析变化原因来自多个方面，首先是这类信息产品面向海量互联网用户，用户体验敏感度高，细微的展示规则差别都可能会导致不同的转化效果，到底是哪个展示规则效果比较好，产品只能通过不断的调整来进行验证。其次，本地生活服务标准化程度低，内容本身的结构也在不断迭代，内容变更同时也决定了展示功能要跟着变。最后一点，互联网行业中产品的职责也会经常进行调整，不同的产品对功能的理解是不一样的，这也是导致功能更迭的原因之一。

以上是生活服务行业信息产品的特点，面对大规模、差异化的信息展示类功能的挑战，产品在持续迭代，研发同学又面临怎样的问题和挑战呢？

2.2 研发挑战

在分享技术挑战之前，可以先看看研发同学的日常。这里有两个小场景：

• 场景一，由 B 端（商家 / 运营）直接生产出来的信息，不能直接展示给用户。B 端主要关注信息能否高效录入，录入的信息不适合直接展示给用户，需要经过一些逻辑加工，同一份 B 端录入的信息可能会有多种加工展示规则。
• 场景二，由于 B/C 端业务领域问题差别较大，为降低开发难度，B/C 端一般会做精细化分工，一拨人专注 B 端的信息录入能力建设，一拨人专注 C 端的信息展示。

而我们就是专注信息展示的这拨人。这类系统业界也有一些标准的术语，叫 BFF（Backend For Frontend）。BFF 的主要职责是组合使用底层数据，额外处理 C 端展示逻辑。综上所述，我们研发同学具体的工作通常是：通过外部数据源将原始数据查到，然后按照产品的要求，把查到的原始信息加工成可以展示给用户的信息，最后发送给客户端使用。如下图所示，这部分工作主要由中间的 BFF API 服务负责：

联系方式

地址: 徐州大学生创业园、徐州市泉山区人民广场西侧西城华庭B座 邮编: 221000

电话: 18105201506 15052002776

邮件: haobin@yiro.top

网址: http://www.yiro.top

扫一扫加企业微信