CSE JAVA SDK使用service_description.version定义版本号， 目前推荐支持如下规则：x.y.z或者a.b.c.d其中x/y/z/a/b/c/d都是一个int值（short），不能超过2个字节（注意不是4个字节）的数字大小。 关于版本规则的特殊说明CSE JAVA SDK的版本号必须采用数字，而不能使用字符等特殊字符。 因为这个版本号，不是传统意义上的版本管理的概念，用于表达一些版本逻辑，比如主要、次要、补丁等。 CSE的版本号主要用于表达“接口兼容”性概念， 版本号变化表示可能存在接口变更。 在处理路由规则的时候，会基于契约和版本号进行分组，将兼容的接口分为一组，从而实现多版本并存和自动基于接口兼容性进行请求转发。 这个特性是CSE JAVA SDK非常独特的特性，优雅的解决了灰度版本并存的问题，而不需要用户做任何额外的开发。 关于接口兼容性的一些推荐实践参考：https://huaweicse.github.io/cse-java-chassis-doc/question-and-answer/interface-compatibility.html

CSE JAVA SDK使用vertx的HTTP实现，支持客户端TLS和服务端TLS。 使用openssl 加上配置项：   ssl.engine: openssl即可。 文档参考:  https://docs.servicecomb.io/java-chassis/zh_CN/security/tls.html

