在我们之前设计的一个供应链系统中，它包含了商品、销售订单、加盟商、门店运营、门店工单等服务，涉及了各种用户角色，比如总部商品管理、总部门店管理、加盟商员工、门店人员等，而且每个部门的角色还会进行细分。而且这个系统中还包含了两个客户端 App：一个面向客户，另一个面向公司员工和加盟商。
此时，整个供应链系统的架构如下图所示：
上图中的网关层主要负责路由、认证、监控、限流熔断等工作。
此时，我们的架构看起来是不是挺完美？且市面上标准的 Spring Cloud 架构都是这样做的。不过，这个架构会出现一些问题，下面我们先通过几个例子来看看。
在这个供应链系统中，很多界面都需要显示多个服务数据，比如在一个 App 首页中，针对门店运营人员，需要显示工单数量、最近的工单、销售订单数据、最近待处理的订单、低于库存安全值的商品等信息。
此时第一个问题来了，在接口设计过程中，我们经常纠结将两个客户端 App 调用的接口存放在哪个服务中？以至于决策效率低下，而且还会出现职责划分不统一的情况。
最终我们决定将第一个接口存放在门店服务中，此时调用关系如下图所示：
并将第二个接口存放在工单服务中，此时调用关系如下图所示：
一个用户的提交操作常常需要修改多个服务数据，比如一个提交工单的操作，我们需要修改库存、销售订单状态、工单等数据。
此时第二个问题出现了，因为这样的需求非常多，所以服务经常被其他多个服务调来调去，导致服务之间的依赖非常混乱，最终服务调用关系如下图所示：
通过上图，我们发现服务间的依赖问题给技术迭代带来了地狱般的体验，关于这点我们已经在 15 讲中进行了细致讲解，这里就不过多赘述。
为了解决这 2 个问题，最终我们决定抽象一个 API 层。
一般来说，客户端的接口需要满足聚合、分布式调用、装饰这三种需求。
因此，我们决定在客户端与后台服务之间增加一个新的 API 层，专门用来满足上面的三点需求，此时整个架构如下图所示。
从图中我们发现，所有请求经过网关后，全部交由一个共用的 API 层进行处理，而该 API 层没有自己的数据库，它的主要职责是调用其他后台服务。
通过这样的设计方案后，以上两个问题就得到了很多地解决。
此时，我们的设计方案完美了吧？别高兴得太早，还会出现新的问题。
在这个供应链系统中，一系列的接口主要供各种客户端（比如 App、H5、PC 网页、小程序等）进行调用，此时的调用关系如下图所示：
不过，这种设计方案会存在三个问题：
这时该如何解决呢？我们就可以考虑使用 BFF 了。
BFF 不是一个架构，而是一个设计模式，它的主要职责是为前端设计出优雅的后台服务，即一个 API。一般而言，每个客户端都有自己的 API 服务，此时整个架构如下图所示：
从上图可以看到：不同的客户端请求经过同一个网关后，它们都将分别重定向到为对应客户端设计的 API 服务中。因为每个 API 服务只能针对一种客户端，所以它们可以对特定的客户端进行专门优化。而去除了兼容逻辑的 API 显得更轻便，响应速度还比通用的 API 服务更快（因为它不需要判断不同客户端的逻辑）。
除此之外，每种客户端还可以实现自己发布，不需要再跟着其他客户端一起排期。
此时的方案挺完美了吧？还不完美，因为上面的方案属于一个通用架构。在实际业务中，我们还需要结合实际业务来定，下面我们深入说明一下实际业务需求。
前面我们列出了 5 种服务，实际上，整个供应链系统将近有 100 种服务。因为它是一个非常庞大的系统，且整个业务链条的所有工作都包含在这个系统中，比如新零售、供应链、财务、加盟商、售后、客服等，，这就需要几百号研发人员同时进行维护。
因为我们共同维护一个 App、PC 界面、新零售、售后、加盟商，还有各自的小程序和 H5，所以为了实现业务解耦和分开排期，每个部门需要各自维护自己的 API 服务，而且 App 与 PC 前端也需要根据部门实现组件化，此时的架构如下图所示。
针对以上需求，我们如何在技术架构上进行实现呢？下面具体来看看。
我们的整套架构还是基于 Spring Cloud 设计的，如下图所示：
下面我们简单介绍下图中网关、API服务、后台服务的作用。
此时的方案看着很完美了，不过它会出现 API 之间代码重复问题。此时我们该如何解决？且往下看。
虽然 H5 与小程序的布局不同，但是页面中很多功能一致，也就是说重复的代码逻辑主要存在 PC API 和 App API 中。
然而，针对重复代码的问题，不同部门在设计时会呈现 3 种不同的逻辑：
假如某些 API 服务提供接口的出入参与后台服务的一致，此时该怎么办？ 此时 API 服务的接口无须做任何事情，因为它只是一个简单的代理层。
于是，有同事提出：“每次一看到这些纯代理的 API 接口就不爽，我们能不能想办法把它们去掉。”办法倒是有几个，我们一起来看看。
网关直接绕过 API 服务调用后台服务，不过这样就会破坏分层，所以很快被否掉了。
在 API 服务层做一个拦截器，如果 URI 找不到对应 API 服务中的 controller mapping，就会直接通过 URI 找后台服务并进行调用。不过这种方式将大大增加系统的复杂度，出问题时调查起来更麻烦且收益不大。而写这些无脑代码不仅成本低，整体的接口列表还更可控。
综合考虑后，最终我们决定保留无脑的代码。
最后我们是这样分工的：专门的 API 开发团队负责 API 服务，而后台服务需要根据领域再划分小组的职责。
这种划分方式的好处在于 API 团队能对所有服务有个整体认识，且不会出现后台服务划分不清晰、工作重复的情况。而坏处在于 API 团队整体业务逻辑偏简单，长久留不住人。
本文链接：http://www.28at.com/showinfo-26-85542-0.html如何处理好微服务之间千丝万缕的关系？到BFF大显身手了
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
上一篇： C# 读写 JSON 配置文件详解
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号
