将 url 路径重写为 API 的子域答案

【问题标题】：Rewrite url path to sub domain for API将 url 路径重写为 API 的子域
【发布时间】：2021-08-07 06:59:53
【问题描述】：

我正在使用 azure 流量管理器，但我的 api 在主要的 simian A 记录上。但是我需要一个来利用 Azure 流量管理器。

我的问题是我可以从 API 的当前路径到下面的子域执行 GET 和 POST 吗？如果可以，最好的方法是什么？

当前 API 路径

新的 API 路径（重写？）

解决方案是否存在任何性能问题？我有 500 多个应用程序，无法手动更新每个应用程序的网址。

【问题讨论】：

我建议你使用 URL 重写模块。关于“URL Rewrite 2.0 Performance”的信息，可以参考这篇博客：blogs.iis.net/danielvl/url-rewrite-2-0-performance
我想帮忙，但这个问题（至少对我来说）很难理解...However I need a came to take advantage...这是一个错字吗？一般来说，进行 IIS 级别的重写不应该有性能问题，但很明显，如果您必须设置相同的重写 500 次以上，那将是一个问题。您是否有 500 多个应用程序实例，或者您是否正在重写不同的应用程序？
我不需要做同样的重写 500 次。我是说 500 多个应用程序使用端点 test.com/mobile/v1/api... 但我希望他们使用 api.test.com/mobile/v1/api... 代替。

【解决方案1】：

这里有几件事。如果您有通配符 A 记录，请记住，您还需要通配符 SSL（但这不是重点）。

您的网关/代理/负载平衡器应该像处理“WWW”一样处理子域的路由/负载平衡；毕竟“WWW”只是另一个子域。

至于如何设置/配置，这取决于您使用的网关/代理/负载均衡器。在您使用的工具中查看“路由”的配置。

【讨论】：

我用的是 IIS，SSL 没问题。
迈克，IIS 是服务器。嗯......因为我只知道开源（即 Apache、Tomcat、Nginx 等），所以除非你有 Nginx 或 IIS 前面的东西充当代理，否则我无能为力。

【解决方案2】：

据我了解，您正在寻找一种可扩展的解决方案，该解决方案允许 N 个应用程序使用相同的配置值来定位服务。

我建议使用服务发现或集中配置。 “集中式配置”有点不言自明，服务发现是您的应用知道服务名称（例如：“the-api”）并在运行时从发现服务器获取位置的地方。

如果您想坚持使用基于配置的方法，Azure 有您可以使用的a configuration server，或者您可以使用Spring Cloud Config Server 和Steeltoe client for SCCS。

如果您想尝试服务发现方法，Steeltoe 可以选择 Netflix Eureka 和 HashiCorp Consul

【讨论】：