# Mall4cloud: a Spring Boot 4 microservices mall you can actually read

> Mall4cloud is the open source B2B2C mall line under Mall4j, split into gateway, auth, rbac, product, order and payment services. It is a reference architecture first and a product second, and the AGPLv3 licence is the line most teams trip over.

**gz-yami/mall4cloud** — ⭐️⭐️⭐️微服务商城系统 springcloud微服务商城 小程序商城

- Repository: https://github.com/gz-yami/mall4cloud
- Website: https://www.mall4j.com
- Stars: 6,158 · Forks: 1,481
- Language: JavaScript
- License: AGPL-3.0
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/gz-yami-mall4cloud

## What Mall4cloud is, and the problem it removes

Building a multi-merchant mall from scratch means writing the boring layer first: tenant separation between platform and shop, a permission model that spans both, an order state machine that survives payment callbacks, and a product catalogue that supports SKUs and specifications. Mall4cloud ships that layer as a set of Spring Cloud services. The README describes the open source edition as a B2B2C architecture with a platform console, a merchant console and a user client, plus what it calls a complete order flow.

The intended reader is not a shop owner. The README is explicit that the repository suits people learning microservice e-commerce architecture, evaluating multi-merchant mall source code, and doing secondary development on an enterprise mall. That framing matters, because it tells you what the project optimises for: readable service boundaries and a conventional layering scheme, not a one-command deployment. If you want a mall running tonight, this is the wrong shape of project.

## How the services are split and how a request moves

The gateway is the only public door. The README states that both the admin front end and the uni-app client connect to the gateway on port 8000, and warns against pointing VITE_APP_BASE_API at a business port. Auth, rbac, product and the rest listen on their own ports for local startup and Nacos registration, but those ports are internal.

Service-to-service calls go through Feign, and the interfaces are not declared inside each service. They are extracted into a mall4cloud-api module with one submodule per provider: mall4cloud-api-auth, mall4cloud-api-biz, mall4cloud-api-leaf, mall4cloud-api-multishop, mall4cloud-api-order, mall4cloud-api-platform, mall4cloud-api-product, mall4cloud-api-rbac, mall4cloud-api-search and mall4cloud-api-user. The README gives the reasoning directly: Feign is HTTP, so when a provider changes an interface and the caller does not, you get an exception, and pulling the contracts into one module makes that breakage visible at compile time. It is a sound decision and it is also a coupling decision, since every consumer now depends on the contract module.

Around that core sit Nacos for registration and configuration, Seata for distributed transactions, Redis for caching, RocketMQ for messaging, Elasticsearch for search, MinIO for file storage, and mall4cloud-leaf, described as an ID generation service based on Meituan Leaf. Inside each service the layering is the familiar one: Controller, Service, Manager, Mapper, plus VO, DTO, BO and Model objects. The README notes that the Manager layer absorbs third-party platform wrappers and shared middleware handling, and that Mapper talks to MySQL. Listeners consume RocketMQ messages.

## Starting the minimum backend chain on port 8000

The README does not give a single install command. It points to the doc directory in the repository, a Gitee mirror of that documentation, and a Bilibili video on setting up the development environment. What it does give is the order of operations and the minimum set of services.

Bring up the middleware first. The README lists MySQL, Redis, Nacos and MinIO for the initial run, and the wider stack adds RocketMQ, Seata and Elasticsearch. Then start the smallest backend chain that can serve a request. The README names the gateway mall4cloud-gateway on port 8000 plus auth, rbac, biz, and either the platform console or the merchant console:

```bash
mall4cloud-gateway    # port 8000
mall4cloud-auth
mall4cloud-rbac
mall4cloud-biz
mall4cloud-platform   # or mall4cloud-multishop
```

The front end then points at the gateway and nothing else, using the variable the README names:

```bash
VITE_APP_BASE_API
```

One detail the README calls out: the example IP in the repository is 192.168.1.46, and it says to replace it in bulk with your own address once you have the source. Skipping that step is the most common way to get a stack that starts cleanly and then fails on every cross-service call. The platform and merchant consoles ship with default credentials of admin and 123456, which you should change before anything is reachable from outside your machine.

## The version jump to Spring Boot 4 and what it costs you

Release v4.0, tagged on 2026-03-26, is described as Spring Boot 4 plus Spring Cloud 2025.1. The previous line, 3.4, was Spring Cloud 2024 with Spring Boot 3.4, released on 2025-03-10, and 3.3 before that on 2024-07-30. The README states that the mainline has moved to Spring Boot 4, Spring Cloud and Vue3, and that exact dependency versions should be read from the backend pom.xml and the front-end package.json rather than from the README.

That last sentence is the honest part and also the warning. A Spring Boot 4 mainline means the surrounding ecosystem has to keep up: Seata, Nacos client, RocketMQ client, the Elasticsearch client and the MyBatis layer all have to be compatible versions. If your team already runs a Spring Boot 3.x estate, adopting this repository's mainline puts you ahead of your own upgrade schedule rather than alongside it. The README makes the argument for moving, saying that systems left on older stacks face higher framework upgrade, dependency compatibility and security maintenance costs later. That is a reasonable position, but it is the project's position, and it applies to the project's own roadmap as much as to yours.

The repository was last pushed on 2026-09-20, which is recent, and it is not archived.

## Where it is the wrong tool

The licence is the first boundary. The open source edition is AGPLv3. The README states plainly that closed-source commercial use requires a separate commercial authorisation, and that enterprise private deployment, cluster deployment support, long-term support and additional business editions fall under the Mall4j commercial offering. AGPLv3 is a network copyleft licence: if you modify the code and let users interact with it over a network, the licence's obligations reach your users. Teams that want to keep their own modifications private should treat this repository as a study copy, not a starting point, and talk to the vendor instead.

