Lessons and Reflections on Service‑Oriented Architecture and Microservice Evolution at Zhihu

Zhihu's evolution toward service‑oriented architecture has been a central theme over several years, growing the company from dozens to hundreds of engineers while building monitoring, tracing, frameworks, containers, and multiple backend teams, prompting new technical reflections.

The vision of service‑orientation aligns with popular microservice promises: loose coupling, independent releases, rapid iteration, fault isolation, and increased reuse.

Splitting monolithic applications into independently deployable services reduces overall complexity, enables parallel development, assigns clear ownership, allows targeted scaling, and improves stability, but it also introduces unexpected pain points.

One major issue is the uncontrolled proliferation of services; new features often start as separate services, leading to fragmentation, higher communication overhead, and difficulty extending existing services.

Horizontal splitting based on RPC brings compatibility constraints, frequent breaking changes, high deployment risk because upstream and downstream services must be released together, and limited rollback options.

RPC also changes access patterns: N+1 queries that are acceptable for cache‑based data become problematic for RPC, causing unexpected load, higher resource consumption, and performance that lags behind direct cache access.

Vertical splitting using SSO (single sign‑on) and HTTP interfaces offers an alternative, reducing intermediate layers, enabling gray‑scale releases, and keeping client interactions transparent, especially for new projects with limited coupling to the main site.

Desktop client scenarios illustrate that a page often aggregates multiple services (e.g., Q&A, comments, recommendations), making page‑level splitting unsuitable; instead, component‑level alignment with backend modules mirrors the front‑end’s componentization trend.

Vertical splitting risks inconsistency across shared entities; Zhihu mitigates this by maintaining comprehensive Swagger documentation to enforce uniform field definitions across services.

Defining service boundaries ideally matches business boundaries, but practical constraints require prioritization, assessment of split benefits versus risks, and consideration of team ownership, domain focus, collaboration improvement, and core versus non‑core distinction.

The Feed service exemplifies these principles: an independent team, reduced redundant RPC calls, uniform access patterns, TTL caching, circuit‑breaker protection, and a clear contract that lets vertical services integrate via a single RPC, improving both performance and stability.

Service layering separates business services—optimized for rapid iteration and front‑end developer friendliness—from common services that prioritize stability, reliability, and strong SLAs for reuse across the organization.

Key takeaways include: organize collaboration around domains rather than technical roles, adopt a goal‑driven and incremental approach to service‑ification, and continuously collect feedback to refine engineering practices.

Looking forward, Zhihu reaffirms its commitment to the original microservice goals—loose coupling, independent releases, fast iteration, fault isolation, and reuse—while acknowledging inevitable trade‑offs and the need for ongoing architectural improvement.

References:

[1] Microservices: a definition of this new architectural term: https://www.martinfowler.com/articles/microservices.html [2] Seven Microservices Anti‑patterns: https://www.infoq.com/articles/seven-uservices-antipatterns [3] Service Level Agreement: https://en.wikipedia.org/wiki/Service-level_agreement [4] Swagger: https://swagger.io/ [5] Eventual consistency: https://en.wikipedia.org/wiki/Eventual_consistency