हमने कुबेरनेट्स के अंदर क्लाउड FaaS कैसे बनाया और टिंकॉफ हैकथॉन जीता

पिछले साल से, हमारी कंपनी ने हैकथॉन का आयोजन शुरू किया। इस तरह की पहली प्रतियोगिता बहुत सफल रही, हमने इसके बारे में लिखा था लेख. दूसरा हैकथॉन फरवरी 2019 में हुआ और कम सफल नहीं रहा। उत्तरार्द्ध को पकड़ने के लक्ष्यों के बारे में बहुत पहले नहीं मैंने लिखा था व्यवस्था करनेवाला।

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

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

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

स्कोरिंग क्या है

कई आधुनिक कंपनियों की तरह, Tinkoff.ru के पास ग्राहक स्कोरिंग है। स्कोरिंग डेटा विश्लेषण के सांख्यिकीय तरीकों पर आधारित एक ग्राहक मूल्यांकन प्रणाली है।

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

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

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

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

मौजूदा कार्य के लिए, हम पहले से ही एक विशेष निर्णय लेने वाली प्रणाली का उपयोग करते हैं आईबीएम वेबस्फीयर आईएलओजी जेरूल्स बीआरएमएस, जो विश्लेषकों, प्रौद्योगिकीविदों और डेवलपर्स द्वारा निर्धारित नियमों के आधार पर, ग्राहक को किसी विशेष बैंकिंग उत्पाद को मंजूरी देने या अस्वीकार करने का निर्णय लेता है।

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

काम

हैकथॉन 23 फरवरी को आयोजित किया गया था। प्रतिभागियों को एक लड़ाकू कार्य की पेशकश की गई थी: एक निर्णय लेने की प्रणाली विकसित करना जिसे कई शर्तों को पूरा करना था।

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

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

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

हमारा समाधान

थोड़े विचार-मंथन के बाद, हमने निर्णय लिया कि कार्य को पूरा करने के लिए FaaS समाधान आदर्श होगा।

इस समाधान के लिए, विकसित की जा रही निर्णय लेने की प्रणाली के नियमों को लागू करने के लिए एक उपयुक्त सर्वर रहित ढांचा खोजना आवश्यक था। चूंकि टिंकॉफ सक्रिय रूप से बुनियादी ढांचे के प्रबंधन के लिए कुबेरनेट्स का उपयोग करता है, इसलिए हमने इसके आधार पर कई तैयार समाधानों को देखा; मैं आपको इसके बारे में बाद में और बताऊंगा।

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

1. विश्लेषक गोदाम से प्राप्त डेटा के आधार पर एक स्क्रिप्ट, नियम या एमएल मॉडल लिखता है। हैकथॉन के भाग के रूप में, हमने मोंगोडब का उपयोग करने का निर्णय लिया, लेकिन डेटा भंडारण प्रणाली का चुनाव यहां महत्वपूर्ण नहीं है।
2. ऐतिहासिक डेटा पर विकसित नियमों का परीक्षण करने के बाद, विश्लेषक अपना कोड व्यवस्थापक पैनल पर अपलोड करता है।
3. वर्जनिंग सुनिश्चित करने के लिए, सभी कोड Git रिपॉजिटरी में जाएंगे।
4. व्यवस्थापक पैनल के माध्यम से कोड को एक अलग कार्यात्मक सर्वर रहित मॉड्यूल के रूप में क्लाउड में तैनात करना संभव होगा।

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

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

सभी फायदे और नुकसान पर विचार करने के बाद, हमने चुना विखंडन. इस सर्वर रहित ढांचे को प्रबंधित करना काफी आसान है और कार्य की आवश्यकताओं को पूरा करता है।

विखंडन के साथ काम करने के लिए, आपको दो बुनियादी अवधारणाओं को समझने की आवश्यकता है: कार्य और पर्यावरण। एक फ़ंक्शन उन भाषाओं में से एक में लिखा गया कोड का एक टुकड़ा है जिसके लिए एक विखंडन वातावरण है। इस ढाँचे के अंतर्गत कार्यान्वित परिवेशों की सूची इसमें Python, JS, Go, JVM और कई अन्य लोकप्रिय भाषाएँ और प्रौद्योगिकियाँ शामिल हैं।

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

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

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

हमें क्या मिला

चूँकि हम हैकथॉन में एक तैयार समाधान (अपनी कल्पनाओं में) के साथ आए थे, हमें बस अपने सभी विचारों को कोड की पंक्तियों में बदलना था।

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

