नमस्ते! मेरा नाम वादिम मैडिसन है, मैं सिस्टम प्लेटफॉर्म एविटो के विकास का नेतृत्व करता हूं। कंपनी में हम कैसे एक अखंड वास्तुकला से एक माइक्रोसैस आर्किटेक्चर पर स्विच कर रहे हैं, यह एक से अधिक बार कहा गया है। यह साझा करने का समय है कि किस तरह से हमने अपने बुनियादी ढांचे को बदल दिया ताकि अधिक से अधिक माइक्रोसेवा प्राप्त कर सकें और अपने आप को उनमें खो न दें। कैसे पासा यहां हमारी मदद करता है, कैसे हमने तैनाती को सरल बनाया और एक क्लिक पर माइक्रोसर्विस के निर्माण को कम किया। नहीं सब कुछ है कि मैं नीचे लिखो पूरी तरह से Avito में लागू किया गया है, हिस्सा है कि हम अपने मंच को कैसे विकसित करते हैं।

(और इस लेख के अंत में मैं microservice आर्किटेक्चर क्रिस रिचर्डसन पर एक विशेषज्ञ से तीन-दिवसीय संगोष्ठी को प्राप्त करने के अवसर के बारे में बात करूंगा)।

हम माइक्रोसर्विस में कैसे आए

Avito दुनिया में सबसे बड़े क्लासिफाइड में से एक है, यह प्रति दिन 15 मिलियन से अधिक नए विज्ञापन प्रकाशित करता है। हमारा बैकएंड प्रति सेकंड 20 हजार से अधिक अनुरोध स्वीकार करता है। अब हमारे पास कई सौ microservices हैं।

हम कई वर्षों से माइक्रोसैस आर्किटेक्चर का निर्माण कर रहे हैं। कैसे ठीक है - हमारे सहयोगियों ने RIT ++ 2017 में हमारे अनुभाग में विस्तार से बात की । CodeFest 2017 (देखें वीडियो ) में, सर्गेई ओर्लोव और मिखाइल प्रोकोपचुक ने विस्तार से बताया कि हमें माइक्रोसर्विस के लिए संक्रमण की आवश्यकता क्यों थी और कुबेटेस ने यहां क्या भूमिका निभाई। खैर, अब हम ऐसी वास्तुकला में निहित स्केलिंग लागत को कम करने के लिए सब कुछ कर रहे हैं।

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

अब PaS CLI उपयोगिता में, एक टीम एक नई सेवा बनाती है, और दो और एक नया डेटाबेस जोड़ते हैं और स्टेज पर तैनात होते हैं।

कैसे "microservice विखंडन" के युग पर काबू पाने के लिए

एक अखंड वास्तुकला के साथ, उत्पाद में परिवर्तन की स्थिरता के लिए, डेवलपर्स को यह पता लगाने के लिए मजबूर किया गया था कि उनके पड़ोसियों के साथ क्या हो रहा था। नई वास्तुकला पर काम करते समय, सेवा संदर्भ अब एक दूसरे पर निर्भर नहीं करते हैं।

इसके अलावा, माइक्रोसैस आर्किटेक्चर को प्रभावी बनाने के लिए, कई प्रक्रियाओं को स्थापित करने की आवश्यकता है, अर्थात्:

• लॉगिंग;
• क्वेरी अनुरेखण (Jaeger);
• त्रुटि एकत्रीकरण (संतरी);
• कुबेरनेट्स (इवेंट स्ट्रीम प्रोसेसिंग) से स्टेटस, मैसेज, इवेंट्स;
• रेस लिमिट / सर्किट ब्रेकर (आप हिस्ट्रिक्स का उपयोग कर सकते हैं);
• सेवा कनेक्टिविटी का नियंत्रण (हम नेट्राम का उपयोग करते हैं);
• निगरानी (ग्राफाना);
• विधानसभा (टीमसिटी);
• संचार और अधिसूचना (सुस्त, ईमेल);
• कार्य ट्रैकिंग; (Jira)
• प्रलेखन का संकलन।

ताकि सिस्टम तराजू के रूप में, यह अपनी अखंडता को नहीं खोता है और प्रभावी रहता है, हमने एविटो में माइक्रोसर्विस के काम के संगठन को पुनर्विचार किया।

हम माइक्रोसर्विसेस को कैसे संभालते हैं

कई सूक्ष्म सेवाओं के बीच एकीकृत "पार्टी नीति" का संचालन करने में मदद करता है:

• परतों में बुनियादी ढांचे का विभाजन;
• सेवा (PaS) अवधारणा के रूप में प्लेटफ़ॉर्म;
• उन सभी चीज़ों की निगरानी करना जो माइक्रोसेवा के साथ होती हैं।

इन्फ्रास्ट्रक्चर अमूर्त परतों में तीन परतें शामिल हैं। ऊपर से नीचे तक चलते हैं।

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

सभी परतें पाएएस द्वारा संयुक्त हैं। और यह मंच, बदले में, तीन भागों से बना है।

I. जनरेटर सीएलआई उपयोगिता के माध्यम से नियंत्रित होते हैं। यह वह है जो डेवलपर को सही तरीके से और न्यूनतम प्रयास के साथ एक माइक्रोसैस सर्विस बनाने में मदद करता है।

द्वितीय। एक आम डैशबोर्ड के माध्यम से सभी उपकरणों के नियंत्रण के साथ संयुक्त कलेक्टर ।

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

एविटो में माइक्रोसर्विस का कार्यान्वयन एक एकल योजना के अनुसार किया जाता है, जो विकास और रिलीज के प्रत्येक चरण में उनके नियंत्रण को सरल बनाता है।

कैसे मानक microservice विकास पाइपलाइन काम करता है

सामान्य शब्दों में, microservice निर्माण श्रृंखला निम्नानुसार है:

सीएलआई-पुश → कंटीन्यूअस इंटीग्रेशन → बेक → डिप्लॉय → कृत्रिम परीक्षण → कैनरी परीक्षण → स्क्वीज़ परीक्षण → उत्पादन → सेवा।

हम इस क्रम में इसके माध्यम से चलते हैं।

CLI-धक्का

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

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

- टेम्पलेट के अनुसार एक सेवा बनाता है - कदम से कदम, "विज़ार्ड" मोड में। हमारे पास Avito बैकएंड में मुख्य प्रोग्रामिंग भाषाओं के लिए टेम्पलेट हैं: PHP, गोलंग और पायथन।

- एक आदेश पर, यह एक विशिष्ट मशीन पर स्थानीय विकास के लिए पर्यावरण को चित्रित करता है - मिनिक्यूब उगता है, हेल्म चार्ट स्वचालित रूप से उत्पन्न होते हैं और स्थानीय कुबेरनेट में चलते हैं।

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

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

- ऑटोटेस्ट उत्पन्न करता है। डिस्क के रूप में, लेकिन उपयोग के लिए काफी उपयुक्त है।

• माइक्रोसर्विस तैनात करें ।

इससे पहले एक microservice तैनात करने के लिए यह थोड़ा सुनसान था। अनिवार्य आवश्यक:

आई। डॉकरफाइल।

द्वितीय। कॉन्फिग।
तृतीय। एक हेलम चार्ट, जो स्वयं भारी है और इसमें शामिल हैं:

- चार्ट स्वयं;
- टेम्पलेट्स;
- विभिन्न वातावरणों को ध्यान में रखते हुए विशिष्ट मूल्य।

कुबेरनेट्स के प्रकट होने को कम करने के दर्द से हमने छुटकारा पा लिया, और अब वे स्वतः उत्पन्न हो गए हैं। लेकिन सबसे महत्वपूर्ण बात, उन्होंने सीमा तक तैनाती को सरल बनाया। अब से, हमारे पास एक डॉकरीफाइल है, और डेवलपर पूरे कॉन्फिग को एक ही शॉर्ट ऐप.टोमल फाइल में लिखता है।

हां, और app.toml में अब केवल एक मिनट के लिए कार्य होता है। हम नीचे लिखते हैं कि सेवा की कितनी प्रतियाँ ऊपर उठाई जानी हैं (देव-सर्वर पर, मंचन पर, उत्पादन पर), इसकी निर्भरताएँ बताती हैं। [इंजन] ब्लॉक में लाइन का आकार = "छोटा" नोट करें। यह वह सीमा है जिसे कुबेरनेट्स के माध्यम से सेवा को आवंटित किया जाएगा।

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

• मूल मान्यता। ऐसे चेक स्वचालित भी होते हैं।
ट्रैक करने की आवश्यकता:
- वहाँ एक डॉकरफाइल है;
- वहाँ app.toml है;
- चाहे प्रलेखन हो;
- क्या निर्भरता क्रम में है;
- अलर्ट के नियम निर्धारित हैं।
अंतिम बिंदु तक: सेवा स्वामी स्वयं इंगित करता है कि कौन से उत्पाद पर नज़र रखी जाए।

