我们的应用程序服务于一个只报告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%)客户的新版本应用程序。