API-Gateway ----------------> Port 9191
Department-Service ---------> Ports: 8080, 8082
Employee-Service -----------> Port 8081
Organization-Service -------> Port 8083
Config-Server --------------> Port 8888 (Spring Cloud Config)
Service Registry -----------> Port 8761 (Eureka Server)
Organization-Service -------> Port 8083
React-Frontend -------------> Port 3000
Zipkin Server ---------> Port 9411
curl -G https://start.spring.io/starter.zip -d dependencies=web,mysql,jpa,lombok -d type=maven-build -d groupId=info.josealonso -d artifactId=employee-service -o employee-service.zip
curl -G https://start.spring.io/starter.zip -d dependencies=web,mysql,jpa,lombok -d type=maven-build -d groupId=info.josealonso -d artifactId=department-service -o department-service.zip
http -v get http://localhost:8083/api/v1/organizations/test or
http -v get localhost:8083/api/v1/organizations/test or
http -v get :8083/api/v1/organizations/test
saveOrganization
http -v post :8083/api/v1/organizations id:=7 organizationName=ABCd organizationCode=ABC_23Y
organizationDescription="........"
getOrganizationByCode
http -v get :8083/api/v1/organizations/ABC_23Y
Only /info and /health endpoints are enabled by default.
- We need a mechanism to call other services without hardcoding their hostnames or port numbers.
- Since instances may come up and go anytime, we need some automatic service registration and discovery mechanism.
The @EnableEurekaClient annotation was removed in spring cloud 2022.0.0.
To run another instance of department-service
BASIC APPROACH
cd department-servicejava -jar -Dserver.port=8082 target/department-service-0.0.1-SNAPSHOT.jar
LOAD BALANCER APPROACH
Eureka Server provides the Spring Cloud load balancer library.
It provides a unified interface for a set of microservices so that clients no need to know the microservices internals. It centralizes cross-cutting concerns like security, monitoring or rate limiting.
- Route request.
- Load balancing.
- Security. Spring Cloud provides Spring Cloud Gateway to create an API Gateway.
-
No need to restart the microservice after modifying its configuration.
-
Externalized configuration.
Create a github repository: https://github.com/josealonso/config-server-repo
We do not want to restart the microservice whenever we change the configuration file.
Solution ---> call the Spring Boot Actuator /refresh API to reload the updated values from the Config Server.
Instead of calling the Refresh API for each microservice, a message broker is connected to the event generated by the API. All the microservices are subscribed to this event.
Message -----------> n --------> Config ------> Git repository
Broker microservices Server
Install and run RabbitMQ
docker pull rabbitmq:3.11.0
docker run --rm -it -p 5672:5672 rabbitmq:3.11.0
Testing it
GET http://localhost:8080/message GET http://localhost:8081/users/message
A POST call to http://localhost:8080/actuator/busrefresh will tell the message broker to broadcast the configuration changes to the respecting microservices.
Track the complete request across all the microservices, from start to end. Keep track of how much time the microservice will take to process the request. Trace id is the same for each request. Span id is the same for each microservice.
Spring Cloud Sleuth was used in Spring Boot 2.x projects.
The Spring Cloud Sleuth dependency would be added to the following projects: api-gateway, department-service and employee-service.
As a result, the traces would have the format:
[Service name, Trace id, Span id]
Zipkin is a widely used library.
- Fallback method
- Circuit breaker
3 states:
- closed ---> allows to flow the request between two microservices.
- open -----> that circuit is closed during a configurable time limit.
- half open ---> only certain number of calls are allowed. It goes to open state or to closed state based on the response.
- Retry
- Rate Limiter