Jos http.Client on jo samanaikaisten pyyntöjen jakama, pidä sen Transport-kenttä vakaana. Kääre voi synkronoida, minkä täysin määritetyn kuljettimen kukin myöhempi edestakainen siirto saa:

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()
}

Käytä net/http- ja sync-paketteja ja alusta se ennen asiakkaan julkaisemista:

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

slot.Set(nextTransport)

initialTransport ja nextTransport eivät saa olla nil, ja niiden on oltava täysin määritettyjä ja samanaikaisuuden kannalta turvallisia siirtojen suorittajia. Rakenna jokainen välityspalvelinkuljetin ennen sen julkaisemista äläkä muuta sen määritystä, kun pyynnöt käyttävät sitä.

Lukko suojaa vain osoittimen tilannevedosta, joten hidas pyyntö ei pidä reitityslukkoa koko verkkosiirron ajan. Pyyntö, joka käyttää jo edellistä tilannevedosta, jatkaa kyseisellä kuljettimella; vaihto ei toista sitä eikä siirrä sen yhteyttä.

Säilytä ja poista vanhat kuljettimet sovelluksen rajatun elinkaaren kautta, anna käynnissä olevan työn valmistua ja sulje tyhjätöissä olevat altaat tarpeen mukaan. Uudelleenohjaus voi aiheuttaa vaihdon jälkeen toisen RoundTripin. Jos koko työnkulku tarvitsee yhden reitin, määritä se työnkulun rajalla sen sijaan, että muuttaisit tätä jaettua valitsinta kesken kaiken.

Aiheeseen liittyvät artikkelit