Spring Cloud Azure AutoConfigure Design
- 1. Goal
- 2. Modules
- 3. Developing guide
Spring Boot helps you to create Spring-powered, production-grade applications and services with absolute minimum fuss. When you use Azure Resources in your spring boot project, you may need to use Spring Cloud Azure, which help you to use Azure Resources much easier.
Our primary goals are:
- Provide uniform configuration of Azure SDKs. Auto-configure kinds of Azure SDK client.
- Provide Health Indicator / Metrics for each Azure Resource.
- Simplify dependency management.
Here is a quick overview of modules in Spring Cloud Azure:
- spring-cloud-azure-autoconfigure
spring-cloud-azure-autoconfigure attempts to deduce which beans a user might need. For example, if azure-security-keyvault-secrets is on the classpath, then they probably want an SecretClient to be defined. Auto-configuration will always back away as the user starts to define their own beans.
- spring-cloud-azure-starters
Starters are a set of convenient dependency descriptors that you can include in your application. You get a one-stop-shop for all the Azure Spring and related technology you need without having to hunt through sample code and copy(paste) loads of dependency descriptors. For example, if you want to get started using Spring and Azure Key Vault secrets, include the spring-cloud-azure-starter-keyvault-secrets dependency in your project, and you are good to go.
- spring-cloud-azure-actuator
Actuator endpoints let you monitor and interact with your application. Spring Cloud Azure Actuator provides HealthEndpoint and MetricsEndpoint of all kinds of Azure Resources,
- spring-cloud-azure-actuator-autoconfigure
This provides auto-configuration for actuator endpoints based on the content of classpath and a set of properties. Just like Spring Cloud Azure AutoConfigure, this will back away as the user starts to define their own beans
Click this link to edit Spring Boot modules' relationship
Spring Cloud Azure modules' relationship is just like Spring Boot, but we do not have spring-cloud-azure.
Click this link to edit Spring Cloud Azure modules' relationship
All group-id should be com.azure.spring.
We should contain these artifacts:
- spring-cloud-azure-autoconfigure
- spring-cloud-azure-starter
- spring-cloud-azure-starter-[service]-[module], Example: spring-cloud-azure-starter-keyvault-secrets
- spring-cloud-azure-actuator
- spring-cloud-azure-actuator-autoconfigure
- spring-cloud-azure-starter-actuator
- com.azure.spring.cloud.autoconfigure.[service].[module].implementation. Example: com.azure.spring.cloud.autoconfigure.keyvault.secrets.implementation
- com.azure.spring.cloud.actuator.implementation.
- com.azure.spring.cloud.actuator.autoconfigure.[service].[module].implementation. Example: com.azure.spring.cloud.actuator.autoconfigure.keyvault.secrets.implementation
xxx.implementation.xxx should not export in module-info.java. Classes in this package allow breaking change when upgrade minor / patch version
Configuration options of Spring Cloud Azure for Azures should contain two sources of configuration: One is the unified configuration which apply for all Spring Cloud Azure for Azures, that is, each starter can use the unified properties for its own features. The other is each starter's specific configuration which only work on one starter. For the auto-configuration of each starter, two configuration properties should be enabled.
Unified configuration aims to provide all fundamental and common configuration of all Azure SDK clients for each starter, which includes credential, environment, http client, retry options and so on.
The template of unified configuration is: spring.cloud.azure..
- Configuration-type is to classify the configuration according to its function, the value should be like credential, environment, httpclient and retry.
- Configuration-name is to describe each configuration option, like client-id and authority-host.
Unified configuration property class is com.azure.spring.autoconfigure.unity.AzureProperties.
For service configuration, it should contain all configurable options of that service's client. We divide service configuration into two parts: one is the fundamental configuration inherited from unified configuration, which allows users to configure them using the service configuration options instead of the unified. The other is specific configurations for that service's own features. The template of unified configuration is:
spring.cloud.azure...
- is the name of an Azure service, e.g., servicebus, storage...
- is to classify the unified configuration according to its function if needed, the value should be like credential, environment, httpclient and retry. For some services' properties, this is unnecessary, e.g., spring.cloud.azure.servicebus.connection-string
- is to describe each configuration option, like client-id and authority-host.
Service configuration property class should be under each service's configuration package: com.azure.spring.cloud.autoconfigure.[service].[module]
For legacy properties like azure.., we use EnvironmentPostProcessor to convert them to the active ones, and then put them into the application environment. When Key Vault secret starter is used, the preceding processor will be executed again after KeyVaultEnvironmentPostProcessor to convert legacy properties load from Key Vault if it exists.
We will provide necessary beans for each Azure Service.
- SyncClient
- AsyncClient
These artifacts should only contain a pom file, should not contain other files change readme or changelog. Just like spring-cloud-aws and spring-cloud-gcp.
These artifacts should only contain a pom file, should not contain other files change readme or changelog. Just like spring-cloud-aws and spring-cloud-gcp.