SpringBootの運用・保守実践記事、パッケージング、運用、高度な設定、マルチ環境開発、ログ

プログラミング 2023-09-06 08:13:55 訪問数: null

記事ディレクトリ

SpringBootの運用・保守に関する実践記事

基本章のリリース後、インターネット上で友人からの多くのコメントを目にし、100 人以上の友人が遭遇したいくつかの問題を解決するのを手伝いましたが、いくつかの問題は典型的なものであることがわかりました。次の章の適切な場所にこのコース セットに追加し、ソリューションとして全員に提供します。

ここからは実践編の学習に入ります。実践的な章は、基本的な章の基礎に基づいており、SpringBoot の知識マップを補完します。たとえば、基礎の章では yaml の文法形式のみが説明されていますが、yaml ファイルを記述する実際の開発プロセスにはまだ多くの落とし穴があり、実践の章で学習する必要があります。

実践編は運用保守実践編と開発実践編の２部に分かれています。実際、分割の基準は私が策定したもので、その中に含まれる知識の一部はまだ比較的分散しているためです。2 段階に分割する目的は、類似した知識点をより適切に分類し、学習者が知識間の関係を見つけやすくすることです。これは役に立ちます。記憶の保存と知識の変換に使用され、一連の繰り返しの知識と強化演習の後、一時的な記憶は永続的な記憶に変換されます。コースを作成する際には、単に講義を終えることだけを目的とするのではなく、学習者の学習効果を追求することが、私が長年守り続けている指導の基本理念でもあります。

まずは運用・保守の実践編ですが、運用・保守の実践編では、構成をいじって、開発の実践編でさまざまな技術を統合するための準備をさせます。実践的な開発の章と比較して、実践的な運用と保守の章の内容はわずかに薄く、一部の知識モジュールは実践的な運用と保守の章と実践的な開発の章の両方でカバーされており、これらの内容は実践的な開発の章に配置されています。ナンセンスな話はやめて、運用と保守の実践的な記事に含まれる内容を見てみましょう。
1. SpringBoot プログラムのパッケージ化と実行
2. 高度な構成
3. マルチ環境開発
4. ログ

SpringBoot プログラムのパッケージ化と操作の学習の前半を始めましょう

YW-1. SpringBoot プログラムのパッケージ化と実行

開発や学習を始めたばかりの友人は、知識について間違った理解を持っている可能性があります。私たちは毎日 Idea の下でプログラムを書き、Idea の下で実行します。

画像-20211201091317258

しかし、実際の開発が完了すると、私たちのプロジェクトを自分のコンピュータで実行することは不可能になります。

画像-20211201091341645

今後作るプログラムは専用サーバー上で動作します 簡単に言うと、自分で作ったプログラムを独立して動作するコンピュータ上に置くことです このコンピュータは、あなたが開発して使用するコンピュータよりも、より専門的なものであり、あらゆる面でのセキュリティ レベルは、現在のコンピュータよりもはるかに高くなります。

画像-20211201091502040

次に、プログラムをこの専用コンピュータに配置する方法ですが、まずプログラムをファイルに整理してから、このファイルをこのサーバーに転送する必要があります。ここには 2 つのプロセスがあり、1 つはパッケージ化プロセス、もう 1 つは実行プロセスです。

親切なヒント

環境の適応性を確保するために、エンタープライズ プロジェクトは次のプロセスを採用してプロジェクトをリリースしますが、このプロセスについてはここでは説明しません。
1. 開発部門は、Git、SVN、およびその他のバージョン管理ツールを使用して、プロジェクトをバージョン サーバーにアップロードします。
2. サーバーは、バージョン管理ツールを使用して、プロジェクトをダウンロードします。
3. サーバーは、Maven ツールを使用してプロジェクトを再構築します。現在の実マシン環境
4. サービスを開始します

引き続き、パッケージ化と実行プロセスについてお話します。いわゆるパッケージングとは、プログラムを実行可能ファイルに変換することを指し、いわゆる実行とは、開発環境に依存せずにパッケージングによって生成されたファイルを指します。上記の 2 つの操作には、迅速に実行できる対応するコマンドがあります。

プログラムのパッケージ化

SpringBoot プログラムは Maven に基づいて作成されており、Maven はパッケージと呼ばれるパッケージ化命令を提供します。この操作は Idea 環境で実行できます。

mvn package

パッケージ化すると、プロジェクト名と同様の jar ファイルが生成されます。その名前は、モジュール名 + バージョン番号 + .jar で構成されます。

プログラムの実行中

パッケージをパッケージ化した後は、直接実行できます。プログラムパッケージが配置されているパスでコマンドを実行します。

java -jar 工程包名.jar

プログラムのパッケージ化命令を実行すると、プログラムは通常どおりに実行されます。これは、Idea でプログラムを実行する場合と変わりません。

注意事項：お使いのコンピュータにjavaのjdk環境がインストールされていない場合、プログラムの実行にはjavaの命令が使用されるため、上記の操作が正しく実行できません。

特別な注意: ウィザードを使用して SpringBoot プロジェクトを作成する場合、pom.xml ファイルに次の設定が存在します。この設定セクションを削除しないでください。削除しないと、パッケージ化後にプログラムが正常に実行されません。

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
    </plugins>
</build>

要約する

1. SpringBoot プロジェクトは、Java 環境に基づいて個別に jar ファイルを実行してサービスを開始できます
2. SpringBoot プロジェクトは、mvn コマンド パッケージを実行してパッケージ
化します 3. jar コマンドを実行します: java –jar プロジェクト名.jar

