🥇microconfig.io を使用した簡単なマイクロサービス構成管理

マイクロサービスの開発とその後の運用における主な問題の XNUMX つは、インスタンスの有能かつ正確な構成です。私の意見では、新しいフレームワークがこれに役立つ可能性があります microconfig.io。これにより、いくつかの日常的なアプリケーション構成タスクを非常にエレガントに解決できます。

多数のマイクロサービスがあり、それぞれに独自の構成ファイルが付属している場合、そのうちの XNUMX つでエラーが発生する可能性が高く、適切なスキルとログシステムがなければエラーを検出するのは非常に困難です。フレームワーク自体が設定する主なタスクは、重複するインスタンス構成パラメーターを最小限に抑え、それによってエラーが追加される可能性を減らすことです。

例を見てみましょう。構成ファイルを備えた単純なアプリケーションがあるとします。 ヤムル。これは、任意の言語の任意のマイクロサービスにすることができます。このフレームワークをこのサービスにどのように適用できるかを見てみましょう。

ただし、利便性を高めるために、まず、microconfig.io プラグインをインストールした後、Idea IDE で空のプロジェクトを作成しましょう。

プラグインの起動設定をセットアップしました。上のスクリーンショットのように、デフォルトの設定を使用できます。

私たちのサービスは order と呼ばれるもので、新しいプロジェクトで同様の構造を作成します。

構成ファイルをサービス名のフォルダーに配置します。 アプリケーション.yaml。すべてのマイクロサービスは何らかの環境で起動されるため、サービス自体の構成を作成することに加えて、環境自体を記述する必要があります。このためにフォルダーを作成します。環境そして、作業環境の名前を付けたファイルをそれに追加します。したがって、フレームワークは環境内のサービスの構成ファイルを作成します。 devの, このパラメータはプラグイン設定で設定されているためです。

ファイル構造 開発者yaml それは非常に簡単です:

mainorder:
    components:
         - order

フレームワークは、グループ化された構成で動作します。私たちのサービスでは、グループの名前を選択してください メインオーダー。フレームワークは、環境ファイル内でそのようなアプリケーションの各グループを見つけて、それらすべての構成を作成し、対応するフォルダーで見つけます。

サービス設定ファイル自体注文ここではパラメータを XNUMX つだけ指定しましょう。

spring.application.name: order

次に、プラグインを実行しましょう。プラグインは、プロパティで指定されたパスに従って、サービスに必要な構成を生成します。

つことができますなんとかなるプラグインをインストールせずに、フレームワークのディストリビューションをダウンロードしてコマンドラインから実行するだけです。
このソリューションは、ビルドサーバーでの使用に適しています。

フレームワークが完全に理解していることは注目に値します。財産構文、つまり、一緒に使用できる通常のプロパティファイルです。 ヤムル 構成。

別のサービスを追加しましょう 支払い そして既存のものを複雑化します。
В 注文:

eureka:
 instance.preferIpAddress: true
 client:
   serviceUrl:
     defaultZone: http://192.89.89.111:6782/eureka/
server.port: 9999
spring.application.name: order
db.url: 192.168.0.100

В 支払い:

eureka:
 instance.preferIpAddress: true
 client:
   serviceUrl:
     defaultZone: http://192.89.89.111:6782/eureka/
server.port: 9998
spring.application.name: payments
db.url: 192.168.0.100

これらの構成の主な問題は、サービス設定に大量のコピー＆ペーストが存在することです。フレームワークがそれを取り除くのにどのように役立つかを見てみましょう。最も明白な点から始めましょう - 構成の存在 ユーレカ 各マイクロサービスの説明に記載されています。設定ファイルを含む新しいディレクトリを作成し、そこに新しい構成を追加しましょう。

それでは、各プロジェクトに行を追加しましょう #エウレカを含める.

フレームワークは自動的に eureka 設定を見つけてサービス設定ファイルにコピーしますが、環境ファイルで指定しないため、別個の eureka 設定は作成されません。 開発者yaml。 Сервис 注文:

#include eureka
server.port: 9999
spring.application.name: order
db.url: 192.168.0.100

インポート行を次のように変更することで、データベース設定を別の構成に移動することもできます。 #エウレカ、オラクルを含む.

フレームワークは構成ファイルを再生成するときに各変更を追跡し、それをメイン構成ファイルの隣の特別なファイルに配置することに注目してください。ログのエントリは次のようになります。「Stored 1 プロパティが次のように変更されます」 order/diff-application.yaml」これにより、大規模な構成ファイルへの変更を迅速に検出できます。

構成の共通部分を削除すると、多くの不要なコピー＆ペーストを取り除くことができますが、さまざまな環境に合わせて柔軟に構成を作成することはできません。当社のサービスのエンドポイントは固有であり、ハードコーディングされており、これは問題です。これを削除してみましょう。

