Client.Transport ကို မပြောင်းဘဲ Go HTTP proxy လမ်းကြောင်းများ ပြောင်းခြင်း

http.Client ကို တစ်ပြိုင်နက်တည်း တောင်းဆိုမှုများက မျှဝေပြီးဖြစ်ပါက ၎င်း၏ Transport အကွက်ကို တည်ငြိမ်စွာ ထားရှိပါ။ အုပ်ထုပ်သည် နောက်ဆက်တွဲ သွားလာမှုတစ်ခုစီသည် မည်သည့် အပြည့်အစုံ ပြင်ဆင်ထားသော transport ကို ရမည်ကို ထပ်တူပြုနိုင်သည်:

type routeSlot struct {
    mu sync.RWMutex
    current http.RoundTripper
}

func (s *routeSlot) RoundTrip(r *http.Request) (*http.Response, error) {
    s.mu.RLock()
    current := s.current
    s.mu.RUnlock()
    return current.RoundTrip(r)
}

func (s *routeSlot) Set(next http.RoundTripper) {
    s.mu.Lock()
    s.current = next
    s.mu.Unlock()
}

net/http နှင့် sync ကို အသုံးပြု၍ client ကို မထုတ်ပြန်မီ စတင်ပါ:

slot := &routeSlot{current: initialTransport}
client := &http.Client{Transport: slot}

slot.Set(nextTransport)

initialTransport နှင့် nextTransport သည် non-nil ဖြစ်ရမည်၊ အပြည့်အစုံ ပြင်ဆင်ထားရမည်၊ တစ်ပြိုင်နက်တည်း လုပ်ဆောင်မှုအတွက် လုံခြုံရမည်။ proxy transport တစ်ခုစီကို မထုတ်ပြန်မီ တည်ဆောက်ပါ၊ တောင်းဆိုမှုများ အသုံးပြုနေစဉ် ၎င်း၏ ပြင်ဆင်မှုကို မပြောင်းပါနှင့်။

သော့ခတ်မှုသည် pointer snapshot ကိုသာ ကာကွယ်သည်၊ ထို့ကြောင့် နှေးသော တောင်းဆိုမှုသည် ၎င်း၏ ကွန်ရက် လဲလှယ်မှု တစ်ခုလုံးအတွင်း လမ်းကြောင်းသတ်မှတ်မှု သော့ကို ကိုင်မထားပါ။ ယခင် snapshot ကို အသုံးပြုနေသော တောင်းဆိုမှုသည် ထို transport ပေါ်တွင် ဆက်လက်သွားသည်၊ ပြောင်းလဲမှုသည် ၎င်းကို ပြန်မလုပ်ဆောင်ဘဲ ၎င်း၏ ချိတ်ဆက်မှုကို မရွှေ့ပါ။

အဟောင်း transport များကို အပလီကေးရှင်း၏ ကန့်သတ်ထားသော သက်တမ်းတစ်လျှောက် ထိန်းသိမ်းပြီး အနားယူစေပါ၊ လုပ်ဆောင်နေသော အလုပ်များ ပြီးဆုံးခွင့်ပြုပြီး သင့်လျော်ပါက idle pool များကို ပိတ်ပါ။ ပြောင်းပြီးနောက် ပြန်ညွှန်းမှုတစ်ခုက နောက်ထပ် RoundTrip တစ်ခု ဖြစ်စေနိုင်သည်။ workflow တစ်ခုလုံးသည် လမ်းကြောင်းတစ်ခု လိုအပ်ပါက ဤမျှဝေထားသော ရွေးချယ်ကိရိယာကို အလယ်တွင် ပြောင်းမည့်အစား workflow နယ်စပ် တွင် ထိုလမ်းကြောင်းကို သတ်မှတ်ပါ။