नमस्ते! मेरो नाम Vadim मैडिसन हो, म Avito प्रणाली प्लेटफर्म को विकास को नेतृत्व गर्छु। यो एक पटक भन्दा बढी भनिएको छ कि हामी कसरी कम्पनीमा एक मोनोलिथिक आर्किटेक्चरबाट माइक्रोसर्विसेजमा सर्दै छौं। यो समय साझा गर्ने समय हो कि हामीले कसरी माइक्रोसर्भिसेसहरूबाट बढीभन्दा बढी फाइदा लिनको लागि हाम्रो पूर्वाधारलाई रूपान्तरण गरेका छौं र आफूलाई तिनीहरूमा हराउनबाट जोगाउन। PaaS ले हामीलाई यहाँ कसरी मद्दत गर्छ, हामीले कसरी डिप्लोयमेन्टलाई सरल बनायौं र माइक्रोसर्भिसको सिर्जनालाई एक क्लिकमा कम गर्‍यौं - पढ्नुहोस्। मैले तल लेखेको सबै कुरा Avito मा पूर्ण रूपमा लागू गरिएको छैन, यसमा हामीले हाम्रो प्लेटफर्म कसरी विकास गर्छौं।

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

हामी कसरी माइक्रो सर्भिसमा आयौं

Avito संसारको सबैभन्दा ठूलो वर्गीकृत साइटहरू मध्ये एक हो; यसमा प्रति दिन 15 मिलियन भन्दा बढी नयाँ विज्ञापनहरू प्रकाशित हुन्छन्। हाम्रो ब्याकइन्डले प्रति सेकेन्ड २० हजार भन्दा बढी अनुरोधहरू स्वीकार गर्दछ। हामीसँग हाल सयौं माइक्रो सर्भिसहरू छन्।

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

प्रारम्भमा, हामीले एउटा इकोसिस्टम सिर्जना गरेका थिएनौं जसले हामीलाई सूक्ष्म सेवाहरू विकास गर्न र सुरु गर्न व्यापक रूपमा मद्दत गर्दछ। तिनीहरूले केवल समझदार खुला स्रोत समाधानहरू सङ्कलन गरे, तिनीहरूलाई घरमा सुरू गरे र विकासकर्तालाई तिनीहरूसँग सम्झौता गर्न आमन्त्रित गरे। नतिजाको रूपमा, उहाँ एक दर्जन स्थानहरू (ड्यासबोर्डहरू, आन्तरिक सेवाहरू) मा गए, जसको पछि उहाँ पुरानो तरिकामा, एक मोनोलिथमा कोड काट्ने इच्छामा बलियो हुनुभयो। तलको रेखाचित्रमा रहेको हरियो रङले विकासकर्ताले आफ्नो हातले कुनै न कुनै तरिकाले के गर्छ र पहेंलो रङले स्वचालनलाई संकेत गर्छ।

अब PaaS CLI उपयोगितामा, एउटा कमाण्डको साथ नयाँ सेवा सिर्जना गरिएको छ, र दुई थपसँग नयाँ डाटाबेस थपिएको छ र स्टेजमा तैनात गरिएको छ।

"माइक्रो सर्भिस फ्रेग्मेन्टेसन" को युग कसरी पार गर्ने

एक मोनोलिथिक वास्तुकलाको साथ, उत्पादनमा परिवर्तनहरूको स्थिरताको खातिर, विकासकर्ताहरू आफ्ना छिमेकीहरूसँग के भइरहेको छ भनेर पत्ता लगाउन बाध्य भए। नयाँ वास्तुकलामा काम गर्दा, सेवा सन्दर्भहरू अब एक अर्कामा निर्भर हुँदैनन्।

थप रूपमा, माइक्रोसर्भिस आर्किटेक्चर प्रभावकारी हुनको लागि, धेरै प्रक्रियाहरू स्थापना गर्न आवश्यक छ, अर्थात्:

लगिङ;
• अनुरोध ट्रेसिङ (जेगर);
• त्रुटि एकत्रीकरण (सेन्ट्री);
• स्थितिहरू, सन्देशहरू, Kubernetes बाट घटनाहरू (घटना स्ट्रिम प्रक्रिया);
• दौड सीमा / सर्किट ब्रेकर (तपाईं Hystrix प्रयोग गर्न सक्नुहुन्छ);
• सेवा जडानको नियन्त्रण (हामी नेत्रमेश प्रयोग गर्छौं);
अनुगमन (ग्राफाना);
• सम्मेलन (TeamCity);
• सञ्चार र सूचना (स्ल्याक, इमेल);
कार्य ट्र्याकिङ; (जिरा)
• कागजातको तयारी।

