华为云用户手册

适用场景 Spring Boot、Spring Cloud广泛应用于构建微服务应用。使用ServiceComb引擎托管Spring Cloud应用，主要目的是使用高可靠的商业中间件替换开源组件，对应用系统进行更好地管理和运维，改造过程应尽可能降低对业务逻辑的影响。适用于如下场景： 基于Spring Boot开发的应用系统，不具备微服务基本能力。应用系统通过集成Spring Cloud Huawei，具备服务注册发现、动态配置管理等能力。 基于Spring Cloud开源技术体系开发的应用系统，例如已经采用Eureka实现注册发现、采用Nacos实现动态配置，应用系统通过集成Spring Cloud Huawei，使用高可靠的商业中间件替换开源中间件，降低维护成本。 基于Spring Cloud其他开发体系，例如Spring Cloud Alibaba、Spring Cloud Azure等构建的云原生应用，使用Spring Cloud Huawei迁移到华为云运行。

约束限制 Nacos对Eureka的兼容，主要是兼容Eureka服务端侧的API，将服务侧注册的客户端实例信息进行保存与刷新，因此如果您仅使用Eureka作为注册中心，那么Nacos的诸多特性如命名空间和配置管理是不能使用的。 使用Eureka作为客户端，仅能在Nacos的“服务管理”中进行查阅，Eureka服务均使用Nacos的默认属性进行展示，即： 默认命名空间：public。 默认分组名称：DEFAULT_GROUP。 在Nacos中在“服务管理”页面创建服务的“保护阈值”设置的值属于Nacos的特性，无法作用于Eureka服务。

前置条件 已创建云容器引擎（CCE），创建CCE请参考创建CCE集群。 CCE集群版本需要大于等于1.15。 应用的基础镜像中，需要安装JDK ( 版本为1.8及以上版本 )。 已安装kubectl命令，安装kubectl命令请参考通过kubectl连接集群中相关操作。 已创建ServiceComb引擎实例，详情请参考创建ServiceComb引擎。 CCE集群与ServiceComb引擎处于相同的VPC网络下。 给Sermant Injector预留200m左右的cpu资源和300Mi左右的memory资源。 Sermant Injector版本要求1.0.11及以上，Sermant Agent镜像版本要求1.0.9及以上。

概述 CS E提供Sermant Agent，支持Dubbo应用无需任何修改接入ServiceComb引擎，当前已支持应用注册发现、标签路由功能。 Sermant Agent是基于Sermant开源社区构建的、用于CSE微服务治理场景的Agent。 Sermant Agent基于Java Agent技术实现，应用通过Sermant Agent可实现无代理、非侵入方式接入ServiceComb引擎，并获得标签路由能力。 此功能目前处于公测阶段，当前仅在华东-上海一支持。 父主题： 通过Sermant Agent托管Dubbo应用

前提条件 已创建云容器引擎（CCE），创建CCE请参考创建CCE集群。 CCE集群版本需要大于等于1.15。 已安装kubectl命令，安装kubectl命令请参考通过kubectl连接集群中相关操作。 已创建ServiceComb引擎实例，详情请参考创建ServiceComb引擎。 CCE与ServiceComb引擎处于相同的VPC网络下。 下载Sermant-examples到本地并解压。 本地编译构建打包机器环境已安装了Java JDK、Maven，并且能够访问Maven中央库。 已在CCE集群上部署Sermant Injector，详情请参考通过模板管理页面部署Sermant Injector将应用接入ServiceComb引擎或者通过Helm客户端部署Sermant Injector。

