goshop2: a Java SOA storefront kept as a reference for how 2015 era Dubbo systems were built

Facade, provider, consumer, and five services on five Dubbo ports

Goshop2 is a distributed e-commerce platform based on Spring, Dubbo and MyBatis, and its stated purpose is to show how a typical enterprise Java SOA e-commerce system is organised: databases split by business, services split into Facade, Provider and Consumer layers, with Dubbo, ZooKeeper, Redis, MyBatis, Shiro and ActiveMQ doing the work of distributed service governance, read write separation, shared sessions, back office administration, the shop portal, a CMS and WeChat access.

The service table is the clearest statement of the design, and it gives each business domain a facade module, a provider module, a responsibility and a port.

| Module | Facade | Provider | Responsibility | Dubbo port | | --- | --- | --- | --- | --- | | Users | `goshop-facade-users` | `goshop-service-users` | users, members, roles, password recovery | `28880` | | CMS | `goshop-facade-cms` | `goshop-service-cms` | articles, article categories, slides, multilingual articles | `28881` | | Email | `goshop-facade-email` | `goshop-service-email` | mail sending, MQ mail processing | `28882` | | Goods | `goshop-facade-goods` | `goshop-service-goods` | goods categories, goods types | `28883` | | Store | `goshop-facade-store` | `goshop-service-store` | shops, shop levels, onboarding, in shop categories | `28884` |

Five providers on five consecutive ports, five facade modules, and four business databases underneath. The layering is the classic one: the web tier never talks to a provider directly, it consumes a facade interface through Dubbo, and a provider registers itself with ZooKeeper.

The README names the two files that implement that wiring. The web tier references the facade services through dubbo-reference-*.xml, and each provider registers to ZooKeeper through applicationContext-dubbo-provider.xml. So the contract between a consumer and a provider is declared in XML on both sides, which is exactly the Spring and Dubbo idiom of the period, and it is the part of the repository you should read first if you want to understand how the pieces connect.

Four databases, and a second datasource for every read

The data model is the part of the architecture that a reader can learn the most from, because the rules are simple and the consequences are visible.

The scripts live in goshop-db, and the repository lists six of them with their default database names and the service each belongs to.

| Script | Default database | Service | | --- | --- | --- | | `goshop_user.sql` | `goshop_user` | `goshop-service-users` | | `goshop_cms.sql` | `goshop_cms` | `goshop-service-cms` | | `goshop_goods.sql` | `goshop_goods` | `goshop-service-goods` | | `goshop_store.sql` | `goshop_store` | `goshop-service-store` | | `goshop_user_test.sql` | test database | user service test data | | `goshop_user_test_read.sql` | read only test database | user service read replica test data |

Those last two rows are the tell. There is a test read database, which means the read write separation is not a claim in a slide but a second datasource that has to be provisioned and populated.

The configuration for that lives per service, in a db.properties file under each service's resources directory, for example goshop-service-users/src/main/resources/resource/db.properties and goshop-service-cms/src/main/resources/resource/db.properties. Each service keeps two data sources, the master and the read replica, named master.jdbc.* and read.jdbc.*.

So the isolation is vertical and complete. A user request never touches the goods database, and the goods service never touches the user database. That is a real architectural decision with real costs, which is why it is worth studying here rather than in a book: the price is that a query joining user data to goods data has to become a service call, and the benefit is that each domain can be scaled, deployed and failed independently.

The optional infrastructure layer below the databases is Redis, FastDFS and Solr, described in the architecture diagram as optional infra, with Solr for search and FastDFS for file storage.

The module layout, and the three modules the build ignores

The repository is a Maven multi module project with a root pom.xml as the parent, and the directory names describe the layering directly.

goshop-common
goshop-common-config
goshop-common-service
goshop-common-shiro
goshop-common-web
goshop-facade-users
goshop-service-users
goshop-web-manager
goshop-web-cms
goshop-web-portal
goshop-web-wechat
goshop-mq-email-producer
goshop-mq-email-consumer
goshop-cms-android
goshop-db

The common modules split by concern rather than by layer, and each is named for what it holds. goshop-common carries the shared POJOs, exceptions and utility classes. goshop-common-config holds the shared configuration for Dubbo, Redis, MQ and mail. goshop-common-service holds server side shared capabilities such as the Redis client wrapper. goshop-common-shiro holds the Shiro authentication component, the Redis session and cache integration, and the FreeMarker tags. goshop-common-web holds the web side shared components, attachments, captcha, CORS and response helpers.

The web modules each become a deployable war. The back office becomes admin.war, the CMS REST interface becomes cms_r.war, the shop portal with member and onboarding pages becomes shop.war, and the WeChat end becomes wx.war. The Maven package directories in the top level listing match that exactly, and the naming convention is the clearest documentation in the repository for what runs where.

The README makes one point that a reader would otherwise miss. The root pom.xml aggregates the common, facade, service and web modules, but goshop-mq-email-producer, goshop-mq-email-consumer and goshop-cms-android sit in the repository without being aggregated by the root POM, and are to be treated as standalone modules. That is a real trap for anyone who runs a build at the root and expects the mail example and the Ionic front end to be produced, and it is the kind of detail that only shows up when you read a repository that has been assembled over years.

A stack from 2015, with the version numbers still on the badges

The badges at the top of the README are the fastest way to date the project. Java 7, Dubbo 2.5.3, Spring 4.1.6, and the description calls it a classic enterprise Java stack that keeps the full engineering practice of the Spring MVC, Dubbo and MyBatis era.

