Nền tảng Thiết kế Hệ thống và Các Đánh đổi Cốt lõi

Trong công trình kinh điển "Scalability, Availability & Stability Patterns", Jonas Bonér (tác giả nền tảng Akka) đã xác lập hệ quy chiếu lý thuyết chặt chẽ nhằm giải quyết bài toán trọng tâm: quản lý quá tải (managing overload) khi hệ thống chuyển dịch từ máy chủ đơn lẻ sang cụm phân tán quy mô lớn.

Trước khi áp dụng bất kỳ mẫu thiết kế nào, kiến trúc sư phải tuân thủ các nguyên lý tiên đề:

• Đo lường mọi thông số vận hành: Không thể tối ưu hóa những điểm nghẽn chưa được định lượng bằng số liệu.
• Ưu tiên tính bất biến (Immutability): Dữ liệu bất biến loại bỏ hoàn toàn tranh chấp trạng thái và khóa đồng bộ.
• Tính minh bạch tham chiếu & Laziness: Tận dụng các nguyên lý lập trình hàm để hoãn tính toán và tái sử dụng kết quả.
• Phân loại bản chất tập dữ liệu: Mỗi phân hệ dữ liệu đòi hỏi cấp độ nhất quán khác nhau — xem thêm Định lý CAP, Mô hình ACID và BASE.

Sự tiến hóa của bất kỳ hệ thống nào cũng bắt đầu từ quyết định kiến trúc giữa mở rộng theo chiều dọc và mở rộng theo chiều ngang:

Để chẩn đoán chính xác triệu chứng kỹ thuật, kiến trúc sư cần phân định rõ ba cặp đánh đổi chi phối toàn bộ không gian thiết kế:

Khi các thành phần trong hệ thống giao tiếp qua hàng đợi bất đồng bộ, mối quan hệ giữa lưu lượng, kích thước hàng đợi và độ trễ tuân theo Định luật Little (Little's Law):

# Mô phỏng lý thuyết hàng đợi (M/M/1 Queue)
# λ = Arrival Rate, μ = Service Rate
def calculate_queue_metrics(lambd, mu):
    if lambd >= mu:
        raise ValueError("Overload: Hàng đợi sẽ bùng nổ vô hạn (Latency -> Infinity)")
    
    # Hệ số sử dụng tài nguyên (Utilization)
    rho = lambd / mu
    
    # Số lượng tác vụ trung bình trong hệ thống (Little's Law: L = λ * W)
    L = rho / (1 - rho)
    
    # Thời gian phản hồi trung bình (Total Latency)
    W = 1 / (mu - lambd)
    
    # Thời gian chờ đợi trong hàng đợi
    W_q = rho / (mu - lambd)
    
    return {"utilization": rho, "avg_tasks": L, "latency": W, "queue_wait": W_q}

# Ví dụ: Năng lực xử lý 100 req/s, tải đến 95 req/s (rho = 0.95)
# Độ trễ tăng vọt gấp 20 lần so với lúc tải thấp (rho = 0.1)

Khi chuyển dịch sang kiến trúc phân tán, kỹ sư bắt buộc phải bác bỏ 8 Ngộ nhận Phổ biến (Universal Fallacies of Distributed Computing):

1. Mạng luôn đáng tin cậy: Gói tin luôn có thể bị thất lạc, gián đoạn.
2. Độ trễ bằng không: Độ trễ qua mạng vật lý luôn lớn hơn truy cập bộ nhớ cục bộ hàng nghìn lần.
3. Băng thông là vô hạn: Dữ liệu truyền qua mạng có giới hạn thông lượng.
4. Mạng an toàn tuyệt đối: Mọi ranh giới liên mạng đều tiềm ẩn nguy cơ bảo mật.
5. Cấu trúc liên kết mạng không đổi: Các node có thể gia nhập hoặc rời mạng bất kỳ lúc nào.
6. Chỉ có một quản trị viên duy nhất: Các phân hệ thường do nhiều nhóm vận hành quản lý độc lập.
7. Chi phí truyền tải bằng không: Quá trình serialization/deserialization tiêu tốn đáng kể chu kỳ CPU.
8. Mạng là đồng nhất: Thiết bị, hệ điều hành và giao thức truyền thông trong cụm rất đa dạng.

Các mẫu thiết kế giải quyết các bài toán cụ thể tiếp theo trong hệ thống phân tán:

• Định lý CAP, Mô hình ACID và BASE — Khung lý thuyết nhất quán dữ liệu và toán học Quorum.
• Các Mô hình và Topo Sao chép Dữ liệu — Topo Master-Slave, Multi-Master, Buddy và kịch bản khôi phục thảm họa.
• Các Chiến lược Bộ nhớ Đệm Phân tán — Cache-Aside, Write-Through, Write-Behind và chính sách vô hiệu hóa.
• Phân mảnh RDBMS, DHT và Hệ sinh thái NoSQL — Kỹ thuật Sharding, Consistent Hashing và các họ NoSQL.
• Kiến trúc Hướng sự kiện (EDA) và SEDA — Tách biệt hành vi, cân bằng tải và mô hình đồng thời.
• Các Mẫu Thiết kế Độ Ổn định Hệ thống — Circuit Breaker, Bulkheads, Let-It-Crash và Backpressure.