हामीले कसरी Kubernetes भित्र क्लाउड FaaS बनायौं र Tinkoff ह्याकाथन जित्यौं

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

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

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

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

स्कोरिङ के हो

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

उदाहरणका लागि, एक ग्राहकले उहाँलाई ऋण जारी गर्न वा हामीसँग व्यक्तिगत उद्यमी खाता खोल्न अनुरोधको साथ हामीलाई फर्काउँछ। यदि हामीले उसलाई ऋण जारी गर्ने योजना बनायौं भने, हामीले उसको सोलभेन्सी मूल्याङ्कन गर्न आवश्यक छ, र यदि खाता एक व्यक्तिगत उद्यमी हो भने, हामी निश्चित हुनुपर्दछ कि ग्राहकले धोखाधडी लेनदेनहरू सञ्चालन गर्दैन।

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

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

हामीसँग ग्राहक सम्बन्धको बारेमा डाटाको धन हो, र यो जानकारीको मात्रा निरन्तर बढिरहेको छ। कामको लागि स्कोरिङको लागि, डेटा प्रशोधनलाई नियमहरू (वा गणितीय मोडेलहरू) पनि चाहिन्छ जसले तपाईंलाई कसले आवेदन स्वीकृत गर्ने, कसलाई अस्वीकार गर्ने, र कसले थप उत्पादनहरू प्रस्ताव गर्ने भन्ने निर्णय गर्न तिनीहरूको सम्भावित रुचिको मूल्याङ्कन गर्न अनुमति दिन्छ।

हातमा रहेको कार्यको लागि, हामीले पहिले नै विशेष निर्णय गर्ने प्रणाली प्रयोग गरेका छौं IBM WebSphere ILOG JRules BRMS, जसले, विश्लेषकहरू, प्राविधिकहरू र विकासकर्ताहरूद्वारा सेट गरिएका नियमहरूको आधारमा, ग्राहकलाई विशेष बैंकिङ उत्पादन स्वीकृत गर्ने वा अस्वीकार गर्ने निर्णय गर्दछ।

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

कार्य

ह्याकाथन फेब्रुअरी २३ मा आयोजना गरिएको थियो । सहभागीहरूलाई एक लडाई कार्य प्रस्ताव गरिएको थियो: निर्णय गर्ने प्रणाली विकास गर्न जुन धेरै सर्तहरू पूरा गर्नुपर्दछ।

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

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

प्रविधिको लागि, सबै सहभागीहरूलाई छनौटको पूर्ण स्वतन्त्रता दिइएको थियो। कुनै पनि अवधारणा र प्रविधिहरू प्रयोग गर्न सम्भव थियो: डाटा स्ट्रिमिङ, मेसिन लर्निङ, घटना सोर्सिङ, ठूलो डाटा र अन्य।

हाम्रो समाधान

थोरै विचार-मंथन पछि, हामीले निर्णय गर्यौं कि कार्य पूरा गर्नको लागि एक FaaS समाधान उपयुक्त हुनेछ।

यस समाधानका लागि, विकास भइरहेको निर्णय प्रणालीका नियमहरू लागू गर्न उपयुक्त सर्भरलेस फ्रेमवर्क खोज्न आवश्यक थियो। Tinkoff सक्रिय रूपमा पूर्वाधार व्यवस्थापनको लागि Kubernetes प्रयोग गरेको हुनाले, हामीले यसको आधारमा धेरै तयार समाधानहरू हेरेका छौं; म तपाईंलाई पछि यसको बारेमा थप बताउँनेछु।

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

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

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

ह्याकाथन अघि नै, हामीले प्रयोग गर्ने सर्भरलेस फ्रेमवर्कमा निर्णय गर्यौं। आज बजारमा धेरै प्रविधिहरू छन् जुन यो दृष्टिकोण लागू गर्दछ। Kubernetes आर्किटेक्चर भित्र सबैभन्दा लोकप्रिय समाधान फिशन, Open FaaS र Kubeless हुन्। त्यहाँ पनि छन् तिनीहरूको विवरण र तुलनात्मक विश्लेषणको साथ राम्रो लेख.

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

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

