Eseguire la migrazione di applicazioni Spring Cloud a Azure Container Apps

Questa guida descrive gli aspetti da tenere presenti quando si vuole eseguire la migrazione di un'applicazione Spring Cloud esistente da eseguire in Azure Container Apps.

Pre-migrazione

Per garantire una corretta migrazione, prima di iniziare completare i passaggi di valutazione e inventario descritti nelle sezioni seguenti.

Se non è possibile soddisfare i requisiti di pre-migrazione, vedere le guide alla migrazione complementari seguenti:

• Eseguire la migrazione di applicazioni JAR eseguibili a contenitori in Azure Kubernetes Service (indicazioni pianificate)
• Eseguire la migrazione di applicazioni JAR eseguibili a Azure Virtual Machines (linee guida pianificate)

Esaminare i componenti dell'applicazione

Determinare se e come viene usato il file system

Trovare tutte le istanze in cui i servizi eseguono la scrittura e/o la lettura dal file system locale. Identificare la posizione in cui vengono scritti e letti i file a breve termine/temporanei e i file di lunga durata.

Azure Container Apps offre diversi tipi di archiviazione. L'archiviazione effimera può leggere e scrivere dati temporanei ed essere disponibile per un contenitore o una replica in esecuzione. Azure File fornisce una risorsa di archiviazione permanente e può essere condivisa tra più contenitori. Per altre informazioni, vedere Usare i montaggi di archiviazione in Azure Container Apps.

Contenuto statico di sola lettura

Se l'applicazione attualmente serve contenuto statico, è necessario un percorso alternativo. È possibile prendere in considerazione lo spostamento di contenuto statico in Azure Blob Storage e l'aggiunta di Azure CDN per download veloci a livello globale. Per altre informazioni, vedere Static website hosting in Azure Storage and Quickstart: Integrare un account Azure storage con Azure CDN.

Contenuto statico pubblicato dinamicamente

Se l'applicazione supporta contenuti statici, caricati o generati dall'applicazione stessa, che rimangono invariati dopo la sua creazione, è possibile integrare Azure Blob Storage e Azure CDN. È anche possibile usare una funzione Azure per gestire i caricamenti e attivare gli aggiornamenti della rete CDN quando necessario. È stata fornita un'implementazione di esempio per l'uso in Caricamento e precaricamento della rete CDN di contenuti statici con Azure Functions.

Determinare se uno dei servizi contiene codice specifico del sistema operativo

Se l'applicazione contiene codice con dipendenze dal sistema operativo host, è necessario effettuare il refactoring per rimuovere tali dipendenze. Ad esempio, potrebbe essere necessario sostituire qualsiasi uso di / o \ nei percorsi del file system con File.Separator o Paths.get se l'applicazione è in esecuzione in Windows.

Passare a una piattaforma supportata

Se si crea manualmente l'applicazione Dockerfile e si distribuisce un'applicazione in contenitori in Azure Container Apps, si assume il controllo completo sulla distribuzione, incluse le versioni JRE/JDK.

Per la distribuzione da elementi, Azure Container Apps offre anche versioni specifiche di Java (8, 11, 17 e 21) e versioni specifiche dei componenti Spring Boot e Spring Cloud. Per garantire la compatibilità, eseguire prima di tutto la migrazione dell'applicazione a una delle versioni supportate di Java nell'ambiente corrente, quindi procedere con i passaggi di migrazione rimanenti. Assicurarsi di testare completamente la configurazione risultante. Usare la versione stabile più recente della distribuzione Linux in questi test.

Per ottenere la versione corrente Java, accedere al server di produzione ed eseguire il comando seguente:

java -version

Per le versioni supportate di Java, Spring Boot e Spring Cloud, e per le istruzioni di aggiornamento, vedere Panoramica di Java su Azure Container Apps.

Identificare le versioni di Spring Boot

Esaminare le dipendenze di ogni applicazione di cui viene eseguita la migrazione per determinare la versione di Spring Boot.

Intenditore

Nei progetti Maven, la versione di Spring Boot si trova in genere nell'elemento <parent> del file POM:

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>3.3.3</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>

Gradle

Nei progetti Gradle, la versione di Spring Boot si trova in genere nella plugins sezione, come versione del plug-in org.springframework.boot :