部署Spring Cloud应用 打包Sermant-examples。 在“Sermant-examples”根目录下，打开cmd命令，执行mvn clean package命令，对项目进行打包编译。编译成功后，获取下表中的两个软件包。 表1 软件包列表 软件包所在目录 软件包名称 说明 Sermant-examples/registry-demo/spring-cloud-registry-demo/spring-cloud-registry-consumer/target spring-cloud-registry-consumer.jar 服务消费者 Sermant-examples/registry-demo/spring-cloud-registry-demo/spring-cloud-registry-provider/target spring-cloud-registry-provider.jar 服务生产者 把spring-cloud-registry-consumer.jar复制到“Sermant-examples/registry-demo/spring-cloud-registry-demo/deployment/images/consumer”中。 把spring-cloud-registry-provider.jar复制到“Sermant-examples/registry-demo/spring-cloud-registry-demo/deployment/images/provider”中。 制作镜像。 登录已安装kubectl命令且已部署Sermant Injector的CCE集群中的节点。 把“Sermant-examples/registry-demo/spring-cloud-registry-demo”中的“deployment”文件夹上传至已登录的CCE集群中的节点上。 请参考使用容器引擎客户端上传镜像制作docker镜像，其中，使用到的Dockerfile请参考“Sermant-examples/registry-demo/spring-cloud-registry-demo/deployment/images/consumer”与“Sermant-examples/registry-demo/spring-cloud-registry-demo/deployment/images/provider”目录下的Dockerfile文件按需修改。 部署spring-cloud-registry-consumer.yaml与spring-cloud-registry-provider.yaml。 修改镜像名。 将已上传deployment文件夹到CCE集群中的节点中的“deployment/k8s/spring-cloud-registry-consumer.yaml“与“deployment/k8s/spring-cloud-registry-provider.yaml“中的镜像名修改为您所制作的镜像名。 在已上传deployment文件夹到CCE集群中的节点中的“deployment/k8s“目录下，执行如下命令部署spring-cloud-registry-consumer.yaml与spring-cloud-registry-provider.yaml： kubectl create -f spring-cloud-registry-consumer.yaml kubectl create -f spring-cloud-registry-provider.yaml 若需配置APP名称（默认default）、版本（形如a.b.c的格式，其中a、b、c均为数字，默认为1.0.0）请在yaml中增加SERVICE_META_APPLICATION与SERVICE_META_VERSION环境变量进行配置。如下所示： 验证应用接入ServiceComb引擎。 参考查看微服务列表查看应用（服务名为spring-cloud-registry-consumer与spring-cloud-registry-provider）是否已接入ServiceComb引擎。

前置条件 已创建云容器引擎（CCE），创建CCE请参考创建CCE集群。 CCE集群版本需要大于等于1.15。 应用的基础镜像中，需要安装JDK ( 版本为1.8及以上版本 )。 已安装kubectl命令，安装kubectl命令请参考通过kubectl连接集群中相关操作。 已创建ServiceComb引擎实例，详情请参考创建ServiceComb引擎。 CCE集群与ServiceComb引擎处于相同的VPC网络下。 给Sermant Injector预留200m左右的cpu资源和300Mi左右的memory资源。 Sermant Injector版本要求1.0.11及以上，Sermant Agent镜像版本要求1.0.9及以上。

标签路由 标签路由版本支持： Spring Cloud Spring Boot Spring Cloud Openfeign RestTemplate Spring Cloud Loadbalancer Spring Cloud Netflix Ribbon Spring Cloud Gateway Spring Cloud Netflix Zuul Edgware.SR2+ 1.5.x 1.4.7.RELEASE 4.3.6.RELEASE - 1.4.7.RELEASE - 1.4.7.RELEASE Finchley.x 2.0.x 2.0.x 5.0.x - 2.0.x - 2.0.x Greenwich.x 2.1.x 2.1.x 5.1.x - 2.1.x - 2.1.x Hoxton.x 2.2.x、2.3.x 2.2.x 5.2.x 2.2.5.RELEASE+ 2.2.x 2.2.x 2.2.x 2020.0.x 2.4.x、2.5.x 3.0.x 5.3.x 3.0.x - 3.0.x - 2021.0.0 2.6.x 3.1.x 5.3.x 3.1.x - 3.1.x -

配置管理 Spring Boot Nacos Config Zookeeper Config 1.5.0.RELEASE - 2.6.2 1.5.0.RELEASE+ 1.2.0.RELEASE+ Nacos Config为maven依赖的spring-cloud-starter-alibaba-nacos-config。 Zookeeper Config为maven依赖的spring-cloud-starter-zookeeper-config。 配置管理能力需配合注解@RefreshScope、@Value、@ConfigurationProperties使用。

概述 CSE提供Sermant Agent，支持Spring Cloud应用无需任何修改接入ServiceComb引擎，当前已支持应用注册发现、配置、优雅上下线、标签路由等功能。 此功能目前处于公测阶段，当前仅在华东-上海一支持。 Sermant Agent是基于Sermant开源社区构建的、用于CSE微服务治理场景的Agent。 Sermant Agent基于Java Agent技术实现，应用通过Sermant Agent可实现无代理、非侵入方式接入CSE。 父主题： 通过Sermant Agent托管Spring Cloud应用

