华为云用户手册

时间过滤 参数位置：在创建表/文件迁移作业时，如果源端数据源为文件类型，那么源端作业配置下的高级属性中，“时间过滤”参数选择“是”。 参数原理：“起始时间”和“终止时间”参数中输入时间值后，只有修改时间介于起始时间和终止时间之间（时间区间为左闭右开，即等于起始时间也在区间之内）的文件才会被 CDM 迁移。 配置样例： 例如需要CDM只同步2021年1月1日~2022年1月1日生成的文件到目的端，则参数配置如下： 时间过滤器：选择为“是”。 起始时间：配置为2021-01-01 00:00:00（格式要求为yyyy-MM-dd HH:mm:ss）。 终止时间：配置为2022-01-01 00:00:00（格式要求为yyyy-MM-dd HH:mm:ss） 图2 时间过滤 这样CDM作业就只迁移2021年1月1日~2022年1月1日时间段内生成的文件，下次作业再启动时就可以实现增量同步。

文件/路径过滤器 参数位置：在创建表/文件迁移作业时，如果源端数据源为文件类型，那么源端作业参数的高级属性中可以看到“过滤类型”参数，该参数可选择：通配符或正则表达式。 参数原理：“过滤类型”选择“通配符”时，CDM就可以通过用户配置的通配符过滤文件或路径，CDM只迁移满足指定条件的文件或路径。 配置样例： 例如源端文件名带有时间字段“2017-10-15 20:25:26”，这个时刻生成的文件为“/opt/data/file_20171015202526.data”，则在创建作业时，参数配置如下： 过滤类型：选择“通配符”。 文件过滤器：配置为“*${dateformat(yyyyMMdd,-1,DAY)}*”（这是CDM支持的日期宏变量格式，详见时间宏变量使用解析）。 图1 文件过滤 配置作业定时自动执行，“重复周期”为1天。 这样每天就可以把昨天生成的文件都导入到目的端目录，实现增量同步。 文件增量迁移场景下，“路径过滤器”的使用方法同“文件过滤器”一样，需要路径名称里带有时间字段，这样可以定期增量同步指定目录下的所有文件。

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

操作步骤 获取Nacos Sync部署包。 在nacos-sync中获取Nacos Sync部署包，选择nacos-sync-0.4.8.tar.gz进行下载。 创建Nacos Sync所需要的数据库与表。 创建数据库实例，具体操作请参考创建Mysql数据库实例。 连接MySQL实例，具体操作请参考连接MySQL实例。 创建数据库，数据库名称为nacos_sync，字符集选择utf8mb4，具体操作请参考创建数据库。 解压nacos-sync-0.4.8.tar.gz，获取“nacos-sync/bin/”下的nacosSync.sql文件，并执行该文件，具体操作请参考执行SQL，执行完成后，会生成三张表。 cluster # 存储集群信息 task #存储同步任务信息 system_config # 系统配置信息 部署Nacos Sync至ECS服务器。 请参考Linux弹性云服务器登录方式概述选择相应方式登录弹性云服务器。 将获取的压缩包上传至ECS服务器的“/tmp/”文件夹下。 在压缩包所在路径下，执行解压命令，解压至当前文件夹下。 cd /tmp/ tar -zxvf nacos-sync-0.4.8.tar.gz 修改application.properties配置文件的数据库信息。 cd nacos-sync/conf vi application.properties 修改文件中的数据库连接信息为2创建的数据库信息，然后保存。 spring.datasource.url=jdbc:mysql://127.0.0.1:3306/nacos_sync?characterEncoding=utf8 # 修改为申请的数据库ip信息与自创建的数据库信息 spring.datasource.username=root # 数据库用户名 spring.datasource.password=xxxxxx # 数据库密码 启动Nacos Sync服务。 cd .. cd bin/ sh startup.sh start 日志的路径在“nacos-sync/logs”下，可检查是否有异常信息。 可修改startup.sh中的JAVA_OPT参数，自定义设置JVM堆内存大小。 访问Nacos Sync服务地址。 访问链接为IP+端口号，其中IP为ECS实例绑定的弹性公网IP，端口号为“application.properties”文件中配置的端口号。 Nacos Sync的服务界面如下：

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

操作步骤 为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上。

