适用于如下场景：

1、基于Spring Cloud开源技术体系开发的应用系统，例如已经采用Eureka实现注册发现、采用Nacos实现动态配置，应用系统通过集成Spring Cloud Huawei，使用高可靠的商业中间件替换开源中间件，降低维护成本。

2、基于Spring Boot开发的应用系统，不具备微服务基本能力。应用系统通过集成Spring Cloud Huawei，具备服务注册发现、动态配置管理等能力。

3、基于Spring Cloud其他开发体系，例如Spring Cloud Alibaba、Spring Cloud Azure等构建的云原生应用，使用Spring Cloud Huawei迁移到华为云运行。

在开始使用ServiceComb引擎托管Spring Cloud应用前，可以参考如下建议评估改造的风险和工作量：

1、改造的基本原理是通过实现Spring Cloud提供的DiscoveryClient、PropertySource等接口，为Spring Cloud应用提供注册发现、动态配置等功能。这些实现独立于业务逻辑的开发，集成Spring Cloud Huawei不影响业务逻辑。Spring Cloud开源技术体系、Spring Cloud Alibaba、Spring Cloud Azure等，也都遵循这个设计模式。因此改造可以归纳为两种场景：集成和替换。不具备微服务能力的Spring Boot应用，只需要集成Spring Cloud Huawei；具备微服务能力的Spring Cloud应用，则需要使用Spring Cloud Huawei替换掉相关组件。

2、在替换场景，如果业务系统没有直接依赖实现组件的API，那么替换过程只需要移除原有依赖，添加Spring Cloud Huawei依赖，工作量非常小。如果业务系统大量依赖实现组件的API，那么替换工作量会相应增加。根据实际经验，业务系统通常都不会直接依赖实现组件的API。

3、改造过程中最容易出现的问题是三方软件兼容性问题。处理兼容性问题的最佳策略是存在两个不同版本的三方软件时，优先使用新版本。对于Spring Boot、Spring Cloud版本，尽可能使用社区最新的版本，并紧跟社区的版本配套关系。例如使用Spring Cloud Hoxton.SR8版本，Spring Boot则使用2.3.5.RELEASE版本。虽然Spring Cloud Hoxton.SR8声称支持Spring Boot 2.2.x版本，但是多数组件都是集成2.3.5.RELEASE进行测试的，紧跟社区的版本配套关系，能够极大的减少兼容性问题的发生。三方软件版本管理策略会进一步说明三方软件兼容性问题的最佳实践。

4、Spring Cloud最佳匹配ServiceComb引擎2.x版本，本最佳实践都是基于ServiceComb引擎2.x。ServiceComb引擎1.x和2.x具体改造过程的唯一差异是：配置中心类型ServiceComb引擎1.x使用的是config-center；ServiceComb引擎2.x使用的是kie。因此，ServiceComb引擎1.x的改造也可参考本最佳实践。

使用Spring Cloud Huawei接入CSE的ServiceComb引擎主要步骤可以归纳为如下两个步骤：

1、增加/修改组件依赖。

2、在配置文件“boostrap.yaml”中增加ServiceComb引擎配置信息。

具体操作，请参考Spring Cloud接入CSE的ServiceComb引擎。本章节补充在实际改造过程中需要注意的一些事项，特别是组件依赖有关的注意事项。

假设原来的业务系统都是基于Maven的项目。

第一步：熟悉原业务系统pom结构

Spring Cloud应用系统的pom结构一般分三种：

第一种使用Spring Boot或者Spring Cloud提供的公共pom作为parent。

第二种使用项目本身的parent，不使用Spring Boot或者Spring Cloud提供的公共pom作为parent。但是在项目中，通过dependency management引入了依赖管理。

还有些应用系统会混合使用第一种和第二种，既使用了Spring Boot或者Spring Cloud提供的公共pom作为parent，又通过dependency management引入了依赖管理。

第二步：修改parent和dependency management避免三方软件冲突

parent和dependency management的修改是避免三方软件冲突的关键步骤。

1、首先确定选用的Spring Cloud Huawei的版本，然后查询Spring Cloud Huawei版本对应的Spring Boot版本和Spring Cloud版本。Spring Cloud Huawei一般建议使用当前最新版本，配套的Spring Boot版本和Spring Cloud版本可以在Spring Cloud Huawei官网查询。

2、比对当前项目parent的版本与Spring Cloud Huawei配套的Spring Boot版本和Spring Cloud版本，如果当前项目的parent版本比较低，修改为Spring Cloud Huawei的版本；如果当前版本的parent版本比较高，则无需修改。

3、在当前项目的dependency management中独立引入Spring Boot、Spring Cloud、Spring Cloud Huawei的依赖管理。如果原来项目的Spring Boot或者Spring Cloud版本比较高，使用原来项目的版本；如果原来项目的版本比较低，则使用Spring Cloud Huawei的版本。需要注意依赖管理的顺序，排在前面的依赖管理会优先使用。Spring Boot、Spring Cloud的版本是基础，被这两个依赖关系管理的软件，建议都不提供额外的依赖管理，跟随社区的版本，可以有效减少冲突。这里之所以把3个依赖关系独立出来引入，是为了给以后独立升级其中一个组件提供便利。

