Photo by Thomas Jensen on h Unsplas Most of the business applications which are used today communicate with each other using HTTP 1.1 using REST. This has become a standard in the industry due to its sheer simplicity and almost no effort required to integrate the applications. However, once your application goes to the scale of handling a million requests per second and more, the shortcomings of the above mechanism become apparent. Let’s address those first — No Multiplexing A single HTTP 1.1 connection can only be used to send one request and response at a time. This connection is blocked until the response is received which is highly inefficient. Limited compression HTTP 1.1 headers are not compressed which leads to an unnecessary increase in request data size. In HTTP/2, they are compressed using HPACK algorithm which has 99% compression ratio. Text-based transmission HTTP 1.1 is text-based which is highly inefficient for transmission of data. They require complex parsers and also don’t support high levels of compression. HTTP 2 was made to get rid of all these limitations. It supports multiplexing which allows a client to send multiple parallel requests over a single connection. The headers are compressed using HPACK compression algorithm and transmit binary data. provides a detailed comparison along with performance metrics for both protocols. This article In this article, we’ll be exploring how you can use HTTP/2 in your service. Currently, the most popular way to do this is to use . gRPC by Google gRPC In simple words, it is a web framework used to connect multiple services using HTTP/2. It is currently used by hundreds of companies to efficiently connect microservices. gRPC services differ from REST in the way that they don’t expose endpoints but methods/procedures. The client simply calls a method as if it is locally implemented and in the background, an RPC call is sent to the server which contains the actual implementation of the method. The interface of the service and its methods is defined in a .proto file. This is because gRPC uses Protocol buffers to transfer the data between various services as well as to generate client and server stubs. This results in an order of magnitude faster serialization and deserialization speeds. The detailed comparison between Protocol Buffers, JSON and Flatbuffers can be found in by me. this article The RPC call is done over HTTP/2. This allows gRPC users to automatically leverage all the features of the above protocol. Let’s create a simple Hello World service in gRPC using Java. The example provided here can be found on https://grpc.io/docs/quickstart/java/ Define the service First, we define the interface of the service in a .proto file. Let’s name this file greeter.proto We name the service Greeter. This service contains a method SayHello. The method accepts a HelloRequest object and returns a HelloReply object. Next, we define the format of HelloRequest and HelloReply ProtocolBuffers. syntax = ; { rpc SayHello (HelloRequest) returns (HelloReply) {}
} message HelloRequest { name = ;
} message HelloReply { message = ;
} "proto3" // The greeting service definition. service Greeter // Sends a greeting // The request message containing the user's name. string 1 // The response message containing the greetings string 1 Generate the interfaces Next, we’ll generate the service interface and client stub using protobuf compiler. Create your usual maven java project. Next copy the greeter.proto file in src/main/proto folder. Once it is there, we can use maven proto compiler to generate Java classes from this file. UTF-8 1.19.0 3.6.1 3.6.1 1.7 1.7 ${basedir}/target/generated-sources/ kr.motd.maven os-maven-plugin 1.6.2 org.xolstice.maven.plugins protobuf-maven-plugin 0.5.1 com.google.protobuf:protoc:${protoc.version}:exe:${os.detected.classifier} grpc-java io.grpc:protoc-gen-grpc-java:${grpc.version}:exe:${os.detected.classifier} compile compile-custom test-compile test-compile-custom sasas < > properties < > project.build.sourceEncoding </ > project.build.sourceEncoding < > grpc.version </ > grpc.version  < > protobuf.version </ > protobuf.version < > protoc.version </ > protoc.version  < > maven.compiler.source </ > maven.compiler.source < > maven.compiler.target </ > maven.compiler.target </ > properties < > build < > sourceDirectory </ > sourceDirectory < > extensions < > extension < > groupId </ > groupId < > artifactId </ > artifactId < > version </ > version </ > extension </ > extensions < > plugins < > plugin < > groupId </ > groupId < > artifactId </ > artifactId < > version </ > version < > configuration < > protocArtifact </ > protocArtifact < > pluginId </ > pluginId < > pluginArtifact </ > pluginArtifact </ > configuration < > executions < > execution < > goals < > goal </ > goal < > goal </ > goal < > goal </ > goal < > goal </ > goal </ > goals </ > execution </ > executions </ > plugin </ > plugins </ > build The classes will be generated in target/generated-sources/protobuf directory. Implement the service We can now extend the service interface generated to implement the methods. { { HelloReply reply = HelloReply.newBuilder().setMessage( + req.getName()).build(); responseObserver.onNext(reply); responseObserver.onCompleted();
  }
} private . class GreeterImpl extends GreeterGrpc GreeterImplBase @Override public void sayHello (HelloRequest req, StreamObserver<HelloReply> responseObserver) //Build Proto Messages Object "Hello " //Send the response, you can send multiple objects which will be trasmitted in streaming fashion //Indicate client that response has finished Implement the client Clients can now simply call this sayHello method and the service will return the response via HTTP/2 { ManagedChannel channel; GreeterBlockingStub blockingStub; GreeterStub asyncStub; {
     channel = ManagedChannelBuilder.forAddress(host, port).usePlaintext().build(); blockingStub = GreeterGrpc.newBlockingStub(channel); asyncStub = GreeterGrpc.newStub(channel); } {
      logger.info( + name + );
      HelloRequest request = HelloRequest.newBuilder().setName(name).build();
      HelloReply response; {
        response = blockingStub.sayHello(request);
      } (StatusRuntimeException e) {
        logger.log(Level.WARNING, , e.getStatus()); ;
      }
      logger.info( + response.getMessage());
  } {
    
      StreamObserver<HelloReply> responseObserver = StreamObserver<HelloReply>() { {
            logger.info( + response.getMessage());
          } {
            Status status = Status.fromThrowable(t);
            logger.log(Level.WARNING, , status);
          } {
            info( );
          }
      };
      
      logger.info( + name + );
      HelloRequest request = HelloRequest.newBuilder().setName(name).build();
      asyncStub.sayHello(request, responseObserver);
        
  }
  
} public class Client private final private final private final public Client (String host, String port) //remove .usePlainText for secure connections // use it to make blocking calls // or use this to make async calls public void blockingGreet (String name) "Will try to greet " " ..." try catch "RPC failed: {0}" return "Greeting: " public void asyncGreet (String name) new @Override public void onNext (HelloReply response) "Greeting: " @Override public void onError (Throwable t) "RPC Failed: {0}" @Override public void onCompleted () "Finished Greeting" "Will try to greet " " ..." Run the server You can either use the server bundled with grpc or you can use external frameworks which already provide grpc bindings such as Vert.x Java { (ServerBuilder.forPort(port), port);
} { .port = port;
  server = serverBuilder.addService( GreeterImpl()).build();
} {
  server.start();
  logger.info( + port);
} IOException public GreeterServer ( port) int throws this public GreeterServer (ServerBuilder<?> serverBuilder, port) int this new IOException public void start () throws "Server started, listening on " Now, you have successfully implemented a basic gRPC service. Load balancing The non-trivial part of running a http/2 service in production is load balancing. gRPC breaks the standard connection-level load balancing i.e. to create a new connection to another instance for a request which is provided by default in Kubernetes or HAProxy. This is because gRPC is built on HTTP/2, and HTTP/2 is designed to have a single long-lived TCP connection. The solution is to do request level load balancing. This means to create long-lived connections and then distribute requests across those connections. The easiest and most effective way to do this is to use . It is a service-mesh which can run beside your Kubernetes/Mesos or any other cluster. Linkerd2 serves as a proxy for the incoming request. Since it is written in rust it adds a very minimal delay (<1ms) and load balance requests across host machines which it can detect through k8s API or DNS. linkerd2 You don’t need to configure anything extra in Linkerd2, it handles HTTP 1 and 2 traffic by default. If you want to learn more about gRPC, linkerD or http/2 you can refer the links below: gRPC Load Balancing on Kubernetes without Tears HTTP/2: the difference between HTTP/1.1, benefits and how to use it gRPC Java — Basics Connect with me on LinkedIn or Twitter or drop a mail to kharekartik@gmail.com

Google

Target

Twitter

Read My Stories

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

Here’s How You Can and Why You Should Go Beyond HTTP 1.1

Too Long; Didn't Read

Companies Mentioned

Kartik Khare

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Here’s How You Can and Why You Should Go Beyond HTTP 1.1

Too Long; Didn't Read

Companies Mentioned

Kartik Khare

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES