Analyse de version Finchley basée sur Spring Boot 2.x

Spring Boot 2.x est sorti depuis longtemps, et maintenant Spring Cloud a également publié la version Finchley basée sur Spring Boot 2.x, faisons maintenant une mise à niveau globale du framework pour le projet.

Avant la mise à niveau=> Après la mise à niveau

Spring Boot 1.5.x => Spring Boot 2.0.2

Spring Cloud Edgware SR4 => ; Spring Cloud Finchley.RELEASE

Eureka Server

Mise à jour des dépendances d'Eureka Server

Avant la mise à niveau :

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-eureka-server</artifactId>
</dependency>

Après la mise à niveau :

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>

Eureka Client

Étant donné que le centre de configuration doit être enregistré en tant que service dans le centre d'enregistrement, Eureka Client doit être mis à niveau et les autres dépendances n'ont pas changé.

Mise à jour des dépendances d'Eureka Client

Avant la mise à niveau :

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-eureka</artifactId>
</dependency>

Après la mise à niveau :

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

Spring Cloud

L'adresse IP de l'instance client dans le centre d'inscription n'est pas affichée correctement

Car la configuration de l'adresse IP du client du service Spring Cloud a changé.

Avant la mise à niveau :

${spring.cloud.client.ipAddress}

Après la mise à niveau :

${spring.cloud.client.ip-address}

Spring Security

Les centres d'enregistrement généraux et les centres de configuration utiliseront le cryptage de sécurité. cela dépendra du composant spring-boot-starter-security, et il y a deux problèmes après la mise à niveau.

1. Le nom d'utilisateur et le mot de passe ne peuvent pas être connectés

Car les paramètres de Spring Security ont été modifiés.

Avant la mise à niveau :

security:
  user:
    name:
    password:

Après la mise à niveau :

spring:
  security:
     user:
       name: 
       password:

2 Il n'y a aucune instance enregistrée dans le centre d'enregistrement

Comme le montre la figure, il n'y a pas d'instance d'enregistrement et les deux centres d'enregistrement ne peuvent pas s'inscrire l'un auprès de l'autre.

Étant donné que Spring Security active toutes les défenses contre les attaques CSRF par défaut, la défense de /eureka doit être désactivée.

Ajouter la configuration ignorée dans la classe d'entrée Application :

@EnableWebSecurity
static class WebSecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.csrf().ignoringAntMatchers("/eureka/**");
        super.configure(http);
    }
}

3. Le centre de configuration ne peut pas chiffrer ou déchiffrer

Après la mise à niveau, il a été a constaté que l'accès au centre de configuration ne peut pas être lu. Après avoir obtenu la configuration, les informations de configuration ne peuvent pas être cryptées ou déchiffrées. Le lien pour accéder au centre de configuration passe directement à la page de connexion.

Maintenant, je souhaite revenir à la méthode d'authentification de base précédente. J'ai trouvé le code source et j'ai constaté qu'il était automatiquement configuré pour accéder à la page de connexion. Maintenant, réécrivez-le. .

Code source de configuration automatique :
org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter#configure(org.springframework.security.config.annotation.web.builders.HttpSecurity)

protected void configure(HttpSecurity http) throws Exception {
    logger.debug("Using default configure(HttpSecurity). If subclassed this will potentially override subclass configure(HttpSecurity).");

    http
        .authorizeRequests()
            .anyRequest().authenticated()
            .and()
        .formLogin().and()
        .httpBasic();
}

Après la réécriture :

@EnableWebSecurity
static class WebSecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.csrf().ignoringAntMatchers("/**").and().authorizeRequests().anyRequest()
                .authenticated().and().httpBasic();
    }

}

tue en fait formLogin() et revient à la méthode d'authentification d'authentification de base précédente, comme le montre la figure ci-dessous.

Nous pouvons désormais utiliser les commandes suivantes pour crypter et déchiffrer à nouveau.

Après avoir restauré l'authentification de base, le service précédent qui nécessitait une connexion cryptée au centre de configuration peut à nouveau fonctionner normalement.

Maven

Après la mise à niveau vers Spring Boot 2.x, j'ai constaté que le plug-in de démarrage Maven de Spring Boot n'est pas facile à utiliser, principalement parce que le profil ne peut pas être changé librement.

Avant la mise à niveau :

spring-boot:run -Drun.profiles=profile1

Après la mise à niveau :

spring-boot:run -Dspring-boot.run.profiles=profile1

Résumé

Ce qui précède sont les solutions résumées après avoir traversé tous les pièges. , le processus réel de résolution du problème est beaucoup plus compliqué. Les changements de version sont un peu importants. Cette fois, les dépendances de base de Spring Cloud, ainsi que le centre d'enregistrement (Eureka Server) et le centre de configuration (Config Server) ont été mis à niveau avec succès.

Recommandations associées :

Introduction connexe au processus de démarrage de Spring Boot

Explication détaillée des tests unitaires de Spring Boot

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!