功能介绍 随着istio服务网格的发展，越来越多的应用都会接入服务网格，Sermant Agent提供了一种能让Spring Cloud应用也能访问服务网格中的应用的解决方案。 Spring Cloud应用访问istio应用的部署图如下： istio应用需要注册到istio中，不限制语言，Spring Cloud应用不必注册到istio中，Spring Cloud应用部署的环境可以是ECS/CCE/ASM。Spring Cloud应用会通过Sermant Agent进行istio中的服务发现，然后Spring Cloud应用便可以像调用其它Spring Cloud应用一样，通过服务名调用istio中的服务。 此功能目前处于公测阶段，当前仅在华东-上海一支持。 当ServiceComb引擎为2.x版本且未开启安全认证时，支持此功能。 Sermant Injector版本要求1.0.11及以上，Sermant Agent镜像版本要求1.0.9及以上。

设置服务路由策略 配置项：servicecomb.routeRule，配置内容： providerA: | - precedence: 2 match: headers: id: exact: '1' caseInsensitive: false route: - weight: 0 tags: group: base - weight: 100 tags: group: gray - precedence: 1 route: - weight: 100 tags: group: base - weight: 0 tags: group: gray providerB: | - precedence: 2 match: headers: id: exact: '1' caseInsensitive: false route: - weight: 0 tags: group: base - weight: 100 tags: group: gray - precedence: 1 route: - weight: 100 tags: group: base - weight: 0 tags: group: gray 服务路由策略设置说明： 请求头的id参数值精确匹配为1时，consumer的所有请求流量都是从providerA-gray流向providerB-gray。 请求头的id参数值为其他任意值，consumer的所有请求流量都是从providerA流向providerB。

Sermant Agent监听配置范围 Sermant Agent使用CSE作为配置中心时，监听的范围有以下三个： app=default&environment=&service={服务名} app=default&environment= public=default app对应为“应用”值； environment对应为“环境”； service对应为“微服务名称”； public为公共配置。 一般设置为app=default&environment=作为通用路由设置。

前提条件 已创建云容器引擎（CCE），创建CCE请参考创建CCE集群。 CCE集群版本需要大于等于1.15。 已安装kubectl命令，安装kubectl命令请参考通过kubectl连接集群相关操作。 已创建未开启安全认证的ServiceComb引擎实例，详情请参考创建ServiceComb引擎。 本地编译构建打包机器环境已安装了Java JDK、Maven，并且能够访问Maven中央库。 Sermant Agent开源版本要求1.0.6及以上。

操作步骤 为CCE集群安装sermant-injector，请参考CCE部署场景接入指南。 为工作负载（deployment）中的微服务配置版本号或标签。 在下图所示位置为工作负载（deployment）配置环境变量，配置环境变量后，应用注册时，会使用该环境变量进行注册。 apiVersion: app/v1 kind: Deployment metadata: name: dubbo-providerB labels: app: dubbo-providerB spec: replicas: 1 selector: matchLabels: app: dubbo-providerB template: metadata: labels: app: dubbo-providerB sermant-injection: enabled spec: containers: - name: dubbo-providerB image: dubbo-providerB:1.0.0 imagePullPolicy: IfNotPresent env: - name: "SERVICE_META_VERSION" value: "2.0.0" - name: "SERVICE_META_PA RAM ETERS" value: "group:gray" ports: - containerPort: 8004 imagePullSecrets: - name: default-secret 其中： 键SERVICE_META_VERSION，值为服务注册的版本号（如a.b.c的格式，其中a、b、c均为数字），标签应用需要修改为不同于正常应用的版本号。 键SERVICE_META_PARAMETERS，值为服务注册时的自定义标签（形如tag1:value1,tag2:value2），即标签名与标签值以英文冒号分隔，多个标签之间以英文逗号分隔。 当Sermant Agent为1.0.0及以下版本时，使用键为SERVICECOMB_INSTANCE_PROPS。 一般，如果用版本号进行路由，则只需配置SERVICE_META_VERSION，如果用自定义标签进行路由，则只需配置SERVICE_META_PARAMETERS。 为工作负载（deployment）打上标签并重启相关服务。 在下图所示位置为工作负载（deployment）打上标签sermant-injection: enabled。打上标签后，sermant-injector会在Pod重启时自动挂载Sermant Agent，从而通过Sermant Agent注册到CSE上。