हमारे प्रोजेक्ट की वास्तुकला इस प्रकार थी:

यह आरेख दो प्रवेश बिंदु दिखाता है, विश्लेषक (हमारे सिस्टम का मुख्य उपयोगकर्ता) और ग्राहक।

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

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

JSON दस्तावेज़ों के रूप में डेटा के दस्तावेज़-उन्मुख भंडारण के कारण हमने अपने सिस्टम में भंडारण के रूप में MongoDB का उपयोग करने का निर्णय लिया, क्योंकि मूल अनुरोध सहित संवर्धन सेवाओं ने REST नियंत्रकों के माध्यम से सभी डेटा एकत्र किया था।

इसलिए, हमारे पास प्लेटफ़ॉर्म को लागू करने के लिए XNUMX घंटे थे। हमने भूमिकाओं को काफी सफलतापूर्वक वितरित किया; हमारे प्रोजेक्ट में टीम के प्रत्येक सदस्य की जिम्मेदारी का अपना क्षेत्र था:

1. विश्लेषक के काम के लिए फ्रंट-एंड एडमिन पैनल, जिसके माध्यम से वह लिखित स्क्रिप्ट के संस्करण नियंत्रण प्रणाली से नियम डाउनलोड कर सकता है, इनपुट डेटा को समृद्ध करने के लिए विकल्पों का चयन कर सकता है और नियम स्क्रिप्ट को ऑनलाइन संपादित कर सकता है।
2. बैकएंड एडमिन, जिसमें फ्रंट के लिए REST API और VCS के साथ एकीकरण शामिल है।
3. Google क्लाउड में बुनियादी ढाँचा स्थापित करना और स्रोत डेटा को समृद्ध करने के लिए एक सेवा विकसित करना।
4. नियमों की बाद की तैनाती के लिए सर्वर रहित ढांचे के साथ व्यवस्थापक एप्लिकेशन को एकीकृत करने के लिए एक मॉड्यूल।
5. पूरे सिस्टम के प्रदर्शन के परीक्षण के लिए नियमों की स्क्रिप्ट और अंतिम प्रदर्शन के लिए आने वाले अनुप्रयोगों (निर्णयों) पर विश्लेषण का एकत्रीकरण।

चलो शुरू से शुरू करते हैं।

हमारा फ्रंटएंड बैंकिंग यूआई किट का उपयोग करके एंगुलर 7 में लिखा गया था। व्यवस्थापक पैनल का अंतिम संस्करण इस तरह दिखता था:

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

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

नियम कार्यों के अलावा, हमने संवर्धन कार्यों का उपयोग करके स्रोत डेटा को धीरे-धीरे समृद्ध करने की क्षमता भी लागू की, जिसका कोड भी स्क्रिप्ट था जिसमें डेटा वेयरहाउस में जाना, तृतीय-पक्ष सेवाओं को कॉल करना और प्रारंभिक गणना करना संभव था . अपना समाधान प्रदर्शित करने के लिए, हमने अनुरोध छोड़ने वाले ग्राहक की राशि की गणना की और तृतीय-पक्ष REST सेवा का उपयोग करके उसके मोबाइल ऑपरेटर का निर्धारण किया।

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

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

विखंडन के साथ काम करने के लिए, हमने विखंडन सीएलआई का उपयोग किया, जिसे कुबेरनेट्स सीएलआई के शीर्ष पर स्थापित किया जाना चाहिए। K8s क्लस्टर में फ़ंक्शंस को तैनात करना काफी सरल है; यदि क्लस्टर के बाहर पहुंच की आवश्यकता है तो आने वाले ट्रैफ़िक को अनुमति देने के लिए आपको बस एक आंतरिक मार्ग निर्दिष्ट करने और फ़ंक्शन में प्रवेश करने की आवश्यकता है। एक फ़ंक्शन को तैनात करने में आमतौर पर 10 सेकंड से अधिक समय नहीं लगता है।

परियोजना की अंतिम प्रस्तुति और सारांश

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

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

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

कुल 3 काल्पनिक बैंक उत्पाद उपलब्ध थे:

• क्रेडिट।
• खिलौना
• बंधक।

प्रदर्शन के दौरान, हमने प्रत्येक सेवा के लिए तैयार किए गए फ़ंक्शन और संवर्धन स्क्रिप्ट को तैनात किया।

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

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

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

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

स्रोत: www.habr.com