हुड के तहत RBKmoney भुगतान - भुगतान मंच का तर्क

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

अवलोकन तर्क और सामान्य दृष्टिकोण

सामान्य तौर पर, भुगतान के लिए जिम्मेदार प्रसंस्करण के उस भाग के मूल तत्वों की योजना इस तरह दिखती है।

तार्किक रूप से अपने अंदर, हम जिम्मेदारी के क्षेत्रों को 3 डोमेन में विभाजित करते हैं:

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

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

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

उच्च उपलब्धता सुनिश्चित करने के लिए, हम कई उदाहरणों में सेवाएं प्रदान करते हैं, आमतौर पर 3 से 5 तक।

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

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

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

केवी-योजना को लागू करने के लिए यह बहुत महंगा है, हम PostgeSQL डेटाबेस को प्रतिकृति, या यहां तक ​​कि एकल-मोड समाधानों के साथ उपयोग करते हैं, क्योंकि हम हमेशा मशीनगन के माध्यम से ऑनलाइन भाग से विफलता की स्थिति में आवश्यक घटनाओं को अपलोड कर सकते हैं।

आरेख में माइक्रोसर्विस का रंग अलग होना उन भाषाओं को इंगित करता है जिनमें वे लिखे गए हैं - हल्का हरा - ये जावा अनुप्रयोग हैं, हल्का नीला - एर्लैंग।

सभी सेवाएं डॉकटर कंटेनरों में काम करती हैं, जो CI बिल्ड कलाकृतियां हैं और स्थानीय डॉकटर रजिस्ट्री में स्थित हैं। साल्टस्टैक उत्पादन पर सेवाओं को प्रदर्शित करता है, जिसका विन्यास निजी गितुब भंडार में है।

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

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

बाहरी दुनिया के साथ बातचीत

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

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

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

यह हमें घड़ी के आसपास लगभग तैनात करने की अनुमति देता है, जिसमें शुक्रवार की शाम भी शामिल है, बिना किसी भय के कुछ निष्क्रिय रोल करें, या जल्दी से वापस रोल करें, एक बदलाव के साथ एक साधारण वापसी करें, जब तक कोई भी ध्यान नहीं देता।

प्लेटफ़ॉर्म पंजीकरण और सार्वजनिक एपीआई

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

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

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

JWT की एक विशेषता यह है कि यह संरचना सर्वर की निजी कुंजी द्वारा हस्ताक्षरित है; तदनुसार, भूमिकाओं और इसकी अन्य वस्तुओं की सूची को अधिकृत करने के लिए, हमें प्राधिकरण सेवा तक पहुंचने की आवश्यकता नहीं है, प्रक्रिया पूरी तरह से डिकोड हो गई है। स्टार्टअप पर CAPI सेवाएँ Keycloak सार्वजनिक कुंजी को पढ़ती हैं और सार्वजनिक API विधियों में कॉल को अधिकृत करने के लिए इसका उपयोग करती हैं।

जैसा कि हम प्रमुख प्रत्यावर्तन योजना के साथ आए थे, कहानी अलग है और अपने स्वयं के पद के योग्य है।

तो, हमें JWT प्राप्त हुआ है, हम इसे प्रमाणीकरण के लिए उपयोग कर सकते हैं। यहाँ माइक्रोसॉफ़्ट कॉमन एपीआई का समूह सीएपीआई और सीएपीआई-डीएसएस के रूप में संकेतित डायग्राम पर आता है, जो निम्नलिखित कार्यों को कार्यान्वित करता है:

• प्राप्त संदेशों का प्राधिकरण। प्रत्येक सार्वजनिक एपीआई कॉल एक प्राधिकरण से पहले होता है: वाहक {JWT} HTTP हेडर। कॉमन एपीआई समूह की सेवाएं प्राधिकरण की मौजूदा सार्वजनिक कुंजी के साथ हस्ताक्षरित डेटा को सत्यापित करने के लिए इसका उपयोग करती हैं;
• प्राप्त आंकड़ों का सत्यापन। चूंकि स्कीमा को एक ओपनएपीआई विनिर्देश के रूप में वर्णित किया जाता है, जिसे स्वैगर के रूप में भी जाना जाता है, डेटा सत्यापन बहुत आसान हो सकता है और डेटा स्ट्रीम में नियंत्रण आदेश प्राप्त करने की बहुत कम संभावना है। इससे समग्र रूप से सेवा की सुरक्षा पर सकारात्मक प्रभाव पड़ता है;
• आंतरिक REST JSON से आंतरिक बाइनरी थिफ्ट के लिए डेटा प्रारूपों का अनुवाद;
• एक अद्वितीय ट्रेस_आईडी जैसे डेटा के साथ ट्रांसपोर्ट बाइंडिंग को तैयार करना और प्लेटफॉर्म के अंदर घटना को एक ऐसी सेवा में पारित करना जो व्यापार तर्क का प्रबंधन करता है और जानता है कि उदाहरण के लिए, भुगतान क्या है।

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