下发路由规则配置 下发路由规则配置，详情请参考配置管理。 路由规则说明示例： --- - precedence: 2 # 优先级，数字越大，优先级越高。 match: # 请求匹配规则。0..N个，不配置表示匹配。 headers: # http header匹配 id: # 如果配置了多个header，那么所有的header规则都必须和请求匹配 exact: '1' # 配置策略，等于1，详细配置策略见配置策略表。 caseInsensitive: false # false:不区分大小写（默认）,true:区分大小写。配置为false时，将统一转为大写进行比较 route: # 路由规则 - weight: 20 # 权重值 tags: version: 1.0.0 # 实例标记。满足标记条件的实例放到这一组。 - weight: 80 # 权重值 tags: version: 1.0.1 # 实例标记。满足标记条件的实例放到这一组。 - precedence: 1 route: - weight: 20 tags: group: red - weight: 80 tags: group: green

操作步骤 为CCE集群安装sermant-injector，请参考CCE部署场景接入指南。 为工作负载（deployment）中的微服务配置版本号或标签。 在下图所示位置为工作负载（deployment）配置环境变量，配置环境变量后，应用注册时，会使用该环境变量进行注册。 apiVersion: app/v1 kind: Deployment metadata: name: cloud-providerB labels: app: cloud-providerB spec: replicas: 1 selector: matchLabels: app: cloud-providerB template: metadata: labels: app: cloud-providerB sermant-injection: enabled spec: containers: - name: cloud-providerB image: cloud-providerB:1.0.0 imagePullPolicy: IfNotPresent env: - name: "SERVICE_META_VERSION" value: "2.0.0" - name: "SERVICE_META_PARAMETERS" value: "group:gray" ports: - containerPort: 8004 imagePullSecrets: - name: default-secret 其中： 键SERVICE_META_VERSION，值为服务注册的版本号（如a.b.c的格式，其中a、b、c均为数字），标签应用需要修改为不同于正常应用的版本号。 键SERVICE_META_PARAMETERS，值为服务注册时的自定义标签（形如tag1:value1,tag2:value2），即标签名与标签值以英文冒号分隔，多个标签之间以英文逗号分隔。 当Sermant Agent为1.0.0及以下版本时，使用键为SERVICECOMB_INSTANCE_PROPS。 一般，如果用版本号进行路由，则只需配置SERVICE_META_VERSION，如果用自定义标签进行路由，则只需配置SERVICE_META_PARAMETERS。 为工作负载（deployment）打上标签并重启相关服务。 在下图所示位置为工作负载（deployment）打上标签sermant-injection: enabled。打上标签后，sermant-injector会在Pod重启时自动挂载Sermant Agent，从而通过Sermant Agent注册到CSE上。

版本支持 Spring Cloud Version Spring Boot Version Spring Cloud Openfeign Version RestTemplate Version Spring Cloud Loadbalancer Version Spring Cloud Netflix Ribbon Version Spring Cloud Gateway Version Spring Cloud Netflix Zuul Version Edgware.SR2+ 1.5.x 1.4.3.RELEASE+ 4.3.6.RELEASE+ - 1.4.3.RELEASE+ - 1.4.3.RELEASE+ Finchley.x 2.0.x 2.0.x 5.0.x - 2.0.x - 2.0.x Greenwich.x 2.1.x 2.1.x 5.1.x - 2.1.x - 2.1.x Hoxton.x 2.2.x、2.3.x 2.2.x 5.2.x 2.2.5.RELEASE+ 2.2.x 2.2.x 2.2.x 2020.0.x 2.4.x、2.5.x 3.0.x 5.3.x 3.0.x - 3.0.x - 2021.0.0 2.6.x 3.1.x 5.3.x 3.1.x - 3.1.x - 通过Sermant Agent注册到ServiceComb引擎中的应用可以使用标签路由功能。

