架构设计：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。
  ⽽云函数由于是部署在腾讯云的关系，腾讯云将云调⽤将鉴权部分有效的封装，让你的接⼝很容易的实现了鉴权保护，⽆需维护复杂的鉴权机制，从⽽让个⼈开发者和⼩团队可以更容易地开发⼩程序

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。