Python Web 应用的架构解决方案 [英] Architecture solution for Python Web application

问题描述

我们正在设置 Python REST Web 应用程序.现在，我们正在使用 WSGI，但我们将来可能会对其进行一些更改(例如，使用 Twisted 来改进可扩展性或其他一些功能).我真的很想得到一些关于什么是 Python 中 Web 应用程序的良好架构方面的帮助.

We're setting up a Python REST web application. Right now, we're using WSGI, but we might do some changes to that in the future (using Twisted, for example, to improve on scalability or some other feature). I would really like some help regarding what is considered a good architecture for a Web application in Python.

总的来说，我们的应用程序提供动态内容，处理来自客户端的中到高级数据，执行非常高需求的数据库、网络和文件系统调用，并且应该容易"扩展(这里引用是因为如果解决方案很棒但是配置可扩展性有点困难，它肯定会被认为是好的).从中长期来看，我们可能希望将其发展为高度并行的应用程序.Google App Engine 不是被接受的建议，主要是因为它的成本.

In general our app serves dynamic content, processes a moderate to high level of data from clients, performs pretty high-demand database, network and filesystem calls and should be "easily" scalable (quotes here because if a solution is great but somewhat tough to configure for scalability, it would definitely be thought of as good). We would probably like to evolve this into a highly parallel application in the mid-to-long term. Google App Engine is not an accepted suggestion, mainly because of its cost.

我的问题是:

1. 使用 WSGI 是个好主意吗?我们应该研究像 Twisted 这样的东西吗?
2. 我们应该使用 Apache 作为静态文件的反向代理吗?
3. 是否有一些不同的模式或架构值得我们考虑我没有提到的?(即使完全显而易见).

对此有任何帮助将不胜感激.非常感谢！

Any help at all with this would be very appreciated. Thanks a lot!

推荐答案

WSGI 应用程序会很好 这主要是一个后端问题和数据处理问题，在我看来，因为这是更多架构部分发挥作用的地方.我会考虑使用 Celery ( http://celeryproject.org/ ) 进行工作分配和后端扩展.Twisted 将是一个不错的选择，但看起来您已经编写了用作 WSGI 应用程序的那部分，所以我只是用 Celery 扩展它.

A WSGI application will be fine this is mostly a backend question and data processing question, in my opinion as that is where more architectural parts come into play. I would look into using Celery ( http://celeryproject.org/ ) for your work distribution and backend scaling. Twisted would be a good choice, but it appears you already have that portion written for use as a WSGI application so I would just extend it with Celery.

我不知道你项目的范围，但我会考虑到 Celery 来设计它.

I do not know the scope of your project but I would design it with Celery in mind.

我希望我的前端端点是 WSGI(因为你已经写好了)并编写了通过消息分发的后端.然后，您将拥有一个后端节点池，可以从 Celery 队列中提取消息并完成所需的工作.它看起来有点像:

I would have my frontend endpoints be the WSGI (because you already have that written) and write the backend to be distributed via messages. Then you would have a pool of backend nodes that would pull messages off of the Celery queue and complete the required work. It would look sort of like:

Apache -> WSGI 容器 -> Celery 消息队列 -> Celery Workers.

Apache -> WSGI Containers -> Celery Message Queue -> Celery Workers.

apache 节点将位于某种负载均衡器的后面.这将是一个相当简单的扩展架构，并且如果正确完成，相当可靠.在这样的系统中编写故障代码，你会没事的.

The apache nodes would be behind a load balancer of some kind. This would be a fairly simple architecture to scale and is, if done correctly, fairly reliable. Code for failure in a system like this and you will be fine.

这篇关于Python Web 应用的架构解决方案的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！