नमस्कार! माझे नाव वडिम मॅडिसन आहे, मी अविटो सिस्टम प्लॅटफॉर्मच्या विकासाचे नेतृत्व करतो. आम्ही कंपनीत एका मोनोलिथिक आर्किटेक्चरपासून मायक्रोसर्व्हिसेसकडे कसे जात आहोत हे एकापेक्षा जास्त वेळा सांगितले गेले आहे. मायक्रो सर्व्हिसेसचा अधिकाधिक फायदा घेण्यासाठी आणि त्यामध्ये स्वतःला हरवण्यापासून रोखण्यासाठी आम्ही आमच्या पायाभूत सुविधा कशा बदलल्या आहेत हे सामायिक करण्याची ही वेळ आहे. PaaS आम्हाला येथे कशी मदत करते, आम्ही उपयोजन कसे सोपे केले आणि एका क्लिकवर मायक्रो सर्व्हिसची निर्मिती कशी कमी केली - पुढे वाचा. मी खाली लिहिलेली प्रत्येक गोष्ट Avito मध्ये पूर्णपणे लागू केली जात नाही, त्यातील काही आम्ही आमचे प्लॅटफॉर्म कसे विकसित करतो.

(आणि या लेखाच्या शेवटी, मी मायक्रोसर्व्हिस आर्किटेक्चर तज्ञ ख्रिस रिचर्डसन यांच्या तीन दिवसीय सेमिनारमध्ये उपस्थित राहण्याच्या संधीबद्दल बोलेन).

आम्ही मायक्रोसर्व्हिसेसमध्ये कसे आलो

एविटो ही जगातील सर्वात मोठी वर्गीकृत साइट आहे; त्यावर दररोज 15 दशलक्षाहून अधिक नवीन जाहिराती प्रकाशित केल्या जातात. आमचा बॅकएंड प्रति सेकंद 20 हजाराहून अधिक विनंत्या स्वीकारतो. आमच्याकडे सध्या शेकडो मायक्रो सर्व्हिसेस आहेत.

आम्ही अनेक वर्षांपासून मायक्रोसर्व्हिस आर्किटेक्चर तयार करत आहोत. नक्की कसे - तपशीलवार आमचे सहकारी सांगितले RIT++ 2017 वरील आमच्या विभागात. CodeFest 2017 मध्ये (पहा. видео), सेर्गेई ऑर्लोव्ह आणि मिखाईल प्रोकोपचुक यांनी आम्हाला मायक्रोसर्व्हिसेसमध्ये संक्रमण का आवश्यक आहे आणि कुबर्नेट्सने येथे कोणती भूमिका बजावली हे तपशीलवार सांगितले. बरं, आता आम्ही अशा आर्किटेक्चरमध्ये अंतर्भूत असलेले स्केलिंग खर्च कमी करण्यासाठी सर्वकाही करत आहोत.

सुरुवातीला, आम्ही अशी इकोसिस्टम तयार केली नाही जी आम्हाला सर्वसमावेशकपणे मायक्रो सर्व्हिसेस विकसित आणि लॉन्च करण्यात मदत करेल. त्यांनी फक्त समंजस ओपन सोर्स सोल्यूशन्स गोळा केले, त्यांना घरी लॉन्च केले आणि विकासकाला त्यांच्याशी व्यवहार करण्यासाठी आमंत्रित केले. परिणामी, तो डझनभर ठिकाणी (डॅशबोर्ड, अंतर्गत सेवा) गेला, त्यानंतर तो जुन्या पद्धतीने, एका मोनोलिथमध्ये कोड कट करण्याच्या त्याच्या इच्छेने मजबूत झाला. खालील आकृत्यांमधील हिरवा रंग विकासक त्याच्या स्वत: च्या हातांनी एक किंवा दुसर्या मार्गाने काय करतो हे सूचित करतो आणि पिवळा रंग ऑटोमेशन दर्शवतो.

आता PaaS CLI युटिलिटीमध्ये, एका कमांडसह नवीन सेवा तयार केली जाते आणि आणखी दोनसह नवीन डेटाबेस जोडला जातो आणि स्टेजवर तैनात केला जातो.

"मायक्रोसर्व्हिस फ्रॅगमेंटेशन" च्या युगावर मात कशी करावी

