Giới thiệu dự án

Thương mại điện tử (TMĐT) tại Việt Nam và khu vực Đông Nam Á đang trải qua giai đoạn bùng nổ mạnh mẽ với quy mô thị trường dự kiến vượt mốc 32 tỷ USD vào năm 2025 (theo báo cáo e-Conomy SEA của Google, Temasek và Bain & Company). Sự dịch chuyển nhanh chóng của các nền tảng mạng xã hội lớn (TikTok Shop, Facebook Marketplace) sang tích hợp sâu tính năng mua sắm trực tiếp đã đặt ra thách thức công nghệ chưa từng có cho các nền tảng TMĐT truyền thống: làm thế nào để mở rộng quy mô tức thì, vận hành liên tục 24/7 không gián đoạn, và xử lý hàng triệu giao dịch đồng thời với độ trễ thấp nhất.

Các hệ sinh thái TMĐT nguyên khối (Monolithic Architecture) xây dựng trên nền tảng cũ (điển hình như các hệ thống PHP/Magento thế hệ trước) bộc lộ những điểm nghẽn nghiêm trọng (bottlenecks):

  • Khó khăn trong việc mở rộng quy mô theo chiều ngang (Horizontal Scalability): Việc tăng tải ở một chức năng (như flash sale sản phẩm) buộc toàn bộ khối ứng dụng khổng lồ phải nhân bản, gây lãng phí tài nguyên máy chủ.
  • Rủi ro điểm lỗi đơn lẻ (Single Point of Failure - SPOF): Sự cố xảy ra tại một module thứ cấp (như thông báo, đánh giá) có thể làm tê liệt toàn bộ quy trình cốt lõi như thanh toán và đặt hàng.
  • Rào cản cập nhật và bảo trì: Mã nguồn cồng kềnh với hàng trăm nghìn dòng lệnh khiến việc tích hợp công nghệ mới diễn ra chậm chạp và tiềm ẩn rủi ro hồi quy phần mềm.
  • Trải nghiệm tìm kiếm nghèo nàn: Các công cụ tìm kiếm chỉ dựa trên văn bản (Text-based Search) gây khó khăn cho người dùng khi muốn tìm kiếm một sản phẩm mà họ chỉ có hình ảnh trực quan nhưng không rõ tên gọi hay thương hiệu.

Dự án khóa luận tốt nghiệp "Xây dựng hệ thống TMĐT áp dụng kiến trúc Microservice" (nền tảng Latipe) của sinh viên Trần Tiến Đạt và Hồ Thái Long, dưới sự hướng dẫn của ThS. Nguyễn Hữu Trung tại Trường Đại học Sư phạm Kỹ thuật TP.HCM (HCMUTE), được triển khai nhằm giải quyết triệt để các hạn chế trên.

                  +-----------------------------------+
                  |   Client Web (React 18 + TS)      |
                  +-----------------+-----------------+
                                    |
                               (HTTP/REST)
                                    v
                  +-----------------------------------+
                  |         API Gateway (Fiber)       |
                  +-----------------+-----------------+
                                    |
         +--------------------------+--------------------------+
         | (gRPC / REST)            | (gRPC / REST)            | (REST / Internal)
         v                          v                          v
+------------------+       +------------------+       +------------------+
| User / Auth      |       | Product / Store  |       | Visual Search    |
| (Go Fiber)       |       | (Go Fiber)       |       | (FastAPI + VGG16)|
+--------+---------+       +--------+---------+       +--------+---------+
         |                          |                          |
         |                          | (Publish Events)         |
         +--------------------+     v                          |
                              |   +--------------------+       |
                              +-->| RabbitMQ Broker    |<------+
                                  +---------+----------+
                                            | (Consume Events)
                                            v
                                  +--------------------+
                                  | Order / Promotion  |
                                  | (Spring Boot 3)    |
                                  +--------------------+

