☰

微服务应用程序架构

tag-icon • tag-icon azure docker kubernetes infrastructure architecture
微服务应用程序架构

我不确定这是否是一个适合询问有关基础设施架构问题的论坛。但发布问题希望如此：

我的一位客户有一个采用最新微服务技术开发的 Web 应用程序。Kubernetes 是底层。他们在顶层使用 CDN、API 托管等。现在，从公共云（Azure 或 AWS）的角度来看，我该如何在此构建基础设施？我有几个关于他们使用的服务的问题。为简单起见，我将从 Azure POV 的角度进行讨论。决定使用 Azure 中的以下组件：

Azure CDN、Azure 应用程序网关、Azure FrontDoor。

我对这些服务的调用流程感到困惑。从客户端（如 Web 浏览器）发出对应用程序的请求时，理想情况下，静态内容需要由 Azure CDN 响应，而其他动态内容则需要通过检查容器或服务器来响应。因此，这就是我对调用流程的假设：

浏览器 -> Azure Front Door -> 应用程序网关 -> API 管理微服务 -> 其他微服务 -> Azure CDN -> 浏览器

这是正确的吗？如果不正确，您能指导我了解更好的架构吗？任何帮助都将不胜感激。

答案1

好的，首先，您有几个不同的服务在做同样的事情，所以您要评估是否需要它们全部。

  • Azure CDN 和 Front Door 都提供相同的本地接入点和缓存，因此你实际上只需要其中一个
  • Azure Front Door 和 App Gateway 都提供第 7 层负载平衡和 Web 应用程序防火墙，因此您可能不需要两者。App GW 确实有一些额外的功能，例如 vNet 附件和 K8s Ingress，因此两者可能都有争议

无论您选择 Front Door 还是 CDN，它们都希望位于堆栈的最前端。理想情况下，您希望流量到达 FD/CDN，获得缓存响应，然后结束请求。

如果您无法从缓存提供服务，那么现在您需要将流量引入 Kubernetes，因此您的堆栈前端资源（CDN 或 Front Door）现在将转发到您向外界公开 Kubernetes 集群的方式。如果您决定需要它，这可能是 App Gateway，外部负载均衡器或 Azure API Manager（如果您使用它来公开 API）。

Front Door 是一项未连接到 vNet 的全局服务。您的 Kubernetes 集群已连接到 vNet，因此您需要一种方法来将您的 Kubernetes 资源公开给 Front Door。这可以通过 App GW 来完成，但这会增加额外的费用，您也可以使用具有公共 IP 的 Azure 负载均衡器设置您的 Kubernetes 入口，然后让 Front Door 与其通信。

如果您摆脱了 App GW，那么您将需要在您的集群中运行另一个入口控制器，例如 NGinx、Traefik 等。或者，您可以保留 App GW，但我会使用 CDN 而不是 Front Door。

Front Door 和 CDN 使用相同的端点，因此提供相同的缓存。

相关内容