आम्ही Kubernetes मध्ये क्लाउड FaaS कसे बनवले आणि टिंकॉफ हॅकाथॉन जिंकले

गेल्या वर्षीपासून, आमच्या कंपनीने हॅकाथॉन आयोजित करण्यास सुरुवात केली. अशी पहिली स्पर्धा खूप यशस्वी होती, आम्ही त्याबद्दल लिहिले लेख. दुसरी हॅकाथॉन फेब्रुवारी 2019 मध्ये झाली आणि ती कमी यशस्वी झाली नाही. नंतरचे धारण करण्याच्या उद्दिष्टांबद्दल फार पूर्वी नाही लिहिले आयोजक

सहभागींना त्याच्या अंमलबजावणीसाठी तंत्रज्ञान स्टॅक निवडण्यात पूर्ण स्वातंत्र्यासह एक मनोरंजक कार्य देण्यात आले. ग्राहक स्कोअरिंग फंक्शन्सच्या सोयीस्कर उपयोजनासाठी निर्णय घेण्याच्या प्लॅटफॉर्मची अंमलबजावणी करणे आवश्यक होते जे अनुप्रयोगांच्या जलद प्रवाहासह कार्य करू शकतील, जड भार सहन करू शकतील आणि सिस्टम स्वतः सहज स्केलेबल असेल.

हे कार्य क्षुल्लक नाही आणि अनेक मार्गांनी सोडवले जाऊ शकते, जसे की आम्हाला सहभागींच्या प्रकल्पांच्या अंतिम सादरीकरणाच्या प्रात्यक्षिकाच्या वेळी खात्री होती. हॅकाथॉनमध्ये 6 लोकांचे 5 संघ होते, सर्व सहभागींचे चांगले प्रकल्प होते, परंतु आमचे व्यासपीठ सर्वात स्पर्धात्मक ठरले. आमच्याकडे एक अतिशय मनोरंजक प्रकल्प आहे, ज्याबद्दल मी या लेखात बोलू इच्छितो.

आमचे समाधान हे Kubernetes मधील सर्व्हरलेस आर्किटेक्चरवर आधारित एक प्लॅटफॉर्म आहे, जे उत्पादनात नवीन वैशिष्ट्ये आणण्यासाठी लागणारा वेळ कमी करते. हे विश्लेषकांना त्यांच्यासाठी सोयीस्कर वातावरणात कोड लिहिण्याची आणि अभियंते आणि विकासकांच्या सहभागाशिवाय उत्पादनात उपयोजित करण्यास अनुमती देते.

स्कोअरिंग म्हणजे काय

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

उदाहरणार्थ, एखादा क्लायंट त्याला कर्ज देण्याच्या विनंतीसह आमच्याकडे वळतो किंवा आमच्याकडे वैयक्तिक उद्योजक खाते उघडतो. जर आम्ही त्याला कर्ज देण्याची योजना आखत असाल, तर आम्हाला त्याच्या सॉल्व्हेंसीचे मूल्यांकन करणे आवश्यक आहे आणि खाते वैयक्तिक उद्योजक असल्यास, ग्राहक फसवे व्यवहार करणार नाही याची आम्हाला खात्री असणे आवश्यक आहे.

असे निर्णय घेण्याचा आधार म्हणजे गणितीय मॉडेल्स जे ऍप्लिकेशनमधील डेटा आणि आमच्या स्टोरेजमधील डेटा दोन्हीचे विश्लेषण करतात. स्कोअरिंग व्यतिरिक्त, समान सांख्यिकीय पद्धती आमच्या ग्राहकांसाठी नवीन उत्पादनांसाठी वैयक्तिक शिफारसी तयार करण्याच्या सेवेमध्ये देखील वापरल्या जाऊ शकतात.

अशा मूल्यांकनाची पद्धत विविध इनपुट डेटा स्वीकारू शकते. आणि काही क्षणी आम्ही इनपुटमध्ये एक नवीन पॅरामीटर जोडू शकतो, जे ऐतिहासिक डेटावरील विश्लेषणाच्या परिणामांवर आधारित, सेवा वापरण्याचा रूपांतरण दर वाढवेल.

