SpringBoot --- Operação e Manutenção

1. Embalagem e operação

1.1. Empacotamento e execução do programa (versão do Windows)

A chamada embalagem refere-se à conversão do programa em um arquivo executável, e a chamada execução refere-se ao arquivo gerado pela embalagem sem depender do ambiente de desenvolvimento.

O programa SpringBoot é criado com base no Maven, e o Maven fornece instruções de empacotamento chamadas de pacotes. Esta operação pode ser realizada no ambiente Idea.

mvn package

​Após o empacotamento, será gerado um arquivo jar semelhante ao nome do projeto, cujo nome é composto pelo nome do módulo + número da versão + .jar.

java -jar 工程包名.jar

Programa em execução

Depois que o pacote é empacotado, ele pode ser executado diretamente. No caminho onde o pacote do programa está localizado, execute o comando.

Atenção especial : Se o ambiente jdk do java não estiver instalado em seu computador, as operações acima não poderão ser executadas corretamente, pois a execução do programa utiliza instruções java.

​Atenção especial : Ao usar o assistente para criar um projeto SpringBoot, haverá a seguinte configuração no arquivo pom.xml: Esta seção de configuração não deve ser excluída, caso contrário, o programa não poderá ser executado normalmente após o empacotamento.

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

Resumir

1. O projeto SpringBoot pode executar o arquivo jar de forma independente com base no ambiente java para iniciar o serviço
2. O projeto SpringBoot executa o pacote de comandos mvn para empacotamento
3. Execute o comando jar: java –jar project name.jar

1.2, processamento de falha de empacotamento do programa SpringBoot

Alguns pequenos parceiros terão alguns problemas após o empacotamento e execução, o que fará com que o programa não seja executado normalmente, como o seguinte fenômeno

Se você quiser entender esse problema, precisa falar sobre o mecanismo de trabalho do arquivo .jar.Se você souber disso, saberá como evitar esses problemas.

​Ao fazer desenvolvimento em java, geralmente entramos em contato com muitos pacotes jar, como o pacote jar do driver mysql, e o que obtemos após empacotar o programa acima também é um arquivo jar. Neste momento, se você usar o comando java -jar acima para executar o pacote jar do driver mysql, o fenômeno não executável acima aparecerá, mas por que nosso projeto SpringBoot pode ser executado? Na verdade, é porque o método de embalagem é diferente.

​No pom.xml do projeto SpringBoot, existe o seguinte conjunto de configurações: Este conjunto de configurações determina se o pacote empacotado pode ser executado.

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

Habilitamos esta configuração e comentamos esta configuração para executar dois pacotes respectivamente, e então observamos a diferença entre os dois pacotes empacotados. Existem 3 características óbvias

• O tamanho do arquivo compactado é diferente
• O conteúdo da embalagem é diferente
• O conteúdo de arquivos individuais no empacotador é diferente

Olhe para o primeiro fenômeno, o tamanho do arquivo é diferente. O tamanho do pacote gerado pelo empacotamento com configuração é o seguinte:

Não é difícil ver que o volume do pacote com configuração é 30 vezes maior do que sem configuração, então o que há nele? Pode ser tão diferente? Vamos ver o que há de diferente por dentro.

Descobrimos que o conteúdo é completamente diferente, apenas um diretório é o mesmo, chamado META-INF. Abra o diretório classes sob o diretório BOOT-INF no pacote de programa de grande capacidade e descobrimos que o conteúdo é exatamente o mesmo do pacote de programa de pequena capacidade.

Acontece que o pacote de programa grande contém outras coisas além do conteúdo do pacote de programa pequeno. O que tem ali? Volte para o diretório BOOT-INF e abra o diretório lib, que mostra muitos arquivos jar.

Não é difícil descobrir que esses arquivos jar são os arquivos correspondentes às coordenadas importadas quando fizemos este projeto. Você provavelmente pode descobrir. Para fazer o programa que é empacotado e gerado por ele mesmo rodar de forma independente, o programa SpringBoot não apenas empacota o conteúdo desenvolvido por ele mesmo no projeto, mas também empacota todos os pacotes jar que precisam ser usados para a operação do projeto atual. Por que você faz isso? Só para poder correr de forma independente. O programa atual pode ser executado independentemente sem depender de nenhum recurso fora do pacote. Esta é também a principal razão pela qual a capacidade da embalagem grande é 30 vezes maior que a da embalagem pequena.

