学习
实践
活动
工具
TVP
写文章

BFF 架构简介

Sam Newman详细地说明了BFF。 客户端都不是直接访问服务器的公共接口,而是调用BFF层提供的接口,BFF层再调用基层的公共服务,不同的客户端拥有不同的BFF层,它们定制客户端需要的API。 那么采用BFF架构与多端公用、单一的API有什么优点了?最重要的一点在上文中已经提到了,它能够满足因不同客户端特殊的交互引起的对新接口的要求,所以一开始就会针对相应的设备设计好对应的接口。 而使用BFF在很大程度能避免这样的问题。 当然,凡事有利有弊,BFF带来便利好处的同时也会引起一些问题,如代码重复,加大开发工作量等。所以在使用时需要结合现实情况仔细斟酌,符合项目的应用开发背景。例如蚂蚁财富使用BFF的场景如下。 ?

58630

初识BFF架构设计

最近在公司的微服务架构中遇到了一些多终端访问接口的问题,不同的终端拥有不同的接口服务,有不同的操作数据的能力,针对这种业务场景做出了调研,我们是否可以在不同的访问层进行业务逻辑处理,获取不同的数据内容呢 多端共用一个BFF ? 每个端提供一个BFF ? 如果我们为每一个端点都提供一个BFF,每个端点的BFF处理自身的业务逻辑,需要数据时从基础服务内获取,然后在接口返回之前进行组装数据用于实例化返回对象。 这样基础服务如果有新功能添加,BFF几乎不会受到影响,而我们如果后期把App端点进行拆分成Android、IOS时我们只需要将app-bff进行拆分为android-bff、ios-bff,基础服务同样也不会受到影响 总结 在微服务架构设计中,BFF起到了一个业务聚合的关键作用,可以 通过openfeign、restTemplate调用基础服务来获取数据,将获取到的数据进行组装返回结果对象,BFF解决了业务场景问题,