良い解決策は、すべてのエンドポイントを他のユーザーが参照できる XNUMX つの構成に保持することです。この目的のために、プレースホルダーのサポートがフレームワークに導入されました。設定ファイルはこのように変更されます ユーレカ:

 client:
   serviceUrl:
     defaultZone: http://${endpoints@eurekaip}:6782/eureka/

次に、このプレースホルダーがどのように機能するかを見てみましょう。システムは、という名前のコンポーネントを見つけます。 エンドポイント そしてそこに意味を探す ユーレカイプ、それを設定に置き換えます。しかし、異なる環境ではどうなるでしょうか? これを行うには、次の場所に設定ファイルを作成します。 エンドポイント 次のタイプ application.dev.yaml。フレームワークは、ファイル拡張子に基づいて、この構成がどの環境に属するかを独自に決定し、それを読み込みます。

開発ファイルの内容:

eurekaip: 192.89.89.111
dbip: 192.168.0.100

サービスのポートに対して同じ構成を作成できます。

server.port: ${ports@order}.

すべての重要な設定が XNUMX か所にまとめられているため、構成ファイル内の散在するパラメーターによるエラーの可能性が軽減されます。

フレームワークには、既製のプレースホルダーが多数用意されています。たとえば、構成ファイルが配置されているディレクトリの名前を取得して、それを割り当てることができます。

#include eureka, oracle
server.port: ${ports@order}
spring.application.name: ${this@name}

このおかげで、設定でアプリケーション名を追加で指定する必要がなく、同じ eureka などの共通モジュールに配置することもできます。

client:
   serviceUrl:
     defaultZone: http://${endpoints@eurekaip}:6782/eureka/
 spring.application.name: ${this@name}

設定ファイル注文 XNUMX 行に短縮されます。

#include eureka, oracle
server.port: ${ports@order}

親構成からの設定が必要ない場合は、構成内でそれを指定でき、生成中に適用されます。つまり、何らかの理由で注文サービスに一意の名前が必要な場合は、パラメーターをそのまま残します。 spring.application.name.

たとえば、別のファイルに保存されるカスタムログ設定をサービスに追加する必要があるとします。 ログバック.xml。別の設定グループを作成しましょう。

基本構成では、プレースホルダーを使用して、必要なロギング設定ファイルを配置する場所をフレームワークに指示します。 @ConfigDir:

microconfig.template.logback.fromFile: ${logback@configDir}/logback.xml

ファイル内 ログバック.xml 標準アペンダを設定します。これには、構成の生成中にフレームワークが変更するプレースホルダも含めることができます。次に例を示します。

<file>logs/${this@name}.log</file>

サービス構成にインポートを追加することによって ログバック、サービスごとに構成されたログを自動的に取得します。

#include eureka, oracle, logback
server.port: ${ports@order}

フレームワークで使用可能なすべてのプレースホルダーについて詳しく学びましょう。

${this@env} - 現在の環境の名前を返します。
${…@名前} — コンポーネントの名前を返します。
${…@configDir} — コンポーネントの config ディレクトリへのフルパスを返します。
${…@resultDir} — コンポーネントの宛先ディレクトリへのフルパスを返します (結果のファイルはこのディレクトリに配置されます)。
${this@configRoot} — 構成ストアのルートディレクトリへのフルパスを返します。

このシステムでは、Java へのパスなどの環境変数を取得することもできます。
${env@JAVA_HOME}
フレームワークはで書かれているので、どちらかです。 JAVA、呼び出しと同様のシステム変数を取得できます システム::getProperty 次のような構造を使用します。
${システム@os.name}
拡張言語のサポートについて言及する価値があります スプリングEL。次の式は構成に適用できます。

connection.timeoutInMs: #{5 * 60 * 1000}
datasource.maximum-pool-size: #{${this@datasource.minimum-pool-size} + 10}

また、次の式を使用して構成ファイルでローカル変数を使用できます。 #var:

#var feedRoot: ${system@user.home}/feed
folder:
 root: ${this@feedRoot}
 success: ${this@feedRoot}/archive
 error: ${this@feedRoot}/error

したがって、このフレームワークは、マイクロサービスを微調整して柔軟に構成するための非常に強力なツールです。このフレームワークは、設定のコピー＆ペーストを排除し、設定を統合し、その結果、起こり得るエラーを最小限に抑えながら、構成を簡単に組み合わせてさまざまな環境に合わせて変更できるという主なタスクを完全に実行します。

このフレームワークに興味がある場合は、公式ページにアクセスして完全な内容を確認することをお勧めします。ドキュメンテーション、またはソースを詳しく調べるここで.

出所： habr.com

microconfig.io を使用してマイクロサービス構成を簡単に管理