SpringBootプログラムのパッケージ化失敗の処理

一部の小規模パートナーでは、パッケージ化して実行した後に次のような問題が発生し、プログラムが正常に実行できなくなることがあります。

画像-20211201094223991

この問題を理解するには、.jar ファイルの動作メカニズムについて説明する必要があり、これを理解していれば、そのような問題を回避する方法がわかります。

Java 開発に携わると、通常、mysql のドライバー jar パッケージなど、多くの jar パッケージに触れることがあり、上記のプログラムをパッケージ化した後に得られるものも jar ファイルです。このとき、上記の java -jar コマンドを使用して mysql ドライバーの jar パッケージを実行すると、上記の実行不能現象が発生しますが、なぜ SpringBoot プロジェクトは実行できるのでしょうか。実は梱包方法が違うからなんです。

SpringBootプロジェクトのpom.xmlには以下のような設定があり、この設定によりパッケージ化されたパッケージが実行できるかどうかが決まります。

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
    </plugins>
</build>

この設定を有効にし、この設定をコメントアウトして 2 つのパッケージをそれぞれ実行し、パッケージ化された 2 つのパッケージの違いを観察します。明らかな特徴が 3 つあります。1. パッケージ化されたファイルのサイズが異なります。2. パッケージ化されたパッケージ
の
サイズ含まれる内容が異なる
3. パッケージングプログラム内の各ファイルの内容が異なる

最初の現象を見てください、ファイルサイズが異なります。構成を使用したパッケージ化によって生成されるパッケージ サイズは次のとおりです。

画像-20211201095610270

構成のあるパッケージのボリュームは、構成しないパッケージの 30 倍であることがわかります。その中には何が含まれているのでしょうか? こんなに違うものでしょうか？内部で何が違うのか見てみましょう。

画像-20211201101541267

画像-20211201101652868

内容は完全に異なっており、META-INF と呼ばれる 1 つのディレクトリだけが同じであることがわかりました。大容量プログラムパッケージのBOOT-INFディレクトリ配下のclassesディレクトリを開くと、小容量プログラムパッケージと内容が全く同じであることがわかります。

画像-20211201101805569

画像-20211201101652868

大きなプログラム パッケージには、小さなプログラム パッケージの内容以外にも他のものが含まれていることがわかります。何があるの？BOOT-INF ディレクトリに戻り、lib ディレクトリを開くと、多数の jar ファイルが表示されます。

画像-20211201102025791

これらの jar ファイルが、このプロジェクトを作成したときにインポートされた座標に対応するファイルであることを見つけるのは難しくありません。SpringBootプログラムは、自身でパッケージ化して生成したプログラムを独立して動作させるために、自身で開発した内容をプロジェクトにパッケージ化するだけでなく、使用する必要のあるjarパッケージも全てパッケージ化します。現在のプロジェクトの操作に使用されます。あなたはなぜこれをやっているのですか？ただ独立して実行できるようにするだけです。現在のプログラムは、パッケージ外部のリソースに依存せずに独立して実行できます。これは、大型パッケージの容量が小型パッケージの 30 倍である主な理由でもあります。

大きなプログラム パッケージの違いを見てみましょう。一番外側のディレクトリに org ディレクトリがあります。このディレクトリに入ります。ディレクトリ名は org\springframework\boot\loader です。その中に JarLauncher.class ファイルがあります。まず、このファイルを覚えてください。 。このディレクトリ名のセットをもう一度見てみると、明らかに Spring のディレクトリ名です。なぜ Spring フレームワークをこのパッケージにパッケージ化する必要があるのでしょうか? わからない。

2つのパッケージの一番外側のディレクトリに戻り、META-INFフォルダの下に同じ名前でサイズが異なるMANIFEST.MFというファイルがあることを確認し、ファイルを開いて内容の違いを比較してください。

小さいファイルの場合は MANIFEST.MF

Manifest-Version: 1.0
Implementation-Title: springboot_08_ssmp
Implementation-Version: 0.0.1-SNAPSHOT
Build-Jdk-Spec: 1.8
Created-By: Maven Jar Plugin 3.2.0

MANIFEST.MF (バルクファイル用)

Manifest-Version: 1.0
Spring-Boot-Classpath-Index: BOOT-INF/classpath.idx
Implementation-Title: springboot_08_ssmp
Implementation-Version: 0.0.1-SNAPSHOT
Spring-Boot-Layers-Index: BOOT-INF/layers.idx
Start-Class: com.itheima.SSMPApplication
Spring-Boot-Classes: BOOT-INF/classes/
Spring-Boot-Lib: BOOT-INF/lib/
Build-Jdk-Spec: 1.8
Spring-Boot-Version: 2.5.4
Created-By: Maven Jar Plugin 3.2.0
Main-Class: org.springframework.boot.loader.JarLauncher

明らかに、大きいファイルには小さいファイルよりも情報の行が数行多くあり、情報の最後の行は Main-Class: org.springframework.boot.loader.JarLauncherです。この文はどういう意味ですか? java -jar を使用してこのパッケージを実行すると、Main-Class 属性で構成されたクラスが実行されます。これは、先ほど見たファイルです。SpringBoot パッケージャーの Spring フレームワークが役立つことがわかりました。そして、この org.springframework.boot.loader.JarLauncherクラスは、Start-Class 属性に設定されたクラスを内部的に検索し、対応するクラスを実行します。このプロパティは、ブートストラップ クラス名に対応する現在の構成にも存在します。

