又到周五了有了一个小时的闲暇时间简单写点东西，介绍一个简单的BFF的架构。BFF:Backends For Frontends,其实现在是个比较常见的前端架构设计的方案，其最大的优势便在于前端可以高度自由的在Node层做一些server端才可以做的东西，比如SSR、登录态校验、对接服务端各微服务应用等。今天介绍一种简单的设计方案。
技术背景
新建的系统需要对接集团的用户系统、权限系统以及多方业务的RPC服务端，业务属性原因Client端更新频率远高于Server端，且本地环境不可用（依赖服务的数据链路不通），只能依赖预发环境，预发环境与本地环境是隔离的（本地环境无法直接调用预发环境的RPC接口）。
架构图
技术设计
Demo代码
首先由于需要主动调用多方RPC服务，便采用Node层作为聚合，对Client端提供http接口；因为Node端与Client端更新频率不同，为了提高部署效率，采用了两端分离的设计，分成了两个Project，Client端发布生成CDN资源，然后由Node端提供Controller层代码生成主文档模板，同时引入Client端CDN资源。类似代码如下：
import { Context } from 'egg';
import { Controller, Get, Provide, Priority, Inject } from '@midwayjs/decorator';@Provide()
@Priority(-1) // 降低匹配路由优先级，相当于router放在最后
@Controller('/')
export class HomeController {@Inject()ctx: Context;@Get('/*')async home() {const env =this.ctx.cookies?.get('x-env', { signed: false }) || this.ctx.aliEnv;this.ctx.logger.info(`env: ${env}`);// 远端持久化配置服务获取版本const {version} = await this.mockService.getConfig();const publicPath = {mockLocal: 'https://127.0.0.1:8000/',local: 'http://127.0.0.1:8000/',dev: `https://dev.g.alicdn.com/xxx/${version}/dist/`,pre: `https://dev.g.alicdn.com/xxx/${version}/dist/`,prod: `https://g.alicdn.com/xxx/${version}/dist/`,};return `<!DOCTYPE html><html lang="en"><head><meta charset="UTF-8"><meta name="viewport" content="width=device-width, initial-scale=1.0"><title>Document</title><link rel="stylesheet" href="${publicPath[env]}umi.css" /><script>window.routerBase = "/";</script><script>window.publicPath = window.resourceBaseUrl || "${publicPath[env]}";try {window.__CONFIG__ = {user: ${JSON.stringify(this.ctx.user)},env: '${this.ctx.aliEnv}',clientEnv: '${env}',};} catch (e) {console.error('=== 初始化数据失败(window.__CONFIG__) ===', e);}</script></head><body><div id="root"></div><script src="${publicPath[env]}umi.js"></script></body></html>`}
}
Client版本控制
不同环境CDN路径不同，通过环境来区分配置，因为CDN资源不存在回归能力，所以将CDN资源发布时打上版本号路径，同时引入了第三方持久化配置服务，来配置不同环境的CDN版本号来实现Client资源的版本化控制部署。
本地开发代理&线上问题复现
由于本地环境数据链路不通，因此日常开发调试都需要使用预发环境，为了方便开发，支持通过手动种植指定标识的cookie来mock对应环境来实现本地Client资源的引用，同时也可以用于排查线上Client问题。说到这里可能有很多人没注意，这里有一个隐藏技巧，那就是我们的系统往往预发或者生产访问地址协议时https的，而本地资源是http的，很多人第一反应就是 ，https的页面不能访问http的资源，但是其实是localhost和127.0.0.1除外 ，chrome认为localhost或者127.0.0.1是本机，是可以被信赖的
当然也可以通过本地配置类似代理的方式，将本地的http请求代理到预发环境，但是设计代理工具的配置、登录态token域名及跨域问题等，相对会繁琐一些也可以支持。
![[云原生] k8s之存储卷](https://img-blog.csdnimg.cn/direct/896b564be187492e890acb718b6fa03d.png)
