Developing Microservices Using Spring
This guide describes how to set up a Spring Boot microservice and integrate it in the microservice system landscape.
Content
Requirements
A basic understanding of building an application with Spring Boot and building Java projects with Maven is required.
Dependencies
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 provides all relevant configurations for the microservices system 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.
These declarations must be in a service's bootstrap.yml
. When the service is started,the Servicewatcher (Argus) overwrites the declarations with the configured settings as environment variables in the servicewatcher-sw.yml
.
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 annotation @Profile("cloud")
specifies that this configuration is only available when the service is started with the profile cloud. The annotation @EnableDiscoveryClient
activates the Netflix Eureka DiscoveryClient implementation, through which a service tries to sign in to the configured Discovery. Only when the service with the profile cloud is started can it sign in to Discovery. The corresponding configuration parameters should be added to the application.yml
file and may be overwritten in the system landscape with the application-cloud.yml
. When a service is started with the profile cloud, it automatically gets the application-cloud.yml
configuration from the config server. For more information, see "spring-cloud-starter-config".
A service must sign in to the Discovery Service, so that it can be integrated into the system landscape and communicate with other services (and they with it), even when the landscape grows. It is also important how a service signs in to Discovery. For this, the following parameters must be configured in bootstrap.yml
.
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.
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.
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