गो पर एक साधारण बैलेंसर लिखना

लोड आर्किटेक्चर वेब आर्किटेक्चर में महत्वपूर्ण भूमिका निभाते हैं। वे आपको कई बैकएंड में लोड वितरित करने की अनुमति देते हैं, जिससे स्केलेबिलिटी में सुधार होता है। और चूंकि हमारे पास कई बैकएंड कॉन्फ़िगर किए गए हैं, इसलिए सेवा अत्यधिक उपलब्ध हो जाती है, क्योंकि एक सर्वर पर असफल होने की स्थिति में, बैलेंसर दूसरे काम करने वाले सर्वर को चुन सकता है।

NGINX जैसे पेशेवर बैलेन्सर के साथ खेलने के बाद, मैंने मस्ती के लिए एक साधारण बैलेन्सर बनाने की कोशिश की। मैंने इसे गो पर लिखा, यह एक आधुनिक भाषा है जो पूर्ण समानता का समर्थन करती है। गो में मानक पुस्तकालय में कई विशेषताएं हैं और आपको कम कोड वाले उच्च-प्रदर्शन अनुप्रयोगों को लिखने की अनुमति मिलती है। इसके अलावा, वितरण में आसानी के लिए, यह एक एकल सांख्यिकीय रूप से जुड़ा हुआ बाइनरी उत्पन्न करता है।

हमारा बैलेंसर कैसे काम करता है

बैकएंड के बीच लोड वितरित करने के लिए विभिन्न एल्गोरिदम का उपयोग किया जाता है। उदाहरण के लिए:

• राउंड रॉबिन - लोड समान रूप से वितरित किया जाता है, सर्वर की समान कंप्यूटिंग शक्ति को ध्यान में रखते हुए।
• भारित राउंड रॉबिन - प्रसंस्करण शक्ति के आधार पर, सर्वरों को अलग-अलग भार सौंपा जा सकता है।
• कम से कम कनेक्शन - लोड को कम से कम सक्रिय कनेक्शन के साथ सर्वर पर वितरित किया जाता है।

हमारे बैलेंसर में, हम सबसे सरल एल्गोरिदम - राउंड रॉबिन को लागू करते हैं।

राउंड रॉबिन में चयन

गोल रॉबिन एल्गोरिथ्म सरल है। यह सभी कलाकारों को कार्यों को पूरा करने का समान अवसर देता है।


आने वाले अनुरोधों को संभालने के लिए राउंड रॉबिन में सर्वर का चयन करें।

जैसा कि चित्रण में दिखाया गया है, एल्गोरिथ्म सर्वरों को एक चक्र में, चक्रीय रूप से चुनता है। लेकिन हम उन्हें सीधे , सही का चयन नहीं कर सकते हैं?

और अगर सर्वर झूठ बोल रहा है? हमें शायद इसे ट्रैफ़िक भेजने की आवश्यकता नहीं है। अर्थात, सर्वर का उपयोग तब तक सीधे नहीं किया जा सकता है जब तक हम इसे वांछित स्थिति में नहीं लाते। केवल उन सर्वरों के लिए यातायात को निर्देशित करना आवश्यक है जो ऊपर और चल रहे हैं।

संरचना को परिभाषित करें

हमें बैकएंड से संबंधित सभी विवरणों को ट्रैक करने की आवश्यकता है। आपको यह जानना होगा कि क्या वह जीवित है, और URL को ट्रैक कर सकता है। ऐसा करने के लिए, हम निम्नलिखित संरचना को परिभाषित कर सकते हैं:

type Backend struct { URL *url.URL Alive bool mux sync.RWMutex ReverseProxy *httputil.ReverseProxy } 

चिंता न करें, मैं बैकएंड में फ़ील्ड्स का अर्थ समझाऊंगा।

अब बैलेंसर में आपको किसी तरह सभी बैकेंड को ट्रैक करना होगा। ऐसा करने के लिए, आप स्लाइस और एक चर काउंटर का उपयोग कर सकते हैं। इसे ServerPool में परिभाषित करें:

 type ServerPool struct { backends []*Backend current uint64 } 

