सेवा-उन्मुख प्रणाली विकसित करने में अनुभव

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

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


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

1. पेज की सामग्री को पुनः प्राप्त करना, एपीआई के माध्यम से विभिन्न सेवाओं का डेटा, संरचित फ़ाइलों से डेटा
2. प्राप्त जानकारी को संरचित करना
3. आँकड़ों का विश्लेषण और सिफारिशों का निर्माण

इस पृथक्करण के परिणाम में तीन स्वतंत्र सेवाएं होनी चाहिए: फ़ॉच सेवा, पार्स सेवा और विश्लेषण सेवा

* इसके बाद मैं धारणा और संक्षिप्तता की अधिक सुविधा के लिए कुछ अंग्रेजी नामों का उपयोग करूंगा

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



इसलिए, हमने मुख्य वास्तुशिल्प मॉडल पर फैसला किया। यह काफी सरल, समझने योग्य और काफी विस्तार योग्य निकला। इसके बाद, मैं वर्णन करूंगा कि प्रत्येक सेवा में क्या शामिल है और क्या उन्हें स्केल किए जाने की अनुमति देता है।

सेवा अवयव और प्रौद्योगिकी

आइए उन तकनीकों के बारे में थोड़ी बात करें जो प्रत्येक व्यक्तिगत सेवा के भीतर उपयोग की जाती हैं। इस लेख में, मैं मुख्य रूप से बताऊंगा कि Fetch Service कैसे काम करती है। हालांकि, अन्य सेवाओं में एक समान वास्तुकला है। नीचे मैं सामान्य बिंदुओं, या बल्कि मुख्य घटकों का वर्णन करूंगा। उनमें से चार हैं।

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

अगला घटक एक परिणाम भंडार है। जो MongoDB में एक डेटाबेस है। अधिकतर डेटा वेब पेजों से, या JSON लौटाने वाले विभिन्न एपीआई के माध्यम से प्राप्त किया जाता है। और इस तरह की जानकारी को संग्रहीत करने के लिए MongoDB काफी सुविधाजनक है। इसके अलावा, परिणामों की संरचना बदल सकती है, नए मीट्रिक आदि दिखाई दे सकते हैं। और इस मामले में, हम दस्तावेजों की संरचना में आसानी से बदलाव कर सकते हैं।

और अंत में, सिस्टम का तीसरा घटक कतार है। दो तरह की कतारें हैं। पूर्व इस तथ्य में लगे हुए हैं कि वे अन्य सेवाओं या बाहरी ग्राहकों से सेवाओं का अनुरोध स्थानांतरित करने के लिए सेवा करते हैं (गियरमैन-क्लाइंट के साथ भ्रमित होने की नहीं)। इन कतारों को अनुरोध पंक्ति के रूप में जाना जाता है। पहले उल्लेखित Fetch Service के मामले में, इस प्रकार की कतार JSON स्ट्रिंग प्राप्त करती है। इसमें तृतीय-पक्ष API का अनुरोध करने के लिए वांछित पृष्ठ या मापदंडों का URL है।

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

संदेश दलाल के रूप में RabbitMQ को चुना गया था। यह एक अच्छा समाधान है, यह ठीक काम करता है, कुछ परेशानियों के साथ। हालांकि, ऐसी प्रणाली के लिए यह बहुत अधिक सुविधा संपन्न है, इसलिए इसे कुछ सरल से बदलना बेहतर हो सकता है।

संचार

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

संचार दो प्रकार के होते हैं। सेवाओं के बीच, सिस्टम के अंदर। और अंत ग्राहक और एक पूरे के रूप में पूरे सिस्टम के बीच।
उदाहरण के लिए, Parse Service को नए डेटा की आवश्यकता होती है। वह फ़िच सर्विस के लिए कतार में अनुरोध भेजता है और फिर अपना काम करता रहता है - अनुरोधों को एसिंक्रोनस रूप से निष्पादित किया जाता है।
Fetch Service को कतार से अनुरोध प्राप्त होने के बाद, वांछित स्रोत (वेब ​​पेज, फ़ाइल, API) से डेटा निकालने और उसे रिपॉजिटरी (MongoDB) में रखने के लिए आवश्यक कदम उठाएंगे। और फिर यह ऑपरेशन के पूरा होने की एक अधिसूचना भेजेगा, जो बदले में नवीनतम डेटा को संसाधित करने के लिए पार्स सेवा प्राप्त करेगा।

सेवा प्राप्त करें

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

1. बाह्य स्रोत से डेटा पुनर्प्राप्त करना
2. इस स्तर पर अपवादों और त्रुटियों को संभालना (जैसे HTTP प्रतिक्रियाओं को संभालना)
3. प्राप्त डेटा (हेडर, फ़ाइल परिवर्तनों पर आंकड़े आदि) के बारे में बुनियादी जानकारी प्रदान करना

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

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

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