The technology list is a complete inventory of that period: Java 7 with a Maven multi module build, Spring 4.1.6 with Spring MVC and Spring JDBC, MyBatis 3.2.8 with MyBatis-Spring 1.2.2 and PageHelper, Dubbo 2.5.3 with ZooKeeper 3.4.6 and zkclient, Shiro 1.2.4 with Redis and Jedis, MySQL with the Druid connection pool, FreeMarker with JSP and JSTL, ActiveMQ with JavaMail, SolrJ and FastDFS, Log4j with SLF4J, and Ionic with AngularJS for the static mobile assets.

Read that list as a period marker rather than a recommendation. Dubbo 2.5 predates the Dubbo 3 rewrite and the current Apache Dubbo project, and ZooKeeper 3.4.6 is several major versions behind. Shiro 1.2.4 is a long way from the current line. The MyBatis 3.2.8 and Spring 4.1.6 combination places the code firmly in the Spring 4 era.

The README itself frames this honestly. The technology stack reflects practices common around 2015 to 2017, and the project remains valuable for studying the evolution of enterprise Java systems. The background says it was created as a refactored version of the original Goshop project, and that the goal was to explore service oriented architecture, database read write separation, business database isolation and distributed service deployment using Dubbo.

That framing is what makes it worth reading and also what limits it. It is a preserved system, and preserved systems are for understanding, not for copying into a new deployment.

Where this stops being a shop and becomes a diagram

There is a screen in the README, and it is worth describing precisely because it tells you what state the repository is in.

The Screenshots section states that the repository currently has no complete runtime screenshots committed. To avoid broken image links in the README, the suggested paths are given, under docs/images/, for the admin console, the shop portal and the WeChat end, with the note that once the images are in place the section can be replaced with a markdown snippet.

In other words, the repository contains a template for a screenshots section rather than the screenshots themselves. That is a small detail and a revealing one. It tells you this is a repository being curated for readability, with an explicit maintenance intent and an explicit scope, and that whoever maintains it is thinking about what a reader sees.

It also tells you that running the application and capturing it was not done, or not done recently. A project with a working deployment pipeline would have the images, and the images are the part of a reference implementation you most want, because they show you what the twenty top level modules actually add up to in a browser.

The project also says it is maintained as a reference implementation for developers studying large scale Java SOA applications, and that it is looking for help to enrich the plugins, with a contact address and an invitation to open a GitHub issue. The emphasis throughout is on reading, which is consistent with the absence of a runnable demo.

The Web and WeChat surfaces are described in the highlights list as the back office, the shop portal with member and store onboarding, and the WeChat end with server verification, message handling, menu creation and mobile pages. Those are real features in the code. What is missing is evidence of a running instance.

A concrete alternative, and what the reference value actually is

The honest comparison is with a modern single schema e-commerce backend, and the difference in approach is instructive rather than embarrassing.

A modern application of the same shape would use one relational database with the domains as schemas or tables, one application process, and a connection pool in front of it. Scaling would be vertical, or read replicas behind a load balancer, or a split at the point where the data actually needs splitting. Cross domain queries stay as SQL joins.

Goshop2 does the opposite. Four databases, so a join across domains becomes a Dubbo call, which is a network hop and a failure mode, in exchange for independent deployment and independent scaling of each domain. Two data sources per service, so reads go to a replica and writes to the master, which means a read after write may not see the write, and the test read database exists so that this behaviour can be exercised. A service registry in ZooKeeper, so a provider can be discovered at runtime. Sessions in Redis behind Shiro, so any web node can serve any request.

Every one of those choices was standard practice for a Chinese enterprise Java shop around 2016, and every one of them has a modern equivalent that is cheaper. That is exactly the value of the reference. Reading a system that made the 2015 choices, with the reasoning visible in the module structure and the XML wiring, is a far better way to understand why service oriented architecture was organised this way than a description of it.

The failure mode to watch for is cargo culting it. Nothing in this repository should be copied into a new system as a pattern, because the answers it encodes, ZooKeeper and Dubbo 2.5 and Shiro 1.2, have all moved on and the trade offs have changed with them. What is worth taking is the shape, the separation of facade from provider, the discipline of one database per business domain, and the explicit naming of a read datasource, because those ideas survive even when the components do not.

Editorial conclusion

goshop2 fits a developer who wants to read a complete enterprise Java SOA system of the Dubbo era, with the module split, the XML wiring, the sharded business databases and the read write separation all present and connected, rather than a toy. It does not fit a team that wants to run a shop, because the stack is Java 7 with Spring 4.1.6 and Dubbo 2.5.3, and the project positions itself as a study artefact rather than a product. Check three things before you use it. Check the age of the stack, because the README says the technology reflects practices common around 2015 to 2017 and the project is valued for studying the evolution of enterprise Java systems, so treat every dependency version as a historical artefact. Check the module boundaries, because the root pom.xml aggregates 19 modules and three of them are explicitly not aggregated and are to be treated as standalone. And check the deployment story, because a running instance needs ZooKeeper, four MySQL schemas, Redis, ActiveMQ and a set of Dubbo provider ports, which is a lot of moving parts to stand up. The last push was on 2026-06-16, the repository has no GitHub releases, and no licence is published in the repository metadata.

Frequently asked questions

Official sources

1. Issues
2. pzhgugu/goshop2 on GitHub
3. README