DEV Community

loading...
Cover image for Project Overview: the Basic Microservices Architecture with Spring Cloud

Project Overview: the Basic Microservices Architecture with Spring Cloud

brunodrugowick profile image Bruno Drugowick Originally published at drugowick.dev Updated on ・3 min read

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.
  • 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!

  1. Clone/fork this GitHub repository.
  2. Import everything on STS.
  3. Provide the following configurations:
    • configure the config-server application.yml file with at least the search-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.
  4. 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

Discussion (2)

pic
Editor guide
Collapse
viniciuslovato profile image
Vinicius Lovato

Great article! You should also check resilience4j as a fault tolerance library instead of hystrix. (Hystrix is deprecated and is currently is maintenance mode.

Collapse
brunodrugowick profile image
Bruno Drugowick Author

Just added an issue to the repository: github.com/brunodrugowick/microser...

Will do it, for sure! Thanks, Vini!