आमच्याकडे ग्राहक संबंधांबद्दल भरपूर डेटा आहे आणि या माहितीचे प्रमाण सतत वाढत आहे. कार्य करण्यासाठी स्कोअरिंगसाठी, डेटा प्रोसेसिंगला नियम (किंवा गणितीय मॉडेल्स) देखील आवश्यक असतात जे तुम्हाला कोणाला अर्ज मंजूर करायचा, कोणाला नकार द्यायचा आणि कोणाला आणखी काही उत्पादने ऑफर करायची हे त्यांच्या संभाव्य स्वारस्याचे मूल्यांकन करून त्वरीत ठरवू देते.

हातातील कामासाठी, आम्ही आधीच एक विशेष निर्णय प्रणाली वापरतो IBM WebSphere ILOG JRules BRMS, जे, विश्लेषक, तंत्रज्ञ आणि विकासकांनी सेट केलेल्या नियमांच्या आधारे, क्लायंटला विशिष्ट बँकिंग उत्पादन मंजूर करायचे की नाकारायचे हे ठरवते.

बाजारात अनेक तयार-तयार उपाय आहेत, दोन्ही स्कोअरिंग मॉडेल्स आणि स्वतः निर्णय घेण्याची प्रणाली. आम्ही आमच्या कंपनीमध्ये यापैकी एक प्रणाली वापरतो. परंतु व्यवसाय वाढत आहे, वैविध्यपूर्ण होत आहे, ग्राहकांची संख्या आणि ऑफर केलेल्या उत्पादनांची संख्या दोन्ही वाढत आहे आणि यासह, विद्यमान निर्णय प्रक्रियेत सुधारणा कशी करता येईल यावर कल्पना उदयास येत आहेत. निश्चितपणे विद्यमान प्रणालीसह काम करणार्या लोकांकडे ते सोपे, चांगले, अधिक सोयीस्कर कसे बनवायचे याबद्दल अनेक कल्पना आहेत, परंतु काहीवेळा बाहेरून आलेल्या कल्पना उपयुक्त ठरतात. ध्वनी कल्पना एकत्रित करण्याच्या उद्देशाने न्यू हॅकाथॉनचे आयोजन करण्यात आले होते.

कार्य

23 फेब्रुवारी रोजी हॅकाथॉनचे आयोजन करण्यात आले होते. सहभागींना एक लढाऊ कार्य ऑफर करण्यात आले: निर्णय घेण्याची प्रणाली विकसित करण्यासाठी ज्याला अनेक अटी पूर्ण कराव्या लागल्या.

विद्यमान प्रणाली कशी कार्य करते आणि त्याच्या कार्यादरम्यान कोणत्या अडचणी येतात, तसेच विकसित प्लॅटफॉर्मने कोणती व्यावसायिक उद्दिष्टे पूर्ण केली पाहिजेत हे आम्हाला सांगण्यात आले. नियम विकसित करण्यासाठी सिस्टममध्ये वेगवान वेळ-मार्केट असणे आवश्यक आहे जेणेकरून विश्लेषकांचे कार्य कोड शक्य तितक्या लवकर उत्पादनात येऊ शकेल. आणि अर्जांच्या येणार्‍या प्रवाहासाठी, निर्णय घेण्याची वेळ कमीत कमी असणे आवश्यक आहे. तसेच, विकसित होत असलेल्या सिस्टीममध्ये क्रॉस-सेल क्षमता असणे आवश्यक आहे जेणेकरुन क्लायंटला इतर कंपनीची उत्पादने आमच्याद्वारे मंजूर झाल्यास आणि ग्राहकाकडून संभाव्य स्वारस्य असल्यास ते खरेदी करण्याची संधी द्या.

हे स्पष्ट आहे की एका रात्रीत रिलीज-टू-रिलीझ प्रकल्प लिहिणे अशक्य आहे जे नक्कीच उत्पादनात जाईल आणि संपूर्ण सिस्टम कव्हर करणे खूप कठीण आहे, म्हणून आम्हाला त्याचा किमान काही भाग लागू करण्यास सांगितले गेले. अनेक आवश्यकता स्थापित केल्या गेल्या ज्या प्रोटोटाइपने पूर्ण केल्या पाहिजेत. सर्व गरजा पूर्ण करण्यासाठी आणि विकसित होत असलेल्या प्लॅटफॉर्मच्या वैयक्तिक विभागांवर तपशीलवार काम करण्यासाठी दोन्ही प्रयत्न करणे शक्य होते.

