API गेटवे सिर्जना गर्ने हाम्रो अनुभव

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

यसको लागि, एउटा API प्रयोग गरिन्छ, जुन API गेटवे मार्फत साझेदारहरूलाई जारी गरिनुपर्छ। हामीले यो समस्या समाधान गरेका छौं। यस लेखमा हामी तपाईंलाई विवरण बताउनेछौं।

दिइएको: एक इकोसिस्टम र एक API पोर्टल एक इन्टरफेस संग जहाँ प्रयोगकर्ताहरू दर्ता छन्, जानकारी प्राप्त, आदि। हामीले सुविधाजनक र भरपर्दो API गेटवे बनाउनु पर्छ। प्रक्रियामा, हामीले उपलब्ध गराउन आवश्यक छ

• दर्ता,
• API जडान नियन्त्रण,
• प्रयोगकर्ताहरूले अन्त प्रणाली कसरी प्रयोग गर्छन् भनेर निगरानी गर्दै,
• व्यापार सूचकहरूको लागि लेखा।

लेखमा हामी API गेटवे सिर्जना गर्ने हाम्रो अनुभवको बारेमा कुरा गर्नेछौं, जसको क्रममा हामीले निम्न कार्यहरू समाधान गर्यौं:

• प्रयोगकर्ता प्रमाणीकरण,
• प्रयोगकर्ता प्राधिकरण,
• मौलिक अनुरोधको परिमार्जन,
• प्रोक्सी अनुरोध,
• प्रतिक्रिया पोस्ट प्रोसेसिंग।

त्यहाँ दुई प्रकारका API व्यवस्थापन छन्:

1. मानक, जुन निम्नानुसार काम गर्दछ। जडान गर्नु अघि, प्रयोगकर्ताले सुविधाहरू परीक्षण गर्दछ, त्यसपछि भुक्तानी गर्दछ र उसको साइटमा इम्बेड गर्दछ। प्रायः तिनीहरू साना र मध्यम आकारका व्यवसायहरूमा प्रयोग गरिन्छ।

2. ठूलो B2B API प्रबन्धन, जब कम्पनीले पहिलो पटक जडान गर्ने व्यापारिक निर्णय गर्छ, अनुबंधात्मक दायित्वको साथ कम्पनीको साझेदार बन्छ, र त्यसपछि API मा जडान हुन्छ। र सबै औपचारिकताहरू व्यवस्थित भएपछि, कम्पनीले परीक्षण पहुँच प्राप्त गर्दछ, परीक्षण पास गर्दछ र उत्पादनमा जान्छ। तर जडान गर्ने व्यवस्थापनको निर्णय बिना यो सम्भव छैन।

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

यस भागमा, हामी एपीआई गेटवे सिर्जना गर्ने बारे कुरा गर्नेछौं।

सिर्जना गरिएको API गेटवेका अन्तिम प्रयोगकर्ताहरू हाम्रा ग्राहकका साझेदार हुन्। हामीसँग पहिले नै ती प्रत्येकको लागि आवश्यक सम्झौताहरू छन्। हामीले गेटवेमा प्रदान गरिएको पहुँच चिन्ह लगाएर मात्र कार्यक्षमता विस्तार गर्न आवश्यक हुनेछ। तदनुसार, एक नियन्त्रित जडान र व्यवस्थापन प्रक्रिया आवश्यक छ।

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

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

प्रत्येक वेब सर्भरमा अनुरोध प्रशोधन पाइपलाइन छ। Nginx को मामला मा, यो यस्तो देखिन्छ:

(बाट रेखाचित्र GitHub Lua Nginx)

हाम्रो लक्ष्य यस पाइपलाइनमा एक बिन्दुमा फिट हुनु थियो जहाँ हामी मूल अनुरोध परिमार्जन गर्न सक्छौं।

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

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

