3/N層アーキテクチャ、「フレームワーク+プラグイン」アーキテクチャ、地域分散アーキテクチャ

一般的に使用されるソフトウェア アーキテクチャ モデルは、3/N 層アーキテクチャ、「フレームワーク + プラグイン」アーキテクチャ、地理的に分散されたアーキテクチャの 3 つのタイプに分類できます。

1つ。 3つの建築モデル

1. 3/N層アーキテクチャ

これは古典的な多層アーキテクチャ モデルです。少し複雑なシステムや特に複雑なシステムの場合、階層化アーキテクチャを使用しないことは考えにくいです。次の図は、典型的な 3 層アーキテクチャです。

[[226476]]

今日では、すべてのプログラマーが 3/N 層アーキテクチャについて話すことができます。これはまさにシステムの複雑さを解決するための主流のモデルです。しかし、3/N層アーキテクチャを採用すればシステムの複雑さは解決できるということでしょうか?必ずしもそうではありません。鍵となるのは、3/N 層構造をシステムにどのように実装するかです。

3/N 層アーキテクチャを採用した後も、システムの拡張性 (変更に冷静に対応できること)、システムの保守性 (一度使用したシステムを廃棄しないため)、導入の容易さ (要件の変更時に新しいビジネス機能を導入しやすくすること)、その他のシステム品質属性など、非常に重要な問題を解決する必要があります。ただし、システムのスケーラビリティと保守性は、ほとんどのソフトウェア システムが対処しなければならない最優先事項であり、現在の複雑で変化に富んだソフトウェア環境によって決まります。機能要件を満たすことが最も基本であるのと同様に、3/N 層アーキテクチャの採用は長い道のりの最初の一歩にすぎません。

システムの拡張性、保守性、展開に関する問題を解決するために、「フレームワーク + プラグイン」アーキテクチャを採用しました。

2. 「フレームワーク＋プラグイン」アーキテクチャ

従来の 3/N 層アーキテクチャではシステムを「垂直」に階層化しますが、「フレームワーク + プラグイン」アーキテクチャではシステムを「水平」に分解します。 3/N 層アーキテクチャと「フレームワーク + プラグイン」アーキテクチャは同等であり、依存関係はありません。

しかし、私はよくそれらを一緒に使います。 3/N 層アーキテクチャの垂直階層化と「フレームワーク + プラグイン」アーキテクチャの水平階層化の後、私たちのシステムは「グリッド」構造として見ることができ、その一部は「プラグイン」を接続できる「拡張ポイント」として見ることができます。つまり、3/N 層アーキテクチャの各層に適切なプラグインを添付して、その層の一部の機能を完成させることができます。のように：

プラグインの最も重要な機能は、「ホットスワップ」が可能であることです。つまり、サービスを停止せずにプラグインを動的にロード/削除/更新できます。したがって、プラグイン技術を使用することで、次の機能を実現できます。

（１）UI層では、特定のユーザーインターフェースを置き換えたり、実行時に新しいビジネスに関連するユーザーインターフェースをロードしたりすることができます。ビジネス ロジック レイヤーでは、実行時にビジネス サービスを読み込み、置換、または削除できます。データ アクセス層では、プラグイン テクノロジを使用して、新しいデータベース タイプ (MySQL など) のサポートを動的に追加できます。

プラグインの「ホットスワップ」機能により、システムは非常にスケーラブルになります。

（２）システムをアップグレードする必要がある場合、多くの場合、プラグイン（業務プラグインなど）をアップグレードするだけで済みます。サービスの実行中にプラグインを自動的にアップグレードできます。

（３）システムを「フレームワーク＋プラグイン」構造にするためには、システムのすべての層で「疎結合」設計を行う必要がある。疎結合されたコンポーネントのみを「プラグイン」にすることができます。

「フレームワーク + プラグイン」アーキテクチャを 3/N 層アーキテクチャに統合する際の最も難しい部分は、ビジネス ロジック層の疎結合です。これには、ビジネス要件間の関係を慎重に分析し、密接に結合されたビジネスを 1 つのコンポーネントにカプセル化することが必要です。このようにして取得された独立したビジネス コンポーネントは、プラグインになる機会があります。このプロセスでは、継続的な再構築と設計の再構築が必要になる場合があります。

疎結合されたコンポーネントは、密結合されたコンポーネントよりも明確で保守が容易であることがわかっています。さらに、このアーキテクチャ モデルには AOP フレームワークが導入されており、Aspect フォーカス (処理ログ、権限管理など) の集中プログラミングが可能になるため、Aspect コードが通常のビジネス ロジック コードと混在することがなくなり、コードの明瞭性と保守性がさらに向上します。

