spring cloud gateway

Características

• Java 17

• Estrutura Spring 6

• Bota Primavera 3

• Roteamento dinâmico

• Correspondência de rotas incorporada ao Spring Handler Mapping

• Correspondência de rota na solicitação HTTP (caminho, método, cabeçalho, host, etc…​)

• Filtros com escopo para rota correspondente

• Os filtros podem modificar a solicitação HTTP downstream e a resposta HTTP (adicionar/remover cabeçalhos, adicionar/remover parâmetros, reescrever caminho, definir caminho, Hystrix, etc...​)

• API ou configuração orientada

• Suporta Spring Cloud DiscoveryClient para configuração de rotas

Prédio

Diretiva não resolvida em <stdin> - include::https:///raw.githubusercontent.com/spring-cloud/spring-cloud-build/main/docs/modules/ROOT/partials/building.adoc[]

Contribuindo

Spring Cloud é lançado sob a licença não restritiva Apache 2.0 e segue um processo de desenvolvimento muito padrão do Github, usando o rastreador do Github para problemas e mesclando solicitações pull no principal. Se você quiser contribuir, mesmo que seja algo trivial, não hesite, mas siga as orientações abaixo.

Assine o Contrato de Licença de Colaborador

Antes de aceitarmos um patch não trivial ou uma solicitação pull, precisaremos que você assine o Contrato de Licença de Colaborador. Assinar o acordo do contribuidor não concede a ninguém direitos de commit no repositório principal, mas significa que podemos aceitar suas contribuições, e você receberá um crédito de autor se o fizermos. Contribuidores ativos podem ser convidados a ingressar na equipe principal e ter a capacidade de mesclar solicitações pull.

Código de Conduta

Este projeto segue o código de conduta do Contributor Covenant. Ao participar, espera-se que você cumpra este código. Por favor, relate comportamento inaceitável para [email protected].

Convenções de código e limpeza

Nada disso é essencial para uma solicitação pull, mas todos ajudarão. Eles também podem ser adicionados após a solicitação pull original, mas antes de uma mesclagem.

• Use as convenções de formato de código do Spring Framework. Se você usar o Eclipse, poderá importar as configurações do formatador usando o arquivo eclipse-code-formatter.xml do projeto Spring Cloud Build. Se estiver usando o IntelliJ, você pode usar o plug-in Eclipse Code Formatter para importar o mesmo arquivo.

• Certifique-se de que todos os novos arquivos .java tenham um comentário simples da classe Javadoc com pelo menos uma tag @author identificando você e, de preferência, pelo menos um parágrafo sobre a finalidade da classe.

• Adicione o comentário do cabeçalho da licença ASF a todos os novos arquivos .java (copie dos arquivos existentes no projeto)

• Adicione-se como @author aos arquivos .java que você modifica substancialmente (mais do que alterações cosméticas).

• Adicione alguns Javadocs e, se você alterar o namespace, alguns elementos do documento XSD.

• Alguns testes unitários também ajudariam muito — alguém tem que fazer isso.

• Se ninguém mais estiver usando seu branch, faça o rebase dele no main atual (ou outro branch de destino no projeto principal).

• Ao escrever uma mensagem de commit, siga estas convenções. Se você estiver corrigindo um problema existente, adicione Fixes gh-XXXX no final da mensagem de commit (onde XXXX é o número do problema).

Estilo de verificação

Spring Cloud Build vem com um conjunto de regras de estilo de verificação. Você pode encontrá-los no módulo spring-cloud-build-tools . Os arquivos mais notáveis ​​do módulo são:

ferramentas de construção de nuvem de primavera/

 └── src
   ├── estilo de verificação
   │ └── checkstyle-suppressions.xml (3)
   └── principal
   └── recursos
   ├── checkstyle-header.txt (2)
   └── estilo de verificação.xml (1)

1. Regras de estilo de verificação padrão

2. Configuração do cabeçalho do arquivo

3. Regras de supressão padrão

Configuração de estilo de verificação