Vamos ver o que há de diferente no pacote de programa grande. O diretório externo contém um diretório org. Entre neste diretório. O nome do diretório é org\springframework\boot\loader. Você pode encontrar um arquivo JarLauncher.class nele. Primeiro, lembre-se deste arquivo . Olhando para este conjunto de nomes de diretório novamente, é obviamente um nome de diretório Spring. Por que o framework Spring deve ser empacotado neste pacote? Não tenho certeza.

​Volte aos diretórios mais externos dos dois pacotes e verifique se existe um arquivo chamado MANIFEST.MF na pasta META-INF com o mesmo nome, mas o tamanho é diferente. Abra o arquivo e compare a diferença de conteúdo

• MANIFEST.MF para arquivos pequenos

  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 para arquivos em massa

  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.test.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   jar启动器
  

Obviamente, há mais algumas linhas de informação no arquivo grande do que no arquivo pequeno, e a última linha de informação é Main-Class: org.springframework.boot.loader.JarLauncher . O que está frase significa? Se você usar java -jar para executar este pacote, será executada a classe configurada pelo atributo Main-Class, que por acaso é o arquivo que você viu anteriormente. Acontece que a estrutura Spring no empacotador SpringBoot está aqui para servir. E esta classe org.springframework.boot.loader.JarLauncher procura internamente a classe (SSMPApplication) configurada no atributo Start-Class e executa a classe correspondente. Essa propriedade também existe na configuração atual, correspondendo ao nome da nossa classe bootstrap.

​ Agora o papel deste grupo de configurações é claro

1. Após o programa SpringBoot adicionar configuração, um pacote especial será criado, incluindo algumas funções do framework Spring, conteúdo original do projeto e pacotes jar dos quais o projeto original depende
2. Primeiro, leia o atributo Main-Class no arquivo MANIFEST.MF para marcar a classe que é executada após a execução do comando java -jar
3. Quando a classe JarLauncher for executada, ela encontrará o atributo Start-Class, que é o nome da classe de inicialização
4. Ao executar a classe de inicialização, o conteúdo do projeto atual será executado
5. Ao executar o projeto atual, o pacote jar dependente será usado e pesquisado no diretório lib

​Parece que
o SpringBoot criou um pacote para poder rodar de forma independente, e todos os recursos que precisam ser usados ​​foram adicionados a este pacote. É por isso que este pacote jar pode ser executado de forma independente.

Vejamos novamente a mensagem de erro anterior: Como a configuração não foi usada durante o empacotamento, um pacote jar normal foi formado após o empacotamento e não há nenhum atributo correspondente a Main-Class no arquivo MANIFEST.MF, portanto, o tempo de execução solicita a localização O atributo da lista principal não é alcançado, por isso o erro é relatado.

Resumir

1. O plug-in spring-boot-maven-plugin é usado para empacotar o programa atual em um pacote que pode ser executado independentemente

1.3. Linha de comando iniciar problemas e soluções comuns

Ao iniciar o projeto SpringBoot no ambiente DOS, você pode encontrar o problema de ocupação de porta. Dê a todos um conjunto de comandos e guarde-os para uso posterior.

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

1.4. Programa em execução (versão Linux)

Na verdade, não há muita diferença entre o programa executado no sistema Linux e o programa executado no sistema Windows. Os comandos ainda são o mesmo conjunto de comandos, mas você pode não estar familiarizado com os comandos do Linux, o que levará a vários problemas. Por exemplo, como fechar o firewall, como consultar o endereço IP, como instalar o JDK e assim por diante.

passos :

• Baseado em Linux (CenterOS7)
• Instale o JDK e a versão não seja inferior à versão do JDK usada no empacotamento
• O pacote de instalação é salvo no diretório /usr/local/custom ou em $HOME
• Outras operações referem-se à versão do Windows

Resumir

