系统性问题：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

这个问题，谁遇到过呀？

租户的微服务通过AK/SK访问CSE服务。有些用户需要创建子账号访问CSE，这些用户需要分配下面的权限之一：SvcStg OperatorSvcStg AdminSvcStg Developer对于服务注册发现场景，分配SvcStg Developer权限即可。 

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

问题现象和场景：  服务端使用Tomcat作为服务器, 客户端使用CSE调用。在大规模并发的场景下，低概率出现请求失败问题原因：Tomcat默认会在一定周期内（IDLE），达到一定请求数后关闭连接(active requests)关闭HTTP连接，导致请求失败。 解决方案：对于使用Tomcat + CSE SDK场景，使用Tomcat做HTTP协议接入的业务，临时规避方案如下（Tomcat的server.xml文件）：1、  maxKeepAliveRequests修改为-12、  keepAliveTimeout修改为10分钟修改策略是：对于内部的RPC调用，尽量不要频繁的重建HTTP连接，HTTP空闲连接的回收时间配置长一些，5分钟或者10分钟，或者由CSE 消费端来控制，Tomcat服务端不用控制。最终解决方案：CSE给Vert.X社区提问题单，在下一个CSE版本中修复连接池的BUG，即：如果消息发送时发现连接不可用，要立即失败，并按照业务的重试策略自动重试，对业务的效果就是业务不感知底层HTTP连接的关闭和自动重试，保障业务的成功率。

最近在选型service mesh框架，对比istio和cse mesher。istio支持分布式跟踪，只需在应用调用http请求时，在http header里面添加相关的项即可。参考https://istio.io/docs/tasks/telemetry/distributed-tracing/CSE Mesher是否有类似的功能？如何配置？比如A -> A mesher -> B mesher -> B -> B mesher -> C mesher -> C想跟踪从A触发到B、C的请求，必须在B中传递相关跟踪的上下文才能保持链路的完整。

使用CSE开发的服务，client端发送请求访问server端的接口时，会去服务中心获取server端的endpoint和契约等信息，将查询到的endpoint塞到invocation中，然后发送请求到server端对应的endpoint；如果想要client端不发送给查询服务中心得到的endpoint，而是发送给另外指定的endpoint，以满足某些拨测场景，可以进行如下设置。1、在client端的配置文件里添加配置servicecomb.loadbalance.userDefinedEndpoint.enabled: true2、在localcontext里设置scb-endpoint的值，以rest或highway开头，格式为rest://127.0.0.1:8090，符合CSE的endpoint通用格式；3、发送请求即可；

注意：重试和隔离在不同的应用场景下存在不同的理解。 CSE 在负载均衡管理(loadbalance handler)和熔断容错管理(bizkeeper）模块存在针对不同场景的功能设计， 请注意区分。 负载均衡模块：https://docs.servicecomb.io/java-chassis/zh_CN/references-handlers/loadbalance/简单的描述：1. 网络错误 + 503错误码等情况可以触发重试。2. 网络错误 + 503错误码 + 超时等错误可以触发隔离。细节内容可以参考代码：Retry: https://github.com/apache/servicecomb-java-chassis/blob/master/handlers/handler-loadbalance/src/main/java/org/apache/servicecomb/loadbalance/DefaultRetryExtensionsFactory.javaIsolation: https://github.com/apache/servicecomb-java-chassis/blob/master/handlers/handler-loadbalance/src/main/java/org/apache/servicecomb/loadbalance/LoadbalanceHandler.java   参考isFailedResponse 关于隔离恢复：https://github.com/apache/servicecomb-java-chassis/blob/master/handlers/handler-loadbalance/src/main/java/org/apache/servicecomb/loadbalance/filter/IsolationDiscoveryFilter.java   参考allowVisit 内部线程只会触发快速隔离，不会触发恢复，参考： https://github.com/apache/servicecomb-java-chassis/blob/master/handlers/handler-loadbalance/src/main/java/org/apache/servicecomb/loadbalance/ServiceCombLoadBalancerStats.java  里面的Timer线程熔断容错管理模块：https://docs.servicecomb.io/java-chassis/zh_CN/references-handlers/bizkeeper/在实际的应用系统中，实例隔离和失败重试是保证服务可靠运行做重要的治理能力，这些能力在loadbalance模块提供。 此外， CSE还提供了bizkeeper模块，这个模块集成了Hystrix的隔离仓等能力，这个隔离能力是针对微服务或者接口级别的，在实际业务系统中，发挥作用比较少。 这个模块也有判读错误条件：consumer: 490异常。 比如网络操作、超时等。 参考：https://github.com/apache/servicecomb-java-chassis/blob/master/handlers/handler-bizkeeper/src/main/java/org/apache/servicecomb/bizkeeper/ConsumerBizkeeperCommand.javaprovider: 590异常。比如业务处理抛出的未知RuntimeException等。 参考：https://github.com/apache/servicecomb-java-chassis/blob/master/handlers/handler-bizkeeper/src/main/java/org/apache/servicecomb/bizkeeper/ProviderBizkeeperCommand.java

文档参考：  https://docs.servicecomb.io/java-chassis/zh_CN/general-development/file-download.html 代码示例： https://github.com/apache/servicecomb-java-chassis/blob/master/integration-tests/it-producer/src/main/java/org/apache/servicecomb/it/schema/DownloadSchema.java