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ử, các hệ thống phần mềm doanh nghiệp phải đối mặt với áp lực xử lý hàng chục nghìn yêu cầu đồng thời (RPS - Requests Per Second), đòi hỏi độ sẵn sàng đạt chuẩn viễn thông (High Availability - tối thiểu 99.99% tương đương thời gian ngừng hoạt động tối đa 52.6 phút/năm).

$$A = \frac{\text{MTBF}}{\text{MTBF} + \text{MTTR}}$$

Các hệ thống nguyên khối (Monolithic Architecture) truyền thống dần bộc lộ nhiều điểm nghẽn nghiêm trọng: giới hạn mở rộng tài nguyên theo chiều dọc (Vertical Scaling) đắt đỏ, sự phụ thuộc chặt chẽ giữa các module dẫn đến nguy cơ lỗi đơn điểm (Single Point of Failure - SPOF), và rào cản triển khai chậm trễ khi toàn bộ mã nguồn phải đóng gói lại sau mỗi lần cập nhật.

Đồ án chuyên sâu "Tìm hiểu Spring Boot – Next.js và Xây dựng Ứng dụng Phân tán" tập trung giải quyết bài toán thiết kế kiến trúc hệ thống hiện đại, chuyển dịch từ mô hình nguyên khối sang kiến trúc vi dịch vụ (Microservices) kết hợp giao diện rendered phía máy chủ (Server-Side Rendering - SSR).

+-------------------------------------------------------------------------------+
|                       HỆ THỐNG KIẾN TRÚC PHÂN TÁN                            |
|                                                                               |
|  [ Next.js 14 Frontend ] <--- HTTPS ---> [ Envoy API Gateway (L7 Routing) ]   |
|                                                      |                        |
|                     +--------------------------------+                        |
|                     |                                |                        |
|                     v                                v                        |
|      [ Service Registry: Eureka ]       [ Distributed Cache: Redis Cluster ]  |
|                     |                                |                        |
|        +------------+------------+                   |                        |
|        |                         |                   |                        |
|        v                         v                   v                        |
|  [ Auth Service ]       [ Order Service ] <---> [ Inventory Service ]         |
|  (OAuth2 / JWT)         (Spring Boot 3)         (Spring Boot 3)               |
|        |                         |                   |                        |
|        |                         +---------+---------+                        |
|        |                                   |                                  |
|        v                                   v                                  |
|  [ PostgreSQL DB ]             [ Message Bus: RabbitMQ ]                      |
|                                (Transactional Outbox)                         |
|                                            |                                  |
|                                            v                                  |
|                              [ Distributed Tx: Seata / Saga ]                 |
+-------------------------------------------------------------------------------+

Mục tiêu dự án

  1. Nghiên cứu và chuẩn hóa lý thuyết hệ thống phân tán: Làm rõ các nguyên lý cốt lõi gồm định lý CAP (Consistency, Availability, Partition Tolerance), cơ chế đồng thuận Raft (Consensus Mechanism), quản trị bộ nhớ đệm (Caching Patterns) và kiểm soát giao dịch phân tán (Distributed Transactions).
  2. Xây dựng kiến trúc Backend Microservices hiệu năng cao: Ứng dụng hệ sinh thái Spring Boot 3.2.x, tích hợp Spring Cloud Eureka, Spring Security OAuth2/JWT, RabbitMQ và Apache Seata để quản trị giao dịch Saga.
  3. Phát triển Frontend tối ưu SEO và UX: Xây dựng ứng dụng Next.js 14.2.x (App Router, React 18, TypeScript) tích hợp kỹ thuật Server-Side Rendering (SSR) và Incremental Static Regeneration (ISR).
  4. Đánh giá và tối ưu hóa hệ thống: Thiết lập bài kiểm thử tải định lượng (Load Testing), đo lường độ trễ P95/P99, thông lượng dữ liệu, tỷ lệ Cache Hit Ratio và khả năng chịu lỗi (Fault Tolerance).

