モノリスをマイクロサービスにリファクタリングすることについて話している lightbend によって作成されたウェビナーを見ていましたが、質問がありました。このフレームワークの主なターゲットはモノリスのリファクタリングであるようですが、lagom は独自のコンテナーと一連のテクノロジで実行されているようです。モノリスとレガシー Java アプリについて考えるとき、頭に浮かんだ主なテクノロジーは Java EE です。今日のプロダクションのほとんどのアプリケーションは、いくつかの Java EE テクノロジーに依存していると思います。私が働いているのは、主にEJBに基づいています。私の質問は、Lagom がこの問題をどのように解決するのかということです。この種のアプリケーションをリファクタリングするには、リモート EJB ルックアップをレスト コールに変換する必要があると思います。しかし、ラグムが Java EE コンテナーで実行されない場合、アプリケーションのローカル EJB をどのように保持すればよいでしょうか? 両方を使用することは可能ですか?
3 に答える
Lagom については詳しくありませんが、マイクロサービスに基づくアーキテクチャを使用している市場は、Spring Boot/Cloud に大きく依存しています。現在、私はマイクロサービスを使用して非常に大規模なプロジェクトに取り組んでおり、スプリング担当者は、マイクロサービスについて考えるときに念頭に置く必要がある各マイクロサービス パターンに対して多くのフレームワーク/ツールを提供しているようです。一方、Netflix (最大のマイクロサービス ユーザー) は Spring に依存しています。Spring Boot/Cloud は、Java EE モノリシック アプリをマイクロサービスにリファクタリングするための良い方法だと思います。
次のように、一連の REST Web サービスを使用して既存の EJB サービスを表すことから始めることができます。これは、次のように、新しい Lagom ベースのマイクロサービスによって消費されます。
[EJB サービス] <- [EJB ベースの REST サービス ゲートウェイ] <- [Lagom ベースのマイクロサービス]
または展開モジュールとして:
[EJB アプリ .EAR] <- [EJB-REST ゲートウェイ .WAR] <- [Lagom ベースのアプリ]
EJB アプリはコンテナー (Wildfly など) で実行されるため、Lagom アプリは個別に (おそらく別のホストに) デプロイされます。REST サービス層を導入すると、各モジュールを個別に開発できるようになります。これが、この場合の成功の鍵です。
次に、徐々に新しい機能を実装し、場合によっては、新しい Lagom ベースのアプリでレガシー機能の一部を再実装します。
これはまさに私がやったことであり、魅力のように機能します。