关于前端:如何在中后台领域玩转BFF架构

79次阅读

共计 3554 个字符,预计需要花费 9 分钟才能阅读完成。

本次分享次要从业务背景、BFF 外围架构、基于 Serverless 的 BFF 革新、总结四个局部组成。

业务背景

咱们的供应链场景有很多供应商,每个供应商都有物流、资产、仓储等多个域,而这些域咱们的后端都基于 DDD 畛域模型做了微服务化,此时前端在开发面向这些供应商应用的中后盾利用时,遇到了以下问题:

页面显示须要申请多个域:比方一个商家的详情页,可能既须要申请仓储数据,还须要申请资产数据,能力将一个页面显示进去。

接口格局不满足前端需要:后端微服务化后,是面向多我的项目,通用性的,其接口格局不肯定能满足前端需要,前端须要本人做转换,比方单位转换,字段裁减。

需要变动快:业务在疾速迭代,须要接口的大量反对,而咱们的后端域是面向多我的项目的,更改老本较大,须要投入更多的测试,此时如果在前端和后端两头存在一个中间层,来做这些事件,那么效率会有比拟好的进步。

部门合作老本大:有些需要须要其它部门的后端同学反对,而其它部门的同学因为本人部门的需要缓和,排期较满,导致咱们的需要迟迟无奈排期,此时如果存在一个中间层,在中间层去申请其它部门提供的畛域服务来组合数据提供给前端,此时就能够在其它部门同学不参加的状况下,前端本人实现需要开发,部门之间的合作老本会大大降低。

基于以上背景,前端这边引入了 BFF 架构,BFF 架构能做哪些事件:

业务编排:从后端域多接口获取数据合并输入给页面。比方一个商家详情页即须要仓储数据,也须要资产数据,此时咱们在 BFF 层将仓储和资产数据申请回来组装吐给前端。

字段转换:字段过滤、数据格式化等工作。比方资产域的商户名字段叫 businessName,而仓储域的商户名字段叫 shopName,此时能够在 BFF 层对立掉,这样前端就不须要做判断了。

个性化数据:为前端提供个性化服务,如数据压缩,单位转换等。

BFF 外围架构

外围架构

以上是 BFF 的外围架构图,前端即中后盾利用,后端域即后端服务,右侧的工具撑持是公司的一些根底公共服务,两头的就是 BFF 外围实现,咱们从上往下看:

  • 业务:能够在这一层做业务编排,字段转换,共性定制等业务逻辑,同时提供了一个 node-auth 包,能够利用该包做用户鉴权。
  • 根底框架:根底框架这层,次要封装了 node-soa 这个 npm 包,node-soa 外面蕴含了 node-log 日志工具、node-hook 代码规定校验工具、node-zk 集群链接工具等。
  • Node 框架:Node 框架这块选型的是 Koa2。

调用链路

外围架构讲完后,在看下整个 BFF 架构的调用链路:

调用链路从上往下,咱们的中后盾利用通过 HTTP 申请到 Nginx 服务器上,Nginx 转发到 BFF 层,BFF 层通过 RPC 调用后端域的微服务,实现整个调用过程。

这里有两个概念须要阐明下:

ZooKeeper:可简略了解为服务注册核心,后端的各个微服务都对立注册到这个注册核心,而后 BFF 层充当 ZooKeeper Client 去连贯这个注册核心,连贯后,就能够枚举到注册核心每个服务的 Host 和 Port,拿到 Host 和 Port 就能够发动 RPC 调用了。

RPC:近程过程调用,也就是说两台服务器 A、B,一个部署在 A 服务器上的利用须要拜访 B 服务器上的一个利用的某个办法,因为不在一个内存空间,因而须要通过网络来表白调用的语义和传播的数据,能够简略了解为 A 服务器上部署了咱们的 BFF 利用,B 服务器上部署了咱们的微服务。RPC 通信协议可基于 HTTP 或者 TCP 协定,咱们采纳的是 gRPC,即应用 HTTP/ 2 的一种 RPC 调用形式。

以上介绍了 BFF 的外围架构和整个调用链路,上面来看看 node-soa 的具体实现细节。

服务初始化

通过调用 node-soa 提供的 init 办法来实现服务的初始化,其中 dep 即为各后端域的微服务。

咱们在看看 init 的具体实现:

首先创立了一个 ZooKeeper Client 去连贯 ZooKeeper 集群,连贯上当前通过 listChildren 办法枚举 ZooKeeper 集群的所有子节点,拿到子节点的 Host 和 Port 后创立了一个 grpcClient,之后就能够通过这个 grpcClient 发动 RPC 调用了。

服务调用

服务初始化后就能够发动 RPC 调用了,node-soa 提供了 request 办法,通过这个办法即可发动 RPC 调用,其中 service 就是后端域,method 即为 java 侧提供的办法。

