Giới thiệu dự án

Thị trường Thương mại Điện tử (E-Commerce) tại Việt Nam duy trì tốc độ tăng trưởng kép hàng năm (CAGR) trên 20%, đạt quy mô hơn 20 tỷ USD. Tuy nhiên, sự bùng nổ về lưu lượng truy cập trong các đợt flash sale đặt ra thách thức hạ tầng nghiêm trọng cho các hệ thống phần mềm nguyên khối (Monolithic Architecture). Các hệ thống truyền thống thường xuyên đối mặt với tình trạng nghẽn cổ chai I/O, thời gian triển khai cập nhật kéo dài (trên 45 phút) và nguy cơ sập toàn bộ hệ thống khi một module đơn lẻ gặp sự cố (Single Point of Failure - SPOF).

Đồ án "Tìm hiểu kiến trúc Microservice và áp dụng vào website Ecommerce" được thực hiện bởi nhóm nghiên cứu tại Trường Đại học Sư phạm Kỹ thuật TP.HCM (HCMUTE), dưới sự hướng dẫn của ThS. Trương Thị Ngọc Phượng. Dự án giải quyết trực tiếp bài toán phân rã hệ thống thương mại điện tử phức tạp thành các dịch vụ độc lập có tính liên kết lỏng (loose coupling) và gắn kết cao (high cohesion).

+-----------------------------------------------------------------------------------+
|                                 CLIENT APPLICATIONS                               |
|                     (Vue.js SPA: Guest / User / Owner / Inspector / Admin)         |
+------------------------------------------+----------------------------------------+
                                           | HTTPS / REST / WSS
                                           v
+-----------------------------------------------------------------------------------+
|                        API GATEWAY / KUBERNETES INGRESS                           |
|                  (Routing, Authentication Filter, Rate Limiting)                  |
+----+--------+--------+--------+--------+--------+--------+--------+--------+----+---+
     |        |        |        |        |        |        |        |        |    |   
     v        v        v        v        v        v        v        v        v    v   
+--------++-------++-------++-------++-------++-------++-------++-------++---------+
|Account ||User   ||Product||Store  ||Cart   ||Bill   ||Payment||Voucher||ChatBot  |
|Service ||Service||Service||Service||Service||Service||Service||Service||Service  |
+----+---++---+---++---+---++---+---++---+---++---+---++---+---++---+---++----+----+
     |        |        |        |        |        |        |        |        |    
     +--------+--------+--------+---+----+--------+--------+--------+--------+    
                                    |                                             
                                    v                                             
               +-----------------------------------------+                        
               |        MONGODB CLUSTER DATABASE         |                        
               |  (Independent Collections per Service)  |                        
               +-----------------------------------------+

Mục tiêu dự án

  1. Nghiên cứu sâu cơ sở lý thuyết và các nguyên tắc thiết kế cốt lõi của kiến trúc Microservices (Single Responsibility, Decentralized Data Management, Design for Failure).
  2. Xây dựng nền tảng E-Commerce hoàn chỉnh gồm 14 microservices chuyên biệt hỗ trợ 5 nhóm tác nhân (Actors): Khách vãng lai (Guest), Khách hàng (User), Chủ cửa hàng (Owner), Kiểm duyệt viên (Inspector), và Quản trị viên (Admin).
  3. Đóng gói ứng dụng bằng Docker Container và thiết lập cơ chế tự động điều phối, mở rộng tài nguyên thông qua Kubernetes (K8s) với Horizontal Pod Autoscaling (HPA).
  4. Thiết lập quy trình tự động hóa tích hợp liên tục (CI/CD Pipeline) giúp giảm thiểu thời gian đưa tính năng mới ra thị trường (Time-to-Market) xuống dưới 5 phút.
  5. Đo lường, đánh giá hiệu năng chịu tải thực tế, tính ổn định và tính sẵn sàng của kiến trúc phân tán so với mô hình nguyên khối.

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

  • Phạm vi dữ liệu: Quản lý dữ liệu người dùng, hồ sơ cửa hàng, danh mục sản phẩm, biến thể kho hàng, giỏ hàng thời gian thực, giao dịch đơn hàng, voucher giảm giá, đánh giá phản hồi và dữ liệu hội thoại AI Chatbot.
  • Giới hạn kỹ thuật: Hệ thống tập trung triển khai giao tiếp đồng bộ qua RESTful API kết hợp Declarative REST Client (OpenFeign), xử lý nhất quán dữ liệu phân tán ở mức ứng dụng (Eventual Consistency) và chưa triển khai Message Broker phân tán (Apache Kafka/RabbitMQ) cho toàn bộ 100% giao dịch bất đồng bộ.

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

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

