👩🏾‍⚕️ 📋 🏂🏽 डेटा के डिक्टोटॉमी: डेटा और सेवाओं के साथ संबंध को फिर से जोड़ना 🧙 🚢 🏙️

सभी को नमस्कार! हमारे पास बहुत अच्छी खबर है, जून में OTUS फिर से "सॉफ्टवेयर आर्किटेक्ट" कोर्स शुरू करेगा , जिसके संबंध में हम पारंपरिक रूप से आपके साथ उपयोगी सामग्री साझा करते हैं।

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

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

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

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

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

एनकैप्सुलेशन हमेशा आपका दोस्त नहीं होगा

माइक्रोसर्विसेज एक दूसरे के स्वतंत्र रूप से काम कर सकते हैं। यह वह संपत्ति है जो उन्हें सबसे बड़ा मूल्य देती है। समान संपत्ति सेवाओं को पैमाने और बढ़ने की अनुमति देती है। क्वाड्रिलियन उपयोगकर्ताओं या डेटा की पेटाबाइट्स को कम करने के मामले में इतना अधिक नहीं है (हालांकि यहां वे मदद कर सकते हैं), लेकिन लोगों के दृष्टिकोण से स्केलिंग के मामले में, क्योंकि टीम और संगठन लगातार बढ़ रहे हैं।

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

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

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

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

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

डेटा द्विभाजन

सेवा-उन्मुख दृष्टिकोण पहले से ही मौजूद हो सकते हैं, लेकिन सेवाओं के बीच बड़ी मात्रा में डेटा का आदान-प्रदान कैसे करें, इस बारे में उन्हें अभी भी बहुत कम जानकारी है।

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

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

और यहाँ एक दुविधा पैदा होती है। अंतर्विरोध। विरोधाभास। आखिरकार, सूचना प्रणाली डेटा प्रदान करने के बारे में हैं, और सेवाएं छिपाने के बारे में हैं।

ये दोनों बल मौलिक हैं। वे हमारे अधिकांश कार्यों का आधार बनाते हैं, हम जो सिस्टम बनाते हैं उसमें उत्कृष्टता के लिए निरंतर प्रयास करते हैं।

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

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

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

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

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

जितनी अधिक संख्या में आपस में परिवर्तन होगा, उतना ही डेटा समय के साथ बदलता रहेगा।

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

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

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

डेटा इन्सॉल्वेंसी साइकिल

स्ट्रीम: डेटा और सेवाओं के लिए एक विकेंद्रीकृत दृष्टिकोण

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

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

इस दृष्टिकोण को प्राप्त करने का एक तरीका स्ट्रीमिंग प्लेटफॉर्म का उपयोग करना है। कई विकल्प हैं, लेकिन आज हम काफ्का पर विचार करेंगे, क्योंकि इसकी स्टेटफुल स्ट्रीम प्रोसेसिंग का उपयोग करने से हम प्रस्तुत समस्या को प्रभावी ढंग से हल कर सकते हैं।

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

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

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

राज्यों के प्रतिरक्षा प्रवाह को विभाजित करके डेटा के द्विभाजन से छुटकारा पाएं। फिर स्टेटफुल स्ट्रीम प्रोसेसिंग का उपयोग करके इस सुविधा को प्रत्येक सेवा में जोड़ें।

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

डेटा साझा करें ताकि इसकी अखंडता का उल्लंघन न हो। प्रत्येक सेवा में एक फ़ंक्शन को एनकैप्सुलेट करें, न कि स्रोत के रूप में।

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

इसलिए, आज के दृष्टिकोण के कई फायदे हैं:

डेटा का उपयोग साझा धाराओं के रूप में किया जाता है जिन्हें लॉग में लंबे समय तक संग्रहीत किया जा सकता है, और साझा डेटा के साथ काम करने के लिए तंत्र को प्रत्येक व्यक्तिगत संदर्भ में वायर्ड किया जाता है, जो सेवाओं को जल्दी और आसानी से काम करने की अनुमति देता है। इस तरह, आप डेटा के द्विभाजन को संतुलित कर सकते हैं।
, , . .
Stateful Stream Processing , , .
, , , -.
, . , .
, .

जैसा कि आप देख सकते हैं, यह सिर्फ REST से अधिक है। हमें एक उपकरण मिला है जो आपको साझा डेटा के विकेंद्रीकृत होने के साथ काम करने की अनुमति देता है।

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

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

डेटा के डिक्टोटॉमी: डेटा और सेवाओं के साथ संबंध को फिर से जोड़ना

एनकैप्सुलेशन हमेशा आपका दोस्त नहीं होगा

डेटा द्विभाजन

स्ट्रीम: डेटा और सेवाओं के लिए एक विकेंद्रीकृत दृष्टिकोण

More articles: