8

マイクロサービスで見られるのは、分離されたコンポーネントであり、そのコンポーネントの親コンシューマーとネットワーク経由でプロトコルを介して通信します。

EJB 1.0 と非常によく似たパターンが見られます。

私の質問は、マイクロサービス アーキテクチャ パターンは EJB 1.0 と似ていますか?

4

2 に答える 2

6

元の EJB 仕様の背後にある考え方と、マイクロサービスで行われていることにはいくつかの類似点がありますが、多くの相違点があります。

EJB は、コンポーネントベースのアーキテクチャを構築する標準化された方法を提供し、トランザクション、状態、およびスレッド管理を抽象化しながら、Bean の製品が他のアーキテクチャによって消費されることを保証する契約を備えていました。コンポーネントを構築するという考え方は非常に似ています。最大の変更点は、それらを「サービス」と呼ぶようになったことです。受託開発の考え方も同様です。

高レベルの違いの一部を以下に示します。

  • EJB の仕様には次のように記載されています。これは、優れたマイクロサービスの実装とは対照的です。マイクロサービスの最適な設計は、単一の関心事を持つ境界のあるコンテキストです。

  • EJB 1.x アーキテクチャーでは、コンテナーは持続性プロバイダーです。一方、マイクロサービス アーキテクチャでは、各サービスが独自のデータと永続性を管理します。

  • マイクロサービス パターンを使用すると、スコープを最小限に抑え、トランザクションがマイクロサービスの境界を越えないようにすることで、トランザクション管理が簡素化されます。

  • マイクロサービスでは、スレッド プールはサービスごと、またはサービスのインスタンスごとです。スレッド プールが使い果たされた場合は、サービスの別のインスタンスを生成するのが理想的です。EJB 1.x 環境では、スレッド管理はコンテナーの責任です。

マイクロサービス アーキテクチャと EJB 1.x アーキテクチャの間には他にも多くの違いがありますが、これらはいくつかのハイライトです。私は両方のアーキテクチャの実装に取り​​組んできましたが、これまでのところ、マイクロサービス アーキテクチャのメンテナンス コストは低いようです。特に、EJB がモノリシック アーキテクチャ内で混乱していることを考えると。

于 2015-12-08T19:12:09.520 に答える