我有一些关于使用Django创建微服务的问题。
假设我们有一个在线商店或一个具有许多数据库请求和用户的更大的系统。我想练习和模拟一个简单的微服务来学习一些新的东西。
我们希望创建一个基于微服务的系统，其中包含以下组件：
1.一个基于Django的微服务，具有管理面板和完整功能（不包括DRF）。
1.一个或多个带有React/Angular前端的微服务。
1.几个额外的微服务来分离功能。我不确定建筑。让我们假设我们想要使用Django管理面板来管理数据。
最简单的解决方案是将DRF添加到第一个微服务并扩展其功能（REST应用程序）-而不是创建不同的服务（3.）。
1.但是，如果我们想将功能分离到不同的微服务中呢？
1.第3点中的微服务是否应该连接到同一个数据库，并被视为不同的Django项目（使用DRF）？
1.我们可以使用GoLang，FastAPI或Java Spring来实现第三个微服务吗？如果是，所有模型都应该在第一个微服务中复制和注册吗？
1.或者，有没有更好的方法来解决这个问题？
这将是伟大的听到你的观点和方法如何继续这一点。
祝你今天愉快！
1条答案
按热度按时间3okqufwl1#
首先，快速总结微服务与Monolithic应用程序的优缺点（这很重要）。
微服务：
[优点]
[缺点]
现在回答你们的问题：
1.将功能划分为不同的微服务。这就是Django项目中的应用程序，也是软件工程的核心原则，关注点分离仍然可以应用于单片应用程序中。当讨论微服务时，问题应该是以复杂性为代价会带来什么好处，例如拥有一个纯GPU计算的服务，也许会受益于在优化的语言和系统上运行的微服务，可以访问GPU。我甚至认为，只有当你探索了所有其他解决方案，并与团队一起组成了一个无可辩驳的论点时，你才应该过渡到使用微服务。
1.微服务是否应该连接到同一个数据库。微服务应该有自己的数据库，参见隔离。否则，它就像使用一个单一的应用程序一样，具有额外的复杂性，没有任何好处。
1.您是否可以使用不同的堆栈，以及是否应该注册重复的模型。这又是对微服务的误解。您的微服务应该封装独立运行所需的最小数据量。
1.备选方案：很好地设计您的Monolithic应用程序，在解耦设计中分离出您的关注点和业务逻辑，即使它是一个整体。你必须有这样的心态：“如果我想用微服务来交换这个功能，那么将它删除的容易程度如何，耦合是什么，等等......）一个好的设计会带来最重要的可扩展性和可维护性。它还允许其他人在项目的一个子集上贡献他们的专业知识，而不需要知道整个项目。