Google Cloud 全球负载均衡有什么特点，跨地区网站如何设计访问路径

一个网站从北美扩展到欧洲、亚洲之后，最容易出现的误解是“在三个地区各部署一台服务器，再让DNS根据用户位置返回最近服务器IP”。这种方案在小规模网站上可以工作，但它并不是Google Cloud全球负载均衡的核心工作方式。Google Cloud的全球外部Application Load Balancer更接近一个全球统一的流量入口：用户看到的是同一个全球Anycast IP，Google在全球网络边缘接收请求，然后根据后端位置、健康状态、容量以及负载均衡策略决定请求应该进入哪个区域。

这意味着跨地区网站的访问路径不能只研究DNS。真正的路径需要从域名解析、全球Anycast入口、Google Front End、Backend Service、区域后端一直分析到应用服务器和数据库。只有把这几个层次拆开，才能理解为什么全球负载均衡可以让同一个域名同时服务北美、欧洲和亚洲用户，也才能判断某一次访问延迟究竟发生在客户端到Google网络的途中、Google网络内部，还是后端应用和数据库。

DNS通常不会负责选择欧洲服务器还是北美服务器

假设网站使用www.example.com，并把域名解析到Google Cloud全球External Application Load Balancer的全球IP地址。用户在加拿大、德国和日本访问这个域名时，并不需要DNS分别返回加拿大、欧洲和亚洲三个不同的负载均衡器IP。

全球External Application Load Balancer可以使用一个全球外部IP地址作为统一入口，因此DNS层可以保持非常简单。Google官方文档也明确指出，全球外部Application Load Balancer使用全球外部IP，并可以把用户流量导向不同区域的后端，因此不需要为不同区域维护不同的DNS记录，也不需要等待DNS变更传播后才能改变后端流量。

这里要区分两个概念：DNS解析服务器的位置，与用户实际访问网站的网络入口不是一回事。DNS服务器可能位于美国，但这并不意味着网站请求一定要先进入美国服务器再去欧洲。真正决定HTTP请求进入Google网络哪个入口的，是全球Anycast IP和互联网路由。

所以原稿中“欧洲用户会由DNS优先返回欧洲区域Anycast IP，而北美用户得到北美IP”的描述应该删除。对于全球External Application Load Balancer，更典型的设计就是一个域名对应一个全球入口。

Anycast真正解决的是全球入口问题

Anycast的核心思想，是同一个IP地址可以从全球多个网络位置被公布。互联网中的路由系统会让用户的流量进入一个合适的网络入口，而不是要求用户知道具体应该访问哪一台服务器。

Google Cloud全球负载均衡利用Google全球网络和分布式Google Front Ends接收这些请求。官方架构说明中，全球External Application Load Balancer使用分布在全球的GFE，并通过Google的全球网络和控制平面共同完成多区域负载均衡。

因此，Anycast并不是“把一个请求同时广播给全球所有节点”。这是理解Anycast时非常常见的错误。它不是广播机制，而是同一个目标IP在多个网络位置存在可达入口，互联网路由决定数据包进入哪个入口。

对于HTTP和HTTPS应用，Google的GFE还承担代理功能。HTTPS可以在靠近用户的位置完成TLS终止，然后由Google的网络继续把请求送往后端。Google官方的延迟优化资料也说明，GFE与后端之间可以维护持久连接，从而减少某些请求建立后端连接所产生的额外延迟。

用户最近的入口不等于距离用户最近的VM

这是全球负载均衡另一个容易被误解的地方。

假设用户在加拿大西部，而你的后端分别部署在美国、欧洲和亚洲。用户的流量可能先进入距离用户较近的Google网络边缘，但最终请求到底进入哪个Backend，并不是简单按照地理距离画一个圆圈决定。

Google的全球External Application Load Balancer会综合后端位置、健康状态和容量等因素进行流量分配。官方文档描述的典型行为是，在Premium Tier下，系统会尝试把用户请求发送到距离用户较近、通过健康检查并且具有足够容量的后端；如果最近区域的后端不健康或者没有足够容量，则可以把请求转移到其他区域。

因此，“最近区域”应该理解为负载均衡决策中的重要因素，而不是一个绝对的GPS距离规则。

如果欧洲服务器距离德国用户最近，但欧洲Backend已经没有足够容量，而北美Backend仍然健康并且有资源，那么请求并不一定死板地坚持进入欧洲。

