- About The Project
- Getting Started
- Catalog Microservice
- Customer Microservice
- Order Microservice
- Healthcheck Service
This is a simple proof of concept (POC) to introduce and verify some challenges redarging Microservices Architecture.
The main concept within this project is to implement an enviroment with some microservices in a context of an inventory system, however for this first release there are only 3 microservices, Catalog Microservice, Customer Microservice and Order Microservice, each one with its own database instance and the inter-communication between them happens only through asyncronous events.
This section should list any major frameworks/libraries used to bootstrap the project.
[ back to top ]
root
|
└── docker-compose.yml
└── MSPOC.Catalog.Service
| └── MSPOC.Catalog.Service.sln
| └── src
| | └── MSPOC.Catalog.Service.csproj (WebAPI net5.0)
| | └── Dockerfile
| | └── .dockerignore
| | └── nuget.config
| └── test
| └── MSPOC.Catalog.Service.UnitTest.csproj (xUnit)
|
└── MSPOC.CrossCutting
| └── MSPOC.CrossCutting.Service.csproj (ClassLib net5.0)
|
└── MSPOC.Customer.Service
| └── MSPOC.Customer.Service.sln
| └── src
| | └── MSPOC.Customer.Service.csproj (WebAPI net5.0)
| | └── Dockerfile
| | └── .dockerignore
| | └── nuget.config
| └── test
| └── MSPOC.Customer.Service.UnitTest.csproj (xUnit)
|
└── MSPOC.Events
| └── MSPOC.Events.Service.csproj (ClassLib net5.0)
|
└── MSPOC.Order.Service
| └── MSPOC.Order.Service.sln
| └── src
| | └── MSPOC.Order.Service.csproj (WebAPI net5.0)
| | └── Dockerfile
| | └── .dockerignore
| | └── nuget.config
| └── test
| └── MSPOC.Order.Service.UnitTest.csproj (xUnit)
|
[ back to top ]
We are using in this project a docker compose file in order to simplify the steps related with build and deploy all the microservices, as well as, the setup and exwcution of all the infrastructure resources such as the databases and rabbitmq.
All the docker images are available in DockerHub, including the 3 microservices images are available into my public personal repository.
docker pull ggodoi1986/mspoc.catalog.service
docker pull ggodoi1986/mspoc.customer.service
docker pull ggodoi1986/mspoc.order.serviceTo begin, after cloning the repository, in the base path there is a docker-compose.yml file, just execute the following docker command.
docker compose up -d --remove-orphansAfter executing we are gonna see that all the containers have been started, created and they are now available to be accessed.
[ back to top ]
Service responsible for the catalog items context, including all the catalog items management, such as enrollment, update and deletion.
When running locally, this microservice's API is available at the following address http://localhost:5000.
This microservice uses the MassTransit lib in order to implement the pub/sub pattern for the releated events, accordingly the official documentation available in the following links :
| Syntax | Type | Description |
|---|---|---|
| CatalogItemCreated | Published | When a new catalog item is created |
| CatalogItemUpdated | Published | When a catalog item is updated |
| CatalogItemDeleted | Published | When a catalog item is deleted |
| CatalogItemLowQuantity | Published | When a catalog item quantity reachs out the quantity of 10 units |
| OrderCreated | Consumed | When a new order is created, the catalog item quantity is subtracted |
| OrderUpdated | Consumed | When an order is update, the catalog item quantity is updated |
| OrderRemoved | Consumed | When an order is delete, the catalog item quantity is incremented |
Accordingly the RabbitMQ official documentation, a message is never sent directly to a queue, it is sent to an exchange instead, which is a routing object, thus there is the Primary Exchange.
In order to implement the pub/sub pattern MassTransit creates the Secondary Exchange, which is bind to a destination queue, and there are individual queues for each published event and subscribed consumer.
[ back to top ]
Service responsible for the customer context, including all the customers management, such as enrollment, update and deletion.
When running locally, this microservice's API is available at the following address http://localhost:5001.
This microservice uses the MassTransit lib in order to implement the pub/sub pattern for the releated events, accordingly the official documentation available in the following links :
| Syntax | Type | Description |
|---|---|---|
| CustomerCreated | Published | When a new customer is created |
| CustomerUpdated | Published | When a customer is updated |
| CustomerDeleted | Published | When a customer is deleted |
| OrderCreated | Consumed | When a new order is created, the customer order history is created |
| OrderUpdated | Consumed | When an order is update, the customer order history is updated |
| OrderDeleted | Consumed | When an order is delete, the customer order history is deleted |
Accordingly the RabbitMQ official documentation, a message is never sent directly to a queue, it is sent to an exchange instead, which is a routing object, thus there is the Primary Exchange.
In order to implement the pub/sub pattern MassTransit creates the Secondary Exchange, which is bind to a destination queue, and there are individual queues for each published event and subscribed consumer.
[ back to top ]
Service responsible for the order context, including all the orders management, such as enrollment, update and deletion.
When running locally, this microservice's API is available at the following address http://localhost:5002.
This microservice uses the MassTransit lib in order to implement the pub/sub pattern for the releated events, accordingly the official documentation available in the following links :
| Syntax | Type | Description |
|---|---|---|
| OrderCreated | Published | When a new order is created |
| OrderUpdated | Published | When an order is updated |
| OrderDeleted | Published | When an order is deleted |
| CatalogItemCreated | Consumed | When a new catalog item is created, the local catalog registry is created |
| CatalogItemUpdated | Consumed | When a catalog item is updated, the local catalog registry is updated |
| CatalogItemDeleted | Consumed | When a catalog item is deleted, the local catalog registry is deleted |
| CustomerCreated | Consumed | When a new customer is created, the local customer registry is created |
| CustomerUpdated | Consumed | When a customer is updated, the local customer registry is updated |
| CustomerDeleted | Consumed | When a customer is deleted, the local customer registry is deleted |
(*) Within this microservice we are using a database for catalog and customer, but the difference from the original ones, is that within the order context these entities are simplified, only storaging the minimal data consumed by order microservice.
Accordingly the RabbitMQ official documentation, a message is never sent directly to a queue, it is sent to an exchange instead, which is a routing object, thus there is the Primary Exchange.
In order to implement the pub/sub pattern MassTransit creates the Secondary Exchange, which is bind to a destination queue, and there are individual queues for each published event and subscribed consumer.
[ back to top ]
To monitor the microservices health, it is been used the Xabaril/HealthChecks lin. It provides tools to monitor the microservice as well as its dependencies, such as the database and the message broker, so we are monitoring the health of mongo and rabbitmq.
It also provides a friendly dashboard where is presented all the monitoring information in real-time, as featured in the image below. When running locally, this dashboard is available at the following address http://localhost:8080/healthchecks-ui.
[ back to top ]