BFF实践想法 2022-12-17

简介

很早就接触过BFF，也知道这个概念，也很想实践一番。
只是事不随人愿，目前这一些还都停留在想法阶段。
首先要熟悉后台技术，比如Java；其次至少需要达到中级管理。这是架构层面的事，不是个人做个demo的事。
浏览网页，看到了一篇好文章，感觉和我们遇到的实际情况类似，所以深有同感。
微服务架构中的BFF到底是啥？

现状

公司也是做电商的，一开始只有网页，后来加了APP，和文章中提到的V2很像。

image.png

• 现有网站，后有APP，所以APP都直接使用和网站一样的接口。略有差异的，也是在原有的接口基础上增加几个字段。

• APP界面和交换重新设计，但是业务逻辑尽量和PC保持一致。遇到问题，客服也会引导客户到PC解决。所以，当前阶段，APP可以看做是PC在手机上的一个替身。

• 接口有大量不需要的字段，早成流量浪费，减慢速度。

• 接口数据不适合页面，需要进行大量的显示逻辑变换。

• 一方面是大量不需要的字段，另一方面又缺失很多字段，需要额外多连几个接口才能达到目的。

• 重复内容太多，比如多语言，PC和手机端都要重复定义一遍。

• 精简字段，显示逻辑，接口聚合；等等，这几点，正是BFF可以完成的事。

目标架构

微服务架构中的BFF到底是啥？提到的V4就是非常合理的一个架构。

image.png

• 微服务专注于领域逻辑，按照后台技术潮流发展，做具体的业务就好。

• BFF层本身也应该分为两层，公共部分尽量下沉，抽象出一个common BFF出来。然后在其上根据各种终端特点，分出相互隔离的独立BFF。

• 网关层一般做安全验证，流量控制，数据统计等跟具体业务无关的事情。

• 具体的客户端，专注于用户界面。应该遵循极简原则，数据和逻辑尽量放后台

大前端思路

• 常见的就是技术思路，比如ionic，RN，weeks，Flutter等等。这些技术，要成熟，要形成趋势，非大公司不可。作为普通人，只能顺应潮流，采取主流技术，很难引领潮流。

• 另外一个思路就是内容下沉。iOS和Android手机，都是从Linux发展而来的，所以C语音都是支持的。所以，可以考虑用C来写iOS和Android手机通用的模块。比如游戏框架，就是这个思路。不过C语言表达能力弱，用来实现具体业务，效率太差。实际采用这个方案的很少。

• 另外一个思路就是BFF，iOS和Android手机都使用一个后台，所以，把很多显示逻辑移到后台之后，客观上起到了跨平台的作用。

• 热更新：就像RN，一个很大的卖点就是热更新。相同地，BFF天然具有动态更新的功能。把重复代码从客户端移到BFF，在让客户端瘦身的同时，也带来了热更新的便利。

落地选择

• BFF一个纠结的地方就是BFF这一层，是交给前端团队还是交给后端团队。这里涉及到技术框架的选型。比如，交给前端团队负责，那么就会采用类似Node.js之类的；交给后端团队，那么就会直接采用Java。

• 交给前端团队的理由很充分：BFF是前端显示逻辑，也是为前端服务的，所以前端团队负责，更有针对性。

• 交给后端团队负责也是有道理的：既然是后端，理所当然让后端的团队负责。另外，BFF是运行在服务端的，用后端技术实现更方便。

• 怎么选？既然都有道理，那么就各取一半。由前端团队负责，采用后端技术，比如Java。后端出几个技术专家参与支持，前端人人都学用Java等后端技术。

重复代码

• 对于后端来说，架构更加重要，一定的重复代码是可以接受的。

• 直通代码：就算字段没改，也不应该跳过环节。架构流程重于局部代码。直通只是暂时的，怎么知道以后字段不会变？

把Mock数据写在后台

• 在很多客户端技术中，Mock数据都是很重要的一环。但是实际使用下来，各种Mock技术，作用不大，麻烦不少，真正用起来的不多。

• 开发环境在实际中用的也比较少。所以，可以考虑把Mock数据写在开发环境的BFF中。写在客户端的Mock数据就是Mock数据。但是，写在BFF中的Mock数据，对于客户端来说就是实际可用的程序。

• 客户端的Mock数据一般由开发写死在代码中，但是BFF中的Mock数据，可以让测试写在配置文件或者数据库中。这样，就可以把冒烟用例转化为BFF层的Mock数据，让开发到测试的交付过程更加清晰可控。

• 前端开发提前到设计阶段，后台数据全部由BFF的Mock数据提供。这样的话，可以提前用上实际可用的程序。当感觉差不多了，后台业务再跟上，部署到测试环境成为正式版本。这期间，可以省略N多次的变更，减轻后台业务开发的压力。