14

通常、すべてがデータベースと通信し、いくつかの外部統合ポイントを持ついくつかの webapp および ejbjar モジュールで構成される 3 層のエンタープライズ ソリューションを構築します。

通常、各モジュールには、ソリューションの存続期間中に変更される可能性のある独自の構成が必要です。データソース、キュー、メモリ要件などを設定するためにコピーして構成する必要がある 18 個のプロパティ ファイルがあるため、展開は悪夢になります。

私は希望を持っていますが、より良い方法があるかもしれないと楽観的ではありません. 私たちが検討/使用したいくつかのオプションには、それぞれ長所と短所があります。

  1. 複数の Maven プロジェクトと継続的インテグレーション (例: hudson または jenkins) を使用して、各環境 (dev、qa、prod) のすべてのプロパティ ファイルを含む構成 jar を構築し、すべてを EAR としてバンドルします。しかし、必要なときに本番環境で簡単に変更することはできません。
  2. ほとんどの設定を DB に置き、それを変更するための簡単な画面を用意します。内部的には、値を読み取って変更できる汎用構成サービス EJB を使用できます。各モジュールには、特定のゲッターとセッターを持つカスタム拡張バージョンを含めることができます。
  3. すべてのプロパティ ファイルをバージョン管理してから、本番環境でチェックアウトし、変更を加えた後で本番環境のブランチにチェックインします。