As regras de estilo de verificação estão desativadas por padrão . Para adicionar checkstyle ao seu projeto basta definir as seguintes propriedades e plugins.

pom.xml

 <propriedades>
<maven-checkstyle-plugin.failsOnError>true</maven-checkstyle-plugin.failsOnError> (1)
        <maven-checkstyle-plugin.failsOnViolation>verdadeiro
        </maven-checkstyle-plugin.failsOnViolation> (2)
        <maven-checkstyle-plugin.includeTestSourceDirectory>verdadeiro
        </maven-checkstyle-plugin.includeTestSourceDirectory> (3)
</propriedades>

<construir>
        <plug-ins>
            <plug-in> (4)
                <groupId>io.spring.javaformat</groupId>
                <artifactId>spring-javaformat-maven-plugin</artifactId>
            </plugin>
            <plug-in> (5)
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-checkstyle-plugin</artifactId>
            </plugin>
        </plugins>

    <relatório>
        <plug-ins>
            <plug-in> (5)
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-checkstyle-plugin</artifactId>
            </plugin>
        </plugins>
    </relatório>
</build>

1. Falha na compilação com base em erros de Checkstyle

2. Falha na compilação com base em violações do Checkstyle

3. Checkstyle analisa também as fontes de teste

4. Adicione o plugin Spring Java Format que irá reformatar seu código para passar a maioria das regras de formatação Checkstyle

5. Adicione o plugin checkstyle às suas fases de construção e relatório

Se você precisar suprimir algumas regras (por exemplo, o comprimento da linha precisa ser maior), basta definir um arquivo em ${project.root}/src/checkstyle/checkstyle-suppressions.xml com suas supressões. Exemplo:

projectRoot/src/checkstyle/checkstyle-suppresions.xml

 <?xml versão="1.0"?>
<!DOCTYPE supressões PUBLIC
		"-// Rastreamento de filhotes // Supressões de DTD 1.1 // EN"
		"https://www.puppycrawl.com/dtds/suppressions_1_1.dtd">
<supressões>
	<suppress files=".*ConfigServerApplication.java" checks="HideUtilityClassConstructor"/>
	<suppress files=".*ConfigClientWatch.java" checks="LineLengthCheck"/>
</supressões>

É aconselhável copiar ${spring-cloud-build.rootFolder}/.editorconfig e ${spring-cloud-build.rootFolder}/.springformat para o seu projeto. Dessa forma, algumas regras de formatação padrão serão aplicadas. Você pode fazer isso executando este script:

$ curl https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/main/.editorconfig -o .editorconfig
$ touch .springformat

Configuração do ambiente de desenvolvimento integrado

IDEIA INTELIG

Para configurar o Intellij você deve importar nossas convenções de codificação, perfis de inspeção e configurar o plugin checkstyle. Os arquivos a seguir podem ser encontrados no projeto Spring Cloud Build.

ferramentas de construção de nuvem de primavera/

 └── src
   ├── estilo de verificação
   │ └── checkstyle-suppressions.xml (3)
   └── principal
   └── recursos
   ├── checkstyle-header.txt (2)
   ├── estilo de verificação.xml (1)
   └── inteligência
     ├── Intellij_Project_Defaults.xml (4)
     └── Intellij_Spring_Boot_Java_Conventions.xml (5)

1. Regras de estilo de verificação padrão

2. Configuração do cabeçalho do arquivo

3. Regras de supressão padrão

4. Padrões de projeto para Intellij que aplicam a maioria das regras Checkstyle

5. Convenções de estilo de projeto para Intellij que aplicam a maioria das regras Checkstyle

Figura 1. Estilo de código

Vá para File → Settings → Editor → Code style . Clique no ícone ao lado da seção Scheme . Lá, clique no valor Import Scheme e escolha a opção Intellij IDEA code style XML . Importe o arquivo spring-cloud-build-tools/src/main/resources/intellij/Intellij_Spring_Boot_Java_Conventions.xml .

Figura 2. Perfis de inspeção

