2

現在のアプリは単一の JVM で実行されます。

現在、アプリを個別の論理サービスに分割しており、各サービスは独自の JVM で実行されます。

分割は、システム全体に影響を与えることなく、単一のサービスを変更して展開できるようにするために行われています。これにより、システム全体の QA の必要性が減ります。必要なのは、変更されるサービスとの相互作用の QA だけです。

サービス間通信には、REST、MQ システム バス、およびデータベース ビューを組み合わせて使用​​します。

これについて私が気に入らない点:

  • REST は、XML との間でデータをマーシャリングする必要があることを意味します
  • DBビューはシステムを結合し、個別のサービスの概念全体を無効にします
  • MQ / システム バスが複雑になる
  • サービス間で必然的にコードの重複が発生する
  • n 個の JBoss サーバー構成をセットアップしました。n 個のデプロイ、n 個のセットアップ スクリプトなどを実行する必要があります。

アプリを単一の JVM で実行できるようにしながら (そして関連する利点を実現しながら)、モジュール式の開発と展開を可能にする内部アプリケーションを構築するためのより良い方法はありますか?

4

2 に答える 2

3

ここであなたが本当に何を求めているのか、私は少し混乱しています。アプリケーションをネットワーク全体で実行されるさまざまなサービスに分割する場合、データのマーシャリングはどこかで発生する必要があります。

そうは言っても、OSGiについては調べましたか？異なるバンドル(基本的には、インターフェースを定義する追加のメタデータを含む jar ファイル) を同じ OSGi サーバーにデプロイできます。すべてが同じ JVM 内で実行されるため、サーバーはこれらのバンドル間の通信を透過的に促進します。通常とは異なるバンドル。

OSGi サーバーは、実行時にバンドルのアンロードとアップグレードを許可し、 OSGi バンドルのライフサイクル状態が尊重されていれば、アプリケーションは正常に実行されます (機能が低下している場合) 。

于 2010-03-14T20:58:14.503 に答える
0

あなたのチームには手動の QA プロセスがあり、実際の問題は回帰テストを自動化して、新しいリリースを迅速かつ自信を持って展開できるようにすることです。コードを別々のサーバーに分割することは、その回避策です。

サーバーを再起動する場合は、コードを個別の jar ファイルにコンパイルし、新しい jar をドロップして再起動することでモジュールをデプロイする方法があります。これは主にコード ベースを構造化して、悪い依存関係が入り込まないようにし、jar 間の呼び出しが変更されないインターフェイスを介して行われるようにすることです。(または、代わりに、抽象クラスを使用して、デフォルトの実装で新しいメソッドを追加できるようにします。)ビルド システムは、個別にデプロイされたモジュールが共通のインターフェイスにのみ依存し、それ以外はすべてコンパイル エラーになるようにすることで役立ちます。ただし、コンパイラは、コンパイルしていない jar を交換するときに非互換性を検出するのに役立つわけではないことに注意してください。そのため、これが実際に適切な QA プロセスを回避するかどうかはわかりません。

JVM を再起動せずに新しいコードをデプロイする場合は、OSGI が標準的な方法です。（しかし、私がほとんど知らないもの。）

于 2010-03-14T21:45:07.247 に答える