BFF 实现 - zilor-net/eShopOnContainers-CN-Wiki GitHub Wiki

当前实现的 BFF 模式如下图所示：

**注意：**这个架构只显示了一个 BFF。每种客户端类型（Web端和移动端）都有自己的BFF。

BFF 由两个容器组成：一个 Envoy 代理和一个自定义聚合器（注意：营销 BFF 没有自定义聚合器，因为它没有任何复杂的逻辑）。

Envoy

Envoy 代理充当 BFF 的入口，并为客户端提供一个单一的 URL。所有的客户端调用都要通过 Envoy 代理。因此，根据某些规则，Envoy 代理可以:

将调用转发到自定义聚合器。
将调用直接转发到内部微服务。

自定义聚合器

自定义聚合器是另一个容器，它公开了 HTTP/JSON API，具有复杂的方法，涉及到来自各种内部微服务的数据。

自定义聚合器的每个方法都调用一个（或多个）内部微服务，并将聚合（应用自定义逻辑）后的结果数据返回给客户端。

从聚合器到微服务的所有调用都使用 gRPC 执行（图中的虚线）。

客户端应用

客户端应用程序仅通过 Envoy 代理公开的单一 URL 调用 BFF。

对于请求数据，会将请求转发到内部微服务（单个CRUD调用）或自定义聚合器（复杂逻辑调用），这对客户端是透明的。

当调用直接从 Envoy 转发到内部微服务时，它会使用 HTTP/JSON 执行。也就是说，目前，内部微服务公开了多种方法：一些在 gRPC 中（由聚合器调用），一些在 HTTP/JSON 中（由Envoy调用）。这在未来可能会发生变化（所有的微服务方法都应该使用 gRPC 调用，如果需要的话，Envoy 可以在 gRPC 和 HTTP/JSON 之间自动转换)。