Iframe 客户端能否绕过API网关调用前端微服务？

我们的系统是使用微服务构建的，这些微服务都位于API网关之后。因为所有这些都是RESTAPI服务，所以我很清楚使用API网关的好处和要点。那么前端微服务呢？它是一种小型组件，既有用户界面又有相应的后端来处理内部通信？是否存在代理每个微服务HTTP调用都有害的情况

示例

我们的微服务之一是支付提供商集成。由于处理付款有特定的规定，其中之一是必需的web浏览器重定向到用户的银行页面进行授权。由于这不可能用纯后端的方式实现，我们提供了一个前端微服务——这是一个基本上服务于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代码或任何需要的内容，等待付款获得批准，最后将用户移回

返回URL

，并提供完成付款的正确线索（

orderId

）

---

现在，关于

pay.acme.com frontend pay.acme.com backend

communication呢？让微服务自言自语，或者更确切地说，所有对API消费者没有任何意义的内部通信都必须通过API网关吗？这当然是可能的，并且仍然保持微服务的解耦和unaware的API网关，但这比偏离always do约束要昂贵得多，带来的好处非常小，因为我们现在不使用任何高级速率限制或代理功能。

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

如果实体属于同一个有界上下文（

pay.acme.com frontend pay.acme.com backend

），则它们肯定应作为单一后端微服务存在，服务于以下各项之一：

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

  ws

  连接）
• 厚客户端应用程序（SPA）

这种微服务是常规的微服务，API（如果存在）应该可以通过API网关访问，UI应该通过UI代理/网关代理

希望有帮助