0

分散 API リクエストの実験に取り組んでいます。ユーザーがサーバーに代わってリクエストを作成できるようにする Web サイトを PHP で構築しています。これにより、リクエストをすべてのユーザーに分散し、大量のトラフィックがあってもアプリケーションのスケーラビリティを維持できるはずです。

私の最終的な目標は、ブラウザに API リクエストを作成させ、レスポンスを解析して、解析したデータをサーバーに送信することです。これにより、アプリケーションが現在苦しんでいるパフォーマンスのボトルネックが解消されます。しかし、このシステムを構築する方法に問題があります。

私が想定したシステムの仕組みは次のとおりです。

  1. ユーザーがウェブサイトにアクセス
  2. API リクエスト キューは、作業のリストから読み込まれます
  3. ブラウザは作業キューから複数の API リクエストを作成し、レスポンスを解析します
  4. ブラウザは解析したデータを AJAX 経由でサーバーに送信します
  5. サーバーは古いデータを更新し、タイムスタンプを追加し、作業キューからリクエストを削除します
  6. 所定の TTL 作業が再びキューに追加され、プロセスが繰り返された後

ここに私の懸念があります：

  • API リクエストがサーバーと同じドメインで行われていません。ユーザーのブラウザーからデータを要求するときに、これが問題を引き起こすことを理解しています (同一生成元ポリシーのため)。プロキシ PHP ファイルの使用を検討しましたが、これもいくつかの懸念を引き起こしました。次の箇条書きを参照してください。
  • 解析の配布は問題の一部に過ぎず、他の問題は私の要求を調整することです。1 秒あたりに実行できるリクエストの数が制限されており、スケーラビリティの問題が発生しています。リクエストを作成するためにプロキシ ファイルを作成することで、リクエストが技術的にはまだプロキシ ファイル経由でサーバーから発信されているため、リクエストのスロットリングによってまだ制限されているのではないかと心配しています。
  • ブラウザーは応答を解析してサーバーに送信しているため、誰かが AJAX 呼び出しを介してサーバーに悪意のあるデータを挿入できる可能性があります。

そして最後に私の質問：

  • 私の要件に基づいて、プロキシ PHP ファイルを使用することは、これらの要求を行うための最良の方法ですか?
  • プロキシ ファイルを使用することが最善の方法である場合、要求のスロットリングによって引き続き制限されるのでしょうか、それとも要求 (およびその結果としてスロットリングの制限) がクライアントに渡されるのでしょうか?
  • 標準的なセキュリティ対策 (文字列のエスケープ、スラッシュの削除、SSL の使用) 以外に、AJAX からサーバーへの通信で行うべき予防策はありますか?
  • 誰かがすでにこれを行っていますか?もしそうなら、私が従うことができる例はありますか? すべての結果が私の要件とは無関係であるため、検索の言葉遣いが間違っているに違いありません。
  • そして最後に、いくつかの任意の意見の質問... この方法論についてどう思いますか? この構造は致命的な欠陥ですか？私がやろうとしていることを達成するためのより良い方法はありますか?

よろしくお願いします。

4

1 に答える 1

0

この問題を解決するために最終的に行ったことは、JSONP を使用し、クライアントのブラウザーを介してコンテンツをロードすることです。フローは次のとおりです。

  • クライアントがサイトにアクセスし、API リクエスト URL のリストを受け取ります。これらの URL にはスクリプト タグが埋め込まれています (同一生成元ポリシーを回避するため)。JSONP メソッドを使用すると、データはデータ オブジェクトを含むコールバック関数として返されます。
  • 次に、JSONP データは、クライアントによる操作を回避するためにプライベート関数でクライアント側で解析され、AJAX ハンドラーに送信されます。セキュリティを強化するために、ハンドラーにエスケープと検証も追加しました。
  • ハンドラは、解析されたデータをタイムスタンプとともに MySQL に送信します。挿入が行われた場合、指定されたエントリのワーク キューが更新されます。CRON ジョブは定期的にクリーンアップ ルーチンを実行して、キューを更新し、キャッシュされた配列に設定します。新しい URL がこの配列から取得され、プロセスが繰り返されます。

いくつかのテストを行った後、質問について次のことがわかりました。

  • プロキシ ファイルは、クライアントに代わって要求を行うだけです。サーバーがリクエストを行っているため、これは依然としてスロットリングの対象となります。
  • クライアントのブラウザー ウィンドウから要求を行う唯一のメソッドは、JSONP、CORS、および WebSockets です。CORS と Websockets はすべてのブラウザーで利用できるわけではないため、私はそのルートには行きませんでした。JSONP にはコンテンツの長さの制限がありますが、クライアントごとに大量のデータを解析するのではなく、全体として大量のデータを解析しています。これが、JSONP を選択した理由です。iframe の解析も機能しますが、ほとんどのブラウザーで機能するソリューションを見つけることができませんでした。最終的には、可能な限り多くのユーザーがディストリビューションで共有できるように、データを取得する複数の形式を追加したいと考えています。
  • JSONP と CORS をサポートする多くの API があります。実際、その数には驚きました。API がそれをサポートしていない場合、少しトリッキーになる可能性がありますが、私はその橋を渡ります。
  • この方法に何らかの致命的な欠陥があると考えている人がいるかどうかを知りたいのですが、カスタムスクリプトソリューションの代わりに、JSONP として確立されたものを使用する方がはるかに快適だと思います.
于 2013-08-30T14:10:40.883 に答える