1. SpringBoot プログラムが構成を追加すると、Spring フレームワークの一部の機能、元のプロジェクトのコンテンツ、元のプロジェクトが依存する jar パッケージを含む特別なパッケージが作成されます。
2.
まず MANIFEST.MF ファイルを読み取ります。 の Main-Class 属性は、java -jar コマンドの実行後に実行するクラスをマークするために使用されます。 3.
JarLauncher クラスが実行されると、Start-Class 属性が見つかります。これはスタートアップ クラスの名前です
4. スタートアップ クラスを実行すると、現在のプロジェクトのコンテンツが実行されます
5. 現在のプロジェクトを実行すると、依存する jar パッケージが使用され、lib ディレクトリから検索されます

SpringBoot パッケージは独立して実行するために、使用する必要のあるすべてのリソースをこのパッケージに追加するのに多大な労力を費やしたようです。このため、この jar パッケージは独立して実行できます。

前のエラー メッセージを見てください。

画像-20211201094223991

この構成はパッケージ化中に使用されなかったため、パッケージ化後に共通の jar パッケージが形成され、MANIFEST.MF ファイルには Main-Class に対応する属性がないため、ランタイムはメイン リスト属性が見つからないことを示すプロンプトを表示します。エラーの理由。

上記の内容を理解することはプログラム上あまり意味がありませんが、SpringBoot プロジェクトの自立動作の仕組みを理解するのには役立ちます。実際、プロセス全体の主な目的は、全員が分析できるようにすることです。今後、同様の問題に遭遇した場合は、より多くの質問とその理由を自問してください。そうすれば、おそらく独自に問題を解決できるでしょう。

要約する

spring-boot-maven-plugin プラグインは、現在のプログラムを独立して実行できるパッケージにパッケージ化するために使用されます。

コマンドライン起動時の一般的な問題と解決策

DOS 環境で SpringBoot プロジェクトを開始すると、ポート占有の問題が発生する場合があります。全員に一連のコマンドを提供します。深く勉強する必要はなく、バックアップを作成するだけで済みます。

# 查询端口
netstat -ano
# 查询指定端口
netstat -ano |findstr "端口号"
# 根据进程PID查询进程名称
tasklist |findstr "进程PID号"
# 根据PID杀死任务
taskkill /F /PID "进程PID号"
# 根据进程名称杀死任务
taskkill -f -t -im "进程名称"

実際には、プログラムのパッケージ化と実行には一連の設定とパラメーターがあります。これについては次のコンテンツで説明します。ここから始めて、プログラムをパッケージ化して実行する方法を学びましょう。

SpringBootプロジェクトのクイックスタート（Linux版）

実際、Linux システムで実行されるプログラムと Windows システムで実行されるプログラムには大きな違いはありません。コマンドは同じ一連のコマンドですが、Linux コマンドに慣れていない可能性があります。問題。たとえば、ファイアウォールを閉じる方法、IP アドレスを照会する方法、JDK をインストールする方法などです。これは、すべての人に普及させるための重要なコンテンツではありません。全体的なプロセスを理解するだけです。

YW-2. 高度な構成

構成の一部は基本編で説明していますが、基本編の構成は一般的に、構成の形式を誰もがマスターできるようにするものです。たとえば、設定ファイルの書き方や書き込まれたデータの読み方などはすべて文法レベルの基礎知識です。実践的な章では、構成の適用に焦点を当てます。次に、高度な構成関連コンテンツの最初の部分を学び始めます。なぜ最初の部分と言うかというと、対応する高度な構成知識がこの章で学習するためです。実践的な開発の章。

YW-2-1. 一時属性設定

パッケージがパッケージ化され、リリースの準備が整いました。ただし、プログラム パッケージが完成すると、内部の構成はすでに固定されています。たとえば、サーバーのポートは 8080 に構成されています。プロジェクトを開始したいときに、アプリケーションがサーバー上ですでに開始されており、ポート 8080 を占有していることが判明した場合、現時点では当惑することになります。パッケージ化されたプログラムを再度修正する必要がありますか? たとえば、パッケージプログラムの起動ポートを80に変更したいとします。

画像-20211206095113771

画像-20211206095524343

画像-20211206095101581

SpringBoot は柔軟な構成メソッドを提供しており、プロジェクト内の個々のプロパティを再構成する必要があることがわかった場合は、一時プロパティを使用して一部の構成をすばやく変更できます。方法も非常に簡単で、起動時に対応するパラメータを追加するだけです。

java –jar springboot.jar –-server.port=80

上記コマンドはSpringBootパッケージを起動するコマンドで、コマンド入力後にスペースを入れ、その後に「-」を2つ入力します。次に、対応するパラメータを属性名 = 属性値の形式で追加します。ここでの形式は yaml での記述形式ではないことに注意してください。属性に複数レベルの名前がある場合、それらを区切るためにドットが使用されます。これは、プロパティ ファイルの属性形式とまったく同じです。

変更する属性が複数あることがわかった場合は、上記の形式に従って引き続き記述し、スペースを使用して属性を区切ることができます。

java –jar springboot.jar –-server.port=80 --logging.level.root=debug

プロパティ読み込みの優先順位

これで、プログラム構成は 2 つの場所、最初の構成ファイルと 2 番目の一時属性によって制御されます。そして、一時属性の読み込み優先度が設定ファイルの読み込み優先度よりも高いことがわかりました。他に設定する方法はありますか? 実際にはあります、そしてかなりの数があります。公式ドキュメントの該当するコンテンツを開くと、設定読み込みの優先順位が表示されます。アドレスは次のとおりです: https://docs.spring.io/spring-boot/docs/current/reference/html/spring-boot-features.html#boot-features-external-config

