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

BFF 架构简介

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

64530

初识BFF架构设计

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

1.2K50
  • 广告
    关闭

    热门业务场景教学

    个人网站、项目部署、开发环境、游戏服务器、图床、渲染训练等免费搭建教程,多款云服务器20元起。

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

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

    基于以上背景,前端这边引入了 BFF 架构BFF 架构能做哪些事情: 业务编排:从后端域多接口获取数据合并输出给页面。 BFF 核心架构 核心架构 以上是 BFF 的核心架构图,前端即中后台应用,后端域即后端服务,右侧的工具支撑是公司的一些基础公共服务,中间的就是 BFF 核心实现,我们从上往下看: 业务:可以在这一层做业务编排 Node框架:Node 框架这块选型的是 Koa2。 以上即为我们第一代BFF架构的核心内容,这套架构在当时的业务背景下是一个比较好的解决方案,但随着业务的快速发展,这个架构也遇到了一些问题: 运维成本增大:随着 BFF 应用的增多,需要更多的机器来部署BFF 基于 Serverless 的BFF改造 SFF 架构 上图是改造后的BFF架构,相比于一代的 BFF 架构,这里主要多了两块内容,一块是 FaaS 层,另外一块是开发者平台。

    68530

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

    首先,这些问题必须由BFF自己管理,但我们还需要确保调用BFF的客户机能够解释部分响应并正确地呈现它。 再利用 每个用户界面都有一个BFF的一个关注点是,在BFF本身之间可能会有很多重复。 本文:http://jiagoushi.pro/pattern-backends-frontends 讨论:请加入知识星球【首席架构师圈】或者微信小号【jiagoushi_pro】 微信公众号 关注微信公众号 【首席架构师智库】 微信小号 希望加入的群:架构,云计算,大数据,数据科学,物联网,人工智能,安全,全栈开发,DevOps,数字化,产品转型。 点击加入知识星球【首席架构师圈】 微信圈子 志趣相投的同好交流。 点击加入微信圈子【首席架构师圈】 喜马拉雅 路上或者车上了解最新黑科技资讯,架构心得。 点击,收听【智能时刻,架构君和你聊黑科技】 知识星球 认识更多朋友,职场和技术闲聊。 点击加入知识星球【知识和技术】

    96620

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

    假设我们在一个开发团队中,开发了一个叫做MyShop的电商项目,它采用的是微服务的架构风格。它经历过几次架构调整,我们就跟着它的调整来看看BFF是怎么演化出来的。 自此,v3架构出炉,如下图所示: [7b43aa3dly4ggl3ij2yomj20u00k745z.jpg] v3架构下,BFF按照团队或业务线的边界进行划分,每个业务线团队可以并行各自开发和交付BFF 而网关则由单独的中间件或框架团队进行开发和维护,它专注于路由转发和Cross-Cutting层面的功能建设,让业务线团队专注于业务逻辑的开发。 而BFF层面,也根据业务线拆分为了无线BFF、H5 BFF及开放平台BFF。整个架构层次清晰,职责分明,是一种灵活的、方便支持MyShop业务快速发展的架构。 五、我司还处于v3阶段 刚刚通过MyShop的案例架构演化,讲解了BFF和网关是如何演化出来的。那么,你可能会问,我司的架构处在哪个阶段。这里,回答一下,还在v3阶段。

    1.2K00

    探索原味BFF模式

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

    11420

    BFF与Nestjs实战

    最近我们后端伙伴开始采用了微服务架构,拆分了很多领域服务,身为大前端的我们肯定也要做出改变,平常一个列表需要一个接口就能拿到数据,但微服务架构下就需要中间有一层专门为前端聚合微服务架构下的n个接口,方便前端调用 ,于是我们就采用了当下比较流行的BFF方式。 bff和node没有强绑定关系,但让前端人员去熟悉node之外的后端语言学习成本太高,所以技术栈上我们使用node作为中间层,node的http框架我们使用的是nestjs。 Nest 是一个用于构建高效,可扩展的 Node.js 服务器端应用程序的框架 前端发起请求后后端是怎么做的 首先我们发起一个GET请求 fetch('/api/user') .then(res BFF NestJs官方文档

    14710

    Backend For Frontend (BFF)

    复用问题 拆开之后,多个BFF之间容易产生冗余代码,尤其是一些通用的后端逻辑(如授权、认证、限流等等) 为了消除BFF间的代码冗余,一般采用两种做法: 要么多BFF合一 要么在BFF之上加一层Edge 回到复用问题本身,我们想消除冗余,又不想因为抽离可复用代码而导致BFF间紧耦合,所以就有了一种折衷的态度:容忍BFF间冗余、消除单BFF内冗余。 也就是允许一定程度的BFF间冗余 当然,复用的前提是多BFF技术栈相同,然后识别出冗余部分,并重构掉。 从分工的角度看: BFF模式不仅仅是一种技术架构,从社会分工角度讲,BFF更是一种多元价值导向的分层架构,每一层都有不错的空间去施展。 微服务架构~BFF和网关是如何演化出来的 蚂蚁财富的BFF实践

    1.6K40

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

    4 基于GraphQL及元数据的信息聚合架构设计 4.1 整体思路 通过对后端BFF和前端BFF两种模式的分析,我们最终选择后端BFF模式,前端BFF这个方案对目前的研发模式影响较大,不仅需要大量的前端资源 因此,我们的思路是:基于GraphQL+后端BFF方案改进,实现取数逻辑和展示逻辑的可沉淀、可组合、可复用,整体架构如下示意图所示: ? 通过元数据描述组件及组件之间关联关系,通过框架解析元数据自动进行业务组件的调用执行,形成了如下的元数据架构: ? 图24 基于开发框架搭建展示场景前后研发流程对比 以前是“一杆子捅到底”的开发模式,每个展示场景的搭建需要经历过从接口的沟通到API的开发整个过程,基于新架构之后,系统自动具备多层复用及可视化、配置化能力 本文以基于对美团到店商品展示场景所面临的核心矛盾分析,介绍了: 业界不同的BFF应用模式,以及不同模式的优势和缺点。 基于GraphQL BFF模式改进的元数据驱动的架构方案设计。

    57750

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

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

    56130

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

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

    29820

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

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

    6.7K21

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

    标准化思想及组装式架构在后端BFF中的实践 4.1 产品功能归类之系列化 4.2 功能组件提取与预组装 4.3 变化应对之可变性建模 4.4 可视化组装与配置填充 5. 总结 1. 这类系统业界也有一些标准的术语,叫BFF(Backend For Frontend)。BFF的主要职责是组合使用底层数据,额外处理C端展示逻辑。 标准化思想及组装式架构在后端BFF中的实践 4.1 产品功能归类之系列化 1)产品系列化 在官方语言里,系列化指的是“对同一类产品的结构形式和主要参数规格进行科学规划的一种标准化形式”。 参考文献 [1] Pattern: Backends For Frontends [2] GraphQL及元数据驱动架构在后端BFF中的实践 [3] 福特T型车丨成也标准化,败也标准化 [4] 中台之上 ----------  END  ---------- 也许你还想看   | GraphQL及元数据驱动架构在后端BFF中的实践‍‍‍‍‍‍‍‍‍   | 设计模式二三事   | 大家一直在谈的领域驱动设计

    21040

    框架VS架构

    框架是和架构比较相似的概念,而且两者有着较强的关联关系,所以在实际工作中,很多时候这两个概念并不是分得那么清晰,参考维基百科,框架的定义如下: 软件框架(Software Framework)通常指的是为了实现某个业界标准或者完成特定基本任务的软件组件规范 框架是组件规范,比如:MVC就是一种常见的开发规范,类似的有MVP、MVVM、J2EE等框架框架提供基础功能的产品。 单从定义的角度来看,框架架构的区别还是比较明显的,框架关注的是规范,架构关注的是结构。框架的英文是Framework ,架构的英文是Architecture。 尽管如此,在实际工作中我们却经常碰到一些似而非似的说法,比如: 我们的系统吃MVC架构 我们需要将Android App重构 MVP架构 我们的系统基于SHH框架开发 我们的系统是SHH的架构 以上几种说法到底是对还是错呢 从开发规范的角度分解,“学生信息管理系统”可以采用标准的MVC来开发,因此架构又变成了MVC架构了,如下图: ? 以上这些架构 ,都是学生信息管理系统正确的架构,只是从不同的角度来分解而已。

    46550

    企业架构 | TOGAF架构能力框架

    这正是TOGAF的架构能力框架(Architecture Capability Framework)的关注点所在。架构能力框架为企业如何建立这样一种架构能力提供了一系列参考材料。 综上所述,架构能力框架为企业中架构能力的建设提供了指南。这里所说的架构能力就是企业能够成功建设和运用架构的能力。 作为一个企业架构框架,TOGAF为支持架构治理的实现提供了一个架构治理框架(Architecture Goverance Framework),用于帮助企业明确各种有效的治理流程,从而使得与架构治理相关联的各种业务职责得以被鉴别出来 3)架构治理框架 架构治理框架包括两个部分的内容,其一是用来概括架构治理各流程以及相关内容的概念结构,另外一个是TOGAF对于架构治理所建议的组织结构。 上图展示了架构治理框架的概念结构,其中涵盖了这一框架中的各种概念,这其中最关键的是与治理流程有关的各种概念。

    28310

    现代企业架构框架 — 业务架构

    3.1业务架构元模型综述 业务架构 (Business Architecture) 定义了企业各类业务的运作模式及业务之间的关系结构。 业务架构是企业架构的核心内容,直接决定了企业战略的实现能力,是其他架构领域工作的前提条件和架构设计的主要依据。 业务架构整体上包括“业务”、“流程”、“组织”、 “服务”、“领域”和“模式”六大部分,如下图 3.1-1 所示: 其中“模式”部分是我们为“平台型”企业架构设计的核心解决方案,包括: 3.2 业务架构元模型应用 需要注意的是,通常这套机制需要技术上的开发框架支持。 3.3 业务架构元模型补充说明 在 3.2章节中,我们对业务架构元模型的“Pattern(模式)”部分进行了详细说明,下面对业务架构元模型的其余部分进行补充说明;这些部分都可参照传统业务架构的方法进行设计

    31830

    关注

    腾讯云开发者公众号
    10元无门槛代金券
    洞察腾讯核心技术
    剖析业界实践案例
    腾讯云开发者公众号二维码

    相关产品

    • Serverless 应用中心

      Serverless 应用中心

      联动云上资源,弹性扩缩,按需付费,极速部署 Serverless 应用的开发平台。

    相关资讯

    热门标签

    活动推荐

    扫码关注腾讯云开发者

    领取腾讯云代金券