O Spring boot é empacotado da maneira padrão porque é um pacote totalmente dependente (também chamado de pacote gordo), que não é apenas lento para empacotar, grande em tamanho e lento na transmissão. Hoje, vou ensiná-lo a thin boot boot.
fundo
Agora que a arquitetura de microsserviço está se tornando cada vez mais popular, mais de 10 módulos de serviço baseados em boot de mola para um projeto são muito comuns. Supondo que um módulo de serviço esteja marcado como um pacote jar de 100M, uma versão completa pode precisar fazer upload de arquivos 1G. Quando as condições da rede são boas, você pode não sentir muito, mas se o código precisar ser copiado na intranet para publicação ou carregado em alguns servidores externos, isso afetará seriamente a eficiência do trabalho.
Então, há alguma maneira de nos tornar mais finos o pacote do pote para botas?
A resposta é sim, quando o spring boot é empacotado por meio da configuração relevante, apenas alguns pacotes de dependência que mudam frequentemente são carregados, como o módulo comum do projeto, alguns módulos de API que chamam a interface feign e esses pacotes de dependência fixa são carregados diretamente no servidor No diretório especificado, você pode especificar o diretório onde o pacote lib é carregado por meio do comando quando o projeto é iniciado. Dessa forma, o pacote jar que digitamos tem menos do que alguns megabytes, no máximo, o que reduz muito o tamanho do pacote jar do projeto de boot do spring e melhora a eficiência de publicação e lançamento.
Suplemento:
frasco de gordura : frasco de gordura, o pacote do frasco digitado contém todos os pacotes dependentes.
A vantagem é que pode ser executado diretamente, sem adicionar outros comandos. A desvantagem é que é muito grande e difícil de transmitir.
** thin jar: ** significa pacote thin. O pacote jar que é digitado contém apenas alguns pacotes de dependência frequentemente alterados, geralmente módulos públicos no projeto ou alguns módulos dependentes da interface da API.
A vantagem é que ele é pequeno, o que contribui para melhorar a eficiência do lançamento do projeto; a
desvantagem é que pode haver riscos de segurança em depender de pacotes externos. Se a dependência do maven do projeto muda com frequência, é mais problemático manter o diretório lib no servidor e não é propício para a localização do problema.
Exercício de emagrecimento
1. Modifique os parâmetros de embalagem do maven
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<layout>ZIP</layout>
<includes>
<include>
<groupId>nothing</groupId>
<artifactId>nothing</artifactId>
</include>
<include>
<groupId>com.huacloud.tax.rpc</groupId>
<artifactId>common</artifactId>
</include>
</includes>
</configuration>
</plugin>
</plugins>
</build>
Descrição:
layout
usado para configurar o tipo de pacote executável jar Main-Class, deve ser definido como ZIP, de forma que um jar acesse a Main-Class é PropertiesLauncher.
inclui
terá que manter o pacote de frasco, de acordo com groupId e artifactId (nota que ambos são necessários) incluir na.
Nada significa pacotes dependentes inexistentes, o que significa que
os módulos de serviço comuns são importados sem quaisquer pacotes dependentes .
2. Execute o pacote
maven.Primeiro execute mvn clean e, em seguida, execute mvn package
para copiar o pacote que foi impresso no diretório de destino para o diretório D: \ web e renomeie-o para tax-ws-thin-zip.jar.
Verifique o arquivo MANIFEST.MF no diretório META-INF em tax-ws-thin-zip.jar através da ferramenta de compactação: é
descoberto que o valor de Main-Class realmente mudou para PropertiesLauncher, indicando que nossa configuração foi bem-sucedida.
(Quanto ao motivo pelo qual a classe principal deve ser configurada como PropertiesLauncher, irei apresentá-la mais tarde)
3. Compare o volume de FatJar e ThinJar:
Pode-se verificar que o volume da embalagem fina tax-ws-thin.jar é muito menor do que o volume da embalagem gorda.
4. Copie o pacote lib do pacote fatJar para o diretório D: \ web
5. Inicie o pacote jar por comando
D:\web>java -Dloader.path="D:\web\lib" -jar tax-ws-thin.jar
Configure o caminho de carregamento do pacote externo dependente por meio do parâmetro de inicialização loader.path.
O início bem-sucedido do projeto indica que o pacote de dependência terceirizado que configuramos foi carregado para o efeito.
Exploração Princípio
Por que definir a classe principal do pacote jar executável como PropertiesLauncher para especificar o caminho de carregamento do pacote dependente configurando o parâmetro de inicialização loader.path?
Em primeiro lugar, temos algum entendimento do Launcher no princípio de implementação do pacote jar executável de boot do spring.
O seguinte foi retirado do site oficial do spring boot: A
classe org.springframework.boot.loader.Launcher é uma classe especial de programa de inicialização que serve como ponto de entrada principal para o jar executável. É a verdadeira Main-Class no arquivo jar, usada para definir o URLClassLoader apropriado e, finalmente, chamar o método main ().
Existem três subclasses do launcher ( JarLauncher, WarLauncher e PropertiesLauncher ). Seu objetivo é carregar recursos (arquivos .class, etc.) de arquivos jar aninhados ou arquivos war no diretório (em vez de arquivos explicitamente no classpath). Para JarLauncher e WarLauncher, o caminho de aninhamento é fixo. JarLauncher está localizado em BOOT-INF / lib /, enquanto WarLauncher está localizado em WEB-INF / lib / e WEB-INF / lib-provided /. Se necessário, jars adicionais podem ser adicionados nesses locais. Por padrão, o PropertiesLauncher procura BOOT-INF / lib / no arquivo do seu aplicativo. Você pode adicionar outros locais definindo uma variável de ambiente chamada LOADER_PATH ou loader.path em loader.properties (esta é uma lista separada por vírgulas de diretórios, arquivos compactados ou diretórios em arquivos compactados).
————————————————
Em outras palavras, o Launcher Launcher carrega recursos dependentes para a inicialização do projeto. Existem 3 launchers ( JarLauncher, WarLauncher e PropertiesLauncher ). Os caminhos para JarLauncher e WarLauncher para carregar recursos são fixos e PropertiesLauncher pode ser acessado por meio da variável de ambiente loader.path Especifique onde carregar recursos.
Descrição do valor do atributo de layout:
JAR, o jar executável usual
da classe principal: org.springframework.boot.loader.JarLauncher
WAR, ou seja, o war executável usual, a dependência do contêiner de servlet necessária está localizada em
Main-Class: org.springframework.boot.loader.warLauncher
ZIP ou DIR, semelhante a JAR
Main-Class: org.springframework.boot.loader.PropertiesLauncher
(lembre-se disso, existem alguns outros cenários de aplicativo)
Configuração da propriedade PropertiesLauncher
PropertiesLauncher possui alguns recursos especiais que podem ser ativados por meio de propriedades externas (propriedades do sistema, variáveis de ambiente, entradas de manifesto ou loader.properties). A tabela a seguir descreve esses atributos:
| Chave | objetivo |
|---|---|
| loader.path | caminho de carregamento do pacote lib |
| loader.home | Usado para resolver caminhos relativos em loader.path. Por exemplo, dado loader.path = lib, $ {loader.home} / lib é o local do classpath (e todos os arquivos jar nesse diretório). Essa propriedade também é usada para localizar o arquivo loader.properties, conforme mostrado no seguinte exemplo / opt / app. O padrão é $ {user.dir}. |
| loader.args | Os parâmetros padrão do método principal (separados por espaços). |
| loader.main | O nome da classe principal a ser iniciada (por exemplo, com.app.Application) |
| loader.config.name | O caminho do arquivo de propriedades (por exemplo, classpath: loader.properties). O padrão é loader.properties. |
| loader.system | Sinalizador booleano indicando que todos os atributos devem ser adicionados às propriedades do sistema. O padrão é falso. |
Para obter mais informações, você pode ver a documentação do pacote jar executável do spring boot no site oficial: The Executable Jar Format
Correção de armadilha
Eu vi uma maneira na Internet que não configura layout = ZIP, mas depois de marcá-lo diretamente como um pacote fino, use -Djava.ext.dirs no comando de inicialização para especificar o caminho de carregamento do pacote de dependência externa.
D:\web>java -Djava.ext.dirs="D:\web\lib" -jar tax-ws-thin.jar
Análise de princípio:
-Djava.ext.dirs substituirá a configuração ext do próprio Java. O diretório especificado por java.ext.dirs é carregado pelo carregador ExtClassLoader. Se o seu programa não especificar esta propriedade do sistema, o carregador carregará $ JAVA_HOME / por padrão Todos os arquivos jar no diretório jre / lib / ext. Mas se você especificar manualmente as propriedades do sistema e esquecer de adicionar o caminho $ JAVA_HOME / jre / lib / ext, ExtClassLoader não carregará os arquivos jar em $ JAVA_HOME / lib / ext, o que significa que você perderá algumas funções. Por exemplo, a implementação do algoritmo de criptografia e descriptografia que vem com o java.
Portanto, por esta forma de escrita, modificar diretamente à força o caminho de carregamento do carregador de classe estendido padrão java pode facilmente causar alguns problemas. É melhor não usá-lo casualmente.
Não é possível encontrar o pacote de driver Oracle
Ao usar -Djava.ext.dirs para configurar o caminho de carregamento do pacote de dependência externa, há um problema que o pacote de driver do Oracle não pode ser carregado. Neste momento, você precisa adicionar
-Doracle.jdbc.thinLogonCapability = o3 para configurar a compatibilidade de login do Oracle
Extensão: mecanismo de delegação parental
A expansão aqui envolve o mecanismo de carregamento da delegação pai Java.
1. BootStrapClassLoader: inicia o carregador de classes. O ClassLoader é criado na inicialização e escrito no kernel JVM. Não é um arquivo bytecode, mas um código binário escrito em c ++, portanto, o desenvolvedor não pode obter a inicialização A referência da classe não pode ser operada por referência. Este carregador deve carregar a biblioteca de classes em $ JAVA_HOME / jre / lib (ou especificado pelo parâmetro -Xbootclasspath).
2. EXTClassLoader: carregador de classe estendido, ExtClassLoader irá carregar a biblioteca de classes em $ JAVA_HOME / jre / lib / ext (ou especificado pelo parâmetro -Djava.ext.dirs).
3. AppClassLoader: O carregador de aplicativos carregará a biblioteca de classes no caminho especificado pela variável de ambiente java CLASSPATH, e o caminho especificado pelo CLASSPATH pode ser obtido por meio de Systemn.getProperty ("java.class.path"), que pode ser substituído .
4. CustomClassLoader: O carregador personalizado é o CLassLoader definido pelo usuário.Por exemplo, o standardClassLoader do tomcat pertence a esta categoria.
Mecanismo de delegação pai ClassLoader:
1. Quando APPClassLoader carrega uma classe, ele não carrega primeiro a classe sozinho, mas delega a solicitação de carregamento de classe ao carregador de classe pai EXTClassloader para concluir.
2. Quando EXTClassLoader carrega uma classe, ele não tenta carregar a classe primeiro, mas delega a solicitação de carregamento de classe para BootStrapClassLoader para ser concluída.
3. Se BottStrapClassLoader falhar ao carregar, EXTClassLoader será usado para tentar carregar.
4. Se EXTClassLoader falhar ao carregar, ele usará APPClassLoader para carregar.Se APPClassLoader também falhar ao carregar, ele relatará uma exceção ClassNotFundException.
Resumindo
1. Por que você deseja fazer o pacote executável do jar do projeto de inicialização de primavera slim
? 2. Os três iniciadores de inicialização de primavera explicam
3. Como configurar o iniciador PropertiesLauncher para realizar o carregamento de pacotes de dependência externa
4. Saliente que especificando -Djava.ext.dirs Implementação de parâmetro do problema de carregamento de pacote de dependência externa
5. A extensão explica o mecanismo de carregamento de delegação pai Java
6. A solução para o problema de que o pacote de dependência externa não pode ser carregado com o pacote de driver Oracle
Finalmente
Obrigado pelo vosso recente apoio. Apesar de dizerem que aprender é da sua conta, é muito encorajador ver os seus gostos, comentários e atenção. Obrigado a todos.
Vou continuar a trabalhar duro para compartilhar mais artigos técnicos de alta qualidade e espero me comunicar e crescer com você.
Mais emocionante, siga-me.