ReverseProxy का उपयोग करना

जैसा कि हमने पहले ही निर्धारित किया है, बैलेंसर का सार विभिन्न सर्वरों को ट्रैफ़िक वितरित करने और क्लाइंट को परिणाम वापस करने में है। जैसा कि गो प्रलेखन कहता है:

ReverseProxy एक HTTP हैंडलर है जो आने वाले अनुरोधों को लेता है और इसे एक अन्य सर्वर पर भेजता है, जो क्लाइंट को प्रतिक्रियाएं देता है।

वास्तव में हमें जो चाहिए। पहिया को सुदृढ़ करने की आवश्यकता नहीं है। आप बस ReverseProxy माध्यम से हमारे अनुरोधों को स्ट्रीम कर सकते हैं।

 u, _ := url.Parse("http://localhost:8080") rp := httputil.NewSingleHostReverseProxy(u) // initialize your server and add this as handler http.HandlerFunc(rp.ServeHTTP) 

httputil.NewSingleHostReverseProxy(url) का उपयोग करके httputil.NewSingleHostReverseProxy(url) आप ReverseProxy को इनिशियलाइज़ कर सकते हैं, जो कि दिए गए url अनुरोधों को प्रसारित करेगा। ऊपर दिए गए उदाहरण में, सभी अनुरोध स्थानीयहोस्ट को भेजे गए थे: 8080, और परिणाम क्लाइंट को भेजे गए थे।

यदि आप ServeHTTP विधि के हस्ताक्षर को देखते हैं, तो आप इसमें HTTP हैंडलर के हस्ताक्षर पा सकते हैं। इसलिए, आप इसे http में HandlerFunc को पास कर सकते हैं।

अन्य उदाहरण प्रलेखन में हैं ।

हमारे बैलेंसर के लिए, आप Backend में संबंधित URL साथ ReverseProxy आरंभ कर सकते हैं ताकि ReverseProxy रूट URL लिए अनुरोध URL ।

सर्वर चयन प्रक्रिया

अगले सर्वर के चयन के दौरान, हमें अंतर्निहित सर्वर को छोड़ना होगा। लेकिन आपको गिनती को व्यवस्थित करने की आवश्यकता है।

कई ग्राहक बैलेंसर से जुड़ेंगे, और जब उनमें से प्रत्येक अगले नोड को ट्रैफ़िक स्थानांतरित करने के लिए कहेंगे, तो रेस की स्थिति उत्पन्न हो सकती है। इसे रोकने के लिए, हम ServerPool को mutex साथ ब्लॉक कर सकते हैं। लेकिन यह बेमानी होगा, इसके अलावा हम ServerPool ब्लॉक नहीं करना चाहते हैं। हमें सिर्फ एक-एक करके काउंटर बढ़ाने की जरूरत है।

इन आवश्यकताओं को पूरा करने के लिए सबसे अच्छा समाधान परमाणु वृद्धि होगा। गो atomic पैकेज के साथ इसका समर्थन करता है।

 func (s *ServerPool) NextIndex() int { return int(atomic.AddUint64(&s.current, uint64(1)) % uint64(len(s.backends))) } 

हम एटोमिक रूप से वर्तमान मूल्य को एक से बढ़ाते हैं और सरणी की लंबाई को बदलकर सूचकांक वापस करते हैं। इसका मतलब है कि मान हमेशा 0 से लेकर सरणी की लंबाई तक की सीमा में होना चाहिए। अंत में, हम एक विशिष्ट सूचकांक में दिलचस्पी लेंगे, न कि पूरे काउंटर पर।

एक लाइव सर्वर चुनना

हम पहले से ही जानते हैं कि हमारे अनुरोधों को सभी सर्वरों पर चक्रीय रूप से घुमाया जाता है। और हमें केवल निष्क्रिय को छोड़ने की आवश्यकता है।

GetNext() हमेशा मान 0 से लेकर सरणी की लंबाई तक देता है। किसी भी समय, हम अगला नोड प्राप्त कर सकते हैं, और यदि यह निष्क्रिय है, तो हमें लूप के हिस्से के रूप में सरणी के माध्यम से और खोज करने की आवश्यकता है।