मोनोलिथिक आर्किटेक्चरसह, उत्पादनातील बदलांच्या सुसंगततेसाठी, विकासकांना त्यांच्या शेजाऱ्यांसह काय चालले आहे हे शोधण्यास भाग पाडले गेले. नवीन आर्किटेक्चरवर काम करताना, सेवा संदर्भ यापुढे एकमेकांवर अवलंबून नाहीत.

याव्यतिरिक्त, मायक्रोसर्व्हिस आर्किटेक्चर प्रभावी होण्यासाठी, अनेक प्रक्रिया स्थापित करणे आवश्यक आहे, म्हणजे:

• लॉगिंग;
• विनंती ट्रेसिंग (जेगर);
• त्रुटी एकत्रीकरण (Sentry);
• स्थिती, संदेश, कुबर्नेट्स (इव्हेंट स्ट्रीम प्रोसेसिंग);
• रेस मर्यादा / सर्किट ब्रेकर (तुम्ही Hystrix वापरू शकता);
• सेवा कनेक्टिव्हिटीचे नियंत्रण (आम्ही नेत्रमेश वापरतो);
• देखरेख (ग्राफाना);
• असेंब्ली (टीमसिटी);
• संप्रेषण आणि सूचना (स्लॅक, ईमेल);
• टास्क ट्रॅकिंग; (जिरा)
• कागदपत्रांची तयारी.

प्रणाली तिची अखंडता गमावत नाही आणि ती स्केल करताना प्रभावी राहते याची खात्री करण्यासाठी, आम्ही Avito मधील मायक्रो सर्व्हिसेसच्या संघटनेचा पुनर्विचार केला.

आम्ही मायक्रो सर्व्हिसेस कसे व्यवस्थापित करतो

अनेक एविटो मायक्रो सर्व्हिसेसमध्ये एकसंध “पक्ष धोरण” लागू करण्यात पुढील मदत होते:

• पायाभूत सुविधांचे स्तरांमध्ये विभाजन करणे;
• सेवा (PaaS) संकल्पना म्हणून प्लॅटफॉर्म;
• मायक्रोसर्व्हिसेससह घडणाऱ्या प्रत्येक गोष्टीचे निरीक्षण करणे.

इन्फ्रास्ट्रक्चर ॲब्स्ट्रॅक्शन लेयर्समध्ये तीन स्तरांचा समावेश होतो. चला वरपासून खालपर्यंत जाऊया.

A. शीर्ष - सेवा जाळी. सुरुवातीला आम्ही Istio चा प्रयत्न केला, परंतु असे दिसून आले की ते खूप संसाधने वापरते, जे आमच्या खंडांसाठी खूप महाग आहे. म्हणून, आर्किटेक्चर टीममधील वरिष्ठ अभियंता अलेक्झांडर लुक्यानचेन्को यांनी स्वतःचे समाधान विकसित केले - नेत्रमेश (मुक्त स्त्रोतामध्ये उपलब्ध), जे आम्ही सध्या उत्पादनात वापरतो आणि जे Istio पेक्षा कितीतरी पट कमी संसाधने वापरतो (परंतु Istio ज्या गोष्टींचा अभिमान बाळगू शकतो ते करत नाही).
B. मध्यम - कुबर्नेट्स. आम्ही त्यावर मायक्रोसर्व्हिसेस तैनात आणि ऑपरेट करतो.
C. तळ - बेअर मेटल. आम्ही ढग किंवा OpenStack सारख्या गोष्टी वापरत नाही, परंतु पूर्णपणे बेअर मेटलवर अवलंबून असतो.

सर्व स्तर PaaS द्वारे एकत्र केले जातात. आणि या प्लॅटफॉर्ममध्ये तीन भाग असतात.

I. जनरेटर, CLI युटिलिटी द्वारे नियंत्रित. तीच विकासकाला योग्य मार्गाने आणि कमीत कमी प्रयत्नाने मायक्रोसर्व्हिस तयार करण्यात मदत करते.

II. एकत्रित संग्राहक सामान्य डॅशबोर्डद्वारे सर्व साधनांच्या नियंत्रणासह.

III. स्टोरेज. शेड्युलरशी कनेक्ट होते जे लक्षणीय क्रियांसाठी स्वयंचलितपणे ट्रिगर सेट करतात. अशा प्रणालीबद्दल धन्यवाद, एकही कार्य चुकले नाही कारण कोणीतरी जिरामध्ये कार्य सेट करण्यास विसरले आहे. आम्ही यासाठी Atlas नावाचे अंतर्गत साधन वापरतो.

