客户端直接访问服务会导致很多问题：

多次客户端请求导致用户体验不佳：因为客户端到服务之间是互联网（带宽低，时延高），而服务之间是局域网（带宽高，时延低）。多次客户端直接到服务的请求均通过互联网传输，传输时延高。
客户端与服务耦合度高：因为客户端与服务是直接请求的，所以做出的任何更改都会影响到彼此。
服务可能选用对客户端不友好的进程间通信机制：一般而言，客户端使用的通信协议通常是 HTTP 或者 WebSockets 等协议，而服务选用的通信协议可能是 gRPC，RPC 通信对客户端是不友好的，甚至无法穿透防火墙。

所以可以采用 API Gateway 或者后端前置的方式。

API Gateway

把 API Gateway 作为外部客户端请求的唯一入口点，它为客户端提供 API，也可以进行身份认证、充当 API 组合器、传输协议转换等职责。

可以把 API Gateway 看作是面向设计中的外观模式，它封装了内部架构，并为客户端提供API。

作用

下面说明 API Gateway 的典型作用。

将客户端的请求路由到相应的服务中，来实现一些 API 操作，这与反向代理的功能类似。

API Gateway 也可以作为 API 组合器，它通过对内通过对多个服务的查询、并且将查询结果聚合，来实现对外提供粗粒度的 API。

API Gateway 可以实现协议转换，它可以对外提供 HTTP RESTful API，内部使用 gRPC 进行通信。

边缘功能包括：身份认证、访问授权、速率限制、缓存、请求日志等。

API Gateway 具有分层的模块化架构，由两层组成：API 层和公共层。API 层由一个或者多个独立的 API 模块组成，每个 API 模块都为特定的客户端实现 API。公共层实现共享的功能，如身份认证等。

在 API Gateway 的 API 层，不同客户端团队可以维护各自的 API 模块，这样的一个问题就是职责不明确。多个团队为相同的代码块提交代码，Gateway 团队负责运维。

解决方案就是为每一个客户端提供一个 API Gateway，即后端前置（Backends for front-ends，BFF）。每一个 API 模块都有自己的 API Gateway，由相应的团队进行开发和运维。

BFF 的好处就是：