これらすべてで、コンテナ固有の方法でデータソースやキューなどを構成する必要があります:(

4

6 に答える 6

2
  1. カスタム構成オブジェクトを にバインドすることを検討してJNDIください。次に、アプリでこのオブジェクトを検索して構成します。Map利点 - 一般的なorの代わりにカスタム構成オブジェクトを使用できますProperties
  2. もう 1 つの方法は、JMX必要なアプリケーションを構成するために使用することです。利点 - 構成する必要があるオブジェクトを直接バインドしてから、アプリケーションのコンポーネントを構成するために、またはMBean Serverそのようなよく知られたツールを使用できます。jconsolevisualvm

どちらの方法でも、実行時のアプリケーションの動的再構成がサポートされます。を使用することをお勧めしJMXます。

于 2011-11-17T11:07:50.457 に答える
2

私はこれを行う方法を見つけるためのいくつかのサイクルを経てきました。私はまだ明確な答えを持っていません。

最後のサイクルは、プロパティ ファイルに基づくプロセスで終わりました。各サーバー インスタンスは、すべてを構成する単一のプロパティ ファイルで構成されるという考え方でした。このファイルは、メモリ パラメータを設定するための起動スクリプト、アプリ サーバー、およびアプリケーション自体によって読み取られました。

ただし、重要なことは、このファイルが直接管理されていないことです。むしろ、それはビルド プロセスの産物でした。バージョン管理に保持されたさまざまな目的のさまざまなファイルと、適切なファイルをマージするビルドステップがありました。これにより、さまざまな軸に沿って共有される共通点を抽出できます。

たとえば、開発、継続的インテグレーション、QA、UAT、ステージング、および本番環境があり、それぞれに独自のデータベースがありました。異なる環境のサーバーには異なるデータベース設定が必要でしたが、特定の環境の各サーバーは同じ設定を使用していました。それで、development-db.properties、qa-db.properties などのようなものがありました。各環境には、Web サーバー、コンテンツ管理サーバー、バッチ処理サーバーなど、いくつかの種類のサーバーがありました。各サーバーには、ヒープ サイズなどの JVM 設定があり、他の種類のサーバーとは異なりますが、サーバー全体で一貫しています。環境。そのため、web-jvm.properties、cms-jvm.properties、batch-jvm.properties などがあります。また、特定のシステムをオーバーライドする方法もありました - production-cms-jvm.properties のようなものです。共通点もありました。

私たちのビルド プロセスは、各セットから適切なオプションを選択するだけではなく、実際にはもう少し複雑でした。各環境の各サーバーには、含める他のファイルを指定するマスター ファイルがありました。含める他のファイルをファイルに指定できるようにしたので、インポートのグラフを作成して再利用を最大化できました。

なかなか複雑な仕上がりになりました。複雑すぎると思います。しかし、それは機能し、制御された方法で多くのサーバーに影響を与える変更を非常に簡単に行うことができました. 機密情報を含む、開発からの一連の入力ファイルと運用からの別の入力ファイルもマージしました。とても柔軟なアプローチでした。

于 2012-03-21T18:51:22.627 に答える
2

これはすでに回答されており、私の回答は必ずしも一般的ではありませんが、私の見解は次のとおりです。

ここでは、アプリケーションの設定ではなく、システム/リソースのプロパティのみを考慮していることに注意してください。私の見解では、アプリケーションの設定 (支払いのしきい値やその他の設定などはデータベースに保存する必要があります。これにより、サービスを再起動したり、プロパティ ファイルを再展開または再読み込みしてダウンタイムを引き起こしたりすることなく、システムを再構成できます) .

システムのさまざまな部分 (Web サービス エンドポイントなど) が相互に接続する方法に影響を与える設定については、JNDI ツリーを利用します。

データベース接続と JMS 接続は、Websphere コンソールを使用してセットアップされ、Websphere 管理者が管理できます。これらは、必要に応じてバージョン管理に入れることができる JACL スクリプトとして作成することもできます。

JNDI リソースに加えて、バックエンドへの Web サービス呼び出しのユーザー名などの追加のプロパティについては、Websphere の「名前空間バインディング」を使用します。これらのバインディングは、Websphere コンソールを使用して編集でき、「cell/persistent/mypassword」名を使用して JNDI 経由でアクセスできます。

したがって、「mypassword」バインディング (文字列) を作成することができ、その管理は Websphere 管理者 (開発者の目や、実稼働システムにアクセスしてはならない他の人々から離れて) に委ねられますが、同じ EAR ファイルを使用できます。開発、テスト、運用前、および運用 (他の違いが忍び寄る可能性が低くなるため、システムごとに異なる EAR ファイルを使用することをお勧めします)。

次に、Java コードは単純な JNDI ルックアップを使用します (場合によっては値をメモリにキャッシュします)。

プロパティ ファイルに対する利点:

  • システム プロパティにパスワードが含まれているため、保護する必要がある「脆弱な」ファイルがない。
  • そのファイルの場所へのアクセスを許可するために Java セキュリティ ポリシーを追加する必要がない

データベース プロパティに対する利点:

  • 1 つのデータベースをアプリケーション サーバーに関連付ける必要はありません。

それが役立つことを願っています

于 2012-03-27T13:15:43.013 に答える
1

複数の Maven プロジェクトと継続的インテグレーション (例: hudson または jenkins) を使用して、各環境 (dev、qa、prod) のすべてのプロパティ ファイルを含む構成 jar を構築し、すべてを EAR としてバンドルします。しかし、必要なときに本番環境で簡単に変更することはできません。

構成はアプリケーションインスタンスのデータベースにあるはずだと思います。ローカル マシンの構成は、dev や QA、PROD、DR などとは異なる場合があります。

必要なのは、簡単な方法で構成をデータベースから取得する方法です。

Apache commons-configuration の提供された依存関係を使用して別のプロジェクトを作成します。データを保存する方法はたくさんありますが、データベースが好きで、構成はデータベース環境に存在します。

    import javax.sql.DataSource;
    import org.apache.commons.configuration.DatabaseConfiguration;

    public class MYConfig extends DatabaseConfiguration {

        public MYConfig(DataSource datasource) {
            super(datasource, "TABLE_CONFIG", "PROP_KEY", "PROP_VALUE");
        }
    }

ほとんどの設定を DB に置き、それを変更するための簡単な画面を用意します。内部的には、値を読み取って変更できる汎用構成サービス EJB を使用できます。各モジュールには、特定のゲッターとセッターを持つカスタム拡張バージョンを含めることができます。

単純な API としての Commons 構成。その後、必要に応じて GUI を作成できます。好きなようにインターフェースを行うことができます。または、クイックウィンとしてインターフェイスがありません。

すべてのプロパティ ファイルをバージョン管理してから、本番環境でチェックアウトし、変更後に本番環境のブランチにチェックインします。

バージョン管理は素晴らしいです。コンポジションを使用して別の DatabaseConfiguration を追加します。拡張するクラスはアクティブな構成であり、構成されたクラスは監査です。バージョンを持つことができる別のコンストラクターがあります。適切なメソッドをオーバーロードするだけで、目的の効果が得られます。

    import javax.sql.DataSource;
    import org.apache.commons.configuration.DatabaseConfiguration;

    public class MYConfig extends DatabaseConfiguration {
        final DatabaseConfiguration audit;

        public MYConfig(DataSource datasource) {
            super(datasource, "TABLE_CONFIG", "PROP_KEY", "PROP_VALUE");

            audit = new DatabaseConfiguration("TABLE_CONFIG_AUDIT", "PROP_KEY", "PROP_VALUE");
        }
        @Override
        public void addProperty(String key, Object value) {
            Object wasValue = super.getProperty(key);
            super.addProperty(key, value); 
            audit.put(key,wasValue);//add version code
        }
    }

http://commons.apache.org/proper/commons-configuration/

于 2013-07-10T12:24:01.283 に答える
0

興味深い代替構成ファイル形式:scalaトレイトを記述します。設定ファイルは、サーバーの起動時にコンパイルして評価するscalaファイルにすることができます。 http://robey.lag.net//2012/03/26/why-config.html

于 2012-03-27T12:37:10.310 に答える
0

単純なデータベース テーブル (セクション、キー、値) を使用します。必要に応じて「バージョン」を追加し、次のようなメソッドを使用して単純な ConfigurationService クラスに全体をラップしますgetInt(String section, String key)

それほど多くの作業は必要なく、アプリケーション コードが非常にきれいになり、構成の微調整が非常に簡単になります。

于 2011-11-17T09:52:41.530 に答える