This guide describes how to set up a Spring Boot microservice and integrate it in the microservice system landscape.
Content
| Table of Contents |
|---|
Requirements
A basic understanding of building an application with Spring Boot and building Java projects with Maven is required.
Dependencies
| Anchor | ||||
|---|---|---|---|---|
|
The following dependencies are necessary to be able to integrate a Spring Boot microservice in the system landscape.
spring-boot-starter-actuator
(https://spring.io/guides/gs/actuator-service/)
|
With this dependency, various services and endpoints are available for managing and monitoring the application in a productive system. This includes the endpoint for the health check that the admin-service uses to get the current status of a service in the system.
jolokia-core
|
Jolokia is an HTTP/JSON bridge for remote JMX access. This dependency is needed to be able to access a services's JMX beans from the admin-service user interface.
spring-cloud-starter-config
(https://cloud.spring.io/spring-cloud-config/)
|
This dependency makes it possible for the service to get its configuration from the config server. The config server keeps provides all relevant configurations for the microservices system ready globally. Currently, the config server is integrated in the service-manager (Argus). When started, a service receives so-called profiles, which tell the service which configurations it must get from the config-server. For example, if a service is started with the prod profile, it gets the application-prod.yml from the config server and gets the settings configured therein.
The goal here is to use the same configuration for all services, or for a group of services, so that it does not have to be configured for each service. To do so, you can use a central config-server that knows the configurations of the entire system (for all services) and provides these using REST. Thus, any service that knows where its config server is, can get its configuration there.
The following parameter tells a service where it can reach its config server.
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
...
globalEnvironment:
SPRING_CLOUD_CONFIG_URI: "http://127.0.0.1:${server.port}${spring.cloud.config.server.prefix}"
SPRING_CLOUD_CONFIG_USERNAME: "${security.user.name}"
SPRING_CLOUD_CONFIG_PASSWORD: "${security.user.password}"
... |
spring-cloud-starter-eureka
(https://cloud.spring.io/spring-cloud-netflix/)
|
This dependency delivers the requirements a service must meet to be able to sign in to the Discovery Service. The following configuration class must be available in your service.
...
The configuration parameter server.port specifies at which port the service should be started (see also Overview of Microservices). The port is also used as spring.application.index. The spring.application.name is the service name with which it signs in to Discovery. If multiple services have the same name, the Discovery Service treats them as a service group, even if the instances are running on different hosts and ports. However, if you plan to have the same service running with different configurations for different applications in a system landscape, then these should have different names. One example would be to use the gateway service once with NTLM authentication and once with basic authentication.
| Anchor | ||||
|---|---|---|---|---|
|
Configuration Files
The two most important configuration files are bootstrap.yml and application.yml. In a service, both should be in the directory src/main/resources.
The main difference between the two is that the properties of bootstrap.yml are loaded before those of application.yml. Some properties must be available earlier, and are thus configured in bootstrap.yml. An example is the spring.cloud.config properties, as well as server.port and spring.application.name. For a service to be able to get its configuration from a config server, it must know where it can get this configuration before loading it. In other words, it must know where the config server is. In addition, the service must know its name, since the configuration files of format ${spring.application.name}-prod.yml are loaded in addition to the profile configurations. For more information, see the spring cloud website.
Examples
You can use the following configuration files as templates.
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
# tell eureka where it gets status and health information
eureka.instance.status-page-url-path: /manage/info
eureka.instance.health-check-url-path: /manage/health
# define the instanceId pattern for eureka
eureka.instance.metadata-map.instanceId: ${spring.application.name}:${spring.application.index:${server.port}}
# tell your service where the eureka instance is running
eureka.client.service-url.defaultZone: http://${APPLICATION_DOMAIN:${COMPUTERNAME:localhost}}:7261/eureka/ |
Profiles
Which profiles are used to start a service is defined in the template.yml file of the services. The entries in template.yml are added to the servicewatcher configuration by the SAM tool, and imported after the service manager is (re)started.
The services profiles determine which programmatic configurations get loaded and which configuration files are gotten from the config server (part of the servicewatcher). If, for example, a service with the profile cloud is started, it gets the configuration from the application-cloud.yml file of the config server. In addition, configuration classes with the annotation @Profile("cloud") are loaded. For more information, see "spring-cloud-starter-eureka").
Links
- Jolokia
- Spring Cloud Config
- Spring Cloud Config - Client Side Usage
- Spring Cloud Netflix
- Spring Boot features - Profiles
- Service Registration and Discovery
- Spring Cloud Context: Application Context Services
...