# Spring Cloud Huawei: ServiceComb and Nacos under one Spring Cloud abstraction > Spring Cloud Huawei is a Java framework that plugs Apache ServiceComb or Nacos into Spring Cloud for service discovery, registration and configuration, and adds governance, mesh, router, service engine and Swagger modules on top. It suits teams on Spring Cloud who want a Huawei-adjacent registry, and its support matrix is the first thing to read. **huaweicloud/spring-cloud-huawei** — Spring Cloud Huawei is a framework that makes it easier and productive to develop microservices with Spring Cloud. - Repository: https://github.com/huaweicloud/spring-cloud-huawei - Website: https://github.com/huaweicloud/spring-cloud-huawei/wiki - Stars: 580 · Forks: 231 - Language: Java - License: Apache-2.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/huaweicloud-spring-cloud-huawei ## Two registry choices behind one Spring Cloud surface Spring Cloud Huawei is described as a framework that makes it easier and productive to develop microservices with Spring Cloud, and the interesting decision it asks you to make is which service registry sits underneath. The framework supports Apache ServiceComb and Nacos as the discovery, registration and configuration management service, and the table spells out exactly which component does what in each case. For discovery and registration, the ServiceComb path uses servicecomb-service-center and the Nacos path uses nacos. For configuration management, the ServiceComb path uses servicecomb-kie and the Nacos path uses nacos. So the abstraction is shared but the components are not, and the difference is not a small one, since kie and a Nacos namespace are different models for the same job. The readme also notes that CSE provides commercial versions of ServiceComb and Nacos, which is the route for a team that wants the open source components with a support arrangement around them. The stated benefit of the framework is a large number of out-of-the-box service governance capabilities so developers can build resilient and reliable microservice applications without assembling each piece themselves. ## The support matrix is the most useful file in the repository Because a Spring Cloud integration lives or dies on version alignment, the branch and version table is where a new user should start. The master branch carries three recommended lines. 1.11.15-2025.1.x is compiled against Spring Cloud 2025.1.1 and Spring Boot 4.0.5, 1.11.15-2025.0.x against Spring Cloud 2025.0.1 and Spring Boot 3.5.13, and 1.11.15-2024.0.x against Spring Cloud 2024.0.3 and Spring Boot 3.4.13. All three are tested on OpenJDK 17. Below that sit the older maintained branches, and the table is honest about their status. The 2023.0.x branch with version 1.11.14-2023.0.x, compiled against Spring Cloud 2023.0.6 and Spring Boot 3.3.13, is marked end of support, and so is 2022.0.x with 1.11.10-2022.0.x on Spring Cloud 2022.0.5 and Spring Boot 3.1.12. The 2020.0.x branch and the older Hoxton, Greenwich, Finchley and Edgware branches, which reach back to Spring Boot 1.5.22.RELEASE, are all marked end of support as well. The one line flagged differently is 2021.0.x, which is recommended and tested on OpenJDK 8, but carries a vulnerability note rather than an end of support note, so it is the oldest line still in active consideration. ## The module list shows how much sits above the registry The repository layout is where the scope of the framework becomes concrete, because the directories are the modules a user actually depends on. There is a bom module, which pins the versions across the set, and a dependencies module, which is the artifact the Maven Central badge points at for a project to import. Then come the functional modules: spring-cloud-huawei-governance, which is the service governance capability the readme leads with, spring-cloud-huawei-mesh, spring-cloud-huawei-nacos for the Nacos integration, spring-cloud-huawei-router, spring-cloud-huawei-service-engine, and spring-cloud-huawei-swagger for API documentation. There is a spring-cloud-starter-huawei, which is the Spring Boot style starter, and spring-cloud-huawei-common and spring-cloud-huawei-parents for shared code and parent POM configuration. The parent modules matter more than they look, because they are how the framework keeps a Spring Cloud train and a Spring Boot version pinned consistently across every module you pull in. The root also has an etc directory, integration-tests, pmd for static analysis, spotbugs-security for the security-focused analysis, coverage-reports, docs and scripts. ## Getting the artifact, and what the Maven coordinates look like The distribution route is Maven Central, and the badge in the readme names the group and artifact to search for, com.huaweicloud for the group and spring-cloud-huawei-dependencies for the artifact. The artifact to import is therefore the dependencies module, which is what pulls the versions of every other module into alignment with your chosen Spring Cloud train, and the bom alongside it is what lets a parent POM manage the versions. There is no install script and no build step for a consumer, because this is a set of published Java libraries rather than a service you run, and the wiki linked from the repository homepage is where the configuration and the sample usage live. The documentation directory in the tree holds the same text kept alongside the code, and the Chinese readme sits next to the English one so the two track each other. Before you wire anything up, decide which branch row of the support matrix you are on, because the version suffix in the artifact name, the 2025.1.x or 2025.0.x part, is what selects the Spring Cloud and Spring Boot generation your service compiles against. ## Apache-2.0, an active repository, and a monthly release rhythm On the administrative side the facts are simple. The licence is Apache 2.0, and the badge points at the standard licence text. The repository is not archived and the last push was on 2026-10-16, so the tree is being worked on, and the recent releases show the shape of that work. 1.11.15-2025.1.x and 1.11.15-2025.0.x were both published on 2026-04-20, and 1.11.15-2024.0.x on 2026-03-21. The naming pattern is worth parsing, because it is the whole version strategy in one string. The 1.11.15 part is the framework version, and it is shared across all three release lines, so the framework itself is versioned independently of the Spring Cloud train. The suffix after the dash is the Spring Cloud compatibility line, and the same framework version ships against 2025.1.x, 2025.0.x and 2024.0.x. That is how you support an estate running two or three different Spring Boot generations from a single framework release, and it is also why the branch, not just the version, matters when you pick what to depend on. ## Where the framework does not reach There is a limit to the abstraction, and it sits on the service side rather than the client side. If all you need is a client for Nacos, this framework is a large amount of machinery for a small job, and the readme is clear that the value it adds is the governance capability and the Spring Cloud integration, not the registry access itself. The other limit is the train. Spring Cloud Huawei versions are named after Spring Cloud releases, so you cannot use it on a Spring Boot generation that the matrix does not list, and the branches that fall off the end of that matrix are marked end of support rather than quietly maintained. The wiki is the practical starting point for the parts the readme does not cover, including how the service engine and mesh modules are configured and what the governance capabilities actually do, because the readme describes them by name and by directory rather than by behaviour. If your requirement is a Huawei-adjacent registry with the full Spring Cloud integration around it, this is the project, and if it is only a registry client, it is more than you need. ## Conclusion Spring Cloud Huawei fits a Java team that is already on Spring Cloud and needs either Apache ServiceComb or Nacos as its registry and configuration backend, especially where governance, routing and a service engine are wanted without assembling those pieces separately. It does not fit a team that just needs a Nacos client, because that is a much smaller dependency, and it does not fit a project that cannot commit to the Spring Cloud release train the table lists. Before you adopt it, pick the row of the support matrix that matches the Spring Cloud and Spring Boot versions you are on, check whether the branch you need is still supported rather than marked end of support, and decide between the ServiceComb and Nacos columns before you commit, since the discovery and configuration components differ and the swap is not a configuration change. ## FAQ ### What is Spring Cloud Huawei? It is a framework that makes it easier and productive to develop microservices with Spring Cloud. It supports Apache ServiceComb and Nacos as the discovery, registration and configuration management service, and adds out-of-the-box service governance capabilities on top. ### Which service registry does Spring Cloud Huawei support? Two. With ServiceComb, discovery and registration use servicecomb-service-center and configuration management uses servicecomb-kie. With Nacos, both discovery, registration and configuration management use nacos. CSE provides commercial versions of ServiceComb and Nacos. ### Which Spring Cloud and Spring Boot versions does Spring Cloud Huawei support? The master branch offers three recommended lines: 1.11.15-2025.1.x against Spring Cloud 2025.1.1 and Spring Boot 4.0.5, 1.11.15-2025.0.x against Spring Cloud 2025.0.1 and Spring Boot 3.5.13, and 1.11.15-2024.0.x against Spring Cloud 2024.0.3 and Spring Boot 3.4.13. All are tested on OpenJDK 17. ### Which Spring Cloud Huawei branches are still supported? The 2023.0.x, 2022.0.x, 2020.0.x, Hoxton, Greenwich, Finchley and Edgware branches are all marked end of support. The 2021.0.x line, version 1.11.15-2021.0.x on Spring Cloud 2021.0.9 and Spring Boot 2.7.18, is recommended and tested on OpenJDK 8 but is flagged with a vulnerability note. ### What modules does the Spring Cloud Huawei repository contain? A bom, a dependencies module, and the functional modules for governance, mesh, Nacos integration, router, service engine and Swagger, plus common and parent modules and a spring-cloud-starter-huawei starter. The root also carries integration tests, PMD and SpotBugs security analysis, coverage reports, docs and scripts. ## Sources - [huaweicloud/spring-cloud-huawei on GitHub](https://github.com/huaweicloud/spring-cloud-huawei) - [License: Apache-2.0](https://github.com/huaweicloud/spring-cloud-huawei/blob/master/LICENSE) - [Project website](https://github.com/huaweicloud/spring-cloud-huawei/wiki) - [README](https://github.com/huaweicloud/spring-cloud-huawei/blob/master/README.md) - [Releases](https://github.com/huaweicloud/spring-cloud-huawei/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/huaweicloud-spring-cloud-huawei