展开
关键词
腾讯云·社区
bff架构
相关内容
资源编排 TIC
资源编排 TIC为您提供易用、高效、安全的基础架构管理平台。平台使用声明型语言，兼容众多优秀的开源社区工具，同时提供代码编辑和视图编辑两种模式，有效降低学习成本和使用难度。TIC 使用代码版本管理的方式管理基础架构，保障基础设施的构建、管理和迁移的可靠性和安全性。
初识BFF架构设计
最近在公司的微服务架构中遇到了一些多终端访问接口的问题，不同的终端拥有不同的接口服务，有不同的操作数据的能力，针对这种业务场景做出了调研，我们是否可以在不同的访问层进行业务逻辑处理，获取不同的数据内容呢多端共用一个BFF?每个端提供一个BFF?如果我们为每一个端点都提供一个BFF，每个端点的BFF处理自身的业务逻辑，需要数据时从基础服务内获取，然后在接口返回之前进行组装数据用于实例化返回对象。这样基础服务如果有新功能添加，BFF几乎不会受到影响，而我们如果后期把App端点进行拆分成Android、IOS时我们只需要将app-bff进行拆分为android-bff、ios-bff，基础服务同样也不会受到影响总结在微服务架构设计中，BFF起到了一个业务聚合的关键作用，可以 通过openfeign、restTemplate调用基础服务来获取数据，将获取到的数据进行组装返回结果对象，BFF解决了业务场景问题，也同样带来了一些问题介绍一个架构新词-BFF（这个和微服务也有关系）
端用户体验层->网关层->BFF层->微服务层在微服务架构中，BFF(Backend for Frontend)也称聚合层或者适配层，它主要承接一个适配角色：将内部复杂的微服务，适配成对各种不同用户体验聚合裁剪适配是BFF的主要职责。1 在微服务架构中，网关专注解决跨横切面逻辑，包括路由、安全、监控和限流熔断等。网关一方面是拆分解耦的利器，同时让开发人员可以专注业务逻辑的实现，达成架构上的关注分离。2 端用户体验层->网关层->BFF层->微服务层，是现代微服务架构的典型分层方式，这个架构能够灵活应对业务需求的变化，是一种支持创新的演化式架构。3 技术和业务都在不断变化，架构师要不断调整架构应对这些的变化，BFF和网关都是架构演化的产物。以上的三点总结出自 微服务架构：BFF和网关是如何演化出来的？在没有BFF架构之前，调用接口方式如下图所示，就是根据后端服务的常规调用裁剪等个性化诉求催生了BFF ?微服务架构中的BFF到底是啥？
假设我们在一个开发团队中，开发了一个叫做MyShop的电商项目，它采用的是微服务的架构风格。它经历过几次架构调整，我们就跟着它的调整来看看BFF是怎么演化出来的。，于是架构团队决定在Nginx和内部API微服务之间引入一层无线BFF（英文全称：Backend For Frontend，指为前端应用开发的后端服务）来解决这个问题，也就有了下面的v2.5版本的架构。自此，v3架构出炉，如下图所示：v3架构下，BFF按照团队或业务线的边界进行划分，每个业务线团队可以并行各自开发和交付BFF。而BFF层面，也根据业务线拆分为了无线BFF、H5 BFF及开放平台BFF。整个架构层次清晰，职责分明，是一种灵活的、方便支持MyShop业务快速发展的架构。五、我司还处于v3阶段刚刚通过MyShop的案例架构演化，讲解了BFF和网关是如何演化出来的。那么，你可能会问，我司的架构处在哪个阶段。这里，回答一下，还在v3阶段。微服务架构~BFF和网关是如何演化出来的
介绍BFF(Backend for Frontend)和网关Gateway是微服务架构中的两个重要概念，这两个概念相对比较新，有些开发人员甚至是架构师都不甚理解。本文用假想的公司案例+图示的方式，解释BFF和网关是什么，它们是怎么演化出来的。希望对架构师设计和落地微服务架构有所启发。服务化架构V1我们先把时间推回到大致2011年左右。服务化架构V2.1V2架构问题太多，没有开发实施。为解决上述问题，架构师经过思考决定在外部设备和内部微服务之间引入一个新的角色~Mobile BFF。为了解决上述问题，架构师经过思考决定在外部设备和内部BFF之间再引入一个新的角色~API Gateway，新的架构V3如下图所示：?新的架构V3有如下调整：BFF按团队或业务线进行解耦拆分，拆分成若干个BFF微服务，每个业务线可以并行开发和交付各自负责的BFF微服务。系统服务构建-BFF助力前后端分离
专业术语本文试图讲明白软件架构中的一个新概念 BFF，涉及到的几个技术概念先做一个前置约束和语意说明前端应用：负责直接呈现给终端用户的应用系统，如网站，APP 等带有界面的软件系统。BFF 产生背景在没有 BFF 架构之前，调用接口方式如下图所示，就是根据后端服务的常规调用?前后端调用?Using one server-side BFF per user interface.pngBFF 优势增加 BFF 层可以有哪些优势我们可以把 BFF 层理解为经典的软件架构分层中的业务逻辑层。总结说了这么多 BFF 也可以认为是意识形态的东西，比如 对于 BFF 这个 架构层次或者命名，老板说叫什么就叫什么，不用纠结。毫无疑问，BFF 也是一种架构设计，BFF 的定位和设计也要通过项目版本的迭代和业务驱动逐渐演化而来的。「Web应用架构」模式：前端的后端(BFF)
首先，这些问题必须由BFF自己管理，但我们还需要确保调用BFF的客户机能够解释部分响应并正确地呈现它。再利用每个用户界面都有一个BFF的一个关注点是，在BFF本身之间可能会有很多重复。本文：http:jiagoushi.propattern-backends-frontends讨论：请加入知识星球【首席架构师圈】或者微信小号【jiagoushi_pro】微信公众号关注微信公众号【首席架构师智库】微信小号希望加入的群：架构，云计算，大数据，数据科学，物联网，人工智能，安全，全栈开发，DevOps，数字化，产品转型。点击加入知识星球【首席架构师圈】微信圈子志趣相投的同好交流。点击加入微信圈子【首席架构师圈】喜马拉雅路上或者车上了解最新黑科技资讯，架构心得。点击，收听【智能时刻，架构君和你聊黑科技】知识星球认识更多朋友，职场和技术闲聊。点击加入知识星球【知识和技术】微服务下使用GraphQL构建BFF | 洞见
不管是成熟的互联网公司、创业公司还是个人开发者，对于微服务架构的接纳程度都相当高，微服务架构的广泛应用也自然促进了技术本身更好的发展以及更多的实践。下图看到没有BFF以及加入BFF的前后端项目上的主要区别。1. 没有BFF 的前后端架构 ?加入了BFF 的前后端架构 ?加入了BFF的前后端架构中，最大的区别就是前端(Mobile, Web) 不再直接访问后端微服务，而是通过 BFF 层进行访问。并且每种客户端都会有一个BFF服务。我们使用 GraphQL-express 框架构建项目的 BFF 端，然后通过 Docker 进行部署。整体技术架构 ?整体来看，我们的前后端架构图如下，三个 App 客户端分别使用 GraphQL 的形式请求对应的 BFF。BFF 层再通过 Consul 服务发现和后端通信。Backend For Frontend (BFF)
，多个BFF之间容易产生冗余代码，尤其是一些通用的后端逻辑（如授权、认证、限流等等）为了消除BFF间的代码冗余，一般采用两种做法：要么多BFF合一要么在BFF之上加一层Edge API service多间紧耦合，所以就有了一种折衷的态度：容忍BFF间冗余、消除单BFF内冗余。也就是允许一定程度的BFF间冗余当然，复用的前提是多BFF技术栈相同，然后识别出冗余部分，并重构掉。从分工的角度看：BFF模式不仅仅是一种技术架构，从社会分工角度讲，BFF更是一种多元价值导向的分层架构，每一层都有不错的空间去施展。微服务架构~BFF和网关是如何演化出来的蚂蚁财富的BFF实践基于 Node.js 的 Serverless 架构实践
而前端也在以往前后端分离的基础上，更进一步的演变为了 BFF 架构。根据最终端上的需求，通过 BFF 层将各个微服务进行聚合和裁剪后返回。根据”谁享受谁负责“原则，该 BFF 层通常由前端使用 NodeJS 维护。? （典型 BFF 架构）然而，作为横向支撑的前端团队，我们在实施 BFF 架构1年后，却发现它可能并没有想象的那么美好。（BFF 层横向扩展带来的挑战）所以，我们核心面临的问题总结起来就是运维成本难降低、重复开发难避免、入口分散难管理。那么有没有一种更轻量的架构，使我们所有人能从上述这些繁琐的工作中解放出来？从IaaS到FaaS—— Serverless架构的前世今生BFF in serverless然而独立的 FaaS 其实并不具备实用性，因为他是无状态的，无法进行存储意味着无法针对不同用户提供服务。而 BFF in serverless 在 serverless 架构的基础上，提供了一套完善的 BaaS SDK、监控日志体系以及前端解决方案，从而更进一步降低了开发者门槛。Nodejs BFF 开发 8 个月的心路历程
App，然后当时认为还有h5，小程序，所以当时画架构图，我把多端也考虑进去了，当时领导提出需要做BFF接入到中台到端，然而没有当时预料的多端，只有越来越壮大的BFF。也是在2019年7月，搭建了BFF第一个项目（已废弃），BFF公司已经内部自封框架了，我不是公司第一个使用node.js的（但是其他人应该没有前端和我一样吧，连续几个月全部是在做node.js BFF开发还有其他一些坑，没少麻烦架构师帮忙看问题，（也很感谢架构师重新架构BFF层，CBS和BFF分开，开始拓展更多的业务系统一段时间内相对平稳做迭代，这时候架构师开始对我们组进行要求，所有的日志必须齐全，公共组件的接入也必须规范化还有一个很重要的问题就是，BFF对接两个两个系统，以及还有对端的一些api，全都是在单体系统中，需要做架构拆分，于是架构师最后给出了一个方法，先拆成三个服务，一个是BFF代理服务，另外两个，一个对接P服务在2020 年的2月份，具体就是上个月中，这三个系统上线了，上线过程中不算顺利，本来半分钟就能启动成功的容器，两分钟能切换的转发，因为一些别的配置，上了两个小时......重新架构后带来的好处面向对象式编程【架构拾集】前后端分离演进：不能微服务，那就 BFF 隔离
技术远景或许你在我之前的文章里已经了解了 BFF 是什么，又或许你已经从其它渠道了解到这方面的知识。如果没有的话，那么让我再简单地介绍一下：什么是 BFF？[BFF)(http:architecture.phodal.comimagesbff.jpg)如我在《前端演进史》 一文所说，早期我们在设计系统 API 的时候，只是单纯地为前端（Web、Android而使用 BFF 则意味着，它会多出一层业务处理及转发层。适用场景如上所述，这种架构特别适合于采用绞杀者模式的系统迁移。迁移方案让我们回到 Web 1.0 时代，看看那个时候的网站架构：
相关视频
相关资讯
相关关键词
活动推荐
云+社区
扫码关注云+社区
领取腾讯云代金券