概述
适用场景
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迁移到华为云运行。
应用建议
在开始使用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进行测试的,紧跟社区的版本配套关系,能够极大的减少兼容性问题的发生。三方软件版本管理策略会进一步说明三方软件兼容性问题的最佳实践。
- 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的改造也可参考本最佳实践。