अविटोमध्ये मायक्रोसर्व्हिसेसची अंमलबजावणी देखील एकाच योजनेनुसार केली जाते, जी विकास आणि प्रकाशनाच्या प्रत्येक टप्प्यावर त्यांचे नियंत्रण सुलभ करते.

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

सर्वसाधारणपणे, मायक्रोसर्व्हिस निर्मिती साखळी यासारखी दिसते:

CLI-पुश → कंटिन्युअस इंटिग्रेशन → बेक → डिप्लॉय → कृत्रिम चाचण्या → कॅनरी चाचण्या → स्क्विज टेस्टिंग → उत्पादन → देखभाल.

चला या क्रमाने नक्की पाहू.

CLI-पुश

• मायक्रो सर्व्हिस तयार करणे.
प्रत्येक विकासकाला मायक्रोसर्व्हिसेस कशी करायची हे शिकवण्यासाठी आम्ही बराच काळ संघर्ष केला. यात कॉन्फ्लुअन्समध्ये तपशीलवार सूचना लिहिण्याचा समावेश होता. पण योजना बदलल्या आणि पूरक ठरल्या. याचा परिणाम असा आहे की प्रवासाच्या सुरूवातीस एक अडचण दिसून आली: मायक्रोसर्व्हिसेस लाँच करण्यासाठी जास्त वेळ लागला आणि तरीही त्यांच्या निर्मिती दरम्यान अनेकदा समस्या उद्भवल्या.

शेवटी, आम्ही एक साधी CLI उपयुक्तता तयार केली जी मायक्रोसर्व्हिस तयार करताना मूलभूत पायऱ्या स्वयंचलित करते. खरं तर, ते पहिल्या गिट पुशची जागा घेते. ती नक्की काय करते ते येथे आहे.

— टेम्प्लेटनुसार सेवा तयार करते — स्टेप बाय स्टेप, “विझार्ड” मोडमध्ये. आमच्याकडे अविटो बॅकएंडमधील मुख्य प्रोग्रामिंग भाषांसाठी टेम्पलेट्स आहेत: PHP, गोलंग आणि पायथन.

- एका वेळी एक कमांड विशिष्ट मशीनवर स्थानिक विकासासाठी वातावरण तैनात करते - Minikube लाँच केले जाते, हेल्म चार्ट स्वयंचलितपणे व्युत्पन्न केले जातात आणि स्थानिक kubernetes मध्ये लॉन्च केले जातात.

- आवश्यक डेटाबेस कनेक्ट करते. डेव्हलपरला त्याला आवश्यक असलेल्या डेटाबेसमध्ये प्रवेश मिळवण्यासाठी IP, लॉगिन आणि पासवर्ड माहित असणे आवश्यक नाही - मग ते स्थानिक पातळीवर असो, स्टेजवर किंवा उत्पादनात. शिवाय, डेटाबेस तत्काळ फॉल्ट-टोलरंट कॉन्फिगरेशनमध्ये आणि बॅलन्सिंगसह तैनात केला जातो.

- हे थेट असेंब्ली स्वतः करते. समजा विकासकाने त्याच्या IDE द्वारे मायक्रो सर्व्हिसमध्ये काहीतरी दुरुस्त केले आहे. युटिलिटी फाइल सिस्टीममधील बदल पाहते आणि त्यांच्या आधारे, ऍप्लिकेशन (गोलांगसाठी) पुन्हा तयार करते आणि रीस्टार्ट करते. PHP साठी, आम्ही फक्त क्यूबच्या आत डिरेक्टरी फॉरवर्ड करतो आणि तेथे लाइव्ह-रीलोड "स्वयंचलितपणे" प्राप्त होते.

- ऑटोटेस्ट्स व्युत्पन्न करते. रिक्त स्वरूपात, परंतु वापरासाठी अगदी योग्य.

• सूक्ष्म सेवा उपयोजन.

मायक्रोसर्व्हिस उपयोजित करणे आमच्यासाठी थोडे काम होते. पुढील गोष्टी आवश्यक होत्या:

I. डॉकरफाइल.

II. कॉन्फिग.
III. हेल्म चार्ट, जो स्वतःच अवजड आहे आणि त्यात समाविष्ट आहे:

- चार्ट स्वतः;
- टेम्पलेट्स;
- भिन्न वातावरण लक्षात घेऊन विशिष्ट मूल्ये.

आम्ही Kubernetes मॅनिफेस्ट्सचे पुन्हा काम केल्याने वेदना काढून टाकल्या आहेत त्यामुळे ते आता आपोआप तयार होतात. परंतु सर्वात महत्त्वाचे म्हणजे त्यांनी तैनाती मर्यादेपर्यंत सुलभ केली. आतापासून आमच्याकडे डॉकरफाइल आहे आणि विकसक संपूर्ण कॉन्फिगरेशन एका लहान app.toml फाइलमध्ये लिहितो.

होय, आणि app.toml मध्येच एका मिनिटासाठी काहीही करायचे नाही. सेवेच्या किती आणि किती प्रती वाढवायच्या हे आम्ही निर्दिष्ट करतो (डेव्ह सर्व्हरवर, स्टेजिंगवर, उत्पादनामध्ये) आणि त्याची अवलंबित्व सूचित करतो. [इंजिन] ब्लॉकमधील रेषेचा आकार = "लहान" लक्षात घ्या. ही मर्यादा आहे जी Kubernetes द्वारे सेवेसाठी वाटप केली जाईल.

नंतर, कॉन्फिगरेशनवर आधारित, सर्व आवश्यक हेल्म चार्ट स्वयंचलितपणे व्युत्पन्न केले जातात आणि डेटाबेसशी कनेक्शन तयार केले जातात.

• मूलभूत प्रमाणीकरण. अशा तपासण्याही स्वयंचलित असतात.
ट्रॅक करणे आवश्यक आहे:
- तेथे डॉकरफाइल आहे का;
— तेथे app.toml आहे;
- तेथे कागदपत्रे उपलब्ध आहेत का?
- अवलंबित्व क्रमाने आहे का?
— अलर्टचे नियम सेट केले आहेत की नाही.
शेवटच्या मुद्द्यापर्यंत: सेवेचा मालक स्वतः ठरवतो की कोणत्या उत्पादनाच्या मेट्रिक्सचे परीक्षण करावे.

• कागदपत्रांची तयारी.
तरीही एक समस्या क्षेत्र. हे सर्वात स्पष्ट असल्याचे दिसते, परंतु त्याच वेळी ते "अनेकदा विसरलेले" रेकॉर्ड देखील आहे आणि म्हणूनच साखळीतील एक असुरक्षित दुवा आहे.
प्रत्येक मायक्रोसेवेसाठी कागदपत्रे असणे आवश्यक आहे. यात खालील ब्लॉक्सचा समावेश आहे.

I. सेवेचे संक्षिप्त वर्णन. ते काय करते आणि ते का आवश्यक आहे याबद्दल अक्षरशः काही वाक्ये.

II. आर्किटेक्चर डायग्राम लिंक. हे महत्त्वाचे आहे की त्यावर द्रुत दृष्टीक्षेप टाकल्यास ते समजणे सोपे आहे, उदाहरणार्थ, तुम्ही कॅशिंगसाठी रेडिस वापरत आहात किंवा पर्सिस्टंट मोडमध्ये मुख्य डेटा स्टोअर म्हणून वापरत आहात. अविटोमध्ये आत्तासाठी हा कॉन्फ्लुएंसचा दुवा आहे.

III. रनबुक. सेवा सुरू करण्याबाबतचे एक छोटेसे मार्गदर्शन आणि ती हाताळण्याची गुंतागुंत.

IV. वारंवार विचारले जाणारे प्रश्न, जेथे सेवेसोबत काम करताना तुमच्या सहकाऱ्यांना येणाऱ्या समस्यांचा अंदाज घेणे चांगले होईल.

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

सहावा. लेबल्स. किंवा सेवा कोणत्या कंपनीशी संबंधित आहे याचे उत्पादन, कार्यक्षमता किंवा संरचनात्मक विभाग दर्शवणारे मार्कर. ते तुम्हाला त्वरीत समजण्यास मदत करतात, उदाहरणार्थ, तुमच्या सहकाऱ्यांनी एका आठवड्यापूर्वी त्याच व्यवसाय युनिटसाठी आणलेली कार्यक्षमता तुम्ही कमी करत आहात की नाही.

