This post presents the basic architecture of an online flower shop in a microservices architecture. I have no intention to provide detailed information on each component on this post.
I do provide a working example of a microservices application based on Spring Cloud project. I also provide a basic explanation of the components' responsibilities and how they achieve that, which I believe is a good way to understand the microservices architecture.
Components
Store Front
storefront
folder on the repository.
- The Store itself, like a website (although here it's just an API) where a user buys flowers and stuff.
- Balances the requests to suppliers and carriers locally (client-side load-balancing) by fetching and caching Eureka server information (ribbon).
- Uses Hystrix to control timeout on methods that use other microservices.
- Uses Bulkhead (from Hystrix) to separate a group of threads for each operation managed by Hystrix.
- Controls the integration with other microservices (using states).
- RECEIVED: order created on the
storefront
microservice. - SUPPLIER_ORDER_CREATED: order incremented with information from the
supplier
microservice. - CARRIER_VOUCHER_CREATED: order incremented with information from the
carrier
microservice.
- RECEIVED: order created on the
- Integrates with the authentication server.
- Forwards authentication headers to other microservices with a RequestInterceptor bean.
Supplier
supplier
folder on the repository.
- Someone who provides products on different locations.
- Provides Orders to the
storefront
component. - Integrates with the authentication server.
Carrier
carrier
folder on the repository.
- Someone who delivers stuff to clients from the suppliers.
- Provides Vouchers to the
storefront
component. - Integrates with the authentication server.
Authentication Server
auth-service
folder on the repository.
- This is an OAuth server tying together Spring Security and Spring Cloud OAuth2.
- Spring Security configures a user (hardcoded =).
- Spring Cloud OAuth2 configures a client of the authorization server, the
storefront
(hardcoded =).
API Gateway
zuul-api-gateway
folder on the repository.
- Clients make requests for the API Gateway, which then redirects to the correct microservice for the request.
- Implemented with Netflix Zuul.
- Integrates (automatically) with Eureka to get microservices instances.
- Does client-side load balancing with Ribbon automatically.
Eureka server
eureka-server
folder.
- Handles service registry and discovery.
- Every component registers itself here.
- Balancing is on the client,
via a RestTemplate bean configured to use Eureka server as a client(this was replaced by the FeignClient. See older commits to understand how to configure a RestTemplate to work with Eureka Client). - Balancing is on the client through FeignClient, which is auto-configured on each application to balance requests when eureka client is being used.
Config Server
config-server
folder.
- Provides configuration to the microservices. The
config-repo
folder is used to store the configuration files.
Other Stuff
- I've configured to log to papertrail (a log aggregator as a service) and used Spring Cloud Sleuth to add a traceId to every user request, being able to trace the request across microservices.
- The logback.xml on each "domain" microservice does the magic. This will stop working after a while, so provide your own configuration for logback...
Hands-on!
- Clone/fork this GitHub repository.
- Import everything on STS.
- Provide the following configurations:
- configure the config-server
application.yml
file with at least thesearch-locations
property. You may change to the location of your own config repo on your local machine or use the commented configuration to use a github repository. - provide a MariaDB instance running with the following schemas already created: supplier; storefront;
- Note: you can configure the database, connection info and schema name on the configuration files on the config-server.
- configure the config-server
- Run each of them separately using
./mvnw spring-boot:run
on each folder OR the Boot Dashboard on STS.
Test Stuff
There's a cartRequests.jmx to be imported on JMeter and test Hystrix. Ask me if you want to know more about it.
There's also a insomnia_requests.json file to be imported on Insomnia and test all endpoints.
Notes
- commits to
master
tell the story of this project. You can follow here. - this implementation is based on two courses from Alura: this (in portuguese) and this (in portuguese).
- This is a work in progress.
- The cover image for this post is taken from the spring.io homepage (here).
Top comments (2)
Great article! You should also check resilience4j as a fault tolerance library instead of hystrix. (Hystrix is deprecated and is currently is maintenance mode.
Just added an issue to the repository: github.com/brunodrugowick/microser...
Will do it, for sure! Thanks, Vini!