• प्रलेखन की तैयारी।
अभी भी एक समस्या जगह है। यह सबसे स्पष्ट प्रतीत होता है, लेकिन एक ही समय में एक रिकॉर्ड-ब्रेकिंग "अक्सर भूल गया", और इसलिए श्रृंखला में एक कमजोर कड़ी।
यह आवश्यक है कि प्रलेखन प्रत्येक माइक्रोसिस्ट के तहत हो। इसमें निम्नलिखित ब्लॉक शामिल किए गए हैं।

I. सेवा का संक्षिप्त विवरण । बस कुछ वाक्य वह क्या करता है और इसके लिए क्या आवश्यक है।

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

तृतीय। रनबुक । सेवा शुरू करने और इसे संभालने की पेचीदगियों के लिए एक छोटा गाइड।

चतुर्थ। सामान्य प्रश्न , जहां उन समस्याओं का पूर्वानुमान लगाना अच्छा होगा, जो सेवा के साथ काम करते समय आपके सहयोगियों के सामने आ सकती हैं।

V. API के लिए एंडपॉइंट का विवरण । यदि आप अचानक अपने गंतव्य को इंगित नहीं करते हैं, तो आप निश्चित रूप से उन सहयोगियों द्वारा भुगतान किया जाएगा जिनके माइक्रोसर्विस आपके लिए संबंधित हैं। अब हम इसके लिए स्वैगर का उपयोग करते हैं और हमारे समाधान को संक्षिप्त कहा जाता है।

छठी। लेबल। या मार्कर जो दिखाते हैं कि उत्पाद, कार्यक्षमता, कंपनी की संरचनात्मक इकाई किस सेवा से संबंधित है। वे जल्दी से समझने में मदद करते हैं, उदाहरण के लिए, यदि आप उस कार्यक्षमता को नहीं देख रहे हैं जो आपके सहकर्मियों ने एक सप्ताह पहले उसी व्यावसायिक इकाई के लिए रोल आउट किया था।

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

अंत में, कोड समीक्षा के समान, प्रलेखन की समीक्षा करना अच्छा है।

निरंतर एकीकरण

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

सेंकना

अगला चरण तैनाती से पहले सेवाओं की पैकेजिंग है।

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

लीड समय, कम बेहतर है। अधिकतम: 643ms; न्यूनतम: 42ms। फोटो क्लिक करने योग्य है।

सर्जरी के लिए समय कम है, बेहतर है। अधिकतम: 14091 एनएस, न्यूनतम: 151 एनएस। फोटो क्लिक करने योग्य है।

असेंबली तैयार करने के चरण में, आप इस चर को स्पष्ट रूप से सेट कर सकते हैं या आप उबेर लोगों से ऑटोमैक्सप्रोक्स लाइब्रेरी का उपयोग कर सकते हैं।

तैनाती

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

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

सिंथेटिक परीक्षण

• बंद लूप परीक्षण। उसके लिए, हम अब खुले स्रोत Hoverfly.io का उपयोग कर रहे हैं। सबसे पहले, यह सेवा पर वास्तविक भार रिकॉर्ड करता है, फिर - बस एक बंद लूप में - यह अनुकरण करता है।

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

तनाव परीक्षण के दौरान, हम जांचते हैं कि संसाधन की खपत निर्धारित सीमा को पूरा करती है या नहीं। और हम मुख्य रूप से चरम सीमाओं पर ध्यान केंद्रित करते हैं।

a) हम कुल भार को देखते हैं।
- बहुत छोटा - सबसे अधिक संभावना है कि कुछ काम बिल्कुल नहीं करता है अगर लोड अचानक कई बार गिरा।
- बहुत बड़ा - अनुकूलन आवश्यक है।

बी) हम आरपीएस द्वारा कट-ऑफ को देखते हैं।
यहां हम वर्तमान संस्करण और पिछले एक और कुल संख्या के बीच अंतर को देखते हैं। उदाहरण के लिए, यदि कोई सेवा 100 आरपीएस का उत्पादन करती है, तो यह या तो खराब लिखा जाता है या यह इसकी विशिष्टता है, लेकिन किसी भी मामले में, यह सेवा को बहुत करीब से देखने का अवसर है।
यदि आरपीएस, इसके विपरीत, बहुत अधिक है, तो शायद कुछ प्रकार के बग और कुछ समापन बिंदुओं ने पेलोड का प्रदर्शन करना बंद कर दिया है, लेकिन कुछ प्रकार की return true;

कैनरी परीक्षण

