MicroProfile によるマイクロサービス開発

Eclipse MicroProfile は、Enterprise Java™環境でマイクロサービス・アプリケーションを開発するためのプログラミング・モデルを定義している。これは、エンタープライズJavaコミュニティにマイクロサービスをもたらすための、 Eclipse Foundation傘下のオープンソースプロジェクトである。 MicroProfile は Liberty でサポートされます。

MicroProfile では、弾力性がありセキュアで、モニターが容易なマイクロサービスを作成するための多数の仕様が定義されます。詳しくは、 MicroProfile リバティの機能をご覧ください。

制約事項

CDI は MicroProfile API で幅広く使用されていますが、Liberty では、エンタープライズ・バンドル・アーカイブ (EBA) にパッケージ化された OSGi Web アプリケーションでの CDI はサポートされません。代わりに、MicroProfile を使用するアプリケーションを Web アプリケーション・アーカイブ (WAR) またはエンタープライズ・アプリケーション・アーカイブ (EAR) にパッケージ化します。
MicroProfile フォールト・トレランスは、他のサービスにかけられるコールを管理するように設計されている。 1.0 トランザクション・コンテキスト内のリソースに対する更新を管理するようには設計されていません。 CICS® @Bulkhead,,,, とアノテーションされたメソッドでは、リソースを更新してはならない。 @CircuitBreaker @Fallback @Timeout @Retry CICS JTAが使用されている場合でも、例外が発生した場合にこれらの更新が回復されることを保証することはできない。
Liberty JVMサーバーのserver.xmlでmpJwt-1.0機能が有効になっている場合、すべての認証はJWTベアラートークンを使用して行われなければなりません。他の形式の認証を使用するには、別個の Liberty JVM サーバーを使用する必要があります。

CICS Liberty JVM サーバーにおけるサービス・アーキテクチャ

モノリシック・アーキテクチャー

モノリシック・アーキテクチャーでは、単一の単位でアプリケーションを実装します。内部的にはロジックをモジュール形式にすることができますが、外部的には、アプリケーションは全体的に使用可能であるか、まったく使用不可であるかのいずれかになります。モノリスはマイクロサービスと比較して良好に機能し、セキュリティーおよびトランザクション・コンテキストを管理する場合、それほど複雑ではありません。モノリスのスケーリングでは、アプリケーション全体のインスタンスを追加する必要があり、各パーツを個別にスケーリングすることはできません。

バッキング・サービス

バッキング・サービスを使用すると、バックエンド・データおよびプログラムをメイン・アプリケーションから分離できます。データとプログラムを別々のアプリケーションにすることで、プラットフォームに依存しない通信方法（例えば HTTP、ソケット、メッセージキューなど）で呼び出されます。メイン・アプリケーションがこれらのソースと通信するためのすべてのロジックを保持する代わりに、いくつかの責任がこれらのサービスに与えられる。

CICS では、z/OS® Connect を使用して、CICS プログラムを REST API を介してバッキング・サービスとして公開します。この例では、アプリケーションは JDBC を使用してデータベースと通信します。 E メールの送信には SMTP が使用され、z/OS Connect を介した CICS プログラムの呼び出しには HTTP が使用されます。

バックアップ・サービスは、アプリケーションとアプリケーション・リソースの分離を可能にする。すべてのアプリケーション・ロジックを単一のユニットに格納するのではなく、サービスを公開することで、内部および外部のサービスに簡単にアクセスできるようになります — 図2：バッキング・サービス

ホスト・サービス

サービスは、メイン・アプリケーションをさまざまなコンポーネントからさらに分離するために、CICS でホストされます。バッキング・サービスと同様に、より多くの機能が CICS で CICS Web サービスを通して、または CICS Liberty でサーブレット、JAX-RS、JAX-WS などのテクノロジーを使用してアプリケーションと共に公開されます。

JAX-RSは、RESTfulなWebサービスを作成するための一般的な技術であり、JAX-WSは、リモート・プロシージャ・コール（RPC）指向のWebサービスを作成するために使用される。

ホストされたサービスは、アプリケーションの複数の部分を中央コアに持ち、それぞれの呼び出し可能なサービスによって制御される。 — 図3：ホスト・サービス