1. O empacotamento do programa de inicialização depende do plug-in Maven correspondente ao SpringBoot para empacotar pacotes jar executáveis
2. Execute o pacote jar usando o comando jar
3. O processo de execução do programa de empacotamento de inicialização no Windows e no Linux é o mesmo, apenas é necessário garantir que o ambiente operacional seja válido

Dois, configurar avançado

2.1. Configuração de atributo temporário

Nosso pacote agora está embalado e pronto para lançamento. Mas depois que o pacote do programa é concluído, a configuração interna já está corrigida, por exemplo, a porta do servidor está configurada para 8080. Se eu quiser iniciar o projeto e descobrir que um aplicativo já foi iniciado no meu servidor e ocupa a porta 8080, será constrangedor neste momento. É necessário modificar o programa empacotado novamente? Por exemplo, desejo alterar a porta de inicialização do programa empacotado para 80.

SpringBoot fornece métodos de configuração flexíveis.Se você achar que propriedades individuais em seu projeto precisam ser reconfiguradas, você pode usar propriedades temporárias para modificar rapidamente algumas configurações. O método também é muito simples, basta adicionar os parâmetros correspondentes na inicialização.

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

O comando acima é o comando para iniciar o pacote SpringBoot. Depois que o comando for inserido, insira um espaço e, em seguida, insira dois sinais -. Em seguida, adicione os parâmetros correspondentes na forma de nome do atributo = valor do atributo. Lembre-se, o formato aqui não é o formato de escrita em yaml. Quando há nomes de vários níveis para atributos, pontos são usados ​​para separá-los, que é exatamente o mesmo que o formato de atributo no arquivo de propriedades.

​ Se você achar que há mais de um atributo a ser modificado, pode continuar a escrever de acordo com o formato acima e usar espaços para separar os atributos.

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

2.1.1. Prioridade de carregamento de atributos

Agora a configuração do nosso programa é controlada por dois locais, o primeiro arquivo de configuração e o segundo atributo temporário. E descobrimos que a prioridade de carregamento dos atributos temporários é maior do que a dos arquivos de configuração. Existe alguma outra forma de configurar? Na verdade, existem e são poucos. Abra o conteúdo correspondente no documento oficial e você poderá ver a ordem de prioridade da leitura da configuração. Endereço de referência: https://docs.spring.io/spring-boot/docs/current/reference/html/spring-boot-features.html#boot-features-external-config

Podemos ver que na verdade existem 14 posições de configuração e estamos usando 2 delas agora. Os dados de configuração do Artigo 3 referem-se ao uso de arquivos de configuração e os argumentos da linha de comando do Artigo 11 referem-se ao uso de parâmetros de linha de comando temporários. A ordem dessas 14 configurações é a ordem na qual o SpringBoot carrega a configuração. A implicação é que as propriedades temporárias da linha de comando têm uma prioridade mais alta do que o carregamento do arquivo de configuração, então a prioridade no topo desta lista é baixa , e a prioridade na parte inferior é alta. Apenas lembre-se de uma coisa, você sabe qual efeito deseja no final, não importa quão alto ou baixo seja o pedido

Por exemplo, agora você carrega um atributo user.name. Como resultado, você descobre que o resultado é diferente do que você pensou. Deve ser que outros atributos com prioridade mais alta que a sua tenham sobrescrito seus atributos de configuração. Então você pode olhar para o pedido e verificar um por um. Qual local tem o potencial de substituir seus atributos.

Resumir

1. Ao usar o comando jar para iniciar o projeto SpringBoot, você pode usar propriedades temporárias para substituir as propriedades no arquivo de configuração
2. Método de adição de atributo temporário: java –jar nome do projeto.jar –- nome do atributo=valor
3. Vários atributos temporários são separados por espaços
4. O atributo temporário deve ser um atributo suportado pelo projeto de inicialização atual, caso contrário, a configuração é inválida

2.1.2. Usar atributos temporários no ambiente de desenvolvimento

O uso temporário está disponível no momento, mas os atributos temporários inseridos através da linha de comando devem estar corretos ao entrar online, então devemos testar os valores de configuração desses atributos no ambiente de desenvolvimento. Vamos falar sobre como usar atributos temporários no ambiente de desenvolvimento, que na verdade é como operar na interface do Idea.