这也是全球负载均衡和简单GeoDNS之间的重要区别。GeoDNS通常是在DNS层根据地理或其他策略返回不同地址，而全球负载均衡可以在统一的全球入口之后继续根据后端状态和容量进行决策。

健康检查解决的是后端是否能够继续接收流量

多区域部署的价值不仅仅是降低延迟，更重要的是避免一个区域出现故障以后整个网站不可访问。

例如网站在北美、欧洲和亚洲各部署一组VM或NEG。如果欧洲区域的后端实例出现故障，健康检查发现这些Backend已经无法正常服务，全球负载均衡就可以停止向不健康的后端继续发送流量，并把新的请求分配给其他可用区域。Google Cloud官方资料明确把健康状态和后端容量作为全球流量分配的重要条件。

但这里也不能把健康检查理解成“网站一旦返回500就马上切换整个区域”。

健康检查检查什么、检查频率是多少、后端Service如何配置，以及是否使用更高级的流量管理能力，都会影响故障判断。更复杂的应用还需要考虑Outlier Detection等机制，用于识别持续出现异常的后端。

更重要的是，负载均衡器只能判断它能够观察到的服务状态。数据库已经进入锁等待、应用虽然HTTP 200但业务数据错误、某个依赖服务已经失效，这些情况不一定能够通过简单HTTP健康检查发现。

所以健康检查不是容灾系统的全部，而是流量入口上的第一道故障判断。

全球负载均衡不等于全球应用已经实现高可用

这是设计跨地区网站时最容易踩的坑。

假设在北美、欧洲和亚洲各部署一套Web服务器，然后使用全球负载均衡。看起来已经是全球高可用了，但三套Web服务器如果都连接同一个位于美国的MySQL数据库，那么数据库依然可能是整个系统的单点。

欧洲用户虽然进入欧洲Web服务器，但欧洲Web服务器读取订单数据时仍然可能跨洋访问美国数据库。此时全球负载均衡解决的是HTTP入口和Web层流量问题，却没有解决数据层延迟。

因此，一个真正的多区域架构至少需要分别考虑Web层、缓存层、消息系统、数据库以及对象存储。

如果应用是无状态的，跨区域部署相对容易。用户Session可以放在共享的Redis、数据库或者采用适当的Token机制；上传文件可以放到对象存储；Web服务器本身尽量不保存必须依赖本机磁盘才能恢复的状态。

如果数据库仍然是单区域，那么架构依然可以有价值，但应该诚实地称为“全球入口加多区域计算”，而不是完整意义上的全球多活。

CDN应该放在什么位置

对于图片、CSS、JavaScript、视频、下载文件等静态内容，没有必要让每一次请求都进入应用服务器。

Cloud CDN可以与Google Cloud外部Application Load Balancer配合使用。Google Cloud官方文档说明，Cloud CDN使用外部Application Load Balancer的Anycast IP作为访问入口。缓存命中以后，用户可以直接获得缓存内容，只有缓存未命中等情况下才需要访问后端Origin。

因此，一个典型的全球网站可以让静态内容尽量在边缘完成，动态请求再进入Application Load Balancer和后端应用。

这比简单地“北美放一台Web服务器、欧洲放一台Web服务器、亚洲放一台Web服务器”更加有效，因为大量静态流量根本不需要穿透到应用层。

对于新闻网站、图片网站、电商网站和内容平台，这一点尤其重要。

后端应该如何选择区域

区域选择不能只看云服务器价格。

如果用户主要来自北美，可以把主要Backend放在北美；欧洲用户数量达到一定规模以后，再增加欧洲区域；亚洲用户达到足够规模以后，再增加亚洲区域。

Google自己的最佳实践也明确建议把Backend尽可能放在接近客户端流量进入Google网络的位置，并指出全球用户分布情况下，多个区域部署Backend通常有助于降低客户端访问延迟。

但“每个大洲部署一套”并不是固定答案。

如果一个SaaS产品95%的用户来自美国和加拿大，却为了所谓“全球化”在欧洲和亚洲部署大量服务器，结果可能只是增加成本、增加数据库同步复杂度和运维工作。

多区域部署应该由用户分布、延迟要求、法规、灾备目标以及业务规模共同决定。

跨地区数据库才是最复杂的部分

如果Web服务器跨区域，但数据库只有一个区域，访问路径通常是比较容易理解的。

用户首先进入全球负载均衡器，然后进入距离较近的Backend，Backend再通过VPC内部网络访问数据库。如果Backend和数据库不在同一区域，就会增加跨区域通信延迟和网络成本。

