Eclipse MicroProfile とは

Eclipse MicroProfile は Eclipse Foundation により定められた、Java EE (Jakarta EE) の仕様をベースにした拡張プロファイルといったところでしょうか。
なので、 Java EE 仕様に含まれていない機能もこのプロファイルには含まれていますし、このプロファイルはJCPで定められたものでもありません。(JSRではない)

また、Java EE は EE4J によって、Eclipse Foundation に移管されたことで、 Jakarta EE と名前も変更となりました。
Jakarta EE では今後のバージョンで MicroProfile についても統合されていく可能性が濃厚なようです。

Eclipse MicroProfile 1.3 を構成する仕様

複数の仕様を束ねて、 MicroProfile となっており、その要素には Java EE の幾つかの仕様も含まれております。

From Java EE (Java EE に含まれる)

Spec	Version
CDI	1.2
JAX-RS	2.0.1
JSON-P	1.0

Eclipse MicroProfile Only (Java EE に含まれない)

Spec	Version
Config	1.2
Fault Tolerance	1.0
Health Check	1.0
JWT Authentication	1.0
Metrics	1.1
OpenAPI	1.0
OpenTracing	1.0
Rest Client	1.0

Eclipse MicroProfile 1.3 の各仕様の概要

Java EE にある仕様については、他にもまとめてくれてる方も多いので、ここには書きません。

Eclipse MicroProfile Config

Apache DeltaSpike Config の影響を受けて、MPにConfigの仕様として標準化したものっぽい。
その名の通り、設定(Config)についてだが、設定情報(ソース)の定義やそれをDIする方法などを標準化したもの。
DeltaSpikeを使わない場合などは、JNDIを活用するなどして、いくらか自作する必要があった。

詳しくは、IBMのページが日本語でもよくまとまってました。(WebSphere関係のページですが、実装依存部分の内容は少ないと思うので、大変参考になりそう)
https://www.ibm.com/support/knowledgecenter/ja/SS7K4U_liberty/com.ibm.websphere.wlp.zseries.doc/ae/cwlp_microprofile_overview.html

Eclipse MicroProfile Fault Tolerance

障害許容性と回復性を実現するための機能群。
Fault Tolerance は直訳で "障害許容性", "障害耐性" で、マイクロサービス化されている場合にサービスが一つ障害を起こしていた場合に、他のサービスに波及することを防ぐための機構のことを指します。

MicroProfile の Fault Tolerance では、CDIのインターセプターとして機能提供されます。

@Timeout, @Retry, @Fallback, @CircuitBreaker, @Bulkhead, @Asynchronous のアノテーションがあり、これらを JAX-RSリソースのクラスやメソッドに付加することでそれらの機能が有効になります。

Timeout: サービスの呼び出しのタイムアウト時間が設定できます
Retry: サービスの呼び出しに失敗した場合に再実行する回数が設定できます
Fallback: サービスの呼び出しに失敗した場合に呼び出す代替処理のメソッドやハンドラークラスなどが設定できます
CircuitBreaker: サービスを切り離すための、呼び出しの失敗回数のしきい値等を設定することができます
Bulkhead: 同時に実行可能なサービスの呼び出し数が設定できます
Asynchronous: サービスの呼び出しと処理を別スレッドで非同期に実行させ、サービスはFutureを返すことができるようになります

Eclipse MicroProfile Health Check

サービスで利用可能な状態になってるかを確認するためのエンドポイント /health を提供する機能。
たとえば、コンテナ起動ができたとしても、アプリがデプロイされるまでには少しばかり時間がかかることがあります。
アプリのデプロイが完了していない状態の時にサービスが利用されては困るため、それをチェックするためのインターフェースを標準化し、どのアプリにおいても標準的な方法で確認できるようになりました。

詳しくは、IBMのページが日本語でもよくまとまってました。
https://www.ibm.com/support/knowledgecenter/ja/SS7K4U_liberty/com.ibm.websphere.wlp.zseries.doc/ae/twlp_microprofile_healthcheck.html

Eclipse MicroProfile JWT Authentication

REST API の利用において、認証のためのエンドポイントのインターフェースは千差万別でしたが、JWT(JSON Web Token)認証という標準的な認証/認可方式を JAX-RS Resource に対して容易に提供することができる仕様。

Eclipse MicroProfile Metrics

Health Check と同様に、こちらはメトリクスについて /metrics エンドポイントを提供する機能。
Javaは元々、JMXなどでメトリクスを得ることは出来たが、サービスが多言語で構成されている場合に、言語等のアプリケーションプラットフォーム毎にメトリクスの収集を考え、実装する必要がでてきてしまう。これを解決するためにRESTAPIのエンドポイントにてメトリクスを得る方法として標準化したもの。
エンドポイントから得られるメトリクスのフォーマットは、JSONの他、Prometheusフォーマットも提供することが仕様化されている。

詳しくは、IBMのページが日本語でもよくまとまってました。
https://www.ibm.com/support/knowledgecenter/ja/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/twlp_mp_metrics_monitor.html

Eclipse MicroProfile OpenAPI

OpenAPI Specification (OAS) はかつて、Swagger Specification だったもので、SmartBear社のプロダクトであるSwagger固有とされていたものが、OpenAPI Initiative (Linux Foundation の共同プロジェクト) なるところに寄贈され、パブリックな仕様となりました。
OpenAPIの仕様に沿った YAML または JSON があれば、REST API のドキュメンテーションだけでなく、各言語の REST API の実装を生成したりもできます。

MicroProfile OpenAPI 1.0 では JAX-RS Resource を作ると、その仕様が YAML または JSON として自動で提供されるようになりました。
つまり、はじめはデザイン(ドキュメント)ファーストで OAS の YAML でAPIの仕様を決め、コードに落ちた後に仕様の変更をしたとしてもそれがダイレクトにAPIドキュメントに反映できるので、仕様の書き直しをすることがなくなります。

Eclipse MicroProfile OpenTracing

OpenTracing は本来、分散トレーシングのためにCNCFにて標準化された仕様のことで、サービスの依存関係や各サービスのレイテンシなどのトレーシングなどができるようにするための機構。
仕組みとしては分散トレーシングのためのコンテキストをリクエストヘッダを用いてサービス間で引き回し、その情報をZipkinやJaegerなどのトレーサーにストアして依存関係やレイテンシなどを可視化・分析したりできるようになります。
そのためのOpenTracing用のコンテキストを引き回す機構をアプリケーション開発者がコーディングすることなくアプリに実装することができるようになる仕組みです。

Eclipse MicroProfile Rest Client

JAX-RSリソースが定義されたInterfaceを元にそのクライアントを容易に作ることができ、そのInterfaceに定義されたメソッドを呼び出すかのようにJAX-RSリソースを呼び出すことができる機構を提供するものです。

公式ページのサンプルコードを読めばすぐに理解できると思います。

参考情報

Eclipse MicroProfile 公式ページ

Eclipse MicroProfile まとめ (1.3対応版)