नयाँ पुस्ताको बिलिङ वास्तुकला: ट्रान्टोलमा ट्रान्जिसनको साथ रूपान्तरण

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

Tarantool सँग के सरोकार छ? तिनीहरूले यसको बारेमा कुरा गर्नेछन् ओलेग Ivlev и Andrey Knyazev। ओलेग कम्पनीको प्रमुख वास्तुकार हुन् मेगाफोन विदेशी कम्पनीहरूमा काम गर्ने व्यापक अनुभवको साथ, एन्ड्री व्यापार प्रणालीका निर्देशक हुन्। उनीहरूको प्रतिवेदनको ट्रान्सक्रिप्टबाट Tarantool सम्मेलन 2018 तपाईंले निगमहरूमा किन आर एन्ड डी आवश्यक छ, टारन्टुल के हो, कसरी ठाडो मापन र विश्वव्यापीकरणको गतिरोध कम्पनीमा यस डाटाबेसको उपस्थितिको लागि आवश्यक शर्तहरू बन्यो, टेक्नोलोजिकल चुनौतीहरू, वास्तुकला रूपान्तरण, र मेगाफोनको टेक्नोस्ट्याक कसरी नेटफ्लिक्ससँग मिल्दोजुल्दो छ भन्ने कुरा सिक्नुहुनेछ। , गुगल र अमेजन।

परियोजना "एकीकृत बिलिङ"

प्रश्नमा रहेको परियोजनालाई "एकीकृत बिलिङ" भनिन्छ। यो यहाँ थियो कि Tarantool आफ्नो सबै भन्दा राम्रो गुण देखायो।

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

मेगाफोन एकमा आठ कम्पनीहरू छन्। 2009 मा, पुनर्गठन पूरा भयो: रूसभरका शाखाहरू एउटै कम्पनी, MegaFon OJSC (अहिले PJSC) मा मर्ज गरियो। यसरी, कम्पनीसँग आफ्नै "कस्टम" समाधानहरू, शाखा सुविधाहरू र विभिन्न संगठनात्मक संरचनाहरू, आईटी र मार्केटिङको साथ 8 बिलिङ प्रणालीहरू छन्।

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

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

ठाडो मापन। त्यतिबेलाको उत्कृष्ट हार्डवेयरले पनि आवश्यकता पूरा गर्न सकेन। हामीले Superdome Hi-End लाइनबाट Hewlett-Packard उपकरणहरू प्रयोग गर्यौं, तर यसले दुईवटा शाखाहरूको आवश्यकताहरू पनि पूरा गर्न सकेन। म ठूलो परिचालन लागत र पूंजी लगानी बिना तेर्सो स्केलिंग चाहन्थे।

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

प्राविधिक चुनौतीहरू

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

स्केलेबिलिटी

यदि यो पहिले थियो भने, भनौं, भनौं 8 मिलियन सदस्यहरूको लागि 15 बिलिङहरू, र अब यो काम गर्नुपर्छ 100 मिलियन सदस्यहरू र थप - लोड उच्च परिमाण को एक आदेश हो।

हामी Mail.ru वा Netflix जस्ता ठूला इन्टरनेट प्लेयरहरूसँग स्केलमा तुलनात्मक भएका छौं।

तर लोड र ग्राहक संख्या बढाउनको लागि थप आन्दोलनले हाम्रा लागि गम्भीर चुनौतीहरू खडा गरेको छ।

हाम्रो विशाल देशको भूगोल

कालिनिनग्राद र व्लादिभोस्तोक बीच 7500 किमी र 10 समय क्षेत्र। प्रकाशको गति सीमित छ र त्यस्ता दूरीहरूमा ढिलाइ पहिले नै महत्त्वपूर्ण छ। सबैभन्दा राम्रो आधुनिक अप्टिकल च्यानलहरूमा 150 ms वास्तविक-समय बिलिङको लागि धेरै धेरै छ, विशेष गरी यो अहिले रूसमा टेलिकममा छ। थप रूपमा, तपाईंले एक व्यापार दिनमा अद्यावधिक गर्न आवश्यक छ, र विभिन्न समय क्षेत्रहरूसँग यो समस्या हो।

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