तंत्रज्ञानासाठी, सर्व सहभागींना निवडीचे पूर्ण स्वातंत्र्य दिले गेले. कोणत्याही संकल्पना आणि तंत्रज्ञानाचा वापर करणे शक्य होते: डेटा स्ट्रीमिंग, मशीन लर्निंग, इव्हेंट सोर्सिंग, मोठा डेटा आणि इतर.

आमचे समाधान

थोडे विचारमंथन केल्यानंतर, आम्ही निर्णय घेतला की कार्य पूर्ण करण्यासाठी एक FaaS उपाय आदर्श असेल.

या उपायासाठी, विकसित होत असलेल्या निर्णयप्रणालीच्या नियमांची अंमलबजावणी करण्यासाठी योग्य सर्व्हरलेस फ्रेमवर्क शोधणे आवश्यक होते. Tinkoff सक्रियपणे पायाभूत सुविधा व्यवस्थापनासाठी Kubernetes वापरत असल्याने, आम्ही त्यावर आधारित अनेक तयार-तयार उपाय पाहिले; मी तुम्हाला त्याबद्दल नंतर अधिक सांगेन.

सर्वात प्रभावी उपाय शोधण्यासाठी, आम्ही त्याच्या वापरकर्त्यांच्या नजरेतून विकसित केलेल्या उत्पादनाकडे पाहिले. आमच्या सिस्टमचे मुख्य वापरकर्ते नियम विकासामध्ये गुंतलेले विश्लेषक आहेत. नियम सर्व्हरवर उपयोजित केले जाणे आवश्यक आहे, किंवा, आमच्या बाबतीत, क्लाउडमध्ये उपयोजित, त्यानंतरच्या निर्णयासाठी. विश्लेषकाच्या दृष्टीकोनातून, वर्कफ्लो असे दिसते:

1. विश्लेषक वेअरहाऊसमधील डेटावर आधारित स्क्रिप्ट, नियम किंवा ML मॉडेल लिहितो. हॅकाथॉनचा ​​भाग म्हणून, आम्ही मोंगोडबी वापरण्याचा निर्णय घेतला, परंतु डेटा स्टोरेज सिस्टमची निवड येथे महत्त्वाची नाही.
2. ऐतिहासिक डेटावर विकसित नियमांची चाचणी घेतल्यानंतर, विश्लेषक त्याचा कोड प्रशासक पॅनेलवर अपलोड करतो.
3. आवृत्ती सुनिश्चित करण्यासाठी, सर्व कोड Git रेपॉजिटरीजमध्ये जाईल.
4. ऍडमिन पॅनेलद्वारे क्लाउडमध्ये स्वतंत्र कार्यात्मक सर्व्हरलेस मॉड्यूल म्हणून कोड तैनात करणे शक्य होईल.

क्लायंटचा प्रारंभिक डेटा वेअरहाऊसमधील डेटासह प्रारंभिक विनंती समृद्ध करण्यासाठी डिझाइन केलेल्या विशेष समृद्धी सेवेमधून जाणे आवश्यक आहे. ही सेवा अशा प्रकारे कार्यान्वित करणे महत्त्वाचे होते की ती एका रेपॉजिटरीसह कार्य करेल (ज्यामधून विश्लेषक नियम विकसित करताना डेटा घेतो) एक एकीकृत डेटा संरचना राखण्यासाठी.

हॅकाथॉनच्या आधीही, आम्ही सर्व्हरलेस फ्रेमवर्कचा निर्णय घेतला जो आम्ही वापरू. आज बाजारात बरीच तंत्रज्ञाने आहेत जी हा दृष्टिकोन अंमलात आणतात. कुबर्नेट्स आर्किटेक्चरमधील सर्वात लोकप्रिय उपाय म्हणजे फिशन, ओपन फाएएस आणि कुबेलेस. सम आहेत त्यांच्या वर्णनासह आणि तुलनात्मक विश्लेषणासह चांगला लेख.

