Kiến trúc hệ thốngKhả năng mở rộng cho người mới - Phần 1: Bản sao (Clones)

Khả năng mở rộng cho người mới - Phần 1: Bản sao (Clones)

Nội dung bài

Khả năng mở rộng cho người mới - Phần 1: Bản sao (Clones)

Nền tảng5 phút đọcLe Cloud Blog - Scalability for Dummies, Part 1

Mục lục
  1. Load balancer đứng trước cụm server
  2. Quy tắc vàng đầu tiên
  3. Session phải để ở đâu
  4. Còn triển khai (deployment) thì sao?
  5. Nhân bản server bằng image
  6. Ghi chú của người dịch (2026)

Khả năng mở rộng cho người mới - Phần 1: Bản sao (Clones)

Lời mở đầu của tác giả: Gần đây tôi được hỏi cần những gì để làm một web service có khả năng mở rộng ở quy mô cực lớn. Câu trả lời của tôi khá dài, và có lẽ cũng hữu ích cho người khác. Nên tôi chia sẻ ở đây trên blog, tách thành nhiều phần cho dễ đọc. Các phần mới sẽ ra đều đặn. Chúc vui, và luôn hoan nghênh bình luận của bạn!

Load balancer đứng trước cụm server

Các server công khai (public server) của một web service có khả năng mở rộng đều nằm ẩn sau một load balancer (bộ cân bằng tải). Load balancer này phân phối tải - tức là các request từ người dùng của bạn - một cách đều đặn lên cả nhóm/cụm (cluster) application server.

Nghĩa là, ví dụ người dùng Steve tương tác với dịch vụ của bạn: request đầu tiên của anh ta có thể được server 2 phục vụ, request thứ hai lại do server 9 phục vụ, rồi request thứ ba có khi lại quay về server 2.

Quy tắc vàng đầu tiên

Steve phải luôn nhận về cùng một kết quả cho request của mình, bất kể anh ta "đáp xuống" server nào. Điều đó dẫn tới quy tắc vàng đầu tiên của khả năng mở rộng:

Mọi server phải chứa chính xác cùng một codebase, và không được lưu bất kỳ dữ liệu nào liên quan đến người dùng - như session hay ảnh đại diện - trên ổ đĩa hoặc bộ nhớ cục bộ của chính nó.

Cùng một client, nhiều server khác nhau, nhưng dùng chung một kho session Steve LB Server A Server B Server C Session store dùng chung (Redis / DB, nằm ngoài mọi server)
Steve có thể đáp xuống Server A, B hay C tùy request — vì không server nào giữ session cục bộ, kết quả vẫn nhất quán nhờ kho session dùng chung.

Session phải để ở đâu

Session cần được lưu trong một kho dữ liệu tập trung (centralized data store) mà tất cả application server đều truy cập được. Kho đó có thể là một database bên ngoài, hoặc một persistent cache bên ngoài như Redis. Một persistent cache bên ngoài sẽ cho hiệu năng tốt hơn database bên ngoài.

"Bên ngoài" (external) ở đây nghĩa là: kho dữ liệu đó không nằm trên chính các application server. Thay vào đó, nó nằm đâu đó bên trong hoặc gần với data center chứa các application server của bạn.

Còn triển khai (deployment) thì sao?

Làm sao đảm bảo một thay đổi code được đẩy tới tất cả server, không để sót server nào vẫn còn chạy code cũ?

Vấn đề hóc búa này may thay đã được giải quyết bởi một công cụ rất tốt là Capistrano. Nó đòi hỏi bạn phải học một chút, nhất là nếu bạn không làm Ruby on Rails, nhưng chắc chắn đáng công sức bỏ ra.

Nhân bản server bằng image

Sau khi đã "đưa session ra ngoài" và phục vụ cùng một codebase từ mọi server, giờ bạn có thể tạo một image file từ một trong các server đó. AWS gọi cái này là AMI (Amazon Machine Image).

Dùng AMI này làm một "siêu bản sao" (super-clone) làm nền cho mọi instance mới. Mỗi khi khởi chạy một instance/clone mới, chỉ cần deploy code mới nhất lần đầu là xong, sẵn sàng chạy!


Nguồn: Le Cloud Blog - Scalability for Dummies, Part 1 — Sebastian Kreutzberger

Giấy phép: CC BY 4.0 (nguyên bản: Donne Martin, The System Design Primer)

Xem bản gốc

Bài tiếp theoKhả năng mở rộng cho người mới - Phần 2: Cơ sở dữ liệu (Database)