plugins {
  id 'org.springframework.boot' version '3.3.3'
  id 'io.spring.dependency-management' version '1.1.6'
  id 'java'
}

Per tutte le applicazioni che usano le versioni di Spring Boot precedenti alla versione 3.x, seguire la guida alla migrazione di Spring Boot 2.0 o la Guida alla migrazione di Spring Boot 3.0 per aggiornarli a una versione di Spring Boot supportata. Per le versioni supportate, vedere la documentazione di Spring Cloud .

Identificare le versioni di Spring Cloud

Esaminare le dipendenze di ogni applicazione di cui si intende eseguire la migrazione per determinare la versione dei componenti di Spring Cloud che usa.

Intenditore

Nei progetti Maven la versione di Spring Cloud viene in genere impostata nella spring-cloud.version proprietà :

  <properties>
    <spring-cloud.version>2023.0.2</spring-cloud.version>
  </properties>

Gradle

Nei progetti Gradle la versione di Spring Cloud è in genere impostata nel blocco delle proprietà aggiuntive "extra properties":

ext {
  set('springCloudVersion', "2023.0.2")
}

È necessario aggiornare tutte le applicazioni per usare le versioni supportate di Spring Cloud. Per le versioni supportate, vedere la documentazione di Spring Cloud .

Identificare le soluzioni di aggregazione dei log

Identificare le soluzioni di aggregazione dei log in uso dalle applicazioni di cui si esegue la migrazione. È necessario configurare le impostazioni di diagnostica nella migrazione per rendere disponibili gli eventi registrati per l'utilizzo. Per altre informazioni, vedere La sezione Verificare la registrazione della console e configurare le impostazioni di diagnostica .

Identificare gli agenti di gestione delle prestazioni delle applicazioni

Identificare gli agenti di gestione delle prestazioni delle applicazioni usati dalle applicazioni. ** Azure Container Apps non offre supporto integrato per l'integrazione con APM. È necessario preparare l'immagine del contenitore o integrare lo strumento APM direttamente nel codice. Se si vuole misurare le prestazioni dell'applicazione ma non è ancora integrato alcun APM, è consigliabile usare Azure Application Insights. Per altre informazioni, vedere la sezione Migrazione .

Inventario delle risorse esterne

Identificare le risorse esterne, ad esempio le origini dati, i broker dei messaggi JMS e gli URL di altri servizi. Nelle applicazioni Spring Cloud è in genere possibile trovare la configurazione per tali risorse in uno dei percorsi seguenti:

• Nella cartella src/main/resources , in un file denominato in genere application.properties o application.yml.
• Nel repository di Spring Cloud Config Server che hai identificato nel passaggio precedente.

Database

Per un'applicazione Spring Boot, le stringhe di connessione sono generalmente presenti nei file di configurazione quando dipende da un database esterno. Di seguito è riportato un esempio di file application.properties :

spring.datasource.url=jdbc:mysql://localhost:3306/mysql_db
spring.datasource.username=dbuser
spring.datasource.driver-class-name=com.mysql.jdbc.Driver

Di seguito è riportato un esempio di file application.yaml :

spring:
  data:
    mongodb:
      uri: mongodb://mongouser:deepsecret@mongoserver.contoso.com:27017

Vedere la documentazione di Spring Data per altri scenari possibili di configurazione:

• Repository JPA
• Repository JDBC
• Repository Cassandra
• Repository di MongoDB

Broker di messaggi JMS

Identificare il broker o i broker in uso cercando nel file di configurazione del build (in genere, un pom.xml o build.gradle) che elenca le dipendenze pertinenti.

Ad esempio, un'applicazione Spring Boot che usa ActiveMQ in genere conterrà questa dipendenza nel relativo file pom.xml :

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-activemq</artifactId>
</dependency>

Le applicazioni Spring Boot che usano broker commerciali in genere contengono dipendenze direttamente dalle librerie di driver JMS dei broker. Ecco un esempio di un file build.gradle :

    dependencies {
      ...
      compile("com.ibm.mq:com.ibm.mq.allclient:9.4.0.5")
      ...
    }

Dopo aver identificato i broker in uso, trova le impostazioni corrispondenti. Nelle applicazioni Spring Cloud è in genere possibile trovarli nei file application.properties e application.yml nella directory dell'applicazione o nel repository Spring Cloud Config Server.

