英文论文3

3.3 Service Decomposition Strategy
Service decomposition constitutes one of the most critical decisions in microservices architecture design. Excessively fine granularity leads to excessive inter-service communication overhead and increased maintenance costs, while overly coarse granularity risks degenerating into a "Distributed Monolith," forfeiting the core advantages of microservices architecture. This paper comprehensively applies the Bounded Context concept from Domain-Driven Design (DDD) and Ackerman coupling analysis methodology to guide the delineation of service boundaries.
Domain-Driven Design, introduced by Eric Evans, addresses complex business logic through the establishment of a unified domain model. During the service decomposition process, business domains are first classified into Core Domain, Supporting Domain, and Generic Domain. The Core Domain represents the enterprise's competitive advantage, encompassing dispatch management and vehicle status monitoring; the Supporting Domain provides auxiliary capabilities for core business, including user management and data analytics; the Generic Domain covers common technical capabilities, including authentication, authorization, and audit logging. Building upon this classification, bounded contexts define each service's data ownership and business responsibility boundaries. Specifically, the Dispatch Service owns core data such as dispatch tasks, dispatch rules, and execution records; the Vehicle Management Service owns vehicle profiles, maintenance records, and vehicle status data; and the Track Service owns GPS coordinates, travel trajectories, and mileage statistics. Each service may only access another service's data through API interfaces, ensuring clear data boundaries and service autonomy.
4 Key Technical Solutions
4.1 API Gateway and Service Governance
The API Gateway serves as the unified entry point for all external requests in a microservices architecture, assuming critical responsibilities including routing, security authentication, traffic control, and protocol conversion. This system adopts Spring Cloud Gateway as the API Gateway implementation. Built upon the Reactor non-blocking programming model and running on Netty, Spring Cloud Gateway offers significantly higher concurrent processing capacity and lower memory consumption compared to traditional Servlet containers such as Tomcat, making it particularly well-suited for IO-intensive gateway scenarios. For routing configuration, an automatic route discovery mechanism based on service names is employed: the gateway dynamically retrieves the list of available services from the Nacos registry and automatically generates routing rules, eliminating the cumbersome task of manually maintaining routing tables.
The gateway layer implements the following core functions: (1) Unified JWT-based authentication and authorization — after user login, the authentication service issues a JWT token containing user roles and permission information, which the gateway validates before forwarding requests, substantially reducing redundant security logic across individual microservices; (2) Fine-grained rate limiting based on the Redis token bucket algorithm — differentiated traffic policies are configured according to user tiers (regular users, VIP users, and system administrators), ensuring quality of service for core users while preventing malicious traffic from overwhelming the system; (3) Comprehensive request logging and aggregation — the gateway asynchronously writes metadata including URL, HTTP method, response status code, and latency for each request to Elasticsearch, providing a complete data foundation for distributed tracing, performance analysis, and security auditing.
For service governance, Nacos (Alibaba's open-source platform for dynamic service discovery, configuration, and service management) serves as both the service registry and configuration center. Nacos simultaneously supports both CP (consistency-prioritized) and AP (availability-prioritized) consistency protocols, allowing flexible switching based on business scenarios. AP mode is selected for service registration to ensure high availability of service discovery, while CP mode is applied to configuration management to guarantee consistency of configuration distribution. All microservice instances register their IP address, port, and health status information with Nacos upon startup and periodically (every 5 seconds by default) send heartbeat signals to maintain their registration. Service consumers retrieve the list of available service instances from Nacos by service name, with client-side load balancing (Spring Cloud LoadBalancer) ensuring even distribution of requests.
4.2 Event-Driven Architecture and Asynchronous Communication
In enterprise application systems, not all inter-service interactions require a synchronous request-response pattern. For scenarios such as vehicle trajectory data reporting, dispatch status change notifications, and analytics report generation, an asynchronous event-driven architecture provides superior system decoupling and throughput capacity. This system adopts Apache RocketMQ as the message middleware, implementing an event-driven communication mechanism based on the Topic publish/subscribe model.
Taking vehicle trajectory data acquisition as an example: when vehicle GPS terminals report location data to the Track Service at a frequency of once per second, the Track Service, after completing data validation and persistence, asynchronously publishes trajectory events to RocketMQ's "vehicle-track" topic. The Analytics Service subscribes to this topic and consumes trajectory events in real time to perform heat map computation, abnormal trajectory detection, and mileage statistics. The Dispatch Service likewise subscribes to trajectory events to determine whether vehicles have deviated from planned routes and to trigger timely dispatch adjustments. This asynchronous decoupled design allows trajectory data producers and consumers to evolve independently — the Track Service need not concern itself with how downstream consumers process the data, and adding new consumers does not affect the stability of existing services.
Regarding distributed transaction processing, the core challenge faced by this system is ensuring data consistency across cross-service business operations. Taking dispatch task creation as an example, this operation involves two independent database write operations: task generation in the Dispatch Service and status locking in the Vehicle Management Service. The system employs Seata (Simple Extensible Autonomous Transaction Architecture) in AT (Automatic Transaction) mode to achieve eventual consistency in distributed transactions. Seata coordinates the branch transactions of participating services through a global Transaction Coordinator (TC), utilizing database UNDO logs for automatic rollback and employing a global lock mechanism to prevent concurrent conflicts. Seata AT mode imposes minimal intrusion on business code — developers need only add the @GlobalTransactional annotation on the global transaction initiator, and the framework automatically manages the entire transaction lifecycle.
4.3 Resilience Design and Fault Tolerance Mechanisms
In complex distributed environments, network latency, service overload, and hardware failures are unavoidable realities. While microservices architecture offers advantages in independent deployment and flexible scaling, it also introduces a greater number of potential failure points. To prevent localized failures from cascading through service invocation chains into system-wide collapse — the so-called "avalanche effect" — the system incorporates multiple layers of resilience and fault tolerance mechanisms.
Layer 1: Circuit Breaking and Degradation. The system integrates Sentinel (Alibaba's open-source traffic governance component) to implement circuit breaking, degradation, and adaptive system protection. Sentinel, taking traffic as its entry point, provides multi-dimensional traffic control and circuit breaking capabilities. When the error rate of a downstream service exceeds a preset threshold (e.g., 50%) or response time exceeds the maximum tolerance (e.g., 1 second), the circuit breaker automatically transitions to the Open state. Subsequent invocation requests are rapidly rejected and a predefined fallback logic is executed, preventing invalid requests from continuously consuming system resources. In the Half-Open state, the circuit breaker permits a small number of probe requests; if probes succeed, the circuit breaker closes and normal invocation resumes; if they fail, the Open state is maintained. For example, when the trajectory query interface of the Analytics Service experiences increased latency, the front-end page automatically switches to displaying cached trajectory summary data from Redis for the preceding 24 hours, rather than presenting an error page directly to the user, thereby effectively enhancing user experience resilience.
Layer 2: Bulkhead Isolation. Drawing on the concept of watertight bulkheads in ship design, the system employs thread pool isolation to assign invocations to different downstream services to independent thread pools. For instance, the thread pool used by the Dispatch Service for invoking the Vehicle Management Service is completely independent from that used for invoking the Track Service. Even if the Vehicle Management Service suddenly experiences increased latency, causing its thread pool to be fully occupied, normal invocations to the Track Service remain unaffected. This "fault isolation" mechanism effectively prevents a single slow service from dragging down the entire system.
Layer 3: Infrastructure Redundancy. For critical business services such as the Dispatch Service, the system deploys a minimum of three replica instances, with Kubernetes Pod Anti-Affinity policies ensuring that replicas are distributed across different physical nodes. When a hardware failure occurs on a node, the Pods on that node are automatically rescheduled by Kubernetes to healthy nodes for restart. Combined with Kubernetes Readiness Probe and Liveness Probe health check mechanisms, automatic removal and replacement of failed instances is achieved.
5 System Implementation and Effectiveness Evaluation
5.1 Personal Responsibilities
In this project, the author served as the system architect, participating throughout all critical phases including requirements analysis, architecture design, technology selection, core coding, and production deployment. The primary responsibilities undertaken were as follows:
(1) Led the overall system architecture design. During the project initiation phase, the author conducted in-depth analysis of the enterprise's business status and future development plans, authoring technical documents including the "Logistics Vehicle Dispatch Management System Architecture Design Specification" and "Microservices Development Standards," totaling approximately 35,000 Chinese characters. The design specification provided detailed descriptions of the system's logical architecture view, physical deployment view, data architecture view, and development architecture view, employing UML modeling to produce component diagrams, deployment diagrams, and sequence diagrams, all of which passed formal review by the enterprise Technical Committee.
(2) Responsible for technology selection evaluation and decision-making. For the microservices technology stack selection, the author conducted comprehensive comparative analysis of three mainstream microservices solutions: Spring Cloud Alibaba, Service Mesh (represented by Istio), and Apache Dubbo. Evaluation dimensions included technology maturity, community activity, team learning curve, performance benchmark results, and compatibility with the existing technology stack. Following a two-week technical pre-research and Proof of Concept (POC) development period, the final technology stack was determined: Spring Cloud Alibaba as the core framework, Nacos as the registry, Sentinel for traffic governance, and Seata for distributed transaction resolution. This solution, while ensuring functional completeness, fully leveraged the team's existing Spring Boot expertise, reducing both learning costs and project risk.
(3) Completed core development of the gateway module and service governance module. The author independently implemented the API Gateway module, including JWT-based authentication filter chains, Redis token-bucket-algorithm-based rate limiting filters, a global exception handling mechanism, and a canary release routing strategy (routing requests from specific users to canary-version service instances based on version markers in request headers). Additionally, Nacos namespace and service grouping standards were established, achieving configuration isolation across development, testing, and production environments.
(4) Formulated the database decomposition strategy and data migration plan. Over 200 tables in the original monolithic Oracle database were smoothly decomposed, according to service boundaries, into five independent MySQL schemas and one MongoDB collection. A phased data migration plan was developed: Phase 1 migrated independent foundational data tables (e.g., vehicle information, user information); Phase 2 migrated core business data tables (e.g., dispatch records); Phase 3 migrated historical archive data. Data validation scripts were developed to ensure data consistency and integrity before and after migration.
(5) Organized code reviews and technical knowledge sharing. A code review mechanism was established within the team, requiring that all code merged into the main branch be reviewed by at least one other developer. Concurrently, weekly technical sharing sessions were organized to educate team members on microservices architecture design principles, common anti-patterns, and debugging techniques, with a cumulative total of 12 technical sessions delivered, effectively elevating the team's overall architectural competency.
5.2 Effectiveness Analysis
Since its production launch in June 2025, the system has operated stably for over 10 months, with all performance indicators meeting or exceeding design objectives. Comparative evaluation against the legacy monolithic system demonstrates significant improvements across the following dimensions:
Performance Improvement. Under equivalent hardware resource configurations, the system's average end-to-end response time decreased from 320ms to 208ms, representing a 35% reduction; P99 latency decreased from 850ms to 410ms, a 52% reduction; system throughput increased from 800 requests per second to 2,500 requests per second, a 212% improvement. These significant performance gains are primarily attributable to the independent scalability of microservices — the computation-intensive trajectory analysis service can be independently scaled without affecting the resource allocation of other services.
Elastic Scaling. During the 2025 "Singles' Day" logistics peak period, the system withstood the extreme test of daily dispatch volumes exceeding 300,000. Through pre-configured Kubernetes HPA policies, the Dispatch Service automatically scaled its Pod replicas from 5 to 20 within 2 minutes upon detecting CPU utilization exceeding the 70% threshold, smoothly handling the traffic surge. After the peak subsided, HPA gradually reduced replicas to baseline levels within 15 minutes, effectively controlling resource costs.
High Availability. Since launch, the system has experienced three single-node hardware failures and one network partition event, with core business operations remaining uninterrupted throughout. Fault recovery time was reduced from the minute-level (requiring manual intervention for restart) characteristic of the original monolithic architecture to second-level (automatic Pod reconstruction by Kubernetes). The monthly availability of the core Dispatch Service reached 99.95%, exceeding the 99.9% design target.
Delivery Efficiency. The microservices architecture enables different services to be independently iterated and deployed by different development teams. Code release frequency increased from twice per month (full releases under the monolithic architecture) to an average of four times per week (incremental releases per microservice). The average feature delivery cycle (from requirement confirmation to production deployment) was reduced from three weeks to one week.
This research work has certain limitations: (1) Service Mesh technologies such as Istio were not introduced during the initial phase of the project, resulting in certain traffic management, secure communication (mTLS), and observability capabilities still being implemented at the application layer through code, which increased development and maintenance complexity. Future plans include gradually migrating cross-cutting concerns to the Sidecar proxy layer. (2) The system's chaos engineering practices remain at an early stage, with only limited fault injection experiments conducted in test environments. The automated recovery capability under extreme failure scenarios — such as simultaneous multi-node failures or cross-region network outages — requires further validation and optimization.
6 Conclusion
This paper has presented an in-depth exploration of microservices architecture application methodology in enterprise-grade application systems, taking a logistics enterprise vehicle dispatch management system as a practical case study. Addressing the complete lifecycle of system architecture design, the paper comprehensively elaborates on the methodologies and engineering practices for key phases including business requirements analysis, overall architecture design, service decomposition strategy, API gateway and service governance, event-driven communication mechanisms, and resilience and fault tolerance design. The research demonstrates that the judicious application of microservices architecture patterns can, while ensuring functional completeness, significantly enhance the scalability, maintainability, and deployment flexibility of enterprise application systems. The layered architecture design methodology, DDD-based service decomposition strategy, and multi-layered resilience and fault tolerance mechanisms proposed in this paper have been thoroughly validated in a real-world project, providing an actionable reference solution for the microservices transformation of traditional enterprise applications.
Looking ahead, on the technology evolution front, the team will continue to monitor the development of next-generation infrastructure technologies such as Service Mesh and eBPF, exploring viable pathways for migrating cross-cutting concerns — including traffic management, secure communication, and observability — from the application layer to the infrastructure layer. On the intelligent operations front, plans are underway to introduce machine-learning-based anomaly detection algorithms that learn from historical monitoring data to enable proactive fault warning and automated root cause localization, further elevating the system's intelligent operations capabilities. On the architectural evolution front, close attention will be paid to emerging technology directions appearing in the System Architect qualification examination — such as Serverless architecture, edge computing, and AI-architecture integration — to maintain the currency and foresight of architectural design.
References
[1] Newman S. Building Microservices: Designing Fine-Grained Systems[M]. 2nd ed. Sebastopol: O'Reilly Media, 2021: 45-78.
[2] Richardson C. Microservices Patterns: With Examples in Java[M]. Shelter Island: Manning Publications, 2018: 12-36.
[3] Gintoro A, Saeki M, Washizaki H, et al. Microservices Design Pattern in Action: Improving Modifiability in Microservices-Based Software Development[J]. IEEE Access, 2025, 13: 112345-112362.
[4] Rocha F, Santos M, Santos S, et al. Software Architecture Patterns in Microservices: A Systematic Mapping of the Literature[J/OL]. Research Square, 2024. DOI: 10.21203/rs.3.rs-5203810/v1.
[5] Gurram V B. Integrating Microservices and Event-Driven Design for Cloud-Native Transformation[J]. Journal of International Crisis and Risk Communication Research, 2026, 9(2): 156-178.
[6] Seiger R, Malburg L. Revision of a Smart Factory Software Architecture from Monolith to Microservices[C]// Proceedings of the EDOC 2024 Workshops. Cham: Springer, 2025: 158-172.
[7] Ponugoti M. Cloud-Native Platform Engineering: Scalable Design Patterns for Global Enterprise Resilience[J]. Journal of Computing and Security Technology, 2025, 7(8): 67-85.
[8] Gamma E, Helm R, Johnson R, et al. Design Patterns: Elements of Reusable Object-Oriented Software[M]. Boston: Addison-Wesley, 1995: 137-225.