画像-20211206100859236
実際には 14 個の構成位置があり、現在そのうちの 2 個を使用していることがわかります。第 3 条の構成データは構成ファイルの使用を指し、第 11 条のコマンド ライン引数は一時的なコマンド ライン パラメーターの使用を指します。これら 14 個の構成の順序は、SpringBoot が構成をロードする順序です。これは、コマンド ラインの一時プロパティが構成ファイルのロードよりも高い優先順位を持っていることを意味するため、このリストの先頭の優先順位は低くなります。となり、下側の優先度が高くなります。実際、これは暗記する必要はありません。1 つだけ覚えておいてください。最終的にどのような効果が欲しいかはわかっています。次数の高低に関係なく、開発時に必要な順序で設定する必要があります。この順序は、問題を理解できない場合に分析しやすくするためのものです。

たとえば、ここでは user.name 属性をロードします。その結果、思っていたのと違う結果になった場合は、自分の設定属性よりも優先度の高い他の属性が設定属性を上書きしているのではないかと考え、順番を見て一つ一つ確認していきます。属性をオーバーライドする可能性がある場所はどれですか。

コースのコメント欄で友達が基礎を学んでいるのを見てこの質問をしましたが、それはこのためでした。user.name 属性値は yaml で設定されており、システム属性に user.name という属性があり、両者が競合するため、読み出すと独自の設定値ではありません。システム プロパティの読み込み優先順位は上記のリストの 5 番で、3 番よりも高いため、SpringBoot は最終的にシステム構成プロパティ user.name を読み込みます。

要約する

1. jar コマンドを使用して SpringBoot プロジェクトを開始する場合、一時プロパティを使用して構成ファイル内のプロパティを置き換えることができます。 2. 一時プロパティを追加します
: java –jar プロジェクト名.jar – プロパティ名=値
3. 複数の一時プロパティスペースで区切られています
。 4. 一時属性は、現在のブート プロジェクトでサポートされている属性である必要があります。それ以外の場合、設定は無効です。

開発環境で一時プロパティを使用する

現在一時的な使用が可能ですが、オンラインにするときにコマンド ラインから入力した一時属性が正しい必要があるため、開発環境でこれらの属性の構成値をテストする必要があります。開発環境で一時属性を使用する方法、つまり実際には Idea インターフェイスで操作する方法について説明します。

SpringBoot ブート クラスの実行インターフェイスを開き、その中の構成アイテムを見つけます。このうちプログラムの引数に相当する位置は一時的な属性を追加するもので、いくつか追加して効果を試すことができます。

画像-20211206101947622

Java プログラミングに精通している人は、main メソッドを実行するときに、main メソッドのパラメータ、つまり以下の args パラメータを使用したい場合は、それが上記の位置パラメータ。

public static void main(String[] args) {
     
     
}

これが事実であり、パラメータはこの args を通じて取得できることがわかります。ブート クラスがどのように記述されているかを見てみましょう

public static void main(String[] args) {
     
     
    SpringApplication.run(SSMPApplication.class,args);
}

この args パラメータは実際には run メソッドに渡されるのですが、Idea で設定した一時的なパラメータがこの場所を介してプログラムに渡されるようです。これは、この args がここで使用されない場合、一時属性の外部転送への入り口が切断されることを意味します。この場合、次の呼び出しメソッドを使用して、外部の一時プロパティが SpringBoot プログラムに入らないようにすることができます。

public static void main(String[] args) {
     
     
    SpringApplication.run(SSMPApplication.class);
}

または、次の形式を使用してこの操作を実行することもできます。つまり、構成は構成ファイルに書き込まれず、文字列配列として直接書き込まれ、プログラム エントリに渡されます。もちろん、このアプローチには実際的な開発上の意義はありません。

public static void main(String[] args) {
     
     
    String[] arg = new String[1];
    arg[0] = "--server.port=8082";
    SpringApplication.run(SSMPApplication.class, arg);
}

要約する

SpringBoot プログラムを起動するときに、コマンド ライン属性を使用して SpringBoot プログラムの起動プロパティを渡すかどうかを選択できます。

考える

一時プロパティを使用して、プロジェクトを開始する前に一時的に構成を変更できるようになりましたが、新たな問題が再び発生しました。一時属性は手軽なので使いやすいですが、あまり書きすぎると面倒になります。たとえば、オンラインにするときに一時属性で 20 個の値を設定する必要があるのですが、これは面倒ですが、もっとシンプルにして一元管理できないでしょうか? たとえば、ファイルを作成し、指定されたファイルをロードしますか? 本当にいいですね。どうやってするの？それについては次のセクションで説明しましょう。

YW-2-2. 設定ファイルの分類

SpringBoot は、プログラムを構成するための構成ファイルと一時プロパティを提供します。以前に一時属性について説明しましたが、このセクションでは構成ファイルについて説明します。実際、私たちはこの設定ファイルを使用していますが、SpringBoot が提供する 4 つのレベルの設定ファイルのいずれかを使用します。4 つのレベルは次のとおりです。
1. クラス パスの下の構成ファイル (これは私が使用してきたもの、つまりリソー​​ス ディレクトリ内の application.yml ファイルです)
2. クラス パスの下の config ディレクトリの下の構成ファイル
3 . パッケージが配置されているディレクトリ内の設定ファイル
4. パッケージが配置されているディレクトリの config ディレクトリの下にある設定ファイル