दोष सहिष्णुता

यो केन्द्रीकरणको अर्को पक्ष हो ।

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

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

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

विश्व अनुभव

अचम्मको कुरा, हामीले ग्लोबल टेलिकममा एउटा पनि सन्दर्भ फेला पारेनौं।

युरोप सब्सक्राइबरको संख्या र स्केलको हिसाबले पछाडि परेको छ, अमेरिका - यसको ट्यारिफको सपाटताको हिसाबले। हामीले चीनमा केही हेर्यौं, र केही भारतमा भेट्टायौं र भोडाफोन भारतबाट विशेषज्ञहरू काममा राख्यौं।

वास्तुकलाको विश्लेषण गर्न, हामीले IBM - विभिन्न क्षेत्रका वास्तुकारहरूको नेतृत्वमा एउटा ड्रीम टोली भेला गर्यौं। यी मानिसहरूले हामीले के गर्दैछौं भनेर पर्याप्त रूपमा मूल्याङ्कन गर्न सक्थे र हाम्रो वास्तुकलामा निश्चित ज्ञान ल्याउन सक्थे।

स्केल

दृष्टान्तका लागि केही संख्याहरू।

हामीले प्रणालीको लागि डिजाइन गरेका छौं एक अर्बको रिजर्भको साथ 80 मिलियन सदस्यहरू। यसरी हामी भविष्यको थ्रेसहोल्डहरू हटाउँछौं। यो हामीले चीनलाई कब्जा गर्न लागेकाले होइन, तर IoT र M2M को आक्रमणको कारणले हो।

300 मिलियन कागजातहरू वास्तविक समयमा प्रशोधन गरियो। यद्यपि हामीसँग 80 मिलियन सदस्यहरू छन्, हामी सम्भावित ग्राहकहरू र हामीलाई छोडेकाहरू दुवैसँग काम गर्छौं यदि हामीले प्राप्य सङ्कलन गर्न आवश्यक छ भने। त्यसकारण, वास्तविक मात्राहरू उल्लेखनीय रूपमा ठूलो छन्।

२ अर्बको कारोबार भएको छ ब्यालेन्स दैनिक परिवर्तन हुन्छ - यी भुक्तानीहरू, शुल्कहरू, कलहरू र अन्य घटनाहरू हुन्। 200 TB डाटा सक्रिय रूपमा परिवर्तन हुँदैछ, अलि ढिलो परिवर्तन गर्नुहोस् 8 PB डाटा, र यो एउटा अभिलेख होइन, तर एकल बिलिङमा प्रत्यक्ष डेटा हो। डाटा केन्द्र द्वारा मापन - 5 साइटहरूमा 14 हजार सर्भरहरू.

टेक्नोलोजी स्ट्याक

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

स्ट्याक अन्य प्रमुख खेलाडीहरूको स्ट्याक जस्तै छ: Netflix, Twitter, Viber। यसमा ६ वटा कम्पोनेन्टहरू छन्, तर हामी यसलाई छोटो र एकीकरण गर्न चाहन्छौँ।

लचिलोपन राम्रो छ, तर ठूलो निगममा एकीकरण बिना कुनै बाटो छैन।

हामी उही Oracle लाई Tarantool मा परिवर्तन गर्दैनौं। ठूला कम्पनीहरूको वास्तविकतामा, यो एक यूटोपिया हो, वा अस्पष्ट परिणामको साथ 5-10 वर्षको लागि धर्मयुद्ध हो। तर क्यासान्ड्रा र काउचबेस सजिलैसँग टारान्टुलले प्रतिस्थापन गर्न सकिन्छ, र त्यसको लागि हामी प्रयासरत छौं।

किन Tarantool?

हामीले यो डाटाबेस किन रोज्यौं भन्ने 4 सरल मापदण्डहरू छन्।

गति। हामीले मेगाफोन औद्योगिक प्रणालीहरूमा लोड परीक्षणहरू सञ्चालन गर्यौं। Tarantool जित्यो - यो सबै भन्दा राम्रो प्रदर्शन देखायो।

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