上記の紹介から、3/N 層アーキテクチャと「フレームワーク + プラグイン」アーキテクチャを組み合わせることで、システムのスケーラビリティ、保守性、および容易な展開とアップグレードの能力を強化できることがわかります。

3. 地理的に分散したアーキテクチャ

私は偶然に「地理分散アーキテクチャ」という用語を作り出しました。ハハハ、意味が正確かどうかは分かりません。地理的に分散されたアーキテクチャは、主に地理的な分散を必要とする LBS (位置情報サービス) などのアプリケーションを対象としています。地域分散アーキテクチャは、上記の 3/N 層アーキテクチャと「フレームワーク + プラグイン」アーキテクチャに基づいています。それらの関係は次のとおりです。

ここで、地理的に分散されたアーキテクチャについて簡単に説明します。全国の主要都市にビジネス機能サービスを提供する必要があるとします。各都市には多数の顧客がいて、各都市がアクセスするデータ (各都市の地図データなど) が異なり、アクセスする機能も異なる可能性があります (一部の都市では天気予報のクエリ サービスが提供され、他の都市では提供されないなど)。お客様は、当社のシステムにサービスをリクエストするだけでなく、同じ都市または別の都市にいる友人と即座にコミュニケーションをとるために当社のシステムを使用したいと考えるかもしれません。

さて、地域分散アーキテクチャが上記と同様の要件をどのように解決できるかを見てみましょう。

まず、地理的に分散されたアーキテクチャでは、ユーザー管理サービスとビジネス機能サービスを分離し、それぞれアプリケーション サーバー (AS) と機能サーバー (FS) で処理し、異なるノードに展開します。 AS と FS はともに、3/N 層アーキテクチャと「フレームワーク + プラグイン」アーキテクチャを組み合わせたアーキテクチャを採用しています。たとえば、FS は機能プラグインを通じて機能サービスを提供します。

たとえば、武漢地域では AS と FS を展開し、クライアントは AS に接続してサービス要求を行います。ある日、武漢の顧客数が劇的に増加したとします。すべてのビジネス計算は FS 上で行われるため、FS に最大の負担がかかります。

現時点では、地域分散アーキテクチャにより、サービスを停止することなく FS サーバーを動的に追加することができ、新しく追加された FS サーバーは AS に自動的に登録されます。

AS は各 FS の負荷 (CPU 消費量、メモリ消費量など) を監視できます。クライアントからのリクエストが到着すると、AS は処理負荷が最も低い FS にリクエストを引き渡し、FS の負荷分散を実現します。

クライアント A がクライアント B とリアルタイムで通信する必要がある場合、これらの通信メッセージは AS を介して転送されます。

上記は武漢における当社のシステムの展開状況ですが、他の都市での展開状況も同様です。

この場合、AS は互いに独立していますが、クライアント A がクライアント E とリアルタイムで通信する必要がある場合や、クライアント A が上海地域固有のサービスを要求する必要がある場合など、AS は互いに通信する必要があることがよくあります。

地域分散アーキテクチャでは、地域間アプリケーション サーバー (IRAS) を使用して AS 間の通信問題を解決します。すべての AS は、起動時に自動的に IRAS に登録されます。

長沙でもサービスを提供したい場合は、長沙に AS と FS を展開するだけで、上図に示す地域分散アーキテクチャ全体に統合できます。

これは、地域分散アーキテクチャの簡単な紹介です。読者はより多くのコンテンツを自分で分析し、探索することができます。

二。建築モデルのサポート

上記のアーキテクチャ モデルをサポートする独自のツール セットを持っていない場合は、私がここで無意味なことを言って自慢していると思うかもしれません。過去数年間の開発中に、上記のアーキテクチャ モデルをサポートするフレームワークとライブラリをいくつか蓄積してきました。

（1）DataRabbitはリレーショナルおよびORMベース（軽量）のデータアクセスを提供し、プラグインを通じて新しいデータベースタイプをサポートします。

（２）ESFrameworkは、分散システム（前述の地理的に分散されたアーキテクチャなど）間の基盤となる通信（TCPとUDPに直接基づく）を解決します。

（3）AddinsFrameworkは、「フレームワーク+プラグイン」アーキテクチャモデルのサポートを提供します。

（4）ESAspectはプロキシによって実装され、アスペクトプログラミングをサポートするAOPフレームワークです。

（５）EsfDRArchitectureは地理的に分散したアーキテクチャモデルのサポートを提供します。たとえば、FS の動的な追加/削除をサポートします。 FSの負荷分散。 AS と FS、AS と IRAS 間の通信。地域間サービスリクエストなど

上記のアーキテクチャ設計は、主に J2EE システム設計に偏っているように感じます。通信システムなどの他の設計であれば、話は別かもしれません。