6

我们的应用程序提供一个简单地报告 os.environ['CURRENT_VERSION_ID'] 的端点。我们将其用于一种监视类型，该监视跟踪当前将哪个版本设置为“默认版本”。

从 3 月 5 日下午开始，我们注意到在向该端点发出请求时出现了奇怪的行为。在我们更改默认版本后不久（通过“appcfg.py set_default_version”），对该端点的重复请求将在先前的默认值和新的默认值之间翻转。这会持续大约 10 分钟，之后所有后续请求将始终报告新的、正确的默认版本。因此，在这 10 分钟的窗口中，对我们正常默认 URL 的请求似乎会不一致地报告旧版本或新版本。

这似乎是行为的改变。我们应用程序的默认版本之前的更改发生在 3 月 1 日，并且在该日期之前的所有其他版本更改都没有表现出这种翻转行为。

（从我队友的错误报告中窃取的问题）

4

1 回答 1

10

首先介绍一下背景：

  • App Engine 在分布式基础架构中运行您的应用程序：您的应用程序接收的流量越多，在任何给定时间运行您的代码的实例（应用服务器）就越多
  • 出于可扩展性/简单性和许多其他原因，App Engine 没有实现客户端 <-> 应用服务器粘性；因此，对默认应用版本的任何请求都可以由任何应用服务器处理

更改应用程序的默认版本后，通过管理控制台更改标记为默认的版本，或部署与当前默认相同的主要版本，有关此更改的信息将通过 App Engine 基础架构传播。随着应用服务器意识到新版本，它们开始加载新版本的应用程序代码。一旦给定的应用服务器准备就绪，它将开始提供新版本的代码。

在一段时间内，一些应用服务器将提供以前的默认版本，而其他应用服务器已经在提供新的默认版本。因此，预计任何具有大量流量的应用都会看到您描述的行为。

我们一直在努力减少这些版本更改所花费的时间，但我们最关心的是确保过渡顺利进行。如果应用程序有大量实例为以前的版本提供服务，App Engine 需要确保始终有足够的容量（结合新旧应用服务器）来服务所有当前流量。应用程序的先前版本和新版本可能需要不同数量的应用服务器（由于版本之间的性能差异），这是无法“立即”安全地执行转换的另一个原因。

If you'd like more control over the process, you can use App Engine's Traffic Splitting feature. In a step wise fashion you can increase the percentage of user traffic you'd like to direct at the new version. App Engine will then provide version stickiness based on either client IP address or a cookie (for web apps). You can also use Traffic Splitting to 'canary' a new version of the application on some percentage (say 1%) of clients.

于 2013-03-14T18:20:01.703 回答