आपके वितरित मोनोलिथ आपके पीछे साजिश रच रहे हैं

नमस्कार, हेब्र!

आज का अनुवाद न केवल इतना सूक्ष्म रूप से स्पर्श करता है, बल्कि एक ऐसा विषय है जो आज हर किसी के होंठों पर है - लेकिन यह भी याद दिलाता है कि कुदाल को कुदाल कहना कितना महत्वपूर्ण है। माइक्रोसैसवर्क आर्किटेक्चर के लिए संक्रमण कभी-कभी आवश्यक होता है, लेकिन, जैसा कि लेखक ने एक बार फिर जोर दिया है, इसके परिणामों के बारे में सावधानीपूर्वक विचार करने की आवश्यकता है। आनंद लें और फलदायक पठन!



समय-समय पर मैं एक ही सवाल पूछता हूं।

क्या इतना महत्वपूर्ण सत्य है कि केवल कुछ ही आपसे सहमत हैं? - पीटर थिएल

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

अधिकांश microservice कार्यान्वयन वितरित मोनोलिथ से ज्यादा कुछ नहीं हैं।

मोनोलिथ का युग

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



ठेठ अखंड अनुप्रयोग वास्तुकला

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

• अपने डेटा मॉडल को पूरी तरह से समझें;
• आप डेटा के साथ सहयोग कर सकते हैं (यह माना जाता है कि आपके डेटाबेस को आपके आवेदन के लिए सही ढंग से चुना गया है)।

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

जब यह क्षण आता है, तो आपका सिस्टम सबसे अधिक संभावना एक नए हाइपोस्टेसिस में जाता है : यह एक वितरित मोनोलिथ में बदल जाता है ।

वितरित मोनोलिथ का युग

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

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



मुख्य मोनोलिथिक एप्लिकेशन से बिलिंग और रिपोर्टिंग सेवाओं का पता लगाने के बाद सिस्टम आर्किटेक्चर का एक सामान्यीकृत दृश्य

सब कुछ योजना के अनुसार हो रहा है।

• टीम मोनोलिथ को छोटे सिस्टम में विभाजित करना जारी रखती है;
• निरंतर एकीकरण / वितरण कन्वेयर घड़ी की कल की तरह काम करते हैं;
• कुबेरनेट्स क्लस्टर स्वस्थ है, इंजीनियर सब कुछ के साथ उत्पादक और खुश हैं।

जीवन सुंदर है।

लेकिन क्या होगा अगर मैं कहता हूं कि अभी विले साजिशें तुम्हारे खिलाफ बुन रही हैं?

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

आप बिलकुल सही हैं। लेकिन बढ़ते पैमाने के साथ, अधिक जटिल समस्याएं उत्पन्न होती हैं: अब किसी भी समय आप व्यावसायिक आवश्यकताओं को पूरा करने के लिए मजबूर होते हैं (उदाहरण के लिए, कुछ मीट्रिक को ट्रैक करने के लिए) जिन्हें एक से अधिक प्रणालियों में स्थित डेटा तक पहुंच की आवश्यकता होती है।

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



एक विश्लेषणात्मक ईटीएल प्रणाली का सामान्यीकृत उदाहरण (अनबेल में हमने इसे स्वचालित अनुवाद विश्लेषिकी कहा है)

उनाबेल में, हमने इस दृष्टिकोण का उपयोग किया:

• यह प्रत्येक microservice के प्रदर्शन को बहुत अधिक प्रभावित नहीं करता है;
• इसके लिए बड़े बुनियादी ढाँचे में बदलाव की आवश्यकता नहीं है (बस एक नया माइक्रोसेवा जोड़ें);
• हम अपनी व्यावसायिक आवश्यकताओं को शीघ्रता से पूरा करने में सक्षम थे।

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

1. डेटा में बदलाव

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

2. कई अलग-अलग डेटा योजनाओं को संसाधित करने की आवश्यकता

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

सारी बुराई की जड़

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

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



यह एक प्रकार का डेटा दुर्घटना है, जो 2011 के आसपास लिंकडिन की सूचना प्रवाह का प्रतिनिधित्व करती है

फिलहाल, आप सोच रहे होंगे: "आप लोग यह सब क्या करने जा रहे हैं?" इसका उत्तर सरल है: आपको परिवर्तनों को ट्रैक करने और महत्वपूर्ण कार्रवाइयों पर नज़र रखने की आवश्यकता है क्योंकि वे जगह लेते हैं।

इवेंट सोर्सिंग का उपयोग करके एक वितरित मोनोलिथ को तोड़ें

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

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

शायद आपका सवाल है:
"घटनाओं को उत्पन्न करने वाले माइक्रोसर्विस मुझे वितरित मोनोलिथ की समस्या को हल करने में कैसे मदद कर सकते हैं?"

यदि आपके पास सिस्टम हैं जो घटनाओं को उत्पन्न करते हैं, तो निम्नलिखित गुणों के साथ एक तथ्य लॉग हो सकता है:

• किसी भी डेटा वेयरहाउस के लिए बाध्यकारी की कमी: घटनाओं को आमतौर पर बाइनरी फॉर्मेट जैसे कि JSON, Avro या Protobufs का उपयोग करके क्रमबद्ध किया जाता है;
• अपरिवर्तनशीलता: जैसे ही कोई घटना उत्पन्न होती है, उसे बदलना असंभव है;
• Reproducibility: किसी भी समय सिस्टम की स्थिति को बहाल किया जा सकता है; इसके लिए, यह इवेंट लॉग को "रीप्ले" करने के लिए पर्याप्त है।

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

यहाँ कुछ कारण हैं कि इवेंट लॉग मुझे वितरित मोनोलिथ को तोड़ने में मदद करने का तरीका लगता है:

1. सत्य का एक स्रोत

एन डेटा स्रोतों को बनाए रखने के बजाय जिन्हें (कई) विषम डेटाबेस से कनेक्ट करने की आवश्यकता हो सकती है, इस नए परिदृश्य में, अंतिम सत्य एक रिपॉजिटरी में संग्रहित है: ईवेंट लॉग।

2. यूनिवर्सल डेटा प्रारूप

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

मान लीजिए कि आपको आपके किसी मित्र द्वारा पोस्ट की गई इंस्टाग्राम फोटो पसंद आई। इस तरह की कार्रवाई का वर्णन किया जा सकता है: " उपयोगकर्ता एक्स को चित्र पी पसंद है "। और यहाँ इस तथ्य का प्रतिनिधित्व करने वाली एक घटना है:



एवीओ (अभिनेता, क्रिया, वस्तु) दृष्टिकोण से संबंधित एक घटना, इस तथ्य का अनुकरण करती है कि उपयोगकर्ता उस तस्वीर का चयन करता है जिसे वे पसंद करते हैं।

3. उत्पादकों और उपभोक्ताओं के बीच कमजोर संचार

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

---

इस लेख की शुरुआत में इस सवाल का जवाब दिया गया था: क्या ऐसा कोई महत्वपूर्ण सत्य है जिसमें केवल कुछ ही आपसे सहमत हों?

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

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