PCI-DSS और ओपन कार्ड डेटा

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

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

बिलिंग और टोकनेशन

इसलिए, हम भुगतान शुरू करना चाहते हैं और भुगतानकर्ता के कार्ड से पैसे लिखना चाहते हैं।

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

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

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

यह रूपांतरण और उपयोगकर्ता अनुभव पर सकारात्मक प्रभाव डालता है।

चालान स्टेट मशीन

प्लेटफॉर्म के अंदर, यह श्रृंखला निम्नलिखित मार्ग के साथ बातचीत में बदल जाती है:

• आपके ब्राउज़र में सामग्री देने से पहले, हमारे क्लाइंट-मर्चेंट ने हमारे प्लेटफ़ॉर्म के साथ एकीकृत किया, हमारे साथ पंजीकृत किया और प्राधिकरण के लिए एक JWT प्राप्त किया;
• अपने बैकएंड से, व्यापारी ने createInvoice () विधि को बुलाया, अर्थात , उसने हमारे प्लेटफॉर्म में भुगतान के लिए एक चालान बनाया। वास्तव में, व्यापारी बैकएंड ने हमारे समापन बिंदु पर निम्नलिखित सामग्री का HTTP POST अनुरोध भेजा:

curl -X POST \ https://api.rbk.money/v2/processing/invoices \ -H 'Authorization: Bearer {JWT}' \ -H 'Content-Type: application/json; charset=utf-8' \ -H 'X-Request-ID: 1554417367' \ -H 'cache-control: no-cache' \ -d '{ "shopID": "TEST", "dueDate": "2019-03-28T17:41:32.569Z", "amount": 6000, "currency": "RUB", "product": "Order num 12345", "description": "Delicious meals", "cart": [ { "price": 5000, "product": "Sandwich", "quantity": 1, "taxMode": { "rate": "10%", "type": "InvoiceLineTaxVAT" } }, { "price": 1000, "product": "Cola", "quantity": 1, "taxMode": { "rate": "18%", "type": "InvoiceLineTaxVAT" } } ], "metadata": { "order_id": "Internal order num 13123298761" } }' 

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

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

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

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

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

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

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

वैसे, मशीनगन स्रोत कोड हमारे सार्वजनिक भंडार में अपाचे 2.0 लाइसेंस के तहत खुले हैं। हमें उम्मीद है कि यह सेवा समुदाय के लिए उपयोग की जा सकती है।

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

बाहरी ग्राहकों के प्राधिकरण की बारीकियों

एक सफल बचाने के बाद, हेलगेट डेटा को CAPI में लौटाता है, यह बाइनरी ट्रिफ्ट संरचना को एक खूबसूरती से डिज़ाइन किए गए JSON में परिवर्तित करता है, जो व्यापारी बैकएंड पर भेजे जाने के लिए तैयार है:

 { "invoice": { "amount": 6000, "cart": [ { "cost": 5000, "price": 5000, "product": "Sandwich", "quantity": 1, "taxMode": { "rate": "10%", "type": "InvoiceLineTaxVAT" } }, { "cost": 1000, "price": 1000, "product": "Cola", "quantity": 1, "taxMode": { "rate": "18%", "type": "InvoiceLineTaxVAT" } } ], "createdAt": "2019-04-04T23:00:31.565518Z", "currency": "RUB", "description": "Delicious meals", "dueDate": "2019-04-05T00:00:30.889000Z", "id": "18xtygvzFaa", "metadata": { "order_id": "Internal order num 13123298761" }, "product": "Order num 12345", "shopID": "TEST", "status": "unpaid" }, "invoiceAccessToken": { "payload": "{JWT}" } } 

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

समान JWT के अंदर वर्णित भूमिकाओं का एक उदाहरण:

  "resource_access": { "common-api": { "roles": [ "invoices.18xtygvzFaa.payments:read", "invoices.18xtygvzFaa.payments:write", "invoices.18xtygvzFaa:read", "payment_resources:write" ] } } 

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

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

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

टोकनकरण और कार्ड डेटा

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

यह वह जगह है जहाँ टोकन जेएस पुस्तकालय खेलने में आता है। जब आप इनपुट फ़ील्ड में अपना कार्ड दर्ज करते हैं और "पे" पर क्लिक करते हैं, तो यह इस डेटा को इंटरसेप्ट करता है और एसिंक्रोनस रूप से हमें createPaymentResource () विधि से कॉल करके प्रोसेसिंग के लिए भेजता है।