सर्व साधक आणि बाधक वजन केल्यानंतर, आम्ही निवडले विखंडन. हे सर्व्हरलेस फ्रेमवर्क व्यवस्थापित करणे सोपे आहे आणि कार्याच्या आवश्यकता पूर्ण करते.

फिशनसह कार्य करण्यासाठी, तुम्हाला दोन मूलभूत संकल्पना समजून घेणे आवश्यक आहे: कार्य आणि पर्यावरण. फंक्शन हा एका भाषेत लिहिलेला कोडचा तुकडा आहे ज्यासाठी फिशन वातावरण आहे. या फ्रेमवर्कमध्ये लागू केलेल्या वातावरणाची यादी पायथन, जेएस, गो, जेव्हीएम आणि इतर अनेक लोकप्रिय भाषा आणि तंत्रज्ञानाचा समावेश आहे.

विखंडन अनेक फायलींमध्ये विभागलेले कार्य करण्यास सक्षम आहे, संग्रहणात प्री-पॅक केलेले आहे. कुबर्नेट्स क्लस्टरमध्ये फिशनचे ऑपरेशन विशिष्ट पॉड्सद्वारे सुनिश्चित केले जाते, जे फ्रेमवर्कद्वारेच व्यवस्थापित केले जाते. क्लस्टर पॉड्सशी संवाद साधण्यासाठी, प्रत्येक फंक्शनला स्वतःचा मार्ग नियुक्त करणे आवश्यक आहे आणि ज्यावर तुम्ही GET पॅरामीटर्स पास करू शकता किंवा POST विनंतीच्या बाबतीत मुख्य भागाची विनंती करू शकता.

परिणामी, आम्ही एक उपाय प्राप्त करण्याची योजना आखली आहे ज्यामुळे विश्लेषकांना अभियंते आणि विकासकांच्या सहभागाशिवाय विकसित नियम स्क्रिप्ट तैनात करता येतील. वर्णन केलेला दृष्टीकोन विकासकांना विश्लेषक कोड दुसर्‍या भाषेत पुन्हा लिहिण्याची गरज देखील काढून टाकतो. उदाहरणार्थ, आम्ही वापरत असलेल्या सध्याच्या निर्णयप्रणालीसाठी, आम्हाला अत्यंत विशिष्ट तंत्रज्ञान आणि भाषांमध्ये नियम लिहावे लागतील, ज्याची व्याप्ती अत्यंत मर्यादित आहे, आणि अनुप्रयोग सर्व्हरवर खूप अवलंबून आहे, कारण सर्व मसुदा बँक नियम एकाच वातावरणात तैनात आहेत. परिणामी, नवीन नियम लागू करण्यासाठी संपूर्ण प्रणाली सोडणे आवश्यक आहे.

आमच्या प्रस्तावित सोल्यूशनमध्ये, नियम सोडण्याची आवश्यकता नाही; कोड एका बटणाच्या क्लिकवर सहजपणे तैनात केला जाऊ शकतो. तसेच, कुबर्नेट्समधील पायाभूत सुविधा व्यवस्थापन तुम्हाला लोड आणि स्केलिंगबद्दल विचार न करण्याची परवानगी देते; अशा समस्या बॉक्सच्या बाहेर सोडवल्या जातात. आणि एकल डेटा वेअरहाऊसचा वापर ऐतिहासिक डेटासह रीअल-टाइम डेटाची तुलना करण्याची आवश्यकता दूर करते, जे विश्लेषकाचे कार्य सुलभ करते.

जे मिळाले

आम्ही हॅकाथॉनमध्ये तयार सोल्यूशन (आमच्या कल्पनेत) घेऊन आलो असल्याने, आम्हाला फक्त आमचे सर्व विचार कोडच्या ओळींमध्ये रूपांतरित करायचे होते.

कोणत्याही हॅकाथॉनमधील यशाची गुरुकिल्ली म्हणजे तयारी आणि सु-लिखित योजना. म्हणून, आम्ही पहिली गोष्ट ठरवली की आमच्या सिस्टम आर्किटेक्चरमध्ये कोणते मॉड्यूल असतील आणि आम्ही कोणते तंत्रज्ञान वापरू.