咱们在看看 request 外面的具体实现:

通过服务初始时创立的 grpcClient 发动 RPC 调用,拿到数据后 resolve 回去,即实现一次 RPC 调用,在整个 RPC 调用过程中利用 Jaeger+OpenTracing 做了调用链路的追踪,利用 node-log 做了申请日志的落盘。

以上即为咱们第一代 BFF 架构的核心内容,这套架构在过后的业务背景下是一个比拟好的解决方案,但随着业务的疾速倒退,这个架构也遇到了一些问题:

  • 运维老本增大:随着 BFF 利用的增多,须要更多的机器来部署 BFF 利用。
  • 公布流程长:新增一个 BFF 的接口,须要走完编译,构建,部署一整套流程,无奈做到秒级部署。
  • 域名不收敛:每个 BFF 都有各自独立的域名,减少记忆老本。

鉴于这些痛点,咱们引入了 SFF(Serverless For Frontend)架构,通过将 BFF 构建于 Serverless 之上,用云函数的形式取代传统基于 NodeJS 的 BFF 层。

基于 Serverless 的 BFF 革新

SFF 架构

上图是革新后的 BFF 架构,相比于一代的 BFF 架构,这里次要多了两块内容,一块是 FaaS 层,另外一块是开发者平台。

  • 开发者平台是在线编写云函数的,次要提供了函数治理、公布治理等性能,公布的每个函数都会保留在数据库中。
  • FaaS 层次要就是一个个 Function,一个 BFF 接口申请过去,首先会去数据库获取对应的函数,而后执行该函数。

实现计划选型

目前支流的计划次要是基于容器和基于过程两种形式。

容器计划:根本实现是利用 K8s + Docker, 每个云函数执行的时候都启动一个容器去执行,执行完后容器销毁,整个容器的治理、并发解决、扩缩容都是用 K8s 来治理。

过程计划:每个云函数的执行都启动一个新的过程去执行,执行完后过程销毁。

对于实现计划的选型,咱们须要思考以下几个方面:

  • 业务场景复杂性:高并发采纳容器计划更好;并发少,选用过程更轻量,也更容易实现。
  • 基建 & 运维能力:容器计划对基建和运维能力有更高的要求,要思考公司的运维能不能 Cover 住。
  • 团队人力 / 能力:基于容器计划技术上的要求会更高一些,实现难度也会更大一点,要思考团队的小伙伴这方面的教训有没有,团队的人手够不够。

咱们的业务并不简单,中后盾利用简直没有高并发,目前公司对于容器的应用还没有大推,团队人手也不是很够,加上短少容器这方面的实战经验,最终采纳了基于过程的形式来实现。

实现

根本的实现如下:

用户发动 HTTP 申请,Node 主过程去数据库读取该申请的函数实现,拿到函数实现后会 Fork 一个子过程执行函数,函数执行完后子过程销毁。这里须要留神的一点是管制子过程的执行工夫,避免因为函数执行异样,导致子过程无奈销毁。

咱们在看下执行函数的具体实现:

通过 VM2 模块来执行咱们的云函数,从而保障子过程和主过程之间的 Context 隔离,如果不进行隔离,有可能呈现的一种状况是,子过程外面如果调用了 process.exit(),此时咱们的 Node 主过程就会被退出去。

做了过程的 Context 隔离还不够,咱们能够利用过程池来优化每次 Fork 子过程的工夫,利用 CGroup 来限度子过程的 CPU 使用率、内存占用、磁盘 IO 等。CGroup 是 Linux 内核中的一个外围能力,提供了将不同过程按分组进行治理的能力,并且能对不同的分组限度其所应用的计算资源(CPU、内存、磁盘 IO 等),咱们能够通过限度用来执行函数的子过程所能耗费的最大内存、磁盘及网络带宽,同时管制过程所能应用的最大 CPU 占用率等形式来保证系统的稳定性。

最终的实现如下:

以上就是基于 Serverless 的 BFF 革新的核心内容,相比于一代的 BFF 架构,基于 Serverless 的 BFF 革新有以下几点劣势:

  • 效率晋升:独立云函数,动静编写,秒级部署。
  • 降本:利用收敛,无效升高运维、机器老本。

总结

以上就是本次分享的次要内容,咱们做下总结:

  • 后端畛域微服务化后,须要一套能提供业务编排、字段转换、共性定制的机制来保障业务的疾速迭代。
  • BFF 架构可能无效的做到业务编排、字段转换、共性定制,且让前端进入全栈畛域。
  • 构建于 Serverless 之上的 BFF 进一步的升高了运维、机器老本,进步了人效。

(本文作者:赵存)

本文系哈啰技术团队出品,未经许可,不得进行商业性转载或者应用。非商业目标转载或应用本文内容,敬请注明“内容转载自哈啰技术团队”。

正文完
 0