हम सरणी के माध्यम से लूप करते हैं।

जैसा कि चित्रण में दिखाया गया है, हम सूची के अंत में अगले नोड से जाना चाहते हैं। यह next + length का उपयोग करके किया जा सकता है। लेकिन एक सूचकांक का चयन करने के लिए, आपको इसे सरणी की लंबाई तक सीमित करने की आवश्यकता है। यह संशोधित ऑपरेशन का उपयोग करके आसानी से किया जा सकता है।

खोज के दौरान हमें एक कार्यशील सर्वर मिलने के बाद, इसे वर्तमान के रूप में चिह्नित किया जाना चाहिए:

 // GetNextPeer returns next active peer to take a connection func (s *ServerPool) GetNextPeer() *Backend { // loop entire backends to find out an Alive backend next := s.NextIndex() l := len(s.backends) + next // start from next and move a full cycle for i := next; i < l; i++ { idx := i % len(s.backends) // take an index by modding with length // if we have an alive backend, use it and store if its not the original one if s.backends[idx].IsAlive() { if i != next { atomic.StoreUint64(&s.current, uint64(idx)) // mark the current one } return s.backends[idx] } } return nil } 

बैकएंड संरचना में दौड़ की स्थिति से बचना

यहां आपको एक महत्वपूर्ण मुद्दा याद रखना होगा। Backend संरचना में एक चर है जिसमें कई गोरोनाइट एक ही समय में संशोधित या क्वेरी कर सकते हैं।

हम जानते हैं कि गोरोइटिन इसे लिखने के बजाय चर को पढ़ेगा। इसलिए, Alive तक पहुंच को RWMutex करने के लिए Alive हमने RWMutex चुना।

 // SetAlive for this backend func (b *Backend) SetAlive(alive bool) { b.mux.Lock() b.Alive = alive b.mux.Unlock() } // IsAlive returns true when backend is alive func (b *Backend) IsAlive() (alive bool) { b.mux.RLock() alive = b.Alive b.mux.RUnlock() return } 

संतुलन अनुरोध

अब हम अपने अनुरोधों को संतुलित करने के लिए एक सरल विधि तैयार कर सकते हैं। यह तभी विफल होगा जब सभी सर्वर गिर जाएंगे।

 // lb load balances the incoming request func lb(w http.ResponseWriter, r *http.Request) { peer := serverPool.GetNextPeer() if peer != nil { peer.ReverseProxy.ServeHTTP(w, r) return } http.Error(w, "Service not available", http.StatusServiceUnavailable) } 

इस विधि को HTTP सर्वर में केवल एक HandlerFunc रूप में पारित किया जा सकता है।

 server := http.Server{ Addr: fmt.Sprintf(":%d", port), Handler: http.HandlerFunc(lb), } 

हम ट्रैफिक को केवल रनिंग सर्वर तक ही सीमित करते हैं

हमारे बैलेन्सर में एक गंभीर समस्या है। हमें नहीं पता कि सर्वर चल रहा है या नहीं। यह पता लगाने के लिए, आपको सर्वर की जांच करने की आवश्यकता है। ऐसा करने के दो तरीके हैं:

• सक्रिय: वर्तमान अनुरोध को निष्पादित करते हुए, हम पाते हैं कि चयनित सर्वर प्रतिक्रिया नहीं दे रहा है, और इसे निष्क्रिय के रूप में चिह्नित करता है।
• निष्क्रिय: आप कुछ अंतराल पर सर्वर को पिंग कर सकते हैं और स्थिति की जांच कर सकते हैं।

सक्रिय रूप से चल रहे सर्वर की जाँच