Phạm vi và giới hạn

  • Phạm vi: Thiết kế tầng Gateway (Envoy/Spring Cloud Gateway), phân rã dịch vụ xác thực (Auth Service), dịch vụ đơn hàng (Order Service), dịch vụ kho vận (Inventory Service), đồng bộ dữ liệu phi tập trung và cấu hình CI/CD trên Docker/Kubernetes.
  • Giới hạn: Hệ thống tập trung xử lý lỗi Crash-Stop và Crash-Recovery theo mô hình đồng thuận Raft với giả định mạng nội bộ tin cậy; không trực tiếp giải quyết bài toán lỗi Byzantine (Byzantine Fault) vượt quá ngưỡng $\frac{1}{3}$ số node trong môi trường mạng thù địch (Adversarial Network).

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Tiêu chí Kiến trúc Monolith Kiến trúc Microservices Kiến trúc Serverless
Khả năng mở rộng (Scalability) Kém, chỉ hỗ trợ Vertical Scale tốn kém Rất cao, hỗ trợ Horizontal Scale từng service độc lập Tự động mở rộng (Auto-scaling) theo sự kiện
Độ cô lập lỗi (Fault Isolation) Thấp, lỗi 1 module có thể sập toàn bộ hệ thống Cao, lỗi được cô lập qua Circuit Breaker (Resilience4j) Cao, mỗi function thực thi trong container riêng
Độ phức tạp vận hành Thấp, dễ kiểm thử và triển khai ban đầu Cao, đòi hỏi Service Discovery, Tracing, Monitoring Trung bình - Cao, phụ thuộc hạ tầng Cloud Provider
Tính nhất quán dữ liệu Strong Consistency (ACID qua RDBMS) Eventual Consistency (BASE qua Saga/Outbox) Eventual Consistency
Cold Start Latency Không có (Always warm) Thấp (Duy trì container instance) Cao khi có request đột biến

Phân loại yêu cầu hệ thống theo mô hình MoSCoW

  • Must-Have (Bắt buộc): Xác thực tập trung JWT/OAuth2 qua API Gateway; quản lý phiên giao dịch phân tán đảm bảo Atomicity qua Saga Choreography; Service Discovery tự động đăng ký/hủy dịch vụ.
  • Should-Have (Nên có): Tích hợp Distributed Cache (Redis) với mô hình Cache-Aside và thuật toán đào thải Least Recently Used (LRU); hệ thống Message Queue (RabbitMQ) xử lý bất đồng bộ.
  • Could-Have (Có thể có): Giám sát thời gian thực qua Prometheus + Grafana; Sidecar Proxy Cache tích hợp Envoy.
  • Won't-Have (Chưa triển khai kỳ này): Đồng thuận phân tán trên mạng đa vùng địa lý chịu lỗi Byzantine đầy đủ (BFT).

Thiết kế hệ thống

Technology Stack và phiên bản cụ thể

Tầng kiến trúc Công nghệ / Thư viện Phiên bản Vai trò kỹ thuật
Frontend Framework Next.js / TypeScript 14.2.4 / 5.4.x SSR/ISR rendering, SEO Optimization, State Management
Backend Core Java OpenJDK / Spring Boot 21 LTS / 3.2.5 Business logic processing, Dependency Injection
Service Discovery & Gateway Spring Cloud Netflix Eureka / Envoy 4.1.x / 1.30.1 Service Registry, L7 Reverse Proxy, Rate Limiting
Distributed Transaction Apache Seata / Spring Cloud Sleuth 2.0.0 / 3.1.x Global Transaction Coordinator (Saga/2PC/TCC)
Distributed Cache & Search Redis / Elasticsearch 7.2.4 / 8.13.2 In-memory key-value cache, Distributed Full-text search
Message Broker RabbitMQ 3.13.x Asynchronous event bus, Transactional Outbox consumer
Database Persistence PostgreSQL / MyBatis-Plus 16.2 / 3.5.6 Relational data persistence, Dynamic SQL mapper
DevOps & Monitoring Docker Engine / Kubernetes / Prometheus 26.0.x / 1.29 / 2.51 Containerization, Orchestration, Metrics scraping

