Help Center> Cloud Service Engine> Best Practices> ServiceComb Engine Application Hosting> Hosting a Spring Cloud Application> Introduction
Updated on 2023-11-08 GMT+08:00
View PDF

Introduction

Scenario

Spring Boot and Spring Cloud are widely used to build microservice applications. The main purpose of using ServiceComb engines to host Spring Cloud applications is to replace open-source components with highly reliable commercial middleware to better manage and maintain the application system. The reconstruction process should minimize the impact on service logic. This operation is applicable to the following scenarios:

  • Application systems developed based on Spring Boot do not have basic microservice capabilities. The application system integrates Spring Cloud Huawei to provide capabilities such as service registration and discovery and dynamic configuration management.
  • Application systems developed based on the Spring Cloud open-source technology system, for example, Eureka for registration and discovery and Nacos for dynamic configuration, integrate Spring Cloud Huawei and use highly reliable commercial middleware to replace open-source middleware, reducing maintenance costs.
  • Cloud native applications built based on other Spring Cloud development systems, such as Spring Cloud Alibaba and Spring Cloud Azure, are migrated to Huawei Cloud using Spring Cloud Huawei.

Applying Suggestions

Before using ServiceComb engines to host Spring Cloud applications, evaluate the reconstruction risks and workload based on the following suggestions:

  • The principle of reconstruction is to implement the DiscoveryClient and PropertySource interfaces provided by Spring Cloud to provide functions such as registration, discovery, and dynamic configuration for Spring Cloud applications. These implementations are independent of service logic development and do not affect service logic when integrated with Spring Cloud Huawei. Spring Cloud open-source technology system, Spring Cloud Alibaba, and Spring Cloud Azure also comply with this design mode. Therefore, the reconstruction can be classified into the integration and replacement scenarios. Spring Boot applications without microservice capabilities need to integrate with only Spring Cloud Huawei. For Spring Cloud applications with microservice capabilities, use Spring Cloud Huawei to replace related components.
  • In the replacement scenario, if the service system does not directly depend on APIs that implement components, you only need to remove the original dependency and add the Spring Cloud Huawei dependency during the replacement, which requires small workload. If the service system depends on a large number of APIs that implement components, the replacement workload increases. Based on the actual experience, service systems do not directly depend on the APIs that implement components.
  • The third-party software compatibility issues are the most likely to occur during the reconstruction. When there are two different versions of third-party software, use the later version preferentially. For Spring Boot and Spring Cloud, use the latest version in the community and follow the version mapping of the community. For example, if Spring Cloud Hoxton.SR8 is used, use Spring Boot 2.3.5.RELEASE. Although Spring Cloud Hoxton.SR8 claims to support Spring Boot 2.2.x, most components are integrated with 2.3.5.RELEASE for testing. Keeping up with the version mapping of the community can greatly reduce compatibility issues. For the best practices of third-party software compatibility issues, see Third-Party Software Version Management Policy.
  • Spring Cloud best matches ServiceComb engine 2.x. This best practice is based on ServiceComb engine 2.x. The only difference between ServiceComb engine 1.x and 2.x is that 1.x uses config-center as the configuration center and 2.x uses kie. Therefore, you can also refer to this best practice to reconstruct ServiceComb engine 1.x.