【发布时间】: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