Thiết kế mô hình dữ liệu Transactional Outbox

Nhằm đảm bảo tính nguyên tử giữa thao tác ghi cơ sở dữ liệu và phát sinh sự kiện vào Message Broker, hệ thống áp dụng mẫu thiết kế Transactional Outbox Pattern:

-- Bảng lưu trữ đơn hàng chính
CREATE TABLE tbl_orders (
    order_id VARCHAR(64) PRIMARY KEY,
    user_id VARCHAR(64) NOT NULL,
    total_amount DECIMAL(12, 2) NOT NULL,
    order_status VARCHAR(32) NOT NULL,
    created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);

-- Bảng Transactional Outbox ghi nhận sự kiện nguyên tử
CREATE TABLE tbl_outbox_events (
    event_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    aggregate_type VARCHAR(64) NOT NULL,
    aggregate_id VARCHAR(64) NOT NULL,
    event_type VARCHAR(64) NOT NULL,
    payload JSONB NOT NULL,
    status VARCHAR(20) DEFAULT 'PENDING', -- PENDING, PUBLISHED, FAILED
    retry_count INT DEFAULT 0,
    created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);
CREATE INDEX idx_outbox_status ON tbl_outbox_events(status, created_at);

Methodology

Quy trình phát triển tuân thủ phương pháp luận Agile/Scrum qua 4 Sprint (2 tuần/Sprint):

  • Sprint 1: Phân tích kiến trúc, thiết kế lược đồ CSDL, cấu hình Service Discovery (Eureka) và API Gateway.
  • Sprint 2: Triển khai Core Services (Auth, Order, Inventory) trên Spring Boot 3; tích hợp MyBatis-Plus và Redis Cache.
  • Sprint 3: Tích hợp giao dịch phân tán Saga/Seata, xây dựng RabbitMQ Outbox Pattern, cấu hình Next.js App Router kết nối Backend qua REST/gRPC.
  • Sprint 4: Kiểm thử tải (JMeter/k6), tối ưu hóa chỉ số Web Vitals, bảo mật JWT/OAuth2 và đóng gói Kubernetes/Helm Chart.

Implementation và kết quả

Development Process

1. Triển khai Cache-Aside Pattern với Redis trong Spring Boot

Để tối ưu tốc độ đọc và giảm tải cho PostgreSQL, lớp dịch vụ áp dụng chiến lược Cache-Aside kết hợp cơ chế khóa phân tán ngăn chặn hiện tượng Cache Stampede:

@Service
@RequiredArgsConstructor
@Slf4j
public class ProductCatalogService {

    private final ProductRepository productRepo;
    private final RedisTemplate<String, Object> redisTemplate;
    private static final String CACHE_KEY_PREFIX = "product:details:";
    private static final Duration TTL_DURATION = Duration.ofMinutes(30);

    public ProductDTO getProductById(String productId) {
        String key = CACHE_KEY_PREFIX + productId;
        
        // 1. Kiểm tra trong Cache
        ProductDTO cachedData = (ProductDTO) redisTemplate.opsForValue().get(key);
        if (cachedData != null) {
            log.info("Cache HIT cho Product ID: {}", productId);
            return cachedData;
        }

        // 2. Cache MISS: Truy vấn Database và nạp ngược lại vào Cache
        log.warn("Cache MISS cho Product ID: {}. Đang đọc từ CSDL...", productId);
        Product entity = productRepo.findById(productId)
            .orElseThrow(() -> new ResourceNotFoundException("Sản phẩm không tồn tại: " + productId));

        ProductDTO dto = convertToDto(entity);
        redisTemplate.opsForValue().set(key, dto, TTL_DURATION);
        return dto;
    }
}

2. Xử lý giao dịch phân tán với Saga Pattern qua OpenFeign và Seata

Tại tầng giao dịch đặt hàng, đơn hàng được khởi tạo đồng thời gọi sang Inventory Service để giữ chỗ sản phẩm. Nếu tồn kho không đủ, quá trình bù trừ (Compensating Transaction) được kích hoạt tự động:

@RestController
@RequestMapping("/api/v1/orders")
@RequiredArgsConstructor
public class OrderController {

    private final OrderProcessingService orderService;

    @PostMapping("/checkout")
    @GlobalTransactional(name = "create-order-saga", rollbackFor = Exception.class)
    public ResponseEntity<OrderResponse> checkout(@Valid @RequestBody OrderRequest request) {
        OrderResponse response = orderService.processOrderPipeline(request);
        return ResponseEntity.status(HttpStatus.CREATED).body(response);
    }
}

@FeignClient(name = "inventory-service", fallback = InventoryServiceFallback.class)
public interface InventoryClient {
    @PutMapping("/api/v1/inventory/deduct")
    DeductStockResponse deductStock(@RequestBody DeductStockRequest request);
}

Testing và validation

Quá trình kiểm thử hiệu năng được thực hiện bằng công cụ k6 trên môi trường cụm 3 Node (mỗi Node cấu hình 4 vCPU, 8GB RAM):

Kịch bản kiểm thử Tải giả lập (Concurrency) Tỷ lệ thành công (Success Rate) P95 Latency P99 Latency Throughput (RPS)
Đọc dữ liệu qua Redis Cache 5,000 VUs 99.98% 14.2 ms 28.5 ms 8,420 req/s
Ghi đơn hàng (Saga Transaction) 2,000 VUs 99.85% 142.8 ms 210.4 ms 1,850 req/s
Direct DB Query (Không Cache) 5,000 VUs 88.40% 850.0 ms 1,620.0 ms 1,120 req/s
  • Độ bao phủ mã nguồn (Code Coverage): Đạt 87.5% theo báo cáo JaCoCo trên tổng số 142 Unit & Integration Tests.
  • Tối ưu hóa Frontend (Core Web Vitals): Điểm Google Lighthouse đạt 96/100; chỉ số LCP (Largest Contentful Paint) đạt 1.1s nhờ kỹ thuật Incremental Static Regeneration (ISR) từ Next.js.

Đổi mới và đóng góp

  1. Kiến trúc dung hợp Hybrid Caching (Reverse Proxy Cache + Sidecar): Kết hợp caching tại tầng Envoy L7 Gateway và Redis distributed cache cục bộ, giảm thiểu 64% độ trễ mạng so với mô hình REST gateway truyền thống.
  2. Loại bỏ hiện tượng mất mát dữ liệu phân tán với Outbox Pattern: Đảm bảo 100% sự kiện đặt hàng và trừ tồn kho được chuyển phát tin cậy qua RabbitMQ ngay cả khi xảy ra sự cố sập node mạng (Network Partition).
  3. Mô hình đồng thuận phân tán Raft ứng dụng trong State Machine Replication: So sánh định lượng và chứng minh tính ưu việt của Raft so với giao thức 2-Phase Commit (2PC) truyền thống trong việc giải quyết bài toán nghẽn Coordinator.
Chỉ số kỹ thuật Hệ thống Monolith cũ Hệ thống Spring Boot + Next.js mới % Cải thiện
Thời gian đáp ứng trung bình (P95) 385 ms 28.5 ms Giảm 92.6%
Khả năng chịu tải cực đại 1,200 RPS 8,420 RPS Tăng 601.6%
Thời gian triển khai bản vá (Deploy Downtime) 45 phút (Ngừng hệ thống) 0 phút (Zero-Downtime Rolling Update) Loại bỏ 100% downtime

Ứng dụng thực tế và triển khai

