Trong bài Architecture pattern - Phần 5, chúng ta đã tìm hiểu về kiến trúc microservices. Trong bài này, chúng ta sẽ cùng nhau tìm hiểu về kiến trúc hướng không gian (space-based architecture - SBA).

Đây là phong cách kiến trúc đạt được hiệu suất nhờ loại bỏ cơ sở dữ liệu ra khỏi hệ thống. Vậy tại sao họ lại làm như vậy và họ đã làm điều đó như thế nào? Chúng ta sẽ cùng nhau khám phá ngay sau đây.

1. Kiến trúc hướng không gian là gì?

Kiến trúc hướng không gian (Space-Based Architecture - SBA) là mẫu kiến trúc phần mềm giúp giảm thiểu các yếu tố hạn chế khả năng mở rộng ứng dụng.

Kiến trúc này lấy tên từ ý tưởng về bộ nhớ phân tán dùng chung gọi là không gian dữ liệu (dataspace). Khả năng mở rộng cao đạt được bằng cách loại bỏ ràng buộc cơ sở dữ liệu và thay vào đó sử dụng dữ liệu trong các bộ nhớ (in-memory) được sao chép.

Dữ liệu ứng dụng được lưu trong bộ nhớ và được sao chép giữa tất cả các đơn vị xử lý (Processing Unit) đang hoạt động. Các đơn vị xử lý có thể được khởi động và tắt một cách linh hoạt khi tải của người dùng tăng và giảm, từ đó giải quyết được khả năng mở rộng thay đổi. Do không có cơ sở dữ liệu tập trung nên nút thắt cổ chai cơ sở dữ liệu sẽ được loại bỏ, mang lại khả năng mở rộng gần như vô hạn của ứng dụng.

2. Các thành phần của kiến trúc hướng không gian

Các thành phần cơ bản của kiến trúc hướng không gian bao gồm: processing unit, virtualized middleware, data writer và data reader.

2.1. Processing unit

Processing unit (đơn vị xử lý đang hoạt động) chứa logic của ứng dụng, bao gồm thành phần của ứng dụng, bộ nhớ đệm (in-memory data grid) và engine sao chép dữ liệu.

Processing unit được coi là các đơn vị phân tán giúp xử lý các tác vụ đồng thời, làm tăng hiệu suất và khả năng mở rộng của ứng dụng. Ngoài ra, chúng có thể được bật hoặc tắt linh hoạt tuỳ thuộc vào tải của người dùng.

2.2. Virtualized middleware

Virtualized middleware là thành phần quan trọng nhất và có độ phức tạp nhất trong kiến trúc hướng không gian.

Nó giúp quản lý request và session, đồng bộ dữ liệu, giao tiếp và phối hợp giữa các processing unit và tự động loại bỏ, bật, tắt processing unit dựa vào tải của người dùng.

Virtualized middleware bao gồm 4 thành phần chính như sau:

• Messaging grid: quản lý input request và session information. Khi một request đến virtualized middleware, messaging grid sẽ xác định processing unit (đơn vị xử lý đang hoạt động) có sẵn để nhận yêu cầu và chuyển tiếp yêu cầu đến một trong số chúng.
• Data grid: tương tác với data replication engine ở processing unit để quản lý sự sao chép dữ liệu giữa các processing unit khi dữ liệu được cập nhật. Data grid có thể được triển khai ở trong processing unit dưới dạng bộ nhớ đệm và/hoặc triển khai thành một component của Virtualized middleware.

• Data pumps: Do processing unit không trực tiếp đọc/ghi dữ liệu lên database nên cần một component là data pumps để cập nhật dữ liệu từ processing unit tới cơ sở dữ liệu. Data pumps thường được triển khai dưới dạng messaging, hỗ trợ giao tiếp không đồng bộ, guaranteed delivery và giữ cho tin nhắn được sắp xếp theo thứ tự FIFO (first-in, first-out). Ngoài ra, trong mô hình này, data writer sẽ hoạt động độc lập và không phụ thuộc vào processing unit hay database nên nếu xảy ra lỗi với data writer thì không ảnh hưởng tới các component khác.

• Processing grid: là một component không bắt buộc có ở Virtualized middleware, chịu trách nhiệm điều phối việc xử lý request khi có nhiều processing unit tham gia vào quá trình xử lý request đó. Ví dụ, khi có request thanh toán đơn hàng, processing grid sẽ trở thành trung gian, chịu trách nhiệm điều phối request giữa hai đơn vị xử lý là order và payment.

• Deployment manager: là thành phần quan trọng giúp kiến trúc này tối ưu khả năng mở rộng. Nó chịu trách nhiệm quản lý việc khởi động và tắt động các phiên bản processing unit dựa trên tải bao gồm việc liên tục theo dõi thời gian phản hồi và tải của người dùng, khởi động các bộ xử lý mới khi tải tăng và tắt các bộ xử lý khi tải giảm.

2.3. Data reader

• Data reader là thành phần chịu trách nhiệm đọc dữ liệu từ không gian lưu trữ gửi nó đến các processing unit thông qua một data pump.
• Data reader chỉ được gọi trong 3 tình huống sau:

1. Xảy ra sự cố với tất cả các phiên bản processing unit của cùng một bộ nhớ đệm.
2. Triển khai lại tất cả các processing unit của cùng một bộ nhớ đệm
3. Lấy dữ liệu lưu trữ không có trong bộ đệm được sao chép.

2.4. Data writer

• Data writer là thành phần chịu trách nhiệm nhận tin nhắn từ data pump và cập nhật dữ liệu trong tin nhắn vào database. Data writer thường được triển khai dưới dạng dịch vụ, ứng dụng hoặc trung tâm dữ liệu (data hub).
• Có hai mô hình tổ chức data writer phổ biến:

Mô hình 1: Data writer nhận data từ nhiều data pump có cùng domain.

Customer data writer sẽ nhận tin nhắn có chứa dữ liệu liên quan tới customer từ nhiều data pump, rồi ghi vào database.

Mô hình 2: Mỗi data pump sẽ có 1 data writer riêng.

Mô hình này giúp hỗ trợ tốt hơn cách 1 cho việc mở rộng và linh hoạt của hệ thống nhờ sự điều chỉnh phù hợp từ processing unit tới data pump và data writer.

3. Ví dụ sử dụng kiến trúc hướng không gian

Hệ thống bán vé xem hoà nhạc có đặc điểm nổi bật là hệ thống có rất ít traffic cho tới khi công bố lịch biểu diễn của một show nổi tiếng. Một khi vé bắt đầu bán, số lượt truy cập sẽ tăng vọt từ vài trăm cho tới vài ngàn concurrent user (thậm chí là chục ngàn). Ví dụ điển hình là concert của Hà Anh Tuấn và Taylor Swift, vé bán hết vài phút sau khi mở bán.

Những thách thức của hệ thống bán vé xem hoà nhạc ở trên bao gồm:

• Số lượng concurrent request tăng vọt trong một vài thời điểm.
• Dữ liệu về số ghế trống được liên tục cập nhật càng nhanh càng tốt trong hệ thống, trong khi vẫn phải hiển thị dữ liệu đã cập nhật tức thì.

Nếu dùng một cơ sở dữ liệu tập trung, việc truy cập liên tục vào database sẽ không thể đáp ứng một lượng lớn concurrent request do giới hạn connection tới database. Từ đó, ta thấy database sẽ là vấn đề chính cần giải quyết ở đây.

Kiến trúc hướng không gian rất phù hợp với hệ thống bán vé xem hoà nhạc do các đặc điểm như độ đàn hồi cao và hỗ trợ tốt concurrent request.

4. Trường hợp nên dùng kiến trúc hướng không gian

• Hệ thống cần phải xử lý một lượng lớn dữ liệu thời gian thực (ví dụ 10k+): Dữ liệu được ghi vào bộ nhớ đệm nên hoạt động đọc/ghi dữ liệu tới database được hạn chế tới mức thấp nhất. Nhờ vậy, tốc độ xử lý các concurrent request sẽ cải thiện đáng kể. Ngoài ra, SBA có thể tự động mở hoặc thu hẹp tài nguyên.
• Hệ thống yêu cầu tính khả dụng cao, khả năng mở rộng và khả năng chịu lỗi: SBA cung cấp tính năng tự phục hồi và chịu lỗi cao thông qua việc sao chép dữ liệu và dịch vụ trong không gian dữ liệu, giúp hệ thống nhanh chóng phục hồi sau sự cố mà không ảnh hưởng đến hoạt động kinh doanh.

5. Trường hợp không nên dùng kiến trúc hướng không gian

• Nếu lượng dữ liệu của bạn rất lớn (giả sử vài chục terabytes), việc lưu trữ dữ liệu vào bộ nhớ sẽ gặp phải giới hạn lưu trữ. Nên sử dụng kiến trúc hướng không gian sẽ không phải là một giải pháp tốt.
• Kiến trúc hướng không gian chưa phù hợp với các hệ thống đòi hỏi mức độ nhất quán dữ liệu cao giữa các nguồn dữ liệu do bản chất dữ liệu trong kiến trúc này là "eventually consistent". Data  sẽ mất một khoảng thời gian nhất định để cập nhật từ bộ nhớ tới cơ sở dữ liệu.

6. So sánh các mẫu kiến trúc phần mềm

Dưới đây là bảng tổng kết do Mark Richards, tác giả cuốn sách nổi tiếng Fundamentals of Software Architecture, đưa ra nhằm đánh giá về từng mẫu kiến trúc phần mềm dựa trên 6 tiêu chí:

1. (Overall Agility):
2. (Deployment)
3. Khả năng kiểm thử (Testability)
4. Hiệu năng (Performance)
5. Khả năng mở rộng (Scalability)
6. (Development)

7. Tổng kết

• Kiến trúc hướng không gian (Space-based architecture) là một kiến trúc phần mềm được thiết kế để xử lý các ứng dụng lớn, có khả năng mở rộng cao và yêu cầu độ tin cậy trong việc xử lý dữ liệu. Nó đặc biệt hữu ích cho các ứng dụng cần xử lý một lượng lớn giao dịch hoặc dữ liệu trong thời gian thực.
• Dưới đây là bảng điểm xếp hạng cho kiến trúc hướng không gian trích trong sách Software Architecture Patterns của Mark Richards. Kiến trúc này được đánh giá cao nhất ở khả năng mở rộng và hiệu suất. Tuy nhiên, kiến trúc này được đánh giá là chi phí cao, việc áp dụng phức tạp và tính linh hoạt thấp.

Chuỗi bài viết Architecture Pattern nhằm chia sẻ với bạn cách phân loại các mẫu kiến trúc phần mềm và giới thiệu các mẫu kiến trúc phổ biến. Mỗi mẫu mang tới một cách tiếp cận giải quyết cụ thể và độc đáo cho từng vấn đề riêng biệt.

Hy vọng, qua loạt bài viết này, bạn đã có thêm những kiến thức hữu ích để áp dụng vào dự án của mình, và không ngừng nâng cao kỹ năng lập trình để tạo ra những sản phẩm phần mềm chất lượng và hiệu quả.

8. Tài liệu tham khảo

1. Fundamentals of Software Architecture - Mark Richards
2. Software Architecture Patterns - Mark Richards
3. Software Architecture Monday - Mark Richards
4. Microservices - Martin Flower