Tarantool ले लामो अवधिमा पनि कम्पनीको आवश्यकताहरू समेट्छ।

TCO लागत। MegaFon भोल्युमहरूमा काउचबेसको लागि समर्थनमा खगोलीय मात्रामा पैसा खर्च हुन्छ, तर Tarantool को साथ स्थिति धेरै रमाइलो छ, र तिनीहरू कार्यक्षमतामा समान छन्।

अर्को राम्रो सुविधा जसले हाम्रो छनोटलाई थोरै प्रभाव पारेको छ त्यो हो कि Tarantool ले अन्य डाटाबेसहरू भन्दा मेमोरीसँग राम्रोसँग काम गर्दछ। उसले देखाउँछ अधिकतम दक्षता.

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

हामीले हाम्रो समय र वित्त लगानी गर्यौं, र Mail.ru सँगसँगै हामीले एउटा उद्यम संस्करण सिर्जना गर्यौं, जुन अब धेरै अन्य कम्पनीहरूमा प्रयोग गरिन्छ।

Tarantool-interprise ले सुरक्षा, विश्वसनीयता र लगिङको सन्दर्भमा हामीलाई पूर्ण रूपमा सन्तुष्ट पारेको छ।

भागीदारी

मेरो लागि सबैभन्दा महत्त्वपूर्ण कुरा हो विकासकर्ता संग प्रत्यक्ष सम्पर्क। टारनटूलका केटाहरूले घूस लिएका थिए यही हो।

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

- ठीक छ, आवश्यकताहरू त्यो थुप्रोको फेदमा राख्नुहोस् - कुनै दिन, हामी तिनीहरूमा पुग्न सक्छौं।

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

जहाँ हामीले Tarantool प्रयोग गर्यौं

हामी धेरै तत्वहरूमा Tarantool प्रयोग गर्छौं। पहिलो पाइलटमा छ, जुन हामीले ठेगाना डाइरेक्टरी प्रणालीमा बनायौं। एक पटक म यो Yandex.Maps र Google नक्सा जस्तै एक प्रणाली हुन चाहन्थे, तर यो अलि फरक भयो।

उदाहरणका लागि, बिक्री इन्टरफेसमा ठेगाना सूची। Oracle मा, इच्छित ठेगाना खोजी गर्न 12-13 सेकेन्ड लाग्छ। - असहज संख्या। जब हामी Tarantool मा स्विच गर्छौं, Oracle लाई कन्सोलमा अर्को डाटाबेससँग बदल्छौं, र उही खोजी गर्छौं, हामीले 200x स्पीडअप पाउँछौं! शहर तेस्रो अक्षर पछि पप अप। अब हामी इन्टरफेस अनुकूलन गर्दैछौं ताकि यो पहिलो पछि हुन्छ। यद्यपि, प्रतिक्रिया गति पूर्ण रूपमा फरक छ - सेकेन्डको सट्टा मिलिसेकेन्ड।

दोस्रो अनुप्रयोग एक ट्रेंडी विषयवस्तु हो जसलाई दुई-स्पीड आईटी भनिन्छ। किनकी हरेक कुनाका परामर्शदाताले कर्पोरेसनहरू त्यहाँ जानुपर्छ भन्ने गर्छन् ।

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

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

MegaFon मा टारन्टुलको मुख्य भूमिका माइक्रोसर्भिसेसहरू हुन्।

जहाँ हामी Tarantool प्रयोग गर्ने योजना बनाउँछौं

यदि हामीले हाम्रो सफल बिलिङ परियोजनालाई Deutsche Telekom, Svyazcom, Vodafone India मा परिवर्तन कार्यक्रमहरूसँग तुलना गर्छौं भने, यो आश्चर्यजनक रूपमा गतिशील र रचनात्मक छ। यस परियोजनाको कार्यान्वयनको प्रक्रियामा, MegaFon र यसको संरचना मात्र परिवर्तन भएन, तर Tarantool-enterprise पनि Mail.ru मा देखा पर्‍यो, र हाम्रो विक्रेता Nexign (पहिले Peter-Service) - BSS Box (एक बाकस बिलिङ समाधान)।

