应用网关 CS E应用网关基于开源社区版Envoy，提供Ingress网关和微服务网关二合一的云原生网关服务。使用华为云CSE应用网关可以获得微服务架构或容器化应用的极简网关体验，快速对接服务发现、实现服务路由、安全控制、流量治理等功能，让用户专注于业务应用的开发与维护。CSE应用网关的可观测能力，与华为云 AOM 、 APM 、LTS等服务预集成，提供监控告警、调用链路分析、访问日志查询等功能。 应用网关当前仅在华东-上海一、西南-贵阳一支持公测。

ServiceComb引擎 CSE ServiceComb引擎基于Apache ServiceComb开源生态，提供一站式的微服务平台。支持使用Java-Chassis SDK、SpringCloudHuawei SDK或无侵入的Sermant Java Agent（支持标准SpringCloud和Dubbo框架）接入。接入后，用户可以轻松使用服务契约、服务治理、灰度发布、业务场景治理、服务监控、配置管理、访问控制等众多功能，实践api first开发，构建高安全、高性能、高稳定的微服务应用。关于Apache ServiceComb Service Center的详细内容请参考： https://github.com/apache/servicecomb-service-center/ https://service-center.readthedocs.io/en/latest/user-guides.html ServiceComb引擎分为1.x、2.x版本。 ServiceComb引擎2.x版本是可支持大规模微服务应用管理的商用引擎。您可根据业务需要选择不同规格，引擎创建完成后不支持规格变更；引擎资源独享，性能不受其他租户影响。 相较于ServiceComb引擎1.x版本，ServiceComb引擎2.x版本底层架构、功能、安全及性能全面升级，提供了独立的服务注册发现中心和配置中心，支持基于用户业务场景的定义和治理。两个版本的特性比对请参见表1。 表1 ServiceComb引擎2.x和ServiceComb引擎1.x特性比对 功能 特性 2.x 1.x 备注 引擎管理 安全性 支持安全认证 √ √ - 可靠性 3AZ高可靠 √ √ - 微服务管理 基础能力 注册发现 √ √ - 多框架接入 √ √ 支持Spring Cloud、ServiceComb Java Chassis。 无实例版本自动清理 √ x 2.3.7及以后版本，支持保留最近3个微服务版本，并自动清理无实例版本。 性能 实例变化毫秒级推送 √ √ - 配置管理 基础能力 管理配置 √ √ - 配置格式多样化 √ 仅支持文本 2.x新增支持配置格式有：YAML、JSON、TEXT、Properties、INI、XML。 导入导出 √ √ 2.x新增支持设置导入相同配置策略。 高级特性 历史版本 √ x - 版本对比 √ x - 一键回滚 √ x - 配置标签 √ x - 性能 秒级下发 √ x - 微服务治理 业务场景化治理 业务场景定义 √ x - 基于请求Method的匹配规则 √ x - 基于请求Path的匹配规则 √ x - 基于请求Headers的匹配规则 √ x - 治理策略-流量控制 服务端的令牌桶限流 √ √ - 治理策略-重试 客户端通过重试来保证用户业务的可用性、容错性、一致性 √ √ - 治理策略-熔断 服务端通过熔断故障业务，防止故障蔓延到整个服务，发生大规模故障 √ √ - 治理策略-隔离仓 服务端基于信号量控制请求并发能力 √ x - 开发工具 本地轻量化引擎 本地一键启动，方便开发者离线开发微服务 √ √ -

配额说明 配额是指您引擎实例中可创建的资源数量限制。如需使用更大配额，请提交工单申请扩大配额。 Nacos引擎实例中可创建的资源数量限制如表1所示。 表1 Nacos引擎资源配额限制 资源 最大配额 是否支持修改配额 注意事项 Nacos单实例命名空间数量 50个 否 - Nacos单个配置文件大小上限 100KB 否 - Nacos单个命名空间配置总计大小 10MB 否 - 带宽（网络流出+流入之和） 2Mbit/s 否 - ServiceComb引擎实例中可创建的资源数量限制如表2所示。 表2 ServiceComb引擎资源配额限制 功能 资源 最大配额 是否支持修改配额 注意事项 微服务管理 微服务版本数量（个） 10,000 暂不支持 - 单个实例数据量（KB） 200 支持 扩大配额后，将增加微服务发现的时延。 单个微服务契约数量（个） 500 暂不支持 - 配置管理 单个配置数据量（KB） 128 暂不支持 - 单个应用级配置数量（个） 2,000 暂不支持 - 微服务治理 应用级的治理策略 1,000 暂不支持 所有的应用的治理策略总和不能超过1000条。 单个治理策略包含：治理规则和业务场景。治理规则和业务场景实际会等量占用配置中心的配额。 微服务版本数：微服务场景中版本用来标记微服务的迭代记录，方便对微服务的不同迭代进行管理。 微服务实例数：实例是一个微服务的最小运行和部署单元，通常对应一个应用进程。同一个微服务通过部署在多个容器或虚机，可以实现多个实例同时运行。 配置条目数：微服务场景中的配置是指对程序代码中某些变量的取值控制。比如，动态配置就是通过在微服务运行过程中对某些变量的取值进行动态变更。

