Skip to content

Latest commit

 

History

History
387 lines (282 loc) · 17.1 KB

README.md

File metadata and controls

387 lines (282 loc) · 17.1 KB
Raw

Badges

Java CI

Best Practices of a Microservice Architecture with Spring Cloud, React, CI, CD and IaC

This repository is Dealer Management Systems based on a microservices architecture.

The architecture supports the following technologies:

  • Frameworks - Spring Boot, Spring Cloud, Feign, Eureka, Resilience4j.
  • UI - React Native or React Native Web to build as a mobile app or hybrid app (web + mobile)
  • Firebase, AWS Amplify, or Hasura (using GraphQL subscriptions) to send messages in realtime
  • Cloudinary or Firebase storage for sending messages with image or video content
  • Serverless functions like AWS Lambda or Firebase Functions for notifications
  • Cloudinary or Firebase storage for uploading pictures or video
  • Algolia for lightning-fast vehicle searching
  • Databases - H2, MySQL, MariaDB, PostgreSQL, MongoDB
  • API Management : Spring REST Docs, Swagger
  • Security: JWT (JSON Web Token) with OIDC, OpenID Connect with MITREid Connect, OAuth 2.0, “UAA” (User Account and Authentication) server.
  • Message brokers - Apache Kafka, RabbitMQ, and Redis Streams
  • Services communicate asynchronously using domain events, and command/reply messages.
  • Cloud - AWS, Pivotal Cloud Foundry (PCF), Google Compute Platform (GCP), OpenStack, VMware vSphere, Heroku, Netlify
  • Server Side - Spring Boot, Spring Security, Maven, Hibernate, Liquibase, Cucumber, ArchUnit, Gatling, Elasticsearch, Kafka, Elastic Stack, Prometheus
  • Client Side - HTML5, Bootstrap, TypeScript, Angular, React.
  • CI / CD - Jenkins, Travis CI, Github Workflows, Docker, Docker Compose, Kubernetes, Minikube, Minishift, OpenShift, Jenkins X, KOTS, ECS (Elastic Container Service), EKS (Elastic Kubernetes Service)

The Key Requirements

  • Maximize team autonomy.
  • Optimize for development speed.
  • Focus on automation (Automate everything).
  • Provide flexibility without compromising consistency.
  • Built for resilience.
  • Simplified maintenance.
  • Application portability.
  • Application auto-scaling.
  • Centralized platform administration.
  • Centralized logging.
  • Dynamic routing.
  • Application health management.
  • Integration with external logging components like Elasticsearch and Logstash.
  • Role-based access for deployed applications.
  • Provision for vertical and horizontal scaling.
  • Infrastructure security.
  • Support for various IaaS providers.

Twelve-factor application guide

  1. Codebase One codebase tracked in VCS, many deploys. One app has a single code base and its tracked by a version control system like Git, Subversion, Mercurial, etc. You can do many deployments (from the same code base) to development, testing, staging and production environments.

  2. Dependencies. Explicity declare and isolate dependencies. Some times your environments don’t have internect connection (if is a private system), so you need to think about packaging your dependencies (jars, gems, shared-libraries, etc) or if you have an internal repository of libraries, you can declared manifest like poms, gemfile, bundles, etc. Never rely that you will have everything in your final environment.

  3. Configuration. Store config in the environment. You should’t hardcode anything that varies. Use the environment variables or a configuration server.

  4. Backing Services Treat backing services as attached resources. Connect to services via URL or configuration.

  5. Build, Release, Run Strictly separate build and run stages. Related to a CI/CD (Continuous Integration, Continuous Delivery)

  6. Processes Execute the app as one or more stateless processes. Processess should not store internal state. Share nothing. Any necessary state should be considered as a Backing Service.

  7. Port binding Export services via port port binding. Your application is self-container, and these apps are exposed via port binding. An application can become another App’ service.

  8. Concurrency Scale out via the process model. Scale by adding more application instances. Individual processes are free to multithread.

  9. Disposability Maximize robustness with fast startup and graceful shutdown. Processes should be disposable (remember they are stateless). Fault tolerant.

  10. Environment parity. Keep development, staging and production environments as similar as possible. This is a result of High Quality, ensures continuous delivery.

  11. Logs Treat logs as event streams. Your apps should write to stdout. Logs are streams of aggregated, time-ordered events.

  12. Admin processes Run admin and managemenr tasks as one-off processes. Run admin processes on the platform: DB migrations, one time scripts, etc.

Architecture

The following diagram shows the targert platform architecture.:

Targert platform architecture

Since an auto dealership application uses the Microservice architecture pattern for vehicle details data is spread over multiple services. For example,

  • Vehicle Service - basic information about the vehicle
  • Transaction service - purchase history for vehicle, vehicle price
  • Dealership service - vehicle availability,Order processing, stock

