谷歌负载均衡器如何保持路由的一致性？答案

【问题标题】：How google load balancer maintain consistency in routing?谷歌负载均衡器如何保持路由的一致性？
【发布时间】：2019-10-10 11:28:57
【问题描述】：

我有两个谷歌云实例在不同的区域（西部和东部）运行。每个实例都有自己的数据库。我正在使用Google Load balancer 根据客户端的IP address 路由流量（这是Google 负载平衡器在内部对网络负载平衡所做的事情）。

例如，Bob 正在从东部区域请求，GLB 将仅将请求路由到东部区域节点。同样，Dave 正在从西部区域请求，GLB 会将请求路由到西部区域节点。

场景： 1. Bob 只需注册并在East 区域数据库中添加一个新条目。 2. Bob 试图获取他的个人资料，但不知何故，请求转到了West（Bob 现在使用 VPN）区域并且没有可用的信息。

有没有办法可以自定义GLB？如果是，那么我可以通过在负载均衡器上应用一致性散列（使用 userId 作为散列函数）来解决这个问题，这将确保来自Bob 的请求将始终转到East 区域。

【问题讨论】：

在你的故事中，如果东部地区宕机了怎么办？你是说西部地区无法满足请求？
我有多个容器在West 区域运行。不知何故，假设如果所有容器都关闭，那么它应该服务于West 区域，但我担心请求一致性和数据库一致性。我无法每毫秒同步数据。这将是一个糟糕的架构。我会在凌晨 4 点左右负载下降的某个时间同步，但剩下的时间呢
您是否考虑过使用 Google 的数据库即服务组件之一来提供高容量和可扩展性，例如 BigTable 和 Cloud Spanner？这些确保 ACID 属性与高容量/低延迟相结合，而您不必担心底层基础设施。在您的上一篇文章中……您是想说两次“西方”还是应该说一次西方而另一个东方？
同样的问题也会出现。假设我在部署在不同区域的分布式环境中使用Big Table。我仍然必须保持数据一致性。您的建议是将服务器端代码放在分布式平台中，并且所有服务器节点都与托管Big Table 数据库的单独服务器连接。由于数据库锁定机制，这是一个非常不足且不具有成本效益的解决方案

【解决方案1】：

您可以使用 HTTP 负载平衡器选项：会话关联和客户端 IP 关联。

任何方法都有细微的问题，请仔细阅读文档。最大的问题是 NAT 背后的客户（机场、酒店、星巴克等）。它们的公共 IP 地址对于 NAT 后面的所有客户端都是相同的，因此所有流量都将流向相同的后端，以实现基于客户端 IP 的亲和性。我建议使用 cookie。

会话亲和性使用客户端 IP 或生成的 Cookie 来做出流量决策。这可以保持流量路由到同一个后端。

客户端 IP 关联根据客户端 IP 地址的哈希将来自同一客户端 IP 地址的请求定向到同一后端实例。

【讨论】：