Python分布式应用中的持久体系结构

想知道分布式Python应用程序的持久体系结构。 应该提供一些关于应用程序类型的指导。我们希望能够拥有多个代码服务器和多个数据库服务器，理想情况下，能够采用一些易于管理且不太麻烦的部署方法

我提到的问题提供了一个我喜欢的答案，但我想知道如何使它更耐用，或者这样做是否需要使用其他技术。特别是：

我希望我的前端端点是WSGI（因为您已经编写了它），并编写要通过消息分发的后端。然后，您将拥有一个后端节点池，这些节点将从芹菜队列中提取消息并完成所需的工作。它看起来有点像：

Apache->WSGI容器->芹菜消息队列->芹菜工人

apache节点将位于某种负载平衡器的后面。这将是一个相当简单的体系结构，可以进行扩展，如果操作正确，则相当可靠。在这样的系统中，如果出现故障代码，您将不会有问题

---

制造耐用应用程序的最佳方法是什么？有没有关于如何“为失败编写代码”或以不同方式设计它以使我们不必这样做的建议？如果您认为Python可能不适合于此，那么这也是一个有效的解决方案。

继续我之前给出的答案

在我的项目中，我为失败编写代码，因为我使用AWS来满足很多托管需求

我已经实现了数据库后端，它将确保数据库region是可访问的，如果不可访问，它将从指定列表中选择另一个区域。这对该节点上的系统其余部分是透明的。因此，如果east-1a区域出现故障，我还有几个其他的区域，我也会将其故障转移到其中，比如西海岸。我跟踪当前正在进行的数据库事务，将它们发送到西海岸，并将它们转储到一个文件中，以便在旧数据库区域可用时将其导入

我的前端服务器位于分布在多个区域的弹性负载平衡器后面，这允许在某个区域出现故障时进行持久恢复。但是，它不能被依赖，所以我正在寻找解决方案，比如运行HAProxy，在我的ELB下降的情况下切换我的DNS。这是一项正在进行的工作，我无法给出我自己的解决方案的细节

要使数据处理持久，请查看芹菜并将数据存储在分布式mongo服务器中，以确保结果的安全。使用持久的数据存储来保存结果，可以在节点崩溃时将结果取回。它是以牺牲一些性能为代价的，但是如果您只依赖软实时约束，它应该不会太糟糕

---

上面的文章主要讨论AWS，但这些思想适用于任何需要保持高可用性和系统耐久性的系统。请记住，停机时间是可以的，只要您将停机时间最小化为一部分用户。

持久性是相当不特定的。如果您想要可伸缩，python中有很多很好的选项。我使用mongodb，使用gevent/pywsgi提供应用程序，并使用nginx作为前端。