डेटा डिकोटॉमी: डेटा आणि सेवा यांच्यातील संबंधांवर पुनर्विचार करणे

सर्वांना नमस्कार! आमच्याकडे चांगली बातमी आहे, OTUS जूनमध्ये पुन्हा अभ्यासक्रम सुरू करत आहे "सॉफ्टवेअर आर्किटेक्ट", ज्याच्या संदर्भात आम्ही पारंपारिकपणे आपल्याशी उपयुक्त सामग्री सामायिक करतो.

जर तुम्ही कोणत्याही संदर्भाशिवाय ही संपूर्ण मायक्रोसर्व्हिसेस गोष्ट पाहिली असेल, तर तुम्हाला हे थोडे विचित्र वाटले म्हणून क्षमा केली जाईल. नेटवर्कद्वारे कनेक्ट केलेल्या तुकड्यांमध्ये अनुप्रयोग विभाजित करणे म्हणजे परिणामी वितरित प्रणालीमध्ये जटिल दोष सहनशीलता मोड जोडणे आवश्यक आहे.

जरी या दृष्टिकोनामध्ये ते अनेक स्वतंत्र सेवांमध्ये मोडणे समाविष्ट आहे, परंतु अंतिम लक्ष्य त्या सेवा वेगवेगळ्या मशीनवर चालवण्यापेक्षा बरेच काही आहे. आम्ही येथे बाह्य जगाशी परस्परसंवादाबद्दल बोलत आहोत, जे त्याचे सार देखील वितरीत केले जाते. तांत्रिक अर्थाने नाही, तर त्या इकोसिस्टमच्या अर्थाने ज्यामध्ये अनेक लोक, संघ, कार्यक्रम असतात आणि या प्रत्येक भागाला त्याचे कार्य करणे आवश्यक आहे.

कंपन्या, उदाहरणार्थ, वितरीत प्रणालींचा एक संग्रह आहे जो एकत्रितपणे काही ध्येय साध्य करण्यासाठी योगदान देतात. आम्ही अनेक दशकांपासून या वस्तुस्थितीकडे दुर्लक्ष केले आहे, आमच्या स्वतःच्या वेगळ्या उद्दिष्टांवर लक्ष केंद्रित करताना FTPing फाइल्सद्वारे किंवा एंटरप्राइझ एकत्रीकरण साधने वापरून एकीकरण साधण्याचा प्रयत्न करत आहोत. परंतु सेवांच्या आगमनाने सर्व काही बदलले. सेवांनी आम्हाला क्षितिजाच्या पलीकडे पाहण्यात आणि एकत्र काम करणाऱ्या परस्परावलंबी कार्यक्रमांचे जग पाहण्यास मदत केली आहे. तथापि, यशस्वीरित्या कार्य करण्यासाठी, दोन मूलभूतपणे भिन्न जग ओळखणे आणि डिझाइन करणे आवश्यक आहे: बाह्य जग, जिथे आपण इतर अनेक सेवांच्या इकोसिस्टममध्ये राहतो आणि आपले वैयक्तिक, अंतर्गत जग, जिथे आपण एकटे राज्य करतो.

हे वितरित जग आपण ज्यामध्ये वाढलो आणि ज्याची आपण सवय झालो त्यापेक्षा वेगळे आहे. पारंपारिक मोनोलिथिक आर्किटेक्चरची तत्त्वे टीकेला टिकत नाहीत. त्यामुळे या सिस्टीम्स बरोबर मिळवणे म्हणजे एक मस्त व्हाईटबोर्ड आकृती किंवा संकल्पनेचा छान पुरावा तयार करण्यापेक्षा अधिक आहे. मुद्दा हा आहे की अशी प्रणाली दीर्घ कालावधीत यशस्वीरित्या कार्य करते याची खात्री करणे. सुदैवाने, सेवा काही काळापासून आहेत, जरी त्या वेगळ्या दिसत आहेत. SOA धडे अजूनही संबंधित आहेत, अगदी डॉकर, कुबर्नेट्स आणि किंचित जर्जर हिपस्टर दाढीसह देखील अनुभवी आहेत.