यो, एक अर्थमा, रूसी बजार को लागी एक ऐतिहासिक परियोजना हो। यसलाई फ्रेडरिक ब्रूक्सको पुस्तक "द मिथिकल म्यान-मन्थ" मा वर्णन गरिएको कुरासँग तुलना गर्न सकिन्छ। त्यसपछि, 60 को दशकमा, IBM ले मेनफ्रेमहरूको लागि नयाँ OS/360 अपरेटिङ सिस्टम विकास गर्न 5 मानिसहरूलाई काममा लिए। हामीसँग कम छ - 000, तर हाम्रो भेस्टमा छ, र खुला स्रोत र नयाँ दृष्टिकोणहरूको प्रयोगलाई ध्यानमा राख्दै, हामी थप उत्पादनशील रूपमा काम गर्छौं।

तल बिलिङका डोमेनहरू वा, अधिक व्यापक रूपमा बोल्ने, व्यापार प्रणालीहरू छन्। उद्यमका मानिसहरूले CRM लाई राम्ररी जान्दछन्। सबैसँग पहिले नै अन्य प्रणालीहरू हुनुपर्छ: खुला API, API गेटवे।

API खोल्नुहोस्

फेरि नम्बरहरू हेरौं र कसरी Open API ले हाल काम गर्छ। यसको भार छ प्रति सेकेन्ड १०,००० लेनदेन। हामीले माइक्रोसर्भिसेस तहलाई सक्रिय रूपमा विकास गर्ने र मेगाफोन पब्लिक एपीआई निर्माण गर्ने योजना बनाएकाले, हामी यस भागमा भविष्यमा अझ ठूलो वृद्धिको अपेक्षा गर्छौं। त्यहाँ निश्चित रूपमा 100 लेनदेन हुनेछ.

मलाई थाहा छैन यदि हामी SSO मा Mail.ru सँग तुलना गर्न सक्छौं - केटाहरूसँग प्रति सेकेन्ड 1 लेनदेनहरू छन्। तिनीहरूको समाधान हाम्रो लागि अत्यन्तै चाखलाग्दो छ र हामी तिनीहरूको अनुभवलाई ग्रहण गर्ने योजना गर्छौं - उदाहरणका लागि, Tarantool प्रयोग गरेर कार्यात्मक SSO ब्याकअप बनाउने। अब Mail.ru बाट विकासकर्ताहरूले यो हाम्रो लागि गर्दैछन्।

सीआरएम

CRM उही 80 मिलियन सदस्यहरू हुन् जुन हामी एक अर्बमा बढाउन चाहन्छौं, किनभने त्यहाँ पहिले नै 300 मिलियन कागजातहरू छन् जसमा तीन वर्षको इतिहास समावेश छ। हामी वास्तवमै नयाँ सेवाहरू र यहाँ हेर्दै छौं वृद्धि बिन्दु जोडिएको सेवा हो। यो एक बल हो जुन बढ्नेछ, किनकि त्यहाँ धेरै र अधिक सेवाहरू हुनेछन्। तदनुसार, हामीलाई एउटा कथा चाहिन्छ; हामी यसमा ठेस लाग्न चाहँदैनौं।

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

प्रणाली डोमेनहरूमा विभाजित गरिएको छ, लोड वितरण गरिएको छ र दोष सहिष्णुता सुनिश्चित गरिएको छ। थप रूपमा, हामीले वितरित वास्तुकलासँग काम गर्यौं।

अरू सबै उद्यम-स्तर समाधान हो। कल भण्डारणमा - दैनिक २ अर्ब, 60 बिलियन प्रति महिना। कहिलेकाहीँ तपाईंले तिनीहरूलाई एक महिनामा गणना गर्नुपर्छ, र यो छिटो राम्रो छ। आर्थिक अनुगमन - यो ठ्याक्कै उस्तै 300 मिलियन हो जुन निरन्तर बढ्दै र बढ्दै छ: ग्राहकहरू प्रायः अपरेटरहरू बीच चल्छन्, यो भाग बढ्दै।

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