प्रणालीले आफ्नो अखण्डता गुमाउँदैन र यो स्केलको रूपमा प्रभावकारी रहन्छ भनेर सुनिश्चित गर्न, हामीले Avito मा microservices को संगठन पुनर्विचार गर्यौं।

हामी कसरी माइक्रोसेवाहरू व्यवस्थापन गर्छौं

धेरै Avito microservices बीच एक एकीकृत "पार्टी नीति" लागू गर्न निम्न मद्दत:

• तहहरूमा पूर्वाधार विभाजन;
• सेवा (PaaS) अवधारणाको रूपमा प्लेटफर्म;
• माइक्रोसर्भिसेससँग हुने सबै कुराको निगरानी गर्दै।

पूर्वाधार अमूर्त तहहरूमा तीन तहहरू समावेश छन्। माथि देखि तल जाऔं।

A. शीर्ष - सेवा जाल। सुरुमा हामीले Istio कोसिस गर्‍यौं, तर यो पत्ता लाग्यो कि यसले धेरै स्रोतहरू प्रयोग गर्दछ, जुन हाम्रो भोल्युमहरूको लागि धेरै महँगो छ। त्यसकारण, वास्तुकला टोलीमा वरिष्ठ ईन्जिनियर अलेक्जेंडर लुक्यान्चेन्कोले आफ्नै समाधान विकसित गरे - नेत्रमेश (खुला स्रोतमा उपलब्ध), जुन हामीले हाल उत्पादनमा प्रयोग गर्छौं र जसले Istio भन्दा धेरै गुणा कम स्रोतहरू खपत गर्छ (तर Istio ले घमण्ड गर्न सक्ने सबै कुरा गर्दैन)।
B. मध्यम - कुबर्नेट्स। हामी यसमा माइक्रो सर्भिसहरू तैनाथ र सञ्चालन गर्छौं।
C. तल - खाली धातु। हामी क्लाउड वा ओपनस्ट्याक जस्ता चीजहरू प्रयोग गर्दैनौं, तर पूर्ण रूपमा नाङ्गो धातुमा भर पर्छौं।

सबै तहहरू PaaS द्वारा संयुक्त छन्। र यो प्लेटफर्म, बारीमा, तीन भागहरू हुन्छन्।

I. जेनरेटरहरू, CLI उपयोगिता मार्फत नियन्त्रित। उनी नै हुन् जसले विकासकर्तालाई सही तरिकामा र न्यूनतम प्रयासमा माइक्रोसर्भिस सिर्जना गर्न मद्दत गर्छिन्।

II। समेकित कलेक्टर साझा ड्यासबोर्ड मार्फत सबै उपकरणहरूको नियन्त्रणको साथ।

III। भण्डारण। महत्त्वपूर्ण कार्यहरूको लागि स्वचालित रूपमा ट्रिगरहरू सेट गर्ने तालिकाकर्ताहरूसँग जडान हुन्छ। यस्तो प्रणालीको लागि धन्यबाद, एक कार्य पनि छुटेको छैन किनकि कसैले जिरामा कार्य सेटअप गर्न बिर्सेको छ। हामी यसको लागि एटलस भनिने आन्तरिक उपकरण प्रयोग गर्दछौं।

Avito मा माइक्रोसर्भिसेसहरूको कार्यान्वयन पनि एकल योजना अनुसार गरिन्छ, जसले विकास र रिलीजको प्रत्येक चरणमा तिनीहरूमाथि नियन्त्रणलाई सरल बनाउँछ।

मानक माइक्रोसेवा विकास पाइपलाइनले कसरी काम गर्छ?

सामान्यतया, microservice सिर्जना श्रृंखला यस्तो देखिन्छ:

CLI-पुश → निरन्तर एकीकरण → बेक → डिप्लोय → कृत्रिम परीक्षण → क्यानरी परीक्षण → स्क्विज परीक्षण → उत्पादन → मर्मतसम्भार।

यस क्रममा ठ्याक्कै यसलाई मार्फत जाऔं।

CLI-पुश

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

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

