सर्विस डिस्कवरी टूल्स और लोड बैलेंसर्स के बीच वैचारिक अंतर क्या है जो नोड स्वास्थ्य की जांच करता है?

Question

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

एलबी के साथ, आप बैलेंसर के पीछे नोड्स का एक गुच्छा क्लस्टर करते हैं, और फिर क्लाइंट बैलेंसर को अनुरोध करते हैं, जो तब (आमतौर पर) क्लस्टर में सभी नोड्स के लिए उन अनुरोधों को राउंड रॉबिन करते हैं।

सेवा खोज (Consul, ZK, आदि) के साथ, आप एक केंद्रीकृत "आम सहमति" सेवा का निर्धारण क्या नोड विशेष सेवा के लिए स्वस्थ हैं, और अपने अनुप्रयोग नोड्स सेवा स्वस्थ होने के रूप में समझे को जोड़ता करते हैं। इसलिए सेवा खोज और लोड संतुलन दो अलग-अलग अवधारणाएं हैं, सेवा खोज आपको सुविधाजनक साइड इफेक्ट के रूप में संतुलित संतुलन प्रदान करती है।

लेकिन, अगर लोड संतुलन (माना HAProxy या nginx) की निगरानी और स्वास्थ्य की जांच में बनाया गया है, तो आप काफी सेवा खोज लोड संतुलन का एक पक्ष प्रभाव के रूप में मिलता है! मतलब, अगर मेरा एलबी अपने क्लस्टर में एक अस्वास्थ्यकर नोड के अनुरोध को अग्रेषित नहीं करना चाहता है, तो यह कार्यात्मक रूप से एक सर्वसम्मति सर्वर के बराबर है जो मेरे ऐप को एक असहाय नोड से कनेक्ट नहीं करने के लिए कहता है।

तो मेरे लिए, सेवा खोज उपकरण लोड बैलेंसर्स के बराबर "6-इन-वन, आधा दर्जन-इन-द-अन्य" जैसा महसूस करते हैं। क्या मुझसे कोई चूक हो रही है? यदि किसी के पास लोड संतुलित माइक्रोस्कोर्सेस पर पूरी तरह से एक अनुप्रयोग आर्किटेक्चर की भविष्यवाणी की गई है, तो सेवा खोज-आधारित मॉडल पर स्विच करने के लिए लाभ (या नहीं) क्या है?

Answer 1

लोड बैलेंसर्स को आम तौर पर यातायात लोड को संतुलित करने वाले संसाधनों के अंतराल की आवश्यकता होती है। सूक्ष्मदर्शी और कंटेनर आधारित अनुप्रयोगों के विकास के साथ, रनटाइम ने गतिशील कंटेनर (डॉकर कंटेनर) बनाए हैं, जो अल्पकालिक हैं और इसमें स्थिर अंत बिंदु नहीं हैं। ये कंटेनर एंडपॉइंट्स अल्पकालिक हैं और वे बदलते हैं और स्केलिंग या अन्य कारणों के लिए बनाए जाते हैं। कंसुल जैसे सेवा खोज उपकरण गतिशील रूप से बनाए गए कंटेनरों (डॉकर कंटेनर) की एंडपॉइंट्स जानकारी को स्टोर करने के लिए उपयोग किए जाते हैं। कंटेनर होस्ट पर चल रहे कंसुल-रजिस्ट्रेटर जैसे उपकरण कंसुल जैसे सेवा खोज उपकरण में कंटेनर एंड पॉइंट पंजीकृत करते हैं। कंसुल-टेम्पलेट जैसे टूल्स कंसुल में कंटेनर एंड पॉइंट्स में बदलावों को सुनेंगे और ट्रैफिक भेजने के लिए लोड बैलेंसर (nginx) अपडेट करेंगे। इस प्रकार सर्विस डिस्कवरी टूल्स जैसे कंसुल और लोड बैलेंसिंग टूल्स जैसे कि नग्निक्स सह-अस्तित्व में क्रमशः रनटाइम सर्विस डिस्कवरी और लोड बैलेंसिंग क्षमता प्रदान करने के लिए मौजूद हैं।

अनुवर्ती: पारंपरिक वीएम की तरह "स्थायी" नोड्स बनाम अस्थायी नोड्स (जो आते हैं और जाते हैं, रहते हैं और मरते हैं) के क्या फायदे हैं?

[डी डी जी]: चीज़ें है कि मेरे मन को जल्दी आओ: अल्पकालिक नोड्स डोकर कंटेनर की तरह एपीआई आदि जैसे राज्यविहीन सेवाओं के लिए उपयुक्त है (इस बाहरी मात्रा का उपयोग करते हुए लगातार कंटेनरों के लिए कर्षण नहीं है - मात्रा ड्राइवरों आदि)

1. गति: बादल के युग में हम बाहर पैमाने पर करना चाहते हैं और में: ऊपर स्पिनिंग या नष्ट अल्पकालिक कंटेनर (छवि से डोकर कंटेनर) कम से कम 500 मिली सेकंड के रूप में पारंपरिक VMs

खड़े में

2. लचीला इंफ्रास्ट्रक्चर मिनट के लिए विरोध लेता है उपयोगकर्ताओं की मांग के अनुसार जो दर्शाता है कि वहां होगा प्रकृति में क्षणिक के tainers (आईपी आदि पर पकड़ नहीं कर सकते हैं)। एक हफ्ते के लिए मार्करिंग अभियान के बारे में सोचें जिसके लिए हम यातायात टीपीएस में 200% की वृद्धि की उम्मीद करते हैं, कंटेनर के साथ जल्दी पैमाने पर स्केल करते हैं और फिर अभियान चलाते हैं, इसे नष्ट कर देते हैं।

3. संसाधन उपयोग: डेटा केंद्र या क्लाउड अब एक बड़ा कंप्यूटर (गणना क्लस्टर) है और कंटेनर अधिकतम संसाधन उपयोग के लिए गणना क्लस्टर पैक करते हैं और कमजोर मांग के दौरान कम बिल/संसाधन उपयोग के लिए आधारभूत संरचना को नष्ट कर देते हैं। इस के

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

Answer 2

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

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

Answer 3

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

इसके अलावा, सेवा-खोज केवल आपको अंतिम स्कैन के रूप में एक तस्वीर देता है, न कि वास्तविक समय (निश्चित रूप से निर्भर करता है जिस पर आपने स्कैनिंग अंतराल सेट किया है), जबकि लोड संतुलन एक अप-टू- आपके आवेदन के स्वास्थ्य की तारीख तस्वीर।