架构设计：BFF和Serverless简介

一、BFF

　　在聊Serverless之前跟大家先谈谈BFF，BFF顾名思义就是Backend For Frontend，用中文解释就是服务于前端的后端，那么为什么会有BFF？

　　在项目开发中，前后端分配的问题

　　“你自己请求2个接口再组装不就行了吗” - 后端同学

　　“少一次http请求啊，加一个接口有那么难吗” - 前端同学

　　前端同学和后端同学都各有各的道理，有没有一种解决方案可以化解这种尴尬的场景，于是就有了BFF

1、介绍

　　BFF层初衷是在后台服务与前端（客户端）之间添加一层，接下来我们来看看下面这张图

2、BFF到底发挥什么作用

　　答案是：用户体验适配层和API聚合层 : 主要负责快速跟进 UI 迭代，对后端接口服务进行组合、处理，对数据进行：裁剪、格式化、聚合等

　　在BFF层下面是各种后端微服务，在BFF上层则是各种前端应用（多端应用），向下调用后端为服务，向上给客户端提供接口服务，后端为BFF层的前端提供的 RPC 接口， BFF 层则直接调用服务端 RPC 接口拿到数据，按需加工数据，来完成整个BFF的闭环（以Node+GraphQL技术栈为主）

3、BFF层谁来开发

　　遵循服务自治，谁使用谁开发的原则，也就意味着只能由前端同学来挑起这个重任，同时离“全栈工程师”又进一步了。

4、api网关

　　BFF和网关Gateway都是微服务架构中的重要的两个概念，看下图简单的例子

　　分享一下蚂蚁金服体验技术部负责人玉伯，曾说的一句话：“BFF 模式不仅仅是一种技术架构，从社会分工角度讲，BFF 更是一种多元价值导向的分层架构

5、BFF的优势

　　主要有以下几点优势：

（1）可以降低沟通成本：后端同学追求解耦，希望客户端应用和内部微服务不耦合，通过引入BFF这中间层，使得两边可以独立变化

（2）多端应用适配：展示不同的（或更少量的）数据，比如PC端页面设计的API需要支持移动端，发现现有接口从设计到实现都与桌面UI展示需求强相关，无法简单适应移动端的展示需求 ，就好比PC端一个新闻推荐接口，接口字段PC端都需要，而移动端呢H5不需要，这个时候根据不同终端在BFF层做调整，同时也可以进行不同的（或更少的）API调用（聚合）来减少http请求

　　当你在设计 API 时，会因为不同终端存在不同的区分，它们对服务端提供的 API 访问也各有其特点，需要做一些区别处理。这个时候如果考虑在原有的接口上进行修改，会因为修改导致耦合，破坏其单一的职责。

6、BFF的痛点

（1）重复开发：每个设备开发一个 BFF 应用，也会面临一些重复开发的问题展示，增加开发成本

（2）维护问题：需要维护各种 BFF 应用。以往前端也不需要关心并发，现在并发压力却集中到了 BFF 上

（3）链路复杂：流程变得繁琐，BFF引入后，要同时走前端、服务端的研发流程，多端发布、互相依赖，导致流程繁琐

（4）浪费资源: BFF层多了，资源占用就成了问题，会浪费资源，除非有弹性伸缩扩容

　　总结BFF分层下“幸福的烦恼”：研发成本上升、流程繁琐、运维经验不足

7、有什么方案可以解决传统BFF痛点

　　包括解决前端需要关心应用的负载均衡、备份冗灾、监控报警等一些列运维部署的操作

　　如何统一管理和运维，提高发布速度、降低运维成本

　　答案是：Serverless

二、Serverless

　　我们可以将 Serverless 拆解为 server 和 less 两个单词，从字面上推断词意即为“少服务器的，亦或是无服务器的，弱化后端和运维概念，当前比较成熟的 Serverless 云产品主要有 Amazon Lambda、Google Cloud Function、Azure Function、AliCloud Function Compute、Tencent CloudBase等

　　Serverless 的演变

1、什么是Serverless

　　Serverless = Faas (Function as a service) + Baas (Backend as a service)

2、云函数（Faas）

　　FaaS（Function-as-a-Service）是服务商提供一个平台、提供给用户开发、运行管理这些函数的功能，而无需搭建和维护基础框架，是一种事件驱动由消息触发的函数服务

　　前端同学调用Faas服务如同调用本地函数一样简洁，如下所示，是一个腾讯云中一个简单的小程序云开发demo，cloudfunction是用来定义云函数的方法

3、后端即服务（ BaaS）

　　BaaS（Backend-as-a-Service）后端即服务，包含了后端服务组件，它是基于 API 的第三方服务，用于实现应用程序中的核心功能，包含常用的数据库、对象存储、消息队列、日志服务等等。

　　比如腾讯云云开发中下面的这些服务：

• 微信小程序的云调用 wx-server-sdk

• 云开发数据库 wx.cloud.database

4、Serverless的架构

5、Serverless的优势

• 环境统一: 不需要搭建服务端环境,, 保持各个机器环境一致 Serverless 的机制天然可复制
• 按需计费: 我们只在代码运行的时候付费，没有未使用资源浪费的问题
• 丰富的SDK: 有完善的配套服务, 如云数据库, 云存储, 云消息队列, 云音视频和云 AI 服务等
• 弹性伸缩: 不需要预估流量, 关心资源利用率, 备份容灾, 扩容机器 ，可以根据流量动态提前峰值流量

6、Serverless的缺点

• 云厂商强绑定：它们常常会和厂商的其他云产品相绑定，如对象存储、消息队列等，意味你需要同时开通其他的服务，迁移成本高，如果想迁移基本原有的逻辑不可服用，kennel需要重构
• 不适合长时间任务：云函数平台会限制函数执行时间，如阿里云 Function Compute 最大执行时长为 10 min
• 冷启动时间：函数运行时，执行容器和环境需要一定的时间，对 HTTP 请求来讲，可能会带来响应时延的增加
• 调试与测试：开发者需要不断调整代码，打印日志，并提交到函数平台运行测试，会带来开发成本和产生费用

7、Serverless的应用场景

（1）场景1: 负载有波峰波谷

　　波峰波谷时，机器资源要按照峰值需求预，比如医院挂号这需求，假设在每天10点放号预约，那10点就会有峰值的出现，为了这个峰值并发的考虑，准备了相对应性能（固定）的服务器，然而在波谷时机器利用率又明显下降，不能进行资源复用导致浪费，而serverless不用为了波峰去做准备，不用留住水位，支持弹性缩扩容，在你高峰时再在进行动态扩容

（2）场景2: 定时任务（报表统计等）

　　服务空闲时间来处理批量数据，来生成数据报表，通过Serverless方式，不用额外购买利用率并不高的处理资源，比如每日的凌晨，分析前一天收集的数据并生成报告

（3）场景3: 小程序开发（云开发）

　　比如微信小程序开发m在实际开发中，如果我们不用云开发的openid获取流程，而用传统的方式，你就知道openid的获取是非常繁琐的一个过程，前端需要通过wx.login获取一个code值（具有时效性）再通过code值去后台用appsecret去调取openid。

　　而云函数由于是部署在腾讯云的关系，腾讯云将云调用将鉴权部分有效的封装，让你的接口很容易的实现了鉴权保护，无需维护复杂的鉴权机制，从而让个人开发者和小团队可以更容易地开发小程序