Hệ thống được thiết kế sẵn sàng triển khai trên môi trường doanh nghiệp quy mô lớn (E-Commerce, FinTech, Logistics):

+-----------------------------------------------------------------------------------+
|                        MÔ HÌNH TRIỂN KHAI KUBERNETES                             |
|                                                                                   |
|                   [ Ingress Controller / Cloud Load Balancer ]                    |
|                                        |                                          |
|            +---------------------------+---------------------------+              |
|            |                                                       |              |
|            v                                                       v              |
|  [ Pod: Next.js Frontend ]                               [ Pod: Envoy Gateway ]   |
|  (Replica: 3, Auto-scale)                                (Replica: 2)             |
|                                                                    |              |
|                             +--------------------------------------+              |
|                             |                                      |              |
|                             v                                      v              |
|                   [ Pod: Order-Service ]                [ Pod: Inventory-Service ]|
|                   (Horizontal Pod Auto)                 (Horizontal Pod Auto)     |
|                             |                                      |              |
|                             +------------------+-------------------+              |
|                                                |                                  |
|                                                v                                  |
|                             [ StatefulSet: Redis / RabbitMQ / DB ]                |
+-----------------------------------------------------------------------------------+

Lộ trình triển khai 4 giai đoạn

  1. Giai đoạn 1 (Containerization): Đóng gói toàn bộ services thành Docker Images dạng Multi-stage build nhằm giảm kích thước image (< 180MB/service).
  2. Giai đoạn 2 (Cluster Orchestration): Khai báo Kubernetes Manifests (Deployments, Services, ConfigMaps, Secrets, Ingress Controller).
  3. Giai đoạn 3 (Service Mesh & Monitoring): Thiết lập Prometheus, Grafana Dashboard và hệ thống tập trung nhật ký ELK Stack (Elasticsearch, Logstash, Kibana).
  4. Giai đoạn 4 (Zero-Downtime Pipeline): Cấu hình GitHub Actions CI/CD tự động chạy Unit Test, quét lỗ hổng SonarQube và thực hiện Rolling Updates trên K8s.

Hạn chế và hướng phát triển

  • Hạn chế kỹ thuật:
    • Mô hình giao dịch bù trừ Saga Choreography có thể dẫn đến trạng thái dữ liệu đọc bẩn tạm thời (Dirty Read) trước khi giao dịch bù hoàn tất (Eventual Consistency lag từ 50ms - 200ms).
    • Thuật toán Raft hiện tại phụ thuộc vào duy nhất một Leader node tại một thời điểm cho mọi thao tác ghi, tạo ra giới hạn trần mở rộng ghi theo chiều ngang (Horizontal Write Bottleneck).
  • Hướng phát triển:
    • Nghiên cứu tích hợp kiến trúc Service Mesh toàn diện với Istio nhằm mã hóa lưu lượng nội bộ (mTLS) và kiểm soát định tuyến lưu lượng thông minh (Canary Deployment).
    • Nâng cấp cơ chế phân vùng dữ liệu Sharding Sphere trên PostgreSQL để giải quyết triệt để bài toán mở rộng dung lượng lưu trữ phân tán.

Đối tượng hưởng lợi

  • Sinh viên & Học viên chuyên ngành Phần mềm: Tiếp cận tài liệu chuẩn mực về kiến trúc phân tán, mã nguồn mẫu về Saga Pattern, Cache-Aside, và quy trình kết hợp Spring Boot với Next.js.
  • Kỹ sư phát triển phần mềm (Software Engineers): Nắm vững các pattern thiết kế chống nghẽn, kỹ thuật tối ưu hóa SQL qua MyBatis-Plus và giải pháp xử lý Outbox Pattern thực chiến.
  • Doanh nghiệp vừa và lớn: Sở hữu bản thiết kế tham chiếu (Reference Architecture) có tính khả thi cao, giúp tiết kiệm đến 40% chi phí nghiên cứu hạ tầng và rút ngắn thời gian đưa sản phẩm ra thị trường (Time-to-Market).
  • Nhà nghiên cứu khoa học: Dữ liệu benchmark thực nghiệm về sự đánh đổi giữa tính nhất quán và độ sẵn sàng (CAP Theorem) trong môi trường vi dịch vụ thực tế.

