负载均衡选项
根据发送到您应用的流量类型，您可以选择多种外部负载均衡方法。您的可用选项如下表所述：
| 选项 | 说明 | 流量 | 范围 |
|---|---|---|---|
| 外部应用负载均衡器 | 支持 HTTP(S) 流量和高级功能，例如网址映射和 SSL 分流 使用外部代理网络负载均衡器来处理非 HTTP 流量特定端口。 |
TCP 或 SSL (TLS) 会话在 Google 网络边缘的 Google Front End (GFE) 前端终结，并且流量被代理到后端。 | 全球 |
| 外部直通网络负载均衡器 | 允许 TCP/UDP 流量使用任何端口通过负载均衡器。 | 利用 Google 的 Maglev 技术将流量分配到后端。 | 区域 |
由于内部负载均衡器和 Cloud Service Mesh 不支持面向用户的流量，因此不在本文讨论范围之内。
本文的测量结果使用 Network Service Tiers 中的优质层级，因为全球负载均衡需要此服务层级。
测量延迟时间
在访问 us-central1 中托管的网站时，德国的用户使用以下方法来测试延迟时间：
- Ping：虽然 ICMP ping 是衡量服务器可达性的一种常用方法，但 ICMP ping 不会衡量最终用户延迟。如需了解详情，请参阅外部应用负载均衡器的额外延迟效应。
- Curl：Curl 测量收到第一个字节的时间 (TTFB)。向服务器重复发出
curl命令。
在比较结果时，请注意，光纤链路上的延迟时间受到距离和光纤中光速（约为 200000 公里/秒，或 124724 英里/秒）的限制。
德国法兰克福与爱荷华州康瑟尔布拉夫斯（us-central1 区域）之间的距离约为 7500 公里。在位置之间采用笔直的光纤，往返延迟如下：
7,500 km * 2 / 200,000 km/s * 1000 ms/s = 75 milliseconds (ms)
用户和数据中心之间的光纤线缆不会遵循笔直的路径。光纤线缆上的光线沿途要经过有源和无源设备。观察到的延迟约为理想值的 1.5 倍，即 112.5 毫秒，即表明接近理想的配置。
比较延迟时间
本部分比较了以下配置中的负载均衡：
- 无负载均衡
- 外部直通网络负载均衡器
- 外部应用负载均衡器或外部代理网络负载均衡器
在此场景中，应用是由 HTTP Web 服务器的区域级托管式实例组所组成的。由于该应用依赖于对中央数据库的短延迟时间调用，因此必须将各个网络服务器托管在一个位置。该应用部署在 us-central1 区域，用户分布在全球各地。德国用户在此方案中观察到的延迟时间说明了全球用户都可能会遇到的情况。
无负载均衡
当用户发出 HTTP 请求时，除非配置负载均衡，否则流量会直接从用户的网络流向 Compute Engine 上托管的虚拟机。对于高级层级，流量会在靠近用户位置的边缘入网点 (PoP) 处进入 Google 的网络。对于标准层级，用户流量会在靠近目标区域的 PoP 进入 Google 的网络。如需了解详情，请参阅网络服务层级文档。
下表显示了德国用户在没有使用负载均衡的情况下测试系统延迟时间的结果：
| 方法 | 结果 | 最短延迟时间 |
|---|---|---|
| 对虚拟机 IP 地址进行 Ping 操作（网络服务器直接响应） |
ping -c 5 compute-engine-vm PING compute-engine-vm (xxx.xxx.xxx.xxx) 56(84) bytes of data. 64 bytes from compute-engine-vm (xxx.xxx.xxx.xxx): icmp_seq=1 ttl=56 time=111 ms 64 bytes from compute-engine-vm (xxx.xxx.xxx.xxx): icmp_seq=2 ttl=56 time=110 ms [...] --- compute-engine-vm ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4004ms rtt min/avg/max/mdev = 110.818/110.944/111.265/0.451 ms |
110 毫秒 |
| TTFB |
for ((i=0; i < 500; i++)); do curl -w /
"%{time_starttransfer}\n" -o /dev/null -s compute-engine-vm; done
0.230 0.230 0.231 0.231 0.230 [...] 0.232 0.231 0.231 |
230 毫秒 |
TTFB 延迟是稳定的，如下图（含有前 500 个请求）所示：
对虚拟机 IP 地址执行 ping 操作时，响应直接来自网络服务器。与网络延迟时间 (TTFB) 相比，网络服务器的响应时间最短。这是因为每个 HTTP 请求都会打开新的 TCP 连接。发送 HTTP 响应前需要初始三向握手，如下图所示。因此，观察到的延迟时间接近 ping 延迟时间的两倍。
外部直通式网络负载均衡器
使用外部直通网络负载均衡器，用户请求仍会在最近的边缘 PoP（在高级层级）进入 Google 网络。在项目虚拟机所在的区域中，流量首先流经外部直通网络负载均衡器。然后，系统在不做任何更改的情况下将其转发到目标后端虚拟机。外部直通网络负载均衡器根据稳定的哈希算法分配流量。该算法结合使用来源和目标端口、IP 地址和协议。虚拟机侦听负载均衡器 IP 地址并原封不动地接受流量。
下表显示了德国用户针对 network-load-balancing 选项测试延迟时间的结果。
| 方法 | 结果 | 最短延迟时间 |
|---|---|---|
| 对外部直通网络负载均衡器执行 Ping 测试 |
ping -c 5 net-lb PING net-lb (xxx.xxx.xxx.xxx) 56(84) bytes of data. 64 bytes from net-lb (xxx.xxx.xxx.xxx): icmp_seq=1 ttl=44 time=110 ms 64 bytes from net-lb (xxx.xxx.xxx.xxx): icmp_seq=2 ttl=44 time=110 ms [...] 64 bytes from net-lb (xxx.xxx.xxx.xxx): icmp_seq=5 ttl=44 time=110 ms --- net-lb ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4007ms rtt min/avg/max/mdev = 110.658/110.705/110.756/0.299 ms |
110 毫秒 |
| TTFB |
for ((i=0; i < 500; i++)); do curl -w /
"%{time_starttransfer}\n" -o /dev/null -s net-lb
0.231 0.232 0.230 0.230 0.232 [...] 0.232 0.231 |
230 毫秒 |
由于负载均衡操作发生在区域内，并且流量只转发，因此与没有负载均衡器相比，延迟时间不会受到显著影响。
外部负载均衡
使用外部应用负载均衡器，GFE 可以代理流量。这些 GFE 位于 Google 全球网络边缘。GFE 终结 TCP 会话并连接到可处理流量的最近区域的后端。
下表显示了德国用户针对 HTTP-load-balancing 选项测试延迟时间的结果：
| 方法 | 结果 | 最短延迟时间 |
|---|---|---|
| 对外部应用负载均衡器执行 Ping 测试 |
ping -c 5 http-lb PING http-lb (xxx.xxx.xxx.xxx) 56(84) bytes of data. 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=1 ttl=56 time=1.22 ms 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=2 ttl=56 time=1.20 ms 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=3 ttl=56 time=1.16 ms 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=4 ttl=56 time=1.17 ms 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=5 ttl=56 time=1.20 ms --- http-lb ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4005ms rtt min/avg/max/mdev = 1.163/1.195/1.229/0.039 ms |
1 毫秒 |
| TTFB |
for ((i=0; i < 500; i++)); do curl -w /
"%{time_starttransfer}\n" -o /dev/null -s http-lb; done
0.309 0.230 0.229 0.233 0.230 [...] 0.123 0.124 0.126 |
123 毫秒 |
外部应用负载均衡器的结果明显不同。在对外部应用负载均衡器执行 ping 测试时，往返延迟时间略微超过 1 毫秒。此结果表示到最近的 GFE 的延迟时间，且该 GFE 位于用户所在的城市。当用户尝试访问托管在 us-central1 区域的应用时，此结果并不反映用户体验到的实际延迟时间。使用与您的应用通信协议 (HTTP) 不同的协议 (ICMP) 进行实验可能会产生误导。
在测量 TTFB 时，初始请求表现出的响应延迟时间相似。一些请求达到了 123 毫秒的最短延迟时间，如下图所示：
即使使用笔直的光纤，客户端与虚拟机之间的两次往返也会花费超过 123 毫秒。延迟时间更短，因为 GFE 代理流量。GFE 会保持与后端虚拟机的持久连接。因此，只有从特定 GFE 前端到特定后端的第一个请求才需要三次握手。
每个位置有多个 GFE。延迟时间图显示了首次到达每个 GFE 后端对时的多个波动峰值。然后，GFE 必须建立与该后端的新连接。这些峰值反映了不同的请求哈希。后续请求的延迟时间会更短。
这些方案演示了用户在生产环境中可体验到的减少的延迟时间。结果如下表所示：
| 选项 | Ping | TTFB |
|---|---|---|
| 无负载均衡 | 110 毫秒到达网络服务器 | 230 毫秒 |
| 外部直通网络负载均衡器 | 110 毫秒到达区域内的外部直通网络负载均衡器 | 230 毫秒 |
| 外部应用负载均衡器 | 1 毫秒到达最近的 GFE | 123 毫秒 |
当运行状况良好的应用为某个特定区域中的用户提供服务时，该区域中的 GFE 会保持对所有服务后端开放的持久连接。因此，如果该区域中的用户离应用后端很远，他们会注意到第一个 HTTP 请求的延迟时间缩短。如果用户靠近应用后端，则用户不会注意到延迟时间方面的改善。
对于后续请求（例如点击页面链接），延迟时间未得到改善，因为现代浏览器会保持与服务的持久连接。这与从命令行发出的 curl 命令不同。
外部应用负载均衡器的额外延迟效应
外部应用负载均衡器的其他可观察效应取决于流量模式。
与外部直通网络负载均衡器相比，外部应用负载均衡器对复杂资源的延迟时间更短，因为在响应完成之前需要的往返次数较少。例如，当德国用户在重复下载 10 MB 文件时通过同一连接测量延迟时间，外部直通网络负载均衡器的平均延迟时间为 1911 毫秒。使用外部应负载均衡器，平均延迟时间为 1341 毫秒。每次请求可节省大约 5 次往返。GFE 和服务后端之间的持久连接减少了 TCP 缓慢启动的影响。
外部应用负载均衡器可显著减少对 TLS 握手的额外延迟时间（通常为 1-2 次额外往返）。这是因为外部应用负载均衡器使用 SSL 分流，并且只有到边缘 PoP 的延迟时间是相关的。对于德国用户，使用外部应用负载均衡器观察到的最短延迟时间为 201 毫秒，而通过外部直通网络负载均衡器使用 HTTP(S) 观察到的最短延迟时间为 525 毫秒。
外部应用负载均衡器允许将面向用户的会话自动升级到 HTTP/2。HTTP/2 可以通过改进二进制协议、头文件压缩和连接多路复用来减少所需的数据包数量。这些改进措施可以减少观察到的延迟时间，甚至比切换到外部应用负载均衡器所观察到的延迟时间减少得更多。使用 SSL/TLS 的当前浏览器支持 HTTP/2。对于德国用户来说，用 HTTP/2 代替 HTTPS 时，最短延迟时间进一步减少，从 201 毫秒减少至 145 毫秒。
优化外部应用负载均衡器
使用外部应用负载均衡器可以优化应用的延迟，如下所示：
如果您提供的部分流量可缓存，您可以将其与 Cloud CDN 进行集成。Cloud CDN 通过直接在 Google 的网络边缘为资源提供服务来减少延迟时间。Cloud CDN 还利用了外部应用负载均衡器的额外延迟时间影响部分中提到的来自 HTTP/2 的 TCP 和 HTTP 优化。
您可以将任何 CDN 合作伙伴的服务与 Google Cloud 搭配使用。通过使用 Google 的CDN 互连合作伙伴之一的服务，您可以从享受折扣的数据传输费用中受益。
如果内容是静态的，您可以借助外部应用负载均衡器直接从 Cloud Storage 提供内容，从而减少网络服务器上的负载。此选项与 Cloud CDN 结合使用。
将您的 Web 服务器部署在靠近用户的多个区域中可以减少延迟时间，因为负载均衡器会自动将用户定向到最近的区域。但是，如果您的应用是部分集中式，请将其设计为减少区域间往返次数。
如需减少应用内的延迟时间，请检查在虚拟机之间进行通信的任何远程过程调用 (RPC)。当应用在层级或服务之间进行通信时，通常会出现这种延迟。Cloud Trace 等工具可以帮助您降低应用服务请求造成的延迟。
由于外部代理网络负载均衡器基于 GFE，因此对延迟时间的影响与使用外部应用负载均衡器时相同。由于外部应用负载均衡器比外部代理网络负载均衡器提供的功能更多，因此我们建议将外部应用负载均衡器用于 HTTP(S) 流量。
后续步骤
我们建议您在靠近大多数用户的位置部署应用。如需详细了解 Google Cloud 中的不同负载均衡选项，请参阅以下文档：