如果进一步要求数据库也跨区域运行，问题就从“负载均衡”进入了“分布式系统”。

数据库复制延迟、写入冲突、主从切换、读写分离、数据一致性、事务边界以及故障恢复时间，都比简单的Web流量分配复杂得多。

因此，不应该因为Google Cloud拥有全球负载均衡，就认为数据库也可以简单复制三份然后自动全球切换。

网站的访问路径和数据路径必须分开设计。

Session和文件也是跨区域架构中的隐藏问题

假设用户在欧洲登录，第一次请求进入欧洲服务器；下一次请求因为网络状态或负载变化进入北美服务器。

如果Session只保存在欧洲服务器本地内存，那么第二次请求可能无法找到用户登录状态。

解决办法通常是使用共享Session存储、合适的Token机制或者其他跨实例状态管理方案。

文件也是类似问题。

如果用户在欧洲上传一个文件，而文件只保存在欧洲某台VM的本地磁盘，那么后续请求如果进入北美服务器，就可能找不到这个文件。

因此，全球Web架构通常倾向于把业务服务器设计成尽可能无状态，把需要跨实例共享的数据放到专门的数据服务中。

全球负载均衡并不是自动优化所有网络路径

原稿中“Google通过BGP持续监测网络状态，然后实时调整路由，将跨洋延迟降低30%至50%”的说法过于绝对。

全球负载均衡确实依赖Google的全球网络和互联网路由体系，但不能把它描述成一个按照每个用户实时测量互联网全部链路延迟，然后立即重新计算最短路径的系统。

用户到Google Front End之间的互联网路径仍然受到本地ISP、运营商互联和BGP路由影响。

Google能够控制的是进入自己全球网络之后的相当一部分路径和服务调度。因此，一个用户从温哥华访问欧洲网站时，Google网络能够帮助优化进入Google网络后的传输路径，但并不能控制用户家里的ISP如何把第一个数据包送到Google。

这也是为什么实际生产环境必须用真实用户数据、Cloud Monitoring、负载均衡日志以及不同地区的合成监测来验证性能，而不能只根据地图上的距离推算延迟。

全球网站应该怎样设计访问路径

一个比较典型的架构可以是：用户通过域名访问全球Anycast IP，Google全球边缘接收请求，HTTPS在Google Front End完成处理，然后由Global External Application Load Balancer根据URL规则和Backend Service配置选择后端，再把请求发送到健康且具有容量的区域Backend。静态内容可以通过Cloud CDN缓存，动态请求进入应用服务器，应用再访问区域数据库、共享缓存或者其他内部服务。

如果北美、欧洲和亚洲三个区域都存在健康Backend，那么用户通常会被导向较合适的区域；如果某个区域出现故障或者容量不足，系统可以将新的请求转移到其他可用区域。

如果业务需要按照URL、Host、Header等条件进行更加复杂的路由，还可以利用Global URL Map和Backend Service实现更细粒度的流量控制。Google Cloud当前的全球Application Load Balancer支持基于Host、Path以及更高级路由规则进行Backend选择。

对于一个实际的网站，真正应该画出来的不是一张简单的“用户到最近服务器”的地图，而是一张完整的数据路径图：用户、DNS、Anycast IP、Google Front End、Load Balancer、Backend、Cache、数据库以及外部API分别在哪里，数据在这些组件之间如何移动，哪一个组件保存状态，哪个区域发生故障后其他区域是否仍然能够完成完整业务流程。

Google Cloud全球负载均衡最大的价值，是把全球用户访问入口和多区域Backend组织成一个统一的网络服务。它不要求网站为每个国家维护一个独立IP，也不需要靠DNS不断切换区域地址。全球Anycast IP负责统一入口，Google全球网络和GFE负责接收与转发流量，Backend Service和健康检查负责决定哪些后端能够继续服务，而具体的应用和数据库架构则决定这个网站究竟能不能真正做到跨区域高可用。

因此，跨地区网站设计最忌讳把“全球负载均衡”当成一个打开以后就自动全球加速的开关。它解决的是全球流量进入应用以及Backend选择的问题；数据库一致性、Session、文件、缓存、消息队列、第三方API以及业务状态仍然需要应用架构自己解决。对于真正的全球业务，最合理的设计通常不是把所有东西复制到每一个地区，而是根据用户分布和业务特征决定哪些层需要多区域，哪些层可以保持单区域，再利用全球负载均衡把用户流量稳定地送到最合适的计算位置。