Triển khai mẫu Sidecar trong ứng dụng ASP.NET Core kiến trúc Microservices

Các ứng dụng hiện đại ngày càng phức tạp với nhu cầu lớn về giám sát, ghi nhật ký (logging), cấu hình và bảo mật. Việc tích hợp chặt chẽ các chức năng này vào ứng dụng chính thường dẫn đến sự phụ thuộc lẫn nhau, khiến việc bảo trì khó khăn và có thể khiến toàn bộ hệ thống sụp đổ nếu một thành phần phụ gặp sự cố. Đây chính là lúc mẫu thiết kế Sidecar phát huy tác dụng.

Mô hình minh họa Sidecar

Mẫu thiết kế Sidecar là gì?

Mẫu Sidecar (xe bên) được đặt tên theo chiếc xe gắn máy bên cạnh mô tô. Trong kiến trúc phần mềm, Sidecar là một container hoặc tiến trình riêng biệt được gắn liền với ứng dụng chính. Nó chia sẻ cùng vòng đời và tài nguyên với ứng dụng cha, nhưng hoạt động độc lập để xử lý các tác vụ phụ trợ.

Solution Explorer hiển thị cả hai dự án

Trong khi container chính xử lý logic nghiệp vụ, container Sidecar sẽ đảm nhận các trách nhiệm như:

• Ghi log và giám sát (Monitoring).
• Truy vết phân tán (Distributed tracing).
• Thực thi bảo mật.
• Khám phá dịch vụ (Service discovery).
• Định tuyến lưu lượng.

Tại sao nên sử dụng Sidecar?

Sử dụng mẫu Sidecar mang lại nhiều lợi ích thiết thực cho các hệ thống Microservices:

• Giảm độ phức tạp: Tách biệt các mối quan tâm xuyên suốt (cross-cutting concerns) giúp mã nguồn ứng dụng chính tập trung vào nghiệp vụ.
• Độc lập ngôn ngữ: Bạn có thể xây dựng Sidecar bằng bất kỳ ngôn ngữ lập trình nào, khác với ngôn ngữ của ứng dụng chính.
• Tính tái sử dụng cao: Một Sidecar có thể được chia sẻ và sử dụng lại cho nhiều dịch vụ khác nhau.
• Khả năng mở rộng: Dễ dàng thêm các tính năng mới bằng cách đính kèm thêm Sidecar mà không cần sửa đổi ứng dụng chính.

Triển khai ghi nhật ký phân tán với Sidecar

Để minh họa, chúng ta sẽ xây dựng một hệ thống quản lý tồn kho đơn giản gồm hai Microservices: TransactionsAPI (ứng dụng chính) và SidecarAPI (sidecar). Mục tiêu là ghi log từ TransactionsAPI, lưu vào một tệp chia sẻ, và SidecarAPI sẽ đọc tệp này để gửi dữ liệu đến Elasticsearch.

1. TransactionsAPI (Người sản xuất Log)

Microservices này xử lý các giao dịch và tạo ra log. Thay vì ghi trực tiếp ra đĩa hoặc gọi Elasticsearch (gây độ trễ), nó sử dụng một hàng đợi trong bộ nhớ (ConcurrentQueue).

• TransactionsController: Nhận yêu cầu HTTP POST, xác thực dữ liệu và đẩy thông điệp log vào hàng đợi.
• ThreadSafeFileLogger: Một dịch vụ ghi tệp an toàn luồng sử dụng SemaphoreSlim để đảm bảo không có xung đột khi ghi dữ liệu.
• TransactionsBackgroundService: Một dịch vụ chạy nền lấy log từ hàng đợi và ghi vào tệp văn bản trong một thư mục chia sẻ.

2. SidecarAPI (Người tiêu thụ Log)

SidecarAPI hoạt động độc lập để thu thập và xử lý log.

• SidecarBackgroundService: Thăm dò tệp log trong thư mục chia sẻ mỗi 5 giây, phân tích cú pháp nội dung và chuẩn bị gửi đi.
• ElasticSearchClientService: Đóng gói logic để kết nối và chỉ mục hóa dữ liệu vào Elasticsearch.
• LogsController: Cung cấp endpoint HTTP GET để truy vấn các log đã lưu trữ trong Elasticsearch.

Container hóa với Docker

Để triển khai mẫu Sidecar hiệu quả, chúng ta sử dụng Docker để đóng gói từng dịch vụ thành các container riêng biệt. Cả hai container sẽ chia sẻ một volume để trao đổi tệp log.

Ứng dụng và các container Sidecar đang thực thi

Chúng ta sử dụng Docker Compose để định nghĩa và chạy toàn bộ hệ thống. File docker-compose.yml sẽ bao gồm ba dịch vụ chính:

1. elasticsearch: Cơ sở dữ liệu lưu trữ log.
2. transactions-api: Ứng dụng chính, mở port 8080.
3. sidecar-api: Sidecar, mở port 8081.

Cả hai dịch vụ API đều mount thư mục ./logs từ máy chủ vào đường dẫn /app/logs trong container để chia sẻ tệp log.

Kubernetes và các lưu ý về hiệu suất

Mặc dù Docker Compose rất tốt cho môi trường phát triển, Kubernetes mới là nơi lý tưởng để triển khai Sidecar trong sản xuất. Trong Kubernetes, Sidecar thực sự tỏa sáng khi các container nằm cùng một Pod, chia sẻ cùng mạng localhost và vòng đời.

Tuy nhiên, cần lưu ý đến hiệu suất:

• Việc sử dụng Sidecar có thể thêm độ trễ mạng và tài nguyên so với giải pháp trong tiến trình (in-process).
• Các thao tác nhập/xuất tệp (I/O) trong ví dụ trên có thể gây tốn kém tài nguyên.
• Để tối ưu hóa, nên gửi log theo lô (batch) thay vì từng cái một và sử dụng các công cụ như OpenTelemetry để thu thập chỉ số.

Kết luận

Mẫu thiết kế Sidecar là một giải pháp mạnh mẽ để giải quyết các vấn đề về ghi log, giám sát và cấu hình trong kiến trúc Microservices. Bằng cách tách biệt các mối quan tâm phụ trợ, Sidecar giúp ứng dụng chính trở nên gọn nhẹ, dễ bảo trì và mở rộng. Mặc dù có một số chi phí về hiệu suất, nhưng lợi ích về tính module hóa và linh hoạt mà nó mang lại là vô giá đối với các ứng dụng đám mây hiện đại.