PROXY DESIGN PATTERN IN MICROSERVICES
In Proxy pattern, all the requests are transferred transparently to a service that invokes a different microservice. Here, the actual consumer is not aware of the service that is being called internally.
There are two categories of proxy service pattern namely;
- Dumb Proxy: Responsible for delegating a request to another service.
- Smart Proxy: Responsible for applying transformation, logic, filtering, rejection before delegating a request to another service.
Consider the following example.
Assume you have an Employee Service. You are going to deploy a new service or a new version of that particular service. Your consumers already consume the version 1 of that service. And the consumers pass Employee Code although they need to pass Employee ID for the new service.
If you deploy your service into production / if you update your current service, your consumers will break at the meantime because they do not know how to pass Employee ID.
✹ This is the place where Proxy pattern will fit.
You can create a separate proxy service. If you have a requirement like updating services frequently, it is better to deploy proxy service with first service itself. You can ask consumers to come through Proxy service.
✹ In that case, you do not have to change anything in consumer side.
Now, consumers invoke your proxy service. We modify Proxy service in a way where if consumer passes;
➣ Employee ID parameter, go ahead and talks to version 2.0 of Employee Service.
➣ Employee Code parameter, go ahead and invokes version 1.0 of Employee Service.
In that way, you can independently deploy your service without disturbing your consumers.
Later on, when you do not see any traffic from Employee Code, you can decommission version 1.0 and keep the latest version (2.0). Here, the semantic versioning plays a major role.
( Semantic Versioning has clearly described on one of my previous articles under versioning.) Please refer that through following link:
✹ With Proxy, you dedicate services to 2 different versions and direct the traffic.
Service Discovery is involved with this process.
🔺 It is better to use external party to discover the services for you whenever you create a service because the host name, IP addresses and other things can change with the infrastructure change.
🔺 If you have a service discovery tool, the proxy will invoke it ask the service discovery tool where the previous version of service(employeeService 1.00) is and it will tell the IP Address of that particular version.
For Service Discovery, you can use WSO2 Governance Registry that has this capability and CONSUL that has the service discovery feature.
🔺 Service Discovery is important as your service is independent.
🔺 When you implement proxy service, it is like service chaining. Sometimes, cascade failures may occur. If one service is timing out or takes a long time to respond, it will affect the next service and likewise it is cascading the effect.
Example: Let’s say the final service which is Database Service takes a lot of time because the Database is slow. In that case, it will affect and cascade through all your services.
To avoid those type of issues, we can use;
Message Queues
It will store all the messages and queue processor will process one by one into Database.
You need to have a redundant mechanism when you implement thus type of an architecture. There are ways to implement without repelling own delays throughout other services.
Thread Pools
You need to pay attention on Thread Pools when you implement Proxy pattern. You can use either multiple thread pools or Thread Handover mechanisms.
Example: One thread will take the traffic from consumer and it hands over once it decides the version. In that case, it does not affect on other consumers even though service is slowed down.
Time Outs
Let us assume you have a proxy service and your version 1.00 is getting more delays. If you do not have implemented time outs, that blocks thread and can be affected on version 2.00 calls as well. Therefore, it is important to pay attention on those best practices.
Advantages of implementing Proxy Pattern
💠 Can deploy independently without disturbing consumers.
💠 Easy to implement.
💠 Access to microservices is encapsulated.
💠 Application clients can consume practical data.
💠 Control and diversion of requests.
💠 Better programming techniques such as caching can be used.
Disadvantages of implementing Proxy Pattern
♨️ Inappropriate changes of responses
♨️ Bottleneck