1.1K50
  • 广告
    关闭

    2022腾讯全球数字生态大会

    11月30-12月1日,邀您一起“数实创新,产业共进”!

  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    如何在中后台领域玩转BFF架构

    基于以上背景,前端这边引入了 BFF 架构BFF 架构能做哪些事情: 业务编排:从后端域多接口获取数据合并输出给页面。 A 服务器上部署了我们的 BFF 应用,B 服务器上部署了我们的微服务。 以上即为我们第一代BFF架构的核心内容,这套架构在当时的业务背景下是一个比较好的解决方案,但随着业务的快速发展,这个架构也遇到了一些问题: 运维成本增大:随着 BFF 应用的增多,需要更多的机器来部署BFF 发布流程长:新增一个 BFF 的接口,需要走完编译,构建,部署一整套流程,无法做到秒级部署。 域名不收敛:每个 BFF 都有各自独立的域名,增加记忆成本。 基于 Serverless 的BFF改造 SFF 架构 上图是改造后的BFF架构,相比于一代的 BFF 架构,这里主要多了两块内容,一块是 FaaS 层,另外一块是开发者平台。

    59430

    「Web应用架构」模式:前端的后端(BFF)

    这意味着,当推出新的交付时,单个API后端可能会成为瓶颈,因为许多更改都试图对同一个可部署工件进行。 通用API后端承担多个职责的趋势,因此需要大量工作,通常会导致专门创建一个团队来处理这个代码库。 此外,要构建类似于生产的堆栈,需要部署的层越多,开发和测试就越复杂—将所有这些关注点都放在BFF中作为一个更独立的解决方案可能会很有吸引力: ? 如果部署额外服务的成本很高,我可能会重新考虑,但是在大多数情况下,BFF可以带来的关注分离使它成为一个相当有说服力的提议。 【首席架构师智库】 微信小号 希望加入的群:架构,云计算,大数据,数据科学,物联网,人工智能,安全,全栈开发,DevOps,数字化,产品转型。 点击加入知识星球【首席架构师圈】 微信圈子 志趣相投的同好交流。 点击加入微信圈子【首席架构师圈】 喜马拉雅 路上或者车上了解最新黑科技资讯,架构心得。

    89420

    微服务架构中的BFF到底是啥?

    假设我们在一个开发团队中,开发了一个叫做MyShop的电商项目,它采用的是微服务的架构风格。它经历过几次架构调整,我们就跟着它的调整来看看BFF是怎么演化出来的。 自此,v3架构出炉,如下图所示: [7b43aa3dly4ggl3ij2yomj20u00k745z.jpg] v3架构下,BFF按照团队或业务线的边界进行划分,每个业务线团队可以并行各自开发和交付BFFBFF层面,也根据业务线拆分为了无线BFF、H5 BFF及开放平台BFF。整个架构层次清晰,职责分明,是一种灵活的、方便支持MyShop业务快速发展的架构。 相信看到这里,你大概应该明白了BFF是个啥,它在微服务架构中的位置和作用,以及它是如何演化出来的。 画外音:如果还没明白,那就再看一遍! 五、我司还处于v3阶段 刚刚通过MyShop的案例架构演化,讲解了BFF和网关是如何演化出来的。那么,你可能会问,我司的架构处在哪个阶段。这里,回答一下,还在v3阶段。

    1.1K00

    探索原味BFF模式

    BFF — Backend For Frontends,经典分布式架构设计模式之一。我在学习和工作经验累积中,逐渐加深了对 BFF 的理解。 在本篇文章中,你们会与我一起穿越回BFF诞生的历史中,寻找其起源。并一同探索和学习这个在分布式系统中出镜率极高的架构模式。 SoundCloud 的 BFF 依然随着时间在横向增长,不同的是这种横向增长不会再引起任何问题了。最终,BFF 模式的架构演变成与我们现在使用的几乎一致了。 架构如下图: 总结 我们在维护和使用分布式架构,同时面对多客户端时,BFF 模式提供了一种很好的架构模式,使后端团队在构建面向客户端的复杂需求时,能够掌控自己的命运。 在系统架构中,因为离需求频繁变化的前端比较近(网络和组织架构上),BFF很容易野蛮生长,成为各种“妥协”的自留地,在使用的过程中,我们需要明确架构中各层相关的职能和边界。

    8220

    BFF与Nestjs实战

    最近我们后端伙伴开始采用了微服务架构,拆分了很多领域服务,身为大前端的我们肯定也要做出改变,平常一个列表需要一个接口就能拿到数据,但微服务架构下就需要中间有一层专门为前端聚合微服务架构下的n个接口,方便前端调用 ,于是我们就采用了当下比较流行的BFF方式。 BFF作用 BFF(Backends For Frontends),就是服务于前端的后端,经过几个项目的洗礼,我对它也有了一些见解,我认为它主要有以下作用: 接口聚合和透传:和上文所讲的一致,聚合多个接口 需求变化频繁,接口经常需要变动:后端有一套稳定的领域服务为多个项目服务,变动的话成本较高,而bff层针对单一的项目,在bff层变动可以实现最小成本的改动。 BFF NestJs官方文档

    9110

    Backend For Frontend (BFF)

    复用问题 拆开之后,多个BFF之间容易产生冗余代码,尤其是一些通用的后端逻辑(如授权、认证、限流等等) 为了消除BFF间的代码冗余,一般采用两种做法: 要么多BFF合一 要么在BFF之上加一层Edge 回到复用问题本身,我们想消除冗余,又不想因为抽离可复用代码而导致BFF间紧耦合,所以就有了一种折衷的态度:容忍BFF间冗余、消除单BFF内冗余。 希望越来越多的开发者,可以不用再关注流程、构建、环境、部署等各种事,希望能做到技术无感化(Techless),让每一位开发着能安安静静的快乐编码。 从分工的角度看: BFF模式不仅仅是一种技术架构,从社会分工角度讲,BFF更是一种多元价值导向的分层架构,每一层都有不错的空间去施展。 微服务架构~BFF和网关是如何演化出来的 蚂蚁财富的BFF实践

    1.5K40

    GraphQL及元数据驱动架构在后端BFF中的实践

    4 基于GraphQL及元数据的信息聚合架构设计 4.1 整体思路 通过对后端BFF和前端BFF两种模式的分析,我们最终选择后端BFF模式,前端BFF这个方案对目前的研发模式影响较大,不仅需要大量的前端资源 因此,我们的思路是:基于GraphQL+后端BFF方案改进,实现取数逻辑和展示逻辑的可沉淀、可组合、可复用,整体架构如下示意图所示: ? 除此之外,整体架构的核心设计还包括以下三个方面:1)取数展示分离;2)查询模型归一;3)元数据驱动架构。 图9 元数据驱动架构 整体架构由三个核心部分组成: 业务能力:标准的业务逻辑单元,包括取数单元、展示单元和查询模型,这些都是关键的可复用资产。 本文以基于对美团到店商品展示场景所面临的核心矛盾分析,介绍了: 业界不同的BFF应用模式,以及不同模式的优势和缺点。 基于GraphQL BFF模式改进的元数据驱动的架构方案设计。

    53750

    微服务架构~BFF和网关是如何演化出来的

    介绍 BFF(Backend for Frontend)和网关Gateway是微服务架构中的两个重要概念,这两个概念相对比较新,有些开发人员甚至是架构师都不甚理解。 本文用假想的公司案例+图示的方式,解释BFF和网关是什么,它们是怎么演化出来的。希望对架构师设计和落地微服务架构有所启发。 服务化架构V1 我们先把时间推回到大致2011年左右。 服务化架构V2.1 V2架构问题太多,没有开发实施。为解决上述问题,架构师经过思考决定在外部设备和内部微服务之间引入一个新的角色~Mobile BFF。 为了解决上述问题,架构师经过思考决定在外部设备和内部BFF之间再引入一个新的角色~API Gateway,新的架构V3如下图所示: ? 新的架构V3有如下调整: BFF按团队或业务线进行解耦拆分,拆分成若干个BFF微服务,每个业务线可以并行开发和交付各自负责的BFF微服务。

    51930

    架构拾集】前后端分离演进:不能微服务,那就 BFF 隔离

    技术远景 或许你在我之前的文章里已经了解了 BFF 是什么,又或许你已经从其它渠道了解到这方面的知识。如果没有的话,那么让我再简单地介绍一下:什么是 BFFBFF BFF,即 Backends For Frontends (服务于前端的后端),也就是服务器设计 API 时会考虑前端的使用,并在服务端直接进行业务逻辑的处理。 ! [BFF)(http://architecture.phodal.com//images/bff.jpg) 如我在《前端演进史》 一文所说,早期我们在设计系统 API 的时候,只是单纯地为前端(Web、 而使用 BFF 则意味着,它会多出一层业务处理及转发层。 适用场景 如上所述,这种架构特别适合于采用绞杀者模式的系统迁移。 迁移方案 让我们回到 Web 1.0 时代,看看那个时候的网站架构

    28620

    Yunong Xiao : Serverless Is Your BFF

    然而语言只是服务端开发最表层也是最易突破的一层,可靠性、速度性能、安全性、架构可扩展性、甚至运维,都是前端向全栈发展需要考虑的关键因素。 10月20日, JSConf大会上,腾讯云中间件总经理 Yunong Xiao 将发表《Serverless Is Your BFF》主题演讲,从前端发展演进、前端到全栈的路径和问题以及如何利用Severless Yunong Xiao,腾讯云中间件和Devops的总经理,首席架构师。 在此之前,曾主导Netflix API Serverless平台的体系架构,使微服务更易于开发人员使用,同时,也让容器在Netflix得到规模化使用。

    55240

    介绍一个架构新词-BFF(这个和微服务也有关系)

    聚合裁剪适配是BFF的主要职责。 1 在微服务架构中,网关专注解决跨横切面逻辑,包括路由、安全、监控和限流熔断等。 2 端用户体验层->网关层->BFF层->微服务层,是现代微服务架构的典型分层方式,这个架构能够灵活应对业务需求的变化,是一种支持创新的演化式架构。 3 技术和业务都在不断变化,架构师要不断调整架构应对这些的变化,BFF和网关都是架构演化的产物。 以上的三点总结出自 微服务架构BFF和网关是如何演化出来的? 在没有BFF架构之前,调用接口方式如下图所示,就是根据后端服务的常规调用 裁剪等个性化诉求催生了BFF ? (https://www.thoughtworks.com/insights/blog/bff-soundcloud) 微服务架构BFF和网关是如何演化出来的?

    6.4K21

    标准化思想及组装式架构在后端BFF中的实践

    标准化思想及组装式架构在后端BFF中的实践 4.1 产品功能归类之系列化 4.2 功能组件提取与预组装 4.3 变化应对之可变性建模 4.4 可视化组装与配置填充 5. 总结 1. 标准化思想及组装式架构在后端BFF中的实践 4.1 产品功能归类之系列化 1)产品系列化 在官方语言里,系列化指的是“对同一类产品的结构形式和主要参数规格进行科学规划的一种标准化形式”。 组件开发环节关注功能的抽象和封装,基于已有组件,组装集成环节做的事情就是选择需要的组件,填充配置,一旦组装结果被保存之后,即完成系统的集成,不再需要构件和部署。 参考文献 [1] Pattern: Backends For Frontends [2] GraphQL及元数据驱动架构在后端BFF中的实践 [3] 福特T型车丨成也标准化,败也标准化 [4] 中台之上 ----------  END  ---------- 也许你还想看   | GraphQL及元数据驱动架构在后端BFF中的实践‍‍‍‍‍‍‍‍‍   | 设计模式二三事   | 大家一直在谈的领域驱动设计

    17840

    Lamp架构_lamp部署

    网站架构方案 LAMP(Linux- Apache-MySQL-PHP)网站架构是目前国际流行的Web框架,该框架包括:Linux操作系统,Apache网络服务器,MySQL数据 库,Perl、PHP或者 Python编程语言,所有组成产品均是开源软件,是国际上成熟的架构框架,很多流行的商业应用都是采取这个架构,和 Java/J2EE架构相比,LAMP具有Web资源丰富、轻量、快速开发等特点,微软的.NET 对于大流量、大并发量的网站系统架构来说,除了硬件上使用高 性能的服务器、负载均衡、CDN等之外,在软件架构上需要重点关注下面几个环节:使用高性能的操作系统(OS)、高性能的网页服务器(Web Server 很多大型网站都采用这种架构。 综上所述,基于LAMP架构设计具有成本低廉、部署灵活、快速开发、安全稳定等特点,是Web网络应用和环境的优秀组合。 版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。

    6520

    你学BFF和Serverless了吗

    ❝ 前沿:前段时间在公司内部分享了关于bff和serverless的知识体会,从概念、特征、和应用场景再到简单的实践,今天借此机会跟大家分享,什么是BFF? 什么是serverless? ❞ 1.BFF ❝ 在聊Serverless之前跟大家先谈谈BFFBFF顾名思义就是Backend For Frontend,用中文解释就是服务于前端的后端,那么为什么会有BFF? ❞ ? 前端同学和后端同学都各有各的道理,有没有一种解决方案可以化解这种尴尬的场景,于是就有了BFF 1.1 介绍 ❝ BFF层初衷是在后台服务与前端(客户端)之间添加一层,接下来我们来看看下面这张图 ❞ ?

    54031

    系统服务构建-BFF助力前后端分离

    专业术语 本文试图讲明白软件架构中的一个新概念 BFF,涉及到的几个技术概念先做一个前置约束和语意说明 前端应用:负责直接呈现给终端用户的应用系统,如网站,APP 等带有界面的软件系统。 BFF 产生背景 在没有 BFF 架构之前,调用接口方式如下图所示,就是根据后端服务的常规调用 ? 前后端调用 ? Using one server-side BFF per user interface.png BFF 优势 增加 BFF 层可以有哪些优势 我们可以把 BFF 层理解为经典的软件架构分层中的业务逻辑层 总结 说了这么多 BFF 也可以认为是意识形态的东西,比如 对于 BFF 这个 架构层次或者命名,老板说叫什么就叫什么,不用纠结。 毫无疑问,BFF 也是一种架构设计,BFF 的定位和设计也要通过项目版本的迭代和业务驱动逐渐演化而来的。

    1.2K10

    扫码关注腾讯云开发者

    领取腾讯云代金券