- टेम्प्लेट अनुसार सेवा सिर्जना गर्दछ — चरण-दर-चरण, "विजार्ड" मोडमा। हामीसँग Avito ब्याकइन्डमा मुख्य प्रोग्रामिङ भाषाहरूका लागि टेम्प्लेटहरू छन्: PHP, Golang र Python।

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

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

- यसले प्रत्यक्ष सभा आफैं गर्छ। मानौं एक विकासकर्ताले आफ्नो IDE मार्फत माइक्रोसर्भिसमा केहि सुधार गर्यो। उपयोगिताले फाइल प्रणालीमा परिवर्तनहरू देख्छ र, तिनीहरूको आधारमा, एप्लिकेसन (गोलाङका लागि) पुन: निर्माण गर्दछ र पुन: सुरु हुन्छ। PHP को लागि, हामी केवल क्यूब भित्र डाइरेक्टरी फर्वार्ड गर्छौं र त्यहाँ लाइभ-रिलोड "स्वचालित रूपमा" प्राप्त हुन्छ।

- स्वत: परीक्षणहरू उत्पन्न गर्दछ। खाली को रूप मा, तर प्रयोग को लागी एकदम उपयुक्त।

• माइक्रो सर्भिस डिप्लोइमेन्ट.

माइक्रोसर्भिस डिप्लोइ गर्नु हाम्रो लागि थोरै काम थियो। निम्न आवश्यक थियो:

I. डकरफाइल।

II। कन्फिगरेसन।
III। हेल्म चार्ट, जुन आफैमा बोझिलो छ र यसमा समावेश छ:

- चार्टहरू आफैं;
- टेम्प्लेटहरू;
- बिभिन्न वातावरणहरूलाई ध्यानमा राख्दै विशिष्ट मानहरू।

हामीले Kubernetes manifests लाई पुन: कार्य गर्ने पीडालाई बाहिर निकालेका छौं त्यसैले तिनीहरू अब स्वचालित रूपमा उत्पन्न हुन्छन्। तर सबैभन्दा महत्त्वपूर्ण कुरा, तिनीहरूले सीमामा परिनियोजनलाई सरल बनाए। अबदेखि हामीसँग डकरफाइल छ, र विकासकर्ताले एउटा छोटो app.toml फाइलमा सम्पूर्ण कन्फिगरेसन लेख्छ।

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

त्यसपछि, कन्फिगरेसनमा आधारित, सबै आवश्यक हेल्म चार्टहरू स्वचालित रूपमा उत्पन्न हुन्छन् र डाटाबेसहरूमा जडानहरू सिर्जना हुन्छन्।

• आधारभूत प्रमाणीकरण। त्यस्ता जाँचहरू पनि स्वचालित हुन्छन्।
ट्र्याक गर्न आवश्यक छ:
- त्यहाँ एक Dockerfile छ;
- त्यहाँ app.toml छ;
- त्यहाँ कागजात उपलब्ध छ?
- के निर्भरता क्रम मा छ?
- सतर्कता नियमहरू सेट गरिएको छ कि छैन।
अन्तिम बिन्दुमा: सेवाको मालिकले कुन उत्पादन मेट्रिक्स निगरानी गर्ने निर्धारण गर्दछ।

• कागजातको तयारी।
अझै पनि समस्या क्षेत्र। यो सबैभन्दा स्पष्ट देखिन्छ, तर एकै समयमा यो "अक्सर बिर्सिएको" रेकर्ड पनि हो, र यसैले श्रृंखलामा एक कमजोर लिङ्क।
यो आवश्यक छ कि प्रत्येक microservice को लागी कागजात छ। यसले निम्न ब्लकहरू समावेश गर्दछ।

I. सेवाको संक्षिप्त विवरण। शाब्दिक रूपमा यसले के गर्छ र यो किन आवश्यक छ भन्ने बारे केही वाक्यहरू।

II। वास्तुकला रेखाचित्र लिङ्क। यो महत्त्वपूर्ण छ कि यसलाई द्रुत रूपमा हेर्दा यो बुझ्न सजिलो छ, उदाहरणका लागि, तपाइँ क्यासिङको लागि Redis प्रयोग गर्दै हुनुहुन्छ वा पर्सिस्टेन्ट मोडमा मुख्य डाटा भण्डारको रूपमा। अहिलेको लागि Avito मा यो Confluence को लिङ्क हो।

