我们的应用程序服务于一个只报告os.environ ['CURRENT_VERSION_ID']的端点。我们将此用于一种监视，它跟踪当前将哪个版本设置为“默认版本”。
从3月5日下午开始，我们在向此端点发出请求时发现奇怪的行为。在我们更改默认版本后不久（通过“appcfg.py set_default_version”），对此端点的重复请求将在先前的默认值和新默认值之间翻转。这会持续大约10分钟，之后所有后续请求将始终报告新的正确默认版本。因此，在这10分钟的窗口期间，对我们正常的默认URL的请求似乎会不一致地报告旧版本或新版本。
这似乎是行为的改变。我们的应用程序的默认版本的先前更改发生在3月1日，并且在该日期之前的每个其他版本更改都没有表现出这种翻转行为。
（问题来自my teammate的bug report）
答案 0 :(得分：10)
首先介绍一下背景：
更改应用程序的默认版本后，通过更改通过管理控制台标记为默认版本的版本，或者通过部署与当前默认版本相同的主要版本，有关此更改的信息将通过App Engine传播基础设施。随着应用程序了解新版本，他们开始加载新版本的应用程序代码。一旦给定的appserver准备就绪，它将开始提供新版本的代码。
在某段时间内，某些应用服务器将提供之前的默认版本，而其他应用服务器已经在提供新的默认版本。因此，预计任何具有非常重要流量的应用都会看到您描述的行为。
我们一直致力于减少这些版本更改所需的时间，但我们最关心的是确保转换顺利进行。如果应用程序具有大量服务于先前版本的实例，则App Engine需要确保始终有足够的容量（组合旧的和新的应用程序服务器）来为所有当前流量提供服务。应用程序的上一版本和新版本可能需要不同数量的应用程序服务器（由于版本之间的性能差异），这也是无法安全地立即执行转换的另一个原因。
如果您希望更好地控制该过程，可以使用App Engine的Traffic Splitting功能。以步进方式，您可以增加您希望指向新版本的用户流量百分比。然后，App Engine将根据客户端IP地址或cookie（针对Web应用程序）提供版本粘性。您还可以使用流量拆分来“金丝雀”。一些百分比（比如1％）客户的新版本应用程序。