सभी सबसे फैशनेबल

नई, सरल, तेज़ और मापनीय तकनीकों के बारे में इंटरनेट पर पढ़ने के बाद, मैं उन सभी को आज़माना चाहता था। अचानक वे मेरे लिए पहले से परिचित postgresql + django + json-rpc बंडल से बेहतर होंगे।

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

चूंकि कोई विचार नहीं था, लेकिन एक मुफ्त डोमेन uglyrater.org था - मुझे एक रेटिंग बनानी थी।
नीचे की रेखा सरल है: उपयोगकर्ताओं की एक सूची है, जिनके लिए आप + और - को व्यवस्थित कर सकते हैं। नए उपयोगकर्ताओं को वीके पृष्ठ पते पर रेटिंग में जोड़ा जाता है।


चेतावनी! लेख में व्यक्तिगत अनुभव के आधार पर बहुत अधिक व्यक्तिपरक आकलन है!

कार्यान्वयन

वास्तुकला को जानबूझकर जटिल होना पड़ा, अन्यथा सब कुछ दिलचस्प होने की कोशिश नहीं की जा सकती थी। साथ ही, vk api के माध्यम से उपयोगकर्ता डेटा प्राप्त करने का संचालन काफी लंबा है, और इसे समानांतर करने का विचार इतना बुरा नहीं है। ऐसा करने के लिए, आपको MQ की आवश्यकता है, विकल्प RabbitMQ पर गिर गया। आप कह सकते हैं कि AMQP "बेकार है", “ MQ "हमारा सब कुछ", लेकिन zeromq के साथ मैं पहले से ही काम कर चुका हूं, और मुझे इस संदर्भ में कोई दिलचस्पी नहीं है।
RabbitMQ का उपयोग पिका के माध्यम से किया गया था। संदेशों को आरंभ करने और भेजने / प्राप्त करने के लिए, न्यूनतम कोड की आवश्यकता थी, आप इसे "कार्यकर्ता" और इसके परीक्षणों में देख सकते हैं। लिखने के बाद, इस या इसी तरह के कार्य को पूरा करने के लिए पहले से ही इस्तेमाल किए गए ज़ेरोकिस और toMQ के साथ एक छोटी सी तुलना दिखाई दी:

	RabbitMQ	ØMQ	ZerocIce
आकर्षण आते हैं	कोड की एक छोटी राशि; काम की सादगी;	गति; देशी वस्तुओं को भेजना; अपने स्वयं के दानव की आवश्यकता नहीं है;	दूरस्थ कार्यों और वस्तुओं के साथ काम करने की क्षमता; प्रति सॉकेट की कमी; संकेत / स्लॉट;
विपक्ष	डेमॉन लॉन्च की आवश्यकता;	राउटर लिखना आवश्यक है; बहुत सारे कोड;	लेखन की आवश्यकता स्लाइस; डेमन लॉन्च आवश्यक (आइसबॉक्स); जटिलता;

और ऐसा हुआ कि वर्तमान कार्य के लिए, RabbitMQ और fitMQ समान रूप से अच्छी तरह से फिट हैं, और ZerocIce गौरैया पर एक तोप की तरह है।

अब प्राप्त और संसाधित डेटा को कहीं संग्रहीत करने की आवश्यकता है। अब नोसकल फैशनेबल है, इसलिए मोंगोडब को चुना गया था। इस कार्य के लिए orm के साथ postgresql के लिए कोई अंतर नहीं है, सब कुछ स्मार्ट और सुविधाजनक है।

वेब सर्वर कतार आ गई है। अब अतुल्यकालिक और पुश के लिए सर्वर सर्वर से क्लाइंट तक चला गया है, इसलिए बवंडर और टॉर्नाडिओ 2 को चुना गया , खासकर जब से उन्होंने हाल ही में हब पर इसके बारे में लिखा था फिर एक समस्या तुरंत निकल गई, tornadio2 से कुकीज़ प्राप्त करना संभव नहीं था। इसलिए, मुझे सॉकेटियो के माध्यम से क्लाइंट से "गुप्त" आईडी के साथ आईडी भेजने से बैसाखी को रोकना पड़ा, जिसने कार्यान्वयन को थोड़ा जटिल कर दिया। इस सब के बाद, मुझे django + json-rpc के साथ एक छोटी सी तुलना मिली:

	बवंडर + बवंडर	django + json-rpc
आकर्षण आते हैं	सर्वर से धक्का; हल्कापन; गति;	सादगी; मानकीकृत प्रोटोकॉल;
विपक्ष	जटिलता; कुकीज़ के साथ "वक्र" काम;	कुरूपता; धक्का सिमुलेशन के लिए आवधिक अनुरोध;

यहां सब कुछ अस्पष्ट है, लेकिन धक्का की वजह से, बवंडर विकल्प अभी भी बेहतर है।

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

तैनाती

लंबे समय तक सोचने के बिना, मैंने मानक योजना का उपयोग करके सर्वर पर सब कुछ nginx के माध्यम से तैनात करने का निर्णय लिया:



लेकिन वहाँ यह था। यह पता चला कि नगीनक्स वेब सॉकेट्स का समर्थन नहीं करता है और समस्या के 3 समाधान थे:

1. अस्थिर nginx स्थापित करें।
   उबंटू के लिए पीपा है, मैंने इसे इसमें से स्थापित किया, लेकिन http प्राधिकरण बंद हो गया, यह काम नहीं किया। और चूंकि सर्वर में ऐसे प्राधिकरण के साथ एक व्यापारिक भंडार भी है, इसलिए विकल्प जल्दी से गायब हो गया।
2. Tcp प्रॉक्सी के साथ nginx बनाएँ।
   एक सरल निर्देश पाकर , सब कुछ इकट्ठा हो गया। सभी पुराने प्रोजेक्ट शुरू हो गए हैं। लेकिन यहां, या तो मैंने कहीं गलती की, या कुछ और, लेकिन वेबसोकेट ने ठीक से काम नहीं किया। विकल्प गायब हो जाता है।
3. HAProxy का उपयोग करें।
   यहां हमें एक ओवरहेड के साथ एक योजना मिलती है जो तस्वीर के साथ दिखाना आसान है:
   
   
   
   उसके साथ, सब कुछ शुरू हुआ और अच्छी तरह से काम किया।

परिणाम

यह, ज़ाहिर है, शांत, सुविधाजनक और तेज़ है, लेकिन अभी भी कई थानेदार हैं। एक तैनाती के साथ मुख्य जाम, लेकिन अंतिम समाधान इतना बुरा नहीं है।

कोड के साथ github
उपेक्षित रूप में।