Vá para File → Settings → Editor → Inspections . Clique no ícone ao lado da seção Profile . Lá, clique em Import Profile e importe o arquivo spring-cloud-build-tools/src/main/resources/intellij/Intellij_Project_Defaults.xml .

Estilo de verificação

Para que o Intellij funcione com Checkstyle, você deve instalar o plugin Checkstyle . É aconselhável instalar também o Assertions2Assertj para converter automaticamente as asserções JUnit

Vá para File → Settings → Other settings → Checkstyle . Clique no ícone + na seção Configuration file . Lá, você terá que definir de onde as regras de checkstyle devem ser escolhidas. Na imagem acima, escolhemos as regras do repositório clonado do Spring Cloud Build. No entanto, você pode apontar para o repositório GitHub do Spring Cloud Build (por exemplo, para checkstyle.xml : https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/main/spring-cloud-build-tools/src/main/resources/checkstyle.xml ). Precisamos fornecer as seguintes variáveis:

• checkstyle.header.file - aponte-o para o arquivo Spring Cloud Build, spring-cloud-build-tools/src/main/resources/checkstyle-header.txt em seu repositório clonado ou por meio do https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/main/spring-cloud-build-tools/src/main/resources/checkstyle-header.txt URL.

• checkstyle.suppressions.file - supressões padrão. Aponte-o para o arquivo spring-cloud-build-tools/src/checkstyle/checkstyle-suppressions.xml Spring Cloud Build em seu repositório clonado ou por meio de https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/main/spring-cloud-build-tools/src/checkstyle/checkstyle-suppressions.xml URL.

• checkstyle.additional.suppressions.file - esta variável corresponde às supressões em seu projeto local. Por exemplo, você está trabalhando em spring-cloud-contract . Em seguida, aponte para a pasta project-root/src/checkstyle/checkstyle-suppressions.xml . Um exemplo de spring-cloud-contract seria: /home/username/spring-cloud-contract/src/checkstyle/checkstyle-suppressions.xml .

Importante

Lembre-se de definir o Scan Scope como All sources pois aplicamos regras de estilo de verificação para fontes de produção e de teste.

Localizador de duplicatas

Spring Cloud Build traz basepom:duplicate-finder-maven-plugin , que permite sinalizar classes e recursos duplicados e conflitantes no caminho de classe java.

Configuração duplicada do Finder

O localizador de duplicatas está habilitado por padrão e será executado na fase verify da sua construção do Maven, mas só terá efeito no seu projeto se você adicionar o duplicate-finder-maven-plugin à seção build do pom.xml do projeto.

pom.xml

< build >
    < plugins >
        < plugin >
            < groupId >org.basepom.maven</ groupId >
            < artifactId >duplicate-finder-maven-plugin</ artifactId >
        </ plugin >
    </ plugins >
</ build >

Para outras propriedades, definimos padrões conforme listado na documentação do plugin.

Você pode substituí-los facilmente, mas definindo o valor da propriedade selecionada prefixada com duplicate-finder-maven-plugin . Por exemplo, defina duplicate-finder-maven-plugin.skip como true para ignorar a verificação de duplicatas em sua compilação.

Se você precisar adicionar ignoredClassPatterns ou ignoredResourcePatterns à sua configuração, certifique-se de adicioná-los na seção de configuração do plugin do seu projeto:

< build >
    < plugins >
        < plugin >
            < groupId >org.basepom.maven</ groupId >
            < artifactId >duplicate-finder-maven-plugin</ artifactId >
            < configuration >
                < ignoredClassPatterns >
                    < ignoredClassPattern >org.joda.time.base.BaseDateTime</ ignoredClassPattern >
                    < ignoredClassPattern >.*module-info</ ignoredClassPattern >
                </ ignoredClassPatterns >
                < ignoredResourcePatterns >
                    < ignoredResourcePattern >changelog.txt</ ignoredResourcePattern >
                </ ignoredResourcePatterns >
            </ configuration >
        </ plugin >
    </ plugins >
</ build >