III। रनबुक। सेवा सुरु गर्न र यसलाई ह्यान्डल गर्ने जटिलताहरूमा छोटो गाइड।

IV। FAQ, जहाँ यो सेवा संग काम गर्दा तपाईंका सहकर्मीहरूले सामना गर्न सक्ने समस्याहरू अनुमान गर्न राम्रो हुनेछ।

V. API को लागि अन्तिम बिन्दुहरूको विवरण। यदि अचानक तपाईंले गन्तव्यहरू निर्दिष्ट गर्नुभएन भने, सहकर्मीहरू जसका माइक्रोसेवाहरू तपाईंसँग सम्बन्धित छन् लगभग निश्चित रूपमा यसको लागि तिर्नेछन्। अब हामी Swagger प्रयोग गर्दछौं र हाम्रो समाधान यसको लागि संक्षिप्त भनिन्छ।

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

VII। सेवाको मालिक वा मालिकहरू। धेरैजसो अवस्थामा, यो — वा तिनीहरूलाई — PaaS प्रयोग गरेर स्वचालित रूपमा निर्धारण गर्न सकिन्छ, तर सुरक्षित पक्षमा हुनको लागि, हामीले विकासकर्ताले तिनीहरूलाई म्यानुअल रूपमा निर्दिष्ट गर्नुपर्छ।

अन्तमा, यो कोड समीक्षा जस्तै, कागजात समीक्षा गर्न एक राम्रो अभ्यास हो।

निरन्तर एकता

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

बेक गर्नुहोस्

अर्को चरण तैनाती अघि प्याकेजिङ सेवाहरू हो।

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

कार्यान्वयन समय, कम राम्रो छ। अधिकतम: 643ms, न्यूनतम: 42ms। फोटो क्लिक गर्न योग्य छ।

शल्यक्रियाको लागि समय, कम राम्रो छ। अधिकतम: 14091 एनएस, न्यूनतम: 151 एनएस। फोटो क्लिक गर्न योग्य छ।

विधानसभा तयारी चरणमा, तपाइँ यो चर स्पष्ट रूपमा सेट गर्न सक्नुहुन्छ वा तपाइँ पुस्तकालय प्रयोग गर्न सक्नुहुन्छ automaxprocs Uber का केटाहरु बाट।

तैनाथ गर्नुहोस्

• अधिवेशनहरू जाँच गर्दै। तपाईंले आफ्नो इच्छित वातावरणमा सेवा सम्मेलनहरू डेलिभर गर्न सुरु गर्नु अघि, तपाईंले निम्न जाँच गर्न आवश्यक छ:
- API अन्त्य बिन्दुहरू।
— स्कीमासँग API अन्त्यबिन्दु प्रतिक्रियाहरूको अनुपालन।
- लग ढाँचा।
- सेवामा अनुरोधहरूको लागि हेडरहरू सेट गर्दै (हाल यो नेत्रमेशद्वारा गरिन्छ)
- घटना बसमा सन्देशहरू पठाउँदा मालिक टोकन सेट गर्दै। यो बसमा सेवाहरूको जडान ट्र्याक गर्न आवश्यक छ। तपाईं बसमा दुवै idempotent डेटा पठाउन सक्नुहुन्छ, जसले सेवाहरूको कनेक्टिभिटी (जुन राम्रो छ), र व्यापार डेटा जसले सेवाहरूको जडानलाई बलियो बनाउँछ (जुन धेरै खराब छ!)। र बिन्दुमा जब यो जडान एक मुद्दा बन्छ, बस कसले लेख्छ र पढ्छ भनेर बुझ्दा सेवाहरू ठीकसँग अलग गर्न मद्दत गर्दछ।

Avito मा अझै धेरै अधिवेशनहरू छैनन्, तर तिनीहरूको पोखरी विस्तार हुँदैछ। टोलीले बुझ्न र बुझ्न सक्ने फारममा त्यस्ता सम्झौताहरू जति धेरै उपलब्ध हुन्छन्, माइक्रोसर्भिसेसहरू बीच एकरूपता कायम राख्न त्यति नै सजिलो हुन्छ।

कृत्रिम परीक्षण

