Container Design Pattern cho hệ thống phân tán: Adapter [Kỳ 3]
Ở kỳ trước, mình đã giới thiệu về Ambassador pattern, nơi mà dùng dùng một ambassador container như một phần trung gian giúp tương tác giữa container ứng dụng và phần còn lại của thế giới internet. Kỳ này mình sẽ giới thiệu tiếp về Adapter pattern, đây là pattern phù hợp khi chúng ta muốn giữ cho việc giao tiếp giữa các container được nhất quán.
1. Adapter pattern là gì
Giống như bạn củ sạc iphone - cũng được gọi là adapter, chuyển dòng điện 220V xoay chiều nhà bạn sang 5V 1 chiều thì mới sạc được. Adapter pattern cũng hoạt động như vậy, nó có nhiệm vụ chuyển thông tin output của các container bất kì sang một quy ước quy chuẩn chung của toàn bộ ứng dụng. Dưới đây là cấu trúc triển khai chung của 1 adapter pattern:
Lợi ích rõ ràng nhất của adapter pattern đó là:
- Output của các container sẽ được chuẩn hoá sang 1 chuẩn quy ước, từ đó giảm thiểu việc mất thời gian và công sức để xử lý quá nhiều kiểu output các nhau.
- Tách biệt logic xử lý chuyển đổi sang một container riêng, từ đó giữ cho ứng dụng được độc lập mà không phải thêm logic trong code ứng dụng đó.
Sau đây là các use-case phổ biến của adapter pattern để các bạn có cái nhìn tổng quan hơn về việc nó được sử dụng trong thực tế như thế nào.
2. Sử dụng Prometheus để monitoring
Prometheus là một monitoring aggregator - tạm dịch tập hợp thông tin quan sát. Có nhiệm vụ thu thập số liệu và tổng hợp chúng vào một cơ sở dữ liệu theo thời gian (time series database). Bằng database này, Prometheus trực quan hoá số liệu bằng biểu đồ và các query language. Để thu thập số liệu từ nhiều nguồn, nhiều hệ thống khác nhau, Prometheus yêu cầu các nguồn đó phải cung cấp một metric API thì mới thu thập dữ liệu được.
Tuy nhiên, nhiều ứng dụng, chẳng hạn như Redis, không cung cấp một metric API phù hợp với Prometheus. Vì lẽ đó, ta có thể áp dụng adapter pattern, tự tạo một container adapter riêng để chuyển đổi output của Redis sang chuẩn metric API phù hợp với Prometheus để thu thập.
Giả sử ta có 1 Kubernetes Pod đơn giản cho một Redis server:
Ta có thể thêm một adapter container, điều chỉnh output của Pod này thành một chuẩn phù hợp với Prometheus. Ở đây mình không nói logic cụ thể của adapter, cái đó tuỳ thuộc vào người code, các bạn chỉ cần hiểu ý tưởng ở đây là adapter container chứa logic chuyển đổi tín hiệu phù hợp cho mục đích của bạn là được.
Ở ví dụ này, ta thấy được adapter container kể hợp được với Redis container cùng nằm trong 1 Pod. Đấy chính là cấu trúc chung của adapter pattern mình để cập ở trên.
3. Chuẩn hoá nhiều log khác nhau thành cùng 1 format với Fluentd
Fluentd là một logging agent - có thể hiểu là một trạm thu thập và xử lý, phân phối log đến nhiều đích.
Thay vì tự code adapter chuyển đổi log format, ta có thể tiết kiệm thời gian và công sức bằng cách sử dụng Fluentd như 1 adapter. Chỉ đơn giản là bọc Fluentd bằng 1 container, cấu hình phù hợp và đặt vào trong 1 pod với container tương ứng - ví dụ 1 Pod chứa 1 Redis server như trên, thay vì xử lý output thì xử lý log của Redis server xuất ra.
4. Tổng kết:
Trên đây là 2 trên nhiều use-case adapter pattern được sử dụng phổ biến trên thực tế. Tóm lại, khi cần tách biệt và sử dụng lại việc chuyển đổi thông tin tín hiệu, bạn hãy nghĩ ngay đến adapter pattern và tra cứu nó. Việc sử dụng design pattern ngày nay không cần thiết phải nhớ kĩ, chỉ cần biết được mục đích sử dụng và biết tra cứu ở đâu khi cần thiết là được rồi, đúng không nào.
Hy vọng qua bài viết này các bạn sẽ có cái nhìn tổng quan về adapter pattern và là tư liệu tra cứu khi cần.