हाय% उपयोगकर्ता नाम%!
हाल ही में, हाईलोड ++ सम्मेलन समाप्त हो गया (व्यक्तिगत रूप से आयोजकों की पूरी टीम और व्यक्तिगत रूप से फिर से धन्यवाद। यह बहुत अच्छा था!)।
सम्मेलन की पूर्व संध्या पर, एलेक्सी
फिशर ने सम्मेलन में "स्टॉकर्स" का एक पहल समूह बनाने का प्रस्ताव दिया। रिपोर्टों के दौरान, हमने छोटे नोट लिखे जिनका हमने आदान-प्रदान किया। कुछ नोट काफी विस्तृत और विस्तृत निकले।
सामाजिक नेटवर्क में समुदाय ने इस प्रारूप का सकारात्मक मूल्यांकन किया, इसलिए मैंने (अनुमति के साथ) पहली रिपोर्ट का एक सारांश प्रकाशित करने का निर्णय लिया। यदि यह प्रारूप दिलचस्प है, तो मैं कई और लेख तैयार कर सकता हूं।
मिल जाना
Avito में कई सेवाएं और उनके बीच बहुत सारे कनेक्शन हैं। इसके कारण समस्याएँ होती हैं:
- रिपॉजिटरी के बहुत सारे। एक साथ हर जगह कोड बदलना कठिन है
- टीमें उनके संदर्भ से सीमित हैं। अधिकतम ओवरलैप थोड़ा और सभी नहीं
- डेटा का विखंडन जोड़ा जाता है।
बड़ी संख्या में बुनियादी ढांचे के तत्व:
- लॉगिंग
- अनुरोध ट्रेस (Jaeger)
- त्रुटि एकत्रीकरण (संतरी)
- कुबेरनेट्स से सांख्यिक / संदेश / घटनाएँ
- रेस लिमिट / सर्किट ब्रेकर (हिस्टि्रक्स)
- सेवा कनेक्टिविटी (इस्तियो)
- निगरानी (ग्राफाना)
- विधानसभा (टीमसिटी)
- संचार
- टास्क ट्रैकर
- प्रलेखन
- ...
कई परतें हैं; रिपोर्ट केवल एक का वर्णन करती है (PaaS)।
मंच के 3 मुख्य भाग हैं:
- जेनरेटर क्ली द्वारा नियंत्रित
- एग्रीगेटर (कलेक्टर), जिसे डैशबोर्ड के माध्यम से नियंत्रित किया जाता है
- कुछ क्रियाओं के लिए ट्रिगर के साथ संग्रहण।
मानक माइक्रोसर्विस डेवलपमेंट पाइपलाइन
सीएलआई-पुश -> सीआई -> सेंकना -> तैनात -> परीक्षण -> कैनरी -> उत्पादनCLI-धक्का
लंबे समय तक सही डेवलपर्स को करना सिखाया। सभी समान, यह एक कमजोर बिंदु बना रहा।
माइक्रो उपयोगिता के लिए एक आधार बनाने में मदद करने वाली क्ली उपयोगिता के माध्यम से स्वचालित:
- एक टेम्पलेट सेवा बनाता है (कई पीएल के लिए टेम्पलेट समर्थित हैं)।
- स्थानीय विकास के लिए बुनियादी ढांचे को स्वचालित रूप से तैनात करता है
- एक डेटाबेस जोड़ता है (कॉन्फ़िगरेशन की आवश्यकता नहीं है, डेवलपर किसी भी डेटाबेस तक पहुंच के बारे में नहीं सोचता है)।
- लाइव निर्माण
- ऑटोटेस्ट डिस्क पीढ़ी।
कॉन्फ़िगर को टोल फ़ाइल में वर्णित किया गया है।
उदाहरण फ़ाइल:
मान्यता
मूल सत्यापन जांच:
- Dockerfile उपलब्धता
- app.toml
- प्रलेखन की उपलब्धता
- निर्भरता
- निगरानी के लिए अलर्ट नियम (सेवा मालिक द्वारा निर्धारित)
प्रलेखन
सभी के पास प्रलेखन होना चाहिए, लेकिन लगभग किसी के पास नहीं है
प्रलेखन में शामिल होना चाहिए:
- सेवा का विवरण (संक्षिप्त)
- वास्तुकला आरेख के लिए लिंक
- Runbook
- पूछे जाने वाले प्रश्न
- समापन बिंदु एपीआई विवरण
- लेबल (उत्पाद, कार्यक्षमता, संरचनात्मक विभाजन के लिए बाध्यकारी)
- सेवा के मालिक (ओं) में कई हो सकते हैं, ज्यादातर मामलों में यह स्वचालित रूप से निर्धारित किया जा सकता है।
दस्तावेज़ीकरण की समीक्षा करने की आवश्यकता है।
पाइपलाइन तैयार करना
- खाना पकाने के रिपोजिटरी
- TeamCity में पाइपलाइन बनाना
- हमने अधिकार निर्धारित किए
- हम मालिक की तलाश कर रहे हैं (दो, एक अविश्वसनीय)
- एटलस (आंतरिक उत्पाद) में रजिस्टर सेवा
- माइग्रेशन चेक करें।
सेंकना
- डॉकटर छवि में एप्लिकेशन का निर्माण।
- सेवा और संबंधित संसाधनों (डीबी, कैश) के लिए हेल्म चार्ट का निर्माण
- पोर्ट खोलने के लिए प्रशासकों के लिए टिकट बनाए जाते हैं, मेमोरी और सीपीयू प्रतिबंधों को ध्यान में रखा जाता है।
- इकाई परीक्षण चलाएं। कोड-कवरेज बनाए रखा जा रहा है। यदि एक निश्चित से नीचे है, तो तैनाती को लपेटता है। यदि कवरेज प्रगति नहीं करता है, तो सूचनाएं धकेल दी जाती हैं।
स्वामी की खोज को पुश (पुश की संख्या और उनमें कोड की मात्रा) द्वारा निर्धारित किया जाता है।
यदि संभावित खतरनाक माइग्रेशन (परिवर्तन) होते हैं, तो ट्रिगर एटलस में पंजीकृत होता है और सेवा संगरोधित होती है।
मालिकों को पुश के माध्यम से संगरोध का समाधान किया जाता है (मैनुअल मोड में?)
कन्वेंशन चेक
हम जाँच करते हैं:
- सेवा समापन बिंदु
- योजना के उत्तर का अनुपालन
- लॉग फॉर्मेट
- हेडर सेट करना (बस के माध्यम से कनेक्टिविटी को ट्रैक करने के लिए बस को संदेश भेजते समय एक्स-सोर्स-आईडी सहित)
परीक्षण
परीक्षण एक बंद लूप में किया जाता है (उदाहरण के लिए, hoverfly.io) - एक सामान्य लोड दर्ज किया गया है। फिर इसे बंद लूप में अनुकरण किया जाता है।
संसाधन खपत के पत्राचार की जाँच की जाती है (हम चरम मामलों पर अलग से देखते हैं - बहुत कम / कई संसाधन), आरपीएस द्वारा कट-ऑफ।
लोड परीक्षण भी संस्करणों के बीच एक प्रदर्शन डेल्टा दिखाता है।
कैनरी परीक्षण
हम बहुत कम उपयोगकर्ताओं (<0.1%) पर लॉन्च शुरू करते हैं।
न्यूनतम लोड 5 मिनट। मुख्य 2 घंटे। तब सब कुछ ठीक होने पर उपयोगकर्ताओं की मात्रा बढ़ जाती है।
हम देखते हैं:
- उत्पाद मैट्रिक्स (सबसे पहले) - उनमें से कई हैं (100500)
- संतरी त्रुटियां
- प्रतिक्रिया की स्थिति,
- उत्तरदाता समय - सटीक और औसत प्रतिक्रिया समय
- विलंब
- अपवाद (संसाधित और असंसाधित)
- मीट्रिक भाषा के लिए अधिक विशिष्ट (उदा। Php-fpm कार्यकर्ता)
निचोड़ परीक्षण
एक्सट्रूज़न परीक्षण।
हम वास्तविक उपयोगकर्ताओं को विफलता के बिंदु पर 1 उदाहरण लोड करते हैं। हम इसकी छत को देखते हैं। अगला, एक और उदाहरण जोड़ें और इसे लोड करें। हम अगली छत को देखते हैं। हम प्रतिगमन को देखते हैं। हम एटलस में लोड परीक्षण से डेटा को समृद्ध या प्रतिस्थापित करते हैं।
स्केलिंग
केवल सीपीयू खराब है, आपको उत्पाद मीट्रिक जोड़ने की आवश्यकता है।
अंतिम योजना:
- सीपीयू + रैम
- अनुरोधों की संख्या
- प्रतिक्रिया समय
- ऐतिहासिक पूर्वानुमान
जब स्केलिंग, सेवा निर्भरता को देखने के लिए मत भूलना। स्केलिंग कैस्केड (+1 स्तर) याद रखें। हम प्रारंभिक सेवा के ऐतिहासिक डेटा को देखते हैं।
इसके साथ ही
- ट्रिगर हैंडलिंग - X बचे नीचे कोई संस्करण नहीं होने पर माइग्रेशन
- सेवा लंबे समय से अपडेट नहीं की गई है
- कोरांटीन
- सुरक्षित अद्यतन
डैशबोर्ड
हम ऊपर से सब कुछ एक एकीकृत रूप में देखते हैं और निष्कर्ष निकालते हैं।
- सेवा और लेबल फ़िल्टरिंग
- ट्रेस, लॉगिंग, निगरानी के साथ एकीकरण
- एकल बिंदु सेवा प्रलेखन
- सभी सेवा कार्यक्रमों के प्रदर्शन का एक एकल बिंदु
एक उदाहरण:
