【第3374期】携程酒店前端BFF实践

前言

携程酒店前端 BFF 实践探讨了如何通过能效变革提升前端性能。今日前端早读课文章由公号：携程技术授权分享。

@携程酒店研发前端 BFF 组，专注 BFF 研发实践及效能提升；
@携程云函数研发项目组，专注新一代 FaaS 研发模式在携程的落地实践；

正文从这开始～～

本文概述了携程酒店前端 BFF 层在架构迁移及效能提升过程中面临的挑战和应对方案。第一部分描述了 BFF 实践过程中遇到的问题，分析了两种 BFF 模式的对比并提出了一码多端的 BFF 研发方案；第二部分通过介绍携程云函数平台能力来阐述其如何帮助提升 BFF 研发的效能；第三部分简单介绍了前端动态化能力的未来规划。

【第3047期】基于 RPC 和 TypeScript 的 BFF 设计与实践

一、背景介绍

• 1.1 一码一端

• 1.2 一码多端

二、基于 Nest 的多端架构
三、云函数平台

• 3.1 函数能力

• 3.2 研发流程和函数生态

四、前端动态化能力
五、One More Thing

一、背景介绍

随着互联网和移动设备的普及，用户对于应用的需求也越来越多样化和个性化，这就要求应用程序在不同的端类型上表现出差异化的交互和 UI。同时，在后端微服务化的变革浪潮下，后端开发人员需要专注在领域服务及建模的工作中。而交互 / UI 的变更频率往往要高于领域服务及相关模型，加之前 / 后端本身的差异性也会无形中加重后端开发人员的心智负担。这就使得后端开发人员既无法专注于领域模型的抽象，又无法敏捷灵活地适应不同的用户界面差异，限制了整体的研发效率提升。

为了解决这个问题，BFF 作为一种研发模式被提出。其作为 “面向前端的后端服务”，作为中间层在软件架构上隔离了领域服务层及前端 UI 层。随着架构被隔离，相关的开发人员及开发角色也随之被清晰的分开：前端研发负责 BFF 的视图逻辑，后端研发则可以专注在领域服务层当中。

这种模式改变了原来的生产关系，令后端开发人员可以更专注于特定领域模型及服务的搭建，不必过多关注频繁的 UI 层变动。而 BFF 开发人员则可以与前端开发人员更紧密的合作（甚至前端同时兼任 BFF 开发工作），提供更符合前端场景需求的接口及数据结构。BFF 不是一项突破性的生产力变革，更多是一种生产关系变革，通过前后端协作模式的调整来适应互联网领域的敏捷开发节奏。

传统的 API 层包含了视图逻辑和业务逻辑，统一由后端开发进行维护。BFF 层承担其中视图逻辑的职责，而业务逻辑则 “下沉” 到领域微服务层进行维护。

在现代微服务架构模式下，BFF 作为一类后端服务也被部署在微服务架构中。它作为整个架构中前 / 后端应用的中间层，也需要考虑其内部各个 BFF 应用的职责分工问题。通常，可以按照‘领域驱动设计’来进行微服务职责的划分：把特定领域范围内的功能划分到一个微服务上做到聚合，把彼此关联性较小的功能划分到不同的服务上满足解耦。在携程酒店业务 BFF 架构实践过程中，针对 BFF 微服务职责的划分问题，出现过 2 种模式：“一码一端” 和 “一码多端”。

【第2827期】基于 GraphQL 的云音乐 BFF 建设实践

1.1 一码一端

这个模式针对特定客户端提供一个单体 BFF 应用，该应用提供整个酒店预定主流程的全部服务能力。为各端提供了充分的控制端差异的能力，独立开发独立部署。在 Ctrip 小程序端的 BFF 上有过使用，特点是能够快速部署，独立迭代，适合小团队运维和快速上线。

但缺点是出现了单体巨型应用，在一个服务内承载了列表 / 详情 / 填写全流程的前端服务能力，整个应用架构显的臃肿。并且针对同一个产品需求，各端的 BFF 应用内部需要各自实现相似的视图控制逻辑，在实现业务需求的时候存在重复开发的弊端，不利于提高人效。

1.2 一码多端

这个模式将预定主流程划分为若干关键阶段，分别由不同的 BFF 提供服务，且一个 BFF 俱备服务多端的能力并在内部处理不同端的差异性，避免了重复开发，从而提升研发侧整体的生产效率。且由于按页面流程维度进行了微服务划分，架构上更为清晰，迭代也更加灵活。

从两种模式的实践结果来看，“一码多端” 的模式更符合微服务职责划分的原则，也更有利于提高研发人效。因此，当前酒店的 BFF 层的实践方向主要采用了 “一码多端” 的模式。曾经采用 “一码一端” 模式的 BFF 应用也将向 “一码多端” 模式重构迁移。

【第3286期】Next.js SEO：如何使用 Next 构建高性能应用程序

二、基于 NestJS 的多端架构

前述已经谈到了 BFF 的概念以及酒店业务 BFF 的微服务划分方式，接下来谈具体实现层面的问题。

首先，我们选择了 NestJS 作为酒店 BFF 基础框架进行二次开发。NestJS 是一个用于构建高效、可扩展的 NodeJs 服务器端应用的框架。它使用渐进式 JavaScript，构建并完全支持 TypeScript。并结合了 OOP（面向对象编程）、FP（函数式编程）的特点。相比其他框架，有如下一些优势：