VII. सेवेचे मालक किंवा मालक. बहुतेक प्रकरणांमध्ये, ते — किंवा ते — PaaS वापरून स्वयंचलितपणे निर्धारित केले जाऊ शकतात, परंतु सुरक्षिततेसाठी, आम्हाला विकासकाने ते व्यक्तिचलितपणे निर्दिष्ट करणे आवश्यक आहे.

शेवटी, दस्तऐवजाचे पुनरावलोकन करणे ही एक चांगली सराव आहे, कोड पुनरावलोकनाप्रमाणेच.

सतत एकत्रीकरण

• भांडार तयार करत आहे.
• टीमसिटीमध्ये पाइपलाइन तयार करणे.
• अधिकार सेट करणे.
• सेवा मालकांसाठी शोधा. येथे एक हायब्रिड योजना आहे - मॅन्युअल मार्किंग आणि PaaS कडून किमान ऑटोमेशन. जेव्हा सेवा दुसऱ्या डेव्हलपमेंट टीमला समर्थनासाठी हस्तांतरित केली जाते किंवा, उदाहरणार्थ, सेवा विकासकाने सोडल्यास पूर्ण स्वयंचलित योजना अयशस्वी होते.
• ॲटलसमध्ये सेवेची नोंदणी करणे (वर पहा). त्याच्या सर्व मालकांसह आणि अवलंबित्वांसह.
• स्थलांतर तपासत आहे. त्यापैकी कोणतीही संभाव्य धोकादायक आहे का ते आम्ही तपासतो. उदाहरणार्थ, त्यांपैकी एकामध्ये बदल टेबल किंवा दुसरे काहीतरी पॉप अप होते जे सेवेच्या विविध आवृत्त्यांमधील डेटा स्कीमाची सुसंगतता खंडित करू शकते. नंतर स्थलांतर केले जात नाही, परंतु सदस्यत्वामध्ये ठेवले जाते - जेव्हा ते वापरणे सुरक्षित असेल तेव्हा PaaS ने सेवा मालकास सिग्नल करणे आवश्यक आहे.

बेक करावे

पुढील टप्पा तैनातीपूर्वी पॅकेजिंग सेवा आहे.

• अर्ज तयार करणे. क्लासिक्सनुसार - डॉकर प्रतिमेमध्ये.
• सेवेसाठी आणि संबंधित संसाधनांसाठी हेल्म चार्टची निर्मिती. डेटाबेस आणि कॅशेसह. ते CLI-पुश स्टेजवर तयार केलेल्या app.toml कॉन्फिगरेशननुसार आपोआप तयार केले जातात.
• पोर्ट उघडण्यासाठी प्रशासकांसाठी तिकिटे तयार करणे (आवश्यक असेल तेव्हा).
• युनिट चाचण्या चालवणे आणि कोड कव्हरेजची गणना करणे. जर कोड कव्हरेज निर्दिष्ट थ्रेशोल्डच्या खाली असेल, तर बहुधा सेवा पुढे जाणार नाही - तैनात करण्यासाठी. जर ते स्वीकार्य होण्याच्या मार्गावर असेल, तर सेवेला "निराशाजनक" गुणांक नियुक्त केला जाईल: नंतर, कालांतराने निर्देशकामध्ये कोणतीही सुधारणा न झाल्यास, विकासकाला एक सूचना प्राप्त होईल की चाचण्यांच्या बाबतीत कोणतीही प्रगती नाही ( आणि त्याबद्दल काहीतरी करणे आवश्यक आहे).
• मेमरी आणि CPU मर्यादांसाठी लेखांकन. आम्ही प्रामुख्याने गोलांगमध्ये मायक्रोसर्व्हिसेस लिहितो आणि कुबर्नेट्समध्ये चालवतो. म्हणूनच गोलंग भाषेच्या वैशिष्ट्याशी संबंधित एक सूक्ष्मता: डीफॉल्टनुसार, प्रारंभ करताना, मशीनवरील सर्व कोर वापरले जातात, जर तुम्ही GOMAXPROCS व्हेरिएबल स्पष्टपणे सेट केले नाही आणि जेव्हा अशा अनेक सेवा एकाच मशीनवर सुरू केल्या जातात तेव्हा त्या सुरू होतात. संसाधनांसाठी स्पर्धा करणे, एकमेकांमध्ये हस्तक्षेप करणे. खालील आलेख दाखवतात की तुम्ही वादविना आणि संसाधन मोडच्या शर्यतीत अनुप्रयोग चालवल्यास अंमलबजावणीची वेळ कशी बदलते. (ग्राफचे स्त्रोत आहेत येथे).

