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 non-nil, पूर्ण रूपमा कन्फिगर गरिएको र समवर्तीताका लागि सुरक्षित हुनुपर्छ। प्रत्येक प्रोक्सी ट्रान्सपोर्ट प्रकाशित गर्नु अघि बनाउनुहोस्, र अनुरोधहरूले प्रयोग गर्दा यसको कन्फिगरेसन अपरिवर्तित राख्नुहोस्।

लकले पोइन्टर स्न्यापसटको मात्र सुरक्षा गर्छ, त्यसैले ढिलो अनुरोधले आफ्नो सम्पूर्ण नेटवर्क आदानप्रदानभरि राउटिङ लक समात्दैन। अघिल्लो स्न्यापसट प्रयोग गरिरहेको अनुरोध त्यही ट्रान्सपोर्टमा जारी रहन्छ; स्विचले यसलाई फेरि चलाउँदैन वा यसको जडान सार्दैन।

पुराना ट्रान्सपोर्टहरू अनुप्रयोगको सीमित जीवनचक्रभर राख्नुहोस् र अवकाश दिनुहोस्, चलिरहेको काम सम्पन्न हुन दिनुहोस् र उपयुक्त हुँदा निष्क्रिय पूलहरू बन्द गर्नुहोस्। रिडिरेक्टले स्विचपछि अर्को RoundTrip गराउन सक्छ। यदि सम्पूर्ण वर्कफ्लोलाई एउटै मार्ग चाहिन्छ भने, यो साझा सिलेक्टर बीचमा बदल्नुको सट्टा वर्कफ्लोको सिमानामा त्यो मार्ग तोक्नुहोस्।