Mục tiêu cụ thể của đề tài

  1. Module hóa toàn diện: Nghiên cứu và hiện thực hóa kiến trúc Microservice, phân rã toàn bộ quy trình sàn TMĐT C2C thành 15+ dịch vụ độc lập có tính gắn kết cao (high cohesion) và liên kết lỏng (loose coupling).
  2. Xây dựng Backend đa ngôn ngữ (Polyglot Microservices): Kết hợp linh hoạt giữa Go (Fiber) cho các dịch vụ đòi hỏi thông lượng cao (High Throughput) và Java (Spring Boot 3) cho các tác vụ xử lý giao dịch tài chính phức tạp.
  3. Tối ưu hóa lưu trữ phân tán (Polyglot Persistence): Phối hợp đồng thời cơ sở dữ liệu quan hệ (MySQL 8.0) cho tính toàn vẹn dữ liệu đơn hàng và NoSQL (MongoDB 6.0) cho cấu trúc dữ liệu linh hoạt của danh mục sản phẩm.
  4. Tích hợp trí tuệ nhân tạo (AI Engine) trong tìm kiếm hình ảnh: Xây dựng hệ thống CBIR (Content-Based Image Retrieval) dựa trên mạng nơ-ron tích chập (CNN) VGG16 trích xuất vector đặc trưng kết hợp khoảng cách Euclidean.
  5. Giao tiếp bất đồng bộ và điều phối tập trung: Ứng dụng hàng đợi thông điệp RabbitMQ cho mô hình Event-Driven Architecture (EDA) và API Gateway làm cổng giao tiếp duy nhất ra bên ngoài.
  6. Đóng gói và triển khai tự động: Container hóa toàn bộ hệ thống bằng Docker, xây dựng môi trường quản lý tập trung và kiểm thử hiệu năng thực tế.

Phương pháp tiếp cận và kết quả kỳ vọng

Hệ thống kết hợp phương pháp phát triển Agile/Scrum với mô hình thiết kế hướng miền (Domain-Driven Design - DDD) để phân định ranh giới ngữ cảnh (Bounded Contexts) cho từng service. Kết quả kỳ vọng đạt được là một sàn TMĐT C2C hoạt động hoàn chỉnh với thời gian phản hồi tìm kiếm hình ảnh trung bình dưới 300ms, độ chính xác nhận diện sản phẩm Top-4 đạt trên 75%, và hệ thống có khả năng tự phục hồi mà không gây downtime khi có service gặp sự cố.

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

  • Phạm vi: Hiện thực hóa trọn vẹn chu trình mua bán C2C gồm 5 tác nhân (Guest, User, Store/Vendor, Delivery Unit, Admin); tích hợp cổng thanh toán trực tuyến quốc tế (PayPal SDK) và đẩy thông báo thời gian thực (Firebase Cloud Messaging - FCM).
  • Giới hạn: Triển khai thử nghiệm trên hạ tầng máy chủ cục bộ và cụm container ảo hóa; tập dữ liệu tìm kiếm hình ảnh được kiểm thử với 289 ảnh thực nghiệm thuộc 59 nhóm sản phẩm đại diện.

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

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

Tiêu chí so sánh Kiến trúc Monolithic (PHP/Magento 2.x) Kiến trúc Microservice (Latipe Platform)
Cấu trúc mã nguồn Tập trung một repository nguyên khối, độ phụ thuộc module cao Phân tán thành 15+ repositories độc lập cho từng nghiệp vụ
Khả năng mở rộng Scale toàn bộ ứng dụng, tiêu tốn nhiều RAM/CPU Scale độc lập từng service có tải cao (Product/Search/Order)
Độ trễ công nghệ Khó cập nhật framework mới do rủi ro toàn hệ thống Tự do lựa chọn công nghệ tối ưu cho từng module (Go/Java/Python)
Khả năng chịu lỗi Một module bị crash (out-of-memory) có thể kéo sập toàn bộ sàn Cô lập lỗi hoàn toàn; lỗi ở Rating Service không ảnh hưởng Đặt hàng
Hiệu năng xử lý I/O Trung bình, chịu giới hạn bởi mô hình xử lý luồng đồng bộ Cực cao nhờ Non-blocking I/O của Go Fiber và xử lý bất đồng bộ RabbitMQ

Ưu tiên yêu cầu người dùng theo mô hình MoSCoW