注意: RESTもRPCも、マイクロサービスにおける通信のための同じように有効なオプションです。 REST はリソース管理に重点を置いています。 RPC はアクションに重点を置いています。マイクロサービス・アーキテクチャは、RESTやRPC、その他のテクノロジーを強制するものではない。

マイクロサービス

完全なマイクロサービス・アーキテクチャーは、分離されたサービスが相互接続された Web であり、単一の中心点はありませんが、専用のエントリー・ポイントは存在する場合があります。サービスは、必要に応じて相互に通信できます。マイクロサービスのスケーリングには、スケーリングが必要な部分のインスタンスを追加することが含まれる。マイクロサービスは、モノリスよりも障害に対して弾力性があります。

CICS におけるサービスのスケーリング

CICS では、領域のトポロジーおよびセットアップに応じて、サービスを複数の方法でスケーリングできます。通常、マイクロサービスは単一のコンテナーに分離されます。 CICS では、サービスまたはサービスのセットは、領域または JVM サーバー内で分離できます。スケーリングを行うには、同じサービスまたはサービスのセットをホストする複数の CICS 領域を実行します。また、スレッド数を増加させて JVM サーバーをスケーリングすることもできます。

マイクロサービスの保護

可能な場合、マイクロサービスではパブリック・ネットワークをオフにしておく必要があります。 API ゲートウェイを使用して、マイクロサービスへのアクセスを制御できます。 MicroProfile では、マイクロサービス・エンドポイントの役割ベースのアクセス制御 (RBAC) に Open ID Connect (OIDC) ベースの JSON Web Token (JWT) を使用するための方式を提供します。セキュリティー・トークンにより、さまざまなサービスにわたるユーザー ID の単純で相互運用可能な伝搬が可能となります。

MicroProfile JWT Authentication 1.0 では、JWT ベアラー・トークンに基づいてユーザーを認証および許可する機能を提供します。トークンをサービス・コードに注入して、ID をマイクロサービス・ネットワーク全体に伝搬するために使用できます。 JWT の伝搬は、アウトバウンド要求の許可 HTTP ヘッダーにベアラー・トークンとして JWT を組み込むことにより、手動で行うことができます。あるいは、例えばauthnTokenが設定されたserver.xmlの中にwebTarget要素を設定することで、リバティはJWTを自動的に伝播させることができます：

<webTarget uri="http://microservice.example.ibm.com/protected/*" authnToken="mpjwt" />

Important: JWT ID はユーザー・レジストリには自動的にマッピングされず、CICS タスク・ユーザー ID には伝搬されません。 IDマッピングを有効にするには、server.xml内の<mpJwt>要素にmapToUserRegistry=”true”設定属性を追加します。

Libertyにおける MicroProfile JWT認証の設定についての詳細は、.

マイクロサービスでのデータ整合性

マイクロサービスで分散トランザクションを使用することは容易ではありません。その代わりに、サガパターンのような、サービスが更新された後にイベントがパブリッシュされるような代替トランザクション戦略が使用される。例えば、サービスAとサービスBに両方起きるべき更新がある場合、次のような順序になる：

A の更新が保留状態になります。
A から B へメッセージが送信されます。
B の更新が完了状態になります。
B から A へメッセージが送信されます。
A の更新が完了状態になります。

マイクロサービスを使用する場合

マイクロサービスを適用するのに最適なシチュエーションは、アプリケーションをより小さな分離されたサービスに分解可能な場合です。マイクロサービスは、制御されたスケーリング、独立したデプロイメント、より自律的な開発を可能にする。マイクロサービスのアーキテクチャは、特にデプロイとデータの一貫性において、余分な複雑さを生み出す可能性がある。 HTTPなどのプロトコルを介した通信は、メモリ呼び出しと比較して、より高いパフォーマンスコストを伴います。コンポーネントを個別にスケーリングできるようにすることで、コンポーネントの障害に対する弾力性が向上します。マイクロサービス・アーキテクチャーを管理する際には、正常でないサービスの診断を支援するためにモニター・ソリューションがさらに重要となります。