Spring-cloud-huawei、Servicecomb及Sermant功能对比 一级特性 二级特性 servicecomb-java-chassis spring-cloud-huawei sermant agent 备注 微服务网关 服务端限流 √ √ √ - 服务端隔离仓 √ √ √ - 客户端熔断 × √ × - 客户端容错 × √ × - 客户端降级 × × × - 客户端故障注入 × × × - 负载均衡策略 √ √ × - 灰度发布 × √ √ - 优雅停机 √ √ × - 微服务治理 优雅上下线 √ √ √ - 无损升级 √ √ √ - 服务端限流 √ √ √ - 客户端容错 √ √ √ - 客户熔断 √ √ √ - 客户端降级 √ √ √ - 服务端隔离仓 √ √ √ - 客户端隔离仓 √ √ √ - 负载均衡策略 √ √ √ - 灰度发布 √ √ √ - 全链路日志追踪 √ √ × - 服务治理状态上传 √ √ × - 快速失败 √ √ × - 故障注入 √ × √ - 黑白名单 √ √ × - 注册发现 本地注册发现 √ √ × - 单注册-CSE √ √ √ - 单注册-ServiceCenter √ √ √ - 双注册 × × √ 双注册指同时注册到两个注册中心，当前sermant支持同时注册到cse和宿主原生注册中心。 配置中心支持 servicecomb引擎 √ √ √ 可基于配置中心下发配置, 例如服务治理规则、业务配置。 Nacos引擎 √ √ √ servicecomb-kie √ √ √ zookeeper × × √ 轻量化配置中心（zero-config） √ × × apollo × × × 安全特性 安全认证 √ √ × 服务实例与注册中心以及消费端与生产端之间的认证。 开发 多协议支持 √ × × JavaChassis针对消费与生产端支持多种通信协议，如下： 生产端：JAX-RS、SpringMVC、透明RPC。 消费端：透明RPC、RestTemplate、InvokerUtils。 拓展 支持用户自定义处理链处理流量。 支持用户扩展流量治理。 支持Spring Cloud原生扩展。 支持用户扩展流量治理。 基于插件开发模式新增能力。 -

微服务开发框架版本要求 微服务开发框架推荐版本如下表所示。 如果已经使用低版本的微服务开发框架构建应用，建议升级到推荐版本，以获取最稳定和丰富的功能体验。 如果已使用Spring Cloud微服务开发框架开发了应用，推荐使用Spring Cloud Huawei接入应用。 Spring Cloud Huawei各分支版本与Spring Boot、Spring Cloud、Java Chassis及JDK编译版本的配套关系请参考版本配套说明。 如果基于开源开放和业界生态组件新开发微服务应用，可选择Spring Cloud框架。 如果希望使用ServiceComb引擎提供的开箱即用的治理能力和高性能的RPC框架，可选择Java Chassis框架。 框架 推荐版本 说明 Spring Cloud Huawei 1.10.9-2021.0.x及以上 采用Spring Cloud Huawei项目提供接入支持： 适配的Spring Cloud版本为2021.0.5 适配的Spring Boot版本为2.6.13 Spring Cloud微服务开发框架的版本说明请参见：https://github.com/huaweicloud/spring-cloud-huawei/releases。 Java Chassis 2.7.10及以上 可以直接使用开源项目提供的软件包接入，不需要引用其他第三方软件包。 Java Chassis微服务开发框架的版本说明请参见：https://github.com/apache/servicecomb-java-chassis/releases。 系统升级、改造过程中，三方软件冲突是最常见的问题。随着软件迭代速度越来越快，传统的软件兼容性管理策略已经不适应软件的发展，您可以参考三方软件版本管理策略来解决版本冲突。