त्यामुळे आज आम्ही नियम कसे बदलले आहेत, आम्ही सेवांशी संपर्क साधण्याचा मार्ग आणि ते एकमेकांना दिलेला डेटा का पुनर्विचार करणे आवश्यक आहे आणि ते करण्यासाठी आम्हाला पूर्णपणे भिन्न साधनांची आवश्यकता का आहे ते पाहू.

Encapsulation नेहमी तुमचा मित्र नसतो

सूक्ष्म सेवा एकमेकांपासून स्वतंत्रपणे कार्य करू शकतात. हीच मालमत्ता त्यांना सर्वात मोठे मूल्य देते. हीच मालमत्ता सेवांना स्केल आणि वाढू देते. चतुर्भुज वापरकर्ते किंवा डेटाच्या पेटाबाइट्सपर्यंत स्केलिंग करण्याच्या अर्थाने (जरी ते तेथे देखील मदत करू शकतात), परंतु कार्यसंघ आणि संस्था सतत विकसित होत असताना लोकांच्या दृष्टीने स्केलिंगच्या अर्थाने.

मात्र, स्वातंत्र्य ही दुधारी तलवार आहे. म्हणजेच, सेवा स्वतः सहज आणि नैसर्गिकरित्या चालू शकते. परंतु जर एखादे कार्य एखाद्या सेवेमध्ये लागू केले गेले असेल ज्यासाठी दुसर्‍या सेवेचा वापर आवश्यक असेल, तर आम्हाला दोन्ही सेवांमध्ये जवळजवळ एकाच वेळी बदल करावे लागतील. मोनोलिथमध्ये हे करणे सोपे आहे, तुम्ही फक्त बदल करा आणि ते रिलीझ करण्यासाठी पाठवा, परंतु स्वतंत्र सेवा सिंक्रोनाइझ करण्याच्या बाबतीत अधिक समस्या असतील. संघ आणि प्रकाशन चक्रांमधील समन्वय चपळता नष्ट करते.

मानक दृष्टिकोनाचा एक भाग म्हणून, ते सेवांमध्ये कार्यक्षमता स्पष्टपणे विभाजित करून त्रासदायक एंड-टू-एंड बदल टाळण्याचा प्रयत्न करतात. एकल साइन-ऑन सेवा येथे एक चांगले उदाहरण असू शकते. त्याची स्पष्टपणे परिभाषित भूमिका आहे जी ती इतर सेवांपेक्षा वेगळी करते. या स्पष्ट पृथक्करणाचा अर्थ असा आहे की आजूबाजूच्या सेवांवर वेगाने बदलणाऱ्या मागणीच्या जगात, एकल साइन-ऑन सेवा बदलण्याची शक्यता नाही. हे काटेकोरपणे मर्यादित संदर्भात अस्तित्वात आहे.

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

बर्‍याच व्यवसाय सेवा समान डेटा प्रवाह सामायिक करतात, म्हणून त्यांचे कार्य नेहमीच एकमेकांशी जोडलेले असते.

अशा प्रकारे आपण बोलण्यासारख्या महत्त्वाच्या मुद्द्यावर आलो आहोत. सेवा या पायाभूत सुविधांच्या घटकांसाठी चांगल्या प्रकारे कार्य करतात जे मोठ्या प्रमाणात अलगावमध्ये कार्य करतात, बहुतेक व्यावसायिक सेवा अधिक जवळून एकमेकांशी जोडल्या जातात.

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

सेवा-केंद्रित दृष्टीकोन आधीच अस्तित्वात असू शकतात, परंतु सेवांमध्ये मोठ्या प्रमाणात डेटा कसा सामायिक करायचा याबद्दल त्यांच्याकडे अद्याप अंतर्दृष्टी नाही.

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

तथापि, माहिती प्रणालींचा encapsulation शी फारसा संबंध नाही. खरं तर, ते अगदी उलट आहे. डेटाबेस ते संचयित केलेल्या डेटामध्ये प्रवेश प्रदान करण्यासाठी सर्वकाही करतात. ते शक्तिशाली घोषणात्मक इंटरफेससह येतात जे आपल्याला आवश्यकतेनुसार डेटा सुधारण्याची परवानगी देतात. अशी कार्यक्षमता प्राथमिक संशोधनाच्या टप्प्यावर महत्त्वाची असते, परंतु सतत विकसित होणाऱ्या सेवेच्या वाढत्या जटिलतेचे व्यवस्थापन करण्यासाठी नाही.

