Bài 5a. Dựa trên URS ứng dụng của bạn (nhóm), hãy phân tích và thiết kế theo kiến trúc 3-tầng. Bạn có thể tự phân tích, thiết kế hoặc nhờ sự hỗ trợ của chatbot.
Bài 5b. Dựa trên URS ứng dụng của bạn (nhóm), hãy phân tích và thiết kế theo kiến trúc vi dịch vụ. Bạn có thể tự phân tích, thiết kế hoặc nhờ sự hỗ trợ của chatbot.
[Gợi ý làm bài tập]
Bài 5a. Dựa trên URS ứng dụng của bạn (nhóm), hãy phân tích và thiết kế theo kiến trúc 3-tầng. Bạn có thể tự phân tích, thiết kế hoặc nhờ sự hỗ trợ của chatbot.
[Tham khảo giải pháp của chatbot]
Dựa trên URS chi tiết của "Hệ thống bán sách trực tuyến", thực hiện phân tích và thiết kế kiến trúc hệ thống theo mô hình 3-tầng. Đây là một kiến trúc tiêu chuẩn, giúp tăng cường khả năng mở rộng, bảo trì và tách biệt trách nhiệm rõ ràng cho từng phần của hệ thống.
1. Phân tích tương quan URS và kiến trúc 3-tầng
Kiến trúc 3-tầng phân chia hệ thống thành ba lớp logic độc lập: tầng Trình bày (presentation tier), tầng Logic ứng dụng/Nghiệp vụ (application/business logic tier), và tầng Dữ liệu (data tier).
2. Thiết kế theo kiến trúc 3-tầng
Tầng Trình bày (presentation tier)
Đây là giao diện mà người dùng cuối tương tác. Nó chỉ chịu trách nhiệm hiển thị và thu thập dữ liệu từ người dùng, sau đó chuyển giao cho tầng Nghiệp vụ.
- Công nghệ đề xuất:
+ Frontend framework: React, Vue.js, hoặc Angular (để xây dựng SPA - Single Page Application, tối ưu tốc độ tải trang theo NFR-1.1)
+ Ngôn ngữ: HTML5, CSS3, JavaScript
+ Thiết kế: responsive design (tuân thủ NFR-2.2 - Tương thích đa nền tảng)
- Các module/màn hình chính:
+ Trang Khách hàng (FR-1.1, FR-1.2, FR-1.4, FR-1.5): Đăng ký/Đăng nhập, Quản lý hồ sơ, Lịch sử đơn hàng
+ Trang Sản phẩm (FR-2.1, FR-2.2, FR-2.3, FR-2.4): Thanh tìm kiếm, Bộ lọc (thể loại, giá), Danh sách kết quả, Trang chi tiết sách (bao gồm hiển thị đánh giá FR-4.2)
+ Luồng Giao dịch (FR-3.1, FR-3.2, FR-3.3, FR-3.4): Giỏ hàng, trang Thanh toán (lựa chọn phương thức thanh toán trực tuyến)
Tầng Nghiệp vụ (application/business logic tier)
Đây là "bộ não" của hệ thống, nơi xử lý tất cả các quy tắc kinh doanh và logic nghiệp vụ cốt lõi. Tầng này nhận yêu cầu từ tầng Trình bày, xử lý logic, và giao tiếp với tầng Dữ liệu.
- Công nghệ đề xuất:
+ Ngôn ngữ backend/framework: Java (Spring Boot), Python (Django/Flask), hoặc Node.js (Express). Các Framework này có hiệu suất tốt và khả năng mở rộng (NFR-5.1, NFR-5.2)
+ Kiến trúc: Sử dụng Microservices hoặc kiến trúc Monolithic Modular (cho giai đoạn đầu) để dễ dàng mở rộng và tích hợp tính năng mới.
- Các Service/Logic xử lý chính:
+ User Service (FR-1.x): Xử lý xác thực người dùng (FR-1.2), Đặt lại mật khẩu (FR-1.3), Cập nhật thông tin
+ Catalog Service (FR-2.x): Chức năng tìm kiếm/Lọc sản phẩm (theo tác giả, thể loại, giá), Xây dựng dịch vụ truy vấn dữ liệu
+ Order & Payment Service (FR-3.x, Yêu cầu nghiệp vụ):
* Tính toán tổng tiền giỏ hàng (FR-3.3), Tính toán Thuế và Phí vận chuyển
* Xử lý đặt hàng: gọi đến tầng Dữ liệu để trừ tồn kho (logic nghiệp vụ)
* Tích hợp cổng Thanh toán (payment gateway) bên ngoài (FR-3.4) và đảm bảo bảo mật giao dịch (NFR-3.2)
* Gửi Email xác nhận đơn hàng (FR-3.5)
+ Inventory Service (Yêu cầu nghiệp vụ): Quản lý tồn kho, Thực hiện logic trừ tồn kho sau khi đơn hàng thành công, Gửi thông báo cảnh báo tồn kho thấp
+ Review Service (FR-4.x): Xử lý việc nhận và lưu trữ Đánh giá/Xếp hạng của người dùng đã mua sách
Tầng Dữ liệu (data tier)
Tầng này chịu trách nhiệm lưu trữ dữ liệu, quản lý truy cập và đảm bảo tính toàn vẹn, bảo mật.
- Công nghệ đề xuất:
+ Cơ sở dữ liệu chính: PostgreSQL hoặc MySQL (relational database) để lưu trữ dữ liệu có cấu trúc và quan hệ chặt chẽ (Thông tin người dùng, Đơn hàng, Kho sách, Chi tiết sản phẩm)
+ Cơ sở dữ liệu phụ/Cache: Redis/Memcached để lưu trữ các dữ liệu thường xuyên được truy cập (Tồn kho, Dữ liệu phiên người dùng, Kết quả tìm kiếm - nhằm đáp ứng tốc độ phản hồi NFR-1.2)
- Các bảng dữ liệu chính:
+ Users: Lưu trữ thông tin cá nhân và mật khẩu đã mã hóa (NFR-3.1)
+ Books: Thông tin chi tiết sách (tiêu đề, tác giả, NXB, giá)\
+ Orders: Trạng thái đơn hàng, chi tiết sản phẩm đã mua, địa chỉ giao hàng
+ Reviews & Ratings: Đánh giá của khách hàng
- Yêu cầu kỹ thuật:
+ Sử dụng ORM (Object-Relational Mapping) để truy vấn dữ liệu an toàn, giảm thiểu rủi ro SQL Injection (NFR-3.3)
+ Triển khai cơ chế sao lưu dữ liệu hàng ngày (NFR-4.2)
Đánh giá hệ thống đã thiết kế
Việc áp dụng kiến trúc 3-tầng có nhiều ưu điểm, đặc biệt đáp ứng các NFR quan trọng:
- Khả năng mở rộng (scalability - NFR-5.1, NFR-5.2): Ba tầng có thể được mở rộng độc lập. Ví dụ, nếu lượng người dùng tăng cao (áp lực lên NFR-1.3), chỉ cần thêm các máy chủ cho tầng Nghiệp vụ mà không cần thay đổi tầng Dữ liệu
- Hiệu suất (performance - NFR-1.1, NFR-1.2): Việc tách biệt logic nghiệp vụ giúp tối ưu hóa hiệu suất từng phần, đồng thời sử dụng cache (tầng Dữ liệu) giúp tăng tốc độ phản hồi
- Bảo mật (security - NFR-3.x): Tầng Nghiệp vụ đóng vai trò là "cổng kiểm soát", bảo vệ tầng Dữ liệu khỏi việc truy cập trực tiếp từ tầng Trình bày/Người dùng
- Dễ bảo trì và Phát triển: Khi cần thay đổi logic nghiệp vụ (ví dụ: thay đổi cách tính phí vận chuyển), ta chỉ cần tập trung vào tầng Nghiệp vụ mà không ảnh hưởng đến tầng Trình bày
Bài 5b. Dựa trên URS ứng dụng của bạn (nhóm), hãy phân tích và thiết kế theo kiến trúc vi dịch vụ. Bạn có thể tự phân tích, thiết kế hoặc nhờ sự hỗ trợ của chatbot.
[Tham khảo giải pháp của chatbot]
Kiến trúc microservice sẽ chia hệ thống lớn thành các dịch vụ nhỏ, độc lập, giao tiếp với nhau qua API. Mỗi dịch vụ sẽ tập trung vào một nghiệp vụ cụ thể.
1. Phân tích và chia tách dịch vụ (service decomposition)
Dựa trên các nhóm Yêu cầu chức năng (FR) và Yêu cầu nghiệp vụ trong URS, chúng ta sẽ chia hệ thống thành các vi dịch vụ cốt lõi sau:
2. Thiết kế kiến trúc vi dịch vụ (microservices architecture design)
2.1. Cấu trúc và giao tiếp
Kiến trúc sẽ bao gồm các thành phần chính sau:
- Client (tầng Trình bày): Giao diện người dùng (React/Vue/Angular) truy cập hệ thống
- API Gateway:
+ Điểm truy cập duy nhất cho tất cả các yêu cầu từ client
+ Thực hiện chuyển hướng (routing) yêu cầu đến các dịch vụ phù hợp
+ Đảm nhận các chức năng như xác thực cơ bản, cân bằng tải
+ Giúp đáp ứng NFR-1.3 (khả năng chịu tải) bằng cách phân phối yêu cầu
- Vi dịch vụ (microservices): Các dịch vụ độc lập như đã phân tích ở trên
+ Giao tiếp chính thức: Sử dụng RESTful API (HTTP/JSON) cho các tương tác đồng bộ (ví dụ: Catalog gọi Inventory để kiểm tra tồn kho)
+ Giao tiếp phi đồng bộ: Sử dụng Message Broker (Kafka/RabbitMQ) cho các sự kiện (ví dụ: Order Service gửi sự kiện "Order Placed" tới Inventory Service để trừ tồn kho và Notification Service để gửi email)
2.2. Quản lý dữ liệu (database per service)
Để đảm bảo tính độc lập (decoupling) của các dịch vụ và tối ưu hóa hiệu suất (NFR-1.2, NFR-5.1), mỗi dịch vụ nên có cơ sở dữ liệu (CSDL) riêng:
2.3. Khả năng mở rộng và độ tin cậy (NFRs)
- Khả năng mở rộng (NFR-5.1, NFR-5.2):
+ Mỗi dịch vụ có thể được triển khai độc lập và mở rộng quy mô (scale) riêng biệt (ví dụ: chỉ cần tăng số lượng thể hiện (instance) của Catalog Service nếu lượng tìm kiếm tăng cao)
+ Việc thêm tính năng mới (ví dụ: Hệ thống tích điểm thưởng) chỉ cần tạo một dịch vụ mới (Loyalty Service) mà không ảnh hưởng đến các dịch vụ hiện có
- Độ tin cậy (NFR-4.1):
+ Tách biệt lỗi: Nếu một dịch vụ (ví dụ: Review Service) gặp sự cố, các dịch vụ cốt lõi (Catalog, Order) vẫn có thể hoạt động (giảm thiểu rủi ro ngừng hoạt động tổng thể)
+ Sử dụng Circuit Breaker để ngăn chặn lỗi lan truyền và tăng độ ổn định hệ thống
- Hiệu suất (NFR-1.2):
+ Mỗi dịch vụ có thể chọn ngôn ngữ và công nghệ tối ưu nhất cho nghiệp vụ của mình (ví dụ: Go/Rust cho Catalog Service để tối ưu tốc độ tìm kiếm)
+ Sử dụng Distributed Caching (Redis) để tăng tốc truy xuất dữ liệu dùng chung
3. Thách thức và giải pháp
Kiến trúc vi dịch vụ này không chỉ đáp ứng các yêu cầu hiện tại mà còn chuẩn bị cho sự phát triển và mở rộng quy mô lớn trong tương lai của Hệ thống bán sách trực tuyến.