पुस्तक "वितरित प्रणाली। डिजाइन पैटर्न

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

ब्रेंडन बर्न्स, क्लाउड प्रौद्योगिकियों और कुबेरनेट्स के एक प्रतिष्ठित विशेषज्ञ, इस छोटे से काम में वितरित सिस्टम के उचित डिजाइन के लिए पूर्ण न्यूनतम आवश्यक हैं। इस पुस्तक में डिस्ट्रीब्यूटेड सिस्टमों के डिजाइनिंग के व्यापक पैटर्न के बारे में बताया गया है। यह आपको न केवल खरोंच से ऐसे सिस्टम बनाने में मदद करेगा, बल्कि प्रभावी रूप से मौजूदा लोगों को भी परिवर्तित करेगा।

अंश। डेकोरेटर पैटर्न। एक अनुरोध या प्रतिक्रिया में कनवर्ट करें

FaaS आदर्श है जब आपको सरल कार्यों की आवश्यकता होती है जो इनपुट डेटा को संसाधित करते हैं और फिर उन्हें अन्य सेवाओं में स्थानांतरित करते हैं। इस तरह के पैटर्न का उपयोग किसी अन्य सेवा द्वारा भेजे या प्राप्त HTTP अनुरोधों को बढ़ाने या सजाने के लिए किया जा सकता है। यह पैटर्न योजनाबद्ध रूप से अंजीर में दिखाया गया है। 8.1।

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


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

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