+-----------------------------------------------------------------------+
|                               MoSCoW MATRIX                           |
+-----------------------------------------------------------------------+
|  MUST HAVE (Bắt buộc)          |  SHOULD HAVE (Nên có)                |
|  - Xác thực JWT & phân quyền   |  - Thông báo đẩy thời gian thực FCM  |
|  - Quản lý sản phẩm, giỏ hàng  |  - Caching dữ liệu động với Redis    |
|  - Đặt hàng & Transaction ACID |  - Lập lịch tự động (Cronjob Quarkus)|
|  - Tìm kiếm hình ảnh VGG16     |  - Rút tiền từ ví về ví PayPal       |
|  - Thanh toán PayPal & COD     |                                      |
+--------------------------------+--------------------------------------+
|  COULD HAVE (Có thể có)        |  WON'T HAVE (Chưa triển khai)        |
|  - Xuất báo cáo tài chính Excel|  - Đấu giá sản phẩm trực tuyến       |
|  - Lọc đa tiêu chí ElasticSearch| - Phát video trực tiếp (Live Stream) |
|  - Đánh giá phân loại sao      |  - Tích hợp cổng thanh toán nội địa  |
+-----------------------------------------------------------------------+

Thiết kế hệ thống

Toàn bộ hệ thống Backend được bảo vệ sau lớp API Gateway điều phối. Cấu hình định tuyến và phân loại công nghệ theo danh mục cụ thể:

  • API Gateway: Đóng vai trò Reverse Proxy, định tuyến toàn bộ request từ Client vào các microservices bên trong, thực thi Middleware xác thực token và giới hạn lưu lượng (Rate Limiting).
  • Nhóm High-Throughput Services (Ngôn ngữ Go 1.22, Framework Fiber v2):
    • User Service & Auth Service: Quản lý hồ sơ tài khoản, cấp phát Access Token và Refresh Token qua thuật toán mã hóa HMAC-SHA256 (JWT).
    • Product Service & Store Service: CRUD danh mục sản phẩm, quản lý biến thể hàng hóa, quản lý gian hàng và số dư ví điện tử.
    • Cart Service: Xử lý thêm/sửa/xóa giỏ hàng với tốc độ đọc/ghi cực nhanh.
    • Delivery Service: Quản lý thông tin đơn vị vận chuyển, tính toán cước vận chuyển theo cước phí cơ bản.
  • Nhóm Enterprise Transaction Services (Java 17, Spring Boot 3.2):
    • Order Service: Quản lý vòng đời đơn hàng (Tạo mới -> Chờ xác nhận -> Đang chuẩn bị -> Đang giao -> Đã giao -> Hoàn tất/Đã hủy).
    • Payment Service: Tích hợp REST SDK của PayPal API v2 để xử lý Authorize & Capture thanh toán và giao dịch trả hàng (Refund).
    • Promotion Service: Quản lý Voucher, kiểm tra điều kiện áp dụng mã giảm giá và ngăn chặn gian lận mã đồng thời.
  • Nhóm AI & Search Services (Python 3.10, FastAPI 0.100):
    • Visual Search Engine: Tải mô hình Pre-trained VGG16 (ImageNet), thực hiện tiền xử lý ảnh và trích xuất vector đặc trưng dạng ma trận nhị phân NumPy (.npy).
  • Hệ thống hàng đợi và dịch vụ phụ trợ:
    • RabbitMQ 3.12: Xử lý trao đổi dữ liệu phi đồng bộ (Asynchronous Messaging) theo kiến trúc Pub/Sub qua các Exchange order.topic và notification.direct.
    • Notification Service & Schedule Service (Quarkus): Lắng nghe message từ hàng đợi để kích hoạt FCM gửi thông báo và quản lý các cron job định kỳ.
                              +--------------------+
                              |    Client Web      |
                              +---------+----------+
                                        | (HTTPS/REST)
                                        v
                              +--------------------+
                              |    API Gateway     |
                              |   (Go Fiber v2)    |
                              +----+-----+----+----+
                                   |     |    |
            +----------------------+     |    +----------------------+
            | (gRPC/REST)                | (REST)                    | (REST)
            v                            v                           v
  +------------------+         +------------------+        +------------------+
  |  Product/Store   |         |   Order Engine   |        |  Visual Search   |
  |  (Go Fiber v2)   |         | (Spring Boot 3)  |        | (FastAPI+VGG16)  |
  +--------+---------+         +--------+---------+        +--------+---------+
           |                            |                           |
    (MongoDB 6.0)                  (MySQL 8.0)                (Numpy Arrays)
           |                            |                           |
           +--------------------+       |                           |
                                | (Events)                          |
                                v       v                           |
                        +-------------------------------+           |
                        |   RabbitMQ Message Broker     |<----------+
                        +---------------+---------------+
                                        | (Consume)
                                        v
                        +-------------------------------+
                        | Notification & Cron Services  |
                        +-------------------------------+

