डाटा डिकोटोमी: डाटा र सेवाहरू बीचको सम्बन्धलाई पुनर्विचार गर्दै

नमस्ते सबै! हामीसँग राम्रो समाचार छ, OTUS ले जुनमा फेरि पाठ्यक्रम सुरु गर्दैछ "सफ्टवेयर आर्किटेक्ट", जसको सम्बन्धमा हामी परम्परागत रूपमा तपाईसँग उपयोगी सामग्री साझा गर्छौं।

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

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

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

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

त्यसोभए आज हामी कसरी नियमहरू परिवर्तन भएको छ भनेर हेर्न जाँदैछौं, किन हामीले सेवाहरू र तिनीहरूले एकअर्कालाई पठाउने डेटालाई पुनर्विचार गर्न आवश्यक छ, र त्यसका लागि हामीलाई किन पूर्ण रूपमा फरक टुलकिट चाहिन्छ।

Encapsulation सधैं तपाईंको साथी हुनेछैन

माइक्रो सर्भिसहरूले एकअर्काबाट स्वतन्त्र रूपमा काम गर्न सक्छन्। यो यो सम्पत्ति हो जसले तिनीहरूलाई सबैभन्दा ठूलो मूल्य दिन्छ। यो समान सम्पत्तिले सेवाहरूलाई मापन र वृद्धि गर्न अनुमति दिन्छ। चतुर्भुज प्रयोगकर्ताहरू वा डेटाको पेटाबाइटहरू (यद्यपि तिनीहरूले यहाँ पनि मद्दत गर्न सक्छन्) मा स्केलिंगको सन्दर्भमा धेरै होइन, तर टोली र संगठनहरू निरन्तर बढ्दै जाँदा मानिसहरूको सर्तमा स्केलिङको सन्दर्भमा।

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

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

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

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

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

डाटा डिकोटोमी

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

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

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

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

यी दुई शक्तिहरू आधारभूत हुन्। हामीले निर्माण गर्ने प्रणालीहरूमा सर्वोच्चताको लागि निरन्तर दौडदै, तिनीहरूले हाम्रो धेरै कामलाई अण्डरपिन गर्छन्।

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

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

नराम्रो कुरा, डाटा भोल्युमले सेवा सीमाहरूसँग समस्याहरू बढाउँछ। सेवा भित्र जति धेरै सामान्य डाटा हुन्छ, त्यति नै जटिल इन्टरफेस हुँदै जान्छ र विभिन्न सेवाहरूबाट आउने डाटा सेटहरू संयोजन गर्न त्यति नै गाह्रो हुन्छ।

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

समस्या यो हो कि विभिन्न सेवाहरूले तिनीहरूले उपभोग गरेको डेटालाई फरक रूपमा व्याख्या गर्छन्। यो डाटा सधैं हात मा छ। तिनीहरू परिमार्जन र स्थानीय रूपमा प्रशोधन गरिन्छ। चाँडै नै तिनीहरूले स्रोतमा डेटासँग कुनै पनि काम गर्न बन्द गर्छन्।

जति धेरै उत्परिवर्तनीय प्रतिलिपिहरू, अधिक डाटा समय संग भिन्न हुनेछ।

अझ नराम्रो कुरा, यस्तो डाटालाई पछ्याउने मा सही गर्न गाह्रो छ (MDM यो जहाँ यो साँच्चै काममा आउँछ।) वास्तवमा, केहि जटिल टेक्नोलोजी चुनौतिहरू व्यवसायहरूले विषम डेटाबाट स्टेमको सामना गर्छन् जुन अनुप्रयोगबाट अनुप्रयोगमा फैलिन्छ।

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

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

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

प्रवाह: डेटा र सेवाहरूको लागि विकेन्द्रीकृत दृष्टिकोण

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

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

यो दृष्टिकोण हासिल गर्ने एउटा तरिका भनेको स्ट्रिमिङ प्लेटफर्मको प्रयोग हो। त्यहाँ धेरै विकल्पहरू छन्, तर आज हामी काफ्कालाई विचार गर्नेछौं, किनकि यसको स्टेटफुल स्ट्रिम प्रोसेसिङ प्रयोगले हामीलाई प्रस्तुत समस्यालाई प्रभावकारी रूपमा समाधान गर्न अनुमति दिन्छ।

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

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

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

अपरिवर्तनीय राज्य स्ट्रिम विभाजित गरेर डाटा डिकोटोमीबाट छुटकारा पाउनुहोस्। त्यसपछि स्टेटफुल स्ट्रिम प्रोसेसिङ प्रयोग गरी प्रत्येक सेवामा यो कार्यक्षमता थप्नुहोस्।

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

यसको अखण्डतामा सम्झौता नगरी डाटा साझेदारी गर्नुहोस्। आवश्यक पर्ने हरेक सेवामा स्रोत होइन, प्रकार्यलाई समेट्नुहोस्।

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

त्यसोभए, आज छलफल गरिएको दृष्टिकोणमा धेरै फाइदाहरू छन्:

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

तपाईले देख्न सक्नुहुने रूपमा, यो केवल आराम भन्दा बढी हो। हामीले उपकरणहरूको एक सेट प्राप्त गरेका छौं जसले तपाईंलाई विकेन्द्रीकृत तरिकामा साझा डेटासँग काम गर्न अनुमति दिन्छ।

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

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

पाठ्यक्रम बारे थप जान्नुहोस्।

स्रोत: www.habr.com