इस अध्याय के उदाहरणों में, हम kubeless FaaS Framework (https://github.com/kubeless/kubeless) का उपयोग करेंगे। Kubernet Kubernetes कंटेनर ऑर्केस्ट्रेटर सेवा के शीर्ष पर तैनात किया गया है। यदि आपने कुबर्नेटेस क्लस्टर पहले ही तैयार कर लिया है, तो कुबलेस की स्थापना के साथ आगे बढ़ें, जिसे संबंधित साइट (https://github.com/kubeless/kubeless/releases) से डाउनलोड किया जा सकता है। एक बार जब आपके पास कुबूल हो जाए, तो आप इसे कुबूल स्थापित कमांड के साथ क्लस्टर में स्थापित कर सकते हैं।

Kubeless को तृतीय-पक्ष Kubernetes API ऐड-ऑन के रूप में स्थापित किया गया है। इसका मतलब यह है कि इंस्टॉलेशन के बाद इसे kubectl कमांड-लाइन टूल के हिस्से के रूप में इस्तेमाल किया जा सकता है। उदाहरण के लिए, क्लस्टर में तैनात फ़ंक्शंस को kubectl get फ़ंक्शन को चलाकर देखा जा सकता है। वर्तमान में आपके क्लस्टर में कोई फ़ंक्शंस तैनात नहीं हैं।

कार्यशाला। अनुरोध प्रसंस्करण से पहले डिफ़ॉल्ट मानों का प्रतिस्थापन

आप FaaS में डेकोरेटर पैटर्न की उपयोगिता प्रदर्शित कर सकते हैं, पैरामीटर के लिए RESTful कॉल में डिफ़ॉल्ट मानों को प्रतिस्थापित करने के उदाहरण का उपयोग करते हुए जिनके मान उपयोगकर्ता द्वारा निर्धारित नहीं किए गए हैं। FaaS के साथ, यह काफी सरल है। डिफ़ॉल्ट लुकअप फ़ंक्शन पाइथन में लिखा गया है:

#  -,   #   def handler(context): #    obj = context.json #   "name" ,   #   if obj.get("name", None) is None: obj["name"] = random_name() #    'color',   #   'blue' if obj.get("color", None) is None: obj["color"] = "blue" #  API-     #   #    return call_my_api(obj) 

इस फ़ंक्शन को एक फ़ाइल में सहेजें, जिसे defaults.py कहा जाता है। उस API के साथ call_my_api कॉल को बदलना याद रखें जिसे आप चाहते हैं। इस डिफ़ॉल्ट प्रतिस्थापन फ़ंक्शन को निम्न कमांड के साथ एक कुबली फ़ंक्शन के रूप में पंजीकृत किया जा सकता है:

 kubeless function deploy add-defaults \ --runtime python27 \ --handler defaults.handler \ --from-file defaults.py \ --trigger-http 

इसका परीक्षण करने के लिए, आप कुबूल उपकरण का उपयोग कर सकते हैं:

 kubeless function call add-defaults --data '{"name": "foo"}' 

डेकोरेटर पैटर्न दिखाता है कि डिफ़ॉल्ट मूल्यों को मान्य या प्रतिस्थापित करने जैसी अतिरिक्त सुविधाओं के साथ मौजूदा एपीआई को अनुकूलित और विस्तारित करना कितना आसान है।

इवेंट हैंडलिंग

अधिकांश सिस्टम क्वेरी-उन्मुख हैं - वे उपयोगकर्ता और एपीआई अनुरोधों के निरंतर प्रवाह की प्रक्रिया करते हैं। इसके बावजूद, कुछ घटना-उन्मुख प्रणालियाँ हैं। अनुरोध और घटना के बीच अंतर, यह मुझे लगता है, सत्र की अवधारणा में निहित है। अनुरोध एक बड़ी सहभागिता प्रक्रिया (सत्र) के भाग हैं। सामान्य स्थिति में, प्रत्येक उपयोगकर्ता अनुरोध वेब एप्लिकेशन या संपूर्ण के रूप में एपीआई के साथ बातचीत करने की प्रक्रिया का हिस्सा है। मैं घटनाओं को "एक-समय" के रूप में देखता हूं, प्रकृति में अतुल्यकालिक। घटनाएँ महत्वपूर्ण हैं और तदनुसार नियंत्रित किया जाना चाहिए, लेकिन वे बातचीत के मुख्य संदर्भ से बाहर हो जाते हैं और उनके उत्तर कुछ समय बाद ही आते हैं। एक घटना का एक उदाहरण एक निश्चित सेवा के लिए एक उपयोगकर्ता की सदस्यता है, जो ग्रीटिंग पत्र भेजने का कारण होगा; एक साझा फ़ोल्डर में एक फ़ाइल अपलोड करना, जो इस फ़ोल्डर के सभी उपयोगकर्ताओं को सूचनाएं भेजने का नेतृत्व करेगा; या यहां तक ​​कि रिबूट के लिए कंप्यूटर तैयार करना, जो ऑपरेटर या स्वचालित प्रणाली को सूचित करेगा कि उचित कार्रवाई की आवश्यकता है।

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

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

कार्यशाला। दो-कारक प्रमाणीकरण लागू करना

दो-कारक प्रमाणीकरण इंगित करता है कि उपयोगकर्ता को सिस्टम में प्रवेश करने के लिए, उसे कुछ ऐसा चाहिए जो वह जानता हो (उदाहरण के लिए, एक पासवर्ड), और कुछ ऐसा जो उसके पास है (उदाहरण के लिए, एक फ़ोन नंबर)। टू-फैक्टर ऑथेंटिकेशन सिर्फ एक पासवर्ड से काफी बेहतर है, क्योंकि एक हमलावर को एक्सेस हासिल करने के लिए आपका पासवर्ड और आपका फोन नंबर दोनों चोरी करना होगा।

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

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

 def two_factor(context): #     code = random.randint(1 00000, 9 99999) #        user = context.json["user"] register_code_with_login_service(user, code) #      Twillio account = "my-account-sid" token = "my-token" client = twilio.rest.Client(account, token) user_number = context.json["phoneNumber"] msg = ", {},   : {}.".format(user, code) message = client.api.account.messages.create(to=user_number, from_="+1 20652 51212", body=msg) return {"status": "ok"} 

फिर कुबूल में FaaS पंजीकृत करें:

 kubeless function deploy add-two-factor \ --runtime python27 \ --handler two_factor.two_factor \ --from-file two_factor.py \ --trigger-http 

उपयोगकर्ता द्वारा सही पासवर्ड दर्ज करने के बाद क्लाइंट-साइड जावास्क्रिप्ट कोड से इस फ़ंक्शन का एक उदाहरण एसिंक्रोनस रूप से उत्पन्न किया जा सकता है। वेब इंटरफ़ेस तुरंत कोड दर्ज करने के लिए पृष्ठ प्रदर्शित कर सकता है, और उपयोगकर्ता, जैसे ही वह कोड प्राप्त करता है, उसे लॉगिन सेवा के बारे में सूचित कर सकता है जिसमें यह कोड पहले से पंजीकृत है।

इसलिए, Faa दृष्टिकोण ने एक सरल, अतुल्यकालिक, घटना-उन्मुख सेवा के विकास की सुविधा प्रदान की है, जब उपयोगकर्ता सिस्टम पर लॉग ऑन करता है।

घटना के वाहक

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

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

इस तरह की पाइपलाइन और माइक्रोसिस्टवर्क वास्तुकला के बीच अंतर क्या है? दो महत्वपूर्ण अंतर हैं। सेवा कार्यों और लगातार चलने वाली सेवाओं के बीच पहला और सबसे महत्वपूर्ण अंतर यह है कि घटना पाइपलाइन अनिवार्य रूप से घटना संचालित हैं। माइक्रोसिस्टवर्क वास्तुकला, इसके विपरीत, लगातार काम करने वाली सेवाओं का एक सेट है। इसके अलावा, इवेंट पाइपलाइन अतुल्यकालिक हो सकती है और कई प्रकार की घटनाओं को बांध सकती है। यह कल्पना करना कठिन है कि जीरा के आवेदन की मंजूरी को एक माइक्रोसैस सर्विस में कैसे एकीकृत किया जा सकता है। उसी समय, यह कल्पना करना आसान है कि यह घटना पाइपलाइन में कैसे एकीकृत करता है।

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

कार्यशाला। एक नए उपयोगकर्ता को पंजीकृत करने के लिए एक पाइपलाइन का कार्यान्वयन

नए उपयोगकर्ता के पंजीकरण के लिए कार्यों के अनुक्रम को लागू करने के कार्य पर विचार करें। एक नया खाता बनाते समय, क्रियाओं की एक पूरी श्रृंखला हमेशा की जाती है, उदाहरण के लिए, एक स्वागत योग्य ईमेल भेजना। ऐसे कई कार्य भी होते हैं जो हर बार नहीं किए जा सकते हैं, उदाहरण के लिए, किसी उत्पाद के नए संस्करणों के बारे में ई-मेल न्यूज़लेटर की सदस्यता लेना (जिसे स्पैम भी कहा जाता है)।

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

कई एफएएएस सेवाओं की एक घटना पाइपलाइन के रूप में उपयोगकर्ता लॉगिन के कार्यान्वयन पर विचार करें। इस पृथक्करण के साथ, उपयोगकर्ता निर्माण फ़ंक्शन को यह पता नहीं है कि उपयोगकर्ता लॉगिन के दौरान क्या होता है। उसकी दो सूचियाँ हैं:

• आवश्यक कार्यों की एक सूची (उदाहरण के लिए, एक स्वागत योग्य ईमेल भेजना);
• वैकल्पिक क्रियाओं की एक सूची (उदाहरण के लिए, एक न्यूज़लेटर सदस्यता)।

इनमें से प्रत्येक क्रिया को FaaS के रूप में भी लागू किया जाता है, और क्रियाओं की सूची HTTP कॉलबैक फ़ंक्शन की सूची से अधिक कुछ नहीं है। इसलिए, उपयोगकर्ता निर्माण फ़ंक्शन का निम्न रूप होता है:

 def create_user(context): #      for key, value in required.items(): call_function(value.webhook, context.json) #    #     for key, value in optional.items(): if context.json.get(key, None) is not None: call_function(value.webhook, context.json) 

प्रत्येक हैंडलर को अब FaaS सिद्धांत के अनुसार भी लागू किया जा सकता है:

 def email_user(context): #    user = context.json['username'] msg = ', {}, ,     !".format(user) send_email(msg, contex.json['email]) def subscribe_user(context): #    email = context.json['email'] subscribe_user(email) 

इस तरह से विघटित, FaaS सेवा बहुत सरल हो जाती है, जिसमें कोड की कम लाइनें होती हैं और एक विशिष्ट कार्य के कार्यान्वयन पर केंद्रित होती है। माइक्रोसर्विस दृष्टिकोण कोड लेखन को सरल बनाता है, लेकिन तीन अलग-अलग माइक्रोसर्विस को तैनात करने और प्रबंधित करने में कठिनाइयों का कारण बन सकता है। यहाँ एफएएएस दृष्टिकोण अपने सभी महिमा में साबित होता है, क्योंकि इसके उपयोग के परिणामस्वरूप कोड के छोटे टुकड़ों का प्रबंधन करना बहुत सरल हो जाता है। इवेंट पाइपलाइन के रूप में एक उपयोगकर्ता बनाने की प्रक्रिया का विज़ुअलाइज़ेशन हमें सामान्य शब्दों में यह समझने की भी अनुमति देता है कि उपयोगकर्ता द्वारा पाइपलाइन के भीतर फ़ंक्शन से फ़ंक्शन के संदर्भ में परिवर्तन को ट्रैक करके, वास्तव में क्या होता है।

»पुस्तक की अधिक जानकारी प्रकाशक की वेबसाइट पर पाई जा सकती है
» सामग्री
» अंश

डिजाइनरों के लिए कूपन पर 20% की छूट - डिज़ाइन पैटर्न

पुस्तक के पेपर संस्करण के भुगतान पर, पुस्तक का एक इलेक्ट्रॉनिक संस्करण ई-मेल द्वारा भेजा जाता है।