重新部署Google Cloud Endpoint时流量是否丢失？未更新VM config_id的影响及解决方案

1. 重新部署Cloud Endpoints时，流量会被丢弃吗？ #

简短答案：正常情况下不会。

Cloud Endpoints的设计本身就考虑了流量连续性——当你通过gcloud endpoints services deploy这类命令重新部署新配置时，旧的配置版本并不会立刻被下线。Google会保留旧配置一段时间（默认是部署新配置后的30天，除非你手动提前删除），而且在这段时间内，旧配置仍然可以正常处理所有指向它的请求。只有当你主动删除旧配置，或者超过了系统的保留期限，旧配置才会失效。

所以只要你不是部署完立刻删旧配置，流量不会出现被丢弃的情况。

2. VM实例仍使用旧config_id时的流量处理与中断规避 #

流量会不会被丢弃？ #

这得分情况：

• 如果旧的config_id对应的配置还在系统中（没被删除、没过期）：完全不会丢流量，VM上的请求会继续通过旧配置正常处理。
• 如果旧配置已经被删除/过期：这时候VM用无效的config_id发起请求，会收到错误响应，流量相当于被丢弃。

避免服务中断的可行方案 #

这里有几个实践中常用的办法，按优先级排序：

• 让VM使用服务的默认配置，而非指定具体config_id
  如果你不在VM元数据里硬编码endpoint config_id，而是让它使用服务的默认配置，那每次部署新配置后，只需要执行gcloud endpoints configs set-default <新CONFIG_ID> <服务名>，所有VM会自动切换到新配置，完全不需要更新元数据，从根源上避免了配置不一致的问题。

• 延迟删除旧配置，分批更新VM元数据
  如果你必须指定具体config_id，那部署新配置后，先别急着删旧的。分批次更新VM的元数据（比如先更1/3的实例，观察1-2小时没问题再更下一批），等所有VM都切换到新config_id后，再用gcloud endpoints configs delete <旧CONFIG_ID> <服务名>清理旧配置。

• 用负载均衡统一管理流量入口
  把流量先导向负载均衡器，再由LB转发到Endpoints。LB配置时指向Endpoints服务的默认配置，而非具体config_id。这样更新配置后，只需要设置新配置为默认，LB会自动把流量切过去，VM这边完全不用动。

• 给配置加标签，监控流量切换情况
  部署新配置时可以加标签，比如gcloud endpoints services deploy openapi.yaml --labels=version=v2，然后通过Cloud Monitoring监控不同标签配置的请求量。等旧标签（比如v1）的请求量降到0之后，再安全删除旧配置。

内容的提问来源于stack exchange，提问作者Aicos