fanjiwang
fanjiwang
serviceComb-java-chassis支持微服务直接的跨应用调用,调用格式是appID:serviceName,java-chassis SDK 这种方式做了特殊处理,mesher是否支持类似调用方式,比如调用格式为appID.serviceName 或者appID$serviceName,
涉及的类org.apache.servicecomb.common.rest.codec.param.RestClientRequestImpl 走读源码发现: 当formMap != null 时候,  当文件上传的附件为空的时候,不走doEndWithUpload()方法 
提供端接口定义: @PostMapping(path = "/upload", consumes = MediaType.MULTIPART_FORM_DATA) public String fileUpload(@RequestPart MultipartFile file, @RequestPart(value = "name", required = true) String name) { System.out.println(name); return "Upload success ..."; 消费端 调用逻辑: HttpHeaders headers...
问题现象:CSE客户端发起HTTPS调用时,偶现报错:SslHandshakeTimeoutException: handshake timed out after 10000ms 可能出现问题的原因分析: 1、CPU资源不足 首次SSL建连协商密钥使用非对称加密,CPU资源占用较高,CPU资源不足时可能存在导致响应变慢。 2、网络故障 可能的原因包括:网络闪断、网络延迟增大、网络连接不足。 3、服务进程性能问题 FullGC导致的JVM STW。 问题分析验证: 因xxx服务的频繁FullGC导致Tomcat周期性无法响应,部分FullGC时间达到10秒以上
可以监听微服务的启动事件,保证相关配置在B1实例注册事件之前拉取完成
> 请问指导文档里负载均衡章节的“根据实例属性进行路由转发”,是否可以完成上述功能? 服务提供者B默认的tag都是notReady,只有在B初始化完成后,B中的代码把自己的tag设置为Ready; 消费者配置只访问tag为Ready的B的实例。 如果可以实现,还有个疑问,下面文档中这句话如何理解“实例属性可以在microservice.yaml中指定,也可以通过服务中心的API进行修改”,在代码中需要如何设置tag的属性,还需要单独调用服务中的API接口吗?  可以调实例属性更新接口,在配置拉取完成后动态更新自身的实例属性
这个是注册中心服务端的能力 可以去这里咨询https://github.com/apache/servicecomb-service-center
错误日志现象: 2022-02-23 08:46:10,868]-[b5caf7279192835d]-[1002]-[https-jsse-nio-172.18.2.180-18443-exec-20]-[com.huawei.mateinfo.sdk.common.utils.MateInfoLogUtils.record(MateInfoLogUtils.java:38)]-[ERROR] rest failed, url=/adc-studio-project-mgt/web/rest/v1/projects/1013 org.apache.servicecomb.swagger.invocation.exception.InvocationException: InvocationException: code=408;msg=CommonExceptionData{code='SCB.00000004', message='Invocation Timeout.', dynamic={}} at org.apache.servicecomb.core.provider.consumer.SyncResponseExecutor.guardedWait(SyncResponseExecutor.java:85) ~[java-chassis-core-2.1.5-h0.gts.dsp.r68.jar:2.1.5-h0.gts.dsp.r68] at org.apache.servicecomb.core.provider.consumer.SyncResponseExecutor.waitResponse(SyncResponseExecutor.java:54) ~[java-chassis-core-2.1.5-h0.gts.dsp.r68.jar:2.1.5-h0.gts.dsp.r68] at org.apache.servicecomb.core.provider.consumer.InvokerUtils.innerSyncInvoke(InvokerUtils.java:160) ~[java-chassis-core-2.1.5-h0.gts.dsp.r68.jar:2.1.5-h0.gts.dsp.r68] at org.apache.servicecomb.provider.pojo.HandlerInvocationCaller.syncInvoke(HandlerInvocationCaller.java:40) ~[provider-pojo-2.1.5-h0.gts.dsp.r68.jar:2.1.5-h0.gts.dsp.r68] at org.apache.servicecomb.provider.pojo.HandlerInvocationCaller.call(HandlerInvocationCaller.java:34) ~[provider-pojo-2.1.5-h0.gts.dsp.r68.jar:2.1.5-h0.gts.dsp.r68] at org.apache.servicecomb.provider.pojo.Invoker.invoke(Invoker.java:71) ~[provider-pojo-2.1.5-h0.gts.dsp.r68.jar:2.1.5-h0.gts.dsp.r68]...
定位过程: 1. org.apache.servicecomb.core.provider.consumer.SyncResponseExecutor.guardedWait(SyncResponseExecutor.java:85) ~[java-chassis-core-2.1.5-h0.gts.dsp.r68.jar:2.1.5-h0.gts.dsp.r68] 该方法等待有240秒,但是业务没有配置240s 2. 定位org.apache.servicecomb.core.handler.impl.TransportClientHandler 确定该handler执行,并且org.apache.servicecomb.transport.rest.client.http.RestClientInvocation#invoke 请求由业务线程转移到网络线程中发送,该方法也执行 3. 但是查看服务端的日志,并没有access日志记录,服务端没有收到请求
> 复现条件: > > 1. 客户端日志挂载日志磁盘,此时服务调用异常 > 2. 清理日志磁盘以后,发起服务调用报408 Invocation Timeout