Microservices (Part 5) — Design Patterns for Microservices(Proxy Pattern)
The proxy pattern is simply another variation of the Aggregator Pattern. In this pattern, the aggregation doesn't happen on the client side. A Separate Microservice will get invoked based on the requirement.
The difference,
Aggregator Pattern: Invokes multiple services to get the responses required by the application. Aggregation of data.
Proxy Pattern: No aggregation of data.
Let’s try to understand the Proxy pattern with the help of an example.
Think about a scenario where we have a large monolithic application and the management team decides to migrate it to the new Microservices architecture. We can use different software development methodologies to achieve this. If we use the Agile methodology,
- Start deploying the application part by part. That means one functionality after the other. It may take several months to complete the overall system.
- However, there may be instances where we need to change the previously deployed services. This can create problems.
Example: Consider the following scenario.
Assume that we have a Microservice to get Hotel Guest information. This information is retrieved bypassing the Guest Code.
However, with the upcoming changes, developers decided that it is better to retrieve Guest information with the help of “Guest ID” instead of “Guest code”.
Updated Requirement: Get information with the Guest ID instead of the Guest code.
We can implement this will the help of versioning.
Version 01: Pass Guest code.
Version 02: Pass Guest ID
However, we cannot deploy the system as it is. We have to use the Proxy pattern and create a separate Proxy service. All the consumers have to come through this proxy service. We can configure the proxy to route the request to the correct version by checking the particular field value (Guest code or Guest ID). This implementation helps to deploy services without disturbing the customer.
What about the service discovery?
Whenever we create a service, it's always better to use an external party to discover the service. Why?
Easily handle the infrastructure changes. The hostnames, IP addresses, etc can change in the Microservices architecture. We can implement a service discovery tool and configure the Proxy to communicate with this tool. Then the tool can provide the locations of the services to the Proxy. Consul by HashiCorp, WSO2 Governance Registry are some of the popular service discovery tools.
Important Points
- The proxy pattern implementation is similar to service chaining. This introduces the risk of cascading failure. This may result in blocked system resources and the failure of several services.
Solution,
Message Queues
It is basically a queue of messages sent between two applications. In other words, it contains a list of objects(in correct order) that needed to be processed. This helps to overcome cascading failure. But have to consider facts like queue failure before implementing the message queues. Therefore we need to have redundant mechanisms in this type of architecture.
- The developers must pay attention to the Thread pools before implementing the Proxy Pattern. That is because the incorrect implementation of threads can block certain services in the architecture. As a solution, the developers can use multiple thread pools or thread handover mechanisms.
- Timeout is also another important concept to the Proxy pattern. Consider a situation where we have a proxy service that directs traffic to 2 versions of a service. The timeout is important to make sure that one version will not affect the other version in case of failure.
I have used the following playlist by Mr.Krishntha Dinesh to gather the required information.