आणि इथे एक पेच निर्माण होतो. विरोधाभास. द्विभाजन. तथापि, माहिती प्रणाली डेटा प्रदान करण्याबद्दल आहेत आणि सेवा लपविण्याबद्दल आहेत.

या दोन शक्ती मूलभूत आहेत. ते आमच्या बर्‍याच कामाला अधोरेखित करतात, आम्ही तयार करत असलेल्या प्रणालींमध्ये उत्कृष्टतेसाठी सतत लढत असतात.

सेवा प्रणाली जसजशी वाढतात आणि विकसित होत जातात, तसतसे आम्ही डेटा द्वंद्वाचे अनेक प्रकारे परिणाम पाहतो. एकतर सेवा इंटरफेस वाढेल, कार्यक्षमतेची सतत वाढणारी श्रेणी प्रदान करेल आणि एका अतिशय फॅन्सी होमग्रोन डेटाबेससारखे दिसू लागेल किंवा आम्ही निराश होऊ आणि सेवेकडून सेवेपर्यंत डेटाचे संपूर्ण संच पुनर्प्राप्त करण्यासाठी किंवा हलवण्याचा काही मार्ग लागू करू.

या बदल्यात, फॅन्सी होमग्राउन डेटाबेससारखे दिसणारे काहीतरी तयार केल्याने संपूर्ण समस्या उद्भवतील. ते धोकादायक का आहे याबद्दल आम्ही तपशीलात जाणार नाही सामायिक डेटाबेस, फक्त असे म्हणूया की ते महत्त्वपूर्ण खर्चिक अभियांत्रिकी आणि ऑपरेशनलचे प्रतिनिधित्व करते अडचणी ते वापरण्याचा प्रयत्न करणाऱ्या कंपनीसाठी.

सर्वात वाईट म्हणजे डेटा व्हॉल्यूम सेवा सीमा समस्या वाढवते. सेवेमध्ये जितका अधिक सामायिक केलेला डेटा असेल तितका इंटरफेस अधिक जटिल होईल आणि वेगवेगळ्या सेवांमधून येणारा डेटा संच एकत्र करणे अधिक कठीण होईल.

संपूर्ण डेटा संच काढण्याच्या आणि हलवण्याच्या पर्यायी पध्दतीमध्ये देखील समस्या आहेत. या प्रश्नासाठी एक सामान्य दृष्टीकोन फक्त संपूर्ण डेटासेट पुनर्प्राप्त करणे आणि संचयित करणे, आणि नंतर प्रत्येक वापरणार्‍या सेवेमध्ये स्थानिक पातळीवर संग्रहित करणे असे दिसते.

समस्या अशी आहे की भिन्न सेवा वापरत असलेल्या डेटाचा वेगळ्या पद्धतीने अर्थ लावतात. हा डेटा नेहमी हातात असतो. ते सुधारित केले जातात आणि स्थानिक पातळीवर प्रक्रिया केली जातात. स्त्रोतातील डेटासह त्यांच्यात काहीही साम्य नसणे खूप लवकर थांबते.

प्रती जितक्या अधिक बदलता येतील, तितका डेटा कालांतराने बदलेल.

प्रकरण आणखी वाईट करण्यासाठी, असा डेटा पूर्वनिरीक्षणात दुरुस्त करणे कठीण आहे (MDM येथेच ते खरोखर बचावासाठी येऊ शकते). खरं तर, व्यवसायांना सामोरे जाणाऱ्या काही गुंतागुंतीच्या तंत्रज्ञानाच्या समस्या या भिन्न डेटामुळे उद्भवतात जे अनुप्रयोग ते अनुप्रयोगापर्यंत गुणाकार करतात.

या समस्येवर उपाय शोधण्यासाठी, आम्हाला शेअर केलेल्या डेटाबद्दल वेगळ्या पद्धतीने विचार करणे आवश्यक आहे. आम्ही तयार करत असलेल्या आर्किटेक्चरमध्ये त्या प्रथम श्रेणीच्या वस्तू बनल्या पाहिजेत. पॅट हेलँड अशा डेटाला "बाह्य" म्हणतात आणि हे एक अतिशय महत्वाचे वैशिष्ट्य आहे. आम्हाला एन्कॅप्स्युलेशनची आवश्यकता आहे जेणेकरून आम्ही सेवेचे अंतर्गत कार्य उघड करू शकत नाही, परंतु आम्हाला सेवांसाठी सामायिक डेटामध्ये प्रवेश करणे सोपे करणे आवश्यक आहे जेणेकरून ते त्यांचे कार्य योग्यरित्या करू शकतील.