विखंडन पनि धेरै फाइलहरूमा विभाजित कार्यहरू प्रदर्शन गर्न सक्षम छ, अभिलेखमा पूर्व-प्याकेज। Kubernetes क्लस्टरमा फिशनको सञ्चालन विशेष पोडहरूद्वारा सुनिश्चित गरिएको छ, जुन फ्रेमवर्कद्वारा नै व्यवस्थित गरिन्छ। क्लस्टर पोडहरूसँग अन्तर्क्रिया गर्न, प्रत्येक प्रकार्यलाई यसको आफ्नै मार्ग तोक्नुपर्छ, र जसमा तपाईंले GET प्यारामिटरहरू पास गर्न सक्नुहुन्छ वा POST अनुरोधको अवस्थामा शरीरलाई अनुरोध गर्न सक्नुहुन्छ।

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

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

हामीले के पायौं

हामी ह्याकाथनमा तयार समाधान (हाम्रो कल्पनामा) लिएर आएको हुनाले, हामीले हाम्रा सबै विचारहरूलाई कोडको लाइनमा रूपान्तरण गर्नु थियो।

कुनै पनि ह्याकाथनमा सफलताको कुञ्जी तयारी र राम्रोसँग लिखित योजना हो। त्यसकारण, हामीले पहिलो कुरा भनेको हाम्रो प्रणाली वास्तुकलामा कुन मोड्युलहरू समावेश हुनेछन् र हामीले कुन प्रविधिहरू प्रयोग गर्ने भन्ने निर्णय गर्नु थियो।

हाम्रो परियोजनाको वास्तुकला निम्नानुसार थियो:

यो रेखाचित्रले दुई प्रविष्टि बिन्दुहरू देखाउँछ, विश्लेषक (हाम्रो प्रणालीको मुख्य प्रयोगकर्ता) र ग्राहक।

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

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

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

त्यसोभए, हामीसँग प्लेटफर्म लागू गर्न XNUMX घण्टा थियो। हामीले भूमिकाहरू सफलतापूर्वक वितरण गर्यौं; प्रत्येक टोली सदस्यको हाम्रो परियोजनामा ​​जिम्मेवारीको आफ्नै क्षेत्र थियो:

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

क्रममा सुरु गरौं।

हाम्रो फ्रन्टएन्ड बैंकिङ UI किट प्रयोग गरेर Angular 7 मा लेखिएको थियो। प्रशासक प्यानलको अन्तिम संस्करण यस्तो देखिन्थ्यो:

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

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

नियम प्रकार्यहरू बाहेक, हामीले संवर्धन प्रकार्यहरू प्रयोग गरेर स्रोत डेटालाई क्रमशः समृद्ध गर्ने क्षमता पनि लागू गर्‍यौं, जसको कोड पनि स्क्रिप्टहरू थिए जसमा डाटा गोदाममा जान, तेस्रो-पक्ष सेवाहरू कल गर्न र प्रारम्भिक गणनाहरू गर्न सम्भव थियो। । हाम्रो समाधान प्रदर्शन गर्न, हामीले अनुरोध छोड्ने ग्राहकको राशि चिन्ह गणना गर्‍यौं र तेस्रो-पक्ष REST सेवा प्रयोग गरेर आफ्नो मोबाइल अपरेटर निर्धारण गर्‍यौं।