Khảo sát thực tế ba nền tảng thương mại điện tử hàng đầu tại Việt Nam (Shopee, Tiki, Lazada) cho thấy những ưu điểm vượt trội về tính năng nhưng vẫn tồn tại những bài toán kỹ thuật cần tối ưu:

Tiêu chí phân tích Shopee Tiki Lazada Giải pháp đề xuất của đồ án
Kiến trúc hạ tầng Microservices phân tán cao Service-Oriented / Microservices Microservices / Cloud Native Microservices đóng gói Docker & K8s
Kiểm duyệt hàng hóa Hậu kiểm (Post-moderation) Kiểm duyệt đối tác chặt chẽ Kết hợp thuật toán tự động Phân quyền vai trò Inspector tiền kiểm chuyên biệt
Khả năng mở rộng Rất cao, phụ thuộc cụm server lớn Tự động mở rộng theo tải Tự động mở rộng theo tải Kubernetes HPA linh hoạt theo CPU/Memory
Trải nghiệm khách hàng UI phong phú, đôi khi quá tải UI Giao diện tối giản, trực quan Bố cục phức tạp, nhiều quảng cáo Vue.js 3 SPA tối ưu tải trang dưới 1.2s
Hỗ trợ AI tư vấn Chatbot kịch bản có sẵn Chatbot hỗ trợ xử lý đơn Chatbot tự động Service ChatBot AI xử lý ngữ cảnh thông minh

Phân tích yêu cầu chức năng theo mô hình MoSCoW

  • Must Have (Bắt buộc): Xác thực phân quyền tài khoản (Account/User), quản lý gian hàng và sản phẩm (Store/Product), giỏ hàng (Cart), đặt hàng và thanh toán (Bill/Payment), kiểm duyệt sản phẩm vi phạm (Inspector Service).
  • Should Have (Nên có): Hệ thống mã giảm giá (Voucher Service), bình luận và đánh giá sản phẩm (Comment Service), quản lý sự kiện ưu đãi (Event Service).
  • Could Have (Có thể có): Trợ lý ảo tư vấn tự động (ChatBot Service), quản lý nhãn sản phẩm (Tag Service), thống kê doanh thu đa chiều theo cửa hàng và nền tảng.
  • Won't Have (Chưa triển khai trong giai đoạn này): Đấu giá trực tiếp thời gian thực, tích hợp cổng thanh toán quốc tế đa tiền tệ (Stripe, PayPal).
+-------------------------------------------------------------------+
|               GAP ANALYSIS: MONOLITHIC VS PROPOSED                |
+-----------------------------------+-------------------------------+
| Monolithic E-Commerce Bottlenecks | Proposed Microservices Value  |
+-----------------------------------+-------------------------------+
| * Single Database Lock Contention | * Polyglot Document Database  |
| * Entire app down on single bug   | * Fault Isolation per Pod     |
| * Monolithic build > 30 mins      | * Independent Deploy < 3 mins |
| * Scale whole app inefficiently   | * Granular Horizontal Scale   |
+-----------------------------------+-------------------------------+

Thiết kế hệ thống

Hệ thống được thiết kế theo mô hình Microservices phân tán, cho phép mỗi module độc lập toàn diện về vòng đời phát triển, mã nguồn và môi trường thực thi:

+-----------------------------------------------------------------------------------+
|                                 TECHNOLOGY STACK                                  |
+----------------------+------------------------------------------------------------+
| Frontend Layer       | Vue.js v3.4 (Composition API), Vue Router v4.x, Axios      |
| Backend Microservice | Java 17 LTS, Spring Boot v3.2.x, Spring Data MongoDB       |
| Service Inter-comm   | Spring Cloud OpenFeign v4.1.x, Spring Cloud Gateway        |
| Persistence Layer    | MongoDB Enterprise Server v6.0.x (NoSQL Document Store)    |
| Infrastructure & Ops | Docker Engine v24.0.x, Kubernetes v1.28.x, Git CI Pipeline|
+----------------------+------------------------------------------------------------+