अंमलबजावणी वेळ, कमी चांगले आहे. कमाल: 643ms, किमान: 42ms. फोटो क्लिक करण्यायोग्य आहे.

शस्त्रक्रियेसाठी वेळ, कमी चांगले आहे. कमाल: 14091 एनएस, किमान: 151 एनएस. फोटो क्लिक करण्यायोग्य आहे.

असेंबली तयारीच्या टप्प्यावर, तुम्ही हे व्हेरिएबल स्पष्टपणे सेट करू शकता किंवा तुम्ही लायब्ररी वापरू शकता automaxprocs Uber च्या मुलांकडून.

तैनात करणे

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

एविटोमध्ये अद्याप फारशी अधिवेशने नाहीत, परंतु त्यांचा पूल विस्तारत आहे. संघ समजू शकेल आणि समजू शकेल अशा स्वरूपात असे करार जितके अधिक उपलब्ध असतील तितकेच मायक्रो सर्व्हिसेसमध्ये सातत्य राखणे सोपे होईल.

सिंथेटिक चाचण्या

• बंद लूप चाचणी. यासाठी आपण आता ओपन सोर्स वापरत आहोत Hoverfly.io. प्रथम, ते सेवेवरील वास्तविक भार रेकॉर्ड करते, नंतर - फक्त बंद लूपमध्ये - ते त्याचे अनुकरण करते.

• ताण चाचणी. आम्ही सर्व सेवा चांगल्या कामगिरीवर आणण्याचा प्रयत्न करतो. आणि प्रत्येक सेवेच्या सर्व आवृत्त्या लोड चाचणीच्या अधीन असणे आवश्यक आहे - अशा प्रकारे आम्ही सेवेचे वर्तमान कार्यप्रदर्शन आणि त्याच सेवेच्या मागील आवृत्त्यांमधील फरक समजू शकतो. जर, सेवा अद्यतनानंतर, त्याचे कार्यप्रदर्शन दीड पटीने कमी झाले, तर हे त्याच्या मालकांसाठी एक स्पष्ट सिग्नल आहे: आपल्याला कोडमध्ये खोदून परिस्थिती दुरुस्त करण्याची आवश्यकता आहे.
आम्ही गोळा केलेला डेटा वापरतो, उदाहरणार्थ, ऑटो स्केलिंग योग्यरित्या अंमलात आणण्यासाठी आणि शेवटी, सेवा किती स्केलेबल आहे हे समजते.

लोड चाचणी दरम्यान, आम्ही संसाधनाचा वापर निर्धारित मर्यादा पूर्ण करतो की नाही ते तपासतो. आणि आम्ही प्रामुख्याने टोकावर लक्ष केंद्रित करतो.

अ) आम्ही एकूण भार पाहतो.
- खूप लहान - लोड अचानक अनेक वेळा कमी झाल्यास बहुधा काहीतरी कार्य करत नाही.
- खूप मोठे - ऑप्टिमायझेशन आवश्यक आहे.

b) आम्ही RPS नुसार कटऑफ पाहतो.
येथे आपण वर्तमान आवृत्ती आणि मागील आवृत्ती आणि एकूण प्रमाण यांच्यातील फरक पाहतो. उदाहरणार्थ, जर एखादी सेवा 100 आरपीएस तयार करते, तर ती एकतर खराब लिहिली जाते किंवा ही त्याची विशिष्टता आहे, परंतु कोणत्याही परिस्थितीत, सेवेकडे बारकाईने पाहण्याचे हे एक कारण आहे.
जर, उलटपक्षी, खूप जास्त आरपीएस असतील, तर कदाचित एक प्रकारचा बग आहे आणि काही एंडपॉइंट्सने पेलोड कार्यान्वित करणे थांबवले आहे आणि इतर काही फक्त ट्रिगर झाले आहेत. return true;

कॅनरी चाचण्या

