负载平衡器，多个数据中心和基于URL的路由

有一个数据中心 – dc1。有一个业务需要build立另一个数据中心 – 在另一个地理dc2，可能会有更多的未来说dc3。

在数据中心dc1内：

有两个Web服务器说WS1和WS2。这两个networking服务器目前不共享任何内容。没有任何必要预见在每个直stream电中有更多的networking服务器。
dc1也有一个本地负载均衡器，它已被设置为会话粘性。因此，如果用户说u1登陆dc1，并且负载均衡器决定将他的第一个请求路由到WS1，那么从那里所有u1的请求将被路由到WS1。
本地负载均衡器和Web服务器对用户是不可见的。本地负载均衡器侦听分配给虚拟服务器集群ws1和ws2的虚拟ip上的stream量。虚拟IP是主机名在DNS中parsing到的IP。
现在没有客户特定的子域，而是有一个客户特定的url（上下文）。例如：www.example.com/client1和www.example.com/client2。

上面给出的dc2是onboarded时，我想根据客户端路由dc1和dc2之间的stream量。我目前find的选项是。

拥有特定于客户端的子域，例如client1.example.com和client2.example.com，并为每个子域指定要将数据中心路由到的数据中心的虚拟IP。

要么

将www.example.com和www1.example.com分配给第一个dc，即dc1，并将www2.example.com分配给dc2。所有请求将首先被路由到dc1，其中WS1和WS2将根据url是以/ client1还是/ client2结尾将用户redirect到www1.example.com或www2.example.com。

我在下面需要帮助

如果我在dc1和dc2之间设置全局负载均衡器，是否有其他解决scheme？也就是说，全局负载均衡器可以根据url来路由stream量吗？
与www1解决scheme相比，基于子域的解决scheme是否存在缺陷？使用www1解决scheme，我担心它会为第一个请求至less创builddc1的依赖关系，用户将看到他正在redirect到不同的url。

您是否想要手动将客户分配给每个DC，或者只是寻找一种简单的方式来分配负载？如果是后者，基于地理位置的负载平衡通常会给您带来最好的性能。

基于地理位置的负载平衡器几乎总是基于DNS的，这意味着您在DNS查找时不会有URL信息，因此无法做出决定。但是，我已经看到了一个scheme，其中在一个位置的networking服务器在检查请求之后，如果请求的对象更好地从别处获得服务，则将发送301redirect到另一个位置的服务。

至于基于地理位置的负载平衡，有几个DNS-as-a-service产品; 我build议Dynect（ http://dyn.com/dns/dynect-managed-dns/ ）。他们既可以进行地理位置监测，也可以进行现场监测，在发生停电的情况下，将死掉的VIP从DNS轮换中撤出。

也有很多基于设备的解决scheme，比如F5的GTM和思杰的Netscaler，但是它们的成本要比基于云计算的解决scheme要贵得多。

基于DNS的解决scheme的最大缺点是，一旦发生故障转移，某些客户端将无法可靠地刷新其DNScaching。在我工作的网站（这是一个很大的网站）上，我们将看到客户在从DNS中删除其IP后几天到几周内就会遭到弃用。这个问题的解决scheme非常奇特，通常取决于使用路由协议来将VIP从一个站点“移动”到另一个站点，而不是DNS更改。