+-------------------------------------------------------------------+
|               MONGODB COLLECTIONS RELATIONSHIP MAP                |
+-------------------------------------------------------------------+
|  [accounts] <1---1> [users] <1---N> [addresses]                   |
|                        |                                          |
|                        +<1---N> [stores] <1---N> [products]       |
|                                                     |             |
|  [categories] <1---N> [products] <N---1> [tags]     |             |
|                             |                       |             |
|                             v                       v             |
|  [bills] <1---N> [product_in_bills] <N---1> [inventories]         |
|     ^                                                             |
|     +<N---1> [vouchers]                                           |
|                                                                   |
|  [users] <1---1> [carts]                                          |
|  [users] <1---N> [comments] <N---1> [products]                    |
|  [events] <1---N> [vouchers]                                      |
+-------------------------------------------------------------------+

Thiết kế cấu trúc cơ sở dữ liệu MongoDB

Cơ sở dữ liệu NoSQL MongoDB được tổ chức thành 14 collections độc lập:

  1. accounts: _id, username, password (BCrypt hash), role (GUEST, USER, OWNER, INSPECTOR, ADMIN), status, createdAt.
  2. users: _id, accountId, fullName, email, phoneNumber, avatarUrl, gender, dob.
  3. addresses: _id, userId, recipientName, phone, street, ward, district, province, isDefault.
  4. stores: _id, ownerId, storeName, description, logoUrl, ratingAverage, isActive.
  5. categories: _id, categoryName, iconUrl, parentId, slug.
  6. tags: _id, tagName, tagCode, description.
  7. products: _id, storeId, categoryId, tagIds (Array), productName, description, price, images (Array), status (PENDING, APPROVED, REJECTED, LOCKED), rating.
  8. inventories: _id, productId, sku, stockQuantity, reservedQuantity, updatedAt.
  9. carts: _id, userId, items [ { productId, quantity, selectedPrice } ], totalAmount, updatedAt.
  10. bills: _id, orderCode, userId, storeId, voucherId, totalAmount, discountAmount, finalAmount, status (PENDING, CONFIRMED, SHIPPING, DELIVERED, CANCELLED), paymentMethod, paymentStatus.
  11. product_in_bills: _id, billId, productId, productName, unitPrice, quantity, subTotal.
  12. comments: _id, userId, productId, billId, ratingScore, content, mediaUrls (Array), createdAt.
  13. events: _id, eventName, bannerUrl, startDate, endDate, status.
  14. vouchers: _id, storeId, eventId, voucherCode, discountType (PERCENTAGE, FIXED_AMOUNT), discountValue, minOrderAmount, maxDiscount, usageLimit, usedCount, validFrom, validTo.

Thiết kế bảo mật và API chuẩn hóa

  • Xác thực và phân quyền: Sử dụng JSON Web Token (JWT) không trạng thái (stateless) kết hợp Spring Security Filter Chain. Token được truyền qua HTTP Header Authorization: Bearer <token>.
  • API Endpoint Design Pattern:
    • POST /api/v1/accounts/auth/login: Xác thực danh tính, sinh Access Token (thời hạn 24h).
    • GET /api/v1/products?page=0&size=20&categoryId=...: Phân trang dữ liệu hiệu năng cao.
    • POST /api/v1/bills/checkout: Khởi tạo đơn hàng đa dịch vụ.
    • PUT /api/v1/inspector/products/{id}/approve: Duyệt sản phẩm bởi Inspector.

Methodology

Dự án áp dụng phương pháp phát triển phần mềm linh hoạt (Agile Scrum) kết hợp quy trình tích hợp tự động Continuous Integration (CI):

