【问题标题】:Service Fabric (On-premise) Routing to Multi-tenancy Containerized ApplicationService Fabric(本地)路由到多租户容器化应用程序
【发布时间】:2018-11-14 08:12:07
【问题描述】:

我正在尝试对 Service Fabric 中的多租户容器化 ASP.NET MVC 应用程序进行概念验证。这个想法是每个客户将获得 1+ 个应用程序实例,这些实例分布在整个集群中。我在绘制地图时遇到困难的一件事是路由。

每个应用的分区类似于this SO answer。到目前为止的计划是让外部负载平衡器将每个请求路由到 SF 反向代理服务。

例如: tenant1.myapp.com 将被路由到<SF cluster node>:19081/myapp/tenant1 的反向代理(19081 是 SF 反向代理的默认端口)、tenant2.myapp.com -> <SF Cluster Node>:19081/myapp/tenant2 等,然后代理会将其路由到正确的 node:port,其中应用程序的一个实例正在监听。

由于每个应用程序都必须映射到不同的端口,因此 SF 计划在创建每个应用程序时动态分配一个端口。这似乎并不完全可扩展,因为理论上我们可以达到端口限制 (~65k)。

那么我的问题是,这是一种有效/建议的方法吗?有更好的方法吗?有没有我遗漏/忽略的东西?我是 SF 的新手,所以任何帮助/见解将不胜感激!

【问题讨论】:

  • 如果您希望您的解决方案具有可扩展性,也许不同端口的方法不适合您。您可以在 IP、其他域上进行映射,甚至可以使用套接字(我在这里不建议这样做)。您甚至可以使用组合(包括不同的端口)来最大化可能的映射数量。
  • 感谢@David 的回复。对于这些选项,您是否有任何资源可供阅读?我认为可扩展性不会成为问题,尤其是在早期。在我看来,必须有更好的方法来做到这一点。
  • 对不起,没有。我刚刚提到了针对网络服务相关问题的非常通用的选项,并且 Service Fabric 中的实现可能会给您带来更多限制或需要特殊的解决方案。这个问题很有趣,与主要的可扩展性有关,因为端口是有限的,就像你解释的那样。我会坚持使用 Service Fabric 和 azure 的文档,可能 azure 提供了一种我从未考虑过的不同方法。

标签: url-routing service-fabric-stateless azure-service-fabric service-fabric-on-premises


【解决方案1】:

我认为临时端口限制对您来说不是问题,您可能会在消耗一半端口之前消耗所有服务器资源(CPU + 内存)。

您可以做您需要的事情,但这需要您创建一个脚本或一个应用程序,负责为已部署的服务实例创建和管理配置。

我不会使用内置的反向代理,它非常有限,你想要的只会添加额外的配置而没有任何好处。

目前我认为traefik 是最合适的解决方案。 Traefik 使您能够将特定域路由到特定服务,这正是您想要的。

因为您将使用多个域,所以需要动态配置,而该配置并非开箱即用,这就是为什么我建议您创建一个单独的应用程序来部署这些实例的原因。一个非常高级的步骤是:

  • 您使用 traefik 默认规则定义您的服务,如 here 所示
  • 从您的应用程序管理器中,您为新租户部署此服务的新命名服务
  • 部署实例后,将其配置为在特定域中侦听,将规则 traefik.frontend.rule=Host:tenant1.myapp.com 设置为正确的租户名称

您可能需要添加一些额外的配置,但这会引导您走向正确的道路。

关于集群架构,您可以通过多种方式进行,首先,我建议您保持简单,一种前端节点类型包含 traefik 服务,另一种后端节点类型用于您的服务,从那里您可以决定如何为了正确规划集群,已经有很多关于如何定义集群的答案。

请通过以下链接查看更多信息:

https://blog.techfabric.io/using-traefik-reverse-proxy-for-securing-microservices-on-azure-service-fabric/

https://docs.traefik.io/configuration/backends/servicefabric/

【讨论】:

  • @Joseph 你有没有按照 Diego 的建议构建过类似的东西?只是想知道这样的管理解决方案是否可以部分共享,因为我们正在研究构建完全符合您建议的东西。
【解决方案2】:

假设您不需要在每个节点上都有一个实例,您最多可以拥有 (nodecount * 65K) 个服务,这将使其再次可扩展。

看看Azure API managementTraefik,它们有一些SF 集成选项。这比有限的内置反向代理要好得多。例如,它们提供路由规则。

【讨论】:

  • 是的,但是对于升级和故障域,实例通常分布在多个节点上。我必须管理哪些实例可以去哪里。那时我可以为每个应用程序添加放置约束,以控制实例可以继续运行的节点。我认为此时仅添加另一个单独的集群可能会更好?我确实同意,但在某些时候我将不得不放弃 SF 反向代理以获得更强大的东西。
  • Service Fabric 会为您管理正确的放置,前提是您已正确配置容错域。 docs.microsoft.com/en-us/azure/service-fabric/…
猜你喜欢
  • 2016-04-09
  • 2016-05-16
  • 1970-01-01
  • 2016-12-12
  • 2011-09-28
  • 1970-01-01
  • 2012-02-26
  • 1970-01-01
  • 2017-01-14
相关资源
最近更新 更多