आमच्या प्रकल्पाची रचना खालीलप्रमाणे होती:

हा आकृती विश्लेषक (आमच्या सिस्टमचा मुख्य वापरकर्ता) आणि क्लायंट असे दोन एंट्री पॉईंट दाखवते.

कामाच्या प्रक्रियेची रचना अशी आहे. विश्लेषक त्याच्या मॉडेलसाठी नियम फंक्शन आणि डेटा समृद्धी कार्य विकसित करतो, त्याचा कोड Git रेपॉजिटरीमध्ये संग्रहित करतो आणि प्रशासक अनुप्रयोगाद्वारे त्याचे मॉडेल क्लाउडवर तैनात करतो. उपयोजित कार्य कसे कॉल केले जाईल याचा विचार करूया आणि क्लायंटकडून येणाऱ्या विनंत्यांवर निर्णय घेऊया:

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

JSON दस्तऐवजांच्या स्वरूपात डेटाचे दस्तऐवज-देणारं स्टोरेज असल्यामुळे आम्ही आमच्या सिस्टममध्ये MongoDB एक स्टोरेज म्हणून वापरण्याचा निर्णय घेतला, कारण मूळ विनंतीसह समृद्धी सेवांनी REST कंट्रोलर्सद्वारे सर्व डेटा एकत्रित केला.

त्यामुळे, प्लॅटफॉर्म कार्यान्वित करण्यासाठी आमच्याकडे XNUMX तास होते. आम्ही भूमिका यशस्वीरित्या वितरित केल्या; प्रत्येक कार्यसंघ सदस्याची आमच्या प्रकल्पात स्वतःची जबाबदारी होती:

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

चला क्रमाने प्रारंभ करूया.

आमचा फ्रंटएंड बँकिंग UI किट वापरून अँगुलर 7 मध्ये लिहिलेला होता. अ‍ॅडमिन पॅनेलची अंतिम आवृत्ती असे दिसते:

थोडा वेळ असल्याने, आम्ही फक्त मुख्य कार्यक्षमता लागू करण्याचा प्रयत्न केला. कुबर्नेट्स क्लस्टरमध्ये फंक्शन उपयोजित करण्यासाठी, इव्हेंट (एक सेवा ज्यासाठी क्लाउडमध्ये नियम तैनात करणे आवश्यक आहे) आणि फंक्शनचा कोड निवडणे आवश्यक होते जे निर्णय घेण्याचे तर्क लागू करते. निवडलेल्या सेवेसाठी नियमाच्या प्रत्येक उपयोजनासाठी, आम्ही या कार्यक्रमाचा एक लॉग लिहिला. अॅडमिन पॅनेलमध्ये तुम्ही सर्व इव्हेंटचे लॉग पाहू शकता.

सर्व फंक्शन कोड रिमोट गिट रेपॉजिटरीमध्ये संग्रहित केले गेले होते, जे प्रशासक पॅनेलमध्ये देखील सेट केले जाणे आवश्यक होते. कोडच्या आवृत्तीसाठी, सर्व कार्ये रेपॉजिटरीच्या वेगवेगळ्या शाखांमध्ये संग्रहित केली गेली. प्रशासक पॅनेल लिखित स्क्रिप्टमध्ये समायोजन करण्याची क्षमता देखील प्रदान करते, जेणेकरून उत्पादनामध्ये फंक्शन तैनात करण्यापूर्वी, आपण केवळ लिखित कोड तपासू शकत नाही तर आवश्यक बदल देखील करू शकता.

नियम फंक्शन्स व्यतिरिक्त, आम्ही एन्रिचमेंट फंक्शन्स वापरून स्त्रोत डेटा हळूहळू समृद्ध करण्याची क्षमता देखील लागू केली, ज्याचा कोड स्क्रिप्ट देखील होता ज्यामध्ये डेटा वेअरहाऊसमध्ये जाणे, तृतीय-पक्ष सेवांना कॉल करणे आणि प्राथमिक गणना करणे शक्य होते. . आमचे समाधान प्रदर्शित करण्यासाठी, आम्ही विनंती सोडलेल्या क्लायंटच्या राशी चिन्हाची गणना केली आणि तृतीय-पक्ष REST सेवा वापरून त्याचा मोबाइल ऑपरेटर निर्धारित केला.