非常に複雑なので、一つずつ説明していきます。実は、上記4種類のファイルは、4種類の設定ファイルを記述するために用意されており、機能は同じで、いずれも設定用です。では、誰もが気になるのはその違い、そう、立場が違うからこそ違いが生まれるのです。一般的に、4 つの設定ファイルがすべて存在する場合、優先順位が問題になります。端的に言えば、4 つのファイルすべてがあり、それらの設定はすべて同じであり、誰が有効になるかという問題があります。上記4つのファイルの読み込み優先順位は、

1. ファイル：config/application.yml 【最高】
2. ファイル：application.yml
3. クラスパス：config/application.ym
4. クラスパス：application.yml 【最低】

では、なぜこれほど多様なデザインをするのでしょうか? 最も典型的なアプリケーションの 1 つについて話します。
1. シナリオ A: 開発者としてプログラムを作成するとき、独自のコード記述を容易にするために、構成されたデータベースを自分のマシンに接続する必要があります。レベル 4 である application.yml を使用します。以前に使用されました。
2. シナリオ B: プロジェクト開発が段階に達したので、共同デバッグとテストが必要です。接続されているデータベースはテスト サーバーのデータベースであり、一連の構成を変更する必要があります。以前のファイルの内容をすべて変更することもできますが、現時点では面倒ではありません。
3. シナリオ C: テスト後はすべて問題ありません。コードの作成を続けると、最初に作成した構成ファイルがテスト サーバーの内容に変更されていることがわかり、元に戻す必要があります。もう分かりましたか？シーン B では、すべてのコンテンツが変更されています。今すぐ元に戻す必要がありますが、将来はどうなるでしょうか? 変更しますか?

解決策は非常に簡単で、上記の 3 レベルの構成ファイルを使用し、別の構成を記述するだけでこの問題をすぐに解決できます。2つの設定ファイルが共存しているのは、configディレクトリの設定読み込みの優先順位が高いため、設定項目がレベル4の内容と同じ場合は上書きされてしまうのですが、これは非常に簡単でしょうか？

レベル 1 と 2 はどのような場合に使用されますか? このレベルは、プログラムの構成に何が書かれているかに関係なく、プログラムがパッケージ化された後に使用されます。私のレベルは高く、簡単にカバーできるので、これらの構成の矛盾を考慮する必要はありません。

要約する

1. 設定ファイルは 4 種類に分類されます1.1. プロジェクト クラス パス設定ファイル :
ローカルで開発およびテストする
開発者が1.4. プロジェクト パス config ディレクトリ内の設定ファイル : 全体的な制御を行います。運用保守管理者 2. 複数レベルの設定ファイル間の属性は、重ね合わせとカバレッジの形でプログラムに適用されます。


YW-2-3. カスタム設定ファイル

先ほど設定に使用した設定ファイルはapplication.ymlですが、実はこのファイル名も変更できるのでメンテナンスに便利です。たとえば、2020年4月1日にイベントを開催し、設定をそのまま残しましたが、2020年5月1日にイベントが中止となり、元の設定に戻しました。このとき、再度設定ファイルを変更するだけで済みます。 。ただし、元の構成ファイルを変更することはできません。変更しないと、アクティビティの完了後にアクティビティの構成が保持されず、メンテナンスに役立ちません。

設定ファイルをカスタマイズするには、次の 2 つの方法があります:
方法 1: 一時属性を使用して設定ファイル名を設定します (拡張子を除いた名前のみであることに注意してください)

画像-20211206105548238

方法 2: 一時属性を使用して構成ファイルのパス (絶対パス名) を設定します。

画像-20211206105716450

複数の設定ファイルをロードするように設定することもできます
画像-20211206105750285

使用されるプロパティの 1 つは spring.config.name で、もう 1 つは spring.config.location であり、これらは明確に区別する必要があります。

親切なヒント

現在、シングルサーバー版であるSpringBootシングルプロジェクトを検討中です。実際、エンタープライズ開発では現在、SpringCloud テクノロジーに基づいたマルチサーバー プロジェクトがより多く使用されています。この構成方法は、現在学習しているものとはまったく異なります。すべてのサーバーは独自の構成ファイルを設定するのではなく、構成センターを通じて構成を取得し、構成情報を動的にロードします。どうしてこれをやったの？集中管理。これらについてはここではこれ以上説明しません。これらのことについては後で説明します。

要約する

1. 構成ファイルの名前は、起動パラメーターを設定することで変更できます。
2. 構成ファイルのパスは、起動パラメーターを設定することによって変更できます。
3. 構成ファイルは、マイクロサービス開発中に構成センターを通じて設定できます。

YW-3. マルチ環境開発

話の内容はどんどんオンライン開発に近づいてきましたが、マルチ環境開発についてお話しましょう。

複数の環境とは何ですか? 実際、これは、あなたのコンピュータ上で書かれたプログラムが、最終的には他人のサーバーに置かれて実行されることを意味します。コンピューター環境はそれぞれ異なります。これはマルチ環境です。一般的なマルチ環境開発では、主に自分が使用する開発環境、会社が使用するテスト環境、Aさんの父親が使用する本番環境の3種類の環境設定が考慮されます。全く異なる３台のコンピュータなので、接続するデータベースや設定するアクセスポートなどの環境も異なるはずです。

ここに画像の説明を挿入

YW-3-1. マルチ環境開発（yaml単一ファイル版）

では、マルチ環境開発とは何でしょうか? 環境ごとに異なる構成プロパティを設定するだけです。たとえば、自分で開発する場合は、次のようにポートを構成します。

server:
  port: 80

2 つの環境セットをどのように設計しますか? 3 つのマイナス記号で区切られる

server:
  port: 80
---
server:
  port: 81

