4

以下のシナリオを管理するのに最適なアプローチを理解したいと思います。

たとえば、ほとんどが Java である 25 のアプリケーションがあり、さまざまなプラットフォーム jboss、websphere、および tomcat にデプロイされた Web ベースであるとします。各アプリケーションは 3 ～ 5 個のサービスを公開し、他のアプリケーションからのサービスも消費します。それらのほとんどは同期的であり、必要に応じてトリガーされます。以下のユースケースのいくつかは、

  1. 患者が入院すると、入院の詳細 (同期) に関心のある 4 ～ 5 つのシステムにメッセージが送信されます。
  2. 請求システムは、割引を計算するために別のシステムに詳細を送信します (同期)
  3. ID を渡して患者の詳細を取得します。(同期)

したがって、ダイアグラム全体を図で表現しようとすると、システムごとにハードコードされた非常に多くの静的な線のようになります。

問題点

  1. ユーザーが機能していないことを訴えるまで、各システムまたは Web サービスの正常性を確認する一般的な方法はありません。

  2. 追跡する Web サービスとエンドポイントが多すぎます。

  3. 差分アプリケーション サーバーとコンテナーにより、差分標準 JAX-wS、Jax-RS にわたって実装されます。

  4. 一部のメッセージは同じですが、詳細がわずかに異なります。したがって、再利用性が低下し、カスタム要件ごとに新しいサービスを考え出すことになります。

上記の問題に対処するには、どのようなソリューションが適していますか?

4

2 に答える 2

1

これは、大企業では困難で一般的な問題です。SOA を促進するために、エンタープライズ サービス バスを企業に統合することを考えてみてください。その後、エコシステム内の各システムにアダプターを実装できます。アダプタ インターフェイスは、厳密に管理され、文書化され、標準化されます。ただし、これを行うにはかなりのコストがかかります。

システムヘルスのチェックに関して。Nagiosなどのプラットフォームの使用を検討できます。特定のシステムが「稼働」しているかどうかを判断するために使用できる、無害な Web サービス (たとえば、基本的な読み取り) を特定する必要があります。Nagios はこれを定期的に呼び出すことができます。

于 2012-04-12T09:47:54.897 に答える
0

本格的な ESB である必要はありませんが、1 対 1 接続に頼らずにさまざまなエンドポイント タイプとさまざまなプロトコルを確実に管理するには、統合と仲介ポイントが必要です。

Fuse Mediation Hub ( Apache camelベース)を見ることができます。ここでも、さまざまなサービスから統合ロジックを外部化すると、柔軟性が向上します。たとえば、進化しているサービスに依存する各サービスを変更する必要なく、さまざまなサービスをあなたが言及した REST/JSON に移行できます (移行中は全体が機能し続けます)。

監視に関しては、多くのソース (アプリ サーバーのログ、JMX、SNMP) に接続し、イベントを関連付けることができるsplunkを検討することをお勧めします。無料版があります（1日最大500Mbのデータ用）

于 2012-04-13T13:29:46.477 に答える