软件后台服务作用 第1篇
BFF 不是一个架构，而是一个设计模式，它的主要职责是为前端设计出优雅的后台服务，即一个 API。一般而言，每个客户端都有自己的 API 服务，此时整个架构如下图所示
从上图可以看到：不同的客户端请求经过同一个网关后，它们都将分别重定向到为对应客户端设计的 API 服务中。因为每个 API 服务只能针对一种客户端，所以它们可以对特定的客户端进行专门优化。而去除了兼容逻辑的 API 显得更轻便，响应速度还比通用的 API 服务更快（因为它不需要判断不同客户端的逻辑）
除此之外，每种客户端还可以实现自己发布，不需要再跟着其他客户端一起排期
此时的方案挺完美了吧？还不完美，因为上面的方案属于一个通用架构。在实际业务中，还需要结合实际业务来定，下面深入说明一下实际业务需求
前面列出了 5 种服务，实际上，整个供应链系统将近有 100 种服务。因为它是一个非常庞大的系统，且整个业务链条的所有工作都包含在这个系统中，比如新零售、供应链、财务、加盟商、售后、客服等，这就需要几百号研发人员同时进行维护
因为共同维护一个 App、PC 界面、新零售、售后、加盟商，还有各自的小程序和 H5，所以为了实现业务解耦和分开排期，每个部门需要各自维护自己的 API 服务，而且 App 与 PC 前端也需要根据部门实现组件化，此时的架构如下图所示
软件后台服务作用 第2篇
一般来说，客户端的接口需要满足聚合、分布式调用、装饰这三种需求
因此，决定在客户端与后台服务之间增加一个新的 API 层，专门用来满足上面的三点需求，此时整个架构如下图所示
从图中我们发现，所有请求经过网关后，全部交由一个共用的 API 层进行处理，而该 API 层没有自己的数据库，它的主要职责是调用其他后台服务
通过这样的设计方案后，以上两个问题就得到了很多地解决
软件后台服务作用 第3篇
虽然 H5 与小程序的布局不同，但是页面中很多功能一致，也就是说重复的代码逻辑主要存在 PC API 和 App API 中
然而，针对重复代码的问题，不同部门在设计时会呈现 3 种不同的逻辑
假如某些 API 服务提供接口的出入参与后台服务的一致，此时该怎么办？ 此时 API 服务的接口无须做任何事情，因为它只是一个简单的代理层
于是，有人提出：“每次一看到这些纯代理的 API 接口就不爽，能不能想办法把它们去掉。”办法倒是有几个，一起来看看
综合考虑后，最终决定保留无脑的代码
专门的 API 开发团队负责 API 服务，而后台服务需要根据领域再划分小组的职责
这种划分方式的好处在于 API 团队能对所有服务有个整体认识，且不会出现后台服务划分不清晰、工作重复的情况。而坏处在于 API 团队整体业务逻辑偏简单，长久留不住人