Thiết kế cơ sở dữ liệu phân tán (Polyglot Persistence)

Hệ thống loại bỏ kiến trúc Single-Database truyền thống để loại bỏ xung đột dữ liệu:

  • MySQL 8.0 (ACID Compliant): Dành riêng cho Order Service, Payment Service, Promotion Service. Đảm bảo tính toán tài chính chính xác tuyệt đối, tránh hiện tượng Race Condition khi người dùng đồng thời tranh chấp mã giảm giá hoặc trừ số lượng hàng tồn kho.
  • MongoDB 6.0 (Document Store): Dành cho Product Service (chứa các thuộc tính không đồng nhất giữa các ngành hàng: kích cỡ, màu sắc, thông số kỹ thuật) và User Service.

Mô hình tính toán tài chính và phân bổ doanh thu

Hệ thống triển khai thuật toán tính toán dòng tiền chặt chẽ theo công thức nghiệp vụ:

$$\text{Tổng giá trị đơn hàng} = \text{Tổng tiền sản phẩm} + (\text{Phí vận chuyển} - \text{Mã giảm giá vận chuyển}) - (\text{Voucher cửa hàng} + \text{Voucher hệ thống})$$

Sau khi đơn vị vận chuyển xác nhận trạng thái đơn hàng thành công, lợi nhuận được phân bổ ngay lập tức:

$$\text{Lợi nhuận cửa hàng} = \text{Tổng tiền sản phẩm} - (\text{Tổng tiền sản phẩm} \times \text{Phí sàn } 5%) - \text{Voucher cửa hàng}$$

$$\text{Lợi nhuận hệ thống} = (\text{Tổng tiền sản phẩm} \times \text{Phí sàn } 5%) - \text{Mã giảm giá vận chuyển} - \text{Mã giảm giá hệ thống}$$

$$\text{Lợi nhuận đơn vị vận chuyển} = \text{Phí vận chuyển gốc}$$

Phương pháp luận phát triển (Methodology)

Dự án áp dụng quy trình Agile/Scrum qua 5 giai đoạn chính từ ngày 04/03/2024 đến ngày 08/07/2024 (18 tuần làm việc):

  1. Giai đoạn 1 (Tuần 1 - 4): Khảo sát nghiệp vụ sàn C2C, phân tích mô hình tài chính và thiết lập kiến trúc khung Microservice.
  2. Giai đoạn 2 (Tuần 5 - 8): Xây dựng các dịch vụ nền tảng (User, Auth, API Gateway) và triển khai tích hợp cổng thanh toán PayPal.
  3. Giai đoạn 3 (Tuần 9 - 12): Nghiên cứu thuật toán CBIR, huấn luyện tiền xử lý dữ liệu với VGG16 và xây dựng API Visual Search với FastAPI.
  4. Giai đoạn 4 (Tuần 13 - 15): Phát triển giao diện người dùng bằng React 18 / TypeScript, tích hợp toàn diện thông báo qua FCM và hàng đợi RabbitMQ.
  5. Giai đoạn 5 (Tuần 16 - 18): Kiểm thử hộp đen, kiểm thử chịu tải bằng Postman Automation Test, tối ưu hóa container Docker và đóng gói báo cáo.

Hiện thực hóa và kết quả thực nghiệm

Quy trình phát triển và thuật toán cốt lõi

Trọng tâm đổi mới của hệ thống là công cụ tìm kiếm hình ảnh (CBIR Engine). Thuật toán sử dụng mạng CNN VGG16 đã loại bỏ các lớp Fully Connected (FC) phân loại cuối cùng, giữ lại lớp trích xuất vector đặc trưng không gian (Feature Embedding) với kích thước $1 \times 4096$ chiều.

import numpy as np
from tensorflow.keras.applications.vgg16 import VGG16, preprocess_input
from tensorflow.keras.preprocessing import image

