When designing a server, there are a lot of repetitive and tedious tasks that you usually have to do all by yourself. These include the following processes:

• Designing a protocol
• Serializing and deserializing messages on the protocol with code
• Dealing with sockets
• Managing concurrency
• Dealing with clients in different languages

Apache Thrift gets rid of all these excessive tasks. It can carry out all of these automatically after you provide a description of the functions you want to deliver from your server to the client and their parameters. This allows Apache Thrift to generate code in accordance with any choice of language.

The Apache Thrift framework works as follows:

• First, it provides an interface definition language that is free from any specific language and its restrictions.
• With this interface definition language, a compiler is also required to produce server and client codes.
• Apache Thrift provides compiler-generated client code and compiler-generated server code. In the compiler-generated client code, the parameters passed over the functions are converted to a binary format so that they can be transported over the network. This process is commonly known as marshalling.
• In the compiler-generated server code, the functions of the client code are implemented. The parameters that were converted to binary in the client-side code are received by the server-side code, which converts them back to their original language objects and passes them through the function. This process is commonly known as unmarshalling.
• The result of the compiler-generated server code is then converted to binary and sent through the wire over the network to the compiler-generated client code where it is converted back to the original language objects and shown over the user interface.

Most synchronous communications are one-to-one. In synchronous one-to-one communication, you can also use multiple instances of a service to scale the service. However, if you do, you have to use a load-balancing mechanism at the client side. Each service contains meta-information about all instances of the calling service. This information is provided by the service discovery server, an example of which is Netflix Eureka. There are several load-balancing mechanisms you can use. One of these is Netflix Ribbon, which carries out load-balancing on the client side, as illustrated in the following diagram:

As you can see in the preceding diagram, we have multiple instances of a particular service, but the services are still communicating one-to-one. That means that each service communicates to an instance of another service. The load balancer chooses which method should be called. The following is a list of some of the most common load-balancing methods available: 

• Round-Robin: This is the simplest method that routes requests across all the instances sequentially
• Least Connections: This is a method in which the request goes to the instance that has the fewest number of connections at the time
• Weighted Round-Robin: This is an algorithm that assigns weight to each instance and forwards the connection according to this weight
• IP Hash: This is a method that generates a unique hash key from the source IP address and determines which instance receives the request

Spring Cloud provides support to Netflix libraries to balance the load on the client side; you can also use Spring's RestTemplate or Feign client. Netflix Feign implements load-balancing internally.

The following code snippet performs the Feign client configuration:

@FeignClient(value = "ACCOUNT-SERVICE", fallback = AccountFallback.class)
public interface AccountClient {
            @GetMapping("/accounts/customer/{customerId}")
            List <Account> getAccounts(@PathVariable("customerId") Integer customerId);
}
@Component
public class AccountFallback implements AccountClient {
            @Override
            public List <Account> getAccounts(Integer customerId) {
                        List <Account> acc = new ArrayList<>();
                        return acc;
            }
}

In the preceding code, we also configured Hystrix as a circuit breaker pattern.

In the following section, we'll discuss another approach for inter-service communication.