Nacos引擎与微服务框架版本关系 CSE Nacos引擎版本 Spring Cloud Alibaba版本 Spring Cloud版本 Spring Boot版本 2.1.0.x 2022.0.0.0-RC* Spring Cloud 2022.0.0 3.0.0 2021.0.4.0* Spring Cloud 2021.0.4 2.6.11 2021.0.1.0 Spring Cloud 2021.0.1 2.6.3 2021.1 Spring Cloud 2020.0.1 2.4.2 2.2.10-RC1* Spring Cloud Hoxton.SR12 2.3.12.RELEASE 2.2.9.RELEASE Spring Cloud Hoxton.SR12 2.3.12.RELEASE 2.2.8.RELEASE Spring Cloud Hoxton.SR12 2.3.12.RELEASE 2.2.7.RELEASE Spring Cloud Hoxton.SR12 2.3.12.RELEASE 2.2.6.RELEASE Spring Cloud Hoxton.SR9 2.3.2.RELEASE 2.2.1.RELEASE Spring Cloud Hoxton.SR3 2.2.5.RELEASE 2.2.0.RELEASE Spring Cloud Hoxton.RELEASE 2.2.X.RELEASE 2.1.4.RELEASE Spring Cloud Greenwich.SR6 2.1.13.RELEASE 2.1.2.RELEASE Spring Cloud Greenwich 2.1.X.RELEASE 2.0.4.RELEASE(停止维护，建议升级) Spring Cloud Finchley 2.0.X.RELEASE 1.5.1.RELEASE(停止维护，建议升级) Spring Cloud Edgware 1.5.X.RELEASE

开发能力要求 本文档的主要目的就是说明这些开源微服务开发框架如何接入和使用ServiceComb引擎的功能，假设您已经熟悉和掌握如下开发能力： 使用Java语言进行微服务开发。假设您已经基于一种ServiceStage支持的微服务开发框架开发了应用系统，并期望将应用系统托管在ServiceComb引擎上运行。本文档提供微服务应用接入ServiceComb引擎的相关技术支持。开源微服务开发框架如何使用不是本文档的范围，您可以通过开源社区获取相关微服务开发框架的入门材料和开发指南。 理解注册中心、配置中心在微服务应用中的作用，并在项目中搭建和使用注册中心。不同的微服务开发框架默认支持的开源注册中心会有差异，理解注册中心的作用，可以更加容易地更换注册中心。 熟悉应用部署，请参考创建并部署组件。

配置中心概述 配置中心用来管理微服务应用的配置。微服务连接配置中心，能够从配置中心获取配置信息及其变化。配置中心还是其他微服务管控功能的核心部件，比如服务治理规则的下发，也是通过配置中心实现的。 ServiceComb引擎支持的配置中心为：config-center和kie。 当ServiceComb引擎版本为1.x时，取值为config-center。 当ServiceComb引擎版本为2.x时，取值为kie或config-center，推荐使用kie作为配置中心。 本章节介绍不同微服务开发框架使用配置中心的一些开发细节，包括如何配置依赖、连接配置中心有关的配置项等，并简单地介绍微服务应用中如何读取配置和响应配置变化。 ServiceComb引擎使用kie作为配置中心。 微服务默认会读取配置中心应用配置、服务配置、自定义配置。应用配置指环境、应用和微服务相同的配置；服务配置指环境、应用、微服务名称和微服务相同的配置。微服务可以在配置文件中指定一个特定的label及label值，自定义配置指label及label值与微服务相同的配置。 简单的场景，可以使用应用级配置和服务级配置。应用级配置被该应用下的所有微服务共享，是公共配置；服务级配置只对具体微服务生效，是独享配置。 复杂的场景，可以通过使用customLabel和customLabelValue来定义配置。例如某些配置，是对所有应用共享的，那么就可以使用这个机制。在配置文件增加如下配置（以Spring Cloud为例）： spring: cloud: servicecomb: config: kie: customLabel: public# 默认值是public customLabelValue: default # 默认值是空字符串 只要配置项带有public标签，并且标签值为default，这些配置项就会对该微服务生效。 把配置中心当成数据库的一个表tbl_configurations，key是主键，每个label都是属性。 客户端会根据如下3个条件查询配置： 自定义配置 select * from tbl_configurations where customLabel=customLabelValue & match=false 应用级配置 select * from tbl_configurations where app=demo_app & environment=demo_environment & match=true 服务级配置 select * from tbl_configurations where app=demo_app & environment=demo_environment & service=demo_service & match=true 其中，match为true的时候，表示有且只有条件里面指定的属性；match为false的时候，表示除了条件里面的属性，允许有其他的属性。还可以给标签app指定多个应用，或者给标签service指定多个服务，这样配置项就可以对多个服务和应用生效，非常灵活。 ServiceComb引擎的TEXT、XML等类型，SDK会简单地当成key-value对使用；YAML和Properties类型， SDK会解析内容，应用程序将内容作为实际的应用程序配置项。比如： 类型：TEXT key: cse.examples.hello value: World 应用程序会发现1个配置项: cse.examples.hello = World。 类型：YAML key: cse.examples.hello value: | cse: key1: value1 key2: value2 应用程序会发现2个配置项: cse.key1 = value1和cse.key2 = value2。 ServiceComb引擎使用config-center作为配置中心。 微服务默认会读取配置中心全局配置、服务配置。全局配置指环境和微服务相同的配置；服务配置指环境、应用、微服务名称和微服务相同的配置。 ServiceComb引擎只支持key-value的配置项。如果用户需要使用yaml格式的配置文件，可以使用具体SDK提供的fileSource功能。通过在配置文件中指定fileSource的key列表，SDK会将这些key对应的value全部当成yaml解析。以Spring Cloud为例，在bootstrap.yml中增加配置项： spring: cloud: servicecomb: config: fileSource: file1.yaml,file2.yaml 并且在配置中心创建配置，“配置项”及其对应的“值”的示例如下表所示。其中，值的格式为yaml。 配置项 值 file1.yaml cse.example.key1: value1 cse.example.key2: value2 file2.yaml cse.example.key3: value3 cse.example.key4: value4 配置创建方法请参考配置管理中的“创建配置”操作。 应用程序中会发现4个配置项：cse.example.key1=value1，cse.example.key2=value2，cse.example.key3=value3和cse.example.key4=value4。 父主题： 使用配置中心