• बन्द लूप परीक्षण। यसका लागि हामी अहिले खुला स्रोत प्रयोग गरिरहेका छौं Hoverfly.io। पहिले, यसले सेवामा वास्तविक लोड रेकर्ड गर्दछ, त्यसपछि - बन्द लुपमा - यसले यसलाई अनुकरण गर्दछ।

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

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

क) हामी कुल भार हेर्छौं।
- धेरै सानो - सम्भवतः केहि काम गर्दैन यदि लोड अचानक धेरै पटक घट्छ।
- धेरै ठूलो - अनुकूलन आवश्यक छ।

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

क्यानरी परीक्षणहरू

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

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

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

उत्पादन

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

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

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

सेवा

माइक्रोसर्भिस सञ्चालनमा आएपछि, हामी यसमा ट्रिगरहरू जोड्न सक्छौं।

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

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

ड्यासबोर्ड

छोटकरीमा, ड्यासबोर्ड हाम्रो सम्पूर्ण PaaS को नियन्त्रण प्यानल हो।

• सेवाको बारेमा जानकारीको एकल बिन्दु, यसको परीक्षण कभरेजमा डाटा, यसको छविहरूको संख्या, उत्पादन प्रतिलिपिहरूको संख्या, संस्करणहरू, आदि।
• सेवाहरू र लेबलहरू (व्यावसायिक एकाइहरू, उत्पादन कार्यक्षमता, इत्यादिसँग सम्बन्धित मार्करहरू) द्वारा डेटा फिल्टर गर्ने उपकरण।
• ट्रेसिङ, लगिङ, र अनुगमनका लागि पूर्वाधार उपकरणहरूसँग एकीकरणको लागि एउटा उपकरण।
• सेवा कागजातको एकल बिन्दु।
• सेवाहरूमा सबै घटनाहरूको एकल बिन्दु।

कुल

PaaS प्रस्तुत गर्नु अघि, नयाँ विकासकर्ताले उत्पादनमा माइक्रोसर्भिस सुरु गर्न आवश्यक सबै उपकरणहरू बुझ्न धेरै हप्ता खर्च गर्न सक्छ: Kubernetes, Helm, हाम्रो आन्तरिक TeamCity सुविधाहरू, डाटाबेस र क्यासहरूमा गल्ती-सहिष्णु तरिकामा जडानहरू सेटअप गर्ने, आदि। Quickstart पढ्न र सेवा आफै सिर्जना गर्न केही घण्टा लाग्छ।

मैले HighLoad++ 2018 को लागि यस विषयमा रिपोर्ट दिएँ, तपाईं यसलाई हेर्न सक्नुहुन्छ видео и प्रस्तुति.

अन्त्यमा पढ्नेहरूको लागि बोनस ट्र्याक

हामी Avito मा विकासकर्ताहरूका लागि आन्तरिक तीन दिने प्रशिक्षण आयोजना गर्दैछौं क्रिस रिचर्डसन, microservice वास्तुकला मा एक विशेषज्ञ। हामी यस पोष्टका पाठकहरू मध्ये एकलाई यसमा सहभागी हुने अवसर दिन चाहन्छौं। यो छ तालिम कार्यक्रम राखिएको छ ।

तालिम अगस्ट ५ देखि ७ सम्म मस्कोमा हुनेछ । यी काम गर्ने दिनहरू हुन् जुन पूर्ण रूपमा कब्जा हुनेछ। खाजा र प्रशिक्षण हाम्रो कार्यालयमा हुनेछ, र चयन गरिएको सहभागीले यात्रा र आवासको लागि आफैले भुक्तानी गर्नेछ।

तपाईं सहभागिताको लागि आवेदन दिन सक्नुहुन्छ यो गुगल फारममा। तपाइँबाट - तपाइँलाई तपाइँलाई कसरी सम्पर्क गर्ने बारे प्रशिक्षण र जानकारीमा उपस्थित हुन आवश्यक छ भन्ने प्रश्नको जवाफ। अङ्ग्रेजीमा जवाफ दिनुहोस्, किनभने क्रिसले तालिममा सहभागी हुने व्यक्तिलाई छनोट गर्नेछन्।
हामी यस पोष्टको अपडेटमा र विकासकर्ताहरूको लागि सामाजिक सञ्जाल Avito मा प्रशिक्षण सहभागीको नाम घोषणा गर्नेछौं (AvitoTech in फेसबुक, Вконтакте, ट्विटर) जुलाई १९ भन्दा पछि छैन।

स्रोत: www.habr.com