Skip to content

REST over Vertx

Configuration

The REST over Vertx communication channel runs in standalone mode, it can be started in the main function. In the main function, you need to initialize logs and load service configuration. The code is as follow:

import org.apache.servicecomb.foundation.common.utils.BeanUtils;
import org.apache.servicecomb.foundation.common.utils.Log4jUtils;

public class MainServer {
  public static void main(String[] args) throws Exception {
   Log4jUtils.init();// Log initialization
   BeanUtils.init(); // Spring bean initialization
  }
}

To use the REST over Vertx communication channel, add the following dependencies in the maven pom.xml file:

<dependency>
  <groupId>org.apache.servicecomb</groupId>
  <artifactId>transport-rest-vertx</artifactId>
</dependency>

The REST over Vertx related configuration items in the microservice.yaml file are described as follows:

Table 1-1 Configuration items for REST over Vertx

Configuration Item Default Value Description
servicecomb.rest.address listening address, empty for not listen, just a rest client
servicecomb.rest.server.connection-limit Integer.MAX_VALUE Max allowed client connections
servicecomb.rest.server.thread-count verticle-count rest server verticle instance count(Deprecated)
servicecomb.rest.server.verticle-count verticle-count rest server verticle instance count
servicecomb.rest.server.connection.idleTimeoutInSeconds 60 Timeout for server's idle connection, The idle connections will be closed
servicecomb.rest.server.compression false Wether the server support compression
servicecomb.rest.server.maxInitialLineLength 4096 The max initial line length of the request the server can process, unit is Byte
servicecomb.rest.server.maxHeaderSize 32768 The max header size of the request the server can process, unit is Byte
servicecomb.rest.server.maxFormAttributeSize 2048 The max form attribute size of the request the server can process, unit is Byte
servicecomb.rest.server.compressionLevel 6 The gzip/deflate compression level
servicecomb.rest.server.maxChunkSize 8192 The max HTTP chunk size, unit is Byte
servicecomb.rest.server.decoderInitialBufferSize 128 The max initial buffer size for HttpObjectDecoder, unit is Byte
servicecomb.rest.server.http2ConnectionWindowSize -1 HTTP/2 connection window size, unlimited
servicecomb.rest.server.decompressionSupported false whether decompression is supported
servicecomb.rest.client.thread-count verticle-count rest client verticle instance count(Deprecated)
servicecomb.rest.client.verticle-count verticle-count rest client verticle instance count
servicecomb.rest.client.connection.maxPoolSize 5 The maximum number of connections in each connection pool for an IP:port combination
servicecomb.rest.client.connection.idleTimeoutInSeconds 30 Timeout for client's idle connection, The idle connections will be closed
servicecomb.rest.client.connection.keepAlive true Whether to use long connections
servicecomb.rest.client.connection.compression false Wether the client support compression
servicecomb.rest.client.maxHeaderSize 8192 The max header size of the response the client can process, unit is Byte

Supplementary Explanation

  • The connection amount under extreme condition Assumption:
  • servicecomb.rest.client.thread-count = 8
  • servicecomb.rest.client.connection.maxPoolSize = 5
  • there are 10 instances of microservice A

In terms of client side, under the extreme condition: * for a client instance invoking microservice A, there are up to 400 connections.(8 * 5 * 10 = 400) * if this client instance is also invoking another microservice B, and there are 10 instances of microservice B, then there are another 400 connections, and 800 connections in total.

In terms of server side, under the extreme condition: * a client instance establishes up to 40 connections to a server instance.(8 * 5 = 40) * n client instances establish up to 40 * n connections to a server instance.

To improve performance, larger connection pools are needed. While the larger connection pools means the more connections. When the microservice instance scale reaches hundreds, some instances may handle tens of thousands of connections. Therefore, the developers need to make reasonable planning according to the actual condition. The planning of HTTP1.1 may be relatively complex, and sometimes there is no proper solution, in which case the http2 is recommended.

Sample Code

An example of the configuration in the microservice.yaml file for REST over Vertx:

servicecomb:
  rest:
    address: 0.0.0.0:8080
    thread-count: 1
  references:
    hello:
      transport: rest
      version-rule: 0.0.1