1. Giới thiệu
Multi-tenancy (đa thuê bao) là một kiến trúc phần mềm cho phép một hệ thống duy nhất phục vụ nhiều khách hàng (tenant), nhưng mỗi tenant vẫn có dữ liệu và cấu hình riêng biệt.
Giống như một tòa chung cư. Thay vì mỗi người phải tự xây một ngôi nhà riêng (tốn kém, khó quản lý), mọi người cùng sống trong một tòa nhà, dùng chung hệ thống điện, nước, thang máy, nhưng mỗi căn hộ vẫn có chìa khóa riêng và sự riêng tư tuyệt đối.
Hiểu đơn giản:
- Một app → nhiều khách hàng dùng chung
- Nhưng mỗi khách hàng không nhìn thấy dữ liệu của nhau
Ví dụ thực tế:
- SaaS như CRM, ERP
- Ứng dụng quản lý bán hàng cho nhiều cửa hàng
2. Tenant là gì?
Tenant = một khách hàng / tổ chức sử dụng hệ thống
Ví dụ:
- Tenant A: Công ty ABC
- Tenant B: Công ty XYZ
Dù cùng dùng 1 hệ thống, nhưng:
- User khác nhau
- Data khác nhau
- Có thể config khác nhau
Trong mô hình này:
-
Dữ liệu: Dữ liệu của mỗi khách hàng được cách ly và bảo mật, dù nằm chung trên một hạ tầng.
-
Tài nguyên: Các khách hàng dùng chung tài nguyên hệ thống như CPU, RAM, Database và mã nguồn.
-
Cấu hình: Mỗi khách hàng có thể tùy chỉnh một số giao diện hoặc tính năng riêng mà không ảnh hưởng đến người khác.
3. Các mô hình Multi-tenancy phổ biến
Tùy vào yêu cầu về bảo mật và hiệu năng, người ta thường chia làm 3 cấp độ ở tầng cơ sở dữ liệu (Database):
3.1. Shared Application, Shared Database, Shared Schema (Dùng chung tất cả)
Tất cả khách hàng ở chung trong một Database và các bảng (Table). Để phân biệt, người ta dùng một cột gọi là TenantID.
|
1 2 3 4 |
users - id - name - tenant_id |
Ưu điểm:
- Dễ triển khai
- Tiết kiệm tài nguyên
- Scale tốt
Nhược điểm:
- Dễ query nhầm nếu quên
tenant_id - Khó tách riêng khi cần
3.2. Shared Application, Shared Database, Separate Schema (Schema riêng biệt)
Cùng database, nhưng mỗi tenant có schema riêng
|
1 2 |
tenant_1.users tenant_2.users |
Ưu điểm:
- Cách ly dữ liệu tốt hơn
Nhược điểm:
- Quản lý phức tạp hơn
- Migration khó hơn
3.3. Shared Application, Separate Database (Cơ sở dữ liệu riêng biệt)
Mỗi tenant có DB riêng
|
1 2 |
db_tenant_1 db_tenant_2 |
Ưu điểm:
- Bảo mật cao nhất
- Dễ backup/restore riêng
Nhược điểm:
- Tốn tài nguyên
- Khó scale khi có nhiều tenant
4. So sánh nhanh
| Mô hình | Độ phức tạp | Bảo mật | Scale |
|---|---|---|---|
| Shared table | ⭐ | ⭐ | ⭐⭐⭐ |
| Schema | ⭐⭐ | ⭐⭐ | ⭐⭐ |
| Separate DB | ⭐⭐⭐ | ⭐⭐⭐ | ⭐ |
5. Multi-tenancy hoạt động như thế nào?
Flow cơ bản:
- User gửi request
- System xác định tenant (dựa vào domain / token / user)
- Set context tenant
- Query data theo tenant
6. Tại sao Multi-tenancy lại quan trọng?
Nếu bạn đang xây dựng một sản phẩm SaaS (như Slack, Salesforce, hay Microsoft 365), Multi-tenancy là lựa chọn gần như bắt buộc vì những lý do sau:
-
Tiết kiệm chi phí (Cost Efficiency): Thay vì phải trả tiền cho 100 server cho 100 khách hàng, bạn chỉ cần một vài server mạnh để gánh tất cả.
-
Bảo trì dễ dàng: Khi cần cập nhật tính năng mới hoặc vá lỗi, bạn chỉ cần cập nhật một lần duy nhất trên server chính. Tất cả khách hàng sẽ nhận được bản cập nhật ngay lập tức.
-
Khả năng mở rộng (Scalability): Việc thêm một khách hàng mới chỉ đơn giản là tạo thêm một bản ghi trong hệ thống, không cần thiết lập hạ tầng mới từ đầu.
7. Khi nào nên dùng Multi-tenancy?
NÊN dùng khi:
- Làm SaaS
- Nhiều khách hàng dùng chung hệ thống
- Muốn tiết kiệm chi phí hạ tầng
KHÔNG nên nếu:
- Chỉ có 1 khách hàng
- Yêu cầu bảo mật cực cao (nên tách DB)
8. Những thách thức cần đối mặt
Dù có nhiều ưu điểm, nhưng “sống chung” thì cũng có những rắc rối riêng:
-
Vấn đề “Hàng xóm ồn ào” (Noisy Neighbor): Nếu một khách hàng bỗng dưng sử dụng quá nhiều tài nguyên (ví dụ chạy báo cáo nặng), nó có thể làm chậm hệ thống của tất cả các khách hàng khác.
-
Rủi ro bảo mật: Chỉ cần một lỗ hổng nhỏ trong việc phân quyền, dữ liệu của công ty A có thể bị công ty B nhìn thấy. Đây là “cơn ác mộng” lớn nhất của kiến trúc này.
-
Khó khăn khi tùy biến sâu: Vì dùng chung mã nguồn, bạn rất khó để sửa code riêng theo ý muốn “oái oăm” của chỉ một khách hàng duy nhất.
9. Kết luận
Multi-tenancy không chỉ là một kỹ thuật lập trình, mà là một mô hình kinh doanh. Nó cho phép các nhà phát triển phần mềm cung cấp dịch vụ chất lượng cao với giá thành rẻ hơn.
Lời khuyên: Nếu dự án của bạn ưu tiên tốc độ tăng trưởng và tối ưu chi phí, hãy chọn Shared Schema. Nếu bạn làm cho các tập đoàn lớn hoặc ngân hàng yêu cầu bảo mật cực cao, hãy cân nhắc Separate Database.