2 つの環境を区別するにはどうすればよいでしょうか? それに名前を付けます

spring:
	profiles: pro
server:
	port: 80
---
spring:
	profiles: dev
server:
	port: 81

どれを使えばいいのでしょうか？デフォルトでどれを開始するかを設定する

spring:
	profiles:
		active: pro		# 启动pro
---
spring:
	profiles: pro
server:
	port: 80
---
spring:
	profiles: dev
server:
	port: 81

非常に簡単なので、別の環境セットを追加しても問題ありません

spring:
	profiles:
		active: pro		# 启动pro
---
spring:
	profiles: pro
server:
	port: 80
---
spring:
	profiles: dev
server:
	port: 81
---
spring:
	profiles: test
server:
	port: 82

このうち、環境名定義の上記形式は古い形式であり、標準形式は以下のとおりです。

spring:
	config:
    	activate:
        	on-profile: pro

要約する

1. マルチ環境開発では、開発環境、本番環境、テスト環境など複数の共通環境を設定する必要がある
2. マルチ環境利用を yaml 形式で設定する – 環境設定の境界を区別する 3.
各環境の違い4.起動
時に使用するには、この環境を指定する必要があることを有効にします。

YW-3-2. マルチ環境開発（yamlマルチファイル版）

メイン設定ファイル

spring:
	profiles:
		active: pro		# 启动pro

環境設定ファイル

server:
	port: 80

環境設定ファイルはそれぞれ独自の項目を設定するため、環境設定ファイルに名前を記述する必要はありません。問題は、これがどの構成セットであるかをどのように区別するかです。区別するにはファイル名を使用します。

アプリケーション-pro.yaml

server:
	port: 80

アプリケーション開発.yaml

server:
	port: 81

ファイルの命名規則は、アプリケーション環境名.ymlです。

構成ファイルでは、一部の構成項目がすべての環境で同じである場合、これらの項目をメイン構成に書き込むことができ、異なる項目のみが環境構成ファイルに書き込まれます。
1. メイン構成ファイル (グローバル) でパブリック構成を設定します。
2. 環境分類構成ファイル (ローカル) で競合属性を設定するためによく使用されます。

要約する

1. 独立した構成ファイルを使用して環境プロパティを定義できます。
2. 独立した構成ファイルは、オンラインでのシステムの保守と更新に便利で、システムのセキュリティを確保します。

YW-3-3. マルチ環境開発（プロパティマルチファイル版）

SpringBoot が提供する最も初期の設定ファイル形式はプロパティ形式ですが、この形式でのマルチ環境構成についても理解しましょう。

メイン設定ファイル

spring.profiles.active=pro

環境設定ファイル
application-pro.properties

server.port=80

アプリケーション開発のプロパティ

server.port=81

ファイルの命名規則は「アプリケーション環境名.properties」となります。

要約する

プロパティファイルのマルチ環境構成はマルチファイル形式のみをサポートします

YW-3-4. マルチ環境開発に依存しない設定ファイル作成スキル

プログラマーとして構成に携わる場合、長期的な期間を結合し、長期的な期間を分割する必要がある状況に陥ることがよくあります。最初はまとめて書いてから、メンテナンスの便宜のために分割します。マルチ環境開発でも同様ですが、マルチ環境開発を前提とした構成非依存管理の方法を紹介しますので、ぜひマスターしてください。

準備

設定ファイル内のすべての設定情報を機能に応じて分割し、独立した設定ファイルとして作成します 命名規則は以下のとおりです 1.
application-devDB.yml
2. application-devRedis.yml
3. application-devMVC.yml

使用

include 属性を使用して指定した環境をアクティブ化する場合、複数の環境を同時にロードして有効にし、複数の環境を区切るにはカンマを使用します。

spring:
	profiles:
    	active: dev
        include: devDB,devRedis,devMVC

比較のために、開発構成をロードするときに、対応する 3 セットの構成をロードするのと同等になりました。構造は非常に明確で、何が使用され、対応する名前は何であるかがわかります。

知らせ

メイン環境 dev が他の環境と同じ属性を持つ場合、メイン環境属性が有効になり、他の環境が同じ属性を持つ場合、最後にロードされた環境属性が有効になります。

改良

ただし、上記の設定にも問題があり、例えば開発環境をproに切り替えたい場合には、インクルードも変更する必要があります。include 属性は一度しか使用できないため、さらに面倒です。バージョン 2.4 以降、SpringBoot は include 属性の代わりに group 属性を使用するため、構成の書き込み量が削減されます。簡単に言うと、先に書いておきますので、好きな方を使ってください。

spring:
	profiles:
    	active: dev
        group:
        	"dev": devDB,devRedis,devMVC
      		"pro": proDB,proRedis,proMVC
      		"test": testDB,testRedis,testMVC

今見るとdevからproにしたら変更するだけで終わりなんですか？完璧！

要約する

マルチ環境開発では、グループ属性を使用して構成ファイルのグループ化を設定するため、オンラインでの保守と管理に便利です

YW-3-5. マルチ環境開発制御

マルチ環境開発は基本的にここで終了し、最後に競合の問題です。Maven と SpringBoot が同時に複数の環境をセットアップした場合にどうするかです。

この競合の問題に対処するには、まず、複数環境の開発において誰が支配的な立場にあるのかという関係を整理する必要があります。つまり、現在複数の環境が設定されている場合、どれを維持し、もう一方も同じ設定に従う必要があります。

