Google App Engine 逐个升级
Google App Engine upgrading part by part
我有一个用 PHP 编写的复杂的应用程序引擎服务，现在我想将它部分地迁移到 Python。
假设我的服务有两部分：/signIn/.... 和 /data/...。我只想先迁移 /signIn/ 部分，然后再迁移 /data/。
但是，由于我的服务很大，所以我想在 Python 中构建新的 /signIn/ 部分，然后使用 Traffic Splitting 对此进行一些 A/B 测试部分。
我的问题是流量拆分只能应用于版本，所以我的旧版本和新版本必须在同一个模块中，同一个模块意味着它们必须用同一种语言编写（我这里错了，请参阅更新部分）。但我正在从 PHP 迁移到 Python。
最适合我的解决方案是什么？
谢谢，
解决方案
在 Dan Cornilescu 的帮助下，这就是我所做的：
- 将应用拆分为 2 个模块：默认和旧版本。
- 将
/signIn/分派到默认模块，其余分派到旧版本模块。
- 在Python
中创建另一个版本的/signIn/（默认模块）
- 配置流量拆分以缓慢地将请求百分比增加到 Python 部分。这将使我们能够进行测试并确保没有发生严重的错误。
注意：
/signIn/ 部分必须是默认模块，因为 GAE 的流量拆分仅在默认模块下工作。
我确认我们可以为一个模块制作不同语言的 2 个版本。
一种可能的方法是在第一步中将您的 PHP 应用分成多个模块。这不是完全浪费的努力，无论如何，其中大部分都是需要的，只是为了让您的应用程序在多个模块中工作，与语言更改无关。我怀疑这实际上就是您不能使用 A/B 测试的原因 - 模块之间的不匹配。不可避免。
完成模块拆分后，您可以继续第二步 - 切换所选模块的语言，并按预期进行 A/B 测试。
更大胆的做法是将2混合，直接在python中编写/signin/模块。在 PHP 一侧，您只需删除 /signin/ 部分（前面提到的第一步的一部分）。只要你小心只对模块间 communication/operation 使用应用程序语言无关的方法，应该工作得很好：请求路径、cookie、datastore/memcache 键等。良好的模块拆分几乎肯定会确保那。
您有 A/B 以外的测试选项，例如：。
您还可以让新的 code/module 能够处理与旧的相同的请求，side-by-side/simultaneously 并使用 dispatch.yaml 文件来精确控制哪个模块实际处理哪些请求.这可能允许非常集中的迁移，可能提供更高的测试信心。
我也不完全确定您实际上不能拥有不同语言的同一模块的 2 个版本 - 这些版本应该是非常独立的实例，每个实例都以自己的方式服务于自己的请求，最低限度层，独立于语言的 GAE 基础服务。 AFAIK 没有什么能阻止 complete 应用程序的重写和部署，无论是否使用相同的版本——我在学习 GAE 时就这样做过。但我没有切换语言，这是真的。我会试一试，但我现在没有时间学习一门新语言:)
我有一个用 PHP 编写的复杂的应用程序引擎服务，现在我想将它部分地迁移到 Python。
假设我的服务有两部分：/signIn/.... 和 /data/...。我只想先迁移 /signIn/ 部分，然后再迁移 /data/。
但是，由于我的服务很大，所以我想在 Python 中构建新的 /signIn/ 部分，然后使用 Traffic Splitting 对此进行一些 A/B 测试部分。
我的问题是流量拆分只能应用于版本，所以我的旧版本和新版本必须在同一个模块中，同一个模块意味着它们必须用同一种语言编写（我这里错了，请参阅更新部分）。但我正在从 PHP 迁移到 Python。
最适合我的解决方案是什么？
谢谢，
解决方案
在 Dan Cornilescu 的帮助下，这就是我所做的：
- 将应用拆分为 2 个模块：默认和旧版本。
- 将
/signIn/分派到默认模块，其余分派到旧版本模块。 - 在Python 中创建另一个版本的
- 配置流量拆分以缓慢地将请求百分比增加到 Python 部分。这将使我们能够进行测试并确保没有发生严重的错误。
/signIn/（默认模块）
注意：
/signIn/ 部分必须是默认模块，因为 GAE 的流量拆分仅在默认模块下工作。
我确认我们可以为一个模块制作不同语言的 2 个版本。
一种可能的方法是在第一步中将您的 PHP 应用分成多个模块。这不是完全浪费的努力，无论如何，其中大部分都是需要的，只是为了让您的应用程序在多个模块中工作，与语言更改无关。我怀疑这实际上就是您不能使用 A/B 测试的原因 - 模块之间的不匹配。不可避免。
完成模块拆分后，您可以继续第二步 - 切换所选模块的语言，并按预期进行 A/B 测试。
更大胆的做法是将2混合，直接在python中编写/signin/模块。在 PHP 一侧，您只需删除 /signin/ 部分（前面提到的第一步的一部分）。只要你小心只对模块间 communication/operation 使用应用程序语言无关的方法，应该工作得很好：请求路径、cookie、datastore/memcache 键等。良好的模块拆分几乎肯定会确保那。
您有 A/B 以外的测试选项，例如：。
您还可以让新的 code/module 能够处理与旧的相同的请求，side-by-side/simultaneously 并使用 dispatch.yaml 文件来精确控制哪个模块实际处理哪些请求.这可能允许非常集中的迁移，可能提供更高的测试信心。
我也不完全确定您实际上不能拥有不同语言的同一模块的 2 个版本 - 这些版本应该是非常独立的实例，每个实例都以自己的方式服务于自己的请求，最低限度层，独立于语言的 GAE 基础服务。 AFAIK 没有什么能阻止 complete 应用程序的重写和部署，无论是否使用相同的版本——我在学习 GAE 时就这样做过。但我没有切换语言，这是真的。我会试一试，但我现在没有时间学习一门新语言:)