समस्या अशी आहे की आज कोणताही दृष्टीकोन संबंधित नाही, कारण सेवा इंटरफेस किंवा संदेशन किंवा सामायिक डेटाबेस बाह्य डेटासह कार्य करण्यासाठी चांगला उपाय देऊ शकत नाही. सेवा इंटरफेस कोणत्याही प्रमाणात डेटा एक्सचेंजसाठी खराब अनुकूल आहेत. मेसेजिंग डेटा हलवते परंतु त्याचा इतिहास संग्रहित करत नाही, त्यामुळे डेटा कालांतराने दूषित होतो. सामायिक डेटाबेस एका बिंदूवर जास्त लक्ष केंद्रित करतात, ज्यामुळे प्रगती थांबते. डेटा अयशस्वी होण्याच्या चक्रात आम्ही अपरिहार्यपणे अडकतो:

डेटा अयशस्वी होण्याचे चक्र

प्रवाह: डेटा आणि सेवांसाठी विकेंद्रित दृष्टीकोन

तद्वतच, आम्हाला शेअर केलेल्या डेटासह सेवांची कार्यपद्धती बदलण्याची गरज आहे. या टप्प्यावर, एकतर दृष्टीकोन वर नमूद केलेल्या द्वंद्वाचा सामना करतो, कारण त्यावर कोणतीही जादूची धूळ नाही जी ती अदृश्य करण्यासाठी शिंपडली जाऊ शकते. तथापि, आम्ही समस्येचा पुनर्विचार करू शकतो आणि तडजोड करू शकतो.

या तडजोडीमध्ये काही प्रमाणात केंद्रीकरणाचा समावेश होतो. आम्ही वितरित लॉग यंत्रणा वापरू शकतो कारण ते विश्वसनीय, स्केलेबल प्रवाह प्रदान करते. आम्हाला आता सेवा या सामायिक थ्रेड्सवर सामील होण्यास आणि ऑपरेट करण्यास सक्षम बनवायचे आहे, परंतु आम्ही ही प्रक्रिया करणार्‍या जटिल केंद्रीकृत देव सेवा टाळू इच्छितो. म्हणून, प्रत्येक ग्राहक सेवेमध्ये प्रवाह प्रक्रिया तयार करणे हा सर्वोत्तम पर्याय आहे. अशा प्रकारे, सेवा विविध स्त्रोतांकडून डेटा संच एकत्र करण्यास सक्षम असतील आणि त्यांना आवश्यक त्या मार्गाने कार्य करू शकतील.

हा दृष्टिकोन साध्य करण्याचा एक मार्ग म्हणजे स्ट्रीमिंग प्लॅटफॉर्मचा वापर करणे. बरेच पर्याय आहेत, परंतु आज आपण काफ्काकडे पाहू, कारण त्याच्या स्टेटफुल स्ट्रीम प्रोसेसिंगचा वापर आपल्याला प्रस्तुत समस्येचे प्रभावीपणे निराकरण करण्यास अनुमती देतो.

वितरीत लॉगिंग यंत्रणा वापरणे आम्हाला चांगल्या मार्गाचे अनुसरण करण्यास आणि कार्य करण्यासाठी संदेशन वापरण्याची परवानगी देते घटना-चालित आर्किटेक्चर. हा दृष्टिकोन विनंती-प्रतिसाद यंत्रणेपेक्षा चांगले स्केलिंग आणि विभाजन प्रदान करण्यासाठी मानले जाते कारण ते प्रेषकाऐवजी प्राप्तकर्त्याला प्रवाहाचे नियंत्रण देते. तथापि, या जीवनातील प्रत्येक गोष्टीसाठी आपल्याला पैसे द्यावे लागतील आणि येथे आपल्याला ब्रोकरची आवश्यकता आहे. परंतु मोठ्या सिस्टीमसाठी, ट्रेड-ऑफ फायदेशीर आहे (जे तुमच्या सरासरी वेब अनुप्रयोगासाठी असू शकत नाही).

