- Nhận diện vấn đề
- Máy chủ xác thực của Airbridge thỉnh thoảng xảy ra hiện tượng phản hồi chậm.
- Do quá trình xác thực/phân quyền được thực hiện trước mỗi yêu cầu API, nên độ trễ của máy chủ xác thực ảnh hưởng trực tiếp đến độ ổn định của toàn bộ dịch vụ.
- Kết quả giám sát cho thấy cảnh báo độ trễ phản hồi trên 1 giây ngày càng xuất hiện thường xuyên hơn → bắt đầu phân tích nguyên nhân và triển khai tối ưu hóa.
- Phân tích nguyên nhân
- (1) Quá nhiều DB Query: trong quá trình kiểm tra quyền hạn, mỗi yêu cầu phát sinh quá nhiều DB Query, khiến DB Connection Pool nhanh chóng cạn kiệt → gây chậm phản hồi.
- (2) HikariCP Connection Pool bão hòa: khi DB Query bị thực thi quá nhiều, pool của HikariCP bị bão hòa → xác nhận hiện tượng luồng phải chờ hơn 30 giây.
- (3) Hiệu quả cache thấp: TTL được đặt ngắn chỉ 30 giây + logic cache kém hiệu quả → khả năng tái phát sinh DB Query cao.
- Chiến lược cải thiện
- (1) Cải thiện cấu trúc kiểm tra quyền hạn và cache
- Áp dụng cách truy vấn hàng loạt từ DB (
findAllBy~) → số lần DB Query giảm từ 134 xuống 4 (-97%).
- Áp dụng cache
mutableMap dựa trên bộ nhớ ứng dụng.
- Áp dụng nguyên tắc trách nhiệm đơn nhất (SRP) → tách phương thức và thiết lập chiến lược cache theo từng logic con.
- (2) Áp dụng cấu trúc cache 2 lớp
- Áp dụng mô hình kết hợp Local Cache (Caffeine, L1) + Remote Cache (Redis, L2).
- Phân chia chiến lược cache thành L1-Only, L2-Only, Hybrid để cải thiện hiệu quả vận hành.
- Phân tích mức sử dụng bộ nhớ cache → dự kiến 500.000 khóa Redis, yêu cầu khoảng 190MB bộ nhớ, có chừa vùng đệm an toàn.
- (3) Vô hiệu hóa cache dựa trên Redis Pub/Sub
- Thoát khỏi việc phụ thuộc vào TTL, đồng bộ cache theo thời gian thực khi thông tin quyền hạn thay đổi.
- Khi có thay đổi trên một máy chủ, Local Cache của tất cả máy chủ sẽ được vô hiệu hóa đồng bộ thông qua kênh Redis.
- (4) Tinh chỉnh connection pool của HikariCP
- Mở rộng
maximum-pool-size từ 10 lên 30.
- Tối ưu các tùy chọn chi tiết như Connection Timeout, Idle Timeout, Max Lifetime... → giảm tranh chấp DB I/O.
- Kiểm thử hiệu năng và kết quả: duy trì hiệu năng ổn định ngay cả với lưu lượng lớn.
- Hiệu quả cải thiện trong môi trường vận hành
- Sau khi triển khai, cảnh báo chậm phản hồi biến mất, tổng thời gian phản hồi được ổn định hóa.
- Độ tin cậy dịch vụ và độ ổn định vận hành được cải thiện đáng kể.
- Tối ưu bổ sung: JVM Warm-Up
- Phát hiện vấn đề chậm phản hồi ở các yêu cầu đầu tiên do độ trễ biên dịch JIT ngay sau khi triển khai.
- Áp dụng Warm-Up Runner:
- Thực thi trước các yêu cầu giả khi ứng dụng khởi động.
- Khi thay thế K8s Pod, chỉ xử lý lưu lượng sau khi JIT hoàn tất → thời gian phản hồi ban đầu giảm từ 1.07s xuống 94ms.
- Kết luận và hiệu quả
- Giải quyết vấn đề chậm phản hồi + xây dựng cấu trúc sẵn sàng ứng phó khi lưu lượng tăng đột biến.
- Cải thiện độ ổn định và độ tin cậy của toàn bộ dịch vụ Airbridge.
- Nâng cao mức độ tận dụng máy chủ xác thực, từ đó cải thiện năng suất phát triển dịch vụ miền.
2 bình luận
Gần đây, do dịch vụ deeplink của Google ngừng hoạt động nên có lẽ số công ty sử dụng dịch vụ này đã tăng lên.
Mong chờ một dịch vụ ổn định!
Ồ... công ty bên mình cũng mới ký hợp đồng ở đây gần đây, hóa ra mọi người đang làm việc rất chăm chỉ để cải thiện hiệu năng nhỉ!!!