一、什么时机可以使用DynamicPropertyFactory.getInstance()读取配置
如果用spring,在place holder加载之后就可以使用,加载bean的过程中就可以读。 CSE初始化,是使用place holder来初始化的。 果要在更加之前读取, 只能使用local configuration, 具体可以参考java-chassis的config-cc代码实现:
https://github.com/apache/servicecomb-java-chassis/blob/master/dynamic-config/config-cc/src/main/java/org/apache/servicecomb/config/client/ConfigCenterConfig.java
二、io.vertx.core.VertxException: Connection was closed 可能原因
在做超时测试的时候,发现抛出如下异常:
2018-12-06 16:12:02,005 [ERROR] invoke failed, invocation=CONSUMER rest AutoProvider.serverMvc.SayHello org.apache.servicecomb.swagger.invocation.exception.DefaultExceptionToProducerResponseConverter.convert(DefaultExceptionToProducerResponseConverter.java:35)
io.vertx.core.VertxException: Connection was closed
2018-12-06 16:12:02,005 [WARN] bizkeeper command CONSUMER rest AutoProvider.serverMvc.SayHello failed due to InvocationException: code=490;msg=CommonExceptionData [message=Cse Internal Bad Request] org.apache.servicecomb.bizkeeper.BizkeeperCommand.lambda$null$1(BizkeeperCommand.java:82)
2018-12-06 16:12:02,005 [WARN] bizkeeper execution error, info=cause:InvocationException,message:InvocationException: code=490;msg=CommonExceptionData [message=Cse Internal Bad Request];cause:VertxException,message:Connection was closed org.apache.servicecomb.bizkeeper.BizkeeperHandler$1.onExecutionError(BizkeeperHandler.java:55)
2018-12-06 16:12:02,006 [WARN] catch error in bizkeeper:Consumer.AutoProvider.serverMvc.SayHello failed and fallback disabled. org.apache.servicecomb.bizkeeper.BizkeeperHandler.lambda$handle$0(BizkeeperHandler.java:79)
预期是客户端得到超时异常,但是实际捕获到了Connection was closed异常。
最后检查是服务端配置了如下配置项:
servicecomb.rest.server.connection.idleTimeoutInSeconds = 1
由于服务端设置了连接限制时间,关闭了连接。 当处理时间超过1秒的时候,就会出现这个异常了。
三、InvocationException: code=500;msg={message=Timeout when processing the request.}
2018-12-11 13:58:53,387|ERROR|pool-2-thread-5|1zcbErzhtZP7Lv4Im9m|httpclient.CBCHttpClientUtils 484|Failed to execute http request. Exception
InvocationException: code=500;msg={message=Timeout when processing the request.}
at org.apache.servicecomb.swagger.invocation.exception.ExceptionFactory.d**ate(ExceptionFactory.java:74)
at org.apache.servicecomb.swagger.invocation.exception.ExceptionFactory.create(ExceptionFactory.java:61)
at org.apache.servicecomb.swagger.invocation.Response.create(Response.java:93)
at org.apache.servicecomb.transport.rest.client.http.DefaultHttpClientFilter.extractResponse(DefaultHttpClientFilter.java:105)
at org.apache.servicecomb.transport.rest.client.http.DefaultHttpClientFilter.afterReceiveResponse(DefaultHttpClientFilter.java:128)
at org.apache.servicecomb.transport.rest.client.http.RestClientInvocation.lambda$processResponseBody$7(RestClientInvocation.java:200)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
这个异常发生在客户端。 和客户端请求超时不同,这个异常是服务端返回的错误,代表一个请求在服务端队列里面排队超过了设置的超时时间,服务端丢弃这个请求,不再处理。 可以通过servicecomb.rest.server.requestWaitInPoolTimeout设置这个排队时间,默认是30s。
但是通常30s已经是非常长的时间了,设置的太长, 还会触发客户端超时等。 需要做一系列其他配置。 所以一般这种情况发生的时候,需要考虑优化服务端性能。如果已经达到设计的系统上限,那么可以忽略这个错误。
四、Key/certificate is mandatory for SSL
启动CSE的服务的时候,报告:Key/certificate is mandatory for SSL
报告这个错误,是因为启用ssl的情况下需要配置证书。 可以参考这里https://docs.servicecomb.io/java-chassis/zh_CN/security/tls.html进行配置。
配置项里面的路径受ssl.sslCustomClass: org.apache.servicecomb.demo.DemoSSLCustom这个实现类的影响,可以定制他的实现。 缺省情况从当前工作目录查找配置的文件名。
五、Thread[transport-vert.x-eventloop-thread-4,5,main] has been blocked for 30711 ms, time limit is 2000
这个错误代表evenloop线程被阻塞,超过了缺省的2000ms限制,会打印阻塞堆栈。 从下面的堆栈有个核心行:
at org.apache.servicecomb.core.executor.ReactiveExecutor.execute(ReactiveExecutor.java:30)
可以看出,业务逻辑和处理链逻辑是采用reactive模式执行的。如果是edge service(网关服务),缺省就是reactive模式。当在网关出现这个错误的时候,很多时候就需要调整代码实现,将阻塞代码改为异步的方式。
如果不是网关,而是provider,缺省是线程池模式。 那么出现这个错误的可能原因是在项目中错误的引入edge-core这个模块了。 将这个jar包排除即可。 这个包里面提供了一个配置项,会将线程池模式设置为reactive模式。
2018-12-12 15:18:48,886 [WARN] Thread Thread[transport-vert.x-eventloop-thread-4,5,main] has been blocked for 30711 ms, time limit is 2000 io.vertx.core.impl.BlockedThreadChecker$1.run(BlockedThreadChecker.java:52)
io.vertx.core.VertxException: Thread blocked
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
at org.apache.servicecomb.core.provider.consumer.SyncResponseExecutor.waitResponse(SyncResponseExecutor.java:53)
at org.apache.servicecomb.core.provider.consumer.InvokerUtils.innerSyncInvoke(InvokerUtils.java:75)
at org.apache.servicecomb.provider.pojo.Invoker.syncInvoke(Invoker.java:161)
at org.apache.servicecomb.provider.pojo.Invoker.invoke(Invoker.java:157)
at com.sun.proxy.$Proxy30.SayHello(Unknown Source)
at com.huawei.paas.cse.demo.basicoperation.InterfaceBasicUtil.simpleInvoke(InterfaceBasicUtil.java:39)
at com.huawei.paas.cse.demo.pojo.client.ClientImpl.pojoclienttest(ClientImpl.java:28)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.apache.servicecomb.swagger.engine.SwaggerProducerOperation.doInvoke(SwaggerProducerOperation.java:180)
at org.apache.servicecomb.swagger.engine.SwaggerProducerOperation.syncInvoke(SwaggerProducerOperation.java:165)
at org.apache.servicecomb.swagger.engine.SwaggerProducerOperation.invoke(SwaggerProducerOperation.java:119)
at org.apache.servicecomb.core.handler.impl.ProducerOperationHandler.handle(ProducerOperationHandler.java:40)
at org.apache.servicecomb.core.Invocation.next(Invocation.java:189)
at org.apache.servicecomb.bizkeeper.BizkeeperCommand.lambda$construct$2(BizkeeperCommand.java:79)
at org.apache.servicecomb.bizkeeper.BizkeeperCommand$$Lambda$178/1809372843.call(Unknown Source)
at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:50)
at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)
at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:50)
at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)
at rx.Observable.unsafeSubscribe(Observable.java:8666)
at rx.internal.operators.OnSubscribeDefer.call(OnSubscribeDefer.java:52)
at rx.internal.operators.OnSubscribeDefer.call(OnSubscribeDefer.java:36)
at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:50)
at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)
at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:50)
at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)
at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:50)
at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)
at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:50)
at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)
at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:50)
at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)
at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:50)
at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)
at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:50)
at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)
at rx.Observable.unsafeSubscribe(Observable.java:8666)
at rx.internal.operators.OnSubscribeDefer.call(OnSubscribeDefer.java:52)
at rx.internal.operators.OnSubscribeDefer.call(OnSubscribeDefer.java:36)
at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:50)
at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)
at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:50)
at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)
at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:50)
at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)
at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:50)
at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)
at rx.Observable.unsafeSubscribe(Observable.java:8666)
at rx.internal.operators.OnSubscribeDefer.call(OnSubscribeDefer.java:52)
at rx.internal.operators.OnSubscribeDefer.call(OnSubscribeDefer.java:36)
at rx.Observable.subscribe(Observable.java:8759)
at rx.Observable.subscribe(Observable.java:8726)
at rx.Observable.subscribe(Observable.java:8619)
at org.apache.servicecomb.bizkeeper.BizkeeperHandler.handle(BizkeeperHandler.java:78)
at org.apache.servicecomb.core.Invocation.next(Invocation.java:189)
at org.apache.servicecomb.qps.ProviderQpsFlowControlHandler.handle(ProviderQpsFlowControlHandler.java:49)
at org.apache.servicecomb.core.Invocation.next(Invocation.java:189)
at org.apache.servicecomb.common.rest.AbstractRestInvocation.doInvoke(AbstractRestInvocation.java:205)
at org.apache.servicecomb.common.rest.AbstractRestInvocation.invoke(AbstractRestInvocation.java:178)
at org.apache.servicecomb.common.rest.AbstractRestInvocation.runOnExecutor(AbstractRestInvocation.java:162)
at org.apache.servicecomb.common.rest.AbstractRestInvocation.lambda$scheduleInvocation$0(AbstractRestInvocation.java:145)
at org.apache.servicecomb.common.rest.AbstractRestInvocation$$Lambda$170/1191009764.run(Unknown Source)
at org.apache.servicecomb.core.executor.ReactiveExecutor.execute(ReactiveExecutor.java:30)
at org.apache.servicecomb.common.rest.AbstractRestInvocation.scheduleInvocation(AbstractRestInvocation.java:130)
at org.apache.servicecomb.common.rest.RestProducerInvocation.invoke(RestProducerInvocation.java:52)
at org.apache.servicecomb.transport.rest.vertx.VertxRestDispatcher.onRequest(VertxRestDispatcher.java:194)
at org.apache.servicecomb.transport.rest.vertx.VertxRestDispatcher$$Lambda$95/1364287458.handle(Unknown Source)
at io.vertx.ext.web.impl.RouteImpl.handleContext(RouteImpl.java:219)
at io.vertx.ext.web.impl.RoutingContextImplBase.iterateNext(RoutingContextImplBase.java:120)
at io.vertx.ext.web.impl.RoutingContextImpl.next(RoutingContextImpl.java:133)
at org.apache.servicecomb.transport.rest.vertx.RestBodyHandler$BHandler.doEnd(RestBodyHandler.java:248)
at org.apache.servicecomb.transport.rest.vertx.RestBodyHandler$BHandler.end(RestBodyHandler.java:226)
at org.apache.servicecomb.transport.rest.vertx.RestBodyHandler.lambda$handle$0(RestBodyHandler.java:86)
at org.apache.servicecomb.transport.rest.vertx.RestBodyHandler$$Lambda$164/2001137338.handle(Unknown Source)
at io.vertx.core.http.impl.HttpServerRequestImpl.handleEnd(HttpServerRequestImpl.java:417)
at io.vertx.core.http.impl.Http1xServerConnection.handleEnd(Http1xServerConnection.java:482)
at io.vertx.core.http.impl.Http1xServerConnection.processMessage(Http1xServerConnection.java:456)
at io.vertx.core.http.impl.Http1xServerConnection.handleMessage(Http1xServerConnection.java:144)
at io.vertx.core.http.impl.HttpServerImpl$ServerHandlerWithWebSockets.handleMessage(HttpServerImpl.java:712)
at io.vertx.core.http.impl.HttpServerImpl$ServerHandlerWithWebSockets.handleMessage(HttpServerImpl.java:619)
at io.vertx.core.net.impl.VertxHandler.lambda$channelRead$1(VertxHandler.java:146)
at io.vertx.core.net.impl.VertxHandler$$Lambda$59/1535450007.run(Unknown Source)
at io.vertx.core.impl.ContextImpl.lambda$wrapTask$2(ContextImpl.java:337)
at io.vertx.core.impl.ContextImpl$$Lambda$25/1510403823.run(Unknown Source)
at io.vertx.core.impl.ContextImpl.executeFromIO(ContextImpl.java:195)
at io.vertx.core.net.impl.VertxHandler.channelRead(VertxHandler.java:144)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:286)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:310)
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:284)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at io.vertx.core.http.impl.Http1xOrH2CHandler.end(Http1xOrH2CHandler.java:61)
at io.vertx.core.http.impl.Http1xOrH2CHandler.channelRead(Http1xOrH2CHandler.java:38)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:286)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1434)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:965)
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:163)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:645)
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:580)
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:497)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:459)
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)
关于网关的工作模式,以及修改工作模式的配置项的说明参考文档: https://docs.servicecomb.io/java-chassis/zh_CN/edge/by-servicecomb-sdk.html
六、使用Tomcat作为服务器,并采用CSE客户端调用,低概率出现请求失败
问题现象和场景: 服务端使用Tomcat作为服务器, 客户端使用CSE调用。在大规模并发的场景下,低概率出现请求失败
问题原因:Tomcat默认会在一定周期内(IDLE),达到一定请求数后关闭连接(active requests)关闭HTTP连接,导致请求失败。
解决方案:
对于使用Tomcat + CSE SDK场景,使用Tomcat做HTTP协议接入的业务,临时规避方案如下(Tomcat的server.xml文件):
1、 maxKeepAliveRequests修改为-1
2、 keepAliveTimeout修改为10分钟
修改策略是:对于内部的RPC调用,尽量不要频繁的重建HTTP连接,HTTP空闲连接的回收时间配置长一些,5分钟或者10分钟,或者由CSE 消费端来控制,Tomcat服务端不用控制。
最终解决方案:CSE给Vert.X社区提问题单,在下一个CSE版本中修复连接池的BUG,即:如果消息发送时发现连接不可用,要立即失败,并按照业务的重试策略自动重试,对业务的效果就是业务不感知底层HTTP连接的关闭和自动重试,保障业务的成功率。
七、CSE如何配置多个服务中心、配置中心、监控中心地址及其常见错误
CSE支持配置多个服务中心、配置中心、监控中心地址,在一个实例故障的时候,自动切换到另外一个实例,增强了可靠性。目前有如下几种配置方法。
第一种,在microservice.yaml中指定:
cse: service: registry: address: http://127.0.0.1:30100,http://127.0.0.2:30100
第二种,通过JAVA参数指定
java -Dcse.service.registry.address=http://127.0.0.1:30100,http://127.0.0.2:30100 -jar Application.jar
这种方式也可以配套环境变量使用
export SC_ADDRESS=http://127.0.0.1:30100,http://127.0.0.2:30100 java -Dcse.service.registry.address=${SC_ADDRESS} -jar Application.jar
第三种,使用变量别名(Mapping)
如果用户依赖了cse-solution-service-engine这个组件,那么系统提供了默认的别名映射。
PAAS_CSE_ENDPOINT: - cse.service.registry.address - cse.config.client.serverUri PAAS_CSE_SC_ENDPOINT: - cse.service.registry.address PAAS_CSE_CC_ENDPOINT: - cse.config.client.serverUri
因此用户只需要设置环境变量即可
export PAAS_CSE_ENDPOINT=http://127.0.0.1:30100,http://127.0.0.2:30100
错误用法
由于archaius接口设计上的问题,下面这种用法是错误的。 会导致只有第一个地址被使用,第二个地址被忽略。
在microservice.yaml中指定:
cse: service: registry: address: ${SC_ADDRESS}
设置环境变量
export SC_ADDRESS=http://127.0.0.1:30100,http://127.0.0.2:30100
这种方式读取到的实际地址只有一个http://127.0.0.1:30100。因为archaius会将cse.service.registry.address解析为String类型,而SC_ADDRESS解析为List类型,在类型转换的时候,会取第一个元素。 一般的,涉及到配置的参数被当做数组进行解析,使用Place Holder的方式配置,都会出现类似问题。
参考材料: CSE配置层次和动态配置机制https://docs.servicecomb.io/java-chassis/zh_CN/general-development/config.html
八、租户链接CSE的服务中心进行服务注册发现需要授予哪些权限
租户的微服务通过AK/SK访问CSE服务。有些用户需要创建子账号访问CSE,这些用户需要分配下面的权限之一:
SvcStg Operator
SvcStg Admin
SvcStg Developer
对于服务注册发现场景,分配SvcStg Developer权限即可。
九、Mismatched content. Msg=Cannot deserialize instance of `java.lang.String` out of START_OBJECT token
在使用CSE开发REST接口,并使用postman或者客户端调用,经常出现:
Mismatched content. Msg=Cannot deserialize instance of `java.lang.String` out of START_OBJECT token
的错误。 这个错误的含义是将HTTP body转换为 REST接口定义的参数发生的,抛出异常的是jackson API。
2018-12-22 09:49:01.440 ERROR 3048 --- [pool-1-thread-1] o.a.s.common.rest.codec.RestCodec : Parameter is not valid for operation cse-reporting-service.ReportingEndpoint.addAlarm. Message is cause:MismatchedInputException,message:Cannot deserialize instance of `java.lang.String` out of START_OBJECT token
at [Source: (org.apache.servicecomb.foundation.vertx.stream.BufferInputStream); line: 1, column: 1].
2018-12-22 09:49:01.447 ERROR 3048 --- [pool-1-thread-1] o.a.s.c.rest.AbstractRestInvocation : unknown rest exception.
org.apache.servicecomb.swagger.invocation.exception.InvocationException: InvocationException: code=400;msg=CommonExceptionData [message=Parameter is not valid.]
at org.apache.servicecomb.common.rest.codec.RestCodec.restToArgs(RestCodec.java:72) ~[common-rest-1.1.0.B030.jar:1.1.0.B030]
at org.apache.servicecomb.common.rest.filter.inner.ServerRestArgsFilter.afterReceiveRequest(ServerRestArgsFilter.java:60) ~[common-rest-1.1.0.B030.jar:1.1.0.B030]
at org.apache.servicecomb.common.rest.AbstractRestInvocation.prepareInvoke(AbstractRestInvocation.java:226) [common-rest-1.1.0.B030.jar:1.1.0.B030]
at org.apache.servicecomb.common.rest.AbstractRestInvocation.invoke(AbstractRestInvocation.java:206) [common-rest-1.1.0.B030.jar:1.1.0.B030]
at org.apache.servicecomb.common.rest.AbstractRestInvocation.runOnExecutor(AbstractRestInvocation.java:196) [common-rest-1.1.0.B030.jar:1.1.0.B030]
at org.apache.servicecomb.common.rest.AbstractRestInvocation.lambda$scheduleInvocation$0(AbstractRestInvocation.java:159) [common-rest-1.1.0.B030.jar:1.1.0.B030]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) ~[na:1.8.0_111]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) ~[na:1.8.0_111]
at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_111]
下面解读下这个错误:
"Cannot deserialize instance of `java.lang.String`" 表面目标类型是一个String类型; "out of START_OBJECT token"表面HTTP body的内容,是一个对象,比如
1 |
|
String的json表示是需要用引号的,所以就报了上述错误。正确的传递参数应该是:
1 |
|
或者:
1 |
|
一般来说,发生这个错误,都是因为开发人员在业务代码中手工进行了json编码,框架再次进行json编码导致
使用CSE开发,业务在输入/输出层次,应该只关注model,而不要做编解码动作
十、实现ExceptionToProducerResponseConverter注意事项
ExceptionToProducerResponseConverter会在两个环节被调用:
1. 使用RestClient发送请求,出现失败的时候;
2. 服务端在将处理过程中捕获的异常编码为HTTP body写到流之前。
对于第一种场景,RestClient抛出的异常可能影响到后续的控制逻辑。比如重试、隔离。 重试会判断异常是否为某些特定异常,并且异常消息是否包含某些特定内容。 如果ExceptionToProducerResponseConverter将cause丢失掉了, 那么重试判断就会失效。
所以实现的时候,尽可能保留原始异常的cause信息。
1 |
|
下面的方法会丢失cause:
1 |
|
适用于JAVA SDK 2.3.56及其以上版本
十一、InstanceCacheChecker: |instance cache not match
早期的服务中心版本存在一个bug。当实例下线的时候,revision信息没有变化,SDK感知不到实例下线。 SDK为了检测这个BUG,做了一个功能,会定时(缺省是24小时)检测服务中心的实例列表和本地列表是否一致,不一致会发送告警,用户可以手工触发重新刷新SDK缓存。 (在CSE界面操作)
2018-12-19 09:11:00.970|[Service Center Task]|ERROR|[InstanceCacheChecker.java:119]|instance cache not match. appId=AppGallerySearchService, microservice=AppGallerySearchService:AppGalleryMicroContentService.
local cache: [{"instanceId":"0fa1021ff24911e888a800163e0b0521","serviceId":"0f95a43bf24911e888a800163e0b0521","endpoints":["rest://10.1.130.140:8087"],"hostName":"ncn-hispace-govportal-1-130-140","status":"UP","properties":{},"healthCheck":{"mode":"push","port":0,"interval":30,"times":3,"ttl":120},"environment":null,"stage":null,"dataCenterInfo":{"name":"AppMarket","region":"North-China","availableZone":"JiuXianQiao"}},{"instanceId":"78aa5835035f11e9a9c100163e0b085a","serviceId":"789d2f4f035f11e9a9c100163e0b085a","endpoints":["rest://10.1.130.140:18080"],"hostName":"ncn-hispace-govportal-1-130-140","status":"UP","properties":{},"healthCheck":{"mode":"push","port":0,"interval":30,"times":3,"ttl":120},"environment":null,"stage":null,"dataCenterInfo":{"name":"AppMarket","region":"North-China","availableZone":"RunZe"}}]
remote cache: [{"instanceId":"78aa5835035f11e9a9c100163e0b085a","serviceId":"789d2f4f035f11e9a9c100163e0b085a","endpoints":["rest://10.1.130.140:18080"],"hostName":"ncn-hispace-govportal-1-130-140","status":"UP","properties":{},"healthCheck":{"mode":"push","port":0,"interval":30,"times":3,"ttl":120},"environment":null,"stage":null,"dataCenterInfo":{"name":"AppMarket","region":"North-China","availableZone":"RunZe"}}]
这个功能可以帮助用户发现一些潜在问题,但是不是根本解决方案。 如果用户自己部署了服务中心,建议及时升级到最新版本, SDK也做好定期持续升级,避免老版本的BUG对业务产生影响。
十二、如何从头开始使用CSE搭建一个项目
有几种方式快速创建一个项目:
通过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