​Abra a interface de execução da classe de inicialização SpringBoot e encontre os itens de configuração nela. Entre eles, a posição correspondente aos argumentos do programa é adicionar atributos temporários, e você pode adicionar alguns para experimentar o efeito.

Fazer isso pode realmente gerar um pensamento. Quem está familiarizado com a programação em java deve saber que quando executamos o método main, se quisermos usar os parâmetros do método main, ou seja, o parâmetro args abaixo, ele é adicionado no parâmetro de posição acima.

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

Acontece que este é o caso, e os parâmetros podem ser obtidos através deste args. Vejamos como nossa classe de inicialização é escrita

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

Este parâmetro args é realmente passado para o método run.Parece que os parâmetros temporários configurados no Idea são passados ​​para o nosso programa através deste local. A implicação é que se este args não for usado aqui, a entrada para a transferência externa de atributos temporários será desconectada? Este é o caso, podemos usar o seguinte método de chamada, para que as propriedades temporárias externas não possam entrar no programa SpringBoot.

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

Ou você pode usar o seguinte formato para executar esta operação, ou seja, a configuração não é escrita no arquivo de configuração, mas diretamente escrita como um array de strings e passada para a entrada do programa. Claro, esta abordagem não tem significado prático de desenvolvimento.

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

Resumir

1. Ao iniciar o programa SpringBoot, você pode escolher se deseja usar o atributo de linha de comando para passar as propriedades de inicialização do programa SpringBoot

2.2. Classificação dos arquivos de configuração

O SpringBoot fornece arquivos de configuração e propriedades temporárias para configurar o programa. Já falei sobre atributos temporários antes, e esta seção falará sobre arquivos de configuração. Na verdade, temos usado esse arquivo de configuração, mas usamos um dos quatro níveis de arquivos de configuração fornecidos pelo SpringBoot. Os 4 níveis são:

• Arquivo de configuração no caminho da classe (é o que tenho usado, ou seja, o arquivo application.yml no diretório de recursos)
• Arquivos de configuração no diretório config sob o classpath
• Arquivos de configuração no diretório onde o pacote está localizado
• O arquivo de configuração no diretório config no diretório onde o pacote está localizado

Na verdade, os 4 tipos de arquivos acima são fornecidos para você escrever os 4 tipos de arquivos de configuração.As funções são as mesmas e são todas para configuração. De um modo geral, se existem todos os quatro arquivos de configuração, há uma questão de prioridade, para ser franco, tenho todos os quatro arquivos e todos eles têm a mesma configuração, e a questão de quem entra em vigor. A ordem de prioridade de carregamento dos 4 arquivos acima é

1. arquivo: config/application.yml [melhor]
2. arquivo ：aplicativo.yml
3. caminho de classe: config/application.yml
4. classpath: application.yml [mínimo]

efeito:

• Os níveis 1 e 2 são reservados para definir atributos gerais após o pacote do sistema, e o nível 1 é frequentemente usado pelo gerente de operação e manutenção para controlar o plano geral de implantação do projeto online

• Os níveis 3 e 4 são usados ​​para definir atributos comuns durante a fase de desenvolvimento do sistema, e o nível 3 é frequentemente usado por gerentes de projeto para controlar os atributos gerais do projeto.

Então, por que projetar tal variedade? Fale sobre uma das aplicações mais típicas.

• Cenário A: Como desenvolvedor, para facilitar a escrita do código ao fazer programas, o banco de dados configurado deve estar conectado à sua própria máquina.Usamos o nível 4, que é o application.yml que usamos antes.
• Cenário B: Agora que o projeto atingiu um estágio de desenvolvimento, é necessária a depuração e o teste conjunto.O banco de dados conectado é o banco de dados do servidor de teste, portanto, é necessário alterar um conjunto de configurações. Você pode optar por alterar todo o conteúdo do arquivo anterior e isso não é problemático no momento.
• Cenário C: O teste acabou e tudo está OK. Você continua a escrever seu código e descobre que o arquivo de configuração que escreveu originalmente foi alterado para o conteúdo do servidor de teste e precisa alterá-lo novamente. Você entende agora? Na cena B, todo o seu conteúdo foi alterado, você precisa alterá-lo agora, e no futuro? Você quer mudar isso?