आम्ही सिंथेटिक चाचण्या उत्तीर्ण केल्यानंतर, आम्ही थोड्या संख्येने वापरकर्त्यांवर मायक्रो सर्व्हिसची चाचणी करतो. आम्ही काळजीपूर्वक सुरुवात करतो, सेवेच्या अभिप्रेत प्रेक्षकांच्या अल्प वाटा - ०.१% पेक्षा कमी. या टप्प्यावर, देखरेखीमध्ये योग्य तांत्रिक आणि उत्पादन मेट्रिक्स समाविष्ट करणे खूप महत्वाचे आहे जेणेकरून ते शक्य तितक्या लवकर सेवेमध्ये समस्या दर्शवतील. कॅनरी चाचणीसाठी किमान वेळ 0,1 मिनिटे आहे, मुख्य म्हणजे 5 तास. जटिल सेवांसाठी, आम्ही स्वतः वेळ सेट करतो.
चला विश्लेषण करूया:
— भाषा-विशिष्ट मेट्रिक्स, विशेषतः, php-fpm कामगार;
- सेन्ट्रीमधील त्रुटी;
- प्रतिसाद स्थिती;
- प्रतिसाद वेळ, अचूक आणि सरासरी;
- विलंब;
- अपवाद, प्रक्रिया केलेले आणि न हाताळलेले;
- उत्पादन मेट्रिक्स.

पिळणे चाचणी

स्क्वीझ टेस्टिंगला "स्क्वीझिंग" टेस्टिंग असेही म्हणतात. तंत्राचे नाव नेटफ्लिक्समध्ये सादर केले गेले. त्याचे सार हे आहे की प्रथम आपण एक उदाहरण वास्तविक रहदारीसह अयशस्वी होण्याच्या बिंदूपर्यंत भरतो आणि अशा प्रकारे त्याची मर्यादा सेट करतो. मग आम्ही आणखी एक उदाहरण जोडतो आणि ही जोडी लोड करतो - पुन्हा जास्तीत जास्त; आम्ही त्यांची कमाल मर्यादा आणि डेल्टा पहिल्या "स्क्विज" सह पाहतो. आणि म्हणून आम्ही एका वेळी एक प्रसंग जोडतो आणि बदलांच्या पॅटर्नची गणना करतो.
"स्क्विजिंग" द्वारे चाचणी डेटा देखील एका सामान्य मेट्रिक्स डेटाबेसमध्ये प्रवाहित होतो, जिथे आम्ही एकतर त्यांच्यासह कृत्रिम लोड परिणाम समृद्ध करतो किंवा त्यांच्यासह "सिंथेटिक्स" देखील बदलतो.

उत्पादन

• स्केलिंग. जेव्हा आम्ही उत्पादनासाठी सेवा रोल आउट करतो, तेव्हा आम्ही त्याचे प्रमाण कसे मोजतो यावर लक्ष ठेवतो. आमच्या अनुभवात, फक्त CPU निर्देशकांचे निरीक्षण करणे अप्रभावी आहे. RPS बेंचमार्किंगसह ऑटो स्केलिंग त्याच्या शुद्ध स्वरूपात कार्य करते, परंतु केवळ ऑनलाइन स्ट्रीमिंगसारख्या विशिष्ट सेवांसाठी. म्हणून आम्ही प्रथम अनुप्रयोग-विशिष्ट उत्पादन मेट्रिक्स पाहतो.

परिणामी, स्केलिंग करताना आम्ही विश्लेषण करतो:
- सीपीयू आणि रॅम निर्देशक,
- रांगेतील विनंत्यांची संख्या,
- प्रतिसाद वेळ,
— जमा झालेल्या ऐतिहासिक डेटावर आधारित अंदाज.

सेवा स्केलिंग करताना, त्याच्या अवलंबित्वांचे निरीक्षण करणे देखील महत्त्वाचे आहे जेणेकरून आम्ही साखळीतील पहिली सेवा मोजू नये आणि ती ज्यामध्ये प्रवेश करते त्या लोडखाली अयशस्वी होतात. सेवांच्या संपूर्ण पूलसाठी स्वीकार्य लोड स्थापित करण्यासाठी, आम्ही "नजीकच्या" अवलंबित सेवेचा ऐतिहासिक डेटा पाहतो (सीपीयू आणि रॅम निर्देशकांच्या संयोजनावर आधारित, ॲप-विशिष्ट मेट्रिक्ससह) आणि त्यांची ऐतिहासिक डेटाशी तुलना करतो. आरंभिक सेवेचे, आणि असेच संपूर्ण “अवलंबन साखळी” मध्ये, वरपासून खालपर्यंत.

सेवा