# Khởi tạo mô hình VGG16 pre-trained trên ImageNet
model = VGG16(weights='imagenet', include_top=False, pooling='max')

def extract_feature_vector(img_path: str) -> np.ndarray:
    """
    Tiền xử lý ảnh và trích xuất vector đặc trưng kích thước chuẩn hóa
    """
    # Chuẩn hóa ảnh đầu vào về kích thước cố định 224x224x3
    img = image.load_img(img_path, target_size=(224, 224))
    img_array = image.img_to_array(img)
    expanded_img = np.expand_dims(img_array, axis=0)
    preprocessed_img = preprocess_input(expanded_img)
    
    # Trích xuất vector đặc trưng
    feature_vector = model.predict(preprocessed_img, verbose=0)
    normalized_vector = feature_vector.flatten() / np.linalg.norm(feature_vector.flatten())
    return normalized_vector

Khi nhận được truy vấn tìm kiếm từ người dùng, ảnh tải lên được trích xuất vector $q$ và tính toán khoảng cách Euclidean (Euclidean Distance) so với toàn bộ tập vector đặc trưng $\text{img}$ đã được đánh chỉ mục trong cơ sở dữ liệu:

$$d(q, \text{img}) = \sqrt{\sum_{i=1}^{n} (q_i - \text{img}_i)^2}$$

def search_similar_products(query_vector: np.ndarray, indexed_vectors: dict, top_k: int = 10):
    """
    So khớp vector truy vấn và trả về danh sách product_id có khoảng cách Euclidean nhỏ nhất
    """
    distances = {}
    for product_id, feat_vector in indexed_vectors.items():
        # Tính khoảng cách Euclidean
        dist = np.linalg.norm(query_vector - feat_vector)
        distances[product_id] = dist
        
    # Sắp xếp các sản phẩm có khoảng cách nhỏ nhất (độ tương đồng cao nhất)
    sorted_results = sorted(distances.items(), key=lambda item: item[1])
    return [product_id for product_id, _ in sorted_results[:top_k]]

Đánh giá và kiểm thử

Kết quả thử nghiệm công cụ tìm kiếm hình ảnh (Visual Search)

Quá trình đánh giá được thực hiện trên tập dữ liệu kiểm thử chuẩn gồm 289 hình ảnh thuộc 59 nhóm sản phẩm khác nhau. Tiêu chuẩn đánh giá: một kết quả tìm kiếm được tính là chính xác nếu product_id tương ứng xuất hiện trong 4 vị trí đầu tiên (Top-4) của danh sách 10 kết quả trả về.

+-----------------------------------------------------------------------+
|                  CBIR VISUAL SEARCH PERFORMANCE BENCHMARK             |
+-----------------------------------------------------------------------+
|  Tổng số ảnh thử nghiệm: 289 ảnh       |  Top-4 Accuracy: 77.5%       |
|  Số danh mục sản phẩm: 59 nhóm         |  Độ trễ trung bình: 268 ms   |
+----------------------------------------+------------------------------+

Độ trễ phản hồi (ms)
500ms |      * (Khởi tạo ban đầu ~480ms)
400ms |
300ms |           ------------------------- Trung bình: 250 - 300ms
200ms |    =================================
100ms |
  0ms +------------------------------------> Số lượng truy vấn thực nghiệm
  • Độ chính xác: Đạt tỷ lệ 77.5% nhận diện chính xác sản phẩm tương đồng.
  • Thời gian đáp ứng: Thời gian xử lý trung bình cho mỗi yêu cầu tìm kiếm dao động từ 250ms – 300ms (ở trạng thái bộ nhớ đã nạp sẵn model).
  • Phân tích lỗi sai: Sai số 22.5% xuất phát từ hai nguyên nhân chính:
    1. Ảnh chụp từ phía người dùng bị mờ nhòe, thiếu sáng hoặc góc chụp có quá nhiều vật thể phụ gây nhiễu.
    2. Ảnh sản phẩm gốc của cửa hàng đăng tải có góc nghiêng quá lớn làm mất đặc trưng nhận diện chính.