Operational weight is the second boundary. A gateway, auth, rbac, biz, platform, multishop, product, order, payment, search, user and leaf service, plus Nacos, Seata, RocketMQ, Elasticsearch, Redis, MinIO and MySQL, is a lot of moving parts for a shop with a handful of merchants. A single-process mall will be cheaper to run and easier to debug at that scale. The README also separates the open source edition from the enterprise editions explicitly, noting that the enterprise versions are not simply an enhanced build of this repository. If your requirement list includes SaaS, multi-tenant or cross-border scenarios, the open source repository is not the thing you are evaluating.

There is also a documentation gap worth naming. The README describes the directory conventions and the service map in detail, but it does not document rollback behaviour for the Seata transactions, nor does it describe what happens to in-flight orders when a service is restarted mid-saga.

## Mall4j single-process and the other mall projects people compare

The nearest alternative is Mall4j itself, the single-process open source mall from the same organisation. The README draws the line directly: Mall4j's open source repository is aimed at Java monolith malls and single-merchant B2C basics, while Mall4cloud's open source repository targets a microservice B2B2C architecture with platform, merchant and user sides plus several backend service modules. The difference is not feature count, it is the shape of the deployment and the shape of the team that can operate it. A monolith gives you one process to start, one log to read and no distributed transaction to reason about. Mall4cloud gives you independent scaling of the product and order services, at the cost of Nacos, Seata and a gateway between you and a stack trace.

Other Java mall projects circulate in the same conversations, including macrozheng's mall, litemall, Xmall and Yudao Cloud. The README does not describe their internals, so the only fair comparison is at the level of the split: Mall4cloud's distinguishing trait is that it is a B2B2C microservice mall with the Feign contracts extracted into a shared api module, which is a specific answer to the interface-drift problem that plagues multi-service Java codebases. If you are weighing it against a monolith, that extraction is the concrete thing to inspect, because it is what you will live with during secondary development.

## Licence, upgrade cost and what the repository commits to

The licence is AGPL-3.0 and it is stated in the README, in the repository's LICENSE file and in the repository metadata. The README's own summary is that the open source edition suits learning, evaluation and use cases that comply with the agreement, and that closed-source commercial use, enterprise private delivery, microservice cluster delivery, enterprise support and further business editions belong to the commercial authorisation. This is a description of the vendor's position, not legal advice; if your distribution model depends on the answer, get it from a lawyer rather than from a README table.

The upgrade cost is visible in the release history. Three major lines in roughly two and a half years, each moving the Spring Boot and Spring Cloud baseline: 3.3 in July 2024, 3.4 in March 2025, 4.0 in March 2026. Each of those is a framework generation, not a patch. If you fork this repository, you inherit the obligation to move with it, or to stop moving and carry the security maintenance yourself. The README's own argument about old stacks applies to forks of this project as much as to anything else.

On support, the README is candid: the open source edition is described as community-exchange based, while enterprise-grade after-sales support sits with the commercial offering. There is a technical forum linked from the README, and the documentation lives in the doc directory of the repository with a Gitee mirror.

## Conclusion

Adopt Mall4cloud if you want a working multi-merchant mall to study or to fork under AGPLv3, and you are willing to run MySQL, Redis, Nacos, MinIO, RocketMQ, Seata and Elasticsearch before the first page loads. Do not adopt it if you intend to ship a closed-source product: the README states that closed-source commercial use requires a separate commercial licence from the Mall4j site. Before committing, verify the dependency versions in the backend pom.xml and the front-end package.json, confirm the 192.168.1.46 placeholder addresses are all replaced, and check whether your own distribution obligations under AGPLv3 are ones you can meet.

## FAQ

### What is Mall4cloud?

It is the microservice mall product line under Mall4j, and this repository is the main open source repository for Mall4cloud. The open source edition targets a B2B2C mall architecture built on Spring Boot 4, Spring Cloud, Nacos, Seata, Redis, RocketMQ, Elasticsearch and MinIO, with a platform console, a merchant console, a user client and a complete order flow.

### How do I install and start Mall4cloud?

The README does not give a single install command; it points to the doc directory in the repository, a Gitee documentation mirror and a Bilibili video on setting up the development environment. It does give the order: start the middleware MySQL, Redis, Nacos and MinIO first, then bring up the gateway mall4cloud-gateway on port 8000 together with auth, rbac, biz and either the platform console or the merchant console.

### Which port should the Mall4cloud front end connect to?

Only the gateway, on port 8000. The README states that both the admin console and the uni-app client should point VITE_APP_BASE_API at the gateway, and that the individual service ports exist for local startup and Nacos registration rather than for front-end traffic.

### Can I use Mall4cloud in a closed-source commercial product?

The open source repository is AGPLv3, and the README states that closed-source commercial use requires a separate commercial authorisation, with enterprise private deployment, cluster support and additional business editions belonging to the Mall4j commercial offering. This is the vendor's stated position, not legal advice.

### Has Mall4cloud been upgraded to Spring Boot 4?

The README states that the mainline has been upgraded to Spring Boot 4, Spring Cloud and Vue3, and that the exact dependency versions should be read from the backend pom.xml and the front-end package.json. Release v4.0, tagged on 2026-03-26, is described as Spring Boot 4 with Spring Cloud 2025.1.

## Sources

- [gz-yami/mall4cloud on GitHub](https://github.com/gz-yami/mall4cloud)
- [License: AGPL-3.0](https://github.com/gz-yami/mall4cloud/blob/master/LICENSE)
- [Project website](https://www.mall4j.com)
- [README](https://github.com/gz-yami/mall4cloud/blob/master/README.md)
- [Releases](https://github.com/gz-yami/mall4cloud/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gz-yami-mall4cloud