如果业务系统集成了Spring Cloud Alibaba等依赖关系，在dependency management删除；一些已经被Spring Boot、Spring Cloud管理的不必要的依赖，也建议删除。

第三步：添加/删除依赖

添加的是服务注册发现、集中配置管理、服务治理相关的组件，删除的也是这些组件的第三方实现。这些功能以外的其他组件不需要变化，但需要关注Spring Boot、Spring Cloud版本升级后，这些软件可能需要配套升级。兼容性的问题通常会在编译阶段或者服务启动阶段发现。

添加依赖一般不指定版本号，把版本号交给parent和dependency management管理。

点击此处前往Spring Cloud Huawei快速接入CSE的ServiceComb详情→

pring Cloud提供了丰富的组件，帮助搭建具备足够韧性的云原生系统。spring cloud gateway具备通用网关的大部分能力，并且集成了Spring Cloud的服务治理能力，可以实现Spring Cloud多协议转发。

该架构采用静态页面和服务分离，这样静态页面可以灵活的使用CDN、Nginx等形态部署。spring cloud gateway屏蔽了内部微服务的结构，一般会搭配流量控制、安全认证等服务治理策略，使得内部服务能够灵活的进行拆分合并，降低内部服务直接面对流量攻击的风险。

点击此处前往典型的Spring Cloud云原生架构详情→

系统升级、改造过程中，三方软件冲突是最常见的问题。随着软件迭代速度越来越快，传统的软件兼容性管理策略已经不适应软件的发展。

三方软件管理的最佳实践，帮助您打造一个持续演进的应用系统。

开源软件选型

主要的开源社区，例如Spring Boot、Spring Cloud等都会维护多个版本分支。以Spring Cloud为例，存在Hoxton、Greenwich、2020.0.x等分支，其中大部分分支都已经停止维护。开源软件多数维护的分支存在两个：一个为最新版本的开发分支；一个为最近的稳定维护分支。

在开源软件选型上，应该紧跟社区的版本节奏，使用继续提供维护的分支的最新版本。在选择开发分支和维护分支上，没有严格的定论，需要视具体的产品功能确定。例如产品竞争力严重依赖某个三方软件的特性，那么更倾向于选择开发分支的最新版本；一个产品依赖某个三方软件的特性稳定，不使用新功能，那么更倾向于选择维护分支。

不建议选择社区已经停止维护的分支、以及虽然还在维护但发布时间超过半年以上的分支版本。虽然使用这些版本暂时没有发现功能问题，但是会给产品的持续演进带来严重影响：

1、软件的安全漏洞得不到及时处理。安全漏洞的发现和利用都有一定的时间周期，长期使用老版本，安全漏洞被利用的可能性变大，使得系统更加容易被攻击。

2、系统出现故障，更难寻求社区支持。停止维护的版本，或者已经发布超过半年以上的版本，很难得到社区的支持。

3、系统演进变得更加困难。当系统需要增加新特性，引入新开发工具时，老版本更难与新开发工具兼容。

4、还有很多的故障，可能在新版本已经修复，新版本在代码可维护性、性能等方面也都优于老版本。

因此，在开源软件选型问题上 ，最佳方案就是选择社区提供维护升级的开发分支或者维护分支，根据问题驱动升级到分支的最新版本，每季度周期性升级到分支的最新版本。

三方软件版本管理

首先通过一个简单的例子，介绍三方件冲突的原理。假设开发一个X项目，该项目需要同时引用项目A提供的组件，也需要引用项目B的组件，并且项目A和项目B同时依赖了项目C，但是版本号不同。

项目X在最终发布的时候，会出现如下几种情况：

1、使用项目C的0.2.0版本。由于项目A是使用0.1.0版本编译和测试的，那么组件A可能无法正常工作。例如0.2.0版本和0.1.0不兼容，并且项目A恰好使用了这些不兼容的接口。

2、使用项目C的0.1.0版本。由于项目B是使用0.2.0版本编译和测试的，那么组件B可能无法正常工作。例如项目B使用了0.2.0提供的新接口。

可以看出，如果项目A和项目B使用的C组件存在接口不兼容的情况，无论怎么调整，项目X都无法正常工作。必须修改项目A的代码，使用和B同样的或者兼容的版本进行测试，发布新的版本给X项目使用。

因此，进行依赖管理的最佳策略是保证公共组件的依赖，都使用较高的版本。尽管如此，通常还是会碰到一系列问题，特别是项目依赖关系非常复杂的情况。

目前主流的复杂项目，都采用dependency management机制管理依赖。使用dependency management已经被验证是比较有效的管理依赖的手段，因此被开源社区广泛使用。例如，Spring Boot、Spring Cloud和Spring Cloud Huawei，开发者可以通过查看Spring Cloud Huawei的源代码目录结构了解dependency management的具体使用。

Spring Cloud Huawei的这几个pom是相对完整的pom结构，从不同的使用视角给开发者提供了可以引入的pom，比较适用于公共开发组件。

点击此处前往三方软件版本管理策略详情→