合理设置servicecomb.rest.server.thread-count的值

很对开发者测试的时候，发现CSE SDK的CPU占用率很多时候只能够到1CPU，这是因为servicecomb.rest.server.thread-count默认值为1。 官网文档将这个配置项含义解释为“服务端线程数”（参考： https://docs.servicecomb.io/java-chassis/zh_CN/build-provider/protocol/rest-over-vertx.html），这个解释其实不怎么准确，容易和event-loop线程数混淆，开发者理解不了，而且提升这个值，CPU的利用率确实会增加，但是通过jstack查看线程数，却不会增加。 

servicecomb.rest.server.thread-count实际上的含义是Vertical的一个概念： vertical instances count。 他是一个非常抽象的概念， 涉及到资源分配和线程绑定关系。比如当值为1的时候，服务端每收到一个请求，就会将请求丢到一个event-loop线程去执行，然后这个绑定关系就确定下来了，不会发生改变。 

单纯的从服务端来看，缺省值为1，而event-loop线程是2 * CPU个，无法修改，那么实际上被使用的event-loop线程只有1个，其他线程都是永远空缺着的。 vertical instances count和操作系统资源是紧密绑定的，对于服务端而言，CPU核数就是资源，因此servicecomb.rest.server.thread-count大于CPU核数就显得毫无意义了。

但是操作系统还有其他的资源和处理，一个进程里面还会处理客户端网络调用， servicecomb.rest.client.thread-count增加，会分配更多的连接资源（句柄࿰