प्लॅटफॉर्मचा बॅकएंड Java मध्ये लिहिलेला होता आणि स्प्रिंग बूट ऍप्लिकेशन म्हणून लागू केला होता. आम्ही सुरुवातीला प्रशासक डेटा संचयित करण्यासाठी पोस्टग्रेस वापरण्याची योजना आखली, परंतु, हॅकाथॉनचा ​​एक भाग म्हणून, आम्ही वेळ वाचवण्यासाठी स्वतःला साध्या H2 पर्यंत मर्यादित ठेवण्याचा निर्णय घेतला. बॅकएंडवर, क्वेरी एन्रिचमेंट फंक्शन्स आणि नियम स्क्रिप्टच्या आवृत्तीसाठी बिटबकेटसह एकत्रीकरण लागू केले गेले. रिमोट गिट रेपॉजिटरीजसह एकत्रीकरणासाठी, आम्ही वापरले जेजीआयटी लायब्ररी, जे CLI कमांड्सवर एक प्रकारचे रॅपर आहे, जे तुम्हाला सोयीस्कर सॉफ्टवेअर इंटरफेस वापरून कोणत्याही git सूचना कार्यान्वित करण्यास अनुमती देते. म्हणून आमच्याकडे समृद्धी कार्ये आणि नियमांसाठी दोन स्वतंत्र भांडार होते आणि सर्व स्क्रिप्ट डिरेक्टरीमध्ये विभागल्या गेल्या. UI द्वारे रेपॉजिटरीच्या अनियंत्रित शाखेच्या स्क्रिप्टची नवीनतम कमिट निवडणे शक्य होते. प्रशासक पॅनेलद्वारे कोडमध्ये बदल करताना, बदललेल्या कोडची कमिट रिमोट रिपॉझिटरीजमध्ये तयार केली गेली.

आमची कल्पना अंमलात आणण्यासाठी आम्हाला योग्य पायाभूत सुविधांची गरज होती. आम्ही आमचे कुबेरनेट क्लस्टर क्लाउडमध्ये तैनात करण्याचा निर्णय घेतला. आमची निवड Google Cloud Platform होती. फिशन सर्व्हरलेस फ्रेमवर्क Kubernetes क्लस्टरवर स्थापित केले होते, जे आम्ही Gcloud मध्ये तैनात केले होते. सुरुवातीला, स्रोत डेटा संवर्धन सेवा k8s क्लस्टरच्या आत पॉडमध्ये गुंडाळलेल्या वेगळ्या Java अनुप्रयोगाच्या रूपात लागू करण्यात आली. परंतु हॅकाथॉनच्या मध्यभागी आमच्या प्रकल्पाच्या प्राथमिक प्रात्यक्षिकानंतर, येणार्‍या अनुप्रयोगांचा कच्चा डेटा कसा समृद्ध करायचा हे निवडण्याची संधी देण्यासाठी आम्हाला समृद्धी सेवा अधिक लवचिक बनविण्याची शिफारस करण्यात आली. आणि आमच्याकडे समृद्धी सेवा देखील सर्व्हरलेस करण्याशिवाय पर्याय नव्हता.

फिशनसह कार्य करण्यासाठी, आम्ही फिशन सीएलआय वापरला, जो कुबर्नेट्स सीएलआयच्या वर स्थापित केला जाणे आवश्यक आहे. k8s क्लस्टरमध्ये फंक्शन्स डिप्लॉय करणे अगदी सोपे आहे; क्लस्टरच्या बाहेर प्रवेश आवश्यक असल्यास येणार्‍या ट्रॅफिकला परवानगी देण्यासाठी तुम्हाला फक्त अंतर्गत मार्ग नियुक्त करणे आणि फंक्शनमध्ये प्रवेश करणे आवश्यक आहे. एक फंक्शन उपयोजित करण्यासाठी सामान्यत: 10 सेकंदांपेक्षा जास्त वेळ लागत नाही.

प्रकल्पाचे अंतिम सादरीकरण आणि सारांश

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

