0

我们的系统是使用微服务构建的，所有微服务都位于 API 网关后面。由于它们都是 REST API 服务，我很清楚使用 API 网关的好处和重点。现在，前端微服务（既具有 UI 又具有相应后端来处理内部通信的小组件）呢？是否存在代理每个微服务 HTTP 调用有害的情况？

例子

我们的微服务之一是支付提供商集成。由于处理支付有特定的规定，其中之一是需要将网络浏览器重定向到用户的银行页面以进行授权。由于这不可能以纯粹的后端方式进行，因此我们提供前端微服务- 一种本质上提供 HTML 的服务，您必须嵌套在 iframe 中，并且应该能够以 e2e 方式处理付款。下面是非常简化和剥离的示例。

假设您正在使用https://acme.com/order并想要付款，其中嵌入了这样的代码段：

<iframe src="https://pay.acme.com?amount=42+USD
                                 &returnUrl=https://acme.com/thankyou/[orderId]">
</iframe>

对于https://acme.com. iframe 内部发生的事情会保留在那里。https://pay.acme.com但是现在担心：收集信用卡详细信息，验证它们，将用户重定向到银行页面以输入 2FA 代码或任何需要的内容，等到付款被批准，最后将用户返回到returnUrl付款顺序的正确路径最终确定（orderId）。

现在，pay.acme.com frontend <-> pay.acme.com backend沟通呢？是否可以让微服务与自己对话，或者更确切地说，所有的，甚至是对 API 消费者没有任何意义的内部通信，都必须通过 API 网关？这当然是可以做到的，并且仍然保持微服务解耦并且不知道 API 网关，但这比偏离始终执行约束并带来非常小的好处要昂贵得多，因为我们不使用任何高级速率限制或现在代理功能。

4

1 回答 1

1

有一个简单的方法 - 拥有 UI 网关。代替 API 调用的网关将路由和代理资产请求调用（静态文件服务）。

如果实体属于相同的有界上下文 ( pay.acme.com frontend <-> pay.acme.com backend)，它们绝对应该作为单个后端微服务存在，服务于以下之一：

  • 同构js
  • 具有实时重新加载功能的瘦客户端应用程序（然后 UI 网关将需要代理ws连接）
  • 胖客户端应用程序 (SPA)

此类微服务是常规微服务，其 API（如果存在）应可通过 API 网关访问，并且 UI 应通过 UI 代理/网关代理。

希望有帮助。

于 2017-09-11T19:32:16.107 回答