पारंपारिक मेसेजिंग सिस्टीमऐवजी वितरित लॉगिंगसाठी दलाल जबाबदार असल्यास, तुम्ही अतिरिक्त वैशिष्ट्यांचा लाभ घेऊ शकता. वाहतूक जवळजवळ तसेच वितरीत फाइल प्रणाली रेखीयपणे स्केल करू शकते. डेटा बर्याच काळासाठी लॉगमध्ये संग्रहित केला जाऊ शकतो, त्यामुळे आम्हाला केवळ संदेशांची देवाणघेवाणच नाही तर माहिती संचयन देखील मिळते. बदलता येण्याजोग्या सामायिक स्थितीच्या भीतीशिवाय स्केलेबल स्टोरेज.

त्यानंतर तुम्ही उपभोग करणाऱ्या सेवांमध्ये घोषणात्मक डेटाबेस टूल्स जोडण्यासाठी स्टेटफुल स्ट्रीम प्रोसेसिंग वापरू शकता. ही एक अतिशय महत्त्वाची कल्पना आहे. डेटा शेअर्ड स्ट्रीममध्ये संग्रहित केला जातो ज्यामध्ये सर्व सेवा प्रवेश करू शकतात, सेवा करते ती एकत्रीकरण आणि प्रक्रिया खाजगी असते. ते स्वतःला कठोरपणे मर्यादित संदर्भात एकटे शोधतात.

अपरिवर्तनीय स्थिती प्रवाह वेगळे करून डेटा द्विविभाजन दूर करा. नंतर स्टेटफुल स्ट्रीम प्रोसेसिंग वापरून प्रत्येक सेवेमध्ये ही कार्यक्षमता जोडा.

अशा प्रकारे, जर तुमच्या सेवेला ऑर्डर, उत्पादन कॅटलॉग, वेअरहाऊससह कार्य करण्याची आवश्यकता असेल, तर त्यास पूर्ण प्रवेश असेल: कोणता डेटा एकत्र करायचा, त्यावर कुठे प्रक्रिया करायची आणि कालांतराने ते कसे बदलायचे हे फक्त तुम्हीच ठरवाल. डेटा सामायिक केला गेला असूनही, त्यासह कार्य पूर्णपणे विकेंद्रित आहे. हे प्रत्येक सेवेमध्ये तयार केले जाते, अशा जगात जेथे सर्वकाही आपल्या नियमांनुसार चालते.

डेटाच्या अखंडतेशी तडजोड न करता शेअर करा. आवश्यक असलेल्या प्रत्येक सेवेमध्ये स्त्रोत नव्हे तर फंक्शन एन्कॅप्स्युलेट करा.

असे होते की डेटा एकत्रितपणे हलविला जाणे आवश्यक आहे. कधीकधी सेवेसाठी निवडलेल्या डेटाबेस इंजिनमध्ये स्थानिक ऐतिहासिक डेटासेट आवश्यक असतो. युक्ती अशी आहे की आपण हमी देऊ शकता की, आवश्यक असल्यास, वितरित लॉगिंग यंत्रणेमध्ये प्रवेश करून स्त्रोताकडून एक प्रत पुनर्संचयित केली जाऊ शकते. काफ्का मधील कनेक्टर हे उत्तम काम करतात.

तर, आज चर्चा केलेल्या दृष्टिकोनाचे अनेक फायदे आहेत:

• डेटा सामान्य प्रवाहाच्या स्वरूपात वापरला जातो, जो बर्याच काळासाठी लॉगमध्ये संग्रहित केला जाऊ शकतो आणि सामान्य डेटासह कार्य करण्याची यंत्रणा प्रत्येक वैयक्तिक संदर्भात कठोर आहे, ज्यामुळे सेवा सहजपणे आणि द्रुतपणे कार्य करू शकतात. अशाप्रकारे, डेटाचे द्विभाजन संतुलित केले जाऊ शकते.
• वेगवेगळ्या सेवांमधून येणारा डेटा सहजपणे सेटमध्ये एकत्र केला जाऊ शकतो. हे सामायिक केलेल्या डेटासह परस्परसंवाद सुलभ करते आणि डेटाबेसमधील स्थानिक डेटासेट राखण्याची गरज दूर करते.
• स्टेटफुल स्ट्रीम प्रोसेसिंग केवळ डेटा कॅश करते, आणि सत्याचा स्रोत सामान्य नोंदी राहतो, त्यामुळे कालांतराने डेटा करप्शनची समस्या तितकी तीव्र नसते.
• त्यांच्या केंद्रस्थानी, सेवा डेटा-चालित आहेत, याचा अर्थ डेटाच्या सतत वाढत्या प्रमाणात असूनही, सेवा अजूनही व्यवसाय कार्यक्रमांना त्वरित प्रतिसाद देऊ शकतात.
• स्केलेबिलिटी समस्या ब्रोकरवर पडतात, सेवांवर नाही. हे लेखन सेवांची जटिलता लक्षणीयरीत्या कमी करते, कारण स्केलेबिलिटीबद्दल विचार करण्याची आवश्यकता नाही.
• नवीन सेवा जोडण्यासाठी जुन्या बदलण्याची आवश्यकता नाही, त्यामुळे नवीन सेवा कनेक्ट करणे सोपे होते.

तुम्ही बघू शकता, हे फक्त REST पेक्षा जास्त आहे. आम्हाला साधनांचा एक संच प्राप्त झाला आहे जो तुम्हाला विकेंद्रित पद्धतीने सामायिक केलेल्या डेटासह कार्य करण्यास अनुमती देतो.

आजच्या लेखात सर्व बाबींचा समावेश केलेला नाही. विनंती-प्रतिसाद प्रतिमान आणि घटना-चालित प्रतिमान यांच्यात संतुलन कसे साधायचे हे आम्हाला अद्याप शोधण्याची आवश्यकता आहे. पण आम्ही पुढच्या वेळी याचा सामना करू. असे विषय आहेत जे तुम्हाला चांगल्या प्रकारे जाणून घेणे आवश्यक आहे, उदाहरणार्थ, स्टेटफुल स्ट्रीम प्रोसेसिंग इतके चांगले का आहे. याविषयी आपण तिसऱ्या लेखात बोलू. आणि इतर शक्तिशाली बांधकामे आहेत ज्यांचा आपण फायदा घेऊ शकतो जर आपण त्यांचा अवलंब केला तर, उदाहरणार्थ, बरोबर एकदा प्रक्रिया. हे वितरित व्यवसाय प्रणालींसाठी एक गेम चेंजर आहे कारण ते यासाठी व्यवहार हमी प्रदान करते XA स्केलेबल स्वरूपात. चौथ्या लेखात याबद्दल चर्चा केली जाईल. शेवटी, आम्हाला या तत्त्वांच्या अंमलबजावणीच्या तपशीलांवर जावे लागेल.

परंतु आत्तासाठी, फक्त हे लक्षात ठेवा: डेटा डिकोटॉमी ही एक शक्ती आहे ज्याचा आपल्याला व्यवसाय सेवा तयार करताना सामना करावा लागतो. आणि आपण हे लक्षात ठेवले पाहिजे. युक्ती म्हणजे सर्वकाही डोक्यावर वळवणे आणि सामायिक केलेल्या डेटाला प्रथम श्रेणीच्या वस्तू मानणे सुरू करणे. स्टेटफुल स्ट्रीम प्रोसेसिंग यासाठी एक अनोखी तडजोड प्रदान करते. हे केंद्रीकृत "देव घटक" टाळते जे प्रगती रोखते. शिवाय, ते डेटा स्ट्रीमिंग पाइपलाइनची चपळता, स्केलेबिलिटी आणि लवचिकता सुनिश्चित करते आणि त्यांना प्रत्येक सेवेमध्ये जोडते. म्हणून, आम्ही चेतनेच्या सामान्य प्रवाहावर लक्ष केंद्रित करू शकतो ज्यामध्ये कोणतीही सेवा कनेक्ट करू शकते आणि त्याच्या डेटासह कार्य करू शकते. हे सेवांना अधिक स्केलेबल, अदलाबदल करण्यायोग्य आणि स्वायत्त बनवते. त्यामुळे ते केवळ व्हाईटबोर्ड आणि गृहितकाच्या चाचण्यांवरच चांगले दिसत नाहीत, तर ते दशकांपर्यंत कार्य करतील आणि विकसित होतील.

कोर्सबद्दल अधिक जाणून घ्या.

स्त्रोत: www.habr.com