हमारे गेटवे एपीआई निर्माण अनुभव

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

इसके लिए, एक एपीआई का उपयोग किया जाता है, जिसे गेटवे एपीआई के माध्यम से भागीदारों को जारी किया जाना चाहिए। हमने इस समस्या को हल कर दिया है। यह लेख विवरण प्रदान करेगा।

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

• पंजीकरण
• एपीआई कनेक्शन नियंत्रण
• निगरानी करना कि उपयोगकर्ता अंतिम प्रणाली का उपयोग कैसे करते हैं
• व्यापार संकेतकों का लेखा।

लेख में, हम गेटवे एपीआई बनाने के अपने अनुभव के बारे में बात करेंगे, जिसके दौरान हमने निम्नलिखित कार्यों को हल किया:

• उपयोगकर्ता प्रमाणीकरण
• उपयोगकर्ता प्राधिकरण
• मूल अनुरोध का संशोधन,
• अनुरोध करना
• प्रतिक्रिया के बाद प्रसंस्करण।

दो प्रकार के एपीआई प्रबंधन हैं:

1. मानक, जो निम्नानुसार काम करता है। कनेक्ट करने से पहले, उपयोगकर्ता संभावनाओं का परीक्षण करता है, फिर अपनी साइट पर भुगतान करता है और एम्बेड करता है। अधिकतर इसका उपयोग छोटे और मध्यम आकार के व्यवसायों में किया जाता है।

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

हमारा निर्णय

इस भाग में, हम गेटवे एपीआई बनाने के बारे में बात करेंगे।

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

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

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

किसी भी वेब सर्वर में एक अनुरोध प्रसंस्करण पाइपलाइन है। नगनेक्स के मामले में, ऐसा दिखता है:



( GitHub Lua Nginx से आरेख)

हमारा लक्ष्य इस समय इस पाइपलाइन में एकीकृत करना था जहां हम मूल अनुरोध को संशोधित कर सकते हैं।

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

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

नेगनेक्स कॉन्फ़िगरेशन (एप्लिकेशन के रूट के अनुरूप), जहां सभी कार्य किए जाते हैं, समझ में आता है। यहाँ ध्यान देने योग्य अंतिम निर्देश है - पोस्ट_एक्शन।

