0

目標: ビジネス ロジックとプロセスを e コマースのショッピング カートから分離します。念のため申し上げておきますが、私たちはより大きな e コマース ショップですが、ここで膨大な量のトラフィックを処理しているわけではありません。1 日に数千人の訪問者しかいません。

PDF 生成、見積ロジック、請求書と注文書の処理などを処理するために、保守可能な外部アプリケーションが必要です。現在、これは主にモジュラー ショッピング カート ソフトウェアに組み込まれていますが、より多くのモビリティ、安定性、および保守性を実現するために、私たちは考えています。これが最良の方向です。現在、ショッピング カートには LAMP、外部データのインポートと処理には MongoDB、Python を使用しています。この特定のアプリケーションに PHP を使用したいと考えています。ビジネス ロジックの多くは既に PHP で記述されており、移植する必要があるだけなので、開発はより迅速に行われます。

これは新しい問題ではないと確信しています。では、ほとんどの大規模なサイトはどのようにそれを行っているのでしょうか? アプリケーション間の通信に SOAP/REST のようなものを使用するのが最善でしょうか、それとも遅すぎるのでしょうか。e コマースのショッピング カートで直接使用される PHP ライブラリを構築するだけでよいのでしょうか。

もし私に選択肢があれば、Web サービスを実行したいと思いますが、オーバーヘッドが大きすぎて意味をなさないのではないかと心配しています。経験上、UPS API を使用するのは楽しいことではありません。私は REST と DAO の組み合わせに傾倒しています。これを経験したことがある、または以前にこのようなことを見た人からの連絡をお待ちしています。また、メッセージング キューを使用することもできます。これは、時間がかかるプロセスには適していますが、即時の応答が必要なものには適していません...

4

1 に答える 1

1

プロトコルのパフォーマンスは小さな問題である可能性が高く、Web サービスが異なるマシンに存在する場合、使用しているプロトコルに関係なく、マシン間のレイテンシがパフォーマンスの主要なボトルネックになります。

サーバーを同じネットワーク内にプロビジョニングできる場合に最適です。リモート サービスにクエリを実行するときは常に、クエリの数を減らすのが最善です。代わりに、可能な限り一括でクエリを実行するように API を設計する必要があります。

REST または SOAP で唯一考えられる問題は、プッシュ通知を行う簡単な方法がないことです。代わりに、Web フックを使用する必要があります。しかし、それは本当に小さな問題です。

于 2013-05-21T01:01:05.330 に答える