错误日志：  java.lang.IllegalStateException: Another strategy was already registered.     at com.netflix.hystrix.strategy.HystrixPlugins.registerCommandExecutionHook这个日志是由于spring boot也注册了hystrix，bizkeeper也会注册，hystrix不允许同时注册，但是又没接口能够判断是否已经注册(get方法有bug），所以会打印一个警告。 不影响功能。 如果没有bizkeeper的功能，可以在handler配置里面把他移除。 这样cse就不会尝试注册hystrix了，就没有这个异常了。 默认是这个，如果你们没定制的话：# 处理链配置  handler:    chain:      Provider:        default: qps-flowcontrol-provider,bizkeeper-provider      Consumer:        default: qps-flowcontrol-consumer,loadbalance,fault-injection-consumer,bizkeeper-consumer修改为:# 处理链配置  handler:    chain:      Provider:        default: qps-flowcontrol-provider      Consumer:        default: qps-flowcontrol-consumer,loadbalance,fault-injection-consumer当然也可以打个断点调试下registerCommandExecutionHook方法，看看spring boot 的哪个模块调用了这个方法。 如果不使用spring boot的功能不使用，去掉对应的jar包依赖也是可以的。 

使用CSE JAVA SDK开发微服务，报告接口方法不存在，启动失败，查看接口实现，这些方法都是存在的。日志信息：java.lang.Error: swagger method %s not exist in producer  at org.apache.servicecomb.swagger.engine.SwaggerEnvironment.createProducer有些版本报错：java.lang.Error: swagger method %s not exist in producer %s.   at org.apache.servicecomb.swagger.engine.SwaggerEnvironment.createProducer原因分析：   这个错误在比较swagger的方法是否在定义的接口实现里面存在，对于服务端，swagger的方法是根据接口实现生成的，因此任何时候都是存在的，正常情况下不会出现这个异常。    当用户将一个接口定义的schemaId指定为一样的，并且两个实现方法不一样的时候，就会出现这样的问题。 比如：   @RestSchema(schemaId="xyz")   public class Hello   @RestSchema(schemaId="xyz")   public class World

问题详细描述： CSE 服务中心要多长时间判定认为实例故障下线而移除了。 微服务和服务中心之间存在心跳机制，服务中心根据微服务定时发送的心跳来判断实例是否还在。 如果实例不存在了，那么服务中心会删除实例信息，并通知其他微服务实例（或者依赖于pull机制），告知这个实例已经下线。 服务中心移除实例的时间受几个参数控制 servicecomb.service.registry.instance.healthCheck.interval 和 servicecomb.service.registry.instance.healthCheck.times 。 当连续第times+1次心跳仍然失败时则实例被sc下线。即interval * (times + 1)决定了实例被自动注销的时间。如果服务中心等待这么长的时间没有收取到心跳，会注销实例。详细配置参考： https://docs.servicecomb.io/java-chassis/zh_CN/general-development/visit-sc.html

某业务出现一个奇怪的消息，一个接口的调用始终超时， 错误消息为：The timeout period of 60000ms has been exceeded while executing POST /rest/csbmessagecenterservice/v1/config/email/test-email-config for host 172.16.1.186, server is rest://172.16.1.186:8443?sslEnabled=true详细日志中有如下内容，表示配置了重试，重试也是失败。用户使用postman直接请求，调用不会超时，而使用测试工具系统请求，则会超时。 一时不知道为什么。[2019-01-22 06:16:25:638] [ERROR] - [transport-vert.x-eventloop-thread-18] [org.apache.servicecomb.transport.rest.client.http.RestClientInvocation.lambda$invoke$0(RestClientInvocation.java:104)] - Failed to send request to /172.16.1.186:8443.io.vertx.core.http.impl.HttpClientRequestBase$1: The timeout period of 60000ms has been exceeded while executing POST /rest/csbmessagecenterservice/v1/config/email/test-email-config for host 172.16.1.186[2019-01-22 06:16:25:638] [ERROR] - [transport-vert.x-eventloop-thread-18] [org.apache.servicecomb.loadbalance.LoadbalanceHandler$4.lambda$null$0(LoadbalanceHandler.java:369)] - service CONSUMER rest CSBMessageCenterService.ApiMessageConfigResource.testEmailConfig, call error, msg is cause:InvocationException,message:InvocationException: code=490;msg=CommonExceptionData [message=Cse Internal Bad Request];cause:,message:The timeout period of 60000ms has been exceeded while executing POST /rest/csbmessagecenterservice/v1/config/email/test-email-config for host 172.16.1.186, server is rest://172.16.1.186:8443?sslEnabled=true[2019-01-22 06:16:25:639] [ERROR] - [transport-vert.x-eventloop-thread-18] [org.apache.servicecomb.loadbalance.LoadbalanceHandler$3.onExceptionWithServer(LoadbalanceHandler.java:294)] - Invoke server failed. Operation CONSUMER rest CSBMessageCenterService.ApiMessageConfigResource.testEmailConfig; server rest://172.16.1.186:8443?sslEnabled=true; 0-0 msg cause:InvocationException,message:InvocationException: code=490;msg=CommonExceptionData [message=Cse Internal Bad Request];cause:,message:The timeout period of 60000ms has been exceeded while executing POST /rest/csbmessagecenterservice/v1/config/email/test-email-config for host 172.16.1.186[2019-01-22 06:16:25:639] [ERROR] - [transport-vert.x-eventloop-thread-18] [org.apache.servicecomb.loadbalance.LoadbalanceHandler$3.onExecutionFailed(LoadbalanceHandler.java:322)] - Invoke all server failed. Operation CONSUMER rest CSBMessageCenterService.ApiMessageConfigResource.testEmailConfig, e=cause:InvocationException,message:InvocationException: code=490;msg=CommonExceptionData [message=Cse Internal Bad Request];cause:,message:The timeout period of 60000ms has been exceeded while executing POST /rest/csbmessagecenterservice/v1/config/email/test-email-config for host 172.16.1.186超时问题一般通过日志看不出根本原因。 建议业务先做了如下排查：查看服务端的access log，看是否有接受到请求；弄清楚问题出现的环节。 查看下打印超时日志的的服务的access log， 将调用目标服务的其他接口的访问情况观察看，看是一个接口超时还是所有接口都超时。通过日志看，很多接口都有超时，但也并不是每次都超时，只是有些请求超时。 一时找不到原因。 无赖只好自己把所有日志都拉出来，重新排查了一遍，最后发现业务开发者在排查第1步的都是搞漏了。 业务接口在某种输入情况下，处理时间超过8分钟，而access log是在业务处理完毕后打印的，包日志看漏了。 contract:172.16.3.8 - - - - [22/Jan/2019:03:26:16 +0000] "PUT /rest/csb/csbcontractservice/v1/business-change HTTP/1.1" 400 72 8172.16.3.8 - - - - [22/Jan/2019:03:33:07 +0000] "PUT /rest/csb/csbcontractservice/v1/business-change HTTP/1.1" 500 62 481105172.16.3.8 - - - - [22/Jan/2019:03:34:48 +0000] "PUT /rest/csb/csbcontractservice/v1/business-change HTTP/1.1" 500 62 481116172.16.3.8 - - - - [22/Jan/2019:03:40:17 +0000] "PUT /rest/csb/csbcontractservice/v1/business-change HTTP/1.1" 400 72 8172.16.3.8 - - - - [22/Jan/2019:03:41:44 +0000] "PUT /rest/csb/csbcontractservice/v1/business-change HTTP/1.1" 400 72 7172.16.3.8 - - - - [22/Jan/2019:03:42:42 +0000] "PUT /rest/csb/csbcontractservice/v1/business-change HTTP/1.1" 400 72 8edge:172.16.3.1 - 2019-01-22 03:25:06,271 "PUT /rest/csb/csbcontractservice/v1/business-change HTTP/1.1" - 490 38 60003 809168370546  -- 业务22/Jan/2019:03:33:07返回，超过8分钟172.16.3.1 - 2019-01-22 03:26:16,297 "PUT /rest/csb/csbcontractservice/v1/business-change HTTP/1.1" - 400 61 13 5c468d580e692bee172.16.3.1 - 2019-01-22 03:26:47,616 "PUT /rest/csb/csbcontractservice/v1/business-change HTTP/1.1" - 490 38 60002 180593684930 -- 业务22/Jan/2019:03:34:48返回，超过8分钟172.16.3.1 - 2019-01-22 03:40:17,559 "PUT /rest/csb/csbcontractservice/v1/business-change HTTP/1.1" - 400 61 12 5c4690a18978dcfe172.16.3.1 - 2019-01-22 03:41:44,823 "PUT /rest/csb/csbcontractservice/v1/business-change HTTP/1.1" - 400 61 11 180593684930172.16.3.1 - 2019-01-22 03:42:42,757 "PUT /rest/csb/csbcontractservice/v1/business-change HTTP/1.1" - 400 61 12 180593684930为了让超时问题更好的得到定位，建议开发者每个服务都打开access log，便于分析。 对于性能问题，可能还需要打开metrics日志，分析瓶颈点。 

基本步骤包括两个：   1    引入依赖关系 <dependency>          <groupId>org.apache.servicecomb</groupId>          <artifactId>config-apollo</artifactId>   </dependency>   2    配置apollo地址apollo:    config:     serverUri: http://127.0.0.1:8070     erviceName: provider-id #创建应用时的AppID             env: DEV             clusters: default             namespace: application             token: de3c5b2e6d8535b96             refreshInterval: 10 详细使用步骤参考：http://www.chinacion.cn/article/2945.html

系统性问题：1.      整体服务架构和规模摸底a.       对服务规模（微服务数量，每个微服务的实例数，每个微服务的schema个数等）需要进行一定的评估，如果微服务总接口数非常多，并且所有服务的请求都经过Edge Service转发，建议Edge Service等需要调用大量其他服务的消费者设置较大的的JAVA metaspace空间， -XX:MaxMetaspaceSize=512m。 一个微服务接口数量太多还有个问题就是服务第一次被访问的时候，加载会比较慢。 对于对一次访问有明显要求的业务，可以考虑预加载提升访问速度。 2.       业务线程池配置a.       CSE提供的两个配置项servicecomb.rest.server.thread-count和servicecomb.rest.client.thread-count并不是业务线程池配置。这两个参数不需要配置的特别大，一般等于CPU核数即可，建议配置为8~16之间。b.      对于tomcat场景，以及Edge Service的vert.x场景，都有一个业务处理线程池(Edge Service的场景默认在reactive模式，是没有业务线程池的)。CSE设置的默认线程池的线程个数为2 * CPU个数。如果部分服务处理比较慢（比如评价时延>50ms），那么建议要设置一个较大的业务线程池，以提升吞吐量。如果所有接口都处理的很快，则不需要设置非常大的业务线程池，过多线程反而会因为线程调度，增加处理时延。如果一个微服务，有少量的几个接口处理非常耗时，需要考虑将这些接口放到独立的线程池执行（线程池隔离），防止访问慢的接口，影响访问快的接口。 3.       运维参数和建议a.       设置合理的超时时间。超时时间设置不能够小于3秒，即使业务处理时间都非常小（比如小于1ms）b.      打开metrics，用于分析性能瓶颈，并将日志输出到独立的日志文件c.       打开access logd.      对接APM的调用链，增强问题快速定界能力  4.       开发效率提升开发效率提升需要把一些准备工作放到平时，每个微服务尽可能梳理出本微服务对外的依赖关系，通过在本地安装依赖服务（或者提供模拟桩），实现在开发环境调试和验证微服务基本功能。这样能够大大提高开发效率，同时提升软件质量。 5.       SSL性能风险SSL在高并发、频繁断连重连的情况下，可能出现内存高、性能慢的情况。SSL协议慢是已知问题，并没有解决方案，对于对于时延要求很高，频繁超时、短连接，并发特别高等场景，不适合使用HTTPS。 目前有些产品的具体做法：1. 内部通讯使用HTTP；接入层使用HTTPS；2. 使用和验证HTTP2协议，降低连接数和连接重建。 这个可以纳入后续规划，以应对可能的用户增长问题。  开发常见错误：1.       业务中常驻线程或者定时任务的保护。 常驻线程或者定时任务的Task跑出异常， 会导致这些任务不再被调度执行。如果存在这种场景，一定要通过catch Throwable保证线程的可靠性。 可以通过通用的ThreadFactory创建线程实现，详细参考这个问题修改代码。2.       使用vert.x异步HttpClient一定需要注意设置如下几个异常处理器，保证异常的时候，异步回调能够正常执行。这类逻辑再CBC的Edge网关等场景也有使用，建议也排查下。a.       request.exceptionHandlerb.      response.exceptionHandler  --- 这个特别容易遗漏c.       response.bodyHandler3.       程序故障保护和运维方面的一些问题，保护错误，能够让程序在一些故障场景下能够有更好的适应性，但是实际上也会隐含的一层意思“业务故障可能被推迟发现”。 如果没有良好的运维机制，那么故障还是随着问题积累，慢慢的被发现。虽然从软件角度来讲，这个可以提高SLA的水平，是正向的，但是我们还是需要有一定的机制，能够先于用户发现问题。4.       Tomcat超时问题：maxKeepAliveRequests修改为-1， keepAliveTimeout建议是客户端的2倍5.       使用环境变量指定SC地址问题(以及其他需要使用yaml中的List类型情况）：需要测试下配置两个IP地址的情况下，如果一个地址失败，是否访问第二个地址。案例参考： https://bbs.huaweicloud.com/forum/thread-13404-1-1.html

CSE的异常处理机制参考： https://docs.servicecomb.io/java-chassis/zh_CN/general-development/error-handling.html正常情况下，都是通过业务接口定义异常和返回错误码，比如： @Path("/errorCode")  @POST   @ApiResponses({      @ApiResponse(code = 200, response = MultiResponse200.class, message = ""),      @ApiResponse(code = 400, response = MultiResponse400.class, message = ""),      @ApiResponse(code = 500, response = MultiResponse500.class, message = "")})  public MultiResponse200 errorCode(MultiRequest request) {    if (request.getCode() == 400) {       MultiResponse400 r = new MultiResponse400();       r.setCode(400);       r.setMessage("bad request");      throw new InvocationException(javax.ws.rs.core.Response.Status.BAD_REQUEST, r);     } else if (request.getCode() == 500) {       MultiResponse500 r = new MultiResponse500();       r.setCode(500);       r.setMessage("internal error");      throw new InvocationException(javax.ws.rs.core.Response.Status.INTERNAL_SERVER_ERROR, r);     } else {       MultiResponse200 r = new MultiResponse200();       r.setCode(200);       r.setMessage("success result");      return r;     }   }如果需要做一个通用的异常处理机制，可以实现ExceptionToProducerResponseConverter接口并发布为SPI。 或者通过handler来实现，将handler放到最前面，示例参考： https://github.com/apache/servicecomb-java-chassis/pull/1048/files

CSE JAVA SDK Maven 仓库地址早期做过一次变更，最新迁移到华为云了。         <repository>             <id>HuaweiCloudSDK</id>             <url>https://mirrors.huaweicloud.com/repository/maven/huaweicloudsdk/</url>             <releases>                 <enabled>true</enabled>             </releases>             <snapshots>                 <enabled>false</enabled>             </snapshots>         </repository>详细配置参考： https://support.huaweicloud.com/devg-cse/cse_03_summary.html

背景信息CSE Java SDK的开源部分ServiceComb项目已于2017年12月全票通过进入Apache孵化器，根据Apache软件基金会要求，项目groupId统一由io.servicecomb调整为org.apache.servicecomb。CSE Java SDK作为ServiceComb的商业版本，除提供对接华为公有云的能力、安全、分布式数据一致性等商业能力外，其大部分组件来自于开源的ServiceComb。因此提供本指导用于支持客户顺利升级至包名变更后的CSE Java SDK版本（2.3.3+）。更改说明CSE Java SDK版本（2.3.3+）中涉及包名变化情况如下：序号包名称groupId（修改前）groupId（修改后）变化类型1CSE Java-SDK开源包65个包名变更，详见CSE Java SDK开源包列表io.servicecomborg.apache.servicecomb修改2CSE Java-SDK开源包foundation-config-cc新增config-cc，groupId为org.apache.servicecomb新增3CSE Java-SDK商业包foundation-config-cc移除foundation-config-cc删除4CSE Java-SDK商业包共计13个，详见CSE Java SDK商业包列表com.huawei.paas.cse无变化操作步骤通过配置maven setting文件以获取SDK依赖。profiles中增加如下配置。<profile>     <id>nexusProfile</id>     <repositories>         <repository>             <id>cse1</id>             <url>http://maven.huaweicse.com/nexus/content/groups/public/</url>         </repository>     </repositories> </profile>新增activeProfiles配置。<activeProfiles>     <activeProfile>nexusProfile</activeProfile> </activeProfiles>引入dependencyManagement，建议开发者在pom.xml中进行如下配置以便更好的管理三方件。 说明：版本使用2.3.3以上版本。<dependencyManagement>     <dependencies>         <dependency>             <groupId>com.huawei.paas.cse</groupId>             <artifactId>cse-dependency</artifactId>             <version>2.3.58</version>             <type>pom</type>             <scope>import</scope>         </dependency>     </dependencies> </dependencyManagement>修改pom.xml中依赖包的groupid。此处仅以引入对spring-boot-starter-provider、cse-solution-service-engine、foundation-auth的依赖为例。修改前<dependency>     <groupId>io.servicecomb</groupId>     <artifactId>spring-boot-starter-provider</artifactId> </dependency> <dependency>     <groupId>com.huawei.paas.cse</groupId>     <artifactId>cse-solution-service-engine</artifactId> </dependency> <dependency>     <groupId>com.huawei.paas.cse</groupId>     <artifactId>foundation-auth</artifactId>     <exclusions>         <exclusion>             <groupId>org.slf4j</groupId>             <artifactId>slf4j-log4j12</artifactId>         </exclusion>     </exclusions> </dependency>修改后<dependency>     <groupId>org.apache.servicecomb</groupId>     <artifactId>spring-boot-starter-provider</artifactId> </dependency> <dependency>     <groupId>com.huawei.paas.cse</groupId>     <artifactId>cse-solution-service-engine</artifactId> </dependency> <dependency>     <groupId>com.huawei.paas.cse</groupId>     <artifactId>foundation-auth</artifactId>     <exclusions>         <exclusion>             <groupId>org.slf4j</groupId>             <artifactId>slf4j-log4j12</artifactId>         </exclusion>     </exclusions> </dependency>CSE Java SDK开源包列表序号artifactIdgroupid（修改前）groupid（修改后）1common-javassistio.servicecomborg.apache.servicecomb2common-protobufio.servicecomborg.apache.servicecomb3common-restio.servicecomborg.apache.servicecomb4commonio.servicecomborg.apache.servicecomb5config-apolloio.servicecomborg.apache.servicecomb6dynamic-configio.servicecomborg.apache.servicecomb7edge-coreio.servicecomborg.apache.servicecomb8edgeio.servicecomborg.apache.servicecomb9foundation-commonio.servicecomborg.apache.servicecomb10config-ccio.servicecomborg.apache.servicecomb11foundation-configio.servicecomborg.apache.servicecomb12foundation-metricsio.servicecomborg.apache.servicecomb13foundation-sslio.servicecomborg.apache.servicecomb14foundation-test-scaffoldingio.servicecomborg.apache.servicecomb15foundation-vertxio.servicecomborg.apache.servicecomb16foundationsio.servicecomborg.apache.servicecomb17handler-bizkeeperio.servicecomborg.apache.servicecomb18handler-flowcontrol-qpsio.servicecomborg.apache.servicecomb19handler-loadbalanceio.servicecomborg.apache.servicecomb20handler-publickey-authio.servicecomborg.apache.servicecomb21handler-tracing-zipkinio.servicecomborg.apache.servicecomb22handlersio.servicecomborg.apache.servicecomb23java-chassis-coreio.servicecomborg.apache.servicecomb24java-chassis-dependenciesio.servicecomborg.apache.servicecomb25java-chassis-parentio.servicecomborg.apache.servicecomb26java-chassisio.servicecomborg.apache.servicecomb27metrics-commonio.servicecomborg.apache.servicecomb28metrics-coreio.servicecomborg.apache.servicecomb29metrics-extensionio.servicecomborg.apache.servicecomb30metrics-integrationio.servicecomborg.apache.servicecomb31metrics-prometheusio.servicecomborg.apache.servicecomb32metricsio.servicecomborg.apache.servicecomb33provider-jaxrsio.servicecomborg.apache.servicecomb34provider-pojoio.servicecomborg.apache.servicecomb35provider-rest-commonio.servicecomborg.apache.servicecomb36provider-springmvcio.servicecomborg.apache.servicecomb37providersio.servicecomborg.apache.servicecomb38service-registryio.servicecomborg.apache.servicecomb39spring-boot-starter-configurationio.servicecomborg.apache.servicecomb40spring-boot-starter-discoveryio.servicecomborg.apache.servicecomb41spring-boot-starter-parentio.servicecomborg.apache.servicecomb42spring-boot-starter-providerio.servicecomborg.apache.servicecomb43spring-boot-starter-registryio.servicecomborg.apache.servicecomb44spring-boot-starter-servicecombio.servicecomborg.apache.servicecomb45spring-boot-starter-transportio.servicecomborg.apache.servicecomb46spring-cloud-zuul-zipkinio.servicecomborg.apache.servicecomb47spring-cloud-zuulio.servicecomborg.apache.servicecomb48swagger-generator-coreio.servicecomborg.apache.servicecomb49swagger-generator-jaxrsio.servicecomborg.apache.servicecomb50swagger-generator-springmvcio.servicecomborg.apache.servicecomb51swagger-generatorio.servicecomborg.apache.servicecomb52swagger-invocation-coreio.servicecomborg.apache.servicecomb53swagger-invocation-jaxrsio.servicecomborg.apache.servicecomb54swagger-invocation-springmvcio.servicecomborg.apache.servicecomb55swagger-invocationio.servicecomborg.apache.servicecomb56swaggerio.servicecomborg.apache.servicecomb57tracing-commonio.servicecomborg.apache.servicecomb58tracing-zipkinio.servicecomborg.apache.servicecomb59tracingio.servicecomborg.apache.servicecomb60transport-highwayio.servicecomborg.apache.servicecomb61transport-rest-clientio.servicecomborg.apache.servicecomb62transport-rest-servletio.servicecomborg.apache.servicecomb63transport-rest-vertxio.servicecomborg.apache.servicecomb64transport-restio.servicecomborg.apache.servicecomb65transportsio.servicecomborg.apache.servicecombCSE Java SDK商业包列表增删说明序号artifactIdgroupid（不涉及修改）1foundation-config-cc已迁移至ServiceCombCSE Java-SDK商业包列表序号artifactIdgroupid（不涉及修改）1cse-adapter-springmvccom.huawei.paas.cse2cse-dependencycom.huawei.paas.cse3cse-handler-2pccom.huawei.paas.cse4cse-handler-cloud-extensioncom.huawei.paas.cse5cse-handler-performance-statscom.huawei.paas.cse6cse-handler-tcccom.huawei.paas.cse7cse-handler-tracing-apmcom.huawei.paas.cse8cse-handler-tracingcom.huawei.paas.cse9cse-narayanacom.huawei.paas.cse10cse-solution-service-enginecom.huawei.paas.cse11cse-solutionscom.huawei.paas.cse12foundation-authcom.huawei.paas.cse13paas-csecom.huawei.paas.cse

当有些业务处理比较耗时的时候，日志里面经常打印如下异常：2019-01-09 10:42:22,890 [ntloop-thread-0] ERROR Unhandled exception [io.vertx.core.impl.ContextImpl.lambda$wrapTask$2(ContextImpl.java:345)]java.lang.IllegalStateException: Response is closedat io.vertx.core.http.impl.HttpServerResponseImpl.checkValid(HttpServerResponseImpl.java:548)at io.vertx.core.http.impl.HttpServerResponseImpl.end0(HttpServerResponseImpl.java:401)at io.vertx.core.http.impl.HttpServerResponseImpl.end(HttpServerResponseImpl.java:319)at org.apache.servicecomb.foundation.vertx.http.VertxServerResponseToHttpServletResponse.internalFlushBuffer(VertxServerResponseToHttpServletResponse.java:122)at org.apache.servicecomb.foundation.vertx.http.VertxServerResponseToHttpServletResponse.lambda$flushBuffer$0(VertxServerResponseToHttpServletResponse.java:112)at io.vertx.core.impl.ContextImpl.lambda$wrapTask$2(ContextImpl.java:339)at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163)at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:404)at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:463)at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:884)at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)at java.lang.Thread.run(Thread.java:745)这个异常表示的是在给请求返回结果的时候，写结果发现连接已经关闭。这种情况通常发生在业务处理比较长的情况。这个日志在服务端打印（服务端是相对的）。和这个问题相关的配置由如下几个：客户端：cse.rest.client.connection.idleTimeoutInSeconds（缺省值30s）服务端：cse.rest.server.connection.idleTimeoutInSeconds（缺省值30s）如果业务处理时间超过这两个值的最小值，那么服务端就会报告这个异常。 

