# 概述
#### 适用场景
[Spring Boot](https://github.com/spring-projects/spring-boot)、[Spring Cloud](https://github.com/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迁移到华为云运行。
 
#### 应用建议
在开始使用ServiceComb引擎托管Spring Cloud应用前，可以参考如下建议评估改造的风险和工作量：
- 改造的基本原理是通过实现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替换掉相关组件。
- 在替换场景，如果业务系统没有直接依赖实现组件的API，那么替换过程只需要移除原有依赖，添加Spring Cloud Huawei依赖，工作量非常小。如果业务系统大量依赖实现组件的API，那么替换工作量会相应增加。根据实际经验，业务系统通常都不会直接依赖实现组件的API。
- 改造过程中最容易出现的问题是三方软件兼容性问题。处理兼容性问题的最佳策略是存在两个不同版本的三方软件时，优先使用新版本。对于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进行测试的，紧跟社区的版本配套关系，能够极大的减少兼容性问题的发生。[三方软件版本管理策略](https://support.huaweicloud.com/bestpractice-cse/cse_05_0007.html)会进一步说明三方软件兼容性问题的最佳实践。
- 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的改造也可参考本最佳实践。