JavaEE and Microservices †
要約 †
JavaEEの仕様の今までの流れをここでは説明している。マイクロサービス に対応できるJavaEEのコンポーネントと、マイクロサービスへの移行方法への３つのアプローチを紹介する。
詳細 †
JavaEE は、10 以下の個々の仕様で始まった。しかし、その後の更新と34回を含む、リリースを通じて、成長していった。
マイクロサービスベースのアーキテクチャ、JavaEE、その仕様を比べることは、異なる開発と開発モデルで、もともと設計された。
１つだけのモノリシックサーバの実行時、もしくは、たくさんの異なるアプリケーションがホストされたクラスタ は、標準でパッケージされている。このようなモデルは、マイクロサービスのゴールとは逆で、実行する。
ほとんどの Java EE APIsは、同期で、これらのリソースをスケーリングすることは、スレッドプールを通じて行われる。もちろん、これは、その限界を持っていて、調節されるために、すぐに変わる要件、過度の負荷の状況を調整されることを意味していない。
これらの要件があたえられて、JavaEE は、マイクロサービスベースのアーキテクチャを開発するためのベストチョイスではないようだ。
だが、JavaEEの最新のバージョンは、簡素化されたパッケージと、一緒にプラットフォームに対して、たくさんの開発の生産性 を追加した。
Javaのモジュール性と、ち上げたプラットフォームのJVMと、個々の実装と一緒にあるスキルのある開発者で、Java EEは、マイクロサービスの開発にとって、お手頃なソリューションとして、考えられている。
Matching the Real World †
このレポートを書いた時点で最新の利用できるJavaEE の仕様 は、JavaEE 7。
図4-1にあるように、34 個別の仕様が含まれている。
Java Connector アーキテクチャやBatch Processing API のように、マイクロサービスベースのアーキテクチャに、やっといくつかのアドバンテージを提案するためのたくさんのテクノロジーがあります。
JAX-RS 2.0 †
JAX-RSで非同期のリクエストを実行するためには、パラメータとして、JAX-RS リソースメソッドで、javax.ws.rs.container.AsncResponse? インターフェイスに参照を注入する。AsyncResponse? オブジェクトでresumeメソッド は、ここに記述されてあるようにビジネスロジックの実行が完了した後に、分かれたスレッドの中で呼び出される必要がある。
WebSocket? 1.0 †
WebSocket? API と一緒に、 非同期のメッセージを送るために、javax.websocket.Session インターフェイスで、getAsyncRemote? メソッドを使う。これは、javax.web.socket.RemoteEndpoint? で入れ子したインターフェイスのインスタンスである。
Concurrency utilities 1.0 †
ハイパフォーマンスのスレッドのユーティリティを提供するJavaEEのための並列のユーティリティと、そして、ローレベルの非同期処理にアクセスする標準的な方法を提供する。
Servlet 3.1 †
サーブレットの仕様も、非同期のリクエスト処理の利用を 許可する。実装する必要があるパーツは、スレッドプールである( ExecutorService? を使用する)、動作の実行可能なインスタンスAsyncContext?、非同期として完了処理のチェーンをマークするためのFilter である。
EnterpriseJavaBeans? ( EJB ) 3.2 †
JaavEE 6は、すでに、javax.ejb.Asynchronous アノテーションを導入した。これは、Stateless、Stateful、もしくは、Singleton EJB を付け、すべての含まれたメソッドを非同期にするか、メソッドレベルで使われる。@Asynchronous アノテーションで メソッドは、戻り値なし( fire and forget) か、非同期メソッド結果が追跡する必要があるなら java.util.concurrent.Futureのインスタンス を返すことができる。これは、Future.get() メソッドを呼び出すことができる。
The Missing Pieces †
信頼できるマイクロサービスアプリケーション全体を構築するために、今日、典型的なJavaEEサーバが提供すること以上に なにかを必要とする。
これらの欠けているピースは関連しており、あなたは、これらを個々に構築するため、もしくは、インフストラクチャを配布できるようにするため、の機会がある。これらのピースもまた、”NoOps?”と呼ばれ、外部のアーキテクチャである。
API Gateway/Management Solution †
このソリューションについて、更なる情報のためにチャプター3 の ページ18で“Microservices Best Practices”をみてみよう。API gateway / management は、いくつかのマイクロサービスのインフストラクチャの不可欠な部分である。
Service Registry †
複数のマイクロサービスは、アプリケーションを作るために構成される。そして、それぞれのマイクロサービスは、依存なくスケールすることができる。
サービスのエンドポイントは、デプロイされるまで知らないかもしれない。特に、PaaSでデプロイされるなら。サービス登録は、各マイクロサービスを、ローカル名を使ったレジストリと一緒にそれ自身に登録することを許可する。この名前は、物理的なURIと追加のメタ情報の 義務がある。
ローカル名を使用することで、シンプルレジストリクエリの後に、コンシューマはマイクロサービスを位置づけ、起動することができる。マイクロサービスがダウンしたなら、そのときにコンシューマは、連動して通知され、代わりのサービスを取得する。レジストリは、APIゲートウェイと一緒に親密に動作すべきである。
Apache ZooKeper?、Consult、etcd、JBosss APIMan のように、サービス登録と発見のために複数のツールがある。
Security †
典型的な複数層のサーバアーキテクチャで、サーバサイドweb層は、関連するデータや、Lightweight Directory Access Protocol (LDAP) サーバ、をよびだすことで、サーバでユーザを認証することを扱う。
HTTP セッションは、必須の認証とユーザの詳細を含めて作成される。セキュリティのコンテキストは、アプリケーションサーバ内の層の間で伝播され、ユーザの再認証を必要としない。
何度も何度も一つ毎のマイクロサービスのリクエストで高価なオペレーションが発生させたくないため、これは、マイクロサービスとは異なる。ユーザを認証し、関連する情報の下りを含んでいるトークンを伝播する中央のコンポーネントを持つことは、避けられないことである。Enterprise access management (EAM) システムは、エンタープライズの環境で、必要とされた機能をたいてい提供する。さらに、いくつかのAPI マネージメントソリューションもまた トップの管理エンジンで セキュリティ機能を含んでいる。そして、最後に少なくないが、JBoss KeyCloak?のような専用のアプリケーションはある。
Migration Approaches †
実践的にグリーンフィールド vs ブラウンフィールド の開発について チャプター3で議論をしてきて、既存のアプリケーションをマイクロサービスに移行するための３つのことなるアプローチがある。
Selective Improvements †
もっともリスクフリーなアプローチは、選択的な実装 を利用することである。最初の評価のあとに、既存のアプリケーションのどのパーツがマイクロサービスアーキテクチャのアドバンテージを利用できるか、正確に知る。これらのパーツを、１つもしくはそれ以上のサービスに掻き出し、オリジナルのアプリケーションに必要な接点を追加することで、複数のステップでマイクロサービスをスケールアウトすることができる。
・まず、同じアプリケーションサーバクラスタもしくはインスタンスで、分けてデプロイする
・次に、分けてインスタンスをスケールさせる
・そして最後に、新しいデプロイを使用し、”fatJAR” containerにスイッチすることによるアプローチをスケールさせていく。
このアプローチにはたくさんのアドバンテージがある。既存システムで考古学をしている間、理想の候補にしていくためのパーツについて、とても良い概要を受けるだろう。そしてここのサービスを１度に１つ移動させている間、チームは、新しい開発手法に適用し、ポジティブに技術スタックで最初の経験するための公平なチャンスがある。
The Strangler Pattern †
同じではないことを比較することは、 ２つの異なるシステムを並列に実行する２つ目のアプローチである。まず、マーティンファウラーによるStrangerApplication? として作る。リファクター/抜粋 の候補を完全に新しい技術スタックに移動する。そして、アプリケーションの既存パーツは、触れないようにしておく。ロードバランサー、もしくは、プロキシは、オリジナルのアプリケーションに到達するために必要なのがどのリクエストか、新しいパーツにはどれ進めるか を決める。いくつか同期の問題は２つのスタックの間にある。最も大事なことは、既存のアプリケーションは、マイクロサービスのデータベースを変更することは許可することはできない。
Big Bang: Refactor an Existing System †
とてもレアなケースで、既存のアプリケーションの全体のリファクタリングは、正しい方法でおこなわれるかもしれない。エンタープライズアプリケーションは、全体のリファクタリングの間、メンテナンスし続ける必要があるため、レアである。おまけに、2週間で完全に停止するための十分な時間がないだろう。- さらに月でさえ、アプリケーションのサイズによる - 新しいスタックでそれを組み立て直すために。これは、最も推奨しないアプローチである。なぜなら比べても失敗のハイリスクがもたらされるためである。
担当者のつぶやき †
みんなの突っ込み †