मायक्रोसर्व्हिस कार्यान्वित झाल्यानंतर, आम्ही त्यास ट्रिगर जोडू शकतो.

येथे विशिष्ट परिस्थिती आहेत ज्यामध्ये ट्रिगर्स होतात.
- संभाव्य धोकादायक स्थलांतर आढळले.
- सुरक्षा अद्यतने जारी केली गेली आहेत.
- सेवा स्वतःच बर्याच काळापासून अद्यतनित केलेली नाही.
— सेवेवरील भार लक्षणीयरीत्या कमी झाला आहे किंवा त्याचे काही उत्पादन मेट्रिक्स सामान्य श्रेणीच्या बाहेर आहेत.
— सेवा यापुढे नवीन प्लॅटफॉर्म आवश्यकता पूर्ण करत नाही.

काही ट्रिगर ऑपरेशनच्या स्थिरतेसाठी जबाबदार आहेत, काही - सिस्टम देखरेखीचे कार्य म्हणून - उदाहरणार्थ, काही सेवा बर्याच काळापासून तैनात केली गेली नाहीत आणि तिची मूळ प्रतिमा सुरक्षा तपासणी पास करणे थांबवले आहे.

डॅशबोर्ड

थोडक्यात, डॅशबोर्ड हे आमच्या संपूर्ण PaaS चे कंट्रोल पॅनल आहे.

• सेवेबद्दल माहितीचा एक बिंदू, त्याच्या चाचणी कव्हरेजवरील डेटासह, त्याच्या प्रतिमांची संख्या, उत्पादन प्रतींची संख्या, आवृत्त्या इ.
• सेवा आणि लेबलांद्वारे डेटा फिल्टर करण्यासाठी एक साधन (व्यवसाय युनिट्सचे मार्कर, उत्पादन कार्यक्षमता इ.)
• ट्रेसिंग, लॉगिंग आणि मॉनिटरिंगसाठी इन्फ्रास्ट्रक्चर टूल्ससह एकत्रीकरणाचे साधन.
• सेवा दस्तऐवजीकरणाचा एकच बिंदू.
• सेवांमधील सर्व इव्हेंटचा एकच दृष्टिकोन.

एकूण

PaaS ची ओळख करून देण्यापूर्वी, नवीन विकसक उत्पादनामध्ये मायक्रोसर्व्हिस लाँच करण्यासाठी आवश्यक असलेली सर्व साधने समजून घेण्यासाठी अनेक आठवडे घालवू शकतो: Kubernetes, Helm, आमची अंतर्गत TeamCity वैशिष्ट्ये, दोष-सहिष्णु पद्धतीने डेटाबेस आणि कॅशेशी कनेक्शन सेट करणे इ. आता. क्विकस्टार्ट वाचण्यासाठी आणि सेवा स्वतः तयार करण्यासाठी काही तास लागतात.

मी HighLoad++ 2018 साठी या विषयावर एक अहवाल दिला आहे, तुम्ही तो पाहू शकता видео и सादरीकरण.

जे शेवटपर्यंत वाचतात त्यांच्यासाठी बोनस ट्रॅक

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

हे प्रशिक्षण 5 ते 7 ऑगस्ट दरम्यान मॉस्को येथे होणार आहे. हे कामाचे दिवस आहेत जे पूर्णपणे व्यापले जातील. दुपारचे जेवण आणि प्रशिक्षण आमच्या कार्यालयात असेल आणि निवडलेला सहभागी प्रवास आणि निवासासाठी स्वतः पैसे देईल.

तुम्ही सहभागासाठी अर्ज करू शकता या गुगल फॉर्म मध्ये. तुमच्याकडून - तुम्हाला प्रशिक्षणाला उपस्थित राहण्याची गरज का आहे या प्रश्नाचे उत्तर आणि तुमच्याशी संपर्क कसा साधावा याबद्दल माहिती. इंग्रजीत उत्तर द्या, कारण ख्रिस स्वतः प्रशिक्षणाला उपस्थित राहणारा सहभागी निवडेल.
आम्ही या पोस्टच्या अपडेटमध्ये आणि डेव्हलपरसाठी Avito सोशल नेटवर्क्सवर प्रशिक्षण सहभागीचे नाव घोषित करू (AvitoTech in फेसबुक, Вконтакте, ट्विटर) 19 जुलै नंतर नाही.

स्त्रोत: www.habr.com