• 强大的模块化和可扩展性：使用模块化的结构来组织代码，这使得代码更易于组织和维护。此外，NestJS 还提供了一种插件系统，允许开发者扩展框架的功能。

• 内置的依赖注入容器：内置了一个强大的依赖注入（DI）容器，使得服务和控制器之间的解耦变得简单，同时也提高了代码的可测试性。

• TypeScript 的支持：基于 TypeScript 编写的，这意味着可以利用 TypeScript 的静态类型检查和最新的 ECMAScript 特性。也可以使用纯 JavaScript。

• 装饰器和元数据反射：大量使用了装饰器，这使得代码更易于理解和维护。同时，通过元数据反射，NestJS 可以自动处理很多常见的模式，如路由、依赖注入等。

• 支持微服务：提供了一套完整的微服务解决方案，包括消息模式、传输策略等。

• 测试工具：提供了一套强大的测试工具，使得单元测试和端到端测试变得简单。

• 与其他库的集成：可以轻松地与其他流行的 JavaScript 库和工具集成，如 TypeORM、Passport.js、GraphQL 等。

在 Nest 框架提供的 IOC 能力基础上，酒店 BFF 研发组构建了专用于支持” 一码多端 “研发场景的 BFF 服务框架，试图通过统一的状态数据管理及策略流程模式支持多端适配能力的开发：

• 提供了标准的开发模板，令多端处理逻辑的开发过程趋向标准化。

• 帮助开发者在编写接口时通过流程的横向拆分和数据组件的模块化提高代码可维护性。

• 通过框架模板的约束，促使开发者在系统设计之初就考虑如何处理一致性与差异性。

具体来说，BFF 层作为前后端中间层主要的作用是调用下游微服务接口并进行请求参数的处理并最终组装出视图模型数据返回给前端，典型的模式是：

【第3268期】AI驱动的前端UI组件生成器（Next.js，GPT4，Langchain和CopilotKit）

当前端请求到达 BFF 之后，BFF 会解析参数并做出数据结构转换来向下游微服务发起请求，获得返回后再重复这一过程。

面对这样的调用链路，非常容易写成面向过程的逻辑代码。通过一个个工具函数不停对入参 / 出参进行处理并传递给后一个下游服务接口。

整个程序控制流通过工具函数及函数传参被耦合在一起，这种模式在” 一码一端 “下由单一团队维护尚能接受，同一批开发人员确保自己端的 BFF 链路不出错即可。

但当多个端团队共同维护 "一码多端"BFF 应用时，针对同一个 BFF 接口服务的不同特性被耦合在一起，将导致团队协作的困境：

1、下游传参不一致：

由于下游领域服务针对各端可能存在特殊逻辑配置，因此给下游的传参因端而异。

这一点通过 IF/ELSE/SWITCH 在 BFF 层面控制差异尚且能够接受，但多个端的 BFF 开发人员需要共同修改同一段分枝逻辑。

2、调用链路不一致：

各端会存在调用时序差异，例如端 A 某接口强依赖获取用户等级，而端 B 某接口仅依赖用户是否登陆，端 C 同时依赖用户登录态和用户等级。

这种程序控制流程的差异相比与参数的差异更难以处理，可能需要更大更复杂的代码块分枝处理来解决，并更容易引起冲突提高协作成本。

3、视图模型不一致：

由于各个端的 BFF 在不同的时间由不同的团队开发维护，各个版本 BFF 的接口契约难免存在差异，当 “一码一端” 合并为 “一码多端” 时，为了视图模型的一致性，必须将（1）（2）中的不一致在 BFF 层处理为一致的视图模型。

良好的代码组织结构和清晰的调用链路带来可读性和可维护性，降低迁移重构过程中的摩擦成本。

【第3311期】微前端架构思考：量化技术选型方案

为了降低 “一码多端” 迁移过程中的协作成本，降低各端分支逻辑之间的耦合性，我们尝试提出一种 BFF 的多端开发模式：

通过多端策略模式将不同端的处理逻辑在接口内进行分流，并将一个接口逻辑内原本对下游的整体链路横向拆分为互不耦合的独立逻辑处理实例，让每一个实例仅需关注自身与下游服务的调用关系。且针对不同端的差异处理可以被文件级的分开，很大程度减少了冲突的发生。基于这个架构，多个端侧团队可以高效安全的进行协同开发。

多个调用下游的逻辑实例可以被并行执行，多个并行阶段可以被串行，数据流最终到达装饰器实例被处理后返回给前端。

在携程酒店某二级页面 BFF 一码多端项目中，采用前文提到的多端架构模式对原本多套 BFF 应用进行了合并及重构，将原本分散的视图控制逻辑整合收口到了一个 BFF 应用内，大幅减少了后续的迭代维护成本，提升了研发效率。原本由多个 BFF 分别来支持多个端，通过多端开发模式重构之后，多个 BFF 合并成为一个，内部通过多端策略实例来支持各端。原本的过程化代码被横向解耦并拆分成可复用的数据组件被这多个策略分别组合调用，最后再通过视图模型变化映射成统一的视图模型返回给各端。

在应用代码重构的同时，携程酒店 BFF 团队与携程公共平台团队合作，在他们的支持与帮助下实现了 BFF 的云函数化。

三、云函数平台

携程 Node.js 云函数平台从 2021 年正式立项已开始第四个年头。俱备轻量化的运行时，中间件能力及其他丰富的函数中间件接入能力。