क्लायंट फॉर्ममधील डेटा कंट्रोलरकडे गेला, ज्याने एकाच वेळी सर्व उपलब्ध नियमांसाठी विनंत्या पाठवल्या, यापूर्वी निर्दिष्ट अटींनुसार डेटा समृद्ध केला आणि सामान्य स्टोरेजमध्ये जतन केला. एकूण, आम्ही तीन कार्ये तैनात केली आहेत जी येणार्‍या अनुप्रयोगांवर निर्णय घेतात आणि 4 डेटा समृद्धी सेवा. अर्ज सबमिट केल्यानंतर, क्लायंटला आमचा निर्णय प्राप्त झाला:

नकार किंवा मंजूरी व्यतिरिक्त, क्लायंटला इतर उत्पादनांची यादी देखील प्राप्त झाली, ज्यासाठी आम्ही समांतर पाठवलेल्या विनंत्या. अशा प्रकारे आम्ही आमच्या प्लॅटफॉर्ममध्ये क्रॉस-सेलची शक्यता दाखवली.

एकूण 3 काल्पनिक बँक उत्पादने उपलब्ध होती:

• पत.
• खेळण्यांचे
• गहाण.

प्रात्यक्षिक दरम्यान, आम्ही प्रत्येक सेवेसाठी तयार कार्ये आणि संवर्धन स्क्रिप्ट तैनात केल्या.

प्रत्येक नियमाला इनपुट डेटाचा स्वतःचा संच आवश्यक आहे. म्हणून, गहाणखत मंजूर करण्यासाठी, आम्ही क्लायंटच्या राशी चिन्हाची गणना केली आणि हे चंद्र कॅलेंडरच्या तर्काशी जोडले. खेळण्याला मंजूरी देण्यासाठी, आम्ही तपासले की क्लायंटचे वय पूर्ण झाले आहे आणि कर्ज जारी करण्यासाठी, आम्ही सेल्युलर ऑपरेटर निश्चित करण्यासाठी बाह्य खुल्या सेवेला विनंती पाठवली आणि त्यावर निर्णय घेण्यात आला.

आम्ही आमचे प्रात्यक्षिक मनोरंजक आणि परस्परसंवादी बनवण्याचा प्रयत्न केला, उपस्थित प्रत्येकजण आमच्या फॉर्मवर जाऊ शकतो आणि त्यांच्यासाठी आमच्या काल्पनिक सेवांची उपलब्धता तपासू शकतो. आणि सादरीकरणाच्या अगदी शेवटी, आम्ही प्राप्त झालेल्या अर्जांचे विश्लेषण प्रदर्शित केले, ज्याने आमची सेवा किती लोकांनी वापरली, मंजूरीची संख्या आणि नकार दर्शविला.

ऑनलाइन विश्लेषणे गोळा करण्यासाठी, आम्ही ओपन सोर्स BI टूल देखील तैनात केले मेटाबेस आणि ते आमच्या स्टोरेज युनिटमध्ये स्क्रू केले. मेटाबेस आपल्याला आपल्याला स्वारस्य असलेल्या डेटावर विश्लेषणासह स्क्रीन तयार करण्याची परवानगी देतो; आपल्याला फक्त डेटाबेसशी कनेक्शन नोंदणी करणे आवश्यक आहे, टेबल निवडणे आवश्यक आहे (आमच्या बाबतीत, डेटा संग्रह, आम्ही मोंगोडीबी वापरल्यामुळे), आणि आमच्यासाठी स्वारस्य असलेले क्षेत्र निर्दिष्ट करा. .

परिणामी, आम्हाला निर्णय घेण्याच्या व्यासपीठाचा एक चांगला नमुना मिळाला आणि प्रात्यक्षिक दरम्यान, प्रत्येक श्रोता वैयक्तिकरित्या त्याचे कार्यप्रदर्शन तपासू शकतो. एक मनोरंजक उपाय, तयार केलेला प्रोटोटाइप आणि यशस्वी प्रात्यक्षिकामुळे इतर संघांकडून जोरदार स्पर्धा असूनही आम्हाला जिंकता आले. मला खात्री आहे की प्रत्येक संघाच्या प्रकल्पावर एक मनोरंजक लेख देखील लिहिला जाऊ शकतो.

स्त्रोत: www.habr.com