​ A solução é muito simples. Você pode resolver rapidamente este problema usando o arquivo de configuração de 3 níveis acima e apenas escrever outra configuração. Dois arquivos de configuração coexistem, pois a prioridade de carregamento da configuração no diretório config é maior que a sua, então se o item de configuração for igual ao conteúdo do nível 4, ele será sobrescrito.É muito simples?

Quando os níveis 1 e 2 são usados? Este nível será utilizado após o programa ser empacotado, independente do que esteja escrito na configuração do seu programa? Meu nível é alto e posso cobrir você facilmente, então não preciso considerar esses conflitos de configuração.

Resumir

1. Existem 4 arquivos de configuração

   • Arquivo de configuração do caminho de classe do projeto: atendendo desenvolvedores para desenvolvimento e teste local
   • Arquivos de configuração no diretório config do caminho de classe do projeto: servem ao controle geral do gerente de projeto
   • Arquivo de configuração do caminho do projeto: Servindo o pessoal de operação e manutenção para configurar o ambiente online confidencial
   • Arquivos de configuração no diretório config do caminho do projeto: servem ao controle geral do gerente de operação e manutenção

2. As propriedades entre os arquivos de configuração de vários níveis atuam no programa na forma de sobreposição e sobreposição

2.3, arquivo de configuração personalizada

O arquivo de configuração que usamos para configuração antes é application.yml.Na verdade, o nome desse arquivo também pode ser alterado, o que é conveniente para manutenção. Por exemplo, realizei um evento em 1º de abril de 2020 e deixei um conjunto de configurações. O evento foi cancelado em 1º de maio de 2020 e a configuração original foi restaurada. Neste momento, só preciso alterar o arquivo de configuração novamente . Mas você não pode modificar o arquivo de configuração original, caso contrário, após a conclusão da atividade, a configuração da atividade não será mantida, o que não é propício para manutenção.

Existem três maneiras de personalizar o arquivo de configuração da seguinte maneira:

Método 1: Carregar o arquivo de configuração através dos parâmetros de inicialização (não é necessário escrever a extensão do arquivo de configuração)

Método 2: Carregar o arquivo de configuração no caminho de arquivo especificado por meio dos parâmetros de inicialização

Método 3: várias configurações podem ser carregadas ao carregar o arquivo de configuração no caminho de arquivo especificado por meio dos parâmetros de inicialização

importante

• Projetos de servidor único: menos necessidade de usar arquivos de configuração personalizados

• Projeto multi-servidor: a demanda pelo uso de arquivos de configuração personalizados é alta e todas as configurações são colocadas em um diretório para gerenciamento unificado

• Com base na tecnologia SpringCloud, todos os servidores não definirão mais arquivos de configuração, mas os definirão por meio do centro de configuração e carregarão dinamicamente as informações de configuração

Resumo dos perfis personalizados

1. O nome do arquivo de configuração pode ser modificado definindo os parâmetros de inicialização
2. O arquivo de configuração pode modificar o caminho definindo os parâmetros de inicialização
3. Os arquivos de configuração no desenvolvimento de microsserviços são definidos por meio do centro de configuração

Resumir

1. O SpringBoot suporta o uso de parâmetros temporários para modificar as configurações do projeto nos ambientes de desenvolvimento e execução
2. 
   O SpringBoot suporta arquivos de configuração de 4 níveis, que são aplicados a configurações flexíveis para configuração em ambientes de desenvolvimento e online
3. O SpringBoot suporta a modificação do local de armazenamento dos arquivos de configuração na forma de arquivos de configuração personalizados
4. Ao desenvolver com base em microsserviços, os arquivos de configuração serão gerenciados usando o centro de configuração

3. Desenvolvimento multiambiente

O que são ambientes múltiplos? Na verdade, isso significa que o programa escrito em seu computador acabará sendo colocado no servidor de outra pessoa para ser executado. Cada ambiente de computador é diferente, isso é multi-ambiente. O desenvolvimento multiambiente comum leva em consideração principalmente três tipos de configurações de ambiente, o ambiente de desenvolvimento - usado por si mesmo, o ambiente de teste - usado pela empresa e o ambiente de produção - usado pelo servidor de produção. Como são três computadores absolutamente diferentes, o ambiente deve ser diferente, como o banco de dados conectado, a porta de acesso definida e assim por diante.

