7

PythonRESTWebアプリケーションをセットアップしています。現在、WSGIを使用していますが、将来的に変更を加える可能性があります（たとえば、スケーラビリティやその他の機能を改善するためにTwistedを使用します）。PythonのWebアプリケーションに適したアーキテクチャと見なされるものについて、本当に助けが必要です。

一般に、私たちのアプリは動的コンテンツを提供し、クライアントからの中程度から高レベルのデータを処理し、非常に需要の高いデータベース、ネットワーク、およびファイルシステムの呼び出しを実行し、「簡単に」スケーラブルである必要があります（ソリューションが優れているが、やや難しい場合は、ここで引用しますスケーラビリティを構成する場合、それは間違いなく良いと考えられます）。中長期的には、これを高度に並列化されたアプリケーションに進化させたいと考えています。Google App Engineは、主にそのコストのために、受け入れられた提案ではありません。

私の質問はこれです：

  1. WSGIを使用するのは良い考えですか？代わりにツイストのようなものを調べる必要がありますか？
  2. 静的ファイルのリバースプロキシとしてApacheを使用する必要がありますか？
  3. 私が言及していないことを考慮すべきいくつかの異なるパターンまたはアーキテクチャはありますか？（完全に明白であっても）。

これで少しでも助けていただければ幸いです。どうもありがとう！

4

2 に答える 2

5

WSGIアプリケーションは問題ありませんが、これは主にバックエンドの質問とデータ処理の質問です。私の意見では、より多くのアーキテクチャー部分が関係してくると思います。作業の分散とバックエンドのスケーリングにCelery（http://celeryproject.org/ ）を使用することを検討します。ツイストは良い選択ですが、WSGIアプリケーションとして使用するためにその部分がすでに作成されているようですので、Celeryで拡張します。

あなたのプロジェクトの範囲はわかりませんが、Celeryを念頭に置いて設計します。

フロントエンドエンドポイントをWSGIにし（既に記述しているため）、メッセージを介して配布されるバックエンドを記述します。次に、Celeryキューからメッセージをプルして、必要な作業を完了するバックエンドノードのプールがあります。次のようになります。

Apache->WSGIコンテナ->Celeryメッセージキュー->Celeryワーカー。

apacheノードは、ある種のロードバランサーの背後にあります。これは、スケーリングするのにかなり単純なアーキテクチャであり、正しく実行されれば、かなり信頼できます。このようなシステムでの障害のコードを記述すれば、問題はありません。

于 2012-11-05T19:47:02.617 に答える
2

geventとzeromq（または他の「mq」、私はzeromqの経験しかありません）の使用を検討するかもしれません。複数のgeventプロセスを起動し、それらをzeromqと相互に通信させるのは簡単です。それらをロードバランサーの背後に置くことができ、nginxはロードバランサーとして問題なく機能し、nginxを使用して静的ファイルを提供することもできます。

また、geventでは、Werkzeugやwebobなどの「低レベル」のWebフレームワークを使用できます。Werkzeugは私の個人的な選択です。

GeventにはWSGIサーバーが組み込まれており、非常に高速で安定しています。werkzeugは、WSGI環境を変換し、データを使いやすいオブジェクトにリクエストします。

http://www.gevent.org/
http://werkzeug.pocoo.org/
https://github.com/traviscline/gevent-zeromq

ここでは、gevent、zeromq、その他のいくつかの優れた初心者向け記事を見つけることができます。
http://blog.pythonisito.com

興味深い読み物
https://raw.github.com/strangeloop/2011-slides/master/Lindsay-DistributedGeventZmq.pdf

于 2012-11-05T21:06:31.737 に答える