सिंथेटिक परीक्षणों के पारित होने के बाद, हम उपयोगकर्ताओं की एक छोटी संख्या पर माइक्रो सर्विस चलाते हैं। हम ध्यान से शुरू करते हैं, सेवा के अनुमानित दर्शकों के एक छोटे से अंश के साथ - 0.1% से कम। इस स्तर पर, यह बहुत महत्वपूर्ण है कि सही तकनीकी और उत्पाद मीट्रिक निगरानी में स्थापित किए जाते हैं ताकि वे सेवा में समस्या को जितनी जल्दी हो सके दिखा सकें। एक कैनरी परीक्षण के लिए न्यूनतम समय 5 मिनट है, मुख्य एक 2 घंटे है। जटिल सेवाओं के लिए, हम समय को मैनुअल मोड में सेट करते हैं।
हम विश्लेषण करते हैं:
- भाषा-विशिष्ट मीट्रिक, विशेष रूप से php-fpm श्रमिकों में;
- संतरी में त्रुटियाँ;
- प्रतिक्रियाओं की स्थिति;
- प्रतिक्रिया समय (प्रतिक्रिया समय), सटीक और औसत;
- विलंबता;
- अपवाद, संसाधित और असंसाधित;
- फूड मेट्रिक्स।

निचोड़ परीक्षण

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

प्रोडक्शंस

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

परिणामस्वरूप, जब स्केलिंग, हम विश्लेषण करते हैं:
- सीपीयू और रैम संकेतक,
- कतार में अनुरोधों की संख्या,
- प्रतिक्रिया समय
- ऐतिहासिक आंकड़ों के आधार पर पूर्वानुमान।

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

सेवा

माइक्रोसर्विस को ऑपरेशन में डालने के बाद, हम इस पर ट्रिगर लटका सकते हैं।

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

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

डैशबोर्ड

संक्षेप में, डैशबोर्ड हमारे पूरे PaS का नियंत्रण कक्ष है।

• किसी सेवा के बारे में जानकारी का एक बिंदु, परीक्षणों के साथ उसके कवरेज पर डेटा के साथ, उसकी छवियों की संख्या, उत्पादन प्रतियों की संख्या, संस्करण, आदि।
• सेवाओं और लेबल द्वारा डेटा को फ़िल्टर करने का एक उपकरण (व्यवसाय इकाइयों, उत्पाद की कार्यक्षमता, आदि से संबंधित मार्कर)
• ट्रेसिंग, लॉगिंग, निगरानी के लिए बुनियादी ढाँचे के साथ एकीकरण के साधन।
• सेवा प्रलेखन का एक बिंदु।
• सभी सेवा आयोजनों का एक एकल बिंदु।

कुल मिलाकर

PaS की शुरुआत से पहले, एक नया डेवलपर उत्पादन में एक microservice शुरू करने के लिए आवश्यक सभी उपकरणों को छाँटने में कई सप्ताह बिता सकता था: कुबेरनेट्स, हेल्म, हमारी टीमसिटी आंतरिक विशेषताएं, डेटाबेस से कनेक्शन स्थापित करना और दोष-सहिष्णु रूप में कैश करना, आदि। अब क्विकस्टार्ट को पढ़ने और सेवा को बनाने में कुछ घंटे लगते हैं।

मैंने इस विषय पर HighLoad ++ 2018 के लिए एक रिपोर्ट बनाई, आप वीडियो और प्रस्तुति देख सकते हैं।

जो लोग अंत तक पढ़ चुके हैं उनके लिए बोनस ट्रैक

हम एविटो में माइक्रो-आर्किटेक्चर के विशेषज्ञ क्रिस रिचर्डसन से डेवलपर्स के लिए आंतरिक तीन दिवसीय प्रशिक्षण का आयोजन करेंगे। हम इस पोस्ट के पाठकों में से एक को इसमें भाग लेने का अवसर देना चाहते हैं। यहाँ एक प्रशिक्षण कार्यक्रम है।

प्रशिक्षण मास्को में 5 से 7 अगस्त तक आयोजित किया जाएगा। ये ऐसे कार्य दिवस हैं जिन पर पूरी तरह से कब्जा किया जाएगा। दोपहर का भोजन और प्रशिक्षण हमारे कार्यालय में होगा, और चुने गए प्रतिभागी स्वयं यात्रा और आवास के लिए भुगतान करते हैं।

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

UPD, 07/19: हमें दर्जनों आवेदन मिले। क्रिस ने उनकी जांच की और एक प्रतिभागी को चुना: हमारे सहयोगियों के साथ, आंद्रेई इग्मुइनोव अध्ययन करने जाएंगे। बधाई!