Kết quả kiểm thử hiệu năng hệ thống Backend

  • Kiểm thử tích hợp tự động với Postman Runner trên toàn bộ 15 microservices với hơn 120 API Endpoints đạt tỷ lệ thành công 100% (HTTP Status Code 200/201).
  • Nhờ cơ chế Non-blocking I/O của Go Fiber và chia nhỏ tải, mức tiêu thụ bộ nhớ RAM của các dịch vụ viết bằng Go chỉ dao động từ 15MB - 35MB mỗi container trong điều kiện tải bình thường, thấp hơn 80% so với việc khởi chạy toàn bộ các dịch vụ trên Java Virtual Machine (JVM).

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

  1. Ứng dụng thành công mô hình Polyglot Microservices: Khác với các đồ án thông thường chỉ sử dụng một ngôn ngữ lập trình duy nhất, Latipe kết hợp sức mạnh vượt trội của 3 hệ sinh thái:
    • Go (Fiber v2): Tối ưu hóa tối đa thông lượng đọc ghi và quản trị I/O cho các dịch vụ Product, Cart, User.
    • Java 17 (Spring Boot 3): Tận dụng tính chặt chẽ của kiểu dữ liệu và hệ sinh thái Spring Data JPA/Hibernate để bảo vệ giao dịch tiền tệ và đơn hàng.
    • Python 3.10 (FastAPI): Tận dụng các thư viện máy học hàng đầu để xây dựng bộ suy luận AI độc lập.
  2. Hiện thực hóa Visual Search trong TMĐT: Đưa mô hình Deep Learning từ lý thuyết nghiên cứu thành một dịch vụ thực tế có thể gọi qua RESTful API, cung cấp giải pháp tìm kiếm trực quan tiện lợi cho người dùng mua sắm.
  3. Phân tách cơ sở dữ liệu chuyên biệt: Loại bỏ tình trạng Deadlock và thắt nút cổ chai cơ sở dữ liệu bằng cách phân tách dữ liệu đơn hàng (MySQL) và thông tin danh mục sản phẩm phi cấu trúc (MongoDB).
  4. Cơ chế kinh doanh minh bạch: Xây dựng thuật toán tính toán và phân bổ tự động doanh thu - lợi nhuận - hoa hồng sàn 5% rõ ràng ngay khi đơn hàng hoàn thành, cho phép chủ cửa hàng rút tiền trực tiếp về tài khoản cá nhân thông qua PayPal.

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

Kịch bản vận hành thực tế

Hệ thống phục vụ trọn vẹn mô hình sàn giao dịch C2C:

  • Người mua (User): Lướt xem danh mục, chụp ảnh một mẫu đồng hồ hoặc giày dép ngoài đời thực và tải lên ứng dụng để tìm kiếm sản phẩm tương đương trên sàn, thêm vào giỏ hàng, áp dụng Voucher khuyến mãi và thanh toán qua PayPal.
  • Người bán (Store): Mở gian hàng trực tuyến, quản lý tồn kho, theo dõi biểu đồ tăng trưởng doanh thu theo tháng/năm, và tạo các chương trình Voucher riêng biệt để thu hút khách hàng.
  • Đơn vị vận chuyển (Delivery): Tiếp nhận đơn hàng sau khi cửa hàng chuẩn bị xong, cập nhật trạng thái vận chuyển theo thời gian thực (đang giao -> giao thành công).
  • Quản trị viên (Admin): Quản lý trạng thái khóa/mở tài khoản vi phạm, phê duyệt đơn vị vận chuyển, cấu hình tỷ lệ hoa hồng chiết khấu sàn và phát hành Voucher toàn sàn.
                                  +-------------------+
                                  |    Admin Portal   |
                                  +---------+---------+
                                            | (Quản trị & Phê duyệt)
                                            v
+------------------+              +-------------------+              +--------------------+
|  Người mua (User)|              |  Latipe Platform  |              |  Người bán (Store) |
|  - Tìm kiếm ảnh  |-(Đặt hàng)-> |  - Giữ tiền trung |<-(Đăng bán)- |  - Quản lý tồn kho |
|  - Thanh toán    |              |    gian & thu 5%  |              |  - Rút tiền ví     |
+------------------+              +---------+---------+              +--------------------+
                                            | (Bàn giao)
                                            v
                                  +-------------------+
                                  | Đơn vị vận chuyển |
                                  | - Giao hàng & COD |
                                  +-------------------+

Chiến lược đóng gói và triển khai

