Microservices are the kind of service-oriented architecture that works with heavy-load handling systems and was implemented by such giants as Google, Netflix, Amazon, and eBay. This term appeared in 2011 and is still a subject of interest.
Let’s take a closer look at the definition and characteristics of microservices, as well as the ways how they are applied in Java.
A microservice architecture relates to service-oriented architecture (SOA) that is used in systems with several independently deployable modules. Microservices differ in the degree of interconnection of modules; they are largely independent and particular. One server always equals to one business process.
Microservices offer an opportunity to use several programming languages and technologies, improve scaling, and reduce the amount of used memory. This is a helpful solution when the server can’t cope with the burden and consumes a lot of memory, or when more than one server is required.
Java is the best option for building microservices as it is a well-known programming language with a great number of appropriated lightweight and easy-to-use frameworks. Developers can use Spring, Spark, Swagger, Jersey, Dropwizard, Play, Restlet, Restx, or other frameworks at will.
Let’s see how the microservices architecture works in a web store. The system has several tasks: to register users’ profiles, take orders, and send the notification with the status of their order.
First, let’s consider the case if developers used a monolith architecture in this situation.
There are one server and one database. The system consistently performs all tasks and completes them one by one. Connections between the involved units are implemented with inside-code calls.
As a result, the sequence of system actions looks like this: security check, user registration, taking orders, sending the order confirmation, and finishing session.
There can be several problems in this case:
Even if developers duplicate the business logic and share the load between two similar servers with the help of a dynamic balancer, it won’t solve the problems with updating and program shutdown.
Let’s consider how developers can use microservices to build a web application with the same requirements. In this case, every independent server will implement a certain business function and the microservices architecture will consist of two steps.
1.Split the web application into microservices
Developers should single out independent microservices to deploy and maintain. In the case with a web application store, there are 3 servers that work with orders, 2 servers that are for user profiles, and 1 server that deals with notifications. The sync HTTP/REST or async AMQP protocols are used for communication between microservices.
This process requires the implementation of several frameworks and libraries.
First comes the realization of the gateway for the processing of customers’ requests. The gateway also deals with authentication and security, makes servers scalable and independent in deployment. The client side is free from storing server addresses.
After the gateway realization, it is the turn of the Zuul 2 framework. This framework makes it possible to use the profits of non-blocking HTTP calls.
Then let’s move on to the implementation of the Eureka server as a server discovery which will establish connections between users’ profiles and the order server. The Ribbon load balancer will work as a backup of a system and guarantee the most efficient usage of scaled users profile servers.
Hystrix, a latency and fault tolerance library, is necessary when the server is down or overloaded. In this case, the Hystrix library avoids requests from going into the void while the server is recovering.
For async messaging between the notification server and other servers, developers can use the message broker RabbitMQ.
Let’s check, what is going with problems that were detected in a monolith architecture of web application:
Now several independent servers ensure the work of the web application, and there is no serious problem visible for a client, such as slow preloading or system crushing. The system can redirect the requests or continue the work after the server is recovered.
Developers shouldn’t rewrite the entire system anymore. All parts of business logic are independent. It is enough to modify the necessary servers to add new functions, and the rest will remain unchanged.
Internal system processes remain invisible for clients because independent servers can scale. Developers can add new or scale available servers if it is needed, as well as modify several secondary functions if they work slowly.
Microservices are very useful for building complex web applications with multiple functions. This approach helps developers to avoid problems with loading and scaling, but excessive use of splitting can lead to negative consequences. That’s why to avoid any problems with the app implementation, it makes sense to turn to specialists in software development.