宁波seo网站排名,网页游戏开服表37,网站建设补充合同范本,沈阳网站关键词优化做的好吗在现代软件开发中#xff0c;由于程序、团队、数据规模太大#xff0c;需要把企业的业务能力进行复用#xff0c;将领域服务剥离#xff0c;提供通用能力#xff0c;避免重复建设和代码#xff1b;另外服务功能的弹性能力不一样#xff0c;比如定时任务、数据同步明确的…在现代软件开发中由于程序、团队、数据规模太大需要把企业的业务能力进行复用将领域服务剥离提供通用能力避免重复建设和代码另外服务功能的弹性能力不一样比如定时任务、数据同步明确的技术诉求甚至一些“政治”因素微服务架构成为了势不可挡的趋势席卷而来。随着微服务架构和前后端分离思想的流行BFF 也是微服务架构必须考虑的一个设计组件。 一、Why BFF承前启后
BFF即 Backends For Frontends (服务于前端的后端)由于微服务众多需要一个统一入口根据不同的业务场景作为前端集成使用。
面向后端BFF 隔离了因不同渠道前端 UI 展示对后端 API 的需求企业可以在后端构建核心业务领域能力
面向前端BFF 可以根据已有的后端 API快速满足不同渠道的前端在 UI 展示上的需求来不断提升用户体验
同时BFF 可以帮助企业进行微服务架构的迁移或者演进。如下图所示如果我们需要将一个大单体的架构迁移或演进成一个微服务的架构可以先在前端和单体应用间加一个 BFF 层通过 BFF 把单体的服务能力暴露给前端然后我们可以把大单体拆分成领域服务或者中台通过 BFF 或者前台相对于中台的概念把中台和领域服务组合和编排成前端需要的 API这样中台和领域服务的变动也不会影响前端的用户体验。由此可见后台架构的演进可以通过 BFF 来进行隔离微服务架构内部的演进微服务的拆分也可以借助 BFF 来减少对前端的影响。 另外由于进程间存在不同的资源类型业务上存在不同的变化频度我们会对进程间进行分层来获得最优的拓展方法。通常越靠近用户的层它的需求和变化频度就越大所以我们图中前后端的进程间架构采用了漏斗的形式。如果你的系统架构设计是反漏斗的那么就需要反思架构设计是否合理。 二、典型的进程间微服务架构
我们以外卖系统为例它的用户有订餐用户、餐饮商家、后台管理人员。它的渠道有手机 APP、微信小程序和 WEB 页面。在刚开始的时候为了加快上线抢占市场我们把它构建成了大单体但是前后端分离的形式。下图是初始的进程间架构。 随着业务的发展接入的商家越来越多订餐用户的个性化需求也复杂了起来后台管理和一些报表功能也复杂起来了研发团队的规模也从十几人变成了几百人了。因此高层决定把传统的单体架构转变为微服务架构提高需求的上线效率。他们决定引入 BFF 来做架构的演进但是有两种微服务架构让决策团队出现了为难情绪。 薄 BFF
薄 BFF 的意思就是 BFF 的职责较少也叫网关主要负责将前端的路由转发后端的领域服务。当然一些通用的功能如鉴权、限流、熔断、服务降级、灰度路由等也可以放到其中。 厚 BFF
相对于薄 BFF厚 BFF 算是真正意义上的 BFF除了具有薄 BFF 的所有职能外它可以接入不同的协议如 MQ 服务WebSocket等类似 DDD 领域驱动设计中的应用层可以组合和编排不同的领域服务避免了服务间的相互依赖。 微服务模式对比
下面的表格是薄厚两种 BFF 的对比。 模式 渠道独立多样性 聚焦领域服务 前端数据组装难易性 端到端交付 重复代码 薄BFF 差 差 差 好 少 厚BFF 好 好 好 差 多
对于薄 BFF适合接入差异较小的应用如企业内部使用的应用系统。用户群非常固定、交互方式统一、数据权限能找到规律避免了重复代码。
对于厚 BFF对不同的来源请求都使用了各自的入口服务承接此结构成本较大但对于接入渠道多样或业务场景复杂的系统来说较适合。另外Open API可以看做是一种 BFF 作为系统防腐层有必要设计为有编排能力的 BFF。 三、BFF 的问题
前面说了引入 BFF 给我们微服务架构带来了诸多好处。但是引进了一个组件势必会带来不少问题。
1. 由于多个前端渠道会有不同的 BFF往往会导致同样一个功能需要在不同 BFF 中来实现会有大量的重复代码。
2. BFF承载了过多的业务。当新的业务需求产生时具体要在哪个后端领域服务中实现有时候不是一个很容易回答的问题特别是不同的服务有不同的团队归属时如果每个服务的归属团队都认为新的业务需求不是自己服务的业务范畴特别是如果是前端或者BFF团队来牵头需求时最可能的结果就是让 BFF 负责帮忙组合各个服务的功能完成这个新的业务需求。渐渐地BFF 朝着 ESB 的方向发展变成了集成各个微服务对外提供新能力的中间件。
3. 一个接口完成多次写操作很难保证数据一致性。如果一个业务场景需要调用多个后端领域服务来更新或插入数据那么数据的同步就是个问题。
4. 性能。既然有了 BFF前端的设计是否可以放飞自我了可以把想展示的信息一股脑都放在一起展示极端情况下 BFF 可以获取到任意服务的数据进行组合那么一个 BFF 接口需要调用了N个后端服务来拼凑前端需要的数据那么这个接口的性能一定不会好。 四、BFF 的治理方向
针对这些问题我们需要明确该如何治理 BFF。要治理就要有原则
1. BFF 为前端和业务场景而生关注点在提升前端用户体验和对后端业务能力的编排上
2. BFF 不承载业务能力业务逻辑要下沉到合适的后端领域服务中。
3. BFF 不承载特定技术能力必要时可以建立专门的服务承载如文档打印、Excel生成、算法逻辑等。
4. BFF 不做后端服务的集成层某个后端服务的数据变更需要同步到其他服务不能通过BFF 实现。 有了原则就有方向。BFF 的治理方向如下
1. 优先解决后端服务的设计问题
2. 从业务上分析BFF接口的职责保证接口职责单一
3. 将BFF中业务能力下沉到后端领域服务
4. 将BFF中需要复用的技术能力抽取成共享库或下沉建立后端服务
5. 避免一个BFF接口依赖过多的后端服务根据系统复杂度来看最多依赖不超过5个后端服务为宜
6. 避免一个BFF接口多次写操作不滥用BFF站在上帝视角所拥有的权利各司其职
