2

私はいくつかのインターネット ショップを運営する会社で働いています。サイトのコンテンツと製品の管理、注文処理、パートナー関係、経理、顧客ベースなど、コード全体を完全に書き直しています。現在、すべてのもの (すべての内部管理サイト、ビジネス ロジック、およびインターネット ストア Web サイト) が単一の LAMP インスタンス上で実行され、完全にすべてのデータが文字通り単一のガベージ データベースに配置されているシステムがあります。このため (また、10 年間の開発、perl、php コードの品質から部分的に書き直されているため) 新しい Web ストアを導入し、既存のものを再設計したり、ロジックの何かを変更したりすることは、一種の不可能な作業です。

古いコードを書き直すだけでなく、システム アーキテクチャを最適化するために、Web サイトを (相互に) 分離し、Web サイトから「ビジネス コア」を分離し、ビジネス コアを相互に分離することに決めました。

ある時点から、すべての Web ショップはほとんどが 1 つの共通の製品ベースを販売しています。それらは一種の鏡であり、海外の顧客をターゲットにするために設計が異なる場合があります (タイトルと説明は異なる場合があります)。私たちが販売するものは、ローカルパートナーに依存するサービス製品ですが、事前に定義された共通の製品範囲があります. ただし、一部の都市では特別価格を設定しており、他の都市では通常の商品範囲に加えて充実した商品範囲を提供しています。そのため、特定の都市に焦点を当てた専用の Web サイト、特別オファーのみを販売する Web サイトなども運営しています。

各 Web サイトが独自の製品データベース (別のコピーである場合もあります) を持つソリューションとは対照的に、私はすべての製品の説明情報、異なる都市および/または異なるサイトでの入手可能性、および価格を単一の分離された製品管理システムに構成することを検討しています。 SOAPを介してすべての情報を提供します。また、ユーザーがサイトにアクセスするたびに、サイトはそのサービスを消費し (いくつかのパラメーターを提供)、製品を一覧表示します。どうやら共通のアクセス ライブラリを開発して、すべてのサイトに含めることができます。

1) その解決策は適切ですか? キャッシュなしで十分に高速に実行できますか? リソースが限られているため (1.5 開発者)、すべてのサイトで memcached を使用する必要があるなど、技術的な複雑さを (可能な限り) 導入しないようにしています。

2) 分離した方法でシステムを再構築するとします。memcached などを使用したすべての作業に自分自身を従事させるのに十分なメリットがありますか?

3) SOAP サーバー側でデータをキャッシュすることは合理的ですが、Web サイトではなく、何千もの SOAP リクエストを作成し続けますか?

すべてのシステムは分離されます。それらに関連する Web サイトの一部は、注文処理、顧客認証 (すべての Web サイトで共通)、支払い受け取りの統合などです。注文を Web で行う必要がある注文処理の場合-サイトは、SOAP を介してリモートで注文処理システムに配置し、次に独自の SOAP サーバーを公開して、注文ステータスの更新を受信します。

4) そのデカップリング SOAP 中心の哲学は正しいですか?

使用するテクノロジは、nginx、php、MySQL です。

4

1 に答える 1

0

エデュアルド。私はあなたの質問に答えようとします。最初に少し前置きをしてから、ポイントごとに説明します。

I. 完全な書き直しはシステム アーキテクチャの最適化でなければならないことは事実上明らかです。あなたの特定のケースでは、アーキテクチャに「何らかの」モジュール性を導入することは、そのような種類の最適化です。(また、AR スタイルのアプリケーション フレームワークに縛られるまでは、少なくとも 3 つの認識可能なコーパスがコードに含まれている必要があることも強調しておきます。

1) モデルは、今日では非常に「一般的な」用語ですが、ドメイン (オブジェクトと関係) のすべての抽象的な知識を、そのドメインとはあまり関係のないものから分離することは依然として理にかなっています
2) データ永続化組織。は基本的に「データ アクセス レイヤー」ですが、お好みの ORM フレームワークにより、それほど厚くないことを願っています。
3) 上記以外のライブラリコード

この設定を使用すると、大規模なコード部分をすべて再配布可能にし、必要な数の仮想ノード間で共有できるようにすることができます。

Ⅱ．アプリケーションの品質に関する一般的な考え方について、私ができるちょっとした注意点があります。システムの簡潔さ、プロジェクトの締め切り、および結果として得られるパフォーマンス指標の間でバランスを見つける必要があります。これらはすべて相反する要件ですが、あなたの場合の主なものは何なのかはまだ言えません。しかし、あまりにも一般的で抽象的なコードは保守が難しいことが判明する可能性があるため、結果として得られるシステムの機能要件の有効な説明が少なくとも必要になります..少なくとも3〜5か月間有効だと思います.

次に関連する部分:
1) 適切か? 少なくとも、あなたが今持っているものよりも適切でなければなりません。キャッシュなしで高速に実行できますか? 本当にわかりませんが、短い答えは「いいえ」だと思います-正確にターゲットデータキャッシング（大きなデータセット）を意味していると思いますが、これはmemcacheのようなものには当てはまりません。(ところで、あなたには 1.5 開発者はいませんが、(1 - 0.25) 開発者は、0.75 を与えるものだと思います :))
2) 提案として、ビジネスロジック関連のエージェントを PHP よりもくだらないもので書くことができます。それ以外は、関連する可能性のあるテクノロジーに関する個人的な経験に依存します。
3) どちらの方法も可能だと思いますが、Web 側でのキャッシュの方が優れていると思います。ボトルネックの可能性を排除できるからです。
4) その具体例は？私のビジョンではありません。議論として、2 つの Web サイトの統合 (!) は、一般的にひどいプロセスであると言えます。

于 2010-08-17T18:12:27.043 に答える