phụ chỉ với 1 vài cú click chuột.
Thiết kế đằng sau đơn giản là một bảng trong cơ sở dữ
liệu chứa các tính năng của bạn, cùng với 1 biến cờ quy
định trạng thái bật/tắt của tính năng.
và dùng nó để kiểm tra:
Lúc đó, với mỗi user_id, ta sẽ dùng 1 hàm hash để đẩy
người dùng vào 1 tập từ 1-100, và so sánh với giá trị
rollout_percent của mình…
BẬT/TẮT CHO KHÁCH HÀNG CỤ THỂ
Bây giờ mình thảo luận đến một vài trường hợp phức tạp
hơn khi mà bạn:
1. Chỉ muốn bật tính năng cho 1 vài khách hàng thử
nghiệm (hoặc là khách hàng cao cấp)
2. Muốn bật cho toàn bộ hệ thống, nhưng tắt cho 1 vài
khách hàng đặc biệt (khách hàng chưa đăng ký sử dụng
tính năng này)
Có thể nhận ra rằng 2 trường hợp trên giống như 2
mệnh đề đảo ngược nhau, lúc đó, bạn có thể cải thiện hệ
thống bằng cách thêm vào 1 cột exception_list để chứa tập
khách hàng đặc biệt này:
LÚC NÀO THÌ LÀM GÌ?
Nếu để ý kĩ các ví dụ trên, thì không phải lúc nào bạn cũng
cần hết những tính năng nói trên:
Trường hợp bật/tắt cho khách hàng cụ thể sẽ phù hợp với
các ứng dụng B2B (ví dụ: Intercom, Hubspot), khi mà người
xài thuộc các tài khoản công ty khác nhau.
Trường hợp triên khai theo % của user sẽ phù hợp hơn với
các ứng dụng B2C (ví dụ Quora, Facebook, Kipalog) khi mỗi
người xài là 1 user độc lập.
Nói vậy để thấy là tuy cũng chỉ là cơ chế feature toggle,
feature rollout, nhưng mỗi doanh nghiệp khi thiết kế sẽ có
nhiều bài toán con khác nhau, ảnh hưởng đến cách bạn
thiết kế tính năng này.
CẢI THIỆN TỐC ĐỘ (PERFORMANCE IMPROVEMENT)
Lúc này thì:
toggled = false, exception_list = [1, 2] : tắt
toàn bộ, vào bật cho khách hàng ID 1 và 2.
toggled = true, exception_list = [1, 2] : bật
cho toàn bộ khách hàng, chỉ tắt cho khách hàng ID 1 và 2.
Ở trên ta dùng database để lưu các toggles, như vậy mỗi
lần gọi hệ thống phải truy vấn vào cơ sở dữ liệu. Với những
hệ thống có nhiều người dùng, việc này sẽ làm chậm hệ
thống lại rất nhiều và trở nên không thực tế.
Nhận thấy việc dữ liệu toggles ở trên không thường
xuyên thay đổi nhiều (chỉ đổi khi admin vào sửa nội dung),
nên ta có thể dùng caching (như Redis, hoặc lưu thẳng vào
memory) để tránh việc phải có nhiều database calls. Và
ta chỉ cần làm mới bộ đệm khi mà ai đó vào admin để cập
nhật lại toggle settings.
Một cách triển khai khác là ta hoàn toàn có thể hiện
thực trực tiếp bằng Redis mà không cần phải thông qua
SQL database. Lúc này ta phải coi như dữ liệu trong Redis
của bạn là persistent data và có cơ chế backup thích hợp.
KẾT LUẬN
Trong ảnh: UI features toggles của Holistics (dựa trên nền
ActiveAdmin).
TOGGLE CHO % TẬP NGƯỜI DÙNG (HAY LÀ FEATURE
ROLLOUT)
Giả sử bây giờ, bạn vừa deploy 1 tính năng mới và muốn
release thử nghiệm cho 5% người dùng của mình thôi thì
phải thiết kế như thế nào?
Một cách đơn giản là thêm vào 1 cột rollout_percent,
Ở trên mình đã giới thiệu các bạn hướng tiếp cận và giải
quyết bài toán Feature Toggle / Feature Rollout. Tuy nhìn
đơn giản nhưng khi đi sâu vào nó có những yêu cầu đặc
thù khác nhau, cho nên mỗi công ty sẽ có cách tiếp cận/
thực thi khác nhau.
Đọc và thảo luận bài viết online:
https://engineering.grokking.org/
DIJSKTRA
29