Consequently, the code that displays the vehicle details needs to fetch information from all of these services.

Each service is:

  • 🔸 Highly maintainable and testable enables rapid and frequent development and deployment.

  • 🔸 Loosely coupled with other services - enables a team to work independently the majority of time on their service(s) without being impacted by changes to other services and without affecting other services.

  • 🔸 Independently deployable - enables a team to deploy their service without having to coordinate with other teams

  • 🔸 Capable of being developed by a small team - essential for high productivity by avoiding the high communication head of large teams.

  • 🔸 Services communicate using either synchronous protocols such as HTTP/REST or asynchronous protocols such as AMQP.

  • 🔸 Services can be developed and deployed independently of one another.

  • 🔸 Each service has its own database in order to be decoupled from other services.

  • 🔸 Data consistency between services is maintained using the Saga pattern.

  • 🔸 Client-side Discovery pattern or Server-side Discovery pattern to route requests to available service instances.

  • 🔸 The API Gateway authenticate the user and pass an Access Token containing information about the user to the services

  • 🔸 API Gateway use a Circuit Breaker to invoke services 🔸 API gateway often implements the API Composition pattern.

  • 🔸 Asynchronous Java API + Reactive Programming Model.

  • 🔸 Hystrix Fault Tolerance.

Tutorials https://rcherara.ca/

Using patterns

  • Service Discovery & Service Registry : Eureka
  • Load balancing : Spring Cloud Loadbalancer
  • Reliability Circuit-breaking and Fault-tolerance : Resilience4j, Istio, Service Mesh.
  • API Gateway : Spring Cloud Gateway
  • Externalized configuration : Spring Cloud Config
  • Failure- and latency-aware, load balancing, Cluster failover and Retry
  • Distributed tracing : Spring Cloud Sleuth.
  • Hexagonal Architecture (Ports and Adapters Pattern)
  • Consumer Driven Contract : Spring Cloud Contract.
  • Security : Access Token with Okta, Spring Cloud Security
  • Observability :
    • Log aggregation : AWS Cloud Watch
    • Application metrics - instrument a service’s code to gather statistics about operations
    • Audit logging - record user activity in a database
    • Distributed tracing - Zipkin, Sleuth and ELK Stack
    • Exception tracking - Sentry, TrackJS, Raygun and Airbrake.
    • Health check API : EurekaClient, Spring Boot Admin and Spring Boot Actuator
    • Log deployments and changes : GitHub, AWS CloudTrail and LogDNA.
  • Deployment patterns :
    • Service instance per Container - Dockerfile and DockerComposite
    • Serverless deployment - deploy a service using serverless deployment platform
    • Service deployment platform - deploy services using a highly automated deployment platform that provides a service abstraction
  • Transactional messaging:
  • Data management :
    • Database per Service - each service has its own private database
    • Domain event - publish an event whenever data changes
    • Event sourcing - persist aggregates as a sequence of events

Building and running the application

This is a Maven project. However, you need to have installed :

  • Java Development Kit >= 11
  • React "^16.13.1"
  • Docker
  • Maven
  • Kubernates CLI
  • Minikube
  • Minishift
  • Ansible
  • Jenkins

The details of how to build and run the services depend slightly on whether you are using

  • SaaS (Software as a Service)
  • IaaS (Infrastructure as a service)
  • PaaS (Platform as a Service)
  • Local

Building and running using SaaS

First, must sign up to get your credentials in order to get free access to the SaaS version.

Next, build the application

  $ git clone https://github.com/rcherara/rcherara-spring-cloud-microservice.git
  $ cd rcherara-spring-cloud-microservice
  $ mvn install

Next, you can launch the services using Docker Compose:

 $ docker-compose up -d

Modules:

  • config-service
  • discovery-service
  • gateway-service
  • config-repo
  • vehicle-service
  • vehicle-ui-web
  • vehicle-ui-mobile
  • dealership-service
  • transaction-service
  • admin-dashboard
  • Shell Scripts files (startRabbit, startDevVault, set-local-env-git, install-letsencrypt-cert, create-services, create-release-branch)
  • RabbitMq
  • Kafka
  • UI React
  • UI AngularJS
  • CI / CD - Jenkins
  • CI / CD - Github Workflows
  • CI / CD - Travis CI
  • CI / CD - Kubernetes (config, configmap, deployment, service, support-bundle, replicated-app)
  • CI / CD - Docker, Docker Compose
  • CI / CD - Jenkins X
  • Auth-server
  • IaC

Important endpoints

Run locally with Maven, Visual Studio Code, STS, Eclipse or IntelliJ:

👉 Gateway http://localhost:8080
👉 Eureka Discovery Dashboard http://localhost:8761
👉 Config Server http://localhost:7761
👉 Spring Admin Dashboard http://localhost:9761
👉 Vehicle service http://localhost:8081
👉 Dealership service http://localhost:8082
👉 Transaction service http://localhost:8083
👉 RabbitMq (username/password: guest/guest) http://localhost:15000

Run with docker-compose:

👉 Gateway http://localhost:5080
👉 Eureka Discovery Dashboard http://localhost:5761
👉 Config Server http://localhost:5760
👉 Spring Admin Dashboard http://localhost:5761
👉 Vehicle service http://localhost:5081
👉 Dealership service http://localhost:5082
👉 Transaction service http://localhost:5083
👉 RabbitMq (username/password: guest/guest) http://localhost:15000

Spring Cloud Config Server

Spring Cloud Config Server offers the following benefits:

  • HTTP resource-based API for external configuration (name-value pairs or equivalent YAML content)

  • Encrypt and decrypt property values (symmetric or asymmetric)

  • Embeddable easily in a Spring Boot application using @EnableConfigServer

Spring Cloud Config Client

Spring Cloud Config Client lets you:

  • Bind to the Config Server and initialize Spring Environment with remote property sources.

  • Encrypt and decrypt property values (symmetric or asymmetric).

  • @RefreshScope for Spring @Beans that want to be re-initialized when configuration changes.

Use management endpoints:

  • /env for updating Environment and rebinding @ConfigurationProperties and log levels.
  • /refresh for refreshing the @RefreshScope beans.
  • /restart for restarting the Spring context (disabled by default).
  • /pause and /resume for calling the Lifecycle methods (stop() and start() on the ApplicationContext).

Bootstrap application context: It binds to the Config Server and decrypts property values.

Using the Swagger UI

The services are Swagger "enabled".

Open the url http://${DOCKER_HOST_IP}:/swagger-ui.html

All Swagger Resources(groups) : http://localhost:/swagger-resources Swagger UI endpoint: http://localhost:/swagger-ui.html Swagger docs endpoint: http://localhost:/v2/api-docs

Monitor services configuration

  • Dealership-service : curl -s http://localhost:/monitor/dealership-service | jq '.'
  • Discovery-service. : curl -s http://localhost:/monitor/discovery-service | jq '.'
  • Gateway-service. : curl -s http://localhost:/monitor/gateway-service | jq '.'
  • Transaction-service. : curl -s http://localhost:/monitor/transaction-service | jq '.'
  • Vehicle-service.yml. : curl -s http://localhost:/monitor/vehicle-service | jq '.'

Build and run service

Before you start

  1. Be sure to clone the project with the command: git clone --recurse-submodules
  2. Install Docker along with Docker Compose.
  3. Build the project: mvn clean package -DskipTests
mkdir rcherara
cd rcherara
git clone --recurse-submodules <url>
cd rcherara-spring-cloud-microservice
mvn clean package -DskipTests

Vehicle service

To run locally:

$ cd vehicle-service
$ java -jar target/vehicle-service-0.0.1.BUILD-SNAPSHOT.jar

Dealership service

To run locally:

cd dealership-service
java -jar target/dealership-service-0.0.1.BUILD-SNAPSHOT.jar

Transaction service

To run locally:

cd transaction-service
java -jar target/transaction-service-0.0.1.BUILD-SNAPSHOT.jar

Gateway Server

To run locally:

cd gateway-service
java -jar target/gateway-service-0.0.1.BUILD-SNAPSHOT.jar

Discovery server

To run locally:

cd discovery-service
java -jar target/discovery-service-0.0.1.BUILD-SNAPSHOT.jar

Admin server

To run locally:

cd admin-service
java -jar target/admin-service-0.0.1.BUILD-SNAPSHOT.jar

Guides

The following guides illustrate how to use some features concretely:

Reference

  1. Microservice Architecture
  2. Spring Cloud Gateway
  3. Minishift– Cherara Reddag blog
  4. About Spring cloud security OAuth2
  5. Dive into Eureka – nobodyiam's blog
  6. About Spring cloud security OAuth2
  7. Synthesis-Based Software Architecture Design
  8. OAuth 2.0 Login
  9. OAuth 2.0 Resource Server
  10. Spring Cloud Security
  11. Spring Cloud Config Server
  12. Spring Cloud
  13. The Twelve Factors
  14. Maximize Observability of your CI/CD Pipeline with LogDNA
  15. Set Up A CI/CD Pipeline With Kubernetes
  16. Database Internationalization
  17. The Exagonal Architecture

Help me to get the app famous!

Eco-system for a car dealer based on a microservices architecture is open source and want to give to you the basics knowledge about cloud native application, architecture, DevOps with Docker, Kubernate Cloud, Spring Java, React Typescript and technologies. A star to this project will be appreciate!

Got questions?

Author

CHERARA REDDAH.