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

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

हम माइक्रोसर्विसेज तक कैसे पहुंचे

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

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

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

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

"माइक्रोसर्विस विखंडन" के युग से कैसे उबरें

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

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

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

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

हम माइक्रोसर्विसेज का प्रबंधन कैसे करते हैं

निम्नलिखित कई एविटो माइक्रोसर्विसेज के बीच एकीकृत "पार्टी नीति" को लागू करने में मदद करते हैं:

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

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

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

सभी परतें PaaS द्वारा संयोजित हैं। और यह प्लेटफ़ॉर्म, बदले में, तीन भागों से बना है।

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

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

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

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

एक मानक माइक्रोसर्विस डेवलपमेंट पाइपलाइन कैसे काम करती है?

सामान्य तौर पर, माइक्रोसर्विस निर्माण श्रृंखला इस तरह दिखती है:

सीएलआई-पुश → सतत एकीकरण → बेक → तैनाती → कृत्रिम परीक्षण → कैनरी परीक्षण → निचोड़ परीक्षण → उत्पादन → रखरखाव।

आइए इसे बिल्कुल इसी क्रम में देखें।

सीएलआई-पुश

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

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

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

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

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

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

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

• माइक्रोसर्विस परिनियोजन.

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

I. डॉकरफ़ाइल।

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

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

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

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

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

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

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

I. सेवा का संक्षिप्त विवरण. यह क्या करता है और इसकी आवश्यकता क्यों है, इसके बारे में वस्तुतः कुछ वाक्य।

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

तृतीय. रनबुक. सेवा शुरू करने और इसे संभालने की जटिलताओं पर एक संक्षिप्त मार्गदर्शिका।

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

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

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

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

अंत में, कोड समीक्षा के समान, दस्तावेज़ीकरण की समीक्षा करना एक अच्छा अभ्यास है।

लगातार मेल जोल

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

सेंकना

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

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

निष्पादन समय, कम बेहतर है. अधिकतम: 643 एमएस, न्यूनतम: 42 एमएस। फोटो क्लिक करने योग्य है.

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

असेंबली तैयारी चरण में, आप इस वेरिएबल को स्पष्ट रूप से सेट कर सकते हैं या लाइब्रेरी का उपयोग कर सकते हैं automaxpro उबर के लोगों से.

तैनात करना

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

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

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

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

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

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

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

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

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

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

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

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

उत्पादन

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

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

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

सेवा

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

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

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

डैशबोर्ड

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

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

कुल मिलाकर

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

मैंने इस विषय पर HighLoad++ 2018 के लिए एक रिपोर्ट दी थी, आप इसे देख सकते हैं वीडियो и की प्रस्तुति.

अंत तक पढ़ने वालों के लिए बोनस ट्रैक

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

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

आप भागीदारी के लिए आवेदन कर सकते हैं इस गूगल फॉर्म में. आपसे - इस प्रश्न का उत्तर कि आपको प्रशिक्षण में भाग लेने की आवश्यकता क्यों है और आपसे संपर्क करने के तरीके के बारे में जानकारी। अंग्रेजी में उत्तर दें, क्योंकि क्रिस उस प्रतिभागी का चयन करेगा जो प्रशिक्षण में भाग लेगा।
हम इस पोस्ट के अपडेट में और सोशल नेटवर्क एविटो फॉर डेवलपर्स (एविटोटेक इन) पर प्रशिक्षण प्रतिभागी के नाम की घोषणा करेंगे। Фейсбуке, VKontakte, चहचहाना) 19 जुलाई से पहले नहीं।

स्रोत: www.habr.com