python - 如何在具有共享模型和数据库的同一项目中拆分 Django 应用程序的部署？

Question

我有一个架构问题:我们有一个由多个应用程序组成的 Django 项目。有一个核心应用程序包含用于其他应用程序集的主要模型。然后，我们有几个面向用户的 API 应用程序。最后，我们有一些仅供开发人员使用的内部应用程序和工具，可在管理界面中作为扩展功能访问。

我们的部署过程非常单一。我们使用 Kubernetes 并将整个项目作为一个整体进行部署。这意味着如果我们只在内部应用程序中进行了更改并且我们在生产中需要它，我们将构建一个新的 Docker 镜像并部署一个新版本并增加新的版本标签。

我不太喜欢这个，因为内部工具的变化不应该创建面向用户的应用程序的新版本。

我一直在想是否有办法拆分这些部署(也许将它们变成微服务架构？)。因此，我们可以将面向用户的应用程序与内部工具分开部署。我知道我可以为项目的各个部分构建单独的图像、标签和所有内容，但我不确定如果 internal_app_1 依赖于 core 的模型，它们如何相互通信> 应用程序，可能还有 settings.py 和 manage.py 文件。

另外，因为在 Kubernetes 中，必须分离应用程序意味着分离运行两台服务器的部署，所以这意味着两个独立的 Django 项目彼此隔离但使用相同的数据库。

有没有人用过类似的东西或者想建议一个替代方案(如果有的话)？

下面是我们项目目前结构的树形示例:

├── core
|   ├── models.py
|   ├── views.py
|   └── urls.py
├── userapi_1
|   ├── views.py
|   └── urls.py
├── userapi_2
|   ├── views.py
|   └── urls.py
├── insternal_app_1
|   ├── templates
|   |   └── ...
|   ├── models.py
|   ├── views.py
|   └── urls.py
├── manage.py
├── settings.py
└── Dockerfiles
    ├── Dockerfile.core
    └── Dockerfile.internal_app_1

Answer 1

Django 和微服务？是的，也许在平行宇宙的某个地方。

我唯一推荐的是构建两个相同的服务，如 django_container_internal 和 django_container_production。在这种情况下，您将能够在不停止生产的情况下发布内部工具。

如果你想阻止使用internal 端点访问production 功能，你可以使用ENVs 停用production URL >。通常 Django 项目有通用的 config/urls.py 聚合所有 URL 端点，看起来像

urlpatterns = [
    url('core/api/v1/', include(core.urls)),
    url('internal/api/v1/', include(internal_app_1.urls)),
    url('user/api/v1/', include(userapi_1.urls))
    ...
]

例如，您可以添加 IS_INTERNAL_TOOLS 环境变量并更新 urls.py

from os import environ

urlpatterns = [
    url('core/api/v1/', include(core.urls)),
    ...
]

if environ.get('IS_INTERNAL_TOOLS', 'false').lower() in ('true', '1', 'yes'):
    urlpatterns.append(url('insternal/api/v1/', include(insternal_app_1.urls)))
else:
    urlpatterns.append(url('user/api/v1/', include(userapi_1.urls)))

• 优点:

  • 两种服务都可以访问所有模型(只有一个公共(public) DAO => 没有双重开发人员创建模型两次)
  • 功能是分开的，所以只有必要的功能可以访问
  • 易于实现

• 缺点:

  • 完整的源代码存储在两个容器中，即使其中一半未被使用
  • 如果您为内部工具和外部 API 使用两个单独的数据库，则必须在这两个数据库中创建所有表(但看起来这不是您的情况)
  • 因为它仍然是单体internal 和production 部分严重依赖于通用core 并且不可能只单独部署更新的核心