Skip to content

Joseph-ljx/Cloud_Library_Microservices_System

Folders and files

NameName
Last commit message
Last commit date

Latest commit

Ā 

History

8 Commits
Ā 
Ā 
Ā 
Ā 
Ā 
Ā 
Ā 
Ā 
Ā 
Ā 
Ā 
Ā 
Ā 
Ā 
Ā 
Ā 

Repository files navigation

Cloud_Library_Microservices_System

Programming Languages:

JavaScript MySQL

Framework:

Express.js NodeJS Yarn NPM

Cloud:

Docker AWS Kubernetes

Tool:

Apache Kafka Postman JWT

šŸ› ļø Introduction

This project entails the development of a robust backend system designed to facilitate efficient management of customer profiles and book information within a library setting. To ensure optimal performance, the project has been deployed on the AWS cloud and leverages the power of EKS (Kubernetes) for seamless scalability, enhanced availability, improved security, and increased operational efficiency. Additionally, the project incorporates a range of essential tools and adheres to crucial design principles to elevate various aspects of the system's functionality.

Main Tasks:

  • Retrieve a book/customer profile information
    • Handle logic problems/exceptions like NULL return, does not exist, illegal, missing, or malformed input.
    • Handle requests from both email search or user ID search.
  • Add a new book/customer to the system based on formatted structure of data
    • Handle logic problems/exceptions like already exist, illegal, missing, or malformed input, etc.
  • Update a book/customer inside the system
    • Handle logic problems/exceptions like not founded, illegal, missing, or malformed input, etc.
  • Hanle customer requests based on different device types (mobile/pc).
  • Provide health checks (health check endpoints) for both AWS EC2 instances and EKS Kubernetes pods.
  • Provide relevent/related books search for a given book ISBN or name (recommendation system). Handling problems like no recommendation books founded, external service time out, internal server break down, etc. Formatted the results.
  • JWT token information verification.
  • Formatted return results according to different customer needs & endpoints.
  • ...

API Endpoints:

There are over 30+ enpoints of Http request handling (please refer to the code for detail) :

  • Http Method: GET, POST, PUT, DELETE
  • Handling of the requests will depend on over 20+ services requirements.
  • Response mainly included (here I will only list the most important http response code for main functionalities)
    • 200: Success.
    • 201: Successful creation.
    • 204: Success with empty response body.
    • 400: Illegal request.
    • 404: Does not exist.
    • 422: Already exist in the database.
    • 500: Internal server error.
    • 503: Server unavailable.
    • 504: Gateway time out.
    • ...

EKS (Kubernetes) System Logic & Diagram

  • A namespace called "book-store"
System Design

EKS Configuration for number of replicas (deployment)

  • 2 pod instances for Customer BFF.
  • 2 pod instances for Customer service.
  • 2 pod instances for Book BFF.
  • 1 pod instance 2 pod instances for Book service.
  • 1 pod instance for CRM

Deployment and Services

  • Load balancer services: link corresponding pods of deployment.
  • Deployment: Obtained latest version of Docker images from Dockerhub, run and operate as background program...

Health Monitoring

  • A liveness probe as an http endpoint: GET /status that responds with a plain text message saying ā€œOKā€. (Plain text message means the response should have Content-Type: text/plain) of all REST services with same end point.

AWS VPC & Deployment

AWS VPC design

Implementations

Circuit Breaker:

  • The call to the external service shall not significantly delay the response to the (hypothetical) end user.
  • Thus, the Book service shall get a response from the recommendation engine within 3 seconds of the request being sent (timeout can be set when making an http call using Axios).
  • The circuit to the open state upon the first call that times out.
    • For that first call that times out, your service should respond with error 504.
    • When the circuit is open the service should automatically return error 503 right away to any requests within 60 seconds of opening the circuit.
  • The first request that arrives at the Book service after 60 seconds elapsed since the circuit was open will be different:
    • Service should try to reach the external service.
    • If it responds within 3 seconds, then you move the circuit back to the closed state, and your service’s response code is 200.
    • If it does not respond within 3 seconds, the service’s response code is 503, the circuit remains open, and start another 60-second window until the next attempt.

Circuit Breaker

K8S volume:

  • A directory, possibly with some data in it, which is accessible to the containers in a pod (mounted by the Book service pod).
  • Used emptyDir type to store the circuit breaker state.

Kafka:

  • Asynchronous services and data pipline.
  • If a request to create a customer is valid, the Customer service (kafka producer) sends a message to a topic on Kafka. The message is in JSON format and contain the same attributes used in the REST service response.
  • Another asynchronous service (CRM in the runtime architecture diagram) is implemented. It is a Kafka consumer that shall connect to the Kafka topic mentioned above.
  • Upon receiving the message, the CRM service (also dockerized and deployed to the EKS cluster using the same mechanisms used for the REST services with only 1 replica) parses the content and send an email to the newly registered customer.
  • I use Amazon SES API and also (Nodemailer + Gmail app authorization) to send the email.
Screenshot 2023-06-06 at 17 18 40

BFF (Backend For Frontend) Services:

This will arouse the services to handle the request and response from client differently:

  • Single Responsibility Principle.
  • Process (Preprocess) the API request and forward to the service endpoints.
  • Formatted the response results transmitted from the service endpoints, performing post data prume.

The capability of the BFF will grow over time.

  • Identify the type of client making the request (desktop or mobile) and configure the response accordingly. The HTTP request to the BFF services contains the "user-agent" header, which specifies the client device (mobile or desktop).
  • Each BFF is associated with 1 or more services.
  • Each BFF is going to verify the corresponding JWT token for each API calling.

JWT Token (Middleware verification):

  • All requests to the BFF services will contain a valid JWT token (encoded with the HS256 algorithm).
  • Ensure the security for stateless, cross-domain microservices authorization.
  • Process and obtained a valid JWT tokwn by outsource tools.
  • The BFF will verify the JWT Token:
    • Correct format.
    • Correct information.
    • In necessary conditions (timestamps, volume...).
JWT

Databases

MySQL (workbench, command clint)

  • Local connection.
  • Local testing (development environment)
  • SQL script test

AWS RDS (DB enginer contains MariaDB, PostgreSQL, MySQL...).

  • Load balancer: balancing load for different replicas for scalability, high performance, high availability, fault tolerance, etc.
  • Security groups: controlling access
  • Subnets: secure acess control.
  • EC2 entities: exploit instances for connection, status control, SQL execution.
  • Master-slave (read-write) mechanisms: adopt write replica as the main replica, ensure high availability and scalability.
  • ...

PuTTY & Linux

  • Distributed System Control.
  • EC2 instances management.
  • Scripts execution.

Test Data:

  • over 200 tuples of mock testing data entries
  • ETL simulation

About

The is the repository for my cloud base microservices system: a library backend project

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published