cse的接口声明是否支持/*这种通配的匹配方式，例如springmvc中的@RequestMapping("/**")来通配所有请求 ，从serviceComb的源码中看貌似是不支持，那如果想做uri通配需要如何操作

微服务引擎专享版，配置了3个AZ，但只提供了两个服务注册地址，目前业务侧已配置两个服务注册地址。当某个AZ故障时，是否会影响到业务侧？

背景介绍：    使用Jmeter工具压测REST接口性能，Jmeter工具设置了1600个线程并发，REST请求是通过SLB转发给后端的服务。后端服务通信协议是Vertx。问题描述：    启动压测时，后端服务返回大量的590错误，REST请求并未走到后端服务的业务处理逻辑中。几分钟后590错误还是会偶尔出现。    搜索业务运行日志并未发现任何ERROR级别日志打印，但在接口日志中可以看到590的错误返回码。    在网上搜索说请求数超过并发连接数会返回590的错误码，但是我在CSE开发指导文档中没有搜索到设置并发连接数的地方。

使用edge调用后端的微服务，去掉了熔断等，request.timeout设置了30秒，但是调用微服务的时候edge直接590错误，但是对应的微服务方法也收到了，并执行，这个有遇到过么

microservice.yaml文件增加了如下配置：  handler:     chain:       Consumer:         default: loadbalance       Provider:         default: bizkeeper-provider   monitor:     client:       enable: true       serverUri: https://10.33.204.210:30109POM文件里增加依赖：        <dependency>             <groupId>com.huawei.paas.cse</groupId>             <artifactId>cse-handler-cloud-extension</artifactId>         </dependency>结果cse服务初始化失败：2020-12-14 17:14:01.673|[main]|ERROR|org.apache.servicecomb.core.SCBEngine|Failed to start ServiceComb due to errors and close: can not find handler :bizkeeper-provider~除此之外无其他有用的日志，请教CSE专家，这种问题怎么定位出原因？

请问下，本地下载 Local-CSE-1.0.3 ，双击“start.bat”启动之后，在启动 local-cse-config-center的时候（对应控制台命令为java -jar .\local-cse-config-center.jar），命令控制台报了一个错误如下：ERROR [vert.x-eventloop-thread-15] c.c.s.HealthVerticle[55] : health server listen fail java.net.BindException: Address already in use: bind         at java.base/sun.nio.ch.Net.bind0(Native Method)         at java.base/sun.nio.ch.Net.bind(Net.java:455)         at java.base/sun.nio.ch.Net.bind(Net.java:447)         at java.base/sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:227)         at io.netty.channel.socket.nio.NioServerSocketChannel.doBind(NioServerSocketChannel.java:130)         at io.netty.channel.AbstractChannel$AbstractUnsafe.bind(AbstractChannel.java:558)         at io.netty.channel.DefaultChannelPipeline$HeadContext.bind(DefaultChannelPipeline.java:1358)         at io.netty.channel.AbstractChannelHandlerContext.invokeBind(AbstractChannelHandlerContext.java:501)         at io.netty.channel.AbstractChannelHandlerContext.bind(AbstractChannelHandlerContext.java:486)         at io.netty.channel.DefaultChannelPipeline.bind(DefaultChannelPipeline.java:1019)         at io.netty.channel.AbstractChannel.bind(AbstractChannel.java:254)         at io.netty.bootstrap.AbstractBootstrap$2.run(AbstractBootstrap.java:366)         at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163)         at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasksFrom(SingleThreadEventExecutor.java:380)         at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:355)         at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:455)         at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:884)         at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)         at java.base/java.lang.Thread.run(Thread.java:834)请问，这个错误是哪里的端口被占用了还是其他什么原因么？应该如何排查解决？谢谢！

有诉求希望后台主动修改配置，请问CSE是否开放配置读取和修改的接口？

动动手指点一点，领取码豆换好礼1、 跟着指引做任务→领取任务a)       在会员中心页面下拉，找到“应用管理与运维任务>微服务管理”，单击“查看服务治理面板”，跟着指引做任务注意，如果您还不是微服务的用户，需要单击“同意授权”成为微服务用户后再领取任务2、 完成任务后返回会员中心查看码豆到账喜欢的老铁请下方回帖给小助手刷不存在的火箭和潜艇，让小助手在寒风中感受下老铁们如春天般的关怀，球球了

CSE升级到3.1.5版本，ServiceComb升级到2.1.2版本之后，通过edge调用其他服务，经常报No schema defined for xxx，我们自己实现了dispatcher，debug是生效的，而且schema也是存在的，也重启了edge和问题服务，这种大概是什么问题？之前使用2.5+1.3版本就没这个问题

这里中断的意思是：访问cse的时候报“Failed to create SSL connection”2020-09-17 02:17:53.370 | [vert.x-eventloop-thread-11] | ERROR | o.a.s.t.rest.client.http.RestClientInvocation | Failed to send request, local:not connected, remote:/10.31.31.29:20001.io.vertx.core.http.impl.NoStackTraceTimeoutException: The timeout period of 5000ms has been exceeded while executing POST /mgmt/v2/queryUserConfigs for server 10.31.31.29:200012020-09-17 02:17:53.374 | [vert.x-eventloop-thread-8] | ERROR | o.a.s.t.rest.client.http.RestClientInvocation | Failed to send request, local:not connected, remote:/10.31.31.29:20001.javax.net.ssl.SSLHandshakeException: Failed to create SSL connection        at io.vertx.core.net.impl.ChannelProvider$1.userEventTriggered(ChannelProvider.java:115)        at io.netty.channel.AbstractChannelHandlerContext.invokeUserEventTriggered(AbstractChannelHandlerContext.java:344)        at io.netty.channel.AbstractChannelHandlerContext.invokeUserEventTriggered(AbstractChannelHandlerContext.java:330)        at io.netty.channel.AbstractChannelHandlerContext.fireUserEventTriggered(AbstractChannelHandlerContext.java:322)        at io.netty.handler.ssl.SslUtils.handleHandshakeFailure(SslUtils.java:347)        at io.netty.handler.ssl.SslHandler$5.run(SslHandler.java:2004)        at io.netty.util.concurrent.PromiseTask.runTask(PromiseTask.java:98)        at io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:170)        at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)        at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)        at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:500)        at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)        at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)        at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)        at java.lang.Thread.run(Thread.java:748)Caused by: javax.net.ssl.SSLException: handshake timed out        at io.netty.handler.ssl.SslHandler$5.run(SslHandler.java:2001)        ... 9 common frames omittedrun log：2020-09-16 11:07:48.689 | ERROR | [http-nio-10.31.31.13-8080-exec-1408] |  10.31.31.13 | V295217425-3f7b-48f | failed to handle request,exception is:InvocationException: code=408;msg=CommonExceptionData [message=Request Timeout. Details: The timeout period of 5000ms has been exceeded while executing POST /channel/v2/ability/queryAbilityDetail for server 10.31.31.29:20000]2020-09-16 11:07:48.698 | ERROR | [http-nio-10.31.31.13-8080-exec-1412] |  10.31.31.13 | V2f56eee1c-cb57-4ce | failed to handle request,exception is:InvocationException: code=408;msg=CommonExceptionData [message=Request Timeout. Details: The timeout period of 5000ms has been exceeded while executing POST /channel/v2/recommend/newCardList for server 10.31.31.29:20000]

CSE开发的微服务注册GRPC后，微服务间能否使用GRCP通讯

CSE的通信模型切换为highway后，服务调用报如下错误2020-09-02 11:50:58.453 | ERROR | vert.x-eventloop-thread-6 |  | decode request header error, msgId=8 | org.apache.servicecomb.transport.highway.HighwayServerConnection.decodeRequestHeader(HighwayServerConnection.java:77)io.protostuff.ProtostuffException: The map was incorrectly serialized, expect value number 2, but be 7at io.protostuff.runtime.RuntimeMapFieldProtobuf.mergeFrom(RuntimeMapFieldProtobuf.java:97) ~[common-protobuf-1.2.0.B017r1.jar:1.5.9]at io.protostuff.runtime.RuntimeSchema.mergeFrom(RuntimeSchema.java:466) ~[protostuff-runtime-1.5.9.jar:1.5.9]at org.apache.servicecomb.codec.protobuf.utils.schema.NotWrapSchema.readObject(NotWrapSchema.java:40) ~[common-protobuf-1.2.0.B017r1.jar:1.2.0.B017r1]at org.apache.servicecomb.codec.protobuf.utils.WrapSchema.readObject(WrapSchema.java:39) ~[common-protobuf-1.2.0.B017r1.jar:1.2.0.B017r1]at org.apache.servicecomb.transport.highway.message.RequestHeader.readObject(RequestHeader.java:42) ~[transport-highway-1.2.0.B017r1.jar:1.2.0.B017r1]at org.apache.servicecomb.transport.highway.HighwayCodec.readRequestHeader(HighwayCodec.java:61) ~[transport-highway-1.2.0.B017r1.jar:1.2.0.B017r1]at org.apache.servicecomb.transport.highway.HighwayServerConnection.decodeRequestHeader(HighwayServerConnection.java:73) ~[transport-highway-1.2.0.B017r1.jar:1.2.0.B017r1]

云社区 博客 博客详情spring cloud 2.0 概述 【摘要】 传统单体架构就是单点应用，也就是在早期开发学习的ssm或ssh整合项目采用分层架构模式、数据库访问层、业务逻辑层、控制层，从前端到后端所有代码都是一个人写的微服务架构演变过程传统单体架构 =》 分布式架构 =》 soa面向服务架构 =》 微服务架构传统单体架构传统单体架构就是单点应用，也就是在早期开发学习的ssm或ssh整合项目采用分层架构模式、数据库访问层、业务逻辑层、控制层，从前端到后端所有代码都是一个人写的cn.itycu.controler ---springmvc 视图层 jsp/ftl cn.itycu.service ---业务逻辑层 cn.itycu.dao ---数据库访问层 将所有的代码都放入到同一个项目中，部署在同一个tomcat中该架构模式存在的优缺点优点：开发简单、运维简单缺点：该架构模式没有对业务逻辑进行拆分，这样子耦合度非常高，只适合小团队或者个人形式开发，不适合团队模式协同工作开发，维护性很难，如果系统中某个模块出现问题，会导致整个系统无法使用。应用场景：政府项目、管理系统、crm、oa，适合于小团队或个人进行开发分布式架构分布式架构模式基于传统的架构模式演变过来，将我们传统的单点系统实现根据业务拆分。会拆分为会员系统、订单系统、支付系统、秒杀系统等。从而降低整个项目的耦合度，这种架构模式开始慢慢适合于互联网公司开发。会员系统 memner.itycu.cn 支付系统 pay.itycu.cn 项目命名为系统意味：包含视图层和服务层soa面向服务架构sso单点登录系统，抽离出通用服务soa面向服务架构基于分布式架构模式演变过来，俗称服务化，也就是面向于服务与接口开发（服务开发），将共同存在的业务逻辑抽取成一个公共服务，提供给其他接口实现调用，服务与服务之间采用rpc远程调用技术。服务：只是有接口、没有视图层cn.itycu.service cn.itycu.dao能够解决我们的代码冗余性问题soa架构模式特点传统政府、银行项目还是保留的在使用webservicewebservice架构模式wsdl组件表示接口信息、方法、调用地址、参数soa架构模式传输协议采用soap协议（HTTP/https+xml）实现传输，在高并发情况下实现通讯协议存在大量的冗余性传输，而且非常占用带宽。所以后来微服务架构中使用json替代了xml。soa架构模式实现方案webservice或者esb企业服务总线，底层采用soap传输协议。soa架构模式存在缺点前后端分离就是对我们控制层和业务逻辑实现区分，前端控制可以采用vue调用我们后端接口（http+json）采用soap协议实现通讯，xml传输非常重，效率比较低。服务化管理和治理设施不够完善依赖于中心服务发现机制不适合前后端分离架构模式微服务架构微服务架构模式基于soa架构模式演变过来的，比soa架构迷失对服务拆分力度会更加精细，采用前后端分离模式让专业的人做专业的事（专注），目的可以实现高效率开发。微服务架构中，每个服务之间都是互不影响，每个服务必须要独立部署、运维、互不影响，微服务架构模式非常轻巧，轻量级、适合于互联网公司开发模式。服务与服务之间通讯的协议采用restful形式，数据交换格式采用http+json格式实现传输整个过程中，采用二进制，所以http协议可以实现跨语言的平台，并且和其他语言实现通讯，所以为什么开放都是采用http+json格式传输SOA架构与微服务架构有哪些区别微服务架构模式比soa架构模式，更加适合于互联网公司敏捷、高效、快速迭代版本开发，因为力度非常精细。微服务架构模式比soa架构模式拆分力度更加精细，提倡让专业的人做专业的事，目的是实现高效的开发，每个服务与服务之间互不影响，每个服务都是单独独立数据库、redis连接、MQ等。并且都是实现独立部署，整个微服务架构更加轻量级。在soa架构中，有可能纯在多个服务共享同一个数据库，但是微服务架构必须强调每个都是独立数据库部署，互不影响。微服务架构基于soa架构模式演变过来，继承了soa架构的优点，在微服务架构中去除soa架构中soap协议和esp企业服务总线。改为http+json形式传输我们的数据。esb企业服务总线解决多系统间跨语言无法实现通讯的问题，对我们的数据实现转换，可以提供可靠的消息传输。一般情况我们采用http+json传输数据，不需要esb对数据进行转换。通讯协议服务拆分力度迭代微服务架构中可能会存在哪些问题分布式事务解决方案（rabbitmq、rocketmq事务消息、lcn（淘汰）、setata）最终一级概念分布式任务调度平台（xxl-job、elastic-job）分布式服务注册与发现（eureka、consul、zookeeper、nacos）分布式日志采集系统elk+kafka分布式服务最综与调用链系统zipkin分布式服务配置中心（spring cloud config/携程阿波罗/nacos/disconfig）微服务架构中有个非常重要的概念：独立部署、可配置、动态化。为什么要使用到spring cloudspring cloud 并不是一个rpc远程调用框架，而是一个微服务全家桶的解决方案的框架。理念就是***服务解决我们在微服务架构中遇到的问题。服务治理：eureka分布式配置：config客户端调用工具：rest/feign客户 rpc远程调用说明：阿里巴巴、腾讯、百度注意：大家如果去一些比较大型的互联网公司中，整个公司内部实现rpc通讯的框架、服务帮助治理都是内部自己研发。rpc远程调用框架：HTTPclent、dubbo、feign、grpc、基于netty手写rpcspring cloud一代和二代的区别spring cloud第一代实际上采用Netflix开源的组件整合微服务解决方案。spring cloud第二代实际上就是自己研发和国内的优秀的服务解决微服务框架进行组合。nacos实现服务注册于发现微服务服务治理核心概念Nacos产生背景rpc远程调用框架：HTTP client、grpc、dubbo、rest、openfeign等。传统rpc远程调用中存在哪些问题？超时、安全、服务与服务之间的url地址管理在我们的微服务架构通讯中，服务间依赖非常大，如果使用传统方式管理我们的服务，非常麻烦，所以采用url治理技术，可以实现我们整个实现动态服务注册与发现、本地负载均衡、容错等nacos分布式注册与发现功能 | 分布式配置中心产生于rpc远程调用中，服务的url的治理传统服务注册中心的实现方式把每个服务器的地址信息和端口号人工存放到数据库表中IdserviceIP端口号1itycu.cn192.168.1.180802itycu.cn192.168.1.18000维护成本高没有实现动态自动化基于数据库形式实现服务url治理的缺点分布式注册中心实现原理注册中心的作用管理整个微服务url地址可以实现动态感知注册中心：duboo依赖zookeeper、eureka、consul、nacos、redis、数据库nacos与eureka的区别eureka与zookeeper的区别注册中心的原理keyIP端口号服务名称192.168.1.18080生产者启动时，根据这种存储方式注册到微服务注册中心根据以上存储方式的服务名称获取到IP地址和端口号获取到地址后在本地实现rpc远程调用生产者：提供我们接口被其他服务调用消费者：调用接口实现服务服务注册：提供服务接口地址信息存放Naxos基本介绍实现注册中心和分布式配置中心默认账号密码：nacos使用命令模式实现对nacos的注册使用discovertyClient从注册中心获取接口地址使用rest Template实现rpc远程调用纯手写本地负载均衡轮询算法实现线下服务动态感知

微服务架构演变过程传统单体架构 =》 分布式架构 =》 soa面向服务架构 =》 微服务架构传统单体架构传统单体架构就是单点应用，也就是在早期开发学习的ssm或ssh整合项目采用分层架构模式、数据库访问层、业务逻辑层、控制层，从前端到后端所有代码都是一个人写的cn.itycu.controler ---springmvc 视图层 jsp/ftl cn.itycu.service ---业务逻辑层 cn.itycu.dao ---数据库访问层 将所有的代码都放入到同一个项目中，部署在同一个tomcat中该架构模式存在的优缺点优点：开发简单、运维简单缺点：该架构模式没有对业务逻辑进行拆分，这样子耦合度非常高，只适合小团队或者个人形式开发，不适合团队模式协同工作开发，维护性很难，如果系统中某个模块出现问题，会导致整个系统无法使用。应用场景：政府项目、管理系统、crm、oa，适合于小团队或个人进行开发分布式架构分布式架构模式基于传统的架构模式演变过来，将我们传统的单点系统实现根据业务拆分。会拆分为会员系统、订单系统、支付系统、秒杀系统等。从而降低整个项目的耦合度，这种架构模式开始慢慢适合于互联网公司开发。会员系统 memner.itycu.cn 支付系统 pay.itycu.cn 项目命名为系统意味：包含视图层和服务层soa面向服务架构sso单点登录系统，抽离出通用服务soa面向服务架构基于分布式架构模式演变过来，俗称服务化，也就是面向于服务与接口开发（服务开发），将共同存在的业务逻辑抽取成一个公共服务，提供给其他接口实现调用，服务与服务之间采用rpc远程调用技术。服务：只是有接口、没有视图层cn.itycu.service cn.itycu.dao能够解决我们的代码冗余性问题soa架构模式特点传统政府、银行项目还是保留的在使用webservicewebservice架构模式wsdl组件表示接口信息、方法、调用地址、参数soa架构模式传输协议采用soap协议（HTTP/https+xml）实现传输，在高并发情况下实现通讯协议存在大量的冗余性传输，而且非常占用带宽。所以后来微服务架构中使用json替代了xml。soa架构模式实现方案webservice或者esb企业服务总线，底层采用soap传输协议。soa架构模式存在缺点前后端分离就是对我们控制层和业务逻辑实现区分，前端控制可以采用vue调用我们后端接口（http+json）采用soap协议实现通讯，xml传输非常重，效率比较低。服务化管理和治理设施不够完善依赖于中心服务发现机制不适合前后端分离架构模式微服务架构微服务架构模式基于soa架构模式演变过来的，比soa架构迷失对服务拆分力度会更加精细，采用前后端分离模式让专业的人做专业的事（专注），目的可以实现高效率开发。微服务架构中，每个服务之间都是互不影响，每个服务必须要独立部署、运维、互不影响，微服务架构模式非常轻巧，轻量级、适合于互联网公司开发模式。服务与服务之间通讯的协议采用restful形式，数据交换格式采用http+json格式实现传输整个过程中，采用二进制，所以http协议可以实现跨语言的平台，并且和其他语言实现通讯，所以为什么开放都是采用http+json格式传输SOA架构与微服务架构有哪些区别微服务架构模式比soa架构模式，更加适合于互联网公司敏捷、高效、快速迭代版本开发，因为力度非常精细。微服务架构模式比soa架构模式拆分力度更加精细，提倡让专业的人做专业的事，目的是实现高效的开发，每个服务与服务之间互不影响，每个服务都是单独独立数据库、redis连接、MQ等。并且都是实现独立部署，整个微服务架构更加轻量级。在soa架构中，有可能纯在多个服务共享同一个数据库，但是微服务架构必须强调每个都是独立数据库部署，互不影响。微服务架构基于soa架构模式演变过来，继承了soa架构的优点，在微服务架构中去除soa架构中soap协议和esp企业服务总线。改为http+json形式传输我们的数据。esb企业服务总线解决多系统间跨语言无法实现通讯的问题，对我们的数据实现转换，可以提供可靠的消息传输。一般情况我们采用http+json传输数据，不需要esb对数据进行转换。通讯协议服务拆分力度迭代微服务架构中可能会存在哪些问题分布式事务解决方案（rabbitmq、rocketmq事务消息、lcn（淘汰）、setata）最终一级概念分布式任务调度平台（xxl-job、elastic-job）分布式服务注册与发现（eureka、consul、zookeeper、nacos）分布式日志采集系统elk+kafka分布式服务最综与调用链系统zipkin分布式服务配置中心（spring cloud config/携程阿波罗/nacos/disconfig）微服务架构中有个非常重要的概念：独立部署、可配置、动态化。为什么要使用到spring cloudspring cloud 并不是一个rpc远程调用框架，而是一个微服务全家桶的解决方案的框架。理念就是***服务解决我们在微服务架构中遇到的问题。服务治理：eureka分布式配置：config客户端调用工具：rest/feign客户 rpc远程调用说明：阿里巴巴、腾讯、百度注意：大家如果去一些比较大型的互联网公司中，整个公司内部实现rpc通讯的框架、服务帮助治理都是内部自己研发。rpc远程调用框架：HTTPclent、dubbo、feign、grpc、基于netty手写rpcspring cloud一代和二代的区别spring cloud第一代实际上采用Netflix开源的组件整合微服务解决方案。spring cloud第二代实际上就是自己研发和国内的优秀的服务解决微服务框架进行组合。nacos实现服务注册于发现微服务服务治理核心概念Nacos产生背景rpc远程调用框架：HTTP client、grpc、dubbo、rest、openfeign等。传统rpc远程调用中存在哪些问题？超时、安全、服务与服务之间的url地址管理在我们的微服务架构通讯中，服务间依赖非常大，如果使用传统方式管理我们的服务，非常麻烦，所以采用url治理技术，可以实现我们整个实现动态服务注册与发现、本地负载均衡、容错等nacos分布式注册与发现功能 | 分布式配置中心产生于rpc远程调用中，服务的url的治理传统服务注册中心的实现方式把每个服务器的地址信息和端口号人工存放到数据库表中IdserviceIP端口号1itycu.cn192.168.1.180802itycu.cn192.168.1.18000维护成本高没有实现动态自动化基于数据库形式实现服务url治理的缺点分布式注册中心实现原理注册中心的作用管理整个微服务url地址可以实现动态感知注册中心：duboo依赖zookeeper、eureka、consul、nacos、redis、数据库nacos与eureka的区别eureka与zookeeper的区别注册中心的原理keyIP端口号服务名称192.168.1.18080生产者启动时，根据这种存储方式注册到微服务注册中心根据以上存储方式的服务名称获取到IP地址和端口号获取到地址后在本地实现rpc远程调用生产者：提供我们接口被其他服务调用消费者：调用接口实现服务服务注册：提供服务接口地址信息存放Naxos基本介绍实现注册中心和分布式配置中心默认账号密码：nacos使用命令模式实现对nacos的注册使用discovertyClient从注册中心获取接口地址使用rest Template实现rpc远程调用纯手写本地负载均衡轮询算法实现线下服务动态感知

服务通过边缘服务进行转发请求到单体微服务。场景：1、目标服务正在重启，转发返回490           2、目标服务连接超时，转发返回490处理：想通过熔断--容错--自定义回退策略进行处理，进行转换HTTP状态码500然后返回；问题：现在配置了熔断降级回退的策略，但是不生效，            1、目标服务未启动，没有进入自定义回退处理类；            2、转发目标服务连接超时，超时时间还是默认30s，不是配置的10s，且不进入自定义的回退处理类；            3、另外问下590场景是什么？怎么样可以复现？边缘服务转发配置：降级配置：容错后处理策略：处理类：