Giới thiệu dự án
Trong kỷ nguyên chuyển đổi số và bùng nổ thương mại điện tử toàn cầu, các hệ thống công nghệ thông tin phải xử lý hàng triệu yêu cầu mỗi giây với yêu cầu nghiêm ngặt về tính sẵn sàng cao (High Availability $\ge 99.99%$) và độ trễ thấp ($< 200\text{ms}$). Kiến trúc nguyên khối (Monolithic Architecture) truyền thống bộc lộ nhiều điểm nghẽn: khó mở rộng theo chiều ngang (Horizontal Scalability), rủi ro điểm lỗi đơn lẻ (Single Point of Failure - SPOF), độ phức tạp mã nguồn tăng theo cấp số nhân dẫn đến thời gian trung bình để sửa chữa (Mean Time To Repair - MTTR) kéo dài.
Đề tài "Xây dựng hệ thống với Spring Boot" (Đồ án 1, Khoa Công nghệ Phần mềm, Trường Đại học Công nghệ Thông tin – ĐHQG-HCM, thực hiện bởi sinh viên Nguyễn Văn Quốc Tuấn và Trần Phước Long dưới sự hướng dẫn của ThS. Nguyễn Công Hoan) tập trung nghiên cứu chuyên sâu các nguyên lý thiết kế hệ thống phân tán (Distributed Systems) và ứng dụng thực tiễn hệ sinh thái Spring Boot / Spring Cloud để xây dựng kiến trúc Microservices hiệu năng cao, chịu lỗi và dễ bảo trì.
+-----------------------------------------------------------------------------------+
| HỆ THỐNG PHÂN TÁN TỔNG THỂ |
+-----------------------------------------------------------------------------------+
| [ Client Web/Mobile ] |
| │ |
| ▼ (HTTPS / REST) |
| [ Spring Cloud Gateway (Layer 7 Load Balancer, Rate Limiting, JWT Auth) ] |
| │ |
| ├──────────────────────────────┬──────────────────────────────┐ |
| ▼ ▼ ▼ |
| [ Order Service ] [ Payment Service ] [ Inventory Service ]|
| (Spring Boot 3.x) (Spring Boot 3.x) (Spring Boot 3.x) |
| - Resilience4j CB - Resilience4j CB - Resilience4j CB |
| - Saga Orchestrator - Local ACID DB - Local ACID DB |
| - PostgreSQL (Outbox) - MySQL - Redis Cache |
| │ │ │ |
| └──────────────────────────────┼──────────────────────────────┘ |
| ▼ |
| [ Netflix Eureka Service Discovery & Spring Cloud Config Server ] |
| [ Distributed Tracing (Zipkin) & Metric Monitoring (Prometheus) ] |
+-----------------------------------------------------------------------------------+
Mục tiêu dự án
- Chuẩn hóa nền tảng lý thuyết thiết kế hệ thống: Phân tích toàn diện các trụ cột phi chức năng: Tính mở rộng (Scalability), Tính khả dụng (Availability), Độ tin cậy (Reliability), Tính bảo trì (Maintainability), Tính nhất quán theo Định lý CAP (Consistency), và Khả năng chịu lỗi (Fault Tolerance).
- Nghiên cứu và giải quyết bài toán giao dịch phân tán (Distributed Transactions): Đánh giá cơ chế Two-Phase Commit (2PC), Three-Phase Commit (3PC) và triển khai mô hình Saga Pattern (Choreography/Orchestration) kết hợp mẫu thiết kế Transactional Outbox.
- Hiện thực hóa kiến trúc Microservices với Spring Boot: Xây dựng các module độc lập tích hợp Netflix Eureka (Service Discovery), Spring Cloud Gateway (API Gateway), Resilience4j (Circuit Breaker), Spring Data JPA, Redis Cache, Spring Security (OAuth2/JWT).
- Đo lường và giám sát toàn diện: Triển khai Distributed Tracing với Zipkin và Metrics Monitoring với Prometheus/Spring Boot Actuator.
Phương pháp tiếp cận và Phạm vi
- Phương pháp: Kết hợp nghiên cứu lý thuyết hệ thống phân tán (Consensus Raft, Byzantine Faults, Caching Topologies) với thực nghiệm xây dựng quy trình Đặt hàng (Order) – Thanh toán (Payment) – Quản lý kho (Inventory).
- Chỉ số đo lường kỳ vọng:
- Tính khả dụng đạt mức "Four Nines" ($99.99%$), tương đương thời gian chết (downtime) dưới $52.6$ phút/năm:
$$A = \frac{\text{MTBF}}{\text{MTBF} + \text{MTTR}}$$
- Rút ngắn thời gian trung bình sửa chữa ($\text{MTTR} \le 15\text{ phút}$).
- Khả năng xử lý thông lượng (Throughput) tăng tối thiểu $300%$ so với kiến trúc monolithic đơn luồng.
- Phạm vi & Giới hạn: Tập trung vào kiến trúc phân tán ở tầng ứng dụng và cơ sở dữ liệu; kiểm thử mô phỏng trên môi trường container hóa Docker và cụm Kubernetes cục bộ.
Phân tích và thiết kế giải pháp
Phân tích hiện trạng
| Tiêu chí |
Monolithic Architecture |
Basic Microservices (No Governance) |
Spring Boot Microservices Ecosystem |
| Khả năng mở rộng (Scalability) |
Kém; chỉ có thể Scale Up (Vertical) đắt đỏ, giới hạn phần cứng |
Trung bình; scale ngang thủ công qua IP/Port cố định |
Xuất sắc; Dynamic Horizontal Scaling qua Eureka + Gateway |
| Quản lý giao dịch |
Đơn giản qua Local ACID DB Transaction |
Rất kém; dễ mất đồng bộ dữ liệu giữa các dịch vụ |
Chặt chẽ; Saga Orchestration + Transactional Outbox |
| Khả năng chịu lỗi (Fault Tolerance) |
Kém; lỗi tại một module làm sập toàn bộ ứng dụng (SPOF) |
Kém; lỗi dây chuyền (Cascading Failure) qua HTTP calls |
Cao; cô lập lỗi bằng Resilience4j Circuit Breaker & Fallbacks |
| Độ phức tạp bảo trì |
Cao khi codebase phình to; MTTR lớn |
Rất cao; khó debug distributed calls |
Trung bình; tối ưu hóa qua Zipkin Distributed Tracing |
Phân loại yêu cầu theo mô hình MoSCoW
- Must have: Service Discovery (Eureka), API Gateway định tuyến động, Database độc lập cho từng service, Xác thực tập trung JWT/OAuth2, Circuit Breaker bảo vệ downstream services.
- Should have: Phân tán giao dịch qua Saga Pattern, Caching đa tầng với Redis (Read-aside, Write-through), Distributed Tracing qua Zipkin.
- Could have: Tích hợp thuật toán đồng thuận Raft để tự động bầu chọn Master trong cụm, Quản lý cấu hình tập trung qua Spring Cloud Config Server.
- Won't have (giai đoạn 1): Triển khai Multi-region Cloud Deployment tự động, Hỗ trợ đồng bộ dữ liệu đồ thị phức tạp (Graph Database).
Thiết kế hệ thống
Technology Stack và Phiên bản chuẩn hóa
- Ngôn ngữ & Runtime: Java OpenJDK 17 LTS.
- Core Framework: Spring Boot 3.1.5, Spring Cloud 2022.0.4 (Leyton release).
- Service Governance: Spring Cloud Netflix Eureka Server, Spring Cloud Gateway (Spring WebFlux / Netty).
- Resilience & Fault Tolerance: Resilience4j 2.1.0 (
resilience4j-spring-boot3).
- Data & Persistence: Spring Data JPA, Hibernate 6.2, PostgreSQL 15, MySQL 8.0.
- Distributed Caching: Redis 7.2 (tích hợp
spring-boot-starter-data-redis & Spring Cache).
- Security: Spring Security 6.1, OAuth2 Client, JJWT (JSON Web Token) 0.11.5.
- Inter-service Communication: OpenFeign 4.0 (
spring-cloud-starter-openfeign).
- Observability: Spring Boot Actuator, Micrometer Tracing, Zipkin 2.24, Prometheus 2.47.
- Containerization & Orchestration: Docker Engine 24.0, Kubernetes (K8s) 1.28, Helm 3.12.
+-----------------------------------------------------------------------------------+
| MÔ HÌNH DỮ LIỆU VÀ GIAO TIẾP INTER-SERVICE |
+-----------------------------------------------------------------------------------+
| |
| [ Client ] ──(HTTP/REST)──> [ API Gateway:8080 ] |
| │ |
| ┌─────────────────┴─────────────────┐ |
| ▼ ▼ |
| [ Order Service:8081 ] [ Payment Service:8082 ] |
| ┌────────────────────────┐ ┌────────────────────────┐ |
| │ - OrderController │ │ - PaymentController │ |
| │ - OrderSagaManager │ │ - PaymentProcessor │ |
| │ - OutboxEventPublisher │ │ - LocalTransaction │ |
| └───────────┬────────────┘ └───────────┬────────────┘ |
| │ │ |
| (Feign + CB) ────────────────────────────────┘ |
| │ |
| ┌──────────┴──────────┐ |
| ▼ ▼ |
| [ PostgreSQL ] [ Redis Cache ] |
| - Table: orders - Key: product_stock:{id} |
| - Table: outbox - Strategy: Read-aside |
+-----------------------------------------------------------------------------------+
Thiết kế An toàn & Chịu tải (Security & Resilience)
- API Gateway Routing & Security: API Gateway đóng vai trò Reverse Proxy (Layer 7 Load Balancer), chặn mọi truy cập trực tiếp vào backend instances, kiểm tra JWT claims trước khi chuyển tiếp yêu cầu kèm header
X-User-Id.
- Circuit Breaker Strategy: Cấu hình Resilience4j tự động mở mạch (OPEN state) khi tỷ lệ lỗi vượt quá $50%$ trong sliding window 100 requests, chuyển hướng sang fallback method ngay lập tức, ngăn ngừa cạn kiệt connection pool.
Phương pháp luận phát triển (Methodology)
Đồ án triển khai theo quy trình Agile/Scrum rút gọn với 4 Sprint (mỗi Sprint 2 tuần):
- Sprint 1: Nghiên cứu lý thuyết hệ thống phân tán, thiết kế kiến trúc tổng thể, cài đặt Service Discovery (Eureka) và API Gateway.
- Sprint 2: Xây dựng Order Service và Inventory Service với Spring Data JPA, thiết lập cơ chế Caching Redis đa tầng.
- Sprint 3: Tích hợp OpenFeign, hiện thực hóa Saga Orchestration cho quy trình Đặt hàng – Thanh toán, cấu hình Resilience4j Circuit Breaker.
- Sprint 4: Đóng gói Docker container, viết manifest Kubernetes/Helm, tích hợp Zipkin Tracing, Prometheus metrics và thực hiện Load Testing.
Implementation và kết quả
Development Process & Key Algorithms
Hệ thống hiện thực hóa các mẫu thiết kế cốt lõi thông qua các thành phần code chuyên biệt:
1. Khai báo Service Discovery với Eureka Server
package vn.edu.uit.discovery;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;
@SpringBootApplication
@EnableEurekaServer
public class ServiceDiscoveryApplication {
public static void main(String[] args) {
SpringApplication.run(ServiceDiscoveryApplication.class, args);
}
}
2. Định tuyến API Gateway kết hợp Bộ lọc JWT và Rate Limiting
spring:
cloud:
gateway:
routes:
- id: order-service
uri: lb://ORDER-SERVICE
predicates:
- Path=/api/v1/orders/**
filters:
- name: CircuitBreaker
args:
name: orderCircuitBreaker
fallbackUri: forward:/fallback/orders
- name: RequestRateLimiter
args:
redis-rate-limiter.replenishRate: 100
redis-rate-limiter.burstCapacity: 200
3. Cấu hình Resilience4j Circuit Breaker & OpenFeign Client
package vn.edu.uit.order.client;
import io.github.resilience4j.circuitbreaker.annotation.CircuitBreaker;
import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import vn.edu.uit.order.dto.PaymentRequest;
import vn.edu.uit.order.dto.PaymentResponse;
@FeignClient(name = "PAYMENT-SERVICE")
public interface PaymentClient {
@PostMapping("/api/v1/payments/process")
@CircuitBreaker(name = "paymentServiceCB", fallbackMethod = "processPaymentFallback")
PaymentResponse processPayment(@RequestBody PaymentRequest request);
default PaymentResponse processPaymentFallback(PaymentRequest request, Throwable t) {
return new PaymentResponse(request.getOrderId(), "PAYMENT_PENDING_RETRY", "Fallback triggered: " + t.getMessage());
}
}
4. Hiện thực hóa Saga Pattern với Transactional Outbox
Để đảm bảo tính nhất quán dữ liệu mà không bị chặn (non-blocking) như 2PC/3PC, hệ thống áp dụng Transactional Outbox:
@Service
@Transactional
public class OrderServiceImpl implements OrderService {
@Autowired private OrderRepository orderRepository;
@Autowired private OutboxRepository outboxRepository;
@Override
public Order createOrder(OrderDTO dto) {
// 1. Lưu đơn hàng cục bộ (Local ACID Transaction)
Order order = new Order(dto.getUserId(), dto.getTotalAmount(), OrderStatus.CREATED);
orderRepository.save(order);
// 2. Ghi nhận sự kiện vào bảng Outbox trong cùng 1 transaction
OutboxEvent event = new OutboxEvent("ORDER_CREATED", order.getId(), JsonUtils.toJson(order));
outboxRepository.save(event);
return order;
}
}
Testing và Validation
Kịch bản kiểm thử (Test Scenarios & Coverage)
- Unit & Integration Testing: Thực hiện $120+$ test cases bằng JUnit 5, Mockito và Testcontainers (PostgreSQL/Redis containers). Code coverage đạt $86.4%$ trên toàn bộ domain services.
- Stress & Load Testing: Sử dụng Apache JMeter mô phỏng tải tăng dần từ $100$ đến $3,000$ concurrent users trong thời gian 10 phút.
+-----------------------------------------------------------------------------------+
| KẾT QUẢ BENCHMARK TRƯỚC VÀ SAU TỐI ƯU |
+-----------------------------------------------------------------------------------+
| |
| Throughput (RPS): |
| Monolith [====] 450 RPS |
| Spring Cloud [========================================] 2,850 RPS (+533%) |
| |
| P99 Latency: |
| Monolith [==============================] 680 ms |
| Spring Cloud [====] 72 ms (-89.4%) |
| |
| Error Rate (Overload): |
| Monolith [=============] 18.2% |
| Spring Cloud [=] 0.15% (-99.2%) |
+-----------------------------------------------------------------------------------+
Bảng thông số hiệu năng thực tế (Benchmarks Data)
| Metric |
Monolithic Database-Direct |
Microservices Không Cache |
Spring Boot + Redis + Eureka + Gateway |
| Max Throughput |
450 req/sec |
820 req/sec |
2,850 req/sec |
| P95 Latency |
420 ms |
210 ms |
48 ms |
| P99 Latency |
680 ms |
390 ms |
72 ms |
| Error Rate under Peak |
18.2% (Connection Timeout) |
6.5% (Cascading Failures) |
0.15% (Graceful Fallback) |
| Cache Hit Ratio |
N/A |
N/A |
92.4% |
| MTTR (Mean Time To Repair) |
45 phút (Restart toàn bộ) |
20 phút |
4.5 phút (Rolling restart instance) |
Đổi mới và đóng góp
- Giải quyết triệt để bài toán Blocking của 2PC/3PC bằng Saga Orchestration: Thay vì sử dụng cơ chế khóa phân tán đồng bộ (Synchronous Distributed Locks) gây tắc nghẽn toàn hệ thống khi có node sập, đồ án hiện thực hóa Saga kết hợp Transactional Outbox, đảm bảo tính nhất quán cuối cùng (Eventual Consistency) với độ trễ thấp hơn $75%$.
- Chiến lược Caching đa tầng tối ưu Disk I/O: Kết hợp mô hình Read-aside và Write-through Cache giúp giảm tải $88%$ số lượng truy vấn trực tiếp vào cơ sở dữ liệu quan hệ (RDBMS), nâng throughput đọc dữ liệu catalog lên gấp 6 lần.
- Mô hình cô lập lỗi tự động (Fault Isolation): Ứng dụng mô hình Client-side Resilience (Resilience4j) cho phép hệ thống tự cô lập các dịch vụ phản hồi chậm ($> 2000\text{ms}$), kích hoạt luồng thanh toán dự phòng mà không làm gián đoạn trải nghiệm người dùng cuối.
Ứng dụng thực tế và triển khai
Use Cases thực tế
- Hệ thống Thương mại Điện tử (E-Commerce): Xử lý các đợt Flash Sale lưu lượng truy cập đột biến; tách biệt module xem sản phẩm (đọc nhiều - Redis Cache) và module thanh toán (ghi quan trọng - Saga Transaction).
- Cổng thanh toán & Ví điện tử: Đảm bảo từng giao dịch trừ tiền và hoàn tiền (Compensating Transaction) được thực thi nguyên tử, không bao giờ xảy ra tình trạng "treo tiền" của khách hàng.
Kế hoạch Triển khai (Deployment Roadmap)
+-----------------------------------------------------------------------------------+
| LỘ TRÌNH TRIỂN KHAI VÀ MỞ RỘNG (ROADMAP) |
+-----------------------------------------------------------------------------------+
| [ Pha 1: Containerization ] |
| - Đóng gói Spring Boot JAR thành multi-stage Docker Images (Kích thước < 180MB) |
| - Thiết lập Docker Compose cho môi trường Development & Staging |
| │ |
| ▼ |
| [ Pha 2: Kubernetes Orchestration ] |
| - Viết Helm Charts định nghĩa Pods, Deployments, Services, ConfigMaps, Ingress |
| - Cấu hình Horizontal Pod Autoscaler (HPA) tự động scale khi CPU > 70% |
| │ |
| ▼ |
| [ Pha 3: Production Observability ] |
| - Triển khai Prometheus Operator + Grafana Dashboards giám sát JVM & Metrics |
| - Thiết lập Alertmanager gửi cảnh báo Real-time qua Slack/Telegram |
+-----------------------------------------------------------------------------------+
Phân tích Chi phí và Hiệu quả Đầu tư (ROI)
- Tối ưu chi phí hạ tầng: Khả năng mở rộng theo chiều ngang (Horizontal Scaling) trên nền tảng container cho phép doanh nghiệp chỉ cấp phát tài nguyên tương ứng với tải thực tế, giảm $35-45%$ chi phí thuê máy chủ đám mây (AWS/GCP) so với việc duy trì máy chủ cấu hình khủng cho khối Monolith.
- Rút ngắn Time-to-Market: Các nhóm kỹ sư có thể phát triển, kiểm thử và deploy các microservices độc lập (CI/CD tự động) mà không cần build lại toàn bộ hệ thống, nâng cao năng suất kỹ thuật lên $60%$.
Hạn chế và hướng phát triển
Hạn chế kỹ thuật hiện tại
- Độ trễ truyền thông liên dịch vụ (Inter-service Network Hops): Việc gọi liên tiếp nhiều REST API qua giao thức HTTP/1.1 tạo ra chi phí overhead đáng kể về CPU và độ trễ mạng.
- Độ phức tạp trong vận hành: Việc quản lý nhiều cơ sở dữ liệu phân tán đòi hỏi kỹ năng DevOps và giám sát đồng bộ cao hơn so với kiến trúc nguyên khối.
Hướng phát triển đề xuất
- Nâng cấp giao tiếp Inter-service sang gRPC / Protocol Buffers: Giảm kích thước payload đến $60%$ và tận dụng multiplexing của HTTP/2 để giảm tối đa độ trễ.
- Triển khai Service Mesh (Istio / Linkerd): Tách biệt hoàn toàn tầng mạng, mã hóa mTLS tự động và traffic shifting ra khỏi mã nguồn ứng dụng Spring Boot.
- Áp dụng Event Sourcing đầy đủ với Apache Kafka: Lưu trữ toàn bộ lịch sử biến đổi trạng thái thành chuỗi sự kiện bất biến (Immutable Event Log), hỗ trợ phân tích dữ liệu lớn và Audit Trail chuẩn ngân hàng.
Đối tượng hưởng lợi
+-----------------------------------------------------------------------------------+
| MA TRẬN ĐỐI TƯỢNG HƯỞNG LỢI |
+-----------------------------------------------------------------------------------+
| [ Sinh viên CNTT / KTPM ] |
| - Nắm vững kiến trúc Microservices chuẩn công nghiệp. |
| - Tài liệu tham khảo đồ án chuyên sâu kèm source code hoàn chỉnh. |
| |
| [ Kỹ sư phần mềm (Backend Developers) ] |
| - Bộ khung (Boilerplate) Spring Boot 3.x, Eureka, Gateway, Resilience4j. |
| - Best practices xử lý giao dịch phân tán Saga & Transactional Outbox. |
| |
| [ Doanh nghiệp & Startup ] |
| - Kiến trúc tham chiếu sẵn sàng mở rộng, giảm 40% chi phí hạ tầng ban đầu. |
| - Rút ngắn chu kỳ phát hành sản phẩm (Release Cycle) từ vài tuần xuống vài ngày. |
| |
| [ Nhà nghiên cứu Hệ thống phân tán ] |
| - Dữ liệu thực nghiệm so sánh định lượng giữa 2PC, 3PC và Saga Pattern. |
+-----------------------------------------------------------------------------------+
Câu hỏi thường gặp
1. Cần chuẩn bị cấu hình phần cứng tối thiểu nào để triển khai hệ thống?
Để chạy toàn bộ hệ thống trên môi trường cục bộ (bao gồm Eureka, Gateway, 3 Microservices, PostgreSQL, MySQL, Redis, Zipkin, Prometheus):
- CPU: Tối thiểu 4 Cores (khuyến nghị 8 Cores).
- RAM: Tối thiểu 16 GB (do các tiến trình JVM của Spring Boot cần khoảng 512MB - 1GB RAM cho mỗi service).
- Hệ điều hành: Linux (Ubuntu 20.04/22.04 LTS), macOS, hoặc Windows với WSL2.
2. Khi xảy ra sự cố phân mảnh mạng (Network Partition), hệ thống ưu tiên Consistency hay Availability?
Theo định lý CAP, hệ thống Spring Boot Microservices được thiết kế theo hướng AP (Availability & Partition Tolerance) kết hợp với Eventual Consistency. Khi có phân mảnh mạng, các service vẫn duy trì khả năng phục vụ đọc/ghi cục bộ; các giao dịch liên dịch vụ sẽ được đồng bộ hóa cuối cùng thông qua Saga Orchestration và cơ chế bù trừ giao dịch (Compensating Transaction).
3. Làm thế nào để tích hợp hệ thống với các dịch vụ thanh toán của bên thứ ba (VNPay, Momo, Stripe)?
Thực hiện qua Payment Service bằng cách xây dựng một Adapter Pattern riêng biệt. Các cuộc gọi sang cổng thanh toán ngoài được bọc trong Resilience4j Circuit Breaker và cơ chế Retry với Exponential Backoff để chống lỗi mạng chập chờn.
4. Chi phí vận hành và bảo trì hệ thống Microservices này có cao không?
Chi phí vận hành ban đầu sẽ cao hơn Monolith do cần thiết lập hạ tầng giám sát và CI/CD. Tuy nhiên, về lâu dài, chi phí vận hành sẽ giảm dần khi hệ thống mở rộng quy mô nhờ khả năng tối ưu hóa tài nguyên linh hoạt của Kubernetes và thời gian MTTR thấp.
5. Tại sao không chọn 2PC (Two-Phase Commit) thay cho Saga Pattern?
Giao thức 2PC là cơ chế chặn (blocking protocol). Khi coordinator hoặc một participant gặp sự cố, tất cả các tài nguyên liên quan sẽ bị khóa chặt, dẫn đến giảm nghiêm trọng tính sẵn sàng (Availability) và có nguy cơ gây tắc nghẽn toàn bộ hệ thống trong môi trường microservices có độ trễ mạng biến thiên.
Kết luận
Đồ án "Xây dựng hệ thống với Spring Boot" của sinh viên Nguyễn Văn Quốc Tuấn và Trần Phước Long (Trường Đại học Công nghệ Thông tin – ĐHQG-HCM) đã hoàn thành xuất sắc các mục tiêu nghiên cứu và ứng dụng:
- Chuẩn hóa hệ thống lý thuyết về thiết kế hệ thống phân tán, phân tích đa chiều các nguyên lý Scalability, Availability ($99.99%$), Reliability (MTBF/MTTR), Consistency và Fault Tolerance.
- Hiện thực hóa thành công kiến trúc Microservices hiện đại dựa trên hệ sinh thái Spring Boot 3.x và Spring Cloud, làm chủ các công nghệ cốt lõi: Netflix Eureka, Spring Cloud Gateway, Resilience4j Circuit Breaker, Spring Data JPA, Redis Caching, và JWT Authentication.
- Đưa ra giải pháp thực tiễn giải quyết bài toán giao dịch phân tán thông qua Saga Pattern và Transactional Outbox, đạt thông lượng xử lý vượt trội $2,850\text{ RPS}$ với độ trễ P99 chỉ $72\text{ms}$.
Đây là tài liệu tham khảo kỹ thuật giá trị và nền tảng kiến trúc vững chắc cho các kỹ sư phần mềm, sinh viên và doanh nghiệp đang định hướng xây dựng các hệ thống quy mô lớn, sẵn sàng cho môi trường sản xuất thực tế.