Thiết lập Cơ chế Thử lại trong Linkerd 2.10

Để Linkerd tự động thử lại các yêu cầu thất bại, chúng ta cần xác định hai vấn đề:

• Yêu cầu nào nên được thử lại?
• Mỗi yêu cầu nên được thử lại bao nhiêu lần?

Cả hai câu hỏi này đều có thể được trả lời bằng cách chỉ định thêm một số thông tin trong tệp cấu hình dịch vụ cho dịch vụ gửi yêu cầu.

Lý do cần các cấu hình này là vì việc thử lại có thể tiềm ẩn rủi ro. Việc tự động thử lại các yêu cầu thay đổi trạng thái (ví dụ: yêu cầu gửi giao dịch tài chính) có thể gây ảnh hưởng tiêu cực đến trải nghiệm người dùng. Ngoài ra, việc thử lại sẽ tăng tải hệ thống. Một nhóm dịch vụ với các yêu cầu liên tục thử lại có thể bị "đánh bại" bởi các lần thử lại mà không có thời gian phục hồi.

Thiết lập Thử lại

Đối với các tuyến đường có tính chất đẳng thức (idempotent) và không có phần thân, bạn có thể chỉnh sửa tệp cấu hình dịch vụ (service profile) và thêm `isRetryable` vào các tuyến đường có thể thử lại:

spec:
  routes:
  - name: GET /api/annotations
    condition:
      method: GET
      pathRegex: /api/annotations
    isRetryable: true ### THÊM DÒNG NÀY ###

Ngân sách Thử lại

`retryBudget` là một cơ chế giới hạn tỷ lệ phần trăm các lần thử lại có thể được thực hiện đối với một dịch vụ so với các yêu cầu ban đầu. Điều này ngăn chặn việc thử lại làm quá tải hệ thống. Theo mặc định, việc thử lại có thể tăng tối đa 20% tải yêu cầu (cộng thêm 10 lần "miễn phí" mỗi giây). Bạn có thể điều chỉnh các cài đặt này bằng cách đặt `retryBudget` trong `service profile` của mình.

spec:
  retryBudget:
    retryRatio: 0.2
    minRetriesPerSecond: 10
    ttl: 10s

Giám sát Thử lại

Bạn có thể sử dụng lệnh `linkerd viz routes` với cờ `--to` và `-o wide` để giám sát các lần thử lại. Vì việc thử lại được thực hiện ở phía client, chúng ta cần sử dụng cờ `--to` để xem các chỉ số về yêu cầu một tài nguyên gửi đến tài nguyên khác (từ góc độ server, các lần thử lại chỉ là các yêu cầu thông thường). Khi chỉ định cả hai cờ này, lệnh `linkerd routes` sẽ phân biệt lưu lượng "hiệu quả (effective)" và "thực tế (actual)".

ROUTE                       SERVICE   EFFECTIVE_SUCCESS   EFFECTIVE_RPS   ACTUAL_SUCCESS   ACTUAL_RPS   LATENCY_P50   LATENCY_P95   LATENCY_P99
HEAD /authors/{id}.json     authors             100.00%          2.8rps           58.45%       4.7rps           7ms          25ms          37ms
[DEFAULT]                   authors               0.00%          0.0rps            0.00%       0.0rps           0ms           0ms           0ms

Các yêu cầu thực tế đại diện cho tất cả các yêu thức mà client thực sự gửi đi, bao gồm cả yêu cầu ban đầu và các lần thử lại. Các yêu cầu hiệu quả chỉ tính các yêu cầu ban đầu. Vì yêu cầu ban đầu có thể kích hoạt một hoặc nhiều lần thử lại, nên khi bật tính năng thử lại, số lượng yêu cầu thực tế thường cao hơn số lượng yêu cầu hiệu quả. Vì yêu cầu ban đầu có thể thất bại lần đầu tiên, nhưng lần thử lại của nó có thể thành công, nên tỷ lệ thành công hiệu quả (effective success rate) thường (nhưng không phải lúc nào cũng) cao hơn tỷ lệ thành công thực tế (actual success rate).