（可选）自定义优雅上下线配置 优雅上下线能力默认开启，若需自定义配置，请参考如下方式： 如果方式一与方式二同时配置，将以方式二为准。 方式一： 在启动Spring Cloud应用时通过环境变量或者-D参数的形式进行配置，配置参数如下： 参数项 说明 grace_rule_startDelayTime 注册延迟时间，默认0秒，若大于0，则开启注册延迟。 grace_rule_enableWarmUp 开启优雅上线能力，默认开启。 grace_rule_warmUpTime 优雅上线时间，单位秒，该配置生效需开启优雅上线功能，默认120秒。 grace_rule_enableGraceShutdown 配置优雅下线能力开关， 默认开启。 grace_rule_shutdownWaitTime 下线前的最大等待时间，默认30S。 grace_rule_enableOfflineNotify 开启下线通知，默认开启。 方式二： 通过配置管理进行配置，配置步骤如下： 登录微服务引擎控制台。 单击，选择区域。 选择“ServiceComb引擎”。 单击待操作的ServiceComb引擎。 选择“配置管理”。 单击右上角的“新建配置”进入新建配置页面。 输入“配置项”，命名为sermant.agent.grace。 此处名称固定为该值。 选择“配置范围”，这里以微服务级配置为例，选择您要配置的服务，如下图所示： “配置格式”选择“YAML”，并自定义优雅上下线配置， 如下： rule: startDelayTime: 0 # 注册延迟时间，默认0秒，若大于0，则开启注册延迟。 enableWarmUp: true # 开启优雅上线能力，默认为true（开启），如需关闭，请设置为fasle。 warmUpTime: 120 # 优雅上线时间，单位秒，该配置生效需开启优雅上线功能，默认120秒。 enableGraceShutdown: true # 配置优雅下线能力开关，默认为true（开启），如需关闭，请设置为fasle。 shutdownWaitTime: 30 # 下线前的最大等待时间，默认30S。 enableOfflineNotify: true # 开启下线通知，默认开启。 单击右下角的“立即创建”，然后重启对应服务实例即可。 下发配置时，请去掉注释，否则会导致下发配置失败。

验证优雅上下线能力 验证优雅上线能力。 图1 优雅上线验证部署图 如上图所示，该套nacos应用有nacos-rest-consumer、nacos-rest-provider（两个实例）以及nacos-rest-data服务，其中灰色的实例已关闭开启优雅上线，而绿色实例开启优雅上线功能。 若需关闭预热，请添加环境变量“grace_rule_enableWarmUp=false”进行指定。 而服务nacos-rest-consumer通过接口graceHot进行模拟调用。 下载demo应用并打包。 按照优雅上线验证部署图进行部署并将nacos-rest-provider的其中一个实例开启优雅上线能力。 查看应用是否已全部接入ServiceComb引擎。 参考查看微服务列表查看您的应用是否已接入ServiceComb引擎。 待应用接入ServiceComb引擎后，使用以下脚本invoke-hot.sh模拟调用过程。 #!/bin/bash endpoint=127.0.0.1:31021 url=${endpoint}/graceHot while true do echo `curl -s ${url}` done endpoint为nacos-rest-consumer服务的调用地址，即ip:port。需根据实际nacos-rest-consumer地址进行替换。 查看服务调用情况。 使用脚本stat.sh查看服务调用情况，脚本如下： #!/bin/bash endpoint=127.0.0.1:31021 watch curl ${endpoint}/stat 下图为某个时刻统计的调用结果： 上图中实例x.x.0.55:8009关闭了优雅上线， 实例x.x.0.51:8004开启了优雅上线，观察请求数（requestCount）与QPS，可观察到开启优雅上线的实例的QPS与请求数都小于关闭优雅上线的实例。持续观察流量请求情况，直到两个实例QPS基本持平则结束验证。 验证优雅下线能力。 优雅下线验证部署图如下： 如上图，该套nacos应用有nacos-rest-consumer、nacos-rest-provider（两个实例）、nacos-rest-provider-close-grace（两个实例）以及nacos-rest-data服务，其中服务nacos-rest-provider-close-grace关闭了优雅下线，其他服务开启优雅下线。 服务说明。 nacos-rest-provider-close-grace与nacos-rest-provider同属于一个jar应用，nacos-rest-provider-close-grace请使用环境变量“spring_application_name=nacos-rest-provider-close-grace”进行指定。 关闭优雅下线的方法。 添加环境变量“grace_rule_enableGraceShutdown=false”进行指定。 nacos-rest-consumer通过调用接口graceDownOpen测试验证优雅下线能力；调用接口graceDownClose对比未开启优雅下线时请求处理情况。查看调用情况可使用nacos-rest-consumer接口的stat方法进行请求统计。 下载demo应用并打包。 按照优雅下线验证部署图进行部署，并关闭nacos-rest-provider-close-grace的优雅下线能力。 查看应用是否已全部接入ServiceComb引擎。 参考查看微服务列表查看您的应用是否已接入ServiceComb引擎。 待应用接入ServiceComb引擎后，使用如下脚本invoke.sh模拟请求。 #!/bin/bash endpoint=127.0.0.1:31021 openUrl=${endpoint}/graceDownOpen closeUrl=${endpoint}/graceDownClose while true do echo `curl -s ${openUrl}` echo `curl -s ${closeUrl}` done endpoint为服务nacos-rest-consumer实例的请求地址，即ip:port。需根据实际nacos-rest-consumer地址进行替换。 openUrl为开启优雅下线能力的调用接口。 closeUrl为关闭优雅下线能力的调用接口。 查看应用的请求情况。 参考如下脚本stat.sh查看请求调用情况: #!/bin/bash endpoint=127.0.0.1:31021 watch curl ${endpoint}/stat endpoint为服务nacos-rest-consumer实例的请求地址，即ip:port。 对服务进行缩容，模拟下线。 分别对nacos-rest-provider-close-grace与nacos-rest-provider进行缩容，将实例缩容为1个。 使用4的脚本，查看服务调用情况。 上图中，graceDownClose为关闭优雅下线能力的请求统计，可以看到存在4个错误请求（errorCount）， 而下方graceDownOpen为开启优雅下线能力的请求统计，可以看到未出现错误请求。

