डेटा द्विभाजन: डेटा और सेवाओं के बीच संबंध पर पुनर्विचार

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

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

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

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

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

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

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

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

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

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

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

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

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

डेटा द्वंद्व

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

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

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

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

ये दो ताकतें मौलिक हैं। वे हमारे अधिकांश कार्यों को रेखांकित करते हैं, हमारे द्वारा निर्मित प्रणालियों में उत्कृष्टता के लिए लगातार लड़ते रहते हैं।

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

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

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

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

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

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

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

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

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

डेटा विफलता का चक्र

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

कोर्स के बारे में और जानें।

स्रोत: www.habr.com