在我们之前设计的一个供应链系统中，它包含了商品、销售订单、加盟商、门店运营、门店工单等服务，涉及了各种用户角色，比如总部商品管理、总部门店管理、加盟商员工、门店人员等，而且每个部门的角色还会进行细分。而且这个系统中还包含了两个客户端 App：一个面向客户，另一个面向公司员工和加盟商。
此时，整个供应链系统的架构如下图所示：
上图中的网关层主要负责路由、认证、监控、限流熔断等工作。
路由：所有的请求都需要通过网关层进行处理，网关层再根据 URI 将请求指向对应的后台服务，如果同一个服务存在多个服务器节点，网关层还将承担负载均衡的工作。 监控：记录所有的 API 请求数据，API 管理系统能对 API 调用实现管理和性能监控。 限流熔断：流量过大时，我们可以在网关层实现限流。如果后台服务响应延时或故障，我们可以主动在调用端的上游服务做熔断，以此保护后端服务资源，同时不影响用户体验。 此时，我们的架构看起来是不是挺完美？且市面上标准的 Spring Cloud 架构都是这样做的。不过，这个架构会出现一些问题，下面我们先通过几个例子来看看。
在这个供应链系统中，很多界面都需要显示多个服务数据，比如在一个 App 首页中，针对门店运营人员，需要显示工单数量、最近的工单、销售订单数据、最近待处理的订单、低于库存安全值的商品等信息。
此时第一个问题来了，在接口设计过程中，我们经常纠结将两个客户端 App 调用的接口存放在哪个服务中？以至于决策效率低下，而且还会出现职责划分不统一的情况。
最终我们决定将第一个接口存放在门店服务中，此时调用关系如下图所示：
并将第二个接口存放在工单服务中，此时调用关系如下图所示：
基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
项目地址：https://gitee.com/zhijiantianya/ruoyi-vue-pro 视频教程：https://doc.iocoder.cn/video/ 一个用户的提交操作常常需要修改多个服务数据，比如一个提交工单的操作，我们需要修改库存、销售订单状态、工单等数据。
此时第二个问题出现了，因为这样的需求非常多，所以服务经常被其他多个服务调来调去，导致服务之间的依赖非常混乱，最终服务调用关系如下图所示：
通过上图，我们发现服务间的依赖问题给技术迭代带来了地狱般的体验，讲解，这里就不过多赘述。
为了解决这 2 个问题，最终我们决定抽象一个 API 层。
基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
项目地址：https://gitee.com/zhijiantianya/yudao-cloud 视频教程：https://doc.iocoder.cn/video/ 一般来说，客户端的接口需要满足聚合、分布式调用、装饰这三种需求。
聚合：一个接口需要聚合多个后台服务返回的数据，并将数据返回给客户端。 分布式调用：一个接口可能需要依次调用多个后台服务，才能实现多个后台服务的数据修改。 装饰：一个接口需要重新装饰后台返回的数据，比如删除一些字段或者对某些字段进行封装，然后组成客户端需要的数据。 因此，我们决定在客户端与后台服务之间增加一个新的 API 层，专门用来满足上面的三点需求，此时整个架构如下图所示。
从图中我们发现，所有请求经过网关后，全部交由一个共用的 API 层进行处理，而该 API 层没有自己的数据库，它的主要职责是调用其他后台服务。
通过这样的设计方案后，以上两个问题就得到了很多地解决。
应该将某个接口放在哪个服务的纠结次数减少了 ：如果是聚合、装饰、分布式的调用逻辑，我们直接把它们放在 API 层。如果是要落库或者查询数据库的逻辑，目标数据在哪个服务中，我们就把数据和逻辑放在哪个服务中。后台服务之间的依赖也大幅减少了 ：目前的依赖关系只有 API 层调用各个后台服务。此时，我们的设计方案完美了吧？别高兴得太早，还会出现新的问题。
在这个供应链系统中，一系列的接口主要供各种客户端（比如 App、H5、PC 网页、小程序等）进行调用，此时的调用关系如下图所示：
不过，这种设计方案会存在 3 个问题：
不同客户端的页面细节的需求可能不一样，比如 App 的功能比重大，就会要求页面中多放一些信息，而小程序的功能比重小，同样的页面就会要求少放一些信息，以至于后台服务中同一个 API 需要针对不同客户端实现不同适配；
客户端经常需要进行一些轻微的改动，比如增加一个字段/删除一个字段，此时我们必须采取数据最小化原则来缩减客户端接口的响应速度。而且，为了客户端这种细微而频繁的改动，后台服务经常需要同步发版；
结合 #1 和 #2 我们发现，在后台服务的发版过程中，常常需要综合考虑不同客户端的兼容问题，这无形中增加了 API 层为不同客户端做兼容的复杂度。
这时该如何解决呢？我们就可以考虑使用 BFF 了。
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 之间代码重复问题。此时我们该如何解决？且往下看
虽然 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 团队整体业务逻辑偏简单，长久留不住人。
