एक हाईलोड परियोजना का इतिहास

एक साथ एक अत्यधिक भरी हुई, बहुआयामी परियोजना को कैसे लिखें? क्या होगा अगर कोई पैसा और समय नहीं है, और आपको खोलने की आवश्यकता है? कटौती के तहत व्यक्तिगत अनुभव से कुछ दिलचस्प जानकारी।



एक ऐसी परियोजना विकसित करने का विचार जो इंटरनेट साइटों को बनाए रखते हुए जीवन को आसान बनाता है, मिन्स्क की एक छोटी कंपनी के साथ आया। हमारी टीम छोटी है, लेकिन महत्वाकांक्षी है, इसलिए इस तरह के बड़े पैमाने के प्रोजेक्ट को एक साथ विकसित करने का निर्णय लिया गया।

चूंकि वेबमास्टर के दिन कठिन और बदसूरत हैं, इसलिए कार्यान्वयन के लिए बहुत अधिक कार्यक्षमता की घोषणा की गई, अर्थात्:

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

सामान्य तौर पर, "डोमिंडर" (अंग्रेजी डोमेन + अनुस्मारक से) लिखना आवश्यक था।
एक उपयोगी, दिलचस्प, आशाजनक परियोजना, लेकिन समस्या पर्याप्त समय और संसाधन नहीं है। दो डेवलपर्स हैं (विकास के शुरू होने के 3 महीने बाद ही दूसरा जुड़ा हुआ)।

हमने पहाड़ी पर एक शांत, आयातित डिजाइन का आदेश दिया। उन्होंने रूबी ऑन रेल्स में लिखने का फैसला किया, PostgreSQL ने मुख्य डेटाबेस के रूप में काम किया।

उन्होंने समझौता और तकनीकी समाधान खोजना शुरू कर दिया, जिसके लिए वर्तमान सामग्री की कमी के साथ कार्यान्वयन को जीवन में लाया जा सकता है।

समाधान नंबर टाइम्स

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

समाधान नंबर दो

क्योंकि यदि कोई समय नहीं है, तो मापदंडों के आधार पर एक या अन्य कार्यान्वयन विधि का चयन किया जाता है:

• समय की लागत;
• scalability;
• (सिस्टम में उपयोगकर्ताओं की वर्तमान संख्या) कार्यान्वयन होना चाहिए।

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

निर्णय संख्या तीन

विकास के समानांतर, उत्पाद को बढ़ावा दिया गया था। यह कैसे हुआ?
2 “नियोजन की धाराएँ” बनाई जा रही हैं: विकास और पीआर। उन्हें समान रूप से परियोजना की वर्तमान आवश्यकताओं और इसके वर्तमान कार्यान्वयन के लिए संभावनाओं के आधार पर भरा जाना चाहिए। उदाहरण के लिए, यदि प्रोजेक्ट का कुछ कार्यात्मक टुकड़ा तैयार है, तो इसे तुरंत परीक्षण किया गया, लुढ़का और लोकप्रिय बनाया गया। या, यदि उपयोगकर्ताओं की वर्तमान संख्या की भविष्यवाणी की तुलना में कम है, तो पहले सुंदर baubles ग्राहकों के लिए विकसित किए गए थे (उदाहरण के लिए, एक डेमो खाता), और वर्तमान एल्गोरिदम का अनुकूलन पहले से ही माध्यमिक था। और इसके विपरीत, अगर ग्राहक थोक में आने लगे, तो वे सब कुछ छोड़ देंगे और गंभीर रूप से कोड शुरू करेंगे। यह एक तरह का स्विंग निकला, लेकिन एक अलग तरीके से, मेरी राय में, किसी भी तरह से नहीं।

समाधान नंबर चार

सभी डोमेन के बारे में जानकारी सार्वजनिक पृष्ठों के माध्यम से उपलब्ध है जो लगातार, निर्दयता से खोज इंजन बोट्स को अनुक्रमित करते हैं। पृष्ठ कैश किए गए थे, और ऐसे डोमेन जो वर्तमान क्लाइंट से संबंधित नहीं थे, उन्हें एक अलग सर्वर (तथाकथित वर्टिकल शार्डिंग) में ले जाया गया।

समाधान नंबर पांच

इस तथ्य के कारण कि पिंग इतिहास को अनिश्चित काल तक संग्रहीत करने की आवश्यकता है - सभी रिकॉर्ड ग्राफ प्रदर्शन एल्गोरिदम के अनुसार "अभिलेखागार" में दबाए जाते हैं।

निर्णय संख्या छह

रजिस्ट्रार से Whois खींचने के लिए अपने स्वयं के मालिकाना प्रॉक्सी सर्वर का उपयोग करना। उनमें से कुछ ने पहली बार बहुत ही लगातार कॉल के कारण आईपी पर प्रतिबंध लगा दिया। परिणामस्वरूप, हम प्रति दिन आधा मिलियन डोमेन के लिए जानकारी प्राप्त करने में कामयाब रहे। सीमा नहीं, लेकिन संशोधन का समय नहीं था।

निर्णय संख्या सात

सब कुछ आप तेजी से की जरूरत है, लगातार NoSql में बेरहमी से धक्का।

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



परीक्षणों के लिए, हमने 140 बेलारूसी साइटों को जोड़ा। परिणामस्वरूप, यह पता चला कि लगभग 40% साइटें सप्ताह में कम से कम एक बार (5 मिनट से कई घंटों तक) सुलभ रहती हैं। और कुछ साइटें केवल बेतहाशा बहती हैं और जाहिर है कि वे अपने ग्राहकों को खो देते हैं।

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

हमारी परियोजना के उद्घाटन के बाद सीमित संसाधन होने के बाद, हमने सभी मोर्चों पर अपने दम पर काम करना शुरू किया: ई-मेल मार्केटिंग, सहबद्ध कार्यक्रम, होस्टिंग कंपनियों और वेब स्टूडियो के रूप में भागीदार, आदि।

नतीजतन, सभी ट्वीक्स और जंप के बाद, हमने खोला और पहला लाभ प्राप्त करना शुरू किया, जबकि प्रत्येक पंजीकृत उपयोगकर्ता से बचकानी खुशी का अनुभव किया।