优雅下线实现机制 延迟下线是优雅下线的核心机制，且Sermant Agent还提供了流量统计机制，即服务处理完所有统计的请求后再下线，减少流量丢失，从而实现了优雅下线。 图1 优雅下线结构图 延迟下线 当服务提供者实例下线时，无法避免仍有业务请求还未处理完成，从而可能会出现请求丢失的现象。延迟下线即对下线的实例提供保护，优雅下线插件基于下线实时通知+刷新缓存的机制快速更新上游的实例缓存，服务消费者能尽早感知服务提供者实例下线的行为，同时基于流量统计的方式，确保即将下线的实例尽可能的将流量处理完成，最大程度避免流量丢失。 流量统计 当服务即将下线时，为确保当前请求已全部处理完成，Sermant Agent会尝试等待30s（可配置），定时统计和判断当前实例请求是否均处理完成，处理完成后最终下线。

版本支持 Spring Cloud Version Spring Boot Version Zookeeper Discovery Version Nacos Discovery Version Consul Discovery Version Eureka Client Version Edgware.SR2+ 1.5.x 1.x.x、2.0.x 1.5.x 1.x.x、2.0.x、2.1.x 1.4.x、2.0.x、2.1.x Finchley.x 2.0.x 2.x.x 1.5.x、2.0.x、2.1.x 1.3.x、2.0.x、2.1.x 1.4.x、2.0.x、2.1.x Greenwich.x 2.1.x 2.x.x 1.5.x、2.0.x、2.1.x 1.3.x、2.0.x、2.1.x 1.4.x、2.0.x、2.1.x Hoxton.x 2.2.x、2.3.x 2.x.x、3.0.0 - 3.1.0 2.x.x、2020.0.RC1、2021.1 1.3.x、2.0.x、2.1.x、2.2.x 1.4.4.RELEASE - 1.4.7.RELEASE、2.x.x、3.0.0 - 3.1.0 2020.0.x 2.4.x、2.5.x 3.0.0 - 3.1.0 2.x.x、2020.0.RC1、2021.1 3.0.0 - 3.1.0 2.1.x、2.2.x、3.0.0 - 3.1.0 2021.0.0 2.6.x 3.0.0 - 3.1.0 2.x.x、2020.0.RC1、2021.1 3.0.0 - 3.1.0 3.0.0 - 3.1.0

