डोमेन के लिए Yandex.Mail कैसे काम करता है

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

जैसा कि समय ने दिखाया है, हम गलत नहीं थे, और आज यैंडेक्स डोमेन के लिए मेल रनेट में सबसे लोकप्रिय मेल सेवा है। कुल मिलाकर, 200 हजार से अधिक डोमेन नाम और लगभग 3.5M मेलबॉक्स ट्रैफिक नियमों से जुड़े हैं। हर दिन लगभग 200 डोमेन ट्रैफिक नियमों से जुड़े होते हैं। इस लेख में हम आपको बताएंगे कि ट्रैफ़िक नियम कैसे काम करते हैं, और टिप्पणियों में हम ख़ुशी से आपके सवालों का जवाब देंगे।



अपने अस्तित्व के दौरान, एसडीए ने कई अतिरिक्त विशेषताएं प्राप्त की हैं: पता पुस्तिका, जैबर सर्वर समर्थन, मेलिंग सूचियों के साथ एकीकरण, उपयोगकर्ता के पिछले सर्वर से मेल का आयात, और, ज़ाहिर है, स्वचालित अनुरोधों के लिए एक बाहरी एपीआई। उदाहरण के लिए, हमें यह सुनिश्चित करने के लिए एक लंबे समय के लिए कहा गया था कि उस पर अधिकृत एक तृतीय-पक्ष साइट का उपयोगकर्ता तुरंत अपने मेलबॉक्स में गिर गया - बिना डोमेन के फिर से प्राधिकरण Yandex.Mail में। और हमारे एपीआई ने हमें पासवर्ड रहित प्राधिकरण की इस पद्धति को लागू करने की अनुमति दी।

ट्रैफ़िक नियमों की पेशकश करने वाले सभी अवसरों को यैंडेक्स उत्पादों के विभिन्न घटकों और अधिक के साथ एकीकरण की आवश्यकता होती है। इसके मूल में, ट्रैफ़िक नियम एक एकीकरण सेवा है जो एक डोमेन व्यवस्थापक के नियंत्रण में असमान घटकों को एक साथ लाता है।

एसडीए एक डोमेन से शुरू होता है: आपको इसे कनेक्ट करने और यह सत्यापित करने की आवश्यकता है कि डोमेन का मालिक और एसडीए प्रशासक एक ही व्यक्ति हैं। ऐसा होता है कि डीएनएस स्तर पर एक कारण या किसी अन्य के लिए डोमेन को डिस्कनेक्ट कर दिया जाता है। स्वामित्व की पुष्टि करने के लिए और एक डोमेन की स्थिति की पुष्टि करने के लिए, हम एक रिलेशनल DBMS और MongoDB पर आधारित एक वितरित लॉक क्लस्टर में कई चेक कतार रिपॉजिटरी सर्वर से युक्त चेक कतार प्रणाली का उपयोग करते हैं।

डोमेन साइट्स या ज़ोन के DNS सर्वरों को होस्ट करने वाले सर्वर को ओवरलोड नहीं करने के लिए, प्रत्येक बाद की सत्यापन जांच एक बढ़ते समय अंतराल के साथ होती है - पांच मिनट से 24 घंटे तक। डोमेन स्थिति की जांच अधिक बार होती है - लगभग हर चार घंटे में लगातार समय अंतराल के साथ। यह दृष्टिकोण चेक के काम की कतारों पर बोझ को काफी कम कर सकता है। जैसे ही डोमेन की पुष्टि हो जाती है, सभी बुनियादी कार्य इसके व्यवस्थापक के लिए उपलब्ध हो जाते हैं और वह मेलबॉक्स बना सकता है।

एक सार्वभौमिक दृष्टिकोण बनाए रखने और त्रुटियों की संख्या को कम करने के लिए, हमने डोमेन के लिए एक आंतरिक मेल एपीआई विकसित किया है, जिसका उपयोग अन्य यैंडेक्स घटकों द्वारा आवश्यक जानकारी का आदान-प्रदान करने के लिए किया जा सकता है। उदाहरण के लिए, सार्वजनिक डोमेन ईमेल एपीआई एक ऐसा घटक है। सार्वजनिक एपीआई कॉल सार्वभौमिक आंतरिक एपीआई कॉल में अनुवाद करती है। एसडीए वेब इंटरफेस में कोई भी कार्रवाई आंतरिक एपीआई तरीकों को भी बुलाती है।

आवश्यक क्रियाओं के आधार पर, आंतरिक एपीआई कॉल हैंडलर कुछ यैंडेक्स घटकों तक पहुंच सकता है। नई कार्यक्षमता डिज़ाइन करते समय मूल सिद्धांत एसडीए पक्ष की जानकारी को संग्रहीत करने के लिए नहीं है जो पहले से ही कहीं और संग्रहीत है। अपवाद केवल उन अनुरोधों के लिए किया जाता है जो निष्पादन समय के लिए महत्वपूर्ण हैं - उन्हें कैश करना होगा।



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

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