अघिल्लो तस्वीर डोमेन हो जहाँ हामी Tarantool प्रयोग गर्न जाँदैछौं। CRM आफैं, निस्सन्देह, फराकिलो छ र हामी यसलाई कोरमा प्रयोग गर्न जाँदैछौं।

हाम्रो अनुमानित 100 मिलियन सदस्यहरूको TTX आंकडाले मलाई वास्तुकारको रूपमा भ्रमित पार्छ - यदि 101 मिलियन? के तपाईंले सबै कुरा फेरि गर्नु पर्छ? यो हुनबाट रोक्नको लागि, हामी क्यासहरू प्रयोग गर्छौं, एकै समयमा पहुँच बढाउँदै।

सामान्यतया, टारन्टुल प्रयोग गर्न दुईवटा दृष्टिकोणहरू छन्। पहिलो - माइक्रोसेवा स्तरमा सबै क्यासहरू निर्माण गर्नुहोस्। जहाँसम्म मैले बुझेको छु, VimpelCom ले यो मार्ग पछ्याउँदै छ, ग्राहकहरूको क्यास सिर्जना गर्दैछ।

हामी विक्रेताहरूमा कम निर्भर छौं, हामी BSS कोर परिवर्तन गर्दैछौं, त्यसैले हामीसँग बाकस बाहिर एक ग्राहक फाइल छ। तर हामी यसलाई विस्तार गर्न चाहन्छौं। त्यसकारण, हामी अलि फरक दृष्टिकोण लिन्छौं - प्रणाली भित्र क्यास बनाउन.

यस तरिकाले त्यहाँ कम सिङ्क्रोनाइजेसन छ - एक प्रणाली क्यास र मुख्य मास्टर स्रोत दुवैको लागि जिम्मेवार छ।

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

RTO र RPO

IT मा दुई सर्तहरू छन् - आरटीओ и RPO.

रिकभरी समय उद्देश्य असफलता पछि सेवा पुनर्स्थापना गर्न लाग्ने समय हो। RTO = 0 को मतलब केहि असफल भए पनि, सेवाले काम जारी राख्छ।

रिकभरी बिन्दु उद्देश्य - यो डाटा रिकभरी समय हो, कति डाटा हामी समय को एक निश्चित अवधि मा गुमाउन सक्छौं। RPO = 0 भनेको हामीले डाटा गुमाउँदैनौं।

Tarantool कार्य

Tarantool को लागि समस्या समाधान गर्न प्रयास गरौं।

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

निर्णय। तपाइँ यसलाई हेड-अन समाधान गर्न प्रयास गर्न सक्नुहुन्छ र डाटाबेस विकासकर्ताहरूलाई सोध्न सक्नुहुन्छ, तर समस्या गणितीय रूपमा हल गर्न सकिँदैन। तपाईंले प्रमेयहरू, संरक्षण कानूनहरू, क्वान्टम भौतिकी सम्झन सक्नुहुन्छ, तर किन - यो DB स्तरमा हल गर्न सकिँदैन।

राम्रो पुरानो आर्किटेक्चरल दृष्टिकोण यहाँ काम गर्दछ - तपाईंले विषय क्षेत्र राम्रोसँग जान्न आवश्यक छ र यो पजल समाधान गर्न प्रयोग गर्नुहोस्।

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

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

हामी प्रारम्भिक रूपमा भू-वितरित समाधान निर्माण गर्दैछौं - दोष सहिष्णुता हाम्रो लागि महत्त्वपूर्ण छ।

त्यसोभए हामीसँग क्लस्टर छ, तर RPO = ० र RTO = ० को बारेमा? समाधान सरल छ, विषय मा निर्भर गर्दछ।

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

यदि मस्को डाटा केन्द्र अचानक असफल भयो भने, त्यसपछि स्वचालित रूपमा अर्को डाटा केन्द्रमा स्विच गरेर, हामी काम जारी राख्नेछौं। सैद्धान्तिक रूपमा, एउटा उत्पादन कार्टमा हराउन सक्छ, तर तपाईंले यसलाई देख्नुहुन्छ, फेरि कार्टमा थप्नुहोस् र काम जारी राख्नुहोस्। यस अवस्थामा RTO = ०।

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

