在聊Serverless之前跟大家先谈谈BFF，BFF顾名思义就是 Backend For Frontend ,用中文解释就是服务于前端的后端，那么为什么会有BFF？
前端同学和后端同学都各有各的道理，有没有一种解决方案可以化解这种尴尬的场景，于是就有了BFF
1.1 介绍
BFF层初衷是在后台服务与前端（客户端）之间添加一层，接下来我们来看看下面这张图
:boy:啊宽同学提问：那BFF到底发挥什么作用？
答案是： 用户体验适配层和API聚合层 : 主要负责快速跟进 UI 迭代，对后 端接口服务进行组合、处理，对数据进行：裁剪、格式化、聚合等
在BFF层下面是各种后端微服务，在BFF上层则是各种前端应用（多端应用），向下调用后端为服务，向上给客户端提供接口服务，后端为BFF层的前端提供的的 RPC 接口， BFF 层则直接调用服务端 RPC 接口拿到数据，按需加工数据，来完成整个BFF的闭环（以Node GraphQL技术栈为主）
:girl:啊呆同学提问：那BFF层谁来开发？
遵循服务自治，谁使用谁开发的原则，也就意味着只能由前端同学来挑起这个重任，同时着离“全栈工程师”又进一步了。不知道 ♂️ 是应该庆幸还是苦恼咯
BFF是否可以由后端来做？当然可以，只是说带来新的问题，就总是包接口，会导致个人能力提升受限
:ok_woman:啊宇同学提问：你是不是漏了api网关？
这个问题好 BFF和网关Gateway都是微服务架构中的重要的两个概念,看下图简单的例子 :point_down:
分享一下蚂蚁金服体验技术部负责人玉伯，曾说的一句话：“BFF 模式不仅仅是一种技术架构，从社会分工角度讲，BFF 更是一种多元价值导向的分层架构”
1.2 BFF的优势
主要有以下几点优势:point_down:
- 可以降低沟通成本：后端同学追求解耦，希望客户端应用和内部微服务不耦合，通过引入BFF这中间层，使得两边可以独立变化
- 多端应用适配：展示不同的（或更少量的）数据，比如PC端页面设计的API需要支持移动端，发现现有接口从设计到实现都与桌面UI展示需求强相关，无法简单适应移动端的展示需求 ，就好比PC端一个新闻推荐接口，接口字段PC端都需要，而移动端呢H5不需要，这个时候根据不同终端在BFF层做调整，同时也可以进行不同的（或更少的）API调用（聚合）来减少http请求
总结：当你在设计 API 时，会因为不同终端存在不同的区分，它们对服务端提供的 API 访问也各有其特点，需要做一些区别处理。这个时候如果考虑在原有的接口上进行修改，会因为修改导致耦合，破坏其单一的职责。
1.3 BFF的痛点
- 重复开发：每个设备开发一个 BFF 应用，也会面临一些重复开发的问题展示，增加开发成本
- 维护问题：需要维护各种 BFF 应用。以往前端也不需要关心并发，现在并发压力却集中到了 BFF 上
- 链路复杂：流程变得繁琐，BFF引入后，要同时走前端、服务端的研发流程，多端发布、互相依赖，导致流程繁琐
- 浪费资源: BFF层多了，资源占用就成了问题，会浪费资源，除非有弹性伸缩扩容
献上之前PPT上看到一个BFF分层下的“幸福烦恼”
1.4 有什么方案可以解决传统BFF痛点？
- 包括解决前端需要关心应用的负载均衡、备份冗灾、监控报警等一些列运维部署的操作
- 如何统一管理和运维，提高发布速度、降低运维成本
答案是： Serverless
2.Serverless
我们可以将 Serverless 拆解为 server 和 less 两个单词，从字面上推断词意即为“少服务器的，亦或是无服务器的，弱化后端和运维概念,当前比较成熟的 Serverless 云产品主要有 Amazon Lambda、Google Cloud Function、Azure Function、AliCloud Function Compute、Tencent CloudBase等
2.1 Serverless 的演变
2.2 什么是Serverless
Serverless = Faas (Function as a service) Baas (Backend as a service)
2.3 云函数（Faas）
FaaS（Function-as-a-Service）是服务商提供一个平台、提供给用户开发、运行管理这些函数的功能，而无需搭建和维护基础框架，是一种事件驱动由消息触发的函数服务
前端同学调用Faas服务如同调用本地函数一样简洁，如下所示，是一个腾讯云中一个简单的小程序云开发demo，cloudfunction是用来定义云函数的方法
2.4 后端即服务（ BaaS）
BaaS（Backend-as-a-Service）后端即服务，包含了后端服务组件，它是基于 API 的第三方服务，用于实现应用程序中的核心功能，包含常用的数据库、对象存储、消息队列、日志服务等等。
比如腾讯云云开发中下面的这些服务:point_down:：
- 微信小程序的云调用 wx-server-sdk
- 云开发数据库 wx.cloud.database
2.5 Serverless的架构
2.6 Serverless的优势
- 环境统一: 不需要搭建服务端环境,, 保持各个机器环境一致 Serverless 的机制天然可复制
- 按需计费: 我们只在代码运行的时候付费，没有未使用资源浪费的问题
- 丰富的SDK: 有完善的配套服务, 如云数据库, 云存储, 云消息队列, 云音视频和云 AI 服务等
- 弹性伸缩: 不需要预估流量, 关心资源利用率, 备份容灾, 扩容机器 ，可以根据流量动态提前峰值流量
“ Serverless 带来的其实是前端研发模式上的颠覆。相对以往纯前端研发的方式，Serverless 屏蔽底层基础设施的复杂度，后台能力通过FaaS平台化，我们不再需要关注运维、部署的细节，开发难度得到了简化，前端开发群体的边界就得以拓宽，能够参与到业务逻辑的开发当中，更加贴近和理解业务，做更有价值的输出。”
2.7 Serverless的缺点
- 云厂商强绑定：它们常常会和厂商的其他云产品相绑定，如对象存储、消息队列等，意味你需要同时开通其他的服务，迁移成本高，如果想迁移基本原有的逻辑不可服用，kennel需要重构
- 不适合长时间任务：云函数平台会限制函数执行时间，如阿里云 Function Compute 最大执行时长为 10 min
- 冷启动时间：函数运行时，执行容器和环境需要一定的时间，对 HTTP 请求来讲，可能会带来响应时延的增加
- 调试与测试：开发者需要不断调整代码，打印日志，并提交到函数平台运行测试，会带来开发成本和产生费用
2.8 Serverless的应用场景
- 场景1: 负载有波峰波谷
波峰波谷时，机器资源要按照峰值需求预，比如医院挂号这需求，假设在每天10点放号预约，那10点就会有峰值的出现，为了这个峰值并发的考虑，准备了相对应性能（固定）的服务器，然而在波谷时机器利用率又明显下降，不能进行资源复用导致浪费，而serverless不用为了波峰去做准备，不用留住水位，支持弹性缩扩容，在你高峰时再在进行动态扩容
- 场景2: 定时任务（报表统计等）
服务空闲时间来处理批量数据，来生成数据报表，通过Serverless方式，不用额外购买利用率并不高的处理资源，比如每日的凌晨，分析前一天收集的数据并生成报告
- 场景3: 小程序开发（云开发）
比如微信小程序开发m在实际开发中，如果我们不用云开发的openid获取流程，而用传统的方式，你就知道openid的获取是非常繁琐的一个过程，前端需要通过wx.login获取一个code值（具有时效性）再通过code值去后台用appsecret去调取openid。
而云函数由于是部署在腾讯云的关系，腾讯云将云调用将鉴权部分有效的封装，让你的接口很容易的实现了鉴权保护，无需维护复杂的鉴权机制，从而让个人开发者和小团队可以更容易地开发小程序
,
