It is one of the advantages of microservices that each individual service can be independently scaled. To distribute the load between the instances, multiple instances, which share the load, can simply be registered in a messaging solution (see section 8.4). The actual distribution of the individual messages is then performed by the messaging solution. Messages can either be distributed to one of the receivers (point-to-point) or to all receivers (publish/subscribe).
In case of REST and HTTP a load balancer has to be used. The load balancer has the function to behave to the outside like a single instance, but to distribute requests to multiple instances. Besides, a load balancer can be useful during deployment: Instances of the new version of the microservice can initially start without getting a lot of load. Afterwards the load balancer can be reconfigured in a way that the new microservices are put into operation. In doing so the load can also be increased in a stepwise manner. This decreases the risk of a system failure.
Figure 7.13 illustrates the principle of a proxy-based load balancer: the client sends its requests to a load balancer running on another server. This load balancer is responsible for sending each request to one of the known instances. There the request is processed.
This approach is common for websites and relatively easy to implement. The load balancer retrieves information from the service instances to determine the load of the different instances. In addition, the load balancer can remove a server from the Load Balancing when the node does not react to requests anymore.
On the other hand, this approach has the disadvantage that the entire traffic for one kind of service has to be directed via a load balancer. Therefore, the load
Figure 7.13 Proxy-Based Load Balancer
balancer can turn into a bottleneck. Besides, a failure of the load balancer results in the failure of a microservice.