यसबाहेक, अनुप्रयोगहरूको वितरित रजिस्ट्री भएकोले, हामी यो सबै मापन गर्न सक्छौं - धेरै प्रेषकहरू र एक्जिक्युटरहरू छन् जसले यस रजिस्ट्रीमा पहुँच गर्छन्।

क्यासान्ड्रा र टारान्टुल सँगै

अर्को मामला छ - "ब्यालेन्सको प्रदर्शन"। यहाँ Cassandra र Tarantool को संयुक्त प्रयोग को एक रोचक मामला छ।

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

क्यासान्ड्राले तपाईंलाई कुनै पनि साइजमा तेर्सो मापन गर्न अनुमति दिन्छ।

हामी क्यासान्ड्रासँग सहज महसुस गर्छौं, तर यसमा एउटा समस्या छ - यो पढ्नमा राम्रो छैन। रेकर्डिङमा सबै ठीक छ, प्रति सेकेन्ड 30 कुनै समस्या छैन - पढ्ने समस्या.

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

यो हुनबाट रोक्नको लागि, हामी हामी समानान्तर कार्यात्मक रिजर्व प्रयोग गर्दछौं। जब हामी काफ्का मार्फत Tarantool मा घटना पठाउँछौं, वास्तविक समयमा समुच्चय पुन: गणना गर्दै, उदाहरण को लागी, आज को लागी, हामी प्राप्त गर्दछौं नगद ब्यालेन्स, जसले कुनै पनि गतिमा ब्यालेन्स स्थानान्तरण गर्न सक्छ, उदाहरणका लागि, प्रति सेकेन्ड 100 हजार लेनदेन र उही 2 सेकेन्ड।

लक्ष्य भनेको कल गरेपछि, तपाईको व्यक्तिगत खातामा २ सेकेन्ड भित्रमा परिवर्तन गरिएको ब्यालेन्स मात्र नभई यो किन परिवर्तन भयो भन्ने बारे जानकारी हुनेछ।

निष्कर्षमा

यी Tarantool प्रयोग गर्ने उदाहरणहरू थिए। हामीले Mail.ru को खुलापन र विभिन्न मामिलाहरू विचार गर्ने तिनीहरूको इच्छा साँच्चै मन पराएका छौं।

BCG वा McKinsey, Accenture वा IBM का सल्लाहकारहरूका लागि हामीलाई केही नयाँ कुराले आश्चर्यचकित गर्न पहिले नै गाह्रो छ - उनीहरूले प्रस्ताव गरेका धेरै जसो हामीले पहिले नै गरिसकेका छौं, वा गर्ने योजनामा ​​छौं। मलाई लाग्छ कि Tarantool ले हाम्रो टेक्नोलोजी स्ट्याकमा यसको सही स्थान लिनेछ र धेरै अवस्थित प्रविधिहरू प्रतिस्थापन गर्नेछ। हामी यस परियोजनाको विकासको सक्रिय चरणमा छौं।

ओलेग र एन्ड्रीको रिपोर्ट गत वर्ष टारान्टुल सम्मेलनमा उत्कृष्ट मध्ये एक हो, र जुन 17 मा ओलेग इभलेभले बोल्नेछन्। T+ सम्मेलन २०१९ एक रिपोर्ट संग "इन्टरप्राइजमा टारन्टूल किन"। अलेक्ज्याण्डर डिउलिनले मेगाफोनबाट प्रस्तुतीकरण पनि दिनेछन् "ओरेकलबाट टारन्टुल क्यास र प्रतिकृति"। के के परिवर्तन भयो, कस्ता योजनाहरु कार्यान्वयन भए जानौँ । सम्मिलित हुनुहोस् - सम्मेलन नि: शुल्क छ, तपाईले गर्नु पर्छ साइन अप... सबै रिपोर्टहरू स्वीकार गरियो र सम्मेलन कार्यक्रम गठन गरिएको छ: नयाँ केसहरू, Tarantool प्रयोग गर्ने नयाँ अनुभव, वास्तुकला, उद्यम, ट्यूटोरियल र माइक्रो सेवाहरू।

स्रोत: www.habr.com