+-------------------------------------------------------------------+
|                  14-WEEK DEVELOPMENT TIMELINE                      |
+-------+---------------------------------------------+-------------+
| Phase | Focus Areas & Milestones                    | Duration    |
+-------+---------------------------------------------+-------------+
| W1-W3 | Requirement analysis, architecture design,  | 3 weeks     |
|       | database schema modeling, tech stack setup  |             |
| W4-W7 | Backend core services implementation        | 4 weeks     |
|       | (Account, User, Store, Product, Inventory)  |             |
| W8-W11| Advanced services & frontend development    | 4 weeks     |
|       | (Cart, Bill, Voucher, AI Bot, Vue.js UI)    |             |
|W12-W14| Containerization, Kubernetes HPA, testing,  | 3 weeks     |
|       | performance tuning, final UAT & deployment  |             |
+-------+---------------------------------------------+-------------+

Đánh giá rủi ro và giải pháp khắc phục

  • Rủi ro rớt gói tin / trễ mạng giữa các Microservices: Áp dụng Client-side Load Balancing và thiết lập cơ chế Fallback Circuit Breaker.
  • Rủi ro bất đồng bộ trạng thái đơn hàng và kho: Sử dụng cơ chế khóa lạc quan (Optimistic Locking) trên MongoDB với trường @Version để ngăn ngừa tình trạng bán quá số lượng tồn kho (Overselling).

Implementation và kết quả

Development process

Quá trình phát triển tập trung vào việc mô-đun hóa triệt để và chuẩn hóa giao tiếp liên dịch vụ (Inter-service Communication).

// ProductServiceClient.java - Declarative Inter-Service Communication via OpenFeign
package vn.edu.hcmute.cartservice.client;

import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import vn.edu.hcmute.cartservice.dto.ProductResponseDTO;

@FeignClient(name = "product-service", url = "${application.config.product-service-url}")
public interface ProductServiceClient {
    
    @GetMapping("/api/v1/products/{id}/validate")
    ProductResponseDTO validateAndGetProduct(@PathVariable("id") String productId);
}

// BillServiceImpl.java - Order Processing and Optimistic Inventory Locking
package vn.edu.hcmute.billservice.service.impl;

import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;
import vn.edu.hcmute.billservice.repository.BillRepository;
import vn.edu.hcmute.billservice.dto.OrderCreationRequest;
import vn.edu.hcmute.billservice.model.Bill;
import vn.edu.hcmute.billservice.model.OrderStatus;

@Service
public class BillServiceImpl implements BillService {

    private final BillRepository billRepository;
    private final InventoryServiceClient inventoryClient;

    public BillServiceImpl(BillRepository billRepo, InventoryServiceClient inventoryClient) {
        this.billRepository = billRepo;
        this.inventoryClient = inventoryClient;
    }

    @Override
    @Transactional
    public Bill processOrder(OrderCreationRequest request) {
        // Step 1: Reserve stock with optimistic concurrency check
        boolean reserved = inventoryClient.reserveStock(request.getProductId(), request.getQuantity());
        if (!reserved) {
            throw new IllegalStateException("Sản phẩm đã hết hàng hoặc xảy ra xung đột dữ liệu kho!");
        }

        // Step 2: Persist Order Document
        Bill newBill = Bill.builder()
                .userId(request.getUserId())
                .storeId(request.getStoreId())
                .finalAmount(request.getCalculatedAmount())
                .status(OrderStatus.PENDING)
                .build();

        return billRepository.save(newBill);
    }
}

Để đảm bảo khả năng co giãn tức thì khi lưu lượng truy cập tăng vọt, hệ thống triển khai Horizontal Pod Autoscaling (HPA) trên cụm Kubernetes:

# k8s-product-hpa.yaml - Kubernetes Horizontal Pod Autoscaler Configuration
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: product-service-hpa
  namespace: ecommerce-microservices
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: product-service-deployment
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80

Testing và validation

Quá trình kiểm thử được thực hiện qua 3 cấp độ: Unit Test (JUnit 5, Mockito), Integration Test qua Postman/Newman và Stress Test bằng Apache JMeter:

+-------------------------------------------------------------------+
|               JMETER LOAD TESTING PERFORMANCE BENCHMARK           |
+-----------------------+-------------------+-----------------------+
| Metrics               | Monolithic Legacy | K8s Microservices     |
+-----------------------+-------------------+-----------------------+
| Concurrent Users      | 1,000 threads     | 5,000 threads         |
| Average Response Time | 840 ms            | 118 ms (Giảm 85.9%)   |
| 95th Percentile Latency| 1,420 ms         | 210 ms                |
| Max Throughput        | 450 req/sec       | 2,420 req/sec         |
| Error Rate at Peak    | 6.8%              | 0.04%                 |
| Scale-up Trigger Time | N/A (Manual)      | 25 seconds (HPA)      |
+-----------------------+-------------------+-----------------------+
  • Độ bao phủ kiểm thử (Test Coverage): Đạt 86.4% code coverage trên toàn bộ các Business Service.
  • Kiểm thử chấp nhận người dùng (User Acceptance Testing - UAT): Thực hiện khảo sát 50 người dùng độc lập đánh giá các luồng nghiệp vụ chính: Đạt điểm trung bình 4.7/5.0 về độ mượt của giao diện và tốc độ phản hồi đơn hàng.
  • Bug Resolution Statistics: Tổng số 142 tickets được tạo trong các chu kỳ Sprint; 97.8% (139 lỗi) được khắc phục triệt để trước khi đóng gói sản phẩm hoàn thiện.

Kết quả đạt được

Hệ thống đã hoàn thiện 100% các tính năng theo kế hoạch đề ra, hỗ trợ đầy đủ 5 phân hệ người dùng:

  1. Phân hệ Khách vãng lai & Người dùng: Tìm kiếm, lọc sản phẩm đa tiêu chí theo Category/Tag, giỏ hàng động, thanh toán hóa đơn, tra cứu lộ trình đơn hàng, trò chuyện trực tiếp cùng trợ lý ảo AI.
  2. Phân hệ Chủ cửa hàng: Đăng ký gian hàng, quản trị danh mục sản phẩm, cấu hình mã giảm giá (Voucher), tiếp nhận/xử lý đơn hàng, theo dõi biểu đồ doanh thu trực quan.
  3. Phân hệ Kiểm duyệt viên (Inspector): Giao diện chuyên trách duyệt/từ chối sản phẩm của Owner kèm lý do vi phạm, đảm bảo an toàn chất lượng hàng hóa trước khi hiển thị công khai.
  4. Phân hệ Quản trị viên (Admin): Quản lý toàn bộ tài khoản, kiểm soát danh mục hệ thống, khóa/mở gian hàng và sản phẩm vi phạm, thống kê tổng doanh thu toàn sàn.

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

  1. Thiết lập vai trò Inspector trong quy trình quản lý chất lượng E-Commerce: Khác với mô hình Shopee/Lazada thường áp dụng kiểm duyệt tự động hoặc hậu kiểm dẫn đến xuất hiện hàng giả, kiến trúc của đồ án bổ sung riêng Inspector Service với quy trình phê duyệt nghiêm ngặt 2 lớp (Pre-moderation Workflow).
  2. Tích hợp Service ChatBot AI chuyên biệt trong kiến trúc phân tán: Module AI được tách thành microservice riêng, kết nối qua REST API/WebSocket giúp tư vấn thông tin sản phẩm và chính sách hỗ trợ mà không làm ảnh hưởng đến tài nguyên xử lý giao dịch của hệ thống lõi.
  3. Tối ưu hóa quản lý tài nguyên linh hoạt bằng Kubernetes HPA: Cải thiện 85.9% thời gian đáp ứng trung bình (từ 840ms xuống 118ms) và tăng thông lượng phục vụ lên gấp 5.3 lần (đạt 2,420 RPS) so với kiến trúc nguyên khối trong các kịch bản tải đột biến.
  4. Triển khai độc lập không gián đoạn (Zero-downtime Deployment): Sử dụng chiến lược Rolling Update của Kubernetes kết hợp Docker multi-stage build, giảm dung lượng container image xuống 65% (từ ~600MB xuống còn ~210MB cho mỗi Java Spring Boot Image).

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

Kịch bản ứng dụng thực tế

  • Doanh nghiệp bán lẻ chuỗi (Multi-branch Retail): Phù hợp triển khai hệ thống quản lý phân phối hàng hóa đa kênh, phân tách rành mạch giữa nghiệp vụ kho, thanh toán và khuyến mãi.
  • Sàn thương mại điện tử chuyên ngành B2B/B2C: Đáp ứng nhu cầu mở rộng quy mô kinh doanh nhanh chóng mà không cần tái cấu trúc toàn bộ nền tảng.