प्लेटफर्मको ब्याकइन्ड जाभामा लेखिएको थियो र वसन्त बुट अनुप्रयोगको रूपमा लागू गरिएको थियो। हामीले प्रारम्भमा व्यवस्थापक डेटा भण्डारण गर्न पोस्टग्रेस प्रयोग गर्ने योजना बनायौं, तर ह्याकाथनको भागको रूपमा, हामीले समय बचत गर्नको लागि आफूलाई साधारण H2 मा सीमित गर्ने निर्णय गर्यौं। ब्याकइन्डमा, Bitbucket सँग एकीकरण क्वेरी संवर्धन कार्यहरू र नियम लिपिहरूको संस्करणमा लागू गरिएको थियो। रिमोट Git भण्डारहरूसँग एकीकरणको लागि, हामीले प्रयोग गर्यौं JGit पुस्तकालय, जुन CLI आदेशहरूमा एक प्रकारको र्यापर हो, जसले तपाईंलाई सुविधाजनक सफ्टवेयर इन्टरफेस प्रयोग गरेर कुनै पनि git निर्देशनहरू कार्यान्वयन गर्न अनुमति दिन्छ। त्यसोभए हामीसँग समृद्धि कार्यहरू र नियमहरूका लागि दुईवटा छुट्टै भण्डारहरू थिए, र सबै लिपिहरूलाई डाइरेक्टरीहरूमा विभाजित गरिएको थियो। UI मार्फत भण्डारको मनमानी शाखाको स्क्रिप्टको नवीनतम कमिट चयन गर्न सम्भव थियो। प्रशासक प्यानल मार्फत कोडमा परिवर्तन गर्दा, रिमोट रिपोजिटरीहरूमा परिवर्तन गरिएको कोडको कमिटहरू सिर्जना गरियो।

हाम्रो विचारलाई कार्यान्वयन गर्न, हामीलाई उपयुक्त पूर्वाधार चाहिन्छ। हामीले क्लाउडमा हाम्रो Kubernetes क्लस्टर तैनाथ गर्ने निर्णय गर्यौं। हाम्रो रोजाइ गुगल क्लाउड प्लेटफर्म थियो। फिशन सर्भरलेस फ्रेमवर्क Kubernetes क्लस्टरमा स्थापना गरिएको थियो, जुन हामीले Gcloud मा तैनात गर्यौं। प्रारम्भमा, स्रोत डेटा संवर्धन सेवा k8s क्लस्टर भित्र पोडमा बेरिएको छुट्टै Java अनुप्रयोगको रूपमा लागू गरिएको थियो। तर ह्याकाथनको बीचमा हाम्रो परियोजनाको प्रारम्भिक प्रदर्शन पछि, हामीलाई आगमन अनुप्रयोगहरूको कच्चा डाटा कसरी समृद्ध गर्ने भनेर छनौट गर्ने अवसर प्रदान गर्न संवर्धन सेवालाई थप लचिलो बनाउन सिफारिस गरिएको थियो। र हामीसँग समृद्धि सेवालाई पनि सर्भरलेस बनाउन बाहेक अर्को विकल्प थिएन।

फिशनसँग काम गर्न, हामीले फिसन सीएलआई प्रयोग गर्‍यौं, जुन कुबर्नेट्स सीएलआईको शीर्षमा स्थापित हुनुपर्छ। k8s क्लस्टरमा प्रकार्यहरू डिप्लोइङ गर्नु एकदम सरल छ; यदि क्लस्टर बाहिर पहुँच आवश्यक छ भने आगमन ट्राफिकलाई अनुमति दिन तपाईंले केवल आन्तरिक मार्ग तोक्न र प्रकार्यमा प्रवेश गर्न आवश्यक छ। एउटा प्रकार्य तैनाथ गर्न सामान्यतया 10 सेकेन्ड भन्दा बढी लाग्दैन।

परियोजनाको अन्तिम प्रस्तुति र संक्षेप

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

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

अस्वीकार वा अनुमोदनको अतिरिक्त, ग्राहकले अन्य उत्पादनहरूको सूची पनि प्राप्त गर्‍यो, जसको लागि हामीले समानान्तरमा पठाएका अनुरोधहरू। यसरी हामीले हाम्रो प्लेटफर्ममा क्रस-सेलको सम्भावना देख्यौं।

त्यहाँ कुल 3 काल्पनिक बैंक उत्पादनहरू उपलब्ध थिए:

• क्रेडिट।
• खिलौना
• धितो।

प्रदर्शनको क्रममा, हामीले प्रत्येक सेवाको लागि तयार कार्यहरू र संवर्धन लिपिहरू तैनात गर्यौं।

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

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

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

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

स्रोत: www.habr.com