优雅上线实现机制 预热是优雅上线的核心机制，Sermant Agent还提供了延迟注册机制，减少流量丢失，从而实现优雅上线。 延迟注册 在服务启动成功之后不立刻注册，而是延迟一段时间再去注册，目的是虽然服务启动成功了，但可能还有一些框架或者业务的代码没有初始化完成，可能会导致调用报错，可以通过设置延迟注册，让服务充分初始化后再注册到注册中心对外提供服务。 预热 该方式主要用于解决当流量突然增加时，可能瞬间把实例压垮的问题。通过预热，让通过的流量缓慢增加，在一定时间内逐渐增加到阈值上限，目的是采用少流量对服务实例进行初始化，防止服务崩溃。预热是基于客户端实现的，当流量进入时，Sermant Agent会动态调整流量，根据服务的预热配置，对流量进行动态分配。对于开启服务预热的实例，在刚启动时，会给该实例分配较少的流量，随后流量将以曲线方式逐渐增加至与其他实例近乎持平。

合理配置日志文件 查看错误日志是定位问题的重要手段，需要合理规划日志输出，并且尽可能降低对系统性能的影响。规划日志文件有如下建议： 使用log4j2或者logback输出日志。 将日志输出到文件，不要依赖于容器的stdout。 打开metrics日志，将metrics日志输出到独立的文件，比如“metrics.log”， 而将业务日志输出到另外的文件，比如“servicecomb.log”。metrics参数配置如下： servicecomb: metrics: window_time: 60000 invocation: latencyDistribution: 0,1,10,100,1000 Consumer.invocation.slow: enabled: true msTime: 3000 Provider.invocation.slow: enabled: true msTime: 3000 publisher.defaultLog: enabled: true endpoints.client.detail.enabled: true 打开access log， 将access log输出到独立的日志文件。 格式化打印业务日志，日志里面包含trace id，可以独立开发一个Handler，配置在Provider Handler的最前面，Handler在接收到请求后打印一条日志，处理完成了打印一条日志，对于问题界定，使用 AOM 快速检索相关日志等非常有帮助。 父主题： 托管Java Chassis应用

合理配置线程池参数 线程池是微服务的主要业务处理单元，合理的规划线程池不仅可以最大限度提升系统性能，还能防止异常情况导致系统无法给正常用户提供服务。线程池优化和业务自身的性能有很大关系，不同的场景参数设置不同，需要具体分析。下面分两种场景介绍。开始之前需要对业务的性能做一些基本的摸底，对常见的接口进行测试，查看时延。 业务性能很好的情况。 即非并发场景，接口的平均时延小于10ms。 业务性能很好的时候，为了让业务系统具备更好的可预测性，防止JVM垃圾回收、网络波动、突发流量等对系统的稳定性造成冲击，需要能够快速丢弃请求，并配合重试等措施，以保障波动情况下系统性能可预测，同时不会出现偶然的业务失败，影响体验。 连接数和超时设置 # 服务端verticle实例数，保持默认值即可。建议配置为8~10。 servicecomb.rest.server.verticle-count: 10 # 最大连接数限制。默认值为 Integer.MAX_VALUE。可以结合实际情况估算最大值，使系统具备更好的韧性。 servicecomb.rest.server.connection-limit: 20000 # 连接闲置时间。默认值60秒，一般不需要修改 servicecomb.rest.server.connection.idleTimeoutInSeconds: 60 # 客户端verticle实例数，保持默认值即可。建议配置为8~10。 servicecomb.rest.client.verticle-count: 0 # 一个客户端与服务器建立的最大连接数为 verticle-count * maxPoolSize，不要超过线程数。 # 这里是 10*50=500. 实例非常多的场景，要减小单个实例的连接数。 servicecomb.rest.client.connection.maxPoolSize: 50 # 连接闲置时间。默认值30 秒，一般不需要修改，要小于服务端的连接闲置时间。 servicecomb.rest.client.connection.idleTimeoutInSeconds 业务线程池配置 # 线程池组数，建议 2~4 servicecomb.executor.default.group: 2 # 建议 50~200 servicecomb.executor.default.thread-per-group: 100 # 线程池排队队列大小，默认值为Integer.MAX_VALUE。高性能场景不要使用默认值，以快速丢弃请求 servicecomb.executor.default.maxQueueSize-per-group: 10000 # 队列最大等待时间，如果超过，理解丢弃请求的处理并返回。默认值为0。 # 高性能场景配置小的排队超时时间，快速丢弃请求 servicecomb.rest.server.requestWaitInPoolTimeout: 100 # 设置比较短的超时时间，快速丢弃请求， 但是不建议这个值小于1秒，可能导致很多问题。 servicecomb.request.timeout=5000 业务性能不那么好的情况。 即非并发场景，接口的平均时延大于100ms。时延高通常是由于业务代码存在IO、资源等等待，CPU利用率上不去导致的。如果是由于计算复杂导致的，调优会变得复杂。 当业务性能不太好的时候，下面几个参数值需要调大，否则业务会大量阻塞。业务性能不好，通过调大参数能够保证系统的吞吐量，应对突发流量来临时带来的业务失败。不过这个是以牺牲用户体验为代价的。 # 服务端连接闲置时间。 servicecomb.rest.server.connection.idleTimeoutInSeconds: 120000 # 客户端连接闲置时间。 servicecomb.rest.client.connection.idleTimeoutInSeconds: 90000 # 线程池组数。 servicecomb.executor.default.group: 4 # 线程池大小。 servicecomb.executor.default.thread-per-group: 200 # 线程池排队队列大小，性能不好的情况下需要排队 servicecomb.executor.default.maxQueueSize-per-group: 100000 # 配置较大的超时时间 servicecomb.rest.server.requestWaitInPoolTimeout: 10000 servicecomb.request.timeout=30000 父主题： 托管Java Chassis应用

