What Is Microservices? Architecture, Practices, and GeTui’s Implementation

Traditional monolithic architecture bundles all code and data into a single package, leading to high development cost, poor maintainability and scalability, while microservice architecture assigns each business capability to an independent service that can be deployed, scaled, and technologically selected separately, despite added deployment and operational complexity.

Microservice communication can be handled either by clients calling multiple services directly—resulting in exposed interface details, inconsistent protocols, and complex client code—or by routing all client requests through a unified API gateway that standardizes protocols, authentication, and flow control, albeit with potential latency and a possible bottleneck.

Service registration and discovery are essential; client‑side discovery requires knowledge of all service addresses and high maintenance, whereas a gateway‑based discovery simplifies client logic and centralizes authentication, demanding high availability of the gateway.

To maintain orderly service interactions, circular dependencies should be avoided; higher‑level services may depend on lower‑level ones, and asynchronous decoupling via message queues (e.g., double‑write patterns for order systems) can handle cross‑service data synchronization.

GeTui’s microservice practice covers three scenarios: a high‑throughput push notification service built with Java and SOA; an advertising trading platform (including DMP) also Java‑centric with demanding concurrency; and a web business system offering stateless request/response APIs, which is the most extensively micro‑service‑ized.

The overall architecture routes external traffic through LVS/HaProxy to an OpenResty‑based API gateway; the gateway forwards requests to service units implemented in Lua, Node.js, or Java, each registering itself with Zookeeper for discovery, while OpenResty provides unified authentication without extra performance cost.

Service units expose endpoints via OpenResty, using Lua scripts for business logic and proxy_pass/upstream to forward to webnode processes; Java logic can also be handled within OpenResty, making the language choice irrelevant for the “drawer‑in‑cabinet” model.

OpenResty integrates Lua scripting and registers services via Zookeeper; to bridge Lua’s incompatibility with Zookeeper, a WebSocket client in each Node.js process maintains a long‑lived connection and heartbeat, allowing OpenResty to delegate registration to a selected Node.js process.

Unified authentication is performed at the OpenResty layer, eliminating additional overhead.

The article uses a “channel” metaphor to illustrate service calls: requests flow through pipes unchanged, with intra‑process require calls for close services and HTTP calls for distant ones.

In the Q&A, the team describes DevOps automation using Jenkins for automatic packaging, testing, deployment, and rollback, and explains that OpenResty’s unified session handling reduces developer effort compared to maintaining separate authentication modules across services.