location /middleware { more_clear_input_headers Accept-Encoding; lua_need_request_body on; rewrite_by_lua_file 'middleware/rewrite.lua'; access_by_lua_file 'middleware/access.lua'; proxy_pass https://someurl.com; body_filter_by_lua_file 'middleware/body_filter.lua'; post_action /process_session; } 

विचार करें कि इस कॉन्फ़िगरेशन में क्या होता है:
more_clear_input_headers - निर्देश के बाद निर्दिष्ट हेडरों के मूल्य को साफ करता है।
lua_need_request_body - यह नियंत्रित करता है कि पुनर्लेखन / पहुँच / access_by_lua निर्देशों को निष्पादित करने से पहले मूल अनुरोध निकाय को पढ़ना है या नहीं। डिफ़ॉल्ट रूप से, nginx क्लाइंट रिक्वेस्ट बॉडी को नहीं पढ़ता है, और यदि आपको इसे एक्सेस करने की आवश्यकता है, तो यह निर्देश चालू होना चाहिए।
rewrite_by_lua_file - स्क्रिप्ट को पथ, जो अनुरोध को संशोधित करने के लिए तर्क का वर्णन करता है
access_by_lua_file - स्क्रिप्ट का पथ, जो उस तर्क का वर्णन करता है जो संसाधन तक पहुंच के लिए जांच करता है।
प्रॉक्सी_पास - url जिसमें अनुरोध सम्‍मिलित किया जाएगा।
body_filter_by_lua_file - स्क्रिप्ट का पथ, जो क्लाइंट को लौटने से पहले अनुरोध को फ़िल्टर करने के लिए तर्क का वर्णन करता है।
और अंत में, post_action एक आधिकारिक रूप से अनिर्दिष्ट निर्देश है जिसका उपयोग क्लाइंट को प्रतिक्रिया देने के बाद किसी अन्य क्रिया को करने के लिए किया जा सकता है।

अगला, हम क्रम में वर्णन करेंगे कि हमने अपनी समस्याओं को कैसे हल किया।

प्राधिकरण / प्रमाणीकरण और अनुरोध संशोधन

प्राधिकरण

हमने प्रमाणपत्र एक्सेस का उपयोग करके प्राधिकरण और प्रमाणीकरण का निर्माण किया। रूट सर्टिफिकेट है। ग्राहक का प्रत्येक नया ग्राहक अपना निजी प्रमाणपत्र बनाता है जिसके साथ वह एपीआई तक पहुंच बना सकता है। यह प्रमाणपत्र nginx सेटिंग्स सर्वर अनुभाग में कॉन्फ़िगर किया गया है।

 ssl on; ssl_certificate /usr/local/openresty/nginx/ssl/cert.pem; ssl_certificate_key /usr/local/openresty/nginx/ssl/cert.pem; ssl_client_certificate /usr/local/openresty/nginx/ssl/ca.crt; ssl_verify_client on; 

परिवर्तन

एक उचित सवाल उठ सकता है: अगर हम अचानक इसे सिस्टम से डिस्कनेक्ट करना चाहते हैं तो प्रमाणित क्लाइंट के साथ क्या करना है? अन्य सभी ग्राहकों के लिए प्रमाण पत्र पुनः जारी न करें।

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

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

ग्राहक डेटा के साथ काम करें

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

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

• डेटा तक त्वरित पहुंच
• विभिन्न नोड्स पर दोहराए गए डेटा के साथ कई नोड्स के क्लस्टर को व्यवस्थित करने की क्षमता।

हम सरलतम कैश डिलीवरी रणनीति के लिए गए:



अंतिम प्रणाली के साथ काम सत्र के ढांचे के भीतर होता है और अधिकतम संख्या पर सीमा होती है। यदि क्लाइंट ने सत्र को बंद नहीं किया, तो हमें यह करना होगा।

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

लुआ और .NET दोनों से हेज़ेलकास्ट तक पहुंच

हेज़लकास्ट के साथ काम करने के लिए लुआ पर कोई ग्राहक नहीं हैं, लेकिन हेज़ेलकास्ट में एक आरईएसटी एपीआई है, जिसे हमने उपयोग करने का फैसला किया है। .NET के लिए, एक क्लाइंट है जिसके द्वारा हमने .NET साइड पर Hazelcast डेटा एक्सेस करने की योजना बनाई है। लेकिन वहाँ यह था।



जब REST के माध्यम से डेटा की बचत होती है और .NET क्लाइंट के माध्यम से पुनर्प्राप्त की जाती है, तो विभिन्न धारावाहिक / डीसेरिएलाइज़र का उपयोग किया जाता है। इसलिए, REST के माध्यम से डेटा डालना असंभव है, लेकिन .NET क्लाइंट के माध्यम से प्राप्त करना और इसके विपरीत।

यदि आप रुचि रखते हैं, तो हम एक अलग लेख में इस समस्या के बारे में अधिक बात करेंगे। स्पोइलर - किन्नर पर।

लॉगिंग और मॉनिटरिंग

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

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

गेटवे एपीआई K8S में काम करता है, इसलिए हमने मौजूदा ओपन tcp पोर्ट फ्लुएंट में लॉग लिखने के लिए उसी उपप्रकार में धाराप्रवाह के साथ कंटेनर को जोड़ने का फैसला किया।

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

निष्कर्ष

कार्यान्वयन के लिए चुने गए दृष्टिकोण ने हमें केवल 2.5 महीनों में मुकाबला करने वाले पर्यावरण के लिए वास्तव में काम करने वाले उत्पाद देने की अनुमति दी।

यदि आप कभी ऐसी चीजें करते हैं, तो हम आपको सबसे पहले यह स्पष्ट रूप से समझने की सलाह देते हैं कि आप किस समस्या को हल कर रहे हैं और आपके पास कौन से संसाधन हैं। मौजूदा एपीआई प्रबंधन प्रणालियों के साथ एकीकरण की जटिलताओं से अवगत रहें।

अपने आप को समझें कि आप वास्तव में क्या विकसित करने जा रहे हैं - अनुरोध प्रसंस्करण के केवल व्यावसायिक तर्क, या, जैसा कि हमारे मामले में, पूरे प्रॉक्सी में हो सकता है। याद रखें कि आप जो कुछ भी स्वयं करते हैं उसे बाद में अच्छी तरह से जांच लेना चाहिए।