From PHP Monolith to Java Microservices: Mogujie's Ops Evolution and Lessons

Preface

In 2015 the author joined Mogujie during a period of rapid business growth. The technical team and the operations group both expanded from scratch, prompting a need to share the evolution process.

1. Technical Architecture and Operations Evolution

Early 2011 the product launched as a simple guide‑shopping site using a common LNMP stack (Linux, Nginx, MySQL, PHP). Development engineers performed operations tasks themselves.

By 2013 the business shifted to e‑commerce, still on LNMP. Increasing traffic exposed bottlenecks in database and cache connections, leading to the addition of DB and cache middle‑layers.

As the PHP codebase grew, it became increasingly monolithic and hard to maintain. Developers resorted to copying files, which further bloated the project and caused reliability issues. To break the monolith, the team adopted a Java service‑oriented architecture, splitting the system into many small services accessed via RPC.

2. Operations Solutions

The team approached the problem in two phases: building a solid foundation (0→1) and then delivering higher‑value capabilities (1→100). Central to the foundation was standardization :

Software & Infrastructure : unified OS versions, kernel parameters, and KVM‑based resource templates (e.g., 2C2G, 8C16G).

Application & Configuration : documented deployment directories, scripts, parameters, and versioning for each application.

Architecture : standardized access layer, middleware, cache, and database configurations.

These standards were codified into application templates and stored in a lightweight CMDB that maps applications to IP addresses. An application‑configuration system then automated deployment based on the templates.

With the foundation in place, the team tackled continuous integration and release . The Java release pipeline follows a typical industry flow: code commit → build server (compile, package dependencies) → test environment → pre‑release/gray environment → production. Automation reduced manual steps, shortened release cycles, and dramatically improved developer efficiency.

3. Operations Technology Management

To improve system stability the team introduced several mechanisms:

Full‑link tracing : an Nginx module generates a global TraceID for each request. Logs containing the TraceID are sent to Kafka, processed in real‑time by Storm, and persisted in Hadoop. This enables rapid identification of slow services and abnormal call patterns.

Pre‑plan, switch, capacity assessment, and flow‑control systems to handle traffic spikes and prioritize core transactions.

Examples show how tracing isolates a slow evaluation service, reveals excessive cache calls, and maps service dependencies for better governance. During peak traffic (e.g., large promotions), non‑core services can be throttled or degraded to protect critical transaction paths.

Overall, the combination of standardization, automated CI/CD, and observability tools transformed Mogujie's operations from ad‑hoc scripts to a reliable, scalable platform.