Hệ thống được đóng gói thông qua Docker và Docker Compose với cấu hình Multi-stage build nhằm giảm kích thước Docker Image:

# Dockerfile mẫu cho Go Microservice (Multi-stage build)
FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-w -s" -o main .

FROM alpine:latest
WORKDIR /root/
COPY --from=builder /app/main .
EXPOSE 8080
CMD ["./main"]

# Dockerfile mẫu cho Java Spring Boot Service
FROM maven:3.9.6-eclipse-temurin-17 AS build
WORKDIR /app
COPY pom.xml .
COPY src ./src
RUN mvn clean package -DskipTests

FROM eclipse-temurin:17-jre-alpine
WORKDIR /app
COPY --from=build /app/target/*.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

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

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

  • Kích thước mô hình AI: Mô hình VGG16 có kích thước tệp trọng số tương đối lớn (~528MB), đòi hỏi tài nguyên RAM đáng kể khi khởi động container Python.
  • Mô hình giao dịch phân tán: Chưa áp dụng toàn diện mẫu thiết kế Saga Pattern (Orchestration/Choreography) để xử lý hoàn tiền tự động (Compensating Transactions) khi có sự cố mạng phức tạp giữa nhiều cơ sở dữ liệu, mà đang dựa trên tính toàn vẹn cục bộ và cơ chế retry của RabbitMQ.
  • Tập dữ liệu chỉ mục hình ảnh: Hiện tại chỉ mới chỉ mục hóa dữ liệu mẫu, chưa tích hợp kỹ thuật Vector Search Database chuyên dụng (như Milvus hoặc Pinecone) để tìm kiếm hàng triệu vector trong thời gian thực dưới 50ms.

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

  • Nâng cấp mô hình tìm kiếm hình ảnh sang MobileNetV3 hoặc CLIP (Contrastive Language-Image Pre-training) nhằm giảm 70% dung lượng mô hình và hỗ trợ tìm kiếm kết hợp cả văn bản lẫn hình ảnh (Multimodal Search).
  • Tích hợp cơ sở dữ liệu vector chuyên dụng Milvus/Qdrant thay thế cho việc tính toán khoảng cách tuần tự trên mảng NumPy.
  • Triển khai hệ thống lên cụm Kubernetes (K8s) với cấu hình Horizontal Pod Autoscaler (HPA), kết hợp giám sát chủ động bằng Prometheus và Grafana.

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

+-----------------------------------------------------------------------------------+
|                            BẢNG ĐỐI TƯỢNG HƯỞNG LỢI                               |
+-------------------+---------------------------------------------------------------+
| Đối tượng         | Giá trị thực tiễn mang lại                                    |
+-------------------+---------------------------------------------------------------+
| Sinh viên CNTT    | - Tài liệu tham khảo chuẩn mực về kiến trúc Microservice.      |
|                   | - Hướng dẫn chi tiết cách tích hợp AI Inference vào Backend.  |
+-------------------+---------------------------------------------------------------+
| Lập trình viên    | - Mô hình phân chia Polyglot (Go + Java + Python) chuẩn hóa.  |
|                   | - Bộ mẫu Dockerfile Multi-stage tối ưu dung lượng triển khai. |
+-------------------+---------------------------------------------------------------+
| Doanh nghiệp TMĐT | - Kiến trúc tham chiếu có thể mở rộng với chi phí thấp.       |
|                   | - Giải pháp Visual Search gia tăng tỷ lệ chuyển đổi đơn hàng. |
+-------------------+---------------------------------------------------------------+
| Nhà nghiên cứu    | - Dữ liệu thực nghiệm về độ chính xác và độ trễ của mạng CBIR.|
+-------------------+---------------------------------------------------------------+

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

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

Để khởi chạy đồng thời 15 microservices kèm theo các cơ sở dữ liệu và công cụ phụ trợ (MySQL, MongoDB, Redis, RabbitMQ, Docker), máy chủ thử nghiệm cần tối thiểu 4 Cores CPU, 8GB RAM (khuyến nghị 16GB RAM) và 30GB dung lượng ổ cứng khả dụng chạy trên hệ điều hành Linux (Ubuntu 20.04/22.04 LTS) hoặc macOS/Windows có cài đặt Docker Engine và Docker Compose.

2. Hệ thống giải quyết bài toán nghẽn cổ chai (Bottleneck) tại API Gateway như thế nào?

API Gateway được phát triển bằng Go Fiber (dựa trên bộ nhân fasthttp tối ưu bộ nhớ), cho phép tiếp nhận hàng chục nghìn kết nối đồng thời với mức tiêu tốn tài nguyên cực thấp. Ngoài ra, API Gateway có thể dễ dàng nhân bản thành nhiều instances đứng sau bộ cân bằng tải vòng tròn (Nginx Load Balancer hoặc AWS ALB).

3. Tại sao hệ thống lại kết hợp cả MySQL và MongoDB thay vì dùng một cơ sở dữ liệu duy nhất?

Mỗi loại cơ sở dữ liệu giải quyết một bài toán riêng biệt:

  • MySQL đảm bảo tính chất ACID (Atomicity, Consistency, Isolation, Durability) tuyệt đối cho đơn hàng và tiền tệ, tránh tình trạng mất mát dữ liệu tài chính.
  • MongoDB với cấu trúc Document linh hoạt không cố định Schema, rất lý tưởng để lưu trữ các thông tin sản phẩm đa dạng thuộc tính (quần áo có size/màu, điện thoại có RAM/ROM/Chip).

4. Tìm kiếm hình ảnh bằng VGG16 có thể mở rộng khi số lượng sản phẩm lên đến hàng triệu không?

Trong phạm vi đồ án, tính toán khoảng cách Euclidean bằng NumPy đáp ứng rất tốt cho tập dữ liệu vài chục nghìn sản phẩm. Khi quy mô tăng lên hàng triệu sản phẩm, giải pháp mở rộng là đẩy toàn bộ vector đặc trưng vào các cơ sở dữ liệu vector chuyên dụng (như Milvus, Faiss, hoặc Elasticsearch Dense Vector), kết hợp thuật toán phân vùng HNSW (Hierarchical Navigable Small World) để giảm độ phức tạp tìm kiếm từ $O(N)$ xuống $O(\log N)$.

5. Cơ chế xử lý khi một Microservice gặp sự cố trong quá trình giao dịch là gì?

Khi một service thứ cấp gặp lỗi, API Gateway và các service liên quan áp dụng mẫu thiết kế Circuit Breaker để ngắt luồng gọi lỗi tạm thời và trả về thông báo lỗi chuẩn xác. Đối với các tác vụ không đồng bộ (như tạo thông báo, gửi email), thông điệp được lưu giữ an toàn trong hàng đợi RabbitMQ và sẽ được tự động gửi lại (Retry mechanism) ngay khi service đích phục hồi.

Kết luận

Đồ án tốt nghiệp "Xây dựng hệ thống TMĐT áp dụng kiến trúc Microservice" của sinh viên Trần Tiến Đạt và Hồ Thái Long đã hiện thực hóa thành công một nền tảng thương mại điện tử hiện đại, giải quyết trọn vẹn bài toán mở rộng quy mô và nâng cao trải nghiệm mua sắm thông qua công nghệ trí tuệ nhân tạo.

Những đóng góp trọng tâm của đề tài bao gồm:

  • Hoàn thiện kiến trúc Microservice phân tán: Xây dựng thành công 15+ dịch vụ vận hành mượt mà với mô hình Polyglot kết hợp Go Fiber, Java Spring Boot và Python FastAPI.
  • Tích hợp giải pháp AI đột phá: Đưa mô hình thị giác máy tính CBIR VGG16 vào ứng dụng thực tế với độ chính xác đạt 77.5% và thời gian phản hồi nhanh chóng dưới 300ms.
  • Đảm bảo tính toàn vẹn kinh doanh: Xây dựng cơ chế tính toán doanh thu, dòng tiền, chiết khấu hoa hồng 5% và thanh toán quốc tế PayPal an toàn, chuẩn mực.

Đây là tài liệu tham khảo kỹ thuật giá trị cho sinh viên, kỹ sư phần mềm và các nhóm khởi nghiệp đang tìm kiếm giải pháp xây dựng các hệ thống phân tán hiệu năng cao, mở ra hướng ứng dụng sâu rộng của trí tuệ nhân tạo trong lĩnh vực thương mại số tương lai.