客户端可以绕过API网关调用前端微服务吗？答案

【问题标题】：Can client-side call frontend microservices bypassing API gateway?客户端可以绕过API网关调用前端微服务吗？
【发布时间】：2018-02-19 12:56:39
【问题描述】：

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

示例

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

假设您在https://acme.com/order 上并想付款，其中嵌入了这样的 sn-p：

<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 网关，但这比偏离 always do 约束并带来非常小的好处要昂贵得多，因为我们不这样做'暂时不要使用任何高级速率限制或代理功能。

【问题讨论】：

标签： iframe architecture microservices api-gateway

【解决方案1】：

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

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

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

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

希望对您有所帮助。

【讨论】：