हुड के तहत RBKmoney भुगतान - भुगतान मंच बुनियादी ढांचा

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

दृष्टिकोण और सीमाएँ

प्लेटफॉर्म के विकास से पहले तैयार की गई पहली आवश्यकताओं में से एक यह है कि "किसी भी संख्या के लेनदेन के प्रसंस्करण को सुनिश्चित करने के लिए रैखिक रूप से कंप्यूटिंग संसाधनों को स्केल करने की क्षमता।"

बाजार सहभागियों द्वारा उपयोग किए जाने वाले भुगतान किए गए सिस्टम के शास्त्रीय दृष्टिकोण बयानों के अनुसार एक सीलिंग की उपस्थिति का मतलब है, हालांकि उच्च। आमतौर पर ऐसा लगता है: "हमारा प्रसंस्करण प्रति सेकंड 1000 लेनदेन स्वीकार कर सकता है।"

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

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

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

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

कंप्यूटिंग शक्ति के संदर्भ में सबसे मजबूत नहीं होने वाले सर्वरों के उपयोग के अपने फायदे हैं - उनकी विफलता का पूरे सिस्टम की सामान्य स्थिति पर महत्वपूर्ण प्रभाव नहीं पड़ता है। कल्पना करें कि क्या बेहतर है - यदि एक महंगा, बड़ा और सुपर-विश्वसनीय ब्रांड सर्वर जलता है, तो मास्टर-स्लेव स्कीम के अनुसार DBMS चलाना (और मर्फी के नियम के अनुसार, यह निश्चित रूप से जल जाएगा, और 31 दिसंबर की शाम को) या मास्टर ऑफ के अनुसार चलने वाले 30 नोड्स के क्लस्टर में कुछ सर्वर -scheme?

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

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

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

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

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

सर्वर अवसंरचना

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

फिलहाल, कंप्यूटिंग शक्ति के लिए हमारा क्लासिक सर्वर इस तरह दिखता है:

• 2xXeon E5-2630 सीपीयू;
• 128 जी रैम;
• 3xSATA SSD (सेफ एसएसडी पूल);
• 1xNVMe SSD (dm-cache)।

राज्यों के भंडारण के लिए सर्वर:

• 1xXeon E5-2630 सीपीयू;
• 12-16 एचडीडी;
• ब्लॉक .b के लिए 2 एसएसडी;
• 32 जी रैम।

नेटवर्क का बुनियादी ढांचा

नेटवर्क हार्डवेयर की पसंद में, हमारा दृष्टिकोण कुछ अलग है। हम अभी भी vlan-s के बीच स्विच करने और रूट करने के लिए ब्रांडेड स्विच का उपयोग करते हैं, अब यह सैन में सिस्को SG500X-48 और सिस्को नेक्सस C5020 है।

शारीरिक रूप से, प्रत्येक सर्वर 4 भौतिक पोर्ट द्वारा नेटवर्क से जुड़ा होता है:

• 2x1GbE - अनुप्रयोगों के बीच प्रबंधन नेटवर्क और RPC;
• 2x10GbE - भंडारण के लिए नेटवर्क।

मशीनों के अंदर के इंटरफेस को बॉन्डिंग द्वारा संयोजित किया जाता है, फिर वांछित वलान के अनुसार टैग किए गए ट्रैफ़िक डाइवर्ज किए जाते हैं।

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

डीसी में विशिष्ट रैक

स्केलिंग करते समय, डीसी में रैक व्यावहारिक रूप से अपलिंक राउटर को छोड़कर एक दूसरे से अलग नहीं होते हैं, जो उनमें से एक में स्थापित होते हैं।

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

ब्लॉक डिवाइस और संसाधन साझाकरण

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

एक विशिष्ट लेआउट इस तरह दिखेगा:

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

सामान्य ब्लॉक उपकरणों के लिए, हम सिफ RBD का उपयोग करते हैं, आमतौर पर स्थानीय NVMe डिस्क पर राइट-थ्रू dm-cache के साथ। वांछित प्रतिक्रिया समय के आधार पर, डिवाइस के लिए ओएसडी एसएसडी लॉग के साथ पूर्ण-फ्लैश या एचडीडी हो सकता है।

अनुप्रयोगों के लिए यातायात का वितरण

बाहर से आने वाले अनुरोधों को संतुलित करने के लिए, हम मानक OSPFv3 ECMP योजना का उपयोग करते हैं। नगीनक्स, बर्ड के साथ छोटी आभासी मशीनें, ओएस इंटरफेस में ओएसपीएफ क्लाउड कॉमन एनाकास्ट एड्रेस में कौंसल की घोषणा। राउटर पर, इन पतों के लिए, पक्षी मल्टी-हॉप मार्ग बनाता है जो प्रति-प्रवाह संतुलन प्रदान करता है, जहां प्रवाह "src-ip src-port dst-ip dst-port" है। लापता बैलेंसर को जल्दी से निष्क्रिय करने के लिए, बीएफडी प्रोटोकॉल का उपयोग किया जाता है।

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

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

समस्या को हल करने के लिए, हम बुनियादी ढांचे के इस हिस्से में पीएमटीयूडी डेमॉन का उपयोग करते हैं।

इसके अलावा, ट्रैफ़िक प्लेटफ़ॉर्म के अंदर विशिष्ट माइक्रोसर्विसेज के अनुसार नंगेक्स कॉन्फ़िगरेशन के अनुसार बैलेन्सर पर जाता है।

