SpringCloud: the Spring Cloud 2023 scaffold rebuilt as Opensabre

The preface tells you to use a different framework instead

The first substantive paragraph of this repository is a refactoring notice. It states that, based on earlier use and feedback, the scaffold has been refactored as a whole, that a new framework called Opensabre has been released, and that you should use the new version. Two links follow, the framework source at github.com/opensabre/opensabre-framework and online documentation at opensabre.github.io/docs. That frames everything else in the repository. The introduction that follows describes Opensabre, and the quick start calls this an aggregate project whose modules reference modules from github.com/opensabre. So the base applications live here, while the framework code comes from the opensabre repositories.

The clone command needs --recursive or the framework is missing

The learning path is a single command, and it carries a flag that is easy to skim past:

git clone https://github.com/zhoutaoo/SpringCloud.git --recursive

The reason sits in the repository layout. The root contains a .gitmodules file alongside an opensabre-framework directory, and the documentation describes the project as an aggregate one whose related modules reference the modules under the opensabre organisation. So the framework itself is a submodule rather than vendored source. A clone without --recursive gives you an empty placeholder where the framework should be, and the failure appears later as missing packages rather than as an obvious error at clone time. For anyone reading the code to learn from it, that single flag is the difference between a working tree and a confusing one.

Database setup is three ordered SQL files, run by hand

Getting a base application to start does not involve a migration tool. The instructions describe three steps in a fixed order, beginning with creating the database and tables. The scripts live under a path of the form application/src/main/resources/db, with base-origanization/src/main/resources/db given as the example, and the order is specific: execute the db file first to create the database, then the ddl file to create the table structure, then the dml file to initialise the data. Each base application in the tree, base-authorization, base-gateway, base-gateway-admin and base-organization, carries its own set. The consequence is that standing up an environment means running several sets of scripts in the right order on every database, and a partially initialised schema shows up as application errors rather than as a clear setup failure.

Each service is its own process on port 8080

Once the schema exists, an application is started from its own directory, either with mvn spring-boot:run or with the run function your IDE provides, and then tested with a request such as:

root@xxxxx # curl http://localhost:8080/test/echo?name=zhangsan

{
    "code":"000000",
    "mesg":"处理成功",
    "time":"2022-11-22T14:46:58.643Z",
    "data":"Hello:zhangsan"
}

The port defaults to 8080 and you start whichever services you need for the test you are running. Two documentation endpoints are live by default, Swagger UI at localhost:8080/swagger-ui/index.html and knife4j at localhost:8080/doc.html, which follows from knife4j and Swagger 3.0 being integrated by default. Since these are independent Spring Boot processes rather than modules in one runtime, bringing up a full environment means starting several of them, and the default port means they cannot share a host without overrides.

Controllers return raw types because the envelope is mandatory

The first feature listed is a unified RESTful response envelope, and its consequence is spelled out: the controller returns the original type with no manual wrapping, which simplifies code and improves readability. The sample response shows the shape, a code field, a message field, an ISO timestamp and a data field. Feature two covers unified exception handling, with the basic responses wrapped for cases such as parameter validation and file upload, and it is described as easier to extend.

Permission resources are derived from the code, not declared

The most operationally interesting feature is number six, which says that at system startup all RESTful urls are automatically collected and registered as permission resources, for the purpose of centralised permission management and authorisation. That means your authorization surface is a startup-time artefact of your controllers rather than a list you maintain by hand. Two consequences follow. Renaming a handler or moving a path changes what appears in the permission table without anyone editing a configuration file, which is convenient until you need to reason about the change. And the registered set is only as complete as the url collection, so a feature exposed outside the REST layer, or behind a path the collector does not see, is not covered by whatever centralised permission logic you build on top of it.

Minio storage and data permissions are the two unfinished rows

The base services table is the honest part of this repository, because it distinguishes done from not done. Registry and configuration centre on Nacos, the message bus on Spring Cloud Bus with RabbitMQ, the dynamic gateway on Spring Cloud Gateway, authorisation on Spring Security OAuth2 in JWT mode, fault tolerance on Spring Cloud Sentinel and service calls on Spring Cloud OpenFeign are all marked complete. Two rows carry the construction marker instead: object storage on Minio, and data permissions, which are described as enhancing the original query through mybatis so that business code does not have to control it. So of nine rows, seven are in place and the two most commonly wanted extras are not. Plan around that, and note the gateway's own note that traffic control across service, IP and user dimensions is backend configurable, and that note itself carries the construction marker.

Masking and config encryption are opt-in, not automatic

Two features carry the security-adjacent weight and both are configurable rather than automatic. Feature twelve covers log sensitive data masking configuration plus response message masking driven by annotations, which means a response field is only masked if it is annotated, while log masking is a matter of configuration. Feature eleven splits configuration into framework global settings and application settings, the latter covering circuit breaking, degradation and gateway routing, and states that configuration items support encrypted processing. Around them sit smaller pieces: log tracing and actuator integrated by default with a unified log format, and spring validation with extended annotations for enums and phone numbers. The practical consequence is that the framework gives you the switches for the hard parts, and the work of deciding which fields get annotated stays with your team.

Editorial conclusion

This scaffold suits a team already working in Spring Cloud 2023 and Spring Cloud Alibaba who want RBAC, OAuth2 with JWT, a configurable gateway and Sentinel wired up rather than assembled. For a new project, the preface points you to the Opensabre framework and its online documentation, and two rows of its own service table, Minio storage and data permissions, are still marked unfinished. Before adopting, read the Opensabre documentation the preface links to, and remember the documented clone command needs --recursive or you get no framework sources.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. zhoutaoo/SpringCloud on GitHub