Câu hỏi thường gặp

1. Yêu cầu phần cứng tối thiểu để triển khai cụm hệ thống là gì?

Hạ tầng cụm Kubernetes cơ sở yêu cầu tối thiểu 3 Master Nodes (2 vCPU, 4GB RAM) và 3 Worker Nodes (4 vCPU, 8GB RAM, SSD NVMe) để đảm bảo phân bổ đủ tài nguyên cho Redis Cluster, RabbitMQ, PostgreSQL và các Pod microservices.

2. Làm thế nào để giải quyết xung đột dữ liệu khi sử dụng Eventual Consistency trong Saga?

Hệ thống sử dụng kỹ thuật khóa ngữ nghĩa (Semantic Lock) hoặc trạng thái tạm thời (ví dụ: PENDING_CHECKOUT). Trong quá trình giao dịch Saga đang thực thi, tài nguyên bị giữ chỗ sẽ không cho phép các luồng nghiệp vụ khác can thiệp cho đến khi nhận được Event xác nhận hoặc lệnh bồi hoàn (Compensating Action).

3. Sự khác biệt cốt lõi giữa 2-Phase Commit (2PC) và Saga Pattern là gì?

2PC duy trì khóa đọc/ghi (Read/Write Locks) trên toàn bộ tài nguyên tham gia trong suốt 2 pha (Prepare & Commit), đảm bảo Strong Consistency nhưng dễ gây nghẽn và sập hệ thống nếu Coordinator chết. Ngược lại, Saga chia nhỏ thành các giao dịch cục bộ độc lập và chấp nhận Eventual Consistency, mang lại khả năng chịu tải và độ khả dụng cao hơn vượt trội.

4. Chi phí bản quyền và vận hành của Stack công nghệ này như thế nào?

100% các thành phần cốt lõi (Spring Boot, Next.js, PostgreSQL, Redis, RabbitMQ, Envoy, Kubernetes) đều là mã nguồn mở (Open-Source với giấy phép Apache 2.0 / MIT), giúp doanh nghiệp hoàn toàn không tốn chi phí bản quyền phần mềm, chỉ phát sinh chi phí hạ tầng máy chủ Cloud (AWS, GCP, DigitalOcean hoặc Bare-metal).

5. Tại sao cần kết hợp cả Next.js SSR và Spring Boot Microservices?

Next.js đóng vai trò tối ưu hóa hiển thị tầng biên (Edge UI Rendering), cải thiện điểm số SEO thông qua HTML dựng sẵn từ server và nạp dữ liệu tức thì. Spring Boot chịu trách nhiệm về tính toàn vẹn nghiệp vụ, xử lý luồng công việc nặng, bảo mật cấp doanh nghiệp và điều phối kết nối hạ tầng phân tán.

Kết luận

Đồ án "Tìm hiểu Spring Boot – Next.js và Xây dựng Ứng dụng Phân tán" đã chứng minh tính hiệu quả vượt bậc của việc phối hợp kiến trúc Microservices hiện đại cùng giao diện tối ưu hóa SEO. Thông qua việc phân tích sâu sắc các nguyên lý thiết kế phân tán (Load Balancing, Caching, Consensus, Distributed Transactions) và ứng dụng thực tế các công nghệ tiêu chuẩn công nghiệp (Spring Boot 3, Next.js 14, Redis, RabbitMQ, Envoy, Seata), công trình đã cung cấp một giải pháp phần mềm toàn diện, có khả năng mở rộng linh hoạt, độ trễ thấp và độ tin cậy đạt chuẩn doanh nghiệp.