इस तरह के एकीकरण के साथ, सेवाओं की प्रतिक्रिया समय और होने वाली संभावित त्रुटियों से निपटने का बहुत महत्व है। मुख्य रूप से दो प्रकार की त्रुटियां हैं: नेटवर्क और तार्किक। पूर्णता के लिए, आइए सेवाओं की सूची और उनके साथ यातायात नियमों के एकीकरण की विशेषताओं को देखें।

पासपोर्ट

वास्तव में, यह यातायात नियमों के लिए मुख्य डेटा स्रोत है, डेटाबेस से कम महत्वपूर्ण नहीं है, और कभी-कभी इससे भी अधिक। पासपोर्ट के साथ एसडीए HTTP के माध्यम से आंतरिक एपीआई के माध्यम से संचार करता है। पासपोर्ट की कोई भी त्रुटि गंभीर है। यदि पासपोर्ट में कोई त्रुटि है या पासपोर्ट के साथ संचार करने में कोई विफलता थी, तो हमने उपयोगकर्ता को त्रुटि प्रसारित की और डेटाबेस या अन्य सेवाओं में पहले से ही निष्पादित कार्यों को रद्द कर दिया। इस प्रकार, विभिन्न एकीकृत सेवाओं के बीच लेनदेन संचालन का समर्थन किया जाता है: प्रत्येक कमांड के लिए इसका एंटीपोड है - ऑपरेशन को रद्द करने का आदेश।

मेल

यह एक महत्वपूर्ण सेवा है जो एक डोमेन व्यवस्थापक ट्रैफ़िक नियमों के माध्यम से प्रबंधित करता है। मेलबॉक्स बनाने के लिए बहुत अधिक संगणना की आवश्यकता होती है, इसलिए यह पृष्ठभूमि में होता है। पंजीकरण पूरा करने के लिए परमाणु संचालन की एक कतार की आवश्यकता होती है: एक बॉक्स खोलें, डोमेन के लिए मूल सेटिंग्स लागू करें, आदि। इस मामले में नेटवर्क त्रुटियां इतनी महत्वपूर्ण नहीं हैं, इसलिए, समस्याओं के मामले में, ऑपरेशन को शांतिपूर्वक बाद में स्थगित कर दिया जाता है, एक और वितरित कतार में, इस कतार के प्रोसेसर विफलता के बाद एक दिन के भीतर बॉक्स को फिर से कॉन्फ़िगर करने का प्रयास करते हैं।

डीएनएस

लगभग तीन यातायात नियमों में से एक डोमेन यैंडेक्स सर्वर पर DNS ज़ोन की मेजबानी करता है। DNS बैकएंड के साथ त्रुटियों को केवल नेटवर्क विफलताओं और डेटाबेस में लिखने की पूर्ण अक्षमता के मामले में महत्वपूर्ण माना जाता है। अन्य सभी मामलों में, एल्गोरिदम चालू हो जाते हैं जो उपयोगकर्ता की समस्या को हल करते हैं।

उदाहरण के लिए, डोमेन डेलिगेशन के समय, यांडेक्स पिछले DNS सर्वर से रिकॉर्ड का हिस्सा कॉपी करता है ताकि उपयोगकर्ता को ज़ोन को स्थानांतरित करने का थकाऊ काम न करना पड़े। इस स्थिति में, एक स्थिति उत्पन्न हो सकती है जब रूट डोमेन रिकॉर्ड CNAME प्रकार का होता है, जो मानक के विपरीत होता है। ऐसे CNAME रिकॉर्ड वाला उपयोगकर्ता अपने डोमेन पर Yandex.Mail को सक्षम नहीं कर सकता है, इसलिए आयात करते समय, ऐसे रिकॉर्ड को छोड़ दिया जाएगा।

लॉगिंग और लॉगिंग

किसी भी बड़े खेत की तरह, कहीं भी कोई प्रोटोकॉल नहीं हैं। एसडीए अन्य यैंडेक्स घटकों के साथ सभी इंटरैक्शन के लिए विस्तृत लॉग रखता है। उपयोगकर्ताओं को ध्यान देने योग्य बनने से पहले अक्सर ये लॉग समस्या को खोजने का प्रबंधन करते हैं। यह सुनिश्चित करने के लिए कि सेवा जल्दी और कुशलता से काम करती है, यह सिस्टम लॉग की निगरानी के लिए विशेष सॉफ्टवेयर की निगरानी करती है। बड़ी दुर्घटनाओं या त्रुटियों के मामले में, जब अनुरोधों के लिए प्रसंस्करण का समय काफी बढ़ जाता है या प्रतिक्रियाओं में त्रुटियां दिखाई देती हैं, तो सिस्टम प्रशासक कुछ मिनटों के भीतर इसे नोटिस करते हैं और दिन या रात के किसी भी समय इसे ठीक करना शुरू करते हैं। लेकिन अगली बार के बारे में और अधिक।

आपके प्रश्नों की प्रतीक्षा है!