3.1. Desenvolvimento em vários ambientes (versão de arquivo único YAML)

Então, o que é desenvolvimento multiambiente? Basta definir diferentes propriedades de configuração para diferentes ambientes. Por exemplo, quando você desenvolve sozinho, configure sua porta da seguinte maneira:

server:
  port: 80

​Como você gostaria de projetar dois conjuntos de ambientes? separados por três sinais de menos

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

Como distinguir os dois ambientes? diga

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

Qual devo usar? Definir qual iniciar por padrão

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

​ É simples assim, não há problema em adicionar outro conjunto de ambientes

spring:
	profiles:
		active: pro		# 启动指定环境
---
spring:
	profiles: pro      #设置生产环境
server:
	port: 80			#生产环境具体参数设定
---
spring:
	profiles: dev		#设置开发环境
server:
	port: 81			#开发环境具体参数设定
---
spring:
	profiles: test		#设置测试环境
server:
	port: 82			#测试环境具体参数设定

Entre eles, o formato acima da definição do nome do ambiente é um formato desatualizado e o formato padrão é o seguinte

spring:
	config:
    	activate:
        	on-profile: pro

Resumir

1. O desenvolvimento em vários ambientes requer a configuração de vários ambientes comuns, como desenvolvimento, produção e ambientes de teste
2. Configurando o uso de vários ambientes no formato yaml—diferenciando os limites de configuração do ambiente
3. A diferença entre cada ambiente é que as propriedades de configuração carregadas são diferentes
4. Ao habilitar um determinado ambiente, você precisa especificar o ambiente a ser usado na inicialização

3.2. Desenvolvimento de vários ambientes (versão de vários arquivos YAML)

Obviamente, não é razoável colocar todas as configurações em um arquivo de configuração, especialmente se cada cenário de aplicativo de configuração for diferente, então há uma ideia de dividir um arquivo de configuração em vários arquivos de configuração. Após a divisão, escreva sua própria configuração em cada arquivo de configuração e escreva claramente qual arquivo de configuração usar no arquivo de configuração principal.

arquivo de configuração principal

spring:
	profiles:
		active: pro		# 启动pro

Arquivo de configuração do ambiente

server:
	port: 80

Como cada um dos arquivos de configuração do ambiente configura seus próprios itens, não há necessidade de escrever o nome nele. A questão é como distinguir qual conjunto de configurações é esse? Use o nome do arquivo para distinguir.

application-pro.yaml

server:
	port: 80

application-dev.yaml

server:
	port: 81

As regras de nomenclatura de arquivo são: application-environment name.yml.

​ No arquivo de configuração, se alguns itens de configuração forem os mesmos em todos os ambientes, esses itens podem ser gravados na configuração principal e apenas os itens diferentes são gravados no arquivo de configuração do ambiente.

• Defina a configuração comum (global) no arquivo de configuração principal
• Comumente usado em arquivos de configuração de classificação de ambiente para definir atributos conflitantes (local)

Resumir

1. As propriedades do ambiente podem ser definidas usando um arquivo de configuração autônomo

2. Arquivos de configuração independentes facilitam a manutenção e atualizações online do sistema e garantem a segurança do sistema

3.3. Desenvolvimento multiambiente (versão Propriedades)

O formato de arquivo de configuração mais antigo fornecido pelo SpringBoot está no formato de propriedades. Vamos entender também a configuração de vários ambientes neste formato.

arquivo de configuração principal

spring.profiles.active=pro

Arquivo de configuração do ambiente

application-pro.properties

server.port=80

application-dev.properties

server.port=81

​ A regra de nomenclatura do arquivo é: application-environment name.properties.

Resumir

1. a configuração de vários ambientes do arquivo de propriedades suporta apenas o formato de vários arquivos

3.4, habilidades de escrita de arquivo de configuração independente de desenvolvimento multi-ambiente

Deixe-me dizer como fazer gerenciamento independente de configuração com base no desenvolvimento de vários ambientes

