モジュラーアーキテクチャの実装に関する RFC

Question

Webアプリケーションのモジュール化に関する意見を募集しています。言語に関係なく、すでにほとんどのアプリケーションにはバックエンド DB があり、それぞれの Web アプリケーション サーバー (Apache、IIS、Lighttp など) との連携をサポートしていますが、私が対応した多くの開発者は Memcached などの使用に問題を抱えていました。 Web アプリの直接のプロセス空間の外側。

Web アプリケーションのモジュール化は私が信じているほど良いことなのでしょうか、それとも私に何か欠けていて、シニアからすべての人に迷惑をかけているのでしょうか。開発者から CTO まで、ビジネス ロジックの特定の部分を Web フロントエンドから特殊なバックエンド サービスに移動することに躊躇していますか?

たとえば、数年前、非常にトラフィックの多い Web サイトのプロジェクト設計会議で、プロセス集約型の ACL ロジックをフロントエンド フレームワークから取り除き、それを半クラスタ化可能なサービス アプリケーションに変えることを提案したところ、撃墜されました。バックエンド。私にとっての利点は、コードがより明確に分離され、REST/JSON を PHP と Python の間のブリッジとして使用することで、複数の場所で ACL ロジックを再利用できることでした。

私のアイデアに反対した開発者は、それは「複雑すぎる」と主張しましたが、私にはどうやっても理解できませんでした。私の主張は、プレゼンテーション層にタグスープが存在する可能性があるのと同じように、コードのロジックスープが存在する可能性があり、多くの場合、問題が発生した場合に「外科的」修正を実行するのは不可能に近いほど互いに噛み合っているということです。

簡潔に言うと、大規模なアプリケーションを独立しているが協調的なプロセス (スレッドやサブリクエストではない) に分割することの短所と長所は何でしょうか。MySQL、Memcache、同様のサービス プロセスは優れています...しかし、なぜ他のものではダメなのでしょうか?この道を進むのはどうして「複雑すぎる」のでしょうか?

Answer 1

まあ、時々「複雑すぎる」「私は私の快適ゾーンの外に考えたくはありません。」という意味。

基本的な概念は、ここではかなり妥当なサービス指向アーキテクチャの話をしている---いいですね。

さて、限り長所と短所として、それに対する最初の事は確かに人々が彼らの快適ゾーンの外で考えることを取得する必要があなたは<全角> のやることです。より技術的な詐欺は、あなたが、実際には、何であるかのセッション状態を維持する必要があるということです。あなたの認証サービスから認証トークンを拾うと言います。どのようにそのトークンは正しいユーザーセッションに関連付けられたままになるだろう。

もう一つの問題は、それがよりダイナミックに起こっているので、それは、デバッグに難しくなるかもしれないということです。

プロ側では、しかし、あなたはセッション状態の問題を満たすことができれば、あなたは非常にスケーラブルなアーキテクチャを取得します。あなたはより多くのサービスが必要な場合、あなたはどちらかのサーバーを拡大したり、単純に別のサーバーを追加することができます。

Answer 2

私は、コア サーバー/ビジネス ロジック機能を Web アプリケーション コードから分離することを支持しています。これにはいくつかの異なる理由があります。

1. ビジネス ロジックをより適切に制御できます。これを GUI コードと混ぜて混乱を引き起こすことはありません。すべてのビジネス ロジックを分離しておき、後でコード機能を呼び出す API を作成し、ビジネス ロジックが GUI コードに入り込まないようにしたいと考えています。
2. 最初から、クライアントからサーバーと通信するために自分で使用する適切な API を設計する必要があります。クライアントは Web インターフェイスであることも、リモート ユーザーであることもできます。
3. 安定性。GUI Web コードは簡単に間違って記述され、メモリを大量に消費してアプリ全体がダウンしてしまう可能性があります。
4. 拡張するために、これらの個別のコンポーネントを別のサーバーに移動できます。すでにクラスタリングが可能なキャッシュ システムを使用している場合、スケールアップはキャッシュ サーバーを追加するだけで簡単になります。
5. アプリケーションの更新は GUI コードに対して最も頻繁に行われるため、ほとんどの場合、コア サービスを停止する必要がないことがわかりました。
6. 安全。セキュリティ コードがサーバー コードに実装されていることを確認できるため、誰かが API を使用しても、GUI コードに侵入したセキュリティ コードをバイパスできなくなります。

私たちのシステムには、Java アプリケーションとして実装されたコア「エンジン」サービスがあります。Web アプリケーションも Java で書かれており、(現時点では) 通信は RMI 経由で行われます。私たちのサイト/アプリケーションは成長していますが、まだ memcached や JCS などのキャッシュ サービスの使用を開始する必要はありません。