記事ディレクトリ
輸入前
マルチ環境とは?実際、あなたのコンピュータで書かれたプログラムは、最終的に誰かのサーバーで実行されることを意味します。すべてのコンピューター環境は異なります。これがマルチ環境です。一般的なマルチ環境開発では、主に、自分が使用する開発環境、自社が使用するテスト環境、A さんの父親が使用する本番環境の 3 種類の環境設定が考慮されます。まったく違う3台のコンピュータなので、接続するデータベースが違う、設定されているアクセスポートが違うなど、環境が違うはずです。
マルチ環境開発(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
要約する
- マルチ環境開発では、開発環境、本番環境、テスト環境など、いくつかの一般的な環境を設定する必要があります
- 複数環境の使用を yaml 形式で設定する - 環境設定の境界を区別する
- 各環境の違いは、読み込まれる構成プロパティです。
- 環境を有効にする場合、起動時に使用する環境を指定する必要があります
マルチ環境開発(yamlマルチファイル版)
すべての構成を 1 つの構成ファイルに入れることは明らかに不合理です。特に構成アプリケーションのシナリオはそれぞれ異なるため、構成ファイルを複数の構成ファイルに分割するという考えがあります。分割後、各構成ファイルに独自の構成を記述し、メインの構成ファイルにどの構成ファイルを使用するかを明確に記述します。
メイン構成ファイル
spring:
profiles:
active: pro # 启动pro
環境構成ファイル
server:
port: 80
各環境設定ファイルは独自の項目を設定するため、名前も書く必要はありません。問題は、これがどの構成セットであるかをどのように区別するかです。ファイル名を使用して区別します。
アプリケーション-pro.yaml
server:
port: 80
アプリケーション-dev.yaml
server:
port: 81
なファイルの命名規則は、アプリケーション環境名.yml です。
上の図の application.yml がメインの構成ファイルで、その他は環境構成ファイルです。
構成ファイルでは、一部の構成項目がすべての環境で同じである場合、これらの項目はメイン構成に書き込むことができ、異なる項目のみが環境構成ファイルに書き込まれます。
- メイン構成ファイルにパブリック構成を設定します (グローバル)
- 環境分類構成ファイル (ローカル) で競合プロパティを設定するために一般的に使用されます。
要約する
-
環境プロパティは、スタンドアロン構成ファイルを使用して定義できます
-
独立した構成ファイルにより、オンラインでのシステムのメンテナンスと更新が容易になり、システムのセキュリティが確保されます
マルチ環境開発(プロパティマルチファイル版)
SpringBoot が提供する最も初期の構成ファイル形式はプロパティ形式であり、この形式でマルチ環境構成についても学ぶことができます。
メイン構成ファイル
spring.profiles.active=pro
環境構成ファイル
application-pro.properties
server.port=80
application-dev.properties
server.port=81
なファイルの命名規則は次のとおりです。 アプリケーション環境名.properties
要約する
properties文件多环境配置仅支持多文件格式
マルチ環境開発に依存しない構成ファイルの作成スキル
プログラマーとして構成に携わっていると、長時間結合し、長時間分割しなければならない状況に陥ることがよくあります。最初は一緒に書かれていましたが、メンテナンスの都合で分割されました。マルチ環境開発も同様ですが、マルチ環境開発をベースに独自の構成管理を行う方法をお伝えしますので、ぜひマスターしてください。
準備
すべての構成は機能ごとに分割され、構成ファイル内の情報は分割されて独立した構成ファイルに作成されます. 命名規則は次のとおりです.
- アプリケーション-devDB.yml
- アプリケーション-devRedis.yml
- アプリケーション-devMVC.yml
使用する
include 属性を使用して複数の環境を同時にロードし、指定した環境がアクティブ化されたときに有効にします。複数の環境はコンマで区切ります。
spring:
profiles:
active: dev
include: devDB,devRedis,devMVC
比較のために、dev 構成をロードしてから、対応する 3 セットの構成をロードするのと同じです。構造は非常に明確で、何が使用され、対応する名前は何ですか。
知らせ
メイン環境 dev が他の環境と同じ属性を持つ場合、メイン環境属性が有効になります; 他の環境が同じ属性を持つ場合、最後にロードされた環境属性が有効になります
向上
しかし、上記の設定にも問題があり、例えばdev環境をproに切り替えたい場合、includeも変更する必要があります。include 属性は 1 回しか使用できないため、これはさらに面倒です。バージョン 2.4 以降、SpringBoot は group 属性を使用して include 属性を置き換え、構成の書き込み量を削減します。簡単に言えば、あなたが使いたい方を最初に書きます。
spring:
profiles:
active: dev
group:
"dev": devDB,devRedis,devMVC
"pro": proDB,proRedis,proMVC
"test": testDB,testRedis,testMVC
では、見てみましょう。dev から pro に切り替える場合は、変更するだけで済みます。完全!
要約する
- マルチ環境開発では、グループ属性を使用して構成ファイル グループを設定します。これは、オンラインでの保守と管理に便利です。
マルチ環境開発管理
最後に、競合について話しましょう。つまり、maven と SpringBoot が複数の環境を同時にセットアップした場合はどうなるでしょうか。
この対立に対処するには、最初に関係を明確にする必要があります。つまり、マルチ環境開発の支配的なプレーヤーは誰なのかということです。つまり、両方の環境が設定されている場合、どちらを維持し、もう一方は同じ設定に従う必要があります。
メイヴンは何をしますか?プロジェクトのビルド管理、そして最終的にコード パッケージの生成、SpringBoot は何をしますか? 簡素化された開発。簡素化はその主役ではありません。最後に、プロジェクト全体を管理するには Maven が必要なので、SpringBoot は Maven をリッスンする必要があります。全体の確認後、以下を行います。一般的な考え方は次のとおりです。
- まず、maven 環境で使用する特定の環境を設定します
- 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@
上記の @property name@ は、maven で設定されたプロパティ値を読み取るための構文形式です。
要約する
- Maven と SpringBoot が同時に複数の環境を制御する場合、Maven がメインであり、SpringBoot は @…@ プレースホルダーを使用して、Maven に対応する構成プロパティ値を読み取ります。
- SpringBoot が Maven 構成プロパティを読み取るという前提に基づいて、Idea でプロジェクトをテストする場合、pom.xml の各更新を手動でコンパイルして有効にする必要があります (この問題は IDEA 21 および 22 バージョンで解決されています)。
ログのプリアンブル
ログとは、実際にはプログラムの日常的な動作を記録する情報であり、主な機能は次のとおりです。
- プログラミング中のコードのデバッグ
- 運用期間中の情報の記録
- 日常業務に関する重要な情報を記録します (ピーク トラフィック、平均応答時間など)。
- アプリケーション エラー情報を記録する (エラー スタック)
- 運用および保守プロセス データの記録 (拡張、ダウンタイム、アラームなど)
ロギング ツールを使用してコードにログを記録する
ログの使用形式は非常に固定されています。操作手順に直接進みます。
ステップ①:ロギング操作を追加する
@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 です。
結果:
デフォルトでは、システムの起動時のログ レベルは info レベルであるため、ここでは info とそのログ情報のみを表示できます。
ステップ②:ログ出力レベルの設定
ログを設定すると、設定に応じてどの参加記録をたどるかを選択できます。これは、ログのレベルに従って設定されます。次の 6 つのログ レベルがあります。
- TRACE: 実行中のスタック情報、使用率が低い
- DEBUG: プログラマーは以下を使用してコードをデバッグします
- 情報: 操作および保守プロセス データの記録
- 警告: 操作およびメンテナンス プロセスのアラーム データを記録します。
- ERROR: エラー スタック情報をログに記録します
- FATAL: 災害情報、ERROR に結合
一般的には、DEBUG は開発用、INFO はオンラインになってからの使用、WARN は運用保守情報記録用として使用されます。ログ レベルを次のように設定します。
# 开启debug模式,输出调试信息,常用于检查系统运行状况
debug: true
デバッグモードをオンにすると、プロジェクトを開始すると大量のテキストが表示されます. 通常、このモードは、プロジェクトが開始された後の検出でのみ使用されます.
この設定は単純すぎて失礼であり、ログ システムは通常、きめの細かい制御を提供します。
# 开启debug模式,输出调试信息,常用于检查系统运行状况
debug: true
# 设置日志级别,root表示根节点,即整体应用日志级别
logging:
level:
root: debug
デバッグ レベルに設定した後、再度実行すると表示されます。
より細かい制御を設定することもできます (たとえば、フレームワークでデバッグ ログを表示したくない場合など)。
ステップ 3 : 指定したパッケージに対応するログ出力レベルを制御するログ グループを設定するか、指定したパッケージに対応するログ出力レベルを直接制御します。
logging:
# 设置日志组
group:
# 自定义组名,设置当前组中所包含的包
ebank: com.nefu.controller,com.nefu.service
level:
root: warn
# 为对应组设置日志级别
ebank: debug
# 为对包设置日志级别
com.nefu.controller: debug
ぶっちゃけ、全体の設定をしてから、パッケージごとに設定するということなので、設定が面倒だと感じたら、まずはパッケージをグループ分けして、グループごとに設定してください。
要約する
- ログは、開発のデバッグと運用および保守プロセスのメッセージを記録するために使用されます
- ログレベルには 6 つのタイプがあり、通常は DEBUG、INFO、WARN、ERROR の 4 つのタイプを使用できます。
- ログ表示レベルは、ロググループまたはコードパッケージの形で制御できます
ログ オブジェクト作成コードの最適化
コードを書くとき、各クラスはロギング オブジェクトを作成して作成する必要がありますが、これは、以前に使用した 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); //这一句可以不写了
}
ログ出力形式の制御
ログは記録されていますが、現在の記録形式は SpringBoot によって提供されているため、コントロールをカスタマイズする場合は、自分で設定する必要があります。まず、現在のログのレコード形式を分析します。
- PID: プロセス ID, 現在の操作が配置されているプロセスを示すために使用されます. 複数のサービスが同時にログを記録する場合、この値はプログラマーがプログラムをデバッグするのを支援するために使用できます.
- Class/Interface Name: 現在表示されている情報はSpringBootによって書き換えられた情報であり、名前が長い場合は簡略化されたパッケージ名を最初の文字として記述するか、直接削除することさえあります.
単一のログ メッセージの場合、日付、トリガーの場所、およびレコード情報がコア情報です。レベルはフィルタリングに使用され、PID とスレッド名は正確な分析に使用されます。この情報がわかれば、ログ形式を DIY できます。
シミュレートされた公式ログ テンプレートの記述形式:
logging:
pattern:
console: "%d %clr(%p) --- [%16t] %clr(%-40.40c){cyan} : %m %n"
ログファイル
ログ情報を見ると、レコードが制御されていることがわかります.次に、ログのダンプについて説明します。ログはコンソールに表示するだけではなく、後で保守および参照しやすいようにファイルに記録する必要があります。
日次記録、機密記録、アラーム後の記録など、ログ ファイルの使用方法はさまざまです。ここでは、主にログ ファイルの記録方法について説明します。
ログをファイルに記録する形式は非常にシンプルで、ログファイル名を設定するだけです。
logging:
file:
name: server.log
上記の形式を使用してログを記録できますが、複雑なオンライン状況に直面した場合、ファイル レコードでは運用および保守の要件を満たすことができません。通常、ログ ファイルは毎日記録されます。ログ ファイルのサイズ。ログ ファイルの一般的な構成方法を以下に示します。
logging:
logback:
rollingpolicy: #代表日志的滚动
max-file-size: 3KB #文件大小限度
file-name-pattern: server.%d{
yyyy-MM-dd}.%i.log #滚动日志的文件名怎么启
上記のフォーマットはログバックログ技術に基づいて、日次ログファイルのフォーマットを設定しており、容量が3KBに達した後、2番目のファイルに情報を転送する必要があります。ファイル命名規則の %d は日付を識別し、%i はログ ファイルを区別するために使用される増分変数です。.