聊聊微服务中的 BFF 架构

本文涉及的产品
云原生网关 MSE Higress,422元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
注册配置 MSE Nacos/ZooKeeper,118元/月
简介: 聊聊微服务中的 BFF 架构


在我们之前设计的一个供应链系统中,它包含了商品、销售订单、加盟商、门店运营、门店工单等服务,涉及了各种用户角色,比如总部商品管理、总部门店管理、加盟商员工、门店人员等,而且每个部门的角色还会进行细分。而且这个系统中还包含了两个客户端 App:一个面向客户,另一个面向公司员工和加盟商。

此时,整个供应链系统的架构如下图所示:

上图中的网关层主要负责路由、认证、监控、限流熔断等工作。

  • 路由:所有的请求都需要通过网关层进行处理,网关层再根据 URI 将请求指向对应的后台服务,如果同一个服务存在多个服务器节点,网关层还将承担负载均衡的工作。
  • 认证:对所有的请求进行集中认证鉴权。
  • 监控:记录所有的 API 请求数据,API 管理系统能对 API 调用实现管理和性能监控。
  • 限流熔断:流量过大时,我们可以在网关层实现限流。如果后台服务响应延时或故障,我们可以主动在调用端的上游服务做熔断,以此保护后端服务资源,同时不影响用户体验。

此时,我们的架构看起来是不是挺完美?且市面上标准的 Spring Cloud 架构都是这样做的。不过,这个架构会出现一些问题,下面我们先通过几个例子来看看。

案例一

在这个供应链系统中,很多界面都需要显示多个服务数据,比如在一个 App 首页中,针对门店运营人员,需要显示工单数量、最近的工单、销售订单数据、最近待处理的订单、低于库存安全值的商品等信息。

此时第一个问题来了,在接口设计过程中,我们经常纠结将两个客户端 App 调用的接口存放在哪个服务中?以至于决策效率低下,而且还会出现职责划分不统一的情况。

最终我们决定将第一个接口存放在门店服务中,此时调用关系如下图所示:

并将第二个接口存放在工单服务中,此时调用关系如下图所示:

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序,支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

案例二

一个用户的提交操作常常需要修改多个服务数据,比如一个提交工单的操作,我们需要修改库存、销售订单状态、工单等数据。

此时第二个问题出现了,因为这样的需求非常多,所以服务经常被其他多个服务调来调去,导致服务之间的依赖非常混乱,最终服务调用关系如下图所示:

通过上图,我们发现服务间的依赖问题给技术迭代带来了地狱般的体验,讲解,这里就不过多赘述。

为了解决这 2 个问题,最终我们决定抽象一个 API 层。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序,支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

API 层

一般来说,客户端的接口需要满足聚合、分布式调用、装饰这三种需求。

  • 聚合:一个接口需要聚合多个后台服务返回的数据,并将数据返回给客户端。
  • 分布式调用:一个接口可能需要依次调用多个后台服务,才能实现多个后台服务的数据修改。
  • 装饰:一个接口需要重新装饰后台返回的数据,比如删除一些字段或者对某些字段进行封装,然后组成客户端需要的数据。

因此,我们决定在客户端与后台服务之间增加一个新的 API 层,专门用来满足上面的三点需求,此时整个架构如下图所示。

从图中我们发现,所有请求经过网关后,全部交由一个共用的 API 层进行处理,而该 API 层没有自己的数据库,它的主要职责是调用其他后台服务。

通过这样的设计方案后,以上两个问题就得到了很多地解决。

  • 应该将某个接口放在哪个服务的纠结次数减少了 :如果是聚合、装饰、分布式的调用逻辑,我们直接把它们放在 API 层。如果是要落库或者查询数据库的逻辑,目标数据在哪个服务中,我们就把数据和逻辑放在哪个服务中。
  • 后台服务之间的依赖也大幅减少了 :目前的依赖关系只有 API 层调用各个后台服务。

此时,我们的设计方案完美了吧?别高兴得太早,还会出现新的问题。

客户端适配问题

在这个供应链系统中,一系列的接口主要供各种客户端(比如 App、H5、PC 网页、小程序等)进行调用,此时的调用关系如下图所示:

不过,这种设计方案会存在 3 个问题:

不同客户端的页面细节的需求可能不一样,比如 App 的功能比重大,就会要求页面中多放一些信息,而小程序的功能比重小,同样的页面就会要求少放一些信息,以至于后台服务中同一个 API 需要针对不同客户端实现不同适配;

客户端经常需要进行一些轻微的改动,比如增加一个字段/删除一个字段,此时我们必须采取数据最小化原则来缩减客户端接口的响应速度。而且,为了客户端这种细微而频繁的改动,后台服务经常需要同步发版;