Preparação

​ Divida todas as informações de configuração no arquivo de configuração de acordo com a função e transforme-as em um arquivo de configuração independente. As regras de nomenclatura são as seguintes

• aplicativo-devDB.yml
• application-devRedis.yml
• aplicativo-devMVC.yml

usar

​ Ao usar o atributo include para ativar o ambiente especificado, carregue vários ambientes ao mesmo tempo para fazê-los entrar em vigor e use vírgulas para separar vários ambientes

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

​ Para comparação, agora é equivalente a carregar os 3 conjuntos de configurações correspondentes ao carregar a configuração dev. A estrutura é muito clara, o que é usado e qual é o nome correspondente

Perceber

​ Quando o ambiente principal dev tem os mesmos atributos dos outros ambientes, os atributos do ambiente principal entram em vigor; quando outros ambientes têm os mesmos atributos, os últimos atributos do ambiente carregado entram em vigor

melhoria

Mas também há um problema com as configurações acima, por exemplo, quando eu quero mudar o ambiente dev para pro, o include também deve ser modificado. Como o atributo include só pode ser usado uma vez, isso é mais problemático. A partir da versão 2.4, o SpringBoot usa o atributo group em vez do atributo include, o que reduz a quantidade de gravação de configuração. Para simplificar, vou escrever primeiro e usar o que você quiser.

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

Olhando agora, se você mudar dev para pro, você só precisa mudar!

Resumir

1. O desenvolvimento multiambiente usa o atributo group para definir o agrupamento de arquivos de configuração, o que é conveniente para manutenção e gerenciamento online

3.5. Controle de desenvolvimento multiambiente

Agora vamos falar sobre um problema de conflito. É o que fazer se o maven e o SpringBoot configurarem vários ambientes ao mesmo tempo.

​ Para lidar com esse problema de conflito, devemos primeiro resolver um relacionamento, quem é o ator dominante no desenvolvimento multiambiente. Ou seja, se vários ambientes forem configurados agora, qual deles deve ser mantido e o outro deve seguir a mesma configuração.

O que o maven faz? O que o SpringBoot faz para gerenciamento de construção de projetos e geração final de pacotes de código? Desenvolvimento simplificado. A simplificação não é o seu papel principal. No final, cabe ao maven gerenciar todo o projeto, então o SpringBoot deve ouvir o maven. Após toda a confirmação, o seguinte é fácil de fazer. A ideia geral é a seguinte:

• Primeiro configure um ambiente específico no ambiente maven
• Basta ler o ambiente definido pelo maven no SpringBoot

Configure vários ambientes no maven (usando atributos para distinguir ambientes)

<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>

Leia o valor de configuração do maven no SpringBoot

spring:
	profiles:
    	active: @profile.active@

​ O @property name@ acima é o formato gramatical para leitura do valor da propriedade configurado no maven.

Resumir

1. Quando o Maven e o SpringBoot controlam vários ambientes ao mesmo tempo, o Mavn é o principal e o SpringBoot usa o espaço reservado @…@ para ler o valor da propriedade de configuração correspondente do Maven
2. Com base na premissa de que o SpringBoot lê as propriedades de configuração do Maven, se você testar o projeto no Idea, cada atualização do pom.xml precisa ser compilada manualmente para entrar em vigor

4. Log

4.1, base de registro

O log serve, na verdade, para registrar as informações sobre o funcionamento diário do programa, e suas principais funções são as seguintes:

• Código de depuração durante a programação
• Registrar informações durante o período de operação
• Registre informações importantes para operações diárias (pico de tráfego, tempo médio de resposta...)
• Registrar informações de erro do aplicativo (pilha de erros)
• Registre os dados do processo de operação e manutenção (expansão, paradas, alarme...)

4.2. Use a ferramenta de log para registrar logs no código

Etapa ① : Adicionar operação de registro

@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";
    }
}

O objeto de log no código acima é o objeto usado para gravar o log, e as operações de log.debug e log.info abaixo são a API para gravar o log.

Etapa ② : Defina o nível de saída do log

Após a configuração do log, você pode escolher quais registros participantes de acordo com as configurações. Aqui é definido de acordo com o nível do log. Existem 6 níveis de logs, a saber:

