我有一个在Python 2.7 Standard框架下运行良好的应用程序，并且在3.7框架中作为两个单独的应用程序运行良好，但我无法弄清楚如何将它们配置为具有两个服务的单个应用程序。 main.app由以下两行组成（与2.7框架中的工作方式并行）
from app import app
from update import update
main的app.yaml只包含运行时：python37
main（app和update）下的两个python包中的每一个都有自己的app.yaml，正如新的部署文档所说的那样。问题出在更新包中。我曾经指定一个具有脚本的处理程序：main.update。这不再允许（仅允许自动。）请注意，应用程序包工作正常，因为app是默认入口点。我知道在运行更新服务时指定去哪里的新方法是使用入口点，但即使在将gunicorn添加到需求之后，yaml语句也是如此
entrypoint: gunicorn b :$PORT main::update
这似乎是所需要的，简单地给我一个500 http的回报。我也试过像main.update这样的变种无济于事。
main.py
app.yaml
-->/app
-----> /app/__init__.py
-----> /app/app.yaml
-->/update
------> /update/__init__.py
------> /update/app.yaml
这两个包和其他一些东西都有模板子目录，但是当它们作为单独的版本运行时它们都可以正常工作
这是我在更新目录中尝试的yaml：
runtime: python37
service: update
entrypoint: gunicorn -b :$PORT main.update
这是应用程序目录中的yaml，似乎工作正常：
runtime: python37
service: default
handlers:
- url: /static
static_files: static/\1
upload: static/(.*\.(bmp|gif|ico|jpeg|jpg|png))
automatic_scaling:
max_idle_instances: 2
max_concurrent_requests: 12
看看你描述的内容并假设你的目标结构类似于你引用的文档的Example部分中提到的目录结构，我看到了一些问题。
您仍然可以在应用程序的顶级/根目录中找到代码，位于服务目录上方 - main.py和app.yaml文件 - 服务无法访问此类代码。特别是app.yaml文件实际上可能会导致问题，因为它可能会被意外地解释为单服务应用程序的.yaml文件。我会摆脱这些文件。
我只会保留应用程序的顶级目录app-level optional config files以及（如果适用）包含多个服务共享代码的文件，我将在共享代码的每个服务中进行符号链接，请参阅Sharing entities between App Engine modules
在update/app.yaml文件中，您使用错误的语法进行入口点配置：
:分隔符，即main:update，而不是main::update或main.update。这假设你有一个update/main.py文件定义你的WSGI兼容的应用程序叫update（如果应用程序被称为app而不是你使用main:app）b而不是-b您没有在app/app.yaml文件中定义入口点。很可能您的default服务符合自动添加默认入口点的条件，请参阅Application startup：
- app目录的根目录包含一个
main.py文件，该文件带有一个名为app的WSGI兼容对象。app.yaml不包含入口点字段。- 您的应用不包含
Pipfile或Pipfile.lock文件。
我个人更喜欢不依赖这种默认行为，我明确地添加了入口点：
entrypoint: gunicorn -b :$PORT main:app