और अगर बाहरी ट्रैफ़िक को संतुलित करना कम या ज्यादा सरल और समझ में आता है, तो इस तरह की स्कीम को आगे की ओर बढ़ाना मुश्किल होगा - हमें नेटवर्क स्तर पर एक माइक्रोसरोवर के साथ कंटेनर की उपलब्धता की जाँच करने की तुलना में अधिक आवश्यकता है।

आदेश प्राप्त करने और प्रसंस्करण शुरू करने के लिए माइक्रोसर्विस के लिए, इसे सेवा डिस्कवरी (हम कांसुल का उपयोग करें) के साथ पंजीकृत होना चाहिए, हर सेकंड स्वास्थ्य जांच से गुजरना चाहिए और एक उचित आरटीटी होना चाहिए।

यदि माइक्रोसिस्ट सेवा महसूस करता है और अच्छी तरह से व्यवहार करता है, तो सेवा के नाम से अपने DNS का उपयोग करते समय, कॉन्सल अपने कंटेनर के पते को हल करना शुरू कर देता है। हम आंतरिक क्षेत्र service.consul उपयोग करते हैं। capi-v2.service.consul , और, उदाहरण के लिए, कॉमन एपीआई संस्करण 2 माइक्रोसर्विस का नाम capi-v2.service.consul ।

अंत में संतुलन के बारे में nginx विन्यास इस तरह दिखता है:

 location = /v2/ { set $service_hostname "${staging_pass}capi-v2.service.consul"; proxy_pass http://$service_hostname:8022; } 

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

यदि बैलेंसर से अनुरोध ऊपर की ओर चला गया, और वह रास्ते में ही मर गया, तो हम 502 लौटाते हैं - अपने स्तर पर बैलेंसर यह निर्धारित नहीं कर सकता है कि अनुरोध निष्क्रिय था या नहीं, इसलिए हम इस तरह की त्रुटियों के प्रसंस्करण को उच्च स्तर के तर्क देते हैं।

बेरोजगारी और समय सीमा

सामान्य तौर पर, हम डरते नहीं हैं और एपीआई के साथ 5xx त्रुटियां देने में संकोच नहीं करते हैं, यह सिस्टम का एक सामान्य हिस्सा है यदि आप आरपीसी व्यावसायिक तर्क स्तर पर ऐसी त्रुटियों का सही प्रसंस्करण करते हैं। इस प्रसंस्करण के सिद्धांतों को हमारे रूप में वर्णित किया जाता है एक छोटी पुस्तिका जिसे एरर्स रिट्री पॉलिसी कहा जाता है, हम इसे अपने मर्चेंट क्लाइंट को वितरित करते हैं और इसे हमारी सेवाओं के अंदर लागू करते हैं।

इस प्रसंस्करण को सरल बनाने के लिए, हमने कई दृष्टिकोण लागू किए हैं।

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

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

तीसरा, हमने समय-समय पर कट-ऑफ पैरामीटर के रूप में हमारे एपीआई के लिए किसी भी बाहरी कॉल के लिए एक पूर्वानुमानित और बाहरी रूप से नियंत्रित प्रतिक्रिया समय को सक्षम करने का निर्णय लिया, जो अनुरोध पर पूरा होने के लिए किसी ऑपरेशन के लिए अधिकतम प्रतीक्षा समय निर्धारित करता है। यह स्थानांतरित करने के लिए पर्याप्त है, उदाहरण के लिए, HTTP हेडर X-Request-Deadline: 10s यह सुनिश्चित करने के लिए कि आपका अनुरोध 10 सेकंड के भीतर निष्पादित किया जाएगा या प्लेटफ़ॉर्म द्वारा कहीं अंदर मारा जाएगा, जिसके बाद हमें फिर से संपर्क किया जा सकता है, द्वारा निर्देशित। अनुरोध अग्रेषण नीति।

मंच प्रबंधन और स्वामित्व

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

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

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

अन्यथा, निगरानी, ​​प्रबंधन और संबंधित सेवाओं के लिए हमारे दृष्टिकोण उद्योग के लिए मानक हैं, मुझे यकीन नहीं है कि इन सेवाओं के एकीकरण का अगला विवरण एक पोस्ट में ध्यान देने योग्य है।

इस लेख में, मैं शायद हमारे भुगतान मंच की व्यवस्था कैसे की जाती है, इस बारे में समीक्षा पदों की श्रृंखला को समाप्त कर दूंगा।

मुझे लगता है कि चक्र काफी स्पष्ट हो गया है, मुझे कुछ लेख मिले हैं जो इस तरह के विस्तार से बड़े भुगतान प्रणालियों के आंतरिक रसोईघर में प्रकट होंगे।

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

इसलिए, इस सिद्धांत द्वारा निर्देशित, हमने हाल ही में मंच की स्थिति और हमारी सेवाओं के अपटाइम इतिहास को सार्वजनिक रूप से उपलब्ध कराया है। हमारे अपटाइम, अपडेट और क्रैश का संपूर्ण बाद का इतिहास अब सार्वजनिक और https://status.rbk.money/ पर उपलब्ध है।

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

हमारे साथ बने रहने के लिए धन्यवाद!

PS आपकी सुविधा के लिए, श्रृंखला के पिछले लेखों के लिए एक सूचक:

• परिचय और यह सब कैसे शुरू हुआ का विवरण ;
• माइक्रोसर्विसेस और बिजनेस प्लेटफॉर्म कॉन्फ़िगरेशन ;
• मंच के व्यापार तर्क प्रसंस्करण के कार्यान्वयन ।