यदि कोई त्रुटि ReverseProxy ErrorHandler कॉलबैक फ़ंक्शन आरंभ करता है। इसका उपयोग विफलताओं का पता लगाने के लिए किया जा सकता है:

 proxy.ErrorHandler = func(writer http.ResponseWriter, request *http.Request, e error) { log.Printf("[%s] %s\n", serverUrl.Host, e.Error()) retries := GetRetryFromContext(request) if retries < 3 { select { case <-time.After(10 * time.Millisecond): ctx := context.WithValue(request.Context(), Retry, retries+1) proxy.ServeHTTP(writer, request.WithContext(ctx)) } return } // after 3 retries, mark this backend as down serverPool.MarkBackendStatus(serverUrl, false) // if the same request routing for few attempts with different backends, increase the count attempts := GetAttemptsFromContext(request) log.Printf("%s(%s) Attempting retry %d\n", request.RemoteAddr, request.URL.Path, attempts) ctx := context.WithValue(request.Context(), Attempts, attempts+1) lb(writer, request.WithContext(ctx)) } 

इस त्रुटि हैंडलर को विकसित करने में, हमने क्लोजर की क्षमताओं का उपयोग किया। यह हमें बाहरी चर जैसे कि सर्वर URL को अपनी विधि में पकड़ने की अनुमति देता है। हैंडलर रिट्री काउंटर की जांच करता है, और यदि यह 3 से कम है, तो हम फिर से उसी सर्वर पर एक ही अनुरोध भेजते हैं। ऐसा इसलिए है, क्योंकि अस्थायी त्रुटियों के कारण, सर्वर हमारे अनुरोधों को छोड़ सकता है, लेकिन यह जल्द ही उपलब्ध हो जाता है (सर्वर में नए ग्राहकों के लिए मुफ्त सॉकेट नहीं हो सकता है)। तो आपको लगभग 10 एमएस के बाद एक नए प्रयास के लिए देरी टाइमर सेट करने की आवश्यकता है। प्रत्येक अनुरोध के साथ हम प्रयासों के काउंटर को बढ़ाते हैं।

प्रत्येक प्रयास की विफलता के बाद, हम सर्वर को निष्क्रिय के रूप में चिह्नित करते हैं।

अब आपको उसी अनुरोध के लिए एक नया सर्वर असाइन करने की आवश्यकता है। हम context पैकेज का उपयोग करके प्रयास काउंटर का उपयोग करेंगे। प्रयासों के काउंटर को बढ़ाने के बाद, हम अनुरोध को संसाधित करने के लिए एक नए सर्वर का चयन करने के लिए इसे पास करते हैं।

हम यह अनिश्चित काल तक नहीं कर सकते हैं, इसलिए हम lb में जांच करेंगे कि अनुरोध की प्रक्रिया को जारी रखने से पहले अधिकतम संख्या में प्रयास हुए हैं या नहीं।

आप अनुरोध से बस प्रयास काउंटर प्राप्त कर सकते हैं, यदि यह अधिकतम तक पहुंचता है, तो हम अनुरोध को बाधित करते हैं।

 // lb load balances the incoming request func lb(w http.ResponseWriter, r *http.Request) { attempts := GetAttemptsFromContext(r) if attempts > 3 { log.Printf("%s(%s) Max attempts reached, terminating\n", r.RemoteAddr, r.URL.Path) http.Error(w, "Service not available", http.StatusServiceUnavailable) return } peer := serverPool.GetNextPeer() if peer != nil { peer.ReverseProxy.ServeHTTP(w, r) return } http.Error(w, "Service not available", http.StatusServiceUnavailable) } 

यह एक पुनरावर्ती कार्यान्वयन है।

संदर्भ पैकेज का उपयोग करना

context पैकेज आपको HTTP अनुरोधों में उपयोगी डेटा संग्रहीत करने की अनुमति देता है। हम अनुरोधों से संबंधित डेटा को ट्रैक करने के लिए सक्रिय रूप से इसका उपयोग करेंगे - Attempt और Retry काउंटर।

सबसे पहले, आपको संदर्भ के लिए कुंजी सेट करने की आवश्यकता है। यह स्ट्रिंग का उपयोग नहीं करने की सिफारिश की जाती है, लेकिन अद्वितीय संख्यात्मक मान। गो के पास स्थिरांक के वृद्धिशील कार्यान्वयन के लिए एक iota कीवर्ड है, जिसमें से प्रत्येक में एक अद्वितीय मूल्य है। यह संख्यात्मक कुंजियों को परिभाषित करने के लिए एक शानदार समाधान है।

 const ( Attempts int = iota Retry ) 

फिर आप मान निकाल सकते हैं, जैसा कि हम आमतौर पर HashMap साथ करते हैं। डिफ़ॉल्ट मान वर्तमान स्थिति पर निर्भर हो सकता है।

 // GetAttemptsFromContext returns the attempts for request func GetRetryFromContext(r *http.Request) int { if retry, ok := r.Context().Value(Retry).(int); ok { return retry } return 0 } 

निष्क्रिय सर्वर सत्यापन

निष्क्रिय चेक गिर गए सर्वरों की पहचान करते हैं और उन्हें पुनर्प्राप्त करते हैं। हम उनकी स्थिति निर्धारित करने के लिए एक निश्चित अंतराल पर उन्हें पिंग करते हैं।

पिंग करने के लिए, टीसीपी कनेक्शन स्थापित करने का प्रयास करें। यदि सर्वर प्रतिक्रिया करता है, तो हम इसे काम करते हुए चिह्नित करते हैं। इस पद्धति को विशिष्ट एंडपॉइंट्स जैसे /status को कॉल करने के लिए अनुकूलित किया जा सकता है। सर्वर पर अतिरिक्त लोड को कम करने के लिए बनाए जाने के बाद कनेक्शन को बंद करना सुनिश्चित करें। अन्यथा, वह इस संबंध को बनाए रखने की कोशिश करेगा और अंततः अपने संसाधनों को समाप्त कर देगा।

 // isAlive checks whether a backend is Alive by establishing a TCP connection func isBackendAlive(u *url.URL) bool { timeout := 2 * time.Second conn, err := net.DialTimeout("tcp", u.Host, timeout) if err != nil { log.Println("Site unreachable, error: ", err) return false } _ = conn.Close() // close it, we dont need to maintain this connection return true } 

अब आप सर्वर को पुनरावृत्त कर सकते हैं और उनकी स्थिति को चिह्नित कर सकते हैं:

 // HealthCheck pings the backends and update the status func (s *ServerPool) HealthCheck() { for _, b := range s.backends { status := "up" alive := isBackendAlive(b.URL) b.SetAlive(alive) if !alive { status = "down" } log.Printf("%s [%s]\n", b.URL, status) } } 

इस कोड को समय-समय पर चलाने के लिए, आप टाइमर को गो में चला सकते हैं। यह आपको चैनल में घटनाओं को सुनने की अनुमति देगा।

 // healthCheck runs a routine for check status of the backends every 2 mins func healthCheck() { t := time.NewTicker(time.Second * 20) for { select { case <-tC: log.Println("Starting health check...") serverPool.HealthCheck() log.Println("Health check completed") } } } 

इस कोड में, <-tC चैनल हर 20 सेकंड में एक मान लौटाएगा। select आपको इस घटना को परिभाषित करने की अनुमति देता है। default स्थिति की अनुपस्थिति में, यह प्रतीक्षा करता है जब तक कि कम से कम एक मामले को निष्पादित नहीं किया जा सकता है।

अब एक अलग गोरोइन में कोड चलाएँ:

 go healthCheck() 

निष्कर्ष

इस लेख में, हमने कई सवालों की जाँच की:

• राउंड रॉबिन एल्गोरिथम
• मानक पुस्तकालय से ReverseProxy
• mutexes
• परमाणु संचालन
• शॉर्ट सर्किट
• कॉलबैक
• चयन ऑपरेशन

हमारे बैलेंसर को बेहतर बनाने के कई और तरीके हैं। उदाहरण के लिए:

• खोज गुंजाइश कम करने के लिए लाइव सर्वर को सॉर्ट करने के लिए हीप का उपयोग करें।
• आंकड़े इकट्ठा करें।
• कम से कम कनेक्शन के साथ भारित राउंड-रॉबिन एल्गोरिथ्म को लागू करें।
• कॉन्फ़िगरेशन फ़ाइलों के लिए समर्थन जोड़ें।

और इसी तरह।

स्रोत कोड यहाँ है