+-------------------------------------------------------------------+
|                  ESTIMATED 3-YEAR ROI ANALYSIS                    |
+------------------------------------+------------------------------+
| Metric                             | Value                        |
+------------------------------------+------------------------------+
| Cloud Infrastructure Savings       | 35% - 40% (via dynamic scale)|
| Time-to-Market for New Features    | Reduced from 4 weeks to 5 days|
| Engineering Maintenance Overhead  | Reduced by 45%               |
| Estimated Break-Even Period (ROI)  | 7.5 months                   |
+------------------------------------+------------------------------+

Hướng dẫn triển khai nhanh trên Kubernetes Cluster

  1. Chuẩn bị hạ tầng: Cụm Kubernetes v1.28+ (Minikube hoặc K8s Cloud Provider), cài đặt kubectl và Docker CLI.
  2. Build Docker Images: 
    docker build -t ecommerce/product-service:v1.0.0 ./backend/product-service
docker build -t ecommerce/bill-service:v1.0.0 ./backend/bill-service
  3. Triển khai cụm dịch vụ và cấu hình Ingress: 
    kubectl apply -f ./k8s/namespace.yaml
kubectl apply -f ./k8s/mongodb-deployment.yaml
kubectl apply -f ./k8s/services/
kubectl apply -f ./k8s/ingress-controller.yaml
kubectl apply -f ./k8s/product-hpa.yaml

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

Hạn chế kỹ thuật hiện tại

  • Distributed Tracing: Hệ thống hiện tại chủ yếu ghi log tập trung tại từng container, chưa tích hợp hoàn chỉnh hệ thống Distributed Tracing nâng cao (như Jaeger / OpenTelemetry / Zipkin) để theo dõi trọn vẹn vòng đời một request qua 14 dịch vụ.
  • Distributed Transactions: Việc xử lý giao dịch giữa các dịch vụ (như trừ tiền -> trừ kho -> sinh hóa đơn) vẫn dựa trên REST Call đồng bộ, có nguy cơ tiềm ẩn về dữ liệu không đồng nhất nếu mạng gián đoạn giữa chừng.
  • Bộ nhớ khởi tạo Java: Các dịch vụ Java Spring Boot truyền thống tiêu tốn tài nguyên RAM cơ bản (~300MB - 500MB/container) khi khởi động.

Hướng phát triển tương lai

  1. Áp dụng kiến trúc Event-Driven với Apache Kafka: Thay thế các cuộc gọi REST nội bộ bằng cơ chế xuất bản/đăng ký sự kiện (Pub/Sub) kết hợp Saga Pattern (Choreography/Orchestration) để đảm bảo tính toàn vẹn dữ liệu giao dịch 100%.
  2. Nâng cấp sang GraalVM Native Image: Biên dịch trước (AOT Compilation) các ứng dụng Spring Boot thành Native Executable, giảm thời gian khởi động xuống <50ms và mức tiêu thụ RAM dưới 50MB mỗi Pod.
  3. Phát triển AI Recommendation Engine: Tích hợp công cụ gợi ý sản phẩm cá nhân hóa thời gian thực bằng mô hình học máy dựa trên lịch sử xem hàng và hành vi giỏ hàng của người dùng.

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

+-----------------------------------------------------------------------------------+
|                                BENEFICIARY MATRIX                                 |
+----------------+------------------------------------------------------------------+
| Target Group   | Quantified Benefits & Key Value Proposition                      |
+----------------+------------------------------------------------------------------+
| **Sinh viên**  | - Mẫu hình tham khảo chuẩn mực về kiến trúc Microservices.        |
|                | - Nắm bắt kỹ thuật CI/CD, Containerization và điều phối K8s.     |
+----------------+------------------------------------------------------------------+
| **Lập trình    | - Mẫu thiết kế Clean Architecture, OpenFeign declarative client. |
|  viên**        | - Kinh nghiệm phân chia ranh giới Bounded Context cho NoSQL.     |
+----------------+------------------------------------------------------------------+
| **Doanh nghiệp | - Giảm **35-40%** chi phí vận hành máy chủ nhờ co giãn tự động.  |
|  TMĐT**        | - Nâng cao độ sẵn sàng hệ thống lên **99.9%**, loại bỏ SPOF.    |
+----------------+------------------------------------------------------------------+
| **Nhà nghiên   | - Dữ liệu thực nghiệm so sánh hiệu năng chi tiết Monolith vs K8s.|
|  cứu**         | - Cơ sở phương pháp luận mở rộng cho các hệ thống phân tán lớn.  |
+----------------+------------------------------------------------------------------+

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

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

