Microservices, Spring Boot 2.5.7 and Spring Cloud 2020.0.4
There are many tutorials on working with microservices, Spring Boot and Spring Cloud and one of the best I’ve found so far was Piotr Mińkowski - here (https://piotrminkowski.com/2018/04/26/quick-guide-to-microservices -with-spring-boot-2–0-eureka-and-spring-cloud/)
The whole process is very well described and with lots of details but when trying to use newer Spring Boot libraries (2.5.7) and other dependencies, I came across some changes in the settings that made the project “break”.
After spending a few days studying and doing the settings, I decided to write this article for anyone who wants to take it as a base and get straight to the point.
I will not explain the whole concept involved, as Piotr described it very well, but I will point out the main changes and new implementations carried out using the most recent libraries.
Project Architecture
- admin-service — Spring Boot Admin for monitoring Spring Boot applications. Uses Spring Boot Actuator in the background.
- config-service — Spring Cloud Config Server for running configuration server in the `native` mode. The configuration files are placed on the classpath.
- discovery-service — Spring Cloud Netflix Eureka as an embedded discovery server.
- gateway-service — Spring Cloud Gateway acts as a gateway, bridging external communication and microservices.
- employee-service — Microservice that allows performing CRUD operation on the “in-memory” repository of employees.
- department-service — Microservice that allows performing CRUD operation on the “in-memory” repository of departments. It communicates with employee-service.
- organization-service — Microservice that allows performing CRUD operation on the “in-memory” repository of organizations. It communicates with both employee-service and department-service.
Spring Boot Admin
In Piotr’s original project, he didn’t use Sprint Boot Admin, but I decided to implement it. For those unfamiliar, Spring Boot Admin is a simple web solution for monitoring Spring Boot applications that use the Spring Boot Actuator module in the background.
2. Spring Cloud Config.
With this microservice, it is possible to centralize the settings of all other microservices (application.yml). When the “client” microservice is started, it looks for its respective settings.
In the original article, it was necessary to use the default bootstrap.yml or bootstrap.yml for the configuration of “client” applications, but as of Spring Boot 2.4.0 this configuration has been deprecated. It is now possible to point the Spring Cloud Config Server directly in application.yml.
spring:
application:
name: discovery-service
cloud:
config:
enabled: true
config:
import: optional:configserver:${CONFIG_SERVER:http://localhost:8088/}3. Service Discovery
There were no significant changes and the configuration was very similar to the original.
4. Spring Cloud Gateway
In the original article, we have two microservices performing the role of the gateway, one of them being an alternative to the use of SpringFox Swagger, where Spring Cloud Netflix Zuul was used as a gateway.
Here, I kept only using Spring Cloud Gateway and SpringFox Swagger version 3.0.0.
<properties>
<java.version>1.8</java.version>
<spring-cloud.version>2020.0.4</spring-cloud.version>
<springfox-version>3.0.0</springfox-version>
<spring-boot-admin.version>2.5.4</spring-boot-admin.version>
</properties><!--SpringFox dependencies -->
<dependency>
<groupId>io.springfox</groupId>
<artifactId>springfox-boot-starter</artifactId>
<version>${springfox-version}</version>
</dependency>
5. Microservices
There was no need for changes. The interesting thing about the original project is the use of Spring Cloud Feign to exchange information between microservices, facilitating the creation of interfaces and communication between them.
6. Docker
Implementation of the Dockerfile for each of the microservices and also the docker-compose for the upload of all synchronized microservices.
Here there were two challenges:
- The first one was to map each of the microservices and pass the specific hostname through configuration properties to the jar.
docker-composediscovery:
hostname: discovery
build: ./discovery-service/
environment:
- JAVA_OPTS=
-DADMIN_SERVER=http://admin:8090/
-DCONFIG_SERVER=http://config:8088/
ports:
- "8061:8061"
mem_limit: 512MB
healthcheck:
test: wget --no-verbose --tries=1 --spider http://localhost:8061/actuator/health || exit 1
interval: 10s
timeout: 5s
retries: 6
depends_on:
config:
condition: service_healthy
DockerfileFROM openjdk:8-jre-alpine
ENV APP_HOME /app
WORKDIR $APP_HOME
COPY target/*.jar /app/app.jar
ENV JAVA_OPTS=""
ENTRYPOINT ["sh", "-c"]
CMD ["exec java $JAVA_OPTS -jar app.jar"]
- The second one was to synchronously upload the microservices so that the dependent applications would not break.
discovery:
hostname: discovery
build: ./discovery-service/
environment:
- JAVA_OPTS=
-DADMIN_SERVER=http://admin:8090/
-DCONFIG_SERVER=http://config:8088/
ports:
- "8061:8061"
mem_limit: 512MB
healthcheck:
test: wget --no-verbose --tries=1 --spider http://localhost:8061/actuator/health || exit 1
interval: 10s
timeout: 5s
retries: 6
depends_on:
config:
condition: service_healthy
gateway:
hostname: gateway
build: ./gateway-service/
environment:
- JAVA_OPTS=
-DADMIN_SERVER=http://admin:8090/
-DCONFIG_SERVER=http://config:8088/
-DEUREKA_SERVER=http://discovery:8061/eureka/
ports:
- "8060:8060"
mem_limit: 512MB
healthcheck:
test: wget --no-verbose --tries=1 --spider http://localhost:8060/actuator/health || exit 1
interval: 10s
timeout: 5s
retries: 6
depends_on:
discovery:
condition: service_healthyThis was my first article and I hope it will be useful for anyone looking for microservices development references using newer versions of the libraries.
The complete code can be found in the repository:
