This blog post is first part of microservices with Spring Cloud series. In this post we are going to do a high level overview of mircoservice ecosystem with Spring Cloud. Will take a look into its main building blocks and will go through one of many possible setups.
First of all why do we need Spring Cloud? Well main propose of Spring Cloud is to provide tools for software engineers to quickly build services and applications.
Spring Cloud Application Example
Let’s imagine our business team decided that we need to build an application capable to process orders at large scale, so scaling up and down easily is one of the main requirements.
We spent some time brainstorming and came up with basic setup, which will allow us to scale quite easily by adding extra instances of Orders service when needed. System structure shown in an image below:
To better understand how the system works first we need to take a look what happens on startup – at the moment when all services are coming to life.
Application Startup Flow
- Spring Cloud Eureka Server starts.
- Spring Cloud Config Server starts and registers on Eureka server.
- All other services starts:
- Both instances of Orders Service starts, registers on Eureka, asks Eureka about available Config Server instances, pulls config from Config Server.
- Spring Cloud Gateway server service starts and registers on Eureka and same as Orders pulls its configuration form Config Server.
- Application is fully started and ready to work.
API Requests Processing
After system is up and ready to work. Request to GET a list of orders can be made to our application as in an application structure image.
Spring Cloud Gateway service will be the first one to get the request in our orders processing system. Since Gateway is an entry point of our application. It will be listening of incoming requests. Then Spring Cloud Gateway will do filtering, request mapping and decide if request is valid and should be passed to corresponding service or it should be blocked and exception thrown.
If Spring Cloud Gateway decides to pass the request to an application. It will call Eureka to get a list of available instances of that service and then load balance on that list, for example with a help of Ribbon.
GET /orders request will be sent to one of the orders service instances for processing. Service will do its job and send back a response to Gateway service and Gateway will forward it to an API caller.
We talked about the setup of this app and how it actually processes requests. Let’s take a look into each element of Orders processing system separately.
Eureka Server – service registry, keeps track of all available services in the system. When new service is started it registers on Eureka as available.
Config Server – centralised configuration storage. When new instance of a service is started service will pull its configuration from config server.
Gateway Service – application entry point, all API calls from outside will have to go through here. Blocked or forwarded to internal services depending on setup.
Orders Service – service responsible for business logic, request processing, executing CRUD operations in this application.
In this post we did high level overview of one possible Spring Cloud microservice application setup.
In flowing posts we will actually build Orders app and study each component in detail. Stay tuned…