メイブンは何をするのですか? SpringBoot はプロジェクトの構築管理とコード パッケージの最終生成に何をしますか? 開発の簡素化。簡素化はその主役ではありません。最終的に、プロジェクト全体を管理するのは Maven に任されているため、SpringBoot は Maven の言うことを聞く必要があります。全体の確認が完了したら、次の作業は簡単です。一般的な考え方は次のとおりです。
1. 最初に Maven 環境で特定の環境をセットアップします
。 2. SpringBoot で Maven によって設定された環境を読み取るだけです。

Maven で複数の環境をセットアップする (属性を使用して環境を区別する)

<profiles>
    <profile>
        <id>env_dev</id>
        <properties>
            <profile.active>dev</profile.active>
        </properties>
        <activation>
            <activeByDefault>true</activeByDefault>		<!--默认启动环境-->
        </activation>
    </profile>
    <profile>
        <id>env_pro</id>
        <properties>
            <profile.active>pro</profile.active>
        </properties>
    </profile>
</profiles>

SpringBootでMaven設定値を読み取る

spring:
	profiles:
    	active: @profile.active@

上記の @プロパティ名@ は、Maven で設定されたプロパティ値を読み取るための文法形式です。

要約する

1. Maven と SpringBoot が同時に複数の環境を制御する場合、Mavn がメインとなり、SpringBoot は @…@ プレースホルダーを使用して Maven の対応する構成プロパティ値を読み取ります。 SpringBoot (
Idea でプロジェクトをテストする場合、pom.xml の各更新を手動でコンパイルして有効にする必要がある場合)

YW-4.ログ

運用保守の記事の最後はログについてお話します、ログについては皆さんよくご存知のことなので簡単に紹介しましょう。ログは実際にはプログラムの毎日の動作情報を記録するもので、その主な機能は次のとおりです。
1. プログラミング期間中のコードのデバッグ
2. 動作期間中の情報の記録
3. 日々の動作に関する重要な情報 (ピークトラフィック、平均応答) の記録4. アプリケーションエラー情報を記録 (エラースタック
)
5. 運用および保守プロセスデータを記録 (拡張、ダ​​ウンタイム、アラームなど)

もしかしたら皆さんはログの使用に慣れていないかもしれませんが、それは問題ではありません。もっとゆっくり使って、慣れてください。大きな工場に入りたいならこれが一番基本で、面接の時に「使ったことがない」「もう終わった」「チャンスがない」などとは言わないようにしましょう。

YW-4-1. ログツールを使用してコード内のログを記録する

ログの使用形式は非常に固定されているため、操作手順に直接進みます。

ステップ①

ロギングアクションの追加

@RestController
@RequestMapping("/books")
public class BookController extends BaseClass{
     
     
    private static final Logger log = LoggerFactory.getLogger(BookController.class);
    @GetMapping
    public String getById(){
     
     
        log.debug("debug...");
        log.info("info...");
        log.warn("warn...");
        log.error("error...");
        return "springboot is running...2";
    }
}

上記コードのlogオブジェクトはログを記録するためのオブジェクトであり、以下のlog.debugとlog.infoの操作がログを書き込むためのAPIです。

ステップ②

ログ出力レベルの設定

ログを設定したら、設定に従ってどのレコードに参加するかを選択できます。ここではログのレベルに応じて設定されます。ログには 6 つのレベルがあります。
1. TRACE: 実行中のスタック情報、低使用率
2. DEBUG: プログラマーによるコードの使用のデバッグ
3. INFO: 運用および保守プロセスのデータの記録
4. WARN: 運用および保守プロセスのアラーム データの記録
5. ERROR: エラースタック情報を記録します。
6. FATAL: ERROR にマージされた災害情報

通常、開発中は DEBUG を使用し、オンラインになった後は INFO を使用し、運用および保守情報の記録には WARN を使用します。ログレベルを設定する方法は次のとおりです。

# 开启debug模式，输出调试信息，常用于检查系统运行状况
debug: true

このような設定は単純すぎて失礼であり、通常はログ システムにより詳細な制御が提供されます。

# 开启debug模式，输出调试信息，常用于检查系统运行状况
debug: true

# 设置日志级别，root表示根节点，即整体应用日志级别
logging:
	level:
    	root: debug

より詳細な制御を設定することもできます

ステップ③

ロググループを設定して、指定したパッケージに対応するログ出力レベルを制御するか、指定したパッケージに対応するログ出力レベルを直接制御します

logging:
	# 设置日志组
    group:
    	# 自定义组名，设置当前组中所包含的包
        ebank: com.itheima.controller
    level:
    	root: warn
        # 为对应组设置日志级别
        ebank: debug
    	# 为对包设置日志级别
        com.itheima.controller: debug

端的に言えば、全体の設定と各パッケージの設定を行うことですが、設定が面倒に感じる場合は、まずパッケージをグループに分けて、グループごとに設定すれば大丈夫です。

要約する

1. ログは、開発、デバッグ、運用および保守プロセスのメッセージを記録するために使用されます
2. ログ レベルは 6 種類あり、通常は DEBUG、INFO、WARN、ERROR の 4 種類で十分です
3.ロググループまたはコードパッケージの形式 ログ表示レベル制御

トリックを教えてください

ログオブジェクト作成コードの最適化

コードを記述する場合、各クラスはログ オブジェクトを作成して作成する必要がありますが、これは、以前に使用されていた lombok テクノロジによって提供されるツール クラスを使用することで最適化できます。

@RestController
@RequestMapping("/books")
public class BookController extends BaseClass{
     
     
    private static final Logger log = LoggerFactory.getLogger(BookController.class);	//这一句可以不写了
}

