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.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 |
The connection amount under extreme condition Assumption:
In terms of client side, under the extreme condition:
8 * 5 * 10 = 400
)In terms of server side, under the extreme condition:
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.
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