结合 #1 和 #2 我们发现,在后台服务的发版过程中,常常需要综合考虑不同客户端的兼容问题,这无形中增加了 API 层为不同客户端做兼容的复杂度。

这时该如何解决呢?我们就可以考虑使用 BFF 了。

BFF(Backend for Front)

BFF 不是一个架构,而是一个设计模式,它的主要职责是为前端设计出优雅的后台服务,即一个 API。一般而言,每个客户端都有自己的 API 服务,此时整个架构如下图所示:

从上图可以看到:不同的客户端请求经过同一个网关后,它们都将分别重定向到为对应客户端设计的 API 服务中。因为每个 API 服务只能针对一种客户端,所以它们可以对特定的客户端进行专门优化。而去除了兼容逻辑的 API 显得更轻便,响应速度还比通用的 API 服务更快(因为它不需要判断不同客户端的逻辑)。

除此之外,每种客户端还可以实现自己发布,不需要再跟着其他客户端一起排期。

此时的方案挺完美了吧?还不完美,因为上面的方案属于一个通用架构。在实际业务中,我们还需要结合实际业务来定,下面我们深入说明一下实际业务需求。

前面我们列出了 5 种服务,实际上,整个供应链系统将近有 100 种服务。因为它是一个非常庞大的系统,且整个业务链条的所有工作都包含在这个系统中,比如新零售、供应链、财务、加盟商、售后、客服等,,这就需要几百号研发人员同时进行维护。

因为我们共同维护一个 App、PC 界面、新零售、售后、加盟商,还有各自的小程序和 H5,所以为了实现业务解耦和分开排期,每个部门需要各自维护自己的 API 服务,而且 App 与 PC 前端也需要根据部门实现组件化,此时的架构如下图所示。

针对以上需求,我们如何在技术架构上进行实现呢?下面具体来看看。

技术架构上如何实现?

我们的整套架构还是基于 Spring Cloud 设计的,如下图所示:

下面我们简单介绍下图中网关、API服务、后台服务的作用。

  • 网关:网关使用的是 Spring Cloud Zuul,Zuul 将拉取的注册存放在 ZooKeeper 的 API 服务中,然后通过 Feign 调用 API 服务。
  • API 服务:API 服务其实就是一个 Spring Web 服务,它没有自己的数据库,主要职责是聚合、分布式调用及装饰数据,并通过 Feign 调用后台服务。
  • 后台服务:后台服务其实也是一个 Spring Web 服务,它有自己的数据库和缓存。

此时的方案看着很完美了,不过它会出现 API 之间代码重复问题。此时我们该如何解决?且往下看

如何解决 API 之间代码重复问题?

虽然 H5 与小程序的布局不同,但是页面中很多功能一致,也就是说重复的代码逻辑主要存在 PC API 和 App API 中。

然而,针对重复代码的问题,不同部门在设计时会呈现 3 种不同的逻辑:

  • 某些部门将这些重复的代码存放在一个 JAR 中,让几个 API 服务实现共用;
  • 某些部门将这些重复的代码抽取出来,然后存放在一个叫 CommonAPI 的独立 API 服务中,其他 API 服务直接调用这个 Common API 就行;
  • 某些部门因为重复逻辑少,通过评估后,他们发现维护这些重复代码的成本小于维护 #1 中的 JAR 或者 #2 中的 CommonAPI 服务,所以会继续让这些重复代码存在。

假如某些 API 服务提供接口的出入参与后台服务的一致,此时该怎么办? 此时 API 服务的接口无须做任何事情,因为它只是一个简单的代理层。

于是,有同事提出:“每次一看到这些纯代理的 API 接口就不爽,我们能不能想办法把它们去掉。”办法倒是有几个,我们一起来看看。

  • 网关直接绕过 API 服务调用后台服务,不过这样就会破坏分层,所以很快被否掉了。
  • 在 API 服务层做一个拦截器,如果 URI 找不到对应 API 服务中的 controller mapping,就会直接通过 URI 找后台服务并进行调用。不过这种方式将大大增加系统的复杂度,出问题时调查起来更麻烦且收益不大。而写这些无脑代码不仅成本低,整体的接口列表还更可控。

综合考虑后,最终我们决定保留无脑的代码。

后台服务与 API 服务的开发团队如何进行分工?

最后我们是这样分工的:专门的 API 开发团队负责 API 服务,而后台服务需要根据领域再划分小组的职责。

这种划分方式的好处在于 API 团队能对所有服务有个整体认识,且不会出现后台服务划分不清晰、工作重复的情况。而坏处在于 API 团队整体业务逻辑偏简单,长久留不住人。



相关文章
|
4天前
|
存储 缓存 监控
探索微服务架构中的API网关模式
【10月更文挑战第1天】探索微服务架构中的API网关模式
28 2
|
20天前
|
安全 应用服务中间件 API
微服务分布式系统架构之zookeeper与dubbo-2
微服务分布式系统架构之zookeeper与dubbo-2
|
20天前
|
负载均衡 Java 应用服务中间件
微服务分布式系统架构之zookeeper与dubbor-1
微服务分布式系统架构之zookeeper与dubbor-1
|
2天前
|
Kubernetes 安全 微服务
使用 Istio 缓解电信 5G IoT 微服务 Pod 架构的安全挑战
使用 Istio 缓解电信 5G IoT 微服务 Pod 架构的安全挑战
21 8
|
5天前
|
消息中间件 负载均衡 Cloud Native
云原生之旅:从容器到微服务的架构演变
在数字化转型的风潮中,云原生技术以其灵活性、可扩展性和弹性而备受青睐。本文将通过一个虚拟的故事,讲述一个企业如何逐步拥抱云原生,实现从传统架构向容器化和微服务架构的转变,以及这一过程中遇到的挑战和解决方案。我们将以浅显易懂的方式,探讨云原生的核心概念,并通过实际代码示例,展示如何在云平台上部署和管理微服务。
|
22天前
|
JSON 监控 安全
探索微服务架构中的API网关模式
【9月更文挑战第22天】在微服务架构的海洋中,API网关如同一位智慧的守门人,不仅管理着服务的进出,还维护着整个系统的秩序。本文将带你一探究竟,看看这位守门人是如何工作的,以及它为何成为现代云原生应用不可或缺的一部分。从流量控制到安全防护,再到服务聚合,我们将一起解锁API网关的秘密。
|
1月前
|
运维 Cloud Native Devops
云原生架构的崛起与实践云原生架构是一种通过容器化、微服务和DevOps等技术手段,帮助应用系统实现敏捷部署、弹性扩展和高效运维的技术理念。本文将探讨云原生的概念、核心技术以及其在企业中的应用实践,揭示云原生如何成为现代软件开发和运营的主流方式。##
云原生架构是现代IT领域的一场革命,它依托于容器化、微服务和DevOps等核心技术,旨在解决传统架构在应对复杂业务需求时的不足。通过采用云原生方法,企业可以实现敏捷部署、弹性扩展和高效运维,从而大幅提升开发效率和系统可靠性。本文详细阐述了云原生的核心概念、主要技术和实际应用案例,并探讨了企业在实施云原生过程中的挑战与解决方案。无论是正在转型的传统企业,还是寻求创新的互联网企业,云原生都提供了一条实现高效能、高灵活性和高可靠性的技术路径。 ##
71 3
|
1月前
|
监控 负载均衡 应用服务中间件
探索微服务架构下的API网关设计与实践
在数字化浪潮中,微服务架构以其灵活性和可扩展性成为企业IT架构的宠儿。本文将深入浅出地介绍微服务架构下API网关的关键作用,探讨其设计原则与实践要点,旨在帮助读者更好地理解和应用API网关,优化微服务间的通信效率和安全性,实现服务的高可用性和伸缩性。
47 3
|
1月前
|
存储 Java Maven
从零到微服务专家:用Micronaut框架轻松构建未来架构
【9月更文挑战第5天】在现代软件开发中,微服务架构因提升应用的可伸缩性和灵活性而广受欢迎。Micronaut 是一个轻量级的 Java 框架,适合构建微服务。本文介绍如何从零开始使用 Micronaut 搭建微服务架构,包括设置开发环境、创建 Maven 项目并添加 Micronaut 依赖,编写主类启动应用,以及添加控制器处理 HTTP 请求。通过示例代码展示如何实现简单的 “Hello, World!” 功能,并介绍如何通过添加更多依赖来扩展应用功能,如数据访问、验证和安全性等。Micronaut 的强大和灵活性使你能够快速构建复杂的微服务系统。
67 5
|
19天前
|
Kubernetes Go Docker
掌握微服务架构:从Go到容器化的旅程
摘要,通常简短概述文章内容,要求精炼。在本文中,我们将打破常规,采用一种故事化叙述的摘要,旨在激发读者的好奇心和探究欲: “从宁静的海滨小城出发,我们踏上了一场技术探险之旅,探索微服务架构的奥秘。我们将学习如何用Go编写微服务,以及如何通过Docker和Kubernetes将它们打包进小巧的容器中。在这场旅程中,我们将遇到挑战、收获知识,最终实现应用的快速部署与可扩展性。”