Microservices Architecture With Java, Spring, and MongoDB
Rate this tutorial
"Microservices are awesome and monolithic applications are evil."
If you are reading this article, you have already read that a million times, and I'm not the one who's going to tell
you otherwise!
In this post, we are going to create a microservices architecture using MongoDB.
The source code is available in these two repositories.
We are going to use Spring Boot and Spring Cloud dependencies to build our architecture.
We need several services to run this project. Let's talk about them one by one.
As you read this post, I suggest that you follow the instructions in the README.md file and start the service related to each section.
The first service that we need is a configuration server.
This service allows us to store all the configuration files of our microservices in a single repository so our
configurations are easy to version and store.
The configuration of our config server is simple and straight to the point:
It allows us to locate the git repository that stores our microservices configuration and the branch that should be
used.
Note that the only "trick" you need in your Spring Boot project to start a config server is the
@EnableConfigServer
annotation.A service registry is like a phone book for microservices. It keeps track of which microservices are running and where
they are located (IP address and port). Other services can look up this information to find and communicate with the
microservices they need.
A service registry is useful because it enables client-side load balancing and decouples service providers from
consumers without the need for DNS.
Again, you don't need much to be able to start a Spring Boot service registry. The
@EnableEurekaServer annotation
makes all the magic happen.The configuration is also to the point:
The last two lines prevent the service registry from registering to itself and retrieving the registry from itself.
The API gateway service allows us to have a single point of entry to access all our microservices. Of course, you should
have more than one in production, but all of them will be able to communicate with all the microservices and distribute
the workload evenly by load-balancing the queries across your pool of microservices.
Also, an API gateway is useful to address cross-cutting concerns like security, monitoring, metrics gathering, and
resiliency.
When our microservices start, they register themselves to the service registry. The API gateway can use this registry to
locate the microservices and distribute the queries according to its routing configuration.
Note that our API gateway runs on port 8080.
Finally, we have our MongoDB microservices.
Microservices are supposed to be independent of each other. For this reason, we need two MongoDB instances: one for
each microservice.
Note that in
the configuration files for the
company and employee services, they are respectively running on ports 8081 and 8082.
Note that the two microservices are connected to two different MongoDB clusters to keep their independence. The
company service is using the MongoDB node on port 27017 and the employee service is on port 27018.
Of course, this is only if you are running everything locally. In production, I would recommend to use two clusters on
MongoDB Atlas. You can overwrite the MongoDB URI with the environment variables (see README.md).
At this point, you should have five services running:
- A config-server on port 8888
- A service-registry on port 8761
- An api-gateway on port 8080
- Two microservices:
- company-service on port 8081
- employee-service on port 8082
And two MongoDB nodes on ports 27017 and 27018 or two MongoDB clusters on MongoDB Atlas.
Note that the employee service sends queries to the company service to retrieve the details of the employees' company.
This confirms that the service registry is doing its job correctly because the URL only contains a reference to the company microservice, not its direct IP and port.
And voilà! You now have a basic microservice architecture running that is easy to use to kickstart your project.
In this architecture, we could seamlessly integrate additional features to enhance performance and maintainability in
production. Caching would be essential, particularly with a potentially large number of employees within the same
company, significantly alleviating the load on the company service.
The addition of a Spring Cloud Circuit Breaker could also
improve the resiliency in production and a Spring Cloud Sleuth would
help with distributed tracing and auto-configuration.
If you have questions, please head to our Developer Community website where the MongoDB engineers and the MongoDB community will help you build your next big idea with MongoDB.