nginx कन्फिगरेसन (एप्लिकेसनको मार्गको समानता), जहाँ सबै काम गरिन्छ, धेरै बुझ्न योग्य छ। यहाँ उल्लेखनीय छ अन्तिम निर्देशन - post_action।

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 - rewrite/access/access_by_lua निर्देशनहरू कार्यान्वयन गर्नु अघि मूल अनुरोध मुख्य भाग पढ्नुपर्छ वा होइन भनेर नियन्त्रण गर्दछ। पूर्वनिर्धारित रूपमा, nginx ले क्लाइन्ट अनुरोधको मुख्य भाग पढ्दैन, र यदि तपाइँ यसलाई पहुँच गर्न आवश्यक छ भने, त्यसपछि यो निर्देशन सक्रिय गर्न सेट गर्नुपर्छ।
rewrite_by_lua_file - स्क्रिप्टको बाटो, जसले अनुरोध परिमार्जनको लागि तर्क वर्णन गर्दछ
access_by_lua_file — स्क्रिप्टको बाटो, जसले स्रोतमा पहुँचको लागि जाँच गर्ने तर्कलाई वर्णन गर्दछ।
proxy_pass - url जसमा अनुरोध प्रोक्सी गरिनेछ।
body_filter_by_lua_file — स्क्रिप्टको बाटो, जसले क्लाइन्टलाई फिर्ता गर्नु अघि अनुरोध फिल्टर गर्ने तर्कको वर्णन गर्दछ।
र अन्तमा post_action - एक आधिकारिक रूपमा कागजात नभएको निर्देशन जसको साथ तपाईले ग्राहकलाई प्रतिक्रिया दिए पछि केहि अन्य कार्यहरू गर्न सक्नुहुन्छ।

अर्को, हामी क्रमबद्ध रूपमा वर्णन गर्नेछौं कि हामीले हाम्रा समस्याहरू कसरी समाधान गर्यौं।

प्राधिकरण/प्रमाणीकरण र अनुरोध परिमार्जन

प्राधिकरण

हामीले प्रमाणपत्र पहुँच प्रयोग गरेर प्राधिकरण र प्रमाणीकरण निर्माण गर्यौं। त्यहाँ रूट प्रमाणपत्र छ। ग्राहकको प्रत्येक नयाँ ग्राहकले उसको व्यक्तिगत प्रमाणपत्र उत्पन्न गर्दछ, जसको साथ उसले API पहुँच गर्न सक्छ। यो प्रमाणपत्र 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 प्रयोग गर्ने निर्णय गर्यौं। त्यसपछि, केही अन्तरालहरूमा, हामी खुला सत्रहरूको जीवनको अधिकार जाँच गर्छौं र सडेकाहरूलाई बन्द गर्छौं।

Lua र .NET दुबैबाट Hazelcast पहुँच गर्दै

Hazelcast सँग काम गर्न कुनै लुआ ग्राहकहरू छैनन्, तर Hazelcast सँग REST API छ, जुन हामीले प्रयोग गर्ने निर्णय गर्यौं। .NET को लागि त्यहाँ छ ग्राहक, जसको माध्यमबाट हामीले .NET पक्षमा Hazelcast डाटा पहुँच गर्ने योजना बनायौं। तर त्यहाँ थिएन।

REST मार्फत डाटा भण्डारण गर्दा र .NET क्लाइन्ट मार्फत डाटा पुन: प्राप्त गर्दा, विभिन्न क्रमिक र deserializers प्रयोग गरिन्छ। त्यसकारण, REST मार्फत डाटा राख्न असम्भव छ, तर यसलाई .NET क्लाइन्ट मार्फत प्राप्त गर्नुहोस् र यसको विपरित।

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

लगिङ र निगरानी

.NET मार्फत लग इन गर्नको लागि हाम्रो कर्पोरेट मानक Serilog हो, सबै लगहरू Elasticsearch मा समाप्त हुन्छन्, र हामी तिनीहरूलाई Kibana मार्फत विश्लेषण गर्छौं। म यस मामला मा यस्तै केहि गर्न चाहन्छु। एक मात्र ग्राहक लुआमा इलास्टिकसँग काम गर्न, जुन फेला पर्यो, पहिलो आवश्यकतामा तोडियो। र हामीले Fluentd प्रयोग गर्यौं।

प्रवाहित - अनुप्रयोग लगिङ को एकल तह प्रदान गर्न को लागी खुला स्रोत समाधान। तपाईंलाई अनुप्रयोगको विभिन्न तहहरूबाट लगहरू सङ्कलन गर्न, र त्यसपछि तिनीहरूलाई एउटै स्रोतमा प्रसारण गर्न अनुमति दिन्छ।

API गेटवे K8S मा काम गर्दछ, त्यसैले हामीले अवस्थित खुला tcp पोर्ट fluentd मा लगहरू लेख्नको लागि समान पोडीमा fluentd भएको कन्टेनर थप्ने निर्णय गर्यौं।

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

निष्कर्षमा

कार्यान्वयनको लागि छनौट गरिएको दृष्टिकोणले हामीलाई 2.5 महिनामा लडाई वातावरणमा वास्तवमै काम गर्ने उत्पादन प्रदान गर्न अनुमति दियो।

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

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

स्रोत: www.habr.com