基础扫盲
BFF——服务于前端的后端
微服务时代
客户端与微服务交互成为了新的考量。应对微服务的方案很多：
- API Gateway：前端请求通过后端 api 网关进行分发
- 弊端：如果数据粒度很细，前后端沟通频繁就会造成微服务之间调度频繁，违背了微服务的本质即清晰的界限上下文，某些场景下会使领域建模变得较为复杂
- CORS：前端跨域请求，分别向不同微服务发出请求，再将回调数据在 Flux 层处理后反映在 DOM 上
- 原理：前端分层和建模，后端提供一些粗粒度的 api，交由前端处理和整合数据
- 弊端：传输负载可能会变大；多平台开发时需要重新组织数据，略显冗余
更优雅的解决方案 BFF
即将组装、聚合、裁剪这部分业务单独拎出来，组成一个叫 Back-end for Front-end 的中间层
BFF 优缺点
- 优点
- 前后端彻底分离，后面即使后端微服务迁移，也不需要改前端代码
- 业务向前靠拢，接口聚合数据重构由前端来做，更适配前端框架
- 自开 Mock，可生成 Api 文档
- 后端服务边界更清晰，只需开发粗粒度接口即可
- 缺点
- 中间层转发会增加延迟
- 必须保证端到端测试
- 需要处理后端异常
- BFF 分层会增加开发成本
Severless
前端开发模式演进
- 基于模板渲染的动态页面
- JSP: Java Server Page: Java服务端页面，在html页面中编写Java代码的页面
- WebServer：网站服务器或web服务器
- 基于 AJAX 的前后端分离
- 网页的复杂度也由后端的 Web Server 转向了浏览器端的 JavaScript
- 基于 Node.js 的前端工程化
- 基于 Node.js 的全栈开发
- 背景：后端由
巨石应用模式向微服务架构转变- 巨石应用模式：大部分web工程是将所有的功能模块(service side)打包到一起并放在一个web容器中运行，很多企业的Java应用程序打包为war包
- 微服务架构：微服务架构是一种架构理念，是指将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。把一个大型的单体应用程序和服务拆分为数个或数十个的微小型服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议
- 背景：后端由
CNCF：云原生计算基金会
IaaS：Infrastructure as a Service，基础架构即服务
PaaS：Platform as a Service，平台即服务
SaaS：Software as a Service，软件即服务
Docker：一个提供服务的平台，任何一台装有 Docker 的机器都可以建立、发布、运行应用程序
Kubernetes：一套成熟的商用服务编排解决方案，定位在Paas层，解决了微服务大规模部署时的服务编排问题
感知 Serverless：CDN、对象存储、第三方 API
定义解读：从技术角度来说，Serverless 就是 FaaS 和 BaaS 的结合
- Faas：Function as a Service，运行函数的平台，比如阿里云的函数计算、AWS 的 Lambda 等
- BaaS：后端云服务，比如云数据库、云存储、对象存储、消息队列等。利用 BaaS，可以简化应用开发难度
- 以上，可以理解为 Serverless 就是运行在云平台上的云服务（运行在 FaaS 中，使用了 BaaS 的函数）
Serverless 特点
- 事件驱动：函数运行在 FaaS 云平台中，需要通过事件驱动函数执行
- 无状态：函数每次运行，使用的都可能是不同的容器，无法进行内存和数据共享，如果要共享数据，只能使用第三方服务，比如 Redis
- Redis：Remote Dictionary Server，远程字典服务，开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value 数据库
- 无运维：使用 Serverless 不需要关心服务器，也不需要关心运维
- 低成本：只需为每次函数的运行付费，不运行就不花钱，不会浪费服务器资源
如上，基于 Serverless，后端变得非常简单了，以往的后端应用被拆分为一个个函数，只需要写完函数并部署到 Serverless 服务即可，后续也不用关心任何服务器的运维操作
Serverless 价值**
- 降低运营复杂度：无需提前规划服务器的数量和规格，无需持续监控和维护具体服务器的状态
- 降低运营成本：服务器不再是受管资源，投入的时间和人力将大大降低
- 缩短开发周期：Serverless下，应用的功能被解构成若干个细颗粒度的无状态函数，功能边界清晰，耦合低
传统 BFF 架构
- 微服务导致前端接口调用复杂，因此使用 BFF 对接口进行聚合裁剪
- 底层是后端微服务，上层是前端应用，中间是前端开发的 BFF
传统 BFF 痛点：以往前端只需开发页面即可，现在还要维护 BFF 应用，关注 BFF 并发压力，而前端不擅长
解决方案：使用 Serverless，用函数是实现接口聚合裁剪。前端向 BFF 发起的请求，就相当于是 FaaS 的一个 HTTP 触发器，触发一个函数的执行，这个函数中来实现针对该请求的业务逻辑，比如调用多个微服务获取数据，然后再将处理结果返回给前端。这样运维的压力，就由以往的 BFF Server 转向了 FaaS 服务，前端再也不用关心服务器了
基于 Serverless 的 BFF 架构
为了更好的管理各种 API，我们还可以添加 API 网关（API Gateway）管理 API，比如对 API 进行分组、分环境；基于网关层，前端无需通过 HTTP 触发器来执行函数，而是将请求发送至网关，由网关触发具体函数执行
- 无 API 网关：需调用方自己组合各种服务，能明显感知到后端各种服务存在，需要做很多相同工作
- 有 API 网关：网关层可以做路由，安全，限流，缓存，日志，监控，重试，熔断等，服务层可脱离这些纯粹做业务，不用关心安全、压力等
传统服务端渲染
三大前端框架客户端渲染由一个简单的 html、js 文件开始，存在白屏时间和 SEO 优化问题。为解决该问题，延伸出了服务端渲染，即基于 React、Vue 等实现的同构应用。思想与早期的模板渲染（JSJP、PHP）是一样的。带来问题是运维成本，前端需要维护用于渲染的服务器
基于 Serverless 的服务端渲染
- 谨记：Serverless 的最大优点就是帮助我们减少运维
- 传统服务端渲染，请求 path 对应每个服务端路由，匹配返回渲染模板，用于渲染的服务端程序，就是集成了这些路由的应用
- 基于 Serverless 的服务端渲染：就是将以往的每个路由拆分成一个个函数，并部署到 FaaS，这样请求的 path 就是对应单独的函数。这种方式就将运维操作转移到了 FaaS 平台，前端做服务端渲染，就不用再关心服务端程序的运维部署了
如上，底层是复杂业务的后端微服务，中间是 FaaS 云平台，上层是前端应用。FaaS 通过一系列函数为前端提供服务，同时前端、后端、FaaS 都可以调用后端云服务 BaaS，大大降低开发难度、减少开发成本
Serverless：无运维，释放了运维压力，将其转移到云平台上，降低了开发周期和成本，让开发更专注于业务，让前端能做的事更多，让后端颗粒度更细，只需要写完函数并部署到 Serverless 服务即可，也无需关注运维
如何 60 分钟交付小程序 + web（基于云开发搭建 Serverless 应用）
借助云开发的 Serverless 框架，可以直接进入开发，无需运维，提升开发效率
web：借助云开发 SDK 连接到应用层
小程序云开发
- 开发者工具开通云开发并创建数据库集合
- 本地项目目录 cloud/functions/XXX 创建云函数（在云开发环境执行的一段代码）入口
- 云函数 XXX 上传并部署，云端安装依赖
web/flutter 如何部署云函数
- 根目录创建 cloudbaserc.js，通过命令行 cloudbase 部署
- 插件部署
云函数多端支持：小程序、web、flutter
腾讯云也可进行静态网站托管：编译好的文件直接部署
云开发：cloudbase，采用 Serverless 架构，提供云函数、云数据库、云存储等基础资源服务，免环境搭建等运维事务 ，同时提供静态托管、命令行工具（CLI）、 VS Code 插件，Flutter SDK等能力，极大降低应用开发门槛，助力快速构建小程序、Web 应用和 App
如何在中后台场景设计与落地 Serverless
中后台场景现状
- 流程繁琐：申请应用 => 申请环境 => 创建仓库 => 申请域名 => 统一接入 => 开发部署 => 上线
- 成本高：前端开发者需要承担大量运维工作，且上线后每秒访问次数少
接入层，即网关，匹配不同 path，然后 trigger 到函数
中后台常见场景，复杂性在于函数自身要实现多层业务逻辑；偏业务场景的 BFF，维护模型的逻辑不应该由函数本身承担
如何借助 Serverless 从前端走向全栈
Serverless 根基：算力、算法、数据
无服务器云计算（Serverless Computing）几乎封装了所有的底层资源管理和系统运维工作，使开发人员更容易使用云基础设施。 它提供了一个方式，极大地简化了基于云服务的编程，犹如汇编语言到高级编程语言般的转换。
IaaS：基础设施即服务；PaaS：平台即服务；SaaS：软件即服务
发展史：物理机 => 虚拟机 => 容器 => 函数
云计算：解决算力合理分配的问题
FaaS 是一个以“业务执行”为粒度的“算力”分配方式（算力分配平台 ）
Serverless：是对全部底层资源和操作的封装，让开发者专注于业务逻辑
前端该怎么走：把手中的事做好；做更多的事
如何基于云函数+BaaS 无缝开发应用
三步上云
- 安装：安装 serverless framework，以 egg 为例，初始化一个 egg
- 配置：配置 YML
- 部署：部署到腾讯云
Serverless：对服务器、容器、资源、网关、数据库的封装，单纯的 FaaS 称不上 serverless，他必须结合触发器或者 BaaS 才可能发挥作用
如何用函数框架快速开发大型 Web 应用 + 实战
Serverless 应用场景：静态网站托管、构建 RESTful API、部署全栈应用
云平台：各家云厂商，商业化部署 FaaS 函数的平台，函数最后承载的平台，现在主要指阿里云 FC 与腾讯云 SCF 两大平台
触发器：也叫 Event（事件），Trigger 等，特指触发函数的方式
- 最常见的触发器就是 http、rpc、api 网关和 timer、云存储等
- 云函数根据请求自动调度基础设施资源实现弹性伸缩，提高计算效率
函数：即代码片段，通过入口文件包裹，但一链路且无状态
- .yml 文件中定义函数名称和函数路径
如何设计闲鱼前端 Faas 框架与通信方案
传统 MVVM 存在什么问题
- 重端侧的研发模式，技术栈迁移、适配成本高
- 定制化的接口，前端无编排能力，前端数据加工成本高
领域模型层是面向具体业务域问题进行的抽象设计，而端侧是面向 UI 展示或特定业务而进行的设计；即领域层下发的数据可能在端侧是不需要的
若有收获，就点个赞吧
0 人点赞
