Client.Transport-ის შეცვლის გარეშე Go HTTP პროქსი მარშრუტების გადართვა

თუ http.Client უკვე პარალელური მოთხოვნებით არის გაზიარებული, შეინარჩუნეთ მისი 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-ის გამოყენებით, ინიციალიზაცია გაუკეთეთ კლიენტის გამოქვეყნებამდე:

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

slot.Set(nextTransport)

initialTransport და nextTransport უნდა იყოს არანილოვანი, სრულად კონფიგურირებული და პარალელურობისთვის უსაფრთხო. ააგეთ ყოველი პროქსი ტრანსპორტი გამოქვეყნებამდე და დატოვეთ მისი კონფიგურაცია უცვლელი, სანამ მოთხოვნები იყენებენ მას.

საკეტი იცავს მხოლოდ მაჩვენებლის სნეპშოტს, ამიტომ ნელი მოთხოვნა არ იკავებს მარშრუტიზაციის საკეტს მთელი ქსელური გაცვლის განმავლობაში. მოთხოვნა, რომელიც უკვე იყენებს წინა სნეპშოტს, აგრძელებს იმ ტრანსპორტზე; გადართვა არ იმეორებს მას და არ გადაადგილებს მის კავშირს.

შეინახეთ და გააუქმეთ ძველი ტრანსპორტები აპლიკაციის შეზღუდული სიცოცხლის ციკლის განმავლობაში, მიეცით საშუალება მიმდინარე სამუშაოს დასრულდეს და საჭიროებისამებრ დახურეთ უმოქმედო აუზები. გადამისამართებამ შეიძლება გამოიწვიოს კიდევ ერთი RoundTrip გადართვის შემდეგ. თუ მთელი სამუშაო ნაკადი ერთ მარშრუტს მოითხოვს, დანიშნეთ ის სამუშაო ნაკადის საზღვართან, ნაცვლად ამ საერთო სელექტორის შუაში შეცვლისა.