Ecco un esempio di ActiveMQ da un file application.properties :

spring.activemq.brokerurl=broker:(tcp://localhost:61616,network:static:tcp://remotehost:61616)?persistent=false&useJmx=true
spring.activemq.user=admin
spring.activemq.password=<password>

Per altre informazioni sulla configurazione di ActiveMQ, vedere la documentazione relativa alla messaggistica spring boot.

Ecco un esempio IBM MQ da un file application.yaml :

ibm:
  mq:
    queueManager: qm1
    channel: dev.ORDERS
    connName: localhost(14)
    user: admin
    password: <password>

Per altre informazioni sulla configurazione di IBM MQ, vedere la documentazione relativa ai componenti IBM MQ Spring.

Identificare le cache esterne

Identificare eventuali cache esterne in uso. Spesso, Redis viene usato tramite Spring Data Redis. Per informazioni sulla configurazione, vedere la documentazione di Spring Data Redis .

Determinare se i dati della sessione vengono memorizzati nella cache tramite Spring Session cercando la rispettiva configurazione (in Java o XML).

Provider di identità

Identificare tutti i provider di identità e tutte le applicazioni Spring Cloud che richiedono l'autenticazione e/o l'autorizzazione. Per informazioni su come configurare i provider di identità, vedere le risorse seguenti:

• Per la configurazione di OAuth2, vedere la guida introduttiva di Spring Cloud Security.
• Per la configurazione di Spring Security di Auth0, vedere la documentazione di Auth0 Spring Security.
• Per la configurazione di PingFederate Spring Security, vedere le istruzioni Auth0 PingFederate.

Risorse configurate tramite il servizio VMware TAS (Tanzu Application Service) (in precedenza Pivotal Cloud Foundry)

Per le applicazioni gestite con TAS, le risorse esterne, incluse quelle descritte in precedenza, vengono spesso configurate tramite le associazioni del servizio TAS. Per esaminare la configurazione per tali risorse, usare l'interfaccia della riga di comando tas (Cloud Foundry) per visualizzare la VCAP_SERVICES variabile per l'applicazione.

# Log into TAS, if needed (enter credentials when prompted)
cf login -a <API endpoint>

# Set the organization and space containing the application, if not already selected during login.
cf target org <organization name>
cf target space <space name>

# Display variables for the application
cf env <Application Name>

Esaminare la VCAP_SERVICES variabile per le impostazioni di configurazione dei servizi esterni associati all'applicazione. Per altre informazioni, vedere la documentazione di TAS (Cloud Foundry).

Tutte le altre risorse esterne

Non è possibile documentare tutte le possibili dipendenze esterne in questa guida. Dopo la migrazione, è responsabilità dell'utente verificare che sia possibile soddisfare tutte le dipendenze esterne dell'applicazione.

Segreti e origini della configurazione dell'inventario

Password e stringhe sicure dell'inventario

Controllare tutte le proprietà e i file di configurazione e tutte le variabili di ambiente nelle distribuzioni di produzione per eventuali stringhe e password segrete. In un'applicazione Spring Cloud è in genere possibile trovare tali stringhe nel file application.properties o application.yml in singoli servizi o nel repository Spring Cloud Config Server.

Certificati di inventario

Documentare tutti i certificati usati per gli endpoint SSL pubblici o per la comunicazione con i database back-end e altri sistemi. È possibile visualizzare tutti i certificati nei server di produzione eseguendo il comando seguente:

keytool -list -v -keystore <path to keystore>

Determinare se viene usato Spring Cloud Vault

Se si usa Spring Cloud Vault per archiviare e accedere ai segreti, identificare l'archivio segreto di backup, ad esempio HashiCorp Vault o CredHub. Identificare quindi tutti i segreti usati dal codice dell'applicazione.

Individuare l'origine del server di configurazione

Se l'applicazione usa un server di configurazione Spring Cloud, identificare dove è archiviata la configurazione. Questa impostazione viene in genere trovata nel file bootstrap.yml o bootstrap.properties o talvolta nel file application.yml o application.properties . L'impostazione è simile all'esempio seguente:

spring.cloud.config.server.git.uri: file://${user.home}/spring-cloud-config-repo

Anche se Git viene usato più comunemente come archivio dati di backup di Spring Cloud Config Server, come illustrato in precedenza, uno degli altri back-end possibili può essere in uso. Consultare la documentazione di Spring Cloud Config Server per informazioni su altri back-end, ad esempio Il database relazionale (JDBC),SVN e il file system locale.

Esaminare l'architettura di distribuzione

Documentare i requisiti hardware per ogni servizio

Per ogni servizio Spring Cloud (escluso il server di configurazione, il registro o il gateway), documentare le informazioni seguenti:

• Numero di istanze in esecuzione.
• Numero di CPU allocate a ogni istanza.
• Quantità di RAM allocata a ogni istanza.

Documentare la replica geografica/distribuzione

Determinare se le applicazioni Spring Cloud sono attualmente distribuite tra più aree o data center. Documentare i requisiti di disponibilità operativa e l'Accordo sul Livello di Servizio (SLA) per le applicazioni che si sta migrando.

Identificare i client che ignorano il registro dei servizi

Identificare tutte le applicazioni client che richiamano i servizi di cui eseguire la migrazione senza usare Spring Cloud Service Registry. Dopo la migrazione, tali chiamate non saranno più possibili. Aggiornare tali client per l'uso di Spring Cloud OpenFeign prima della migrazione.

Migrazione

Rimuovere configurazioni con restrizioni

L'ambiente Azure Container Apps offre Eureka Server gestito, Spring Cloud Config Server e Admin. Quando un'applicazione è associata al componente Java, Azure Container Apps inserisce le proprietà correlate come variabili di ambiente di sistema. In base alla progettazione della configurazione esterna di Spring Boot , le proprietà dell'applicazione definite nel codice o incluse in pacchetti negli artefatti vengono sovrascritte dalle variabili di ambiente di sistema.

Se si imposta una delle proprietà seguenti tramite l'argomento della riga di comando, una proprietà di sistema Java o la variabile di ambiente del contenitore, è necessario rimuoverla per evitare conflitti e comportamenti imprevisti:

• SPRING_CLOUD_CONFIG_COMPONENT_URI
• SPRING_CLOUD_CONFIG_URI
• SPRING_CONFIG_IMPORT
• eureka.client.fetch-registry
• eureka.client.service-url.defaultZone
• eureka.instance.prefer-ip-address
• eureka.client.register-with-eureka
• SPRING_BOOT_ADMIN_CLIENT_INSTANCE_PREFER-IP
• SPRING_BOOT_ADMIN_CLIENT_URL

Creare un ambiente gestito per Azure Container Apps e le relative applicazioni

Effettuare il provisioning di un'app di Azure Container Apps nel proprio abbonamento Azure su un ambiente gestito esistente, oppure creare un nuovo ambiente per ogni servizio che si sta migrando. Non è necessario creare app in esecuzione come server di configurazione e registro Spring Cloud. Per altre informazioni, vedere Quickstart: Distribuire la prima app contenitore usando il portale di Azure.

Preparare il server di configurazione Spring Cloud

Configurare il server di configurazione nel Azure Container Apps per il componente Spring. Per altre informazioni, vedere Configurare le impostazioni per il componente Config Server for Spring in Azure Container Apps.

Verificare la registrazione della console e configurare le impostazioni di diagnostica

Configurare la registrazione per assicurarsi che tutto l'output venga indirizzato alla console anziché ai file.

Dopo la distribuzione di un'applicazione in Azure Container Apps, è possibile configurare le opzioni di registrazione nell'ambiente App contenitore per definire una o più destinazioni dei log. Queste destinazioni possono includere Azure Monitor Log Analytics, Azure Hub eventi o anche altre soluzioni di monitoraggio di terze parti. È anche possibile disabilitare i dati di log e visualizzare i log solo in fase di esecuzione. Per istruzioni dettagliate sulla configurazione, vedere Log storage and monitoring options in Azure Container Apps.For detailed configuration instruction, see Log storage and monitoring options in Azure Container Apps.

Configurare la risorsa di archiviazione persistente

Se una parte dell'applicazione legge o scrive nel file system locale, è necessario configurare l'archiviazione permanente per sostituire il file system locale. È possibile specificare il percorso da montare nel contenitore tramite le impostazioni dell'app e allinearlo al percorso usato dall'app. Per altre informazioni, vedere Usare i montaggi di archiviazione in Azure Container Apps.

Eseguire la migrazione dei segreti di Spring Cloud Vault a Azure KeyVault

È possibile inserire segreti direttamente nelle applicazioni tramite Spring usando il Azure KeyVault Spring Boot Starter. Per altre informazioni, vedere Come usare Spring Boot Starter per Azure Key Vault.

Eseguire la migrazione di tutti i certificati a Key Vault

Azure Container Apps supporta la comunicazione sicura tra le app. L'applicazione non deve gestire il processo di stabilire comunicazioni sicure. È possibile caricare il certificato privato in Azure Container Apps o usare un certificato gestito gratuito fornito da Azure Container Apps. L'uso di Azure Key Vault per gestire i certificati è un approccio consigliato. Per altre informazioni, vedere Certificates in Azure Container Apps.

Configurare le integrazioni di APM (Application Performance Management)

Se nel contenitore sono già state configurate variabili correlate ad APM, è sufficiente assicurarsi che sia possibile stabilire la connessione alla piattaforma APM di destinazione. Se la configurazione di APM fa riferimento alle variabili di ambiente dal contenitore, è necessario impostare le variabili di ambiente di runtime di conseguenza in Azure Container Apps. Le informazioni riservate, ad esempio il connection string, devono essere gestite in modo sicuro. È possibile specificarlo come segreto o fare riferimento a un segreto archiviato in Azure Key Vault.

Configurare i segreti per servizio e le impostazioni esternalizzate

È possibile inserire le impostazioni di configurazione in ogni contenitore come variabili di ambiente. Eventuali modifiche apportate alle variabili creano una nuova revisione per l'app esistente. I segreti sono coppie chiave-valore e rimangono valide in tutte le revisioni.

Eseguire la migrazione e abilitare il provider di identità

Se una delle applicazioni Spring Cloud richiede l'autenticazione o l'autorizzazione, usare le linee guida seguenti per assicurarsi che siano configurate per accedere al provider di identità:

• Se il provider di identità è Microsoft Entra ID, non è necessario apportare modifiche.
• Se il provider di identità è una foresta Active Directory on-premises, considerare l'implementazione di una soluzione di identità ibrida con Microsoft Entra ID. Per indicazioni, vedere la documentazione sull'identità ibrida.
• Se il provider di identità è un'altra soluzione locale, ad esempio PingFederate, consultare l'argomento Installazione personalizzata di Microsoft Entra Connect per configurare la federazione con Microsoft Entra ID. In alternativa, è consigliabile usare Spring Security per usare il provider di identità tramite OAuth2/OpenID Connect o SAML.

Aggiornare le applicazioni client

Aggiornare la configurazione di tutte le applicazioni client per usare gli endpoint di Azure Container Apps pubblicati per le applicazioni migrate.

Fase post-migrazione

Ora che è stata completata la migrazione, verificare che l'applicazione funzioni come previsto. È quindi possibile rendere l'applicazione maggiormente nativa del cloud seguendo queste raccomandazioni.

• Valutare se consentire l'uso dell'applicazione con Spring Cloud Registry. Questo componente consente all'applicazione di essere individuata dinamicamente da altre applicazioni e client Spring distribuiti. Per altre informazioni, vedere Configurare le impostazioni per il componente Eureka Server for Spring in Azure Container Apps. Modificare quindi tutti i client dell'applicazione in modo che usino il Load Balancer Spring Client. Spring Client Load Balancer consente al client di ottenere gli indirizzi di tutte le istanze in esecuzione dell'applicazione e di trovare un'istanza che funzioni se un'altra istanza viene danneggiata o non risponde. Per altre informazioni, vedere Spring Tips: Spring Cloud Load Balancer nel blog di Spring.

• Invece di rendere pubblica l'applicazione, è consigliabile aggiungere un'istanza di Spring Cloud Gateway . Spring Cloud Gateway offre un singolo endpoint per tutte le applicazioni distribuite nell'ambiente Azure Container Apps. Se Spring Cloud Gateway è già distribuito, assicurarsi che una regola di routing sia configurata per instradare il traffico all'applicazione appena distribuita.

• Prendere in considerazione l'aggiunta di un server di configurazione Spring Cloud per gestire centralmente e controllare la configurazione del controllo della versione per tutte le applicazioni Spring Cloud. Creare prima di tutto un repository Git per ospitare la configurazione e configurare l'istanza dell'app per usarla. Per altre informazioni, vedere Configurare le impostazioni per il componente Config Server for Spring in Azure Container Apps. Eseguire quindi la migrazione della configurazione seguendo questa procedura:

  1. All'interno della directory src/main/resources dell'applicazione creare un file bootstrap.yml con il contenuto seguente:

       spring:
         application:
           name: <your-application-name>
     

  2. Nel repository Git di configurazione, creare un <file nome-tua-applicazione>.yml , dove your-application-name è lo stesso del passaggio precedente. Spostare le impostazioni dal file application.yml in src/main/resources al nuovo file creato. Se le impostazioni erano in precedenza in un file con estensione properties , convertirle prima in YAML. Per eseguire questa conversione, è possibile trovare gli strumenti online o i plug-in IntelliJ.

  3. Creare un file application.yml nella directory precedente. È possibile usare questo file per definire le impostazioni e le risorse condivise tra tutte le applicazioni nell'ambiente Azure Container Apps. Tali impostazioni includono in genere origini dati, impostazioni di registrazione, configurazione di Spring Boot Actuator e altro ancora.

  4. Effettua il commit e il push delle modifiche nel repository Git.

  5. Rimuovere il file application.properties o application.yml dall'applicazione.

• Prendere in considerazione l'aggiunta del componente gestito da Spring Admin per abilitare un'interfaccia amministrativa per le applicazioni web Spring Boot che espongono endpoint dell'actuator. Per altre informazioni, vedere Configurare il componente di amministrazione di Spring Boot in Azure Container Apps.

• Valutare la possibilità di aggiungere una pipeline di distribuzione per distribuzioni automatiche e coerenti. Le istruzioni sono disponibili per Azure Pipelines e per GitHub Actions.

• Considera l'uso delle revisioni delle app container, delle etichette di revisione e dei pesi del traffico in ingresso per abilitare l'implementazione blue-green, che consente di testare le modifiche del codice nell'ambiente di produzione prima che siano disponibili per alcuni o per tutti gli utenti finali. Per altre informazioni, vedere Blue-Green Deployment in Azure Container Apps.

• Prendere in considerazione l'aggiunta di associazioni di servizi per connettere l'applicazione ai database Azure supportati. Queste associazioni a servizi elimineranno la necessità di fornire le informazioni di connessione, incluse le credenziali, alle applicazioni Spring Cloud.

• Valutare la possibilità di abilitare lo stack di sviluppo Java per raccogliere le metriche di base di JVM per le applicazioni. Per ulteriori informazioni, consultare le metriche Java per le app Java in Azure Container Apps.

• È consigliabile aggiungere Azure Monitor regole di avviso e gruppi di azioni per rilevare e risolvere rapidamente le condizioni aberranti. Per altre informazioni, vedere Impostare gli avvisi in Azure Container Apps.

• Considerare la possibilità di replicare l'app attraverso le zone della regione abilitando la ridondanza tra zone di Azure Container Apps. Il traffico viene bilanciato e indirizzato automaticamente alle repliche se si verifica un'interruzione della zona. Per altre informazioni sulle impostazioni ridondanti, vedere Reliability in Azure Container Apps.

• Valutare la possibilità di proteggere Azure Container Apps da exploit e vulnerabilità comuni usando Web Application Firewall nel gateway applicazione. Per altre informazioni, vedere Protect Azure Container Apps con Web Application Firewall su Application Gateway.

• Se le applicazioni usano componenti Legacy di Spring Cloud Netflix, è consigliabile sostituirli con le alternative correnti, come illustrato nella tabella seguente:

  Eredità	Corrente
  Spring Cloud Eureka	Registro dei servizi Spring Cloud
  Spring Cloud Netflix Zuul	Spring Cloud Gateway
  Spring Cloud Netflix Archaius	Server di configurazione Spring Cloud
  Barra multifunzione di Spring Cloud Netflix	Spring Cloud Load Balancer (bilanciatore del carico lato client)
  Spring Cloud Hystrix	Spring Cloud Circuit Breaker + Resilience4J
  Spring Cloud Netflix Turbine	Micrometer + Prometheus