• TRACE: executar informações de pilha, baixo uso
• DEBUG: os programadores depuram o código usando
• INFO: registrar os dados do processo de operação e manutenção
• WARN: registra os dados de alarme do processo de operação e manutenção
• ERRO: registrar informações de pilha de erro
• FATAL: informações de desastre, mescladas em ERROR

Em circunstâncias normais, use DEBUG durante o desenvolvimento, use INFO depois de ficar online e use WARN para registros de informações de operação e manutenção. Veja como definir o nível de registro:

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

Essa configuração é muito simples e rude, e o sistema de log geralmente fornece controle refinado

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

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

Você também pode definir um controle mais refinado

Etapa ③ : Defina o grupo de log para controlar o nível de saída de log correspondente ao pacote especificado ou controle diretamente o nível de saída de log correspondente ao pacote especificado

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

​ Para ser franco, é configurar o geral e cada pacote.Se você sentir que a configuração é problemática, primeiro divida os pacotes em grupos e configure os grupos.

Resumir

1. O log é usado para registrar mensagens de processo de desenvolvimento, depuração e operação e manutenção
2. Existem 6 níveis de logs, geralmente 4 podem ser usados, ou seja, DEBUG, INFO, WARN, ERROR
3. O nível de exibição de log pode ser controlado na forma de grupo de log ou pacote de código

Otimize o código de criação do objeto de log

Ao escrever o código, cada classe deve escrever e criar objetos de log. Isso pode ser otimizado usando as classes de ferramentas fornecidas pela tecnologia lombok usada anteriormente.

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

Depois de importar o lombok, use anotações para fazê-lo e o nome do objeto de log é log

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

Resumir

1. Adicione rapidamente objetos de log a classes com base na anotação @Slf4j fornecida pelo lombok

4.2. Controle de formato de saída de log

O log já pode ser gravado, mas o formato de gravação atual é fornecido pelo SpringBoot.Se você quiser personalizar o controle, você mesmo precisa configurá-lo. Primeiro analise o formato de registro do log atual.

• PID: ID do processo, que é usado para indicar o processo da operação atual. Quando vários serviços registram logs ao mesmo tempo, esse valor pode ser usado para auxiliar os programadores na depuração de programas

• Nome da classe/interface pertencente: As informações exibidas atualmente são as informações reescritas do SpringBoot. Se o nome for muito longo, simplifique o nome do pacote e escreva-o como a primeira letra ou exclua-o diretamente

Para uma única mensagem de log, a data, o local do acionador e as informações do registro são as informações principais. O nível é usado para filtragem e o PID e o nome do encadeamento são usados ​​para análise precisa. Depois de conhecer essas informações, você pode fazer o DIY do formato de log.

logging:
	pattern:
    	console: "%d - %m%n"

• %d: data

• %m: mensagem

• %n: nova linha

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

Resumir

1. Regras de formatação de saída de log

4.3. Arquivos de registro

O log não pode ser apenas exibido no console, mas deve ser registrado em um arquivo para posterior manutenção e referência.

​ Existem várias estratégias para o uso de arquivos de log, como registros diários, registros classificados, registros pós-alarme, etc. Aqui estudamos principalmente como os arquivos de log são gravados.

O formato de registro em um arquivo é muito simples, basta definir o nome do arquivo de log.

logging:
	file:
    	name: server.log

Embora o formato acima possa ser usado para gravar o log, mas diante de situações online complexas, um registro de arquivo definitivamente não é capaz de atender aos requisitos de operação e manutenção. Normalmente, os arquivos de log são gravados todos os dias. Ao mesmo tempo , a fim de facilitar a manutenção, cada tamanho do arquivo de log. Os métodos de configuração comuns para arquivos de log são fornecidos abaixo:

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

O formato acima é baseado na tecnologia logback log para definir o formato de configuração do arquivo de log diário, e as informações devem ser despejadas no segundo arquivo depois que a capacidade atingir 3 KB. %d nas regras de nomenclatura de arquivo identifica a data e %i é uma variável incremental usada para distinguir arquivos de log.

Resumir

1. logar em arquivo
2. Configurações de formato de arquivo de log