माइक्रोसैस आर्किटेक्चर पर बुनियादी ढांचे के निर्माण में अनुभव

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

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

• एक मोनोलिथ को माइक्रोसिस्ट्रिस में कैसे तोड़ना है और किन मानदंडों का पालन करना चाहिए।
• माइक्रोसर्विसेस कैसे बातचीत करेंगे?
• कैसे करें निगरानी?

वास्तव में इन सवालों के संक्षिप्त उत्तर इस लेख के लिए समर्पित होंगे।

एक मोनोलिथ को माइक्रोसिस्ट्रिस में कैसे तोड़ना है और किन मानदंडों का पालन करना चाहिए।

यह प्रतीत होता है सरल प्रश्न अंततः भविष्य की पूरी वास्तुकला को निर्धारित करता है।

हम एक बैंक हैं, इसलिए पूरी प्रणाली वित्त और विभिन्न सहायक चीजों के साथ संचालन के चारों ओर घूमती है। सागा के साथ वित्तीय एसीआईडी ​​लेनदेन को वितरित प्रणाली में स्थानांतरित करना निश्चित रूप से संभव है, लेकिन सामान्य मामले में यह बहुत मुश्किल है। इस प्रकार हमने निम्नलिखित नियम विकसित किए:

• एस के साथ एसईएल से माइक्रोसर्विसेज के लिए अनुपालन
• लेन-देन को पूरी तरह से माइक्रोसेवा में किया जाना चाहिए - डेटाबेस की क्षति पर कोई वितरित लेनदेन नहीं
• काम करने के लिए, अपने स्वयं के डेटाबेस या एक अनुरोध से जानकारी की आवश्यकता है
• माइक्रोसर्विस के लिए स्वच्छता (कार्यात्मक भाषाओं के अर्थ में) को सुनिश्चित करने का प्रयास करें

स्वाभाविक रूप से, एक ही समय में उन्हें पूरी तरह से संतुष्ट करना असंभव था, लेकिन यहां तक ​​कि आंशिक कार्यान्वयन भी विकास को बहुत सरल करता है।

माइक्रोसर्विसेस कैसे बातचीत करेंगे?

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

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

इसके अतिरिक्त मैं एक बहुत ही उच्च गुणवत्ता और विस्तृत तुलना पर ध्यान आकर्षित करना चाहता हूं।

कफ़्का + अतुल्यकालिक पर कतारें हमें इसकी अनुमति देती हैं:

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

एक डेटा क्रमांकन प्रणाली के रूप में, हमने AVRO को चुना, क्यों - एक अलग लेख में वर्णित है।

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

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

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

पुनश्च: सहकर्मियों ने ओपनसोर्स का विकल्प बनाया लेकिन केवल AVRO के बजाय JSON-स्कीमा के साथ ।

कुछ सूक्ष्मता

प्रत्येक ग्राहक विषय से सभी संदेश प्राप्त करता है

यह प्रकाशित - सदस्यता इंटरैक्शन मॉडल की विशिष्टता है - जब किसी विषय की सदस्यता ली जाती है, तो ग्राहक उन्हें सभी प्राप्त करेगा। नतीजतन, यदि सेवा को केवल कुछ संदेशों की आवश्यकता है, तो उन्हें उन्हें फ़िल्टर करना होगा। यदि यह एक समस्या बन जाती है, तो एक अलग सेवा राउटर बनाना संभव होगा जो कई अलग-अलग विषयों में संदेश देगा, जिससे रैबिटएमक्यू कार्यक्षमता का हिस्सा लागू हो जो कि काफ्का में नहीं है। अब हमारे पास एक थ्रेड में अजगर पर एक थ्रेड प्रक्रियाओं के बारे में 7-5 हजार संदेश प्रति सेकंड है, लेकिन अगर आप PyPy से चलते हैं, तो गति 11-15 हजार / सेकंड तक बढ़ती है।

एक विषय में एक पॉइंटर के जीवनकाल को सीमित करें

कफ़्का की सेटिंग्स में एक पैरामीटर है जो उस समय को सीमित करता है जो कफ़्का "याद" करता है जहां पाठक ने रोक दिया - डिफ़ॉल्ट 2 दिन है। इसे एक सप्ताह तक उठाना अच्छा होगा, ताकि यदि छुट्टियों पर समस्या उत्पन्न हो और 2 दिनों का समाधान न हो, तो इससे विषय में स्थिति का नुकसान नहीं होगा।

कन्फर्मेशन टाइम लिमिट पढ़ें

यदि काफ्का पाठक 30 सेकंड (एक विन्यास योग्य पैरामीटर) में पढ़ने की पुष्टि नहीं करता है, तो ब्रोकर का मानना ​​है कि कुछ गलत हो गया और पढ़ने की पुष्टि करने की कोशिश करते समय एक त्रुटि उत्पन्न होती है। इससे बचने के लिए, किसी संदेश को लंबे समय तक संसाधित करते समय, हम पॉइंटर को स्थानांतरित किए बिना रीड कन्फर्मेशन भेजते हैं।

कनेक्शन के ग्राफ को समझना मुश्किल है।

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

कैसे करें निगरानी?

यहां तक ​​कि मोनोलिथ के भाग के रूप में, हमारे पास फाइलों और संतरी में लॉग थे । लेकिन जैसा कि हमने काफ्का के माध्यम से बातचीत में बदल दिया था और k8s पर तैनात किया था, लॉग एलिस्टिक्सर्च में चले गए और तदनुसार हमने पहले इलास्टिक में ग्राहकों के लॉग पढ़ने पर नजर रखी। कोई लॉग नहीं - कोई काम नहीं।
उसके बाद, उन्होंने प्रोमेथियस और काफ्का-निर्यातक को इसके डैशबोर्ड को थोड़ा संशोधित करना शुरू कर दिया: https://github.com/kkirsanov/articles/blob/master/2019-habr-kafka/dashboard.json

परिणामस्वरूप, हमें ये चित्र मिलते हैं:

आप देख सकते हैं कि किस सेवा ने किन संदेशों को संसाधित करना बंद कर दिया है।

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

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

• सेवा का नाम
• इस microservice में प्रसंस्करण प्रक्रिया के UUID
• प्रक्रिया प्रारंभ टाइमस्टैम्प
• प्रक्रिया का समय
• टैग सेट

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