Ứng dụng n tầng là những ứng dụng có nhiều hơn ba thành phần (UI, backend server, database) tham gia vào kiến trúc hệ thống.
Vậy các thành phần đó là gì?
- Cache
- Message queue phục vụ xử lý bất đồng bộ
- Load balancer
- Search server dùng để tìm kiếm trên khối lượng dữ liệu lớn
- Các thành phần xử lý dữ liệu lớn (big data processing)
- Các thành phần chạy trên công nghệ dị thể, thường được gọi là web services, microservices, v.v.
Tất cả các ứng dụng mạng xã hội như Instagram, Facebook, TikTok, các dịch vụ tiêu dùng quy mô lớn như Uber, Airbnb, hay game online nhiều người chơi quy mô lớn như Pokémon Go, Roblox, … đều là ứng dụng n tầng.
Ứng dụng n tầng thường được gọi chung là hệ thống phân tán (distributed systems).
What’s the need for so many tiers?
Hai nguyên lý thiết kế phần mềm quan trọng giúp giải thích điều này là:
- Single Responsibility Principle (nguyên lý đơn trách nhiệm)
- Separation of Concerns (nguyên lý phân tách mối quan tâm)
Hãy cùng tìm hiểu từng nguyên lý.
1. Single Responsibility Principle
Nguyên lý đơn trách nhiệm có nghĩa là giao cho mỗi thành phần một trách nhiệm duy nhất và để nó thực hiện thật tốt nhiệm vụ đó, dù là lưu trữ dữ liệu, xử lý logic ứng dụng, hay đảm bảo việc truyền tải thông điệp trong hệ thống.
Cách tiếp cận này mang lại tính linh hoạt cao, giúp việc quản lý trở nên dễ dàng hơn. Chúng ta có thể có các team riêng và repository riêng cho từng thành phần, giúp hệ thống gọn gàng và rõ ràng hơn.
Khi áp dụng nguyên lý đơn trách nhiệm, các thành phần được liên kết lỏng lẻo (loosely coupled) về mặt chức năng. Thay đổi ở một thành phần sẽ không ảnh hưởng tới các thành phần khác.
Ví dụ: nâng cấp hệ điều hành hoặc vá lỗi cho database server sẽ không ảnh hưởng tới các service khác. Ngay cả khi xảy ra sự cố trong quá trình cài đặt OS, chỉ database bị down, hệ thống tổng thể vẫn hoạt động, và chỉ những tính năng phụ thuộc database mới bị ảnh hưởng.
Chính vì lý do này mà tôi không bao giờ ủng hộ việc sử dụng stored procedure.
Stored procedure cho phép đưa business logic vào database, và điều này luôn là một lựa chọn tệ. Giả sử trong tương lai, chúng ta muốn chuyển sang một hệ quản trị cơ sở dữ liệu khác, thì business logic sẽ được xử lý thế nào?
- Đưa toàn bộ logic sang database mới?
- Hay refactor lại code application để nhét logic của stored procedure vào?
Database không nên chứa business logic. Nhiệm vụ duy nhất của database là lưu trữ dữ liệu. Đây chính là tinh thần cốt lõi của nguyên lý đơn trách nhiệm, và cũng là lý do vì sao chúng ta tách riêng các tier cho từng thành phần.
2. Separation of Concerns
Separation of Concerns về cơ bản mang cùng một tinh thần:
👉 Mỗi thành phần chỉ nên quan tâm tới nhiệm vụ của mình, không cần lo lắng về phần còn lại.
Nguyên lý này áp dụng ở mọi cấp độ của hệ thống, từ cấp tier cho tới cấp độ code.
Việc tách biệt các thành phần giúp chúng có thể tái sử dụng. Nhiều dịch vụ khác nhau có thể dùng chung database, messaging server hoặc các thành phần khác, miễn là chúng không bị ràng buộc chặt chẽ với nhau.
Thiết kế loosely coupled là hướng đi đúng đắn. Cách tiếp cận này giúp hệ thống dễ mở rộng (scalable) khi quy mô tăng lên trong tương lai.
3. Sự khác nhau giữa layers và tiers
Lưu ý: Đừng nhầm lẫn tiers với layers của ứng dụng. Một số người hay dùng hai khái niệm này thay thế cho nhau, nhưng trong thực tế ngành phần mềm, application layers thường đề cập đến:
- User Interface layer
- Business layer
- Service layer
- Data Access layer
Trong khi đó, tiers nhấn mạnh vào sự tách biệt về mặt vật lý và triển khai của các thành phần.
Các layer này tồn tại ở mức độ mã nguồn (code level).
Sự khác biệt giữa layers và tiers là:
- Layers thể hiện cách tổ chức logic/khái niệm của mã nguồn
- Tiers thể hiện sự tách biệt vật lý của các thành phần trong hệ thống
