在Azure中路由数千个子域时使用什么？
我们在Microsoft Azure的多个环境中托管了一个应用程序。我们希望根据子域来路由流量，比如xxx.mydomain.com应该转到我在北欧的webapp，yyy.mydomain.com和zzz.mydomain.com应该转到我在美国东部的webapp 我知道这听起来像是简单的DNS，但不仅仅是这样。因为： 我需要能够使用代码动态添加或更新条目，这样就可以使用API来实现这一点。 正常的DNS条目有24小时的生存时间，这意味着如果我想将我的应用程序从一个环境移动到另一个环境，最多24小时，用户将同时访问两个环境。 我希望有几十万个子域。Azure DNS限制25000个条目。 我已经调查了Azure交通管理器。它似乎没有基于子域的流量选项。 此外，我还研究了Azure应用程序网关。这似乎是正确的选择，它支持API，但我找不到子域的限制在Azure中路由数千个子域时使用什么？,azure,routes,url-routing,Azure,Routes,Url Routing,我们在Microsoft Azure的多个环境中托管了一个应用程序。我们希望根据子域来路由流量，比如xxx.mydomain.com应该转到我在北欧的webapp，yyy.mydomain.com和zzz.mydomain.com应该转到我在美国东部的webapp 我知道这听起来像是简单的DNS，但不仅仅是这样。因为： 我需要能够使用代码动态添加或更新条目，这样就可以使用API来实现这一点。 正常的DNS条目有24小时的生存时间，这意味着如果我想将我的应用程序从一个环境移动到另一个环境，最多24
有什么建议吗？Azure Application Gateway确实可能是您的场景的最佳选择之一。 正如您已经说过的，它有一个api，您可以使用它根据子域动态添加规则 应用程序网关的限制仅允许每个网关有200条规则。 但是，每个订阅可以有1000个网关，因此，如果可以链接这些网关，将提供大约200.000条规则。 微软的文档没有显示你可以要求增加这些限制，但是如果你真的要求增加限制，微软可能会允许
也许这不是您问题的答案，但可能是一个答案。Azure应用程序网关确实可能是您场景的最佳选项之一。 正如您已经说过的，它有一个api，您可以使用它根据子域动态添加规则 应用程序网关的限制仅允许每个网关有200条规则。 但是，每个订阅可以有1000个网关，因此，如果可以链接这些网关，将提供大约200.000条规则。 微软的文档没有显示你可以要求增加这些限制，但是如果你真的要求增加限制，微软可能会允许
也许这不是您问题的答案，但它可能是一个答案。从标准来看，您似乎在寻找一个可以通过API控制的负载平衡器/代理/应用程序交付控制器解决方案。我将在这里加上我的5美分，因为我们刚刚经历了非常类似的问题。然而，这些建议更多的是在Azure之外的其他地方寻找答案 蔚蓝 Azure Traffic Manager或Azure Application Gateway具有您无法适应的限制。例如，在具有200条规则的Azure Application Gateway中，您可能只能承载200个HTTPS站点，当您需要提供HTTP和HTTPS服务时，每个应用程序网关只能承载100个站点。您需要在多个订阅中拆分解决方案，以满足订阅范围的限制。此外，应用程序网关API对我来说有点太复杂了 Azure DNS也有点问题，因为DNS记录最多可以持续24小时。因此，您将失去立即将流量切换/路由到不同来源的能力 自托管 您可以研究更多的老式解决方案，运行HAProxy或Nginx，动态地以编程方式修改它们的configurationtext文件并重新加载配置。HAPRoxy还有一个可以简化配置修改和重新加载的功能 还有一组新的服务网格控制器，例如，可以在云中本机运行，用于服务网格解决方案，但是Kong提供了一个简单的API，您可以轻松地管理/路由流量 SaaS
如果您想将其作为一项服务购买，那么Cloudflare、Fastly或其他边缘云提供商确实是一个大型代理服务器，可以通过编程方式对其进行配置，将流量路由到不同的来源，这毕竟是他们所做的。根据标准，您似乎正在寻找一种通过API可以控制的负载平衡器/代理/应用程序交付控制器解决方案。我将在这里加上我的5美分，因为我们刚刚经历了非常类似的问题。然而，这些建议更多的是在Azure之外的其他地方寻找答案 蔚蓝 Azure Traffic Manager或Azure Application Gateway具有您无法适应的限制。例如，在具有200条规则的Azure Application Gateway中，您可能只能承载200个HTTPS站点，当您需要提供HTTP和HTTPS服务时，每个应用程序网关只能承载100个站点。您需要在多个订阅中拆分解决方案，以满足订阅范围的限制。此外，应用程序网关API对我来说有点太复杂了 Azure DNS也有点问题，因为DNS记录最多可以持续24小时。因此，你应该 失去立即将流量切换/路由到不同来源的能力 自托管 您可以研究更多的老式解决方案，运行HAProxy或Nginx，动态地以编程方式修改它们的configurationtext文件并重新加载配置。HAPRoxy还有一个可以简化配置修改和重新加载的功能 还有一组新的服务网格控制器，例如，可以在云中本机运行，用于服务网格解决方案，但是Kong提供了一个简单的API，您可以轻松地管理/路由流量 SaaS
如果您想将其作为一项服务购买，那么Cloudflare、Fastly或其他边缘云提供商确实是一个大型代理服务器，可以通过编程方式对其进行配置，将流量路由到不同的来源，这毕竟是他们所做的。如果有人感兴趣，我们最终使用的是Azure DNS。我们已经联系了微软，他们确认他们可以将配额增加到500000，这对我们来说已经足够了 如果有人感兴趣，我们最终使用了Azure DNS。我们已经联系了微软，他们确认他们可以将配额增加到500000，这对我们来说已经足够了 我认为解决方案是Azure DNS，但你必须与MSFT联系，询问他们是否可以在你的案例中增加子域的数量这是一个边缘案例，因此你应该联系MS寻求一些指导。我认为解决方案是Azure DNS，但是你必须联系微软，询问他们是否可以增加你案例中的子域数量这是一个边缘案例，所以你应该联系微软寻求一些指导。非常感谢你的回复。这是非常详细和有用的。您在您的案例中使用了哪一个，您对您的决定仍然满意吗？有什么隐藏的缺点吗我已经投票决定我们还没有投入生产，但计划使用Cloudflare，因为我们也将使用他们的缓存。对于缺点和优点。。。当然，在选择自托管vs SaaS产品时有一些明显的问题。控制与操作/可维护性、成本。。。你说吧。我想指出的是，您计划在哪里进行TLS终止和证书管理还有一个额外的问题。您希望在这个中间件中有多少日志记录和可扩展性？日志记录、身份验证/授权、请求限制等。非常感谢您的响应。这是非常详细和有用的。您在您的案例中使用了哪一个，您对您的决定仍然满意吗？有什么隐藏的缺点吗我已经投票决定我们还没有投入生产，但计划使用Cloudflare，因为我们也将使用他们的缓存。对于缺点和优点。。。当然，在选择自托管vs SaaS产品时有一些明显的问题。控制与操作/可维护性、成本。。。你说吧。我想指出的是，您计划在哪里进行TLS终止和证书管理还有一个额外的问题。您希望在这个中间件中有多少日志记录和可扩展性？日志记录、身份验证/授权、请求限制等。