यह अनुरोध व्यक्तिगत CAPI-DSS अनुप्रयोगों के लिए संतुलित है, जो अनुरोध को भी अधिकृत करता है, केवल चालान JWT की जाँच करके, डेटा को मान्य करता है और कार्ड डेटा स्टोरेज सेवा में भेज देता है। आरेख में, इसे सीडीएस - कार्ड डेटा स्टोरेज के रूप में इंगित किया गया है।

इस सेवा के मुख्य उद्देश्य:

• एक इनपुट पर संवेदनशील डेटा प्राप्त करते हैं, हमारे मामले में - आपके कार्ड का डेटा;
• डेटा एन्क्रिप्शन कुंजी के साथ इस डेटा को एन्क्रिप्ट करें;
• कुंजी के रूप में उपयोग किए जाने वाले कुछ यादृच्छिक मूल्य उत्पन्न करें;
• इस कुंजी पर एन्क्रिप्टेड डेटा को अपने Riak क्लस्टर में सहेजें;
• CAPI-DSS सेवा के लिए भुगतान डेटा टोकन के रूप में कुंजी लौटाएं।

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

यह पैर में खुद को गोली मारने की संभावना से सुरक्षा के बिना नहीं था। एक गैर-शून्य संभावना है कि एक निजी JWT, जिसे बैकएंड से अनुरोधों को अधिकृत करने के लिए डिज़ाइन किया गया है, वेब पर क्लाइंट के ब्राउज़र में प्रकाशित किया जाएगा। इसे रोकने के लिए, हमने सुरक्षा में बनाया है - आप केवल इनवॉइस प्राधिकरण कुंजी के साथ createPaymentResource () विधि को कॉल कर सकते हैं। जब एक निजी JWT प्लेटफ़ॉर्म का उपयोग करने का प्रयास किया जाता है तो वह HTTP / 401 त्रुटि लौटाएगा।

टोकनकरण अनुरोध को पूरा करने के बाद, टोकनिनेटर चेकआउट को प्राप्त टोकन लौटाता है और इस पर अपना काम पूरा करता है।

भुगतान मशीन व्यवसाय प्रक्रिया

चेकआउट भुगतान प्रक्रिया शुरू करता है, अर्थात्, यह createPayment () विधि को कॉल करता है, पहले प्राप्त कार्ड टोकन को एक तर्क के रूप में पारित करता है और मतदान की घटनाओं की प्रक्रिया शुरू करता है, वास्तव में, getInvoiceEvents () एपीआई विधि को एक बार कॉल करता है।

सीएपीआई के माध्यम से ये अनुरोध हेलगेट में आते हैं, जो कार्ड डेटा का उपयोग किए बिना भुगतान व्यवसाय प्रक्रिया को लागू करना शुरू करता है:

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

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

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

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

भुगतान व्यवसाय प्रक्रिया के मर्चेंट द्वारा निर्दिष्ट createPayment () कॉल के आधार पर, HG बाहरी API से प्राधिकरण कैप्चर विधि से कॉल की अपेक्षा करता है, अर्थात, आपके कार्ड से पैसे की वापसी की पुष्टि करता है, या यह तुरंत अपने दम पर करता है, यदि व्यापारी ने स्कीम को चुना है। एकल-चरण भुगतान।

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

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

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

इस प्रकार, आप मुद्रा जोखिमों को सहन करते हैं, जो आपके पक्ष में और आपके खिलाफ हो सकता है, खासकर मुद्रा बाजार में उच्च अस्थिरता की स्थिति में।

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

यह भी ध्यान देने योग्य है कि इनवॉइस मशीन की स्थिति में कोई भी परिवर्तन, जिसमें भुगतान प्रक्रिया शामिल है, को मशीनगंज में हेलगेट द्वारा दर्ज किया जाता है, डेटा की दृढ़ता सुनिश्चित करता है और नए ईवेंट के साथ इनवॉइस को समृद्ध करता है।

भुगतान मशीन और यूआई का राज्य सिंक्रनाइज़ेशन

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

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

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

ऑफ़लाइन क्षेत्र में घटनाओं की प्रतिकृति

मशीन नियंत्रण इंटरफेस के साथ, मशीनगन प्लेटफ़ॉर्म के अन्य, कम ऑनलाइन कार्यों के लिए घटनाओं के प्रवाह को समाप्त करने के लिए जिम्मेदार एक सेवा को लागू करती है।

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

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

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

विशिष्ट ऑफ़लाइन क्षेत्र अनुप्रयोग टेम्पलेट

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

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

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

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

खैर, नमक स्टैक के बारे में अगली बार about ¯\_(ツ)_/¯