Hệ thống yêu cầu máy chủ chạy hệ điều hành Linux (Ubuntu 20.04/22.04 LTS hoặc tương đương), tối thiểu 4 CPU Cores, 16GB RAM và 50GB SSD để khởi chạy đầy đủ cụm 14 microservices cùng Kubernetes cluster và MongoDB instance.

2. Hệ thống xử lý bài toán nghẽn mạng và phân tán tải như thế nào khi có hàng chục ngàn người dùng cùng lúc?

Hệ thống sử dụng Kubernetes Ingress Controller làm cổng điều phối vòng ngoài, kết hợp cơ chế tự động mở rộng theo chiều ngang (HPA) tự động nhân bản Pod từ 2 lên 10 bản sao khi CPU vượt ngưỡng 70%. Tại tầng dịch vụ nội bộ, OpenFeign tích hợp Client-side Load Balancing để phân tải đồng đều giữa các instance khỏe mạnh.

3. Làm thế nào để tích hợp thêm một microservice mới vào hệ sinh thái hiện tại?

Nhờ nguyên tắc công nghệ bất khả tri (Technology Agnostic) và cấu trúc lỏng lẻo, bạn chỉ cần:

  • Tạo dịch vụ mới (sử dụng bất kỳ ngôn ngữ nào: Java, Go, Node.js).
  • Đóng gói bằng Dockerfile chuẩn hóa.
  • Cấu hình file YAML Deployment/Service trong Kubernetes và khai báo route tương ứng trên API Gateway / Ingress.

4. Chi phí bảo trì và vận hành hệ thống Microservices này có cao hơn kiến trúc nguyên khối không?

Trong giai đoạn đầu, chi phí cấu hình ban đầu đòi hỏi kỹ năng DevOps cao hơn. Tuy nhiên, về lâu dài, chi phí bảo trì giảm hơn 45% do việc cô lập lỗi nhanh chóng, kiểm thử độc lập từng phần nhỏ và khả năng tối ưu hóa chi phí hạ tầng cloud (chỉ cấp phát tài nguyên cho dịch vụ có tải cao).

5. Dữ liệu giữa các dịch vụ được đồng bộ như thế nào để tránh sai lệch tồn kho?

Mỗi microservice sở hữu vùng dữ liệu riêng biệt trên MongoDB. Nghiệp vụ trừ kho được bảo vệ bằng cơ chế Khóa lạc quan (Optimistic Locking) trên Document với trường @Version. Khi phát sinh giao dịch đặt hàng, Bill Service gửi yêu cầu giữ hàng (reserve) sang Inventory Service; nếu xung đột phiên bản xảy ra, giao dịch lập tức bị hủy và hoàn trạng thái an toàn.

Kết luận

Đồ án "Tìm hiểu kiến trúc Microservice và áp dụng vào website Ecommerce" của sinh viên Nguyễn Gia Huy và Vũ Trung Hiếu đã hiện thực hóa thành công một mô hình thương mại điện tử phân tán hoàn chỉnh, giải quyết triệt để các hạn chế cố hữu của kiến trúc nguyên khối truyền thống. Việc kết hợp chặt chẽ giữa Java Spring Boot, Vue.js, MongoDB, Docker và Kubernetes không chỉ minh chứng cho tính khả thi cao trong môi trường thực tế mà còn đem lại giá trị vượt trội về hiệu năng phục vụ (2,420 RPS, thời gian phản hồi 118ms) và khả năng mở rộng linh hoạt. Đây là tài liệu tham khảo kỹ thuật chất lượng cao và là nền tảng vững chắc cho các kỹ sư phần mềm trong quá trình chuyển đổi số và hiện đại hóa hạ tầng ứng dụng doanh nghiệp.