动态配置 动态配置按照公共、应用、服务三个层次进行管理。 简单的场景，可以使用应用级配置和服务级配置。应用级配置被该应用下的所有微服务共享，是公共配置；服务级配置只对具体微服务生效，是独享配置。复杂的场景，可以通过使用custom_tag和custom_value来定义配置。 例如某些配置，是对所有应用共享的，那么就可以使用这个机制。在配置文件增加如下配置： spring: cloud: servicecomb: config: kie: customLabel: public# 默认值是public customLabelValue: default # 默认值是空字符串

设置服务路由策略 配置项：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=作为通用路由设置。

（可选）自定义优雅上下线配置 优雅上下线能力默认开启，若需自定义配置，请参考如下方式： 如果方式一与方式二同时配置，将以方式二为准。 方式一： 在启动SpringCloud应用时通过环境变量或者-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为开启优雅下线能力的请求统计，可以看到未出现错误请求。

前提条件 已创建云容器引擎（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: 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上。

操作步骤 安装Sermant Agent，请参考安装Sermant Agent。 启动应用并开启优雅上下线能力。 在应用的启动参数添加如下参数，添加启动参数后，待应用启动完成。 -javaagent:${HOME}/java-agent/java-agent.jar=appName=default -Ddynamic_config_serverAddress={CSE_CONFIG_CENTER_ENDPOINTS} -Dregister.service.address={CSE_REGISTRY_ENDPOINTS} 相关配置介绍： appName为agent服务名称，该配置无需修改，使用default即可。 ServiceComb引擎服务注册发现地址（CSE_REGISTRY_ENDPOINTS）与CSE配置中心地址（CSE_CONFIG_CENTER_ENDPOINTS）需替换为实际地址，可参考如下方式获取： ServiceComb引擎服务注册发现地址：获取ServiceComb引擎服务注册发现地址。 CSE配置中心地址：获取ServiceComb引擎配置中心地址。 特别说明： 优雅下线是基于http协议进行通知，默认通知端口为16688，若您在虚机部署出现端口冲突问题（通常是单个ECS部署多个实例），请在启动时添加如下参数规避： # 请更换下面的端口号 -Dgrace_rule_httpServerPort=16688

开发环境规划管理 规划开发环境的目的是要保证开发人员更好的并行工作，减少依赖，减少搭建环境的工作量，降低生产环境上线的风险。 管理开发环境的目的是为了更好的进行开发测试，部署上线。 图1 开发环境 结合项目经验，一般会按照图1规划开发环境： 搭建内网本地开发环境。本地开发环境的好处是各个业务/开发者可以搭建符合自己需要的最小功能集合环境，方便查看日志、调试代码等。本地开发环境能够极大的提升代码开发效率，减少部署和调试的时间。本地开发环境的不足之处是集成度不高，需要集成联调的时候，很难确保环境稳定。 云上测试环境是相对比较稳定的集成测试环境。本地开发测试完成后，各个业务将本领域的服务部署到云上测试环境，并且可以调用其他领域的服务进行集成测试。根据业务规模的复杂程度，可以将云上测试环境进一步分为α测试环境、β测试环境、γ测试环境等，这些测试环境集成程度由低到高。一般γ测试环境要求和生产环境一样的管理，确保环境稳定。 生产环境是正式业务环境，生产环境需要支持灰度升级功能，支持在线联调和引流，保证升级故障对服务造成的影响最小化。 云上测试环境可以通过开放CSE、中间件的公网IP，或者实现网络互通，这样可以使用云上的中间件替换本地环境，减少各个开发者自行安装环境的时间。这种情况也属于内网本地开发环境，微服务在本地开发环境的机器上运行。云上采用容器部署的微服务和本地开发环境机器上部署的微服务无法相互访问。为了避免冲突，云上测试环境只作为本地开发环境使用。 父主题： 托管Spring Cloud应用