lombok をインポートした後、アノテーションを使用してインポートを完了します。ログ オブジェクト名は log です。

@Slf4j		//这个注解替代了下面那一行
@RestController
@RequestMapping("/books")
public class BookController extends BaseClass{
     
     
    private static final Logger log = LoggerFactory.getLogger(BookController.class);	//这一句可以不写了
}

要約する

lombok が提供する @Slf4j アノテーションに基づいてログ オブジェクトをクラスにすばやく追加します

YW-4-2. ログ出力形式制御

ログはすでに記録されていますが、現在の記録形式は SpringBoot によって提供されており、コントロールをカスタマイズする場合は自分で設定する必要があります。まず、現在のログのレコード形式を分析します。

画像-20211206123431222

単一のログ メッセージの場合、日付、トリガーの場所、およびレコード情報が中心的な情報です。レベルはフィルタリングに使用され、PID とスレッド名は正確な分析に使用されます。この情報を理解したら、ログ形式を DIY できます。このコースでは詳細な調査は行わず、興味のある友人が関連知識を学ぶことができます。コース内で模擬した公式ログテンプレートの記述形式を誰でも学習できるように以下に示します。

logging:
	pattern:
    	console: "%d %clr(%p) --- [%16t] %clr(%-40.40c){cyan} : %m %n"

要約する

ログ出力のフォーマット規則

YW-4-3. ログファイル

ログ情報から記録が管理されていることがわかるので、ログのダンプについて説明します。ログはコンソールに表示するだけではなく、後のメンテナンスや参照のためにファイルに記録する必要があります。

ログ ファイルの使用方法には、毎日の記録、機密記録、警報後の記録など、さまざまな方法があります。ここでは主にログファイルがどのように記録されるかを学習します。

ファイルへのログの形式は非常に簡単で、ログ ファイル名を設定するだけです。

logging:
	file:
    	name: server.log

上記の形式でもログを記録できますが、複雑なオンライン状況に直面すると、ファイル記録では運用と保守の要件を確実に満たすことができず、通常、ログ ファイルは毎日記録されます。メンテナンスを容易にするために、それぞれのログ ファイルのサイズが異なります。ログ ファイルの一般的な構成方法を以下に示します。

logging:
	logback:
    	rollingpolicy:
        	max-file-size: 3KB
            file-name-pattern: server.%d{
     
     yyyy-MM-dd}.%i.log

上記の形式は、毎日のログ ファイル設定形式を設定するための logback ログ テクノロジに基づいており、容量が 3KB に達した後、情報を 2 番目のファイルにダンプする必要があります。ファイル命名規則の %d は日付を識別し、%i はログ ファイルを区別するために使用される増分変数です。

要約する

1. レコードをファイルにログ記録する
2. ログファイル形式の設定

運用・保守実践記事終了

実践的な運用と保守の記事はここで終わります。これで終わりとしましょう。というのも、運用・保守の章にはまだ知識が残っているのですが、説明が散漫すぎます。したがって、これらの知識を実践的な開発の知識と組み合わせることが、このコースの指導デザインの具体化でもあります。

全体の運用保守実践編では、SpringBootプログラムの実行方法、つまりプログラムのパッケージ化と操作を学び、次に構成のアップグレードと操作を学ぶという4つの内容を皆さんに学んでいただきました。は、構成ファイル内の設定に限定されなくなり、一時プロパティと外部構成ファイルを通じてプロジェクトの構成を制御します。マルチ環境開発では、さまざまなマルチ環境開発形式を紹介し、実際にそれをマスターできるほか、マルチ環境開発と Maven を使用した競合解決のスキルについても説明しました。最後に、ログ システムについて紹介しました。正直に言うと、ログに関する知識のほとんどはこのコースで学習する必要がないため、ここでのログは非常にいい加減です。ここでは、実際にログ システムを統合して使用する方法について説明します。 。

友人全員のコメントを読んだ後、あなたが今後も更新を促し続けることはわかりました。私も一生懸命取り組んでいます。一緒に頑張りましょう。実践的な開発の章でお会いしましょう。実践開発編は更新頻度を上げる予定です、全部終わってなかったら皆さんに更新します、まずは一部公開して、終わったら更新します。 、ここでやめましょう。

おすすめ

転載: blog.csdn.net/weixin_51157081/article/details/132550373
おすすめ
Arc Browser for Windows 1.0 が正式に提供開始
1990 年代生まれのプログラマーがビデオ移植ソフトウェアを開発し、1 年足らずで 700 万以上の利益を上げました。結末は非常に懲罰的でした。
ランキング
パフォーマンスプロファイラを実装する機能のようなCPPマクロ| C ++コードのパフォーマンステストを簡素化するためにマクロを使用する方法
クリック率を推定するための「特効薬」はありませんが、モデル構造よりも重要なことは何ですか？
Flink的重启策略（RestartStrategy）实战
Implementado en base a la tecnología de reconocimiento de huellas de voz Qualcomm SOC
Android custom encryption and decryption for playing audio and video (m3u8 independent encryption)
Oracleマルチテーブル結合クエリ、統計的合計、グループ化
MapReduceのワークフローと動作原理
ボタンを複数回押したときはどうすればサウンドのオーバーラップをすることができますか？
導出と理解SVM
Mac に Appium をインストールする
アーカイブ
もっと
2024-05-03(8)
2024-05-02(0)
2024-05-01(4)
2024-04-30(35)
2024-04-29(5)
2024-04-28(12)
2024-04-27(29)
2024-04-26(22)
2024-04-25(31)
2024-04-24(30)

コードワールド

© 2018 codetd.com