如何正确地将单体架构应用程序迁移到 Django 中的微服务应用程序

Question

今天我可能会向在这方面有丰富经验的人提出这个问题。

基本上是标题所暗示的。 我们有那个应用程序，我们必须将它迁移到微服务。

我们没有找到任何可靠的方法（或者我们觉得那样）。 我们最终做的是为每个微服务创建一个项目（通常是与模块应用程序相关的单个功能），但随后我们遇到了一些问题，因为我们已经有一个可以使用的数据库，因为这已经是一个正常运行的应用程序。 我们在与现有模型通信时遇到了问题，所以基本上我们所做的是将项目的每个settings.py指向现有数据库，并使用python3 manage.py inspectdb ，我们抓取了现有models 。 这种方法最终奏效了，但我们认为这不是最好的方法。 我们在循环导入等方面遇到了很多问题。

有没有关于 Django 微服务的良好实践，以及如何正确地做到这一点，就像在大多数情况下我们想用框架创建一些东西一样？

如果有人知道或拥有某些东西，我们将不胜感激！

Answer 1

您可以将 Django 用于微服务。 在这种情况下，您只有几个应用程序，并且您在自己的端口上启动每个服务：

第一个 Django 项目

pdf生成器+视图生成小pdf

第二个 Django 项目。

pdf生成器+视图生成大pdf（代码可以继承其他项目）

乐队：

第三个 Django 项目：Autorization + 调用大小 pdf 生成器服务

设置

第一个和第二个的settings.py 非常简单，只允许从内部IP 调用。 这里我们不需要middleaware、template、cache、admin等设置。

管弦乐队的 settings.py 也非常简单，仅使用 auth 并通过内部 ip ant 向用户发送响应进行调用。 在这里，我们不需要太多中间件，也不需要很多其他设置。

收获：

1. 一切都是独立的。 如果一台服务器倒下，其他可以工作。
2. 更新很容易。 一次小型服务器更新总是比整体更新容易。
3. 开发很容易：三个小团队在各自的小项目上工作。
4. 单元测试简单快捷
5. 对于复杂的业务目标，整个系统速度更快。

痛苦：

1. 在 100 个微服务之后，使用这些微服务是完全复杂的。
2. 许多团队的代码风格总是不同的。 无论您为 black-linter 定义样式指南或设置多么严格。
3. 集成测试很困难——如果某些东西不起作用，就很难找到在哪里。
4. 生态系统 Auth/services/messaging 真的很复杂
5. 为了实现简单的业务目标，整个系统过于复杂。

概括

不管你想使用多少数据库。 它可以是单体或许多服务。

我认为从其他项目导入一个微服务没有任何问题：它可以是模型/管理员或其他员工。 有用。 可能你需要智能拆分单体，但这也很容易，因为我们有很多经验（我自己的，在互联网或书籍中）