मैं माइग्रेशन एप्लिकेशन के बारे में अपनी कहानी को माइक्रोसर्विस में साझा करना चाहता हूं। कृपया, ध्यान रखें कि यह 2012 - 2014 के दौरान था। यह डॉटनेटकॉन्फ़ (आरयू) में मेरी प्रस्तुति का प्रतिलेखन है। मैं बुनियादी ढांचे के हर हिस्से को बदलने के बारे में एक कहानी साझा करने जा रहा हूं।

परियोजना का विवरण

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

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

क्रौलर

यह बुनियादी ढांचे का एक सरल हिस्सा था। क्रॉलर्स को डाउनलोड, विश्लेषण और बचत करनी चाहिए। पहले एक कार्यान्वयन एकल क्रॉलर था, हालांकि, दुनिया बदल रही थी और बहुत सारे अलग-अलग क्रॉलर दिखाई दिए। MsSQL द्वारा क्रॉलर एक दूसरे के साथ संचार कर रहे थे।

डाउनटाइम क्रॉलर्स के लिए कोई समस्या नहीं थी, इसलिए उन्हें स्केल करना बहुत आसान था:

• स्वचालित प्रावधान।
• व्यावसायिक मैट्रिक्स जोड़ें।
• त्रुटियां एकत्रित करें।

MSSQL

हमारा डेटाबेस लगभग 1TB था।

MsSQL क्लस्टर

क्लस्टर बनाने के विभिन्न तरीके थे:

1. SQL मिररिंग।
2. Windows विफलता क्लस्टर - यह कोई मामला नहीं था क्योंकि कोई सैन / Nas नहीं था।
3. हमेशा - यह हमारे लिए पूरी तरह से नया था और इसमें कोई विशेषज्ञता नहीं थी, इसलिए, यह हमारे लिए कोई मामला नहीं था।

नतीजतन, हमने 1 का उपयोग करने का फैसला किया। मुझे लगता है कि हम async मोड के कारण गवाह का उपयोग नहीं करना चाहते हैं, इसलिए हमने ऑटो स्विच मास्टर -> दास और मैनुअल दास -> मास्टर के लिए स्क्रिप्ट बनाई।

MsSQL perfomance

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

संदेश की कतार

हमारा आवेदन एक संदेश कतार में स्थानांतरित कर दिया गया था। हम डेटाबेस में केवल परिणाम लिख रहे थे। परिणामस्वरूप, हमने डेटाबेस लोड कम किया। लेकिन हमें एक समस्या का सामना करना पड़ा: एक संदेश कतार क्लस्टर कैसे व्यवस्थित करें? सबसे पहले, हमने एक कोल्ड स्टैंडबाय बनाया।

वेब

एक वेब पार्ट में दो भाग होते हैं: स्थिर सामग्री और उपयोगकर्ता गतिशील सामग्री।

वेब स्थिर

WEB अवसंरचना का स्थिर भाग 2TB था, इसमें निम्न शामिल थे:

• चित्र संग्रहित करें।
• छवियाँ परिवर्तित करें।
• यदि आवश्यक हो तो क्रॉल मूल छवि और फसल।

2 प्रमुख मुद्दे थे: फ़ाइलों को कैसे सिंक किया जाए और वेब क्लस्टर कैसे बनाया जाए। फ़ाइलों को सिंक करने के कुछ तरीके थे: एक स्टोरेज खरीदें, प्रत्येक सर्वर पर DFS का उपयोग करें और फाइलों को सेव करें। यह कठिन निर्णय था, हालांकि, हमने तीसरा रास्ता चुनने का फैसला किया। वेब क्लस्टर के लिए, हमने NLB और CDN का उपयोग करने का निर्णय लिया।

वेब Balancer

उच्च-लोड परियोजना के लिए एकल सर्वर का उपयोग करना वास्तव में अच्छा विचार नहीं है, आपको किसी तरह ट्रैफ़िक को संतुलित करना होगा। हमारे मामले में 4 तरीके थे:

1. हार्डवेयर बैलेंसर - यह हमारे लिए बहुत महंगा था।
2. IIS और ARR - यह समर्थन करने के लिए बहुत जटिल था।
3. Nginx - यह काफी अच्छा था, हालांकि, हमने स्वास्थ्य जांच के साथ कुछ मुद्दों का सामना किया।
4. हाप्रोसी - यह सबसे छोटे ओवरहेड के साथ एक समाधान था।

हमने 4 वाँ रास्ता चुना। हम DNS राउंड रॉबिन और कुकी द्वारा उपयोगकर्ताओं द्वारा haproxy को संतुलित कर रहे थे।

MongoDB

कुछ महीनों बाद, हमने सामना किया कि SQL प्रदर्शन फिर से अच्छा नहीं था। यह एक परिष्कृत मुद्दा था, हालांकि, लंबी बातचीत के बाद हमने CAP प्रमेय से उपलब्धता और विभाजन सहिष्णुता चुनने का फैसला किया। नतीजतन, हमने एक MongoDB क्लस्टर (शार्किंग और प्रतिकृति) को लागू किया। एक दिलचस्प अनुभव था: कैसे MongoDB बैकअप बनाने के लिए, कैसे उन्नयन और MongoDB कीड़े का एक बहुत।

बैकअप और निगरानी

हमने 3-2-1 नियम लागू किया:

• कम से कम 3 प्रति।
• कम से कम 2 अलग भंडारण प्रकार।
• कम से कम 1 प्रति कहीं बाहर संग्रहीत की जानी चाहिए।

इसके अलावा, हमने आपदा वसूली योजना बनाई और परीक्षण किया। आप यहां निगरानी के बारे में पढ़ सकते हैं।

अनुप्रयोग अद्यतन

जैसा कि आप देख सकते हैं, बुनियादी ढांचा पाई जितना आसान नहीं था। हमें इसे किसी तरह अपडेट करना था। आकस्मिक अद्यतन की तरह देखा:

1. कुछ तैयारी करो।
2. भागा भागा।
3. वेब एप्लिकेशन अपडेट करें।
4. बैकएंड एप्लिकेशन अपडेट करें।

सभी तार्किक कदम स्टेजिंग / प्रीप्रोड / प्रोडक्शंस वातावरण के लिए समान थे, हालांकि, यह विवरण में थोड़ा अलग था। इसलिए, हमने OOP मैजिक के साथ पॉवरशेल स्क्रिप्ट बनाई। यह हमारे CI / CD अवसंरचना में सुधार की एक सतत प्रक्रिया थी।

निष्कर्ष

यह 3 डेस्कटॉप पीसी को विश्वसनीय बुनियादी ढांचे में स्थानांतरित करने के बारे में एक अद्भुत कहानी थी। धैर्य रखें और योजनाएं बनाएं।

पुनश्च

• डॉटनेटकॉफ़ (आरयू) ।
• स्लाइड्स (आरयू)
• वीडियो (RU)
• यह क्रॉसपोस्ट है