CSE JAVA SDK的线程池模型比较复杂，对于tomcat场景，以及Edge Service的vert.x场景，都有一个业务处理线程池(Edge Service的场景默认在reactive模式，是没有业务线程池的)。CSE设置的默认线程池的线程个数为2 * CPU个数。如果部分服务处理比较慢（比如评价时延>50ms），那么建议要设置一个较大的业务线程池，以提升吞吐量。如果所有接口都处理的很快，则不需要设置非常大的业务线程池，过多线程反而会因为线程调度，增加处理时延。如果一个微服务，有少量的几个接口处理非常耗时，需要考虑将这些接口放到独立的线程池执行（线程池隔离），防止访问慢的接口，影响访问快的接口。     线程池配置 （可以适当的抽时间学习下线程模型： https://bbs.huaweicloud.com/blogs/0a1a862f412611e89fc57ca23e93a89f）        通过配置项servicecomb.executors.default给业务接口制定执行线程池。配置项的的缺省值为servicecomb.executor.groupThreadPool，这个值是Bean的ID，CSE缺省的几个Bean ID如下：  <bean id="cse.executor.groupThreadPool" class="org.apache.servicecomb.core.executor.FixedThreadExecutor"/>   <alias name="cse.executor.groupThreadPool" alias="cse.executor.default"/>   <alias name="cse.executor.groupThreadPool" alias="servicecomb.executor.groupThreadPool"/>   <bean id="cse.executor.reactive" class="org.apache.servicecomb.core.executor.ReactiveExecutor"/>   <alias name="cse.executor.reactive" alias="servicecomb.executor.reactive"/>  2.       通过servicecomb.executors.Provider.[servicename.schemaid.operationId]给某个具体的接口指定不同的线程池。

有几种方式快速创建一个项目：通过ServiceComb脚手架： http://start.servicecomb.io/参考开发指南，下载一个示例项目： https://huaweicse.github.io/cse-java-chassis-doc/featured-topics/develop-microservice-using-cse.html使用CSE服务生成： https://console.huaweicloud.com/cse/?region=cn-north-1#/cse/tools

这个问题，谁遇到过呀？