合理的规划系统架构 Java Chassis提供了丰富的组件，帮助搭建具备足够韧性的云原生系统。Edge Service具备通用网关的大部分能力，并且集成了Java Chassis的服务治理能力，可以实现Java Chassis多协议转发。一个典型的Java Chassis云原生架构如下： 该架构采用静态页面和服务分离，这样静态页面可以灵活的使用CDN、Nginx等形态部署。Edge Service屏蔽了内部微服务的结构，一般会搭配流量控制、安全认证等服务治理策略，使得内部服务能够灵活的进行拆分合并，降低内部服务直接面对流量攻击的风险。 父主题： 托管Java Chassis应用

问题描述 当使用Spring Cloud Huawei时，启动微服务时，当报错示例如下： send request to https://192.168.10.1:30100/v4/default/registry/microservices failed and retry to https://192.168.10.1:30100/v4/default/registry/microservices once. org.apache.http.conn.HttpHostConnectException: Connect to 192.168.10.1:30100 [/127.0.0.2] failed: Connection refused: connect at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:156) ~[httpclient-4.5.13.jar:4.5.13] at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:376) ~[httpclient-4.5.13.jar:4.5.13]

解决方法 启动服务在本地部署 在本地机器上使用curl https://注册中心IP地址:30100/health命令检查注册中心工作状态，查看是否返回类似如下信息： curl: Failed to connect to xxx.xxx.xxx.xxx port 30100: Connection refused 如果是，请检查是否因注册中心IP地址错误、注册中心端口号错误或者网络被隔离，导致网络不通。 启动服务在云上微服务引擎部署 微服务通过ServiceStage部署在微服务引擎，注册中心地址可以通过环境变量自动注入。请检查注入的注册中心地址是否正确。如果注册中心地址错误，请修改为正确地址并重新部署服务。

动态配置的类型选择 微服务引擎2.0的配置中心支持text、yaml等多种格式。 简单的key-value配置项 可以使用text类型，配置中心的key对应于代码中的key。 大量的配置 使用yaml格式，配置中心的key会被忽略，全量的key-value在yaml文件中定义。 ServiceComb引擎1.x不支持yaml格式，可以通过Spring Cloud Huawei适配，来使用yaml，需要在微服务bootstrap中增加如下配置： spring: cloud: servicecomb: config: fileSource: consumer.yaml # 需要按照yaml解析的配置项列表，以逗号分隔 初次使用ServiceComb引擎2.x 建议选择Spring Cloud Huawei的最新版本，最新版本包含更多的特性并针对历史问题进行了较好的优化。

Mongo client升级变更 问题描述 MongoDbFactory的接口存在变更，需要调整为新版本的用法。 解决方案 @Bean public MappingMongoConverter mappingMongoConverter(MongoDbFactory factory, MongoMappingContext context, BeanFactory beanFactory) { DbRefResolver dbRefResolver = new DefaultDbRefResolver(factory); MappingMongoConverter mappingConverter = new MappingMongoConverter(dbRefResolver, context); mappingConverter.setCustomConversions(beanFactory.getBean(MongoCustomConversions.class)); // other customization return mappingConverter; } @Bean public MongoClientOptions mongoOptions() { return MongoClientOptions.builder().maxConnectionIdleTime(60000).socketTimeout(60000).build(); }