Microservice Transformation Experience and Target Architecture Design
This article shares the author's experience and lessons learned from a two‑day intensive discussion on microservice migration, outlining a concrete implementation plan, current architectural challenges, key debates, and the final target architecture blueprint for a third‑party payment company.
As business pressure grew and infrastructure improved, the microservice transformation of our factory’s system architecture was officially scheduled. After two days of intense discussion, the architecture team clarified many business boundaries, and I summarize the knowledge gained from this experience.
Microservice transformation is exactly what this picture depicts.
00 Preface Why build a microservice architecture, how to construct it (see linked article), have been covered elsewhere. This article focuses on how to design a perfect target architecture in the initial stage of microservice migration, which will guide all subsequent transformation actions. The material comes from our factory’s target architecture design process, recorded as a detailed log.
01 Microservice Transformation Implementation Plan Microservice migration is a long process, often taking about two years for systems of similar scale. To ensure orderly progress, we propose a practical plan:
Provide the company’s target architecture blueprint.
Select frameworks and improve infrastructure.
Define development standards for microservice migration.
Practice with typical projects and summarize experience.
Revise architectural specifications.
Roll out large‑scale microservice migration.
This plan aims to make business systems more reasonable, reduce coupling, clarify business boundaries, and achieve a tree‑like dependency structure.
02 Current Architecture We are a third‑party payment company, with a typical range of business systems. Early development was business‑driven, leading to many independently built, redundant, and poorly coupled systems. The existing architecture includes a mix of microservice designs, SOA, front‑back separation, and monolithic projects, resulting in unclear business boundaries and duplicated functionality.
The main problems are:
Slow new product development, unable to keep up with rapid business growth.
Difficulty achieving operational automation.
Challenges scaling performance through capacity expansion.
Microservice principles—small, independently deployable, automated services—combined with domain‑driven design can help isolate services, improve performance, and provide a clearer architectural upgrade path.
03 Main Discussion Issues Key design principles of microservices include keeping services small, independently deployable, and automatable. The team debated several topics:
Where to draw the boundary between underlying capabilities and upper‑level products.
Trade‑offs between splitting and merging services.
Whether single‑point modules are permissible in business design.
The extent to which organizational structure and division of labor can change.
These issues essentially revolve around business boundary definition—vertical (layered) and horizontal (module) boundaries. Using a recharge function as an example, we concluded that standardized functions should be provided by underlying services, while highly specialized features should be implemented by the product layer.
Regarding splitting vs. merging, while microservices aim for high cohesion and low coupling, some common utilities (e.g., unified transaction numbers, session management) are better abstracted as shared services. The discussion also highlighted that microservice architecture influences team organization, encouraging full‑stack teams responsible for the entire product lifecycle.
In summary, architecture design is a balancing act; the best design fits the company’s business development, planning, and organizational structure.
04 Target Architecture (Blueprint) Based on the consensus reached during the discussion and my understanding of the business, I created the following target architecture diagram.
This article reflects my personal understanding of microservice transformation and business refactoring and does not represent the official company architecture; design choices involve trade‑offs and timing.
Source: http://www.jianshu.com/p/03f2ccbae7c7
© Content sourced from the internet; rights belong to the original author. We will credit the author and source whenever possible. If any infringement is identified, please inform us for prompt removal.
--- End of article ---
Note: The following promotional segment is unrelated to the technical content.
Excellent talent is not lacking opportunities, but the right fit. 100offer rigorously matches top talent with top companies. Scan the QR code to register and receive 5‑10 suitable offers within a week.
Architecture Digest
Focusing on Java backend development, covering application architecture from top-tier internet companies (high availability, high performance, high stability), big data, machine learning, Java architecture, and other popular fields.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.