किसी भी NodeJS ऐप को सर्वर रहित कैसे बनाया जाए

मुझे उम्मीद है कि आप सर्वरलेस से उतना ही प्यार करेंगे जितना मैं करता हूं क्योंकि यह उस विषय पर एक और पोस्ट है।

अब, यदि हम एक साधारण सर्वर रहित REST API के बारे में बात कर रहे हैं, तो आपका सेटअप AWS: Lambda + API गेटवे पर काफी स्पष्ट है।

लेकिन अन्य (माइक्रो) सेवाओं के बारे में कैसे आपके बैकएंड में हो सकता है? आप जानते हैं, एक एकल अखंड AWS लैम्बडा फ़ंक्शन में अपने सभी एप्लिकेशन कोड को डालना सबसे अच्छा विचार नहीं है।

चुनौती

हम सर्वर मॉड्यूल के रूप में एप्लिकेशन मॉड्यूल को आसानी से तैनात करना चाहते हैं, जिसमें एक-दूसरे के साथ संवाद करने की भी आवश्यकता होती है। अधिमानतः, सेवाओं के बीच संचार को कुछ प्रकार के एसीएल द्वारा विनियमित किया जाना चाहिए।

प्रयास 1. एपीआई गेटवे

यह पहला विचार है जो मेरे पास था जब मैं समस्या को हल करने की कोशिश कर रहा था: बस एपीआई गेटवे के माध्यम से सभी माइक्रोसर्विस को उजागर करें। समस्या यह है ... निर्मित एपीआई सार्वजनिक हैं।

यह समस्या क्यों है? उदाहरण के लिए, हम यह नहीं चाहते हैं कि किसी तरह की प्राधिकरण का उपयोग करके प्रतिबंधित होने पर भी पूरी दुनिया के सामने एक बिलिंग सेवा उपलब्ध हो।

ठीक है, आप एपीआई को निजी बना सकते हैं, लेकिन सुरक्षा नीतियां बहुत सीमित हैं:

आप एपीआई गेटवे संसाधन नीतियों का उपयोग करके अपने एपीआई को सुरक्षित रूप से लागू कर सकते हैं:
* उपयोगकर्ता एक निर्दिष्ट AWS खाते से
* निर्दिष्ट स्रोत आईपी पता पर्वतमाला या CIDR ब्लॉक
* निर्दिष्ट आभासी निजी बादल (VPC) या VPC समापन बिंदु (किसी भी खाते में)

यह ऐसी सेवाओं के बीच संचार को नियंत्रित करने के लिए काफी परेशान करता है। इसे करने का एकमात्र तरीका सेवाओं को अलग-अलग VPC में डालकर, बहुत अधिक काम है।

प्रयास किया हुआ 2. लंबोदर

हम हर माइक्रोसेव को एक अलग AWS लैम्ब्डा में क्यों नहीं डालते हैं? क्या इससे समस्या हल हो जाएगी?

हां, वास्तव में यह एक सर्वर रहित माइक्रो सर्विस होगा, और आप सेवाओं के बीच पहुंच को ट्यून करने के लिए IAM नीतियों का उपयोग कर पाएंगे, लेकिन ... यह "आसान" नहीं है।

मुझे पता है कि आजकल यह बहुत सामान्य है कि आपकी तैनाती इकाई के रूप में एक छोटा कार्य किया जाए। और उस स्थिति में जब आपकी सेवा में 1 से अधिक समापन बिंदु / विधि / कार्य होते हैं, तो इसे कई लंबोदा के रूप में तैनात करना ठीक माना जाता है।

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

प्रयास 3. मोटा लम्बा

क्या हम वास्तव में सिंगल लैम्बडा (एपीआई गेटवे का उपयोग किए बिना,) के रूप में एंडपॉइंट का एक सेट तैनात कर सकते हैं?

यदि हम ऐसा कर सकते हैं, तो हमें पिछले विकल्प के सभी लाभ मिलेंगे, लेकिन हम अपनी तैनाती इकाइयों की ग्रैन्युलैरिटी भी चुन सकेंगे।

जिस तरह से मैं चाहता हूं कि यह निम्नलिखित है: प्रत्येक तैनाती योग्य सेवा को विधियों के साथ एक साधारण सा पुराना पुराना जेएस ऑब्जेक्ट होना चाहिए। यह आपकी वस्तु और AWS लैम्ब्डा के बीच गोंद कोड की कुछ पंक्तियों को जोड़कर प्राप्त करने के लिए काफी तुच्छ है।

यहाँ इसका कार्यान्वयन है: aws-rpc। यह नोडज मॉड्यूल लैम्बडाहैंडलर फ़ंक्शन को उजागर करता है, जहां आप बस एक ऑब्जेक्ट पास करते हैं, और यह स्वचालित रूप से किसी को भी उजागर करता है जो लैम्बडा तक पहुंचने में सक्षम है:

'aws-rpc' से आयात {lambdaHandler};
आयात {TestServiceImpl} से './TestServiceImpl';
// यह आपकी परिनियोजन इकाई है
// यह वही है जो आप लैम्बडा के हैंडलर फ़ंक्शन के रूप में निर्दिष्ट करते हैं
निर्यात कांस्ट हैंडलर = lambdaHandler (नया TestServiceImpl ());

अब, आप केवल "हैंडलर" को AWS लाम्बा के रूप में तैनात कर सकते हैं। यहां बताया गया है कि आप इसके तरीके कैसे अपनाते हैं:

आयात {TestService} './TestService' से;
const client = wait createClient  ("लेम्बडानेम", "टेस्ट");
कंसोल.लॉग (ग्राहक की प्रतीक्षा करें ।est ());

कृपया ध्यान दें, कि क्लाइंट स्टब ऑब्जेक्ट के लिए विधियाँ उत्पन्न करने में सक्षम होने के लिए, आपको क्लीक करने के लिए सभी विधि नामों को पास करना होगा, जैसा कि हमने उदाहरण में किया था।

इसकी आवश्यकता है क्योंकि JS के पास टाइपस्क्रिप्ट इंटरफेस के बारे में कोई रनटाइम जानकारी नहीं है। मैं इसे अमूर्त कक्षाओं का उपयोग करके लागू कर सकता था, लेकिन मैं इसे ツ \ _ (it) _ / ¯ पसंद नहीं करता।

बोनस! आप इसे स्थानीय स्तर पर चला सकते हैं!

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

सारांश

यह उन सेवाओं में खो जाना बहुत आसान है, जो क्लाउड प्रदाता प्रदान करते हैं, और आपके बुनियादी ढांचे को खत्म कर देते हैं।

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

अगर आपको यह विषय पसंद आया है, तो इन्हें भी देखें:

  • आपको सबसे अच्छा सर्वर रहित आर्किटेक्चर बनाने का तरीका सीखना होगा
  • नि: शुल्क सर्वर रहित सीआई / सीडी पाइपलाइन कैसे बनाएं: 3 आसान उदाहरण
  • कैसे आसानी से क्षेत्र भर में DynamoDB पुन: पेश करने के लिए
  • मल्टीगर्ल एप्लीकेशन कैसे करें (और पे जीरो)
  • किसी भी जावा वेब ऐप को सर्वर रहित बनाएं

टिप्पणियाँ, पसंद और शेयर बहुत सराहना की है। चीयर्स!