升级到Java Chassis的最新版本 持续升级版本，可以更好地使用CSE的新功能和新特性，及时修复已知的质量和安全问题，降低维护成本。 持续升级版本也会带来一些兼容性问题。一个比较好的策略是将持续升级纳入版本计划，安排足够的时间进行，而不是以问题驱动。 持续升级还需要构建自动化测试能力，以减少版本升级的验证时间和控制版本升级的风险，及早发现问题。持续的构建自动化能力和升级版本，是被证明有效的构建高质量软件的最佳实践。 父主题： 托管Java Chassis应用

优雅上线实现机制 预热是优雅上线的核心机制，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

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

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

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

升级零中断 要实现升级零中断，通常需要解决如下问题： 停止服务的时候，可能引起业务中断。在停止服务的过程中，可能服务正在处理请求，新的请求可能持续地发送到该服务。 在微服务架构下，一般都会通过注册中心进行服务发现，客户端会缓存实例地址。停止服务的时候，使用者可能无法及时感知实例下线，并继续使用错误的实例进行访问，导致失败。 实现升级零中断，需要进行滚动升级，在新版本功能就绪后，才能够停止老版本。 实现升级零中断需要很多的措施进行配合，比如滚动升级，实现零中断，建议保证最少有2个可用的实例。在本章节里面，主要描述从微服务的角度进行设置，更好地配合升级零中断。Java Chassis实现零中断的核心机制包括如下几个： 优雅停机。服务停止的时候，需要等待请求完成，并拒绝新请求。 Java Chassis优雅停机默认提供，在进程退出前，会进行一定的清理动作，包括等待正在处理的请求完成、拒绝未进入处理队列的新请求、调用注册中心接口进行注销等动作。Java Chassis进程退出前，先将实例状态修改为DOWN，然后等待一段时间再进行后续的退出过程： servicecomb: boot: turnDown: # 实例状态修改为DOWN以后等待时间，默认值为0，即不等待。 waitInSeconds: 30 重试：客户端对于网络连接错误，以及被拒绝等请求，需要选择新服务器进行重试。 开启重试策略： servicecomb: loadbalance: retryEnabled: true # 是否开启重试策略 retryOnNext: 1 # 重新寻找一个实例重试的次数（不同于失败实例，依赖于负载均衡策略） retryOnSame: 0 # 在失败的实例上重试的次数 隔离：对于失败超过一定次数的服务实例，进行隔离。 开启实例隔离策略： servicecomb: loadbalance: isolation: enabled: true enableRequestThreshold: 5 # 统计周期内实例至少处理的请求数，包括成功和失败。 singleTestTime: 60000 # 实例隔离后，经过这个时间，会尝试访问。如果访问成功，则取消隔离，否则继续隔离。 continuousFailureThreshold: 2 # 实例隔离的条件，连续两次失败。 父主题： 合理规划服务治理