操作步骤 安装Sermant Agent，请参考安装Sermant Agent。 启动应用。 在应用的启动参数添加如下参数，添加启动参数后，待应用启动完成。 -javaagent:${HOME}/java-agent/java-agent.jar=appName=default -Ddynamic_config_serverAddress={CSE_CONFIG_CENTER_ENDPOINTS} -Dregister.service.address={CSE_REGISTRY_ENDPOINTS} -Dgrace_rule_enableSpring=false -Dservice_meta_version={VERSION} -Dservice_meta_parameters={PARAMETERS} 相关配置介绍： appName为agent服务名称，该配置无需修改，使用default即可。 ServiceComb引擎服务注册发现地址{CSE_REGISTRY_ENDPOINTS}与ServiceComb引擎配置中心地址{CSE_CONFIG_CENTER_ENDPOINTS}需替换为实际地址，可参考如下方式获取： ServiceComb引擎服务注册发现地址：获取ServiceComb引擎服务注册发现地址。 ServiceComb引擎配置中心地址：获取ServiceComb引擎配置中心地址。 grace_rule_enableSpring为SpringCloud框架优雅上下线功能，所以Dubbo框架需要手动关闭（设置为fasle），否则可能会存在端口冲突的问题。 {VERSION}需替换为服务注册时的版本号（形如a.b.c的格式，其中a、b、c均为数字，默认为1.0.0），标签应用需要修改为不同于正常应用的版本号。 {PARAMETERS}需替换为服务注册时的自定义标签（形如tag1:value1,tag2:value2），即标签名与标签值以英文冒号分隔，多个标签之间以英文逗号分隔。 一般地，如果用版本号进行路由，则只需配置service_meta_version，如果用自定义标签进行路由，则只需配置service_meta_parameters。

方案概述 本文描述如何将HSF、Dubbo框架改造为Spring Cloud框架并接入ServiceComb引擎的操作。 应用场景 很多微服务框架只是提供了如何解决微服务运维问题的功能模块和工具，但并没有帮用户解决那些问题，用户自行解决这些问题的成本通常非常高，出于现有框架的使用成本和问题，以及对未来业务的发展是否需要选择更加合适的技术考虑，可将微服务框架进行迁移。 方案架构 将HSF、Dubbo框架改造为Spring Cloud框架。 微服务框架HSF、Dubbo提供的主要功能是RPC框架，以及在RPC框架之上，提供相关的服务治理能力，包括注册发现、动态配置和限流熔断等。Spring Cloud提供REST框架，并在REST框架基础之上提供服务治理能力。因此实现微服务开发框架迁移主要是将RPC框架修改为REST框架，其操作主要包括两部分： 将服务端的接口定义由RPC修改为REST。 将客户端的调用方式由RPC修改为REST风格（包括RestTemplate，Feign等）。 服务端的接口定义相对比较集中，客户端的使用则比较难于排查。为了尽可能减少客户端代码的排查和修改，采用Feign来实现客户端代码的替换。 将Spring Cloud+Nacos、Spring Cloud+Eureka接入到ServiceComb引擎。 将Nacos、Eureka相关的依赖替换为ServiceComb引擎相关依赖。 增加ServiceComb引擎相关配置。 Nacos、Eureka一些使用习惯的调整，比如如何规划服务配置和逻辑隔离等。 下图以Eureka为例演示整个改造接入过程：

实施步骤 先将HSF或Dubbo框架改造为Spring Cloud框架。其基本操作步骤为： 修改POM和项目结构。 服务端RPC接口修改为REST接口。 客户端定义Feign引用。 删除HSF或Dubbo配置并增加Spring Cloud配置。 修改启动类。 您可以使用migrator工具一键将HSF、Dubbo等框架改造为Spring Cloud。 将HSF框架改造为Spring Cloud框架详细操作指导请参考HSF迁移Spring Cloud。 将Dubbo框架改造为Spring Cloud框架详细操作指导请参考Dubbo迁移Spring Cloud。 将Spring Cloud+Nacos、Spring Cloud+Eureka接入到ServiceComb引擎。 修改pom文件将Nacos相关的依赖替换为ServiceComb引擎相关依赖。 修改bootstrap.yml文件增加ServiceComb引擎相关配置。 调整Nacos或Eureka的使用习惯。 您可以使用migrator工具一键将Spring Cloud+Nacos、Spring Cloud+Eureka接入到ServiceComb引擎。 将Spring Cloud+Eureka接入到ServiceComb引擎的详细操作指导请参考Eureka+Spring Cloud迁移CSE。 将Spring Cloud+Nacos接入到ServiceComb引擎的详细操作指导请参考Nacos+Spring Cloud迁移CSE。

操作步骤 安装Sermant Agent，请参考安装Sermant Agent。 启动应用。 在应用的启动参数中添加如下参数，添加启动参数后，待应用启动完成。 -javaagent:${HOME}/java-agent/java-agent.jar=appName=default -Ddynamic_config_serverAddress={CSE_CONFIG_CENTER_ENDPOINTS} -Dregister.service.address={CSE_REGISTRY_ENDPOINTS} -Dservice_meta_version={VERSION} -Dservice_meta_parameters={PARAMETERS} 相关配置介绍： appName为agent服务名称，该配置无需修改，使用default即可。 ServiceComb引擎服务注册发现地址{CSE_REGISTRY_ENDPOINTS}与ServiceComb引擎配置中心地址{CSE_CONFIG_CENTER_ENDPOINTS}需替换为实际地址，可参考如下方式获取： ServiceComb引擎服务注册发现地址：获取ServiceComb引擎服务注册发现地址。 ServiceComb引擎配置中心地址：获取ServiceComb引擎配置中心地址。 {VERSION}需替换为服务注册时的版本号（形如a.b.c的格式，其中a、b、c均为数字，默认为1.0.0），标签应用需要修改为不同于正常应用的版本号。 {PARAMETERS}需替换为服务注册时的自定义标签（形如tag1:value1,tag2:value2），即标签名与标签值以英文冒号分隔，多个标签之间以英文逗号分隔。 一般地，如果用版本号进行路由，则只需配置service_meta_version，如果用自定义标签进行路由，则只需配置service_meta_parameters。

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

版本支持 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引擎中的应用可以使用标签路由功能。

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

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

版本支持 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

代码接入 Provider端： import ( "context" "log" "net" "github.com/cloudwego/kitex-examples/hello/kitex_gen/api" "github.com/cloudwego/kitex-examples/hello/kitex_gen/api/hello" "github.com/cloudwego/kitex/pkg/rpcinfo" "github.com/cloudwego/kitex/server" "github.com/kitex-contrib/registry-servicecomb/registry" ) type HelloImpl struct{} func (h *HelloImpl) Echo(_ context.Context, req *api.Request) (resp *api.Response, err error) { resp = &api.Response{ Message: req.Message, } return } func main() { // **初始化ServiceComb注册中心，默认从环境变量读取配置** r, err := registry.NewDefaultSCRegistry() if err != nil { panic(err) } svr := hello.NewServer( new(HelloImpl), server.WithRegistry(r), server.WithServerBasicInfo(&rpcinfo.EndpointBasicInfo{ServiceName: "Hello"}), server.WithServiceAddr(&net.TCPAddr{IP: net.IPv4(0, 0, 0, 0), Port: 8080}), ) if err := svr.Run(); err != nil { log.Println("server stopped with error:", err) } else { log.Println("server stopped") } } Consumer端： import ( "context" "log" "time" "github.com/cloudwego/kitex-examples/hello/kitex_gen/api" "github.com/cloudwego/kitex-examples/hello/kitex_gen/api/hello" "github.com/cloudwego/kitex/client" "github.com/kitex-contrib/registry-servicecomb/resolver" ) func main() { // **初始化ServiceComb注册中心，默认从环境变量读取配置** r, err := resolver.NewDefaultSCResolver() if err != nil { panic(err) } newClient := hello.MustNewClient( "Hello", client.WithResolver(r), client.WithRPCTimeout(time.Second*3), ) for { resp, err := newClient.Echo(context.Background(), &api.Request{Message: "Hello"}) if err != nil { log.Fatal(err) } log.Println(resp) time.Sleep(time.Second) } }

验证 部署成功后，登录微服务引擎控制台，在左侧导航栏选择“ServiceComb引擎专享版”，单击前提条件创建的ServiceComb引擎，选择“微服务目录”，单击微服务名称，在“实例列表”页签查看服务实例是否已经成功注册。 您也可以验证Consumer调用Provider能够正常调用。 设置环境变量serverAddr和serverPort为ServiceComb引擎服务注册发现地址的ip和port。 运行consumer。说明成功从ServiceComb引擎的服务中心获取了provider的ip和port，并调用了provider。

前提条件 已创建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或者通过Helm客户端部署Sermant Injector。

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

操作步骤 打包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引擎。