बैकएंड आर्किटेक्चर से पता चलता है कि आपके वेब ऐप्लिकेशन का बैकएंड कैसे स्ट्रक्चर किया गया है. बैकएंड आर्किटेक्चर यह तय करता है कि ऐप्लिकेशन के कुछ हिस्से, आने वाले अनुरोधों को प्रोसेस करने और रिस्पॉन्स तैयार करने के लिए, कैसे एक-दूसरे से कम्यूनिकेट करते हैं. वेब ऐप्लिकेशन बनाते समय, अपनी खास ज़रूरतों और चीज़ों के आधार पर बैकएंड आर्किटेक्चर चुनें. इनमें लागत (मौजूदा और बड़े पैमाने पर दोनों), आपके ऐप्लिकेशन की जटिलता, लक्ष्यों को बढ़ाने, और आपकी टीम की विशेषज्ञता शामिल है.
खास तौर पर ई-कॉमर्स, अखबारों या ब्लॉग जैसे कॉन्टेंट पर आधारित वेब ऐप्लिकेशन के लिए, ज़रूरी शर्तों में आपके डेटा और उसकी परफ़ॉर्मेंस का लगातार एक जैसा होना शामिल है. खास तौर पर, जब आपका ऐप्लिकेशन दुनिया भर में लोकप्रिय हो रहा है और ज़्यादा लोगों तक पहुंच रहा है. कॉन्टेंट पर आधारित वेब ऐप्लिकेशन के लिए, आपके ऐप्लिकेशन में इस्तेमाल किया जाने वाला डेटा स्टोरेज भी बहुत ज़रूरी होता है. साथ ही, डेटा स्टोरेज गाइड में इसके बारे में ज़्यादा जानकारी दी गई है. अपने ऐप्लिकेशन की परफ़ॉर्मेंस को ऑप्टिमाइज़ करने के लिए, ऐप्लिकेशन के सामान्य आर्किटेक्चर के अलावा, अपने कॉन्टेंट को होस्ट करना, उसे होस्ट करना, और उसे ऐक्सेस करने लायक बनाना बहुत ज़रूरी है. होस्टिंग गाइड में, होस्टिंग की सही रणनीति चुनने और ऐप्लिकेशन को ऑप्टिमाइज़ करने के बारे में ज़्यादा जानें.
अगर आपके पास किसी वेब ऐप्लिकेशन का मौजूदा बैकएंड है, तो अपने मौजूदा आर्किटेक्चर की सीमाओं पर विचार करें. उदाहरण के लिए, जब आपका ऐप्लिकेशन बढ़ता है और उसकी परफ़ॉर्मेंस और विश्वसनीयता में बढ़ोतरी होती है, तो यह देखें कि क्या आपके ऐप्लिकेशन के कुछ हिस्सों को रीफ़ैक्टर किया जाना चाहिए या उन्हें किसी ऐसे आर्किटेक्चर पर ले जाना चाहिए जो बढ़ी हुई स्केलिंग के हिसाब से सही हो. उदाहरण के लिए, हाइब्रिड (या मल्टीक्लाउड) आर्किटेक्चर की मदद से कुछ वर्कलोड को पूरी तरह से अपग्रेड करने से पहले, क्लाउड पर ट्रांसफ़र किया जा सकता है. ऐसे माइग्रेशन में लगने वाली लागत, समय, और जोखिम को ध्यान में रखना भी ज़रूरी है.
मोनोलिथिक आर्किटेक्चर
मोनोलिथिक आर्किटेक्चर का एक यूनिफ़ाइड स्ट्रक्चर होता है. इसमें ऐप्लिकेशन के सभी कॉम्पोनेंट, एक ही कोड बेस में अच्छी तरह से इंटिग्रेट होते हैं. पूरा ऐप्लिकेशन, पूरी तरह से एक ही इकाई में बनाया गया है. मोनोलिथिक आर्किटेक्चर कई स्तर वाला है, जहां ऐप्लिकेशन की अलग-अलग लेयर खास काम पूरे करती हैं.
स्ट्रक्चरल लेयर
- यूज़र इंटरफ़ेस (यूआई) जिसमें ऐप्लिकेशन की सुविधाएं दिखाने के लिए कॉम्पोनेंट शामिल होते हैं. यह आम तौर पर वेब पर आधारित या डेस्कटॉप ऐप्लिकेशन होता है, जो उपयोगकर्ताओं से इंटरैक्ट करता है.
- ऐप्लिकेशन लॉजिक वह जगह है जहां मुख्य फ़ंक्शन मौजूद होता है.कोडबेस के इस हिस्से में नियम, कैलकुलेशन, और कार्रवाइयां शामिल होती हैं, जिनसे पता चलता है कि ऐप्लिकेशन कैसे काम करेगा.
- डेटा ऐक्सेस लेयर में, डेटा को पढ़ने और लिखने के साथ-साथ ऐप्लिकेशन के डेटा स्ट्रक्चर और डेटाबेस स्कीमा के बीच अनुवाद करने के लिए, फ़ंक्शन होते हैं. यह लेयर, ऐप्लिकेशन के डेटाबेस या डेटा स्टोरेज से इंटरैक्ट करने के लिए ज़िम्मेदार होती है.
- डेटाबेस वह जगह है, जहां ऐप्लिकेशन अपना डेटा सेव करता है. आम तौर पर, एक ही डेटाबेस होता है, जिसमें ऐप्लिकेशन का सारा डेटा स्टोर होता है. इसमें उपयोगकर्ता का डेटा, कॉन्फ़िगरेशन, और अन्य जानकारी शामिल होती है.
- मिडलवेयर कॉम्पोनेंट, पुष्टि करने, अनुरोध को रूट करने, और डेटा की पुष्टि करने जैसे कामों को हैंडल करते हैं. ये कॉम्पोनेंट, डेटा के फ़्लो और अनुरोधों को मैनेज करने में मदद करते हैं.
- कुछ मोनोलिथिक ऐप्लिकेशन में बाहरी सेवाओं या एपीआई के साथ इंटिग्रेशन पॉइंट होते हैं. इन बिंदुओं की मदद से ऐप्लिकेशन, तीसरे पक्ष की सेवाओं, डेटा सोर्स या अन्य सिस्टम से इंटरैक्ट कर सकता है.
आम तौर पर, स्ट्रक्चरल लेयर एक कोडबेस का हिस्सा होती हैं. इस कोड बेस में पूरा ऐप्लिकेशन होता है. आम तौर पर, इसे डायरेक्ट्री, मॉड्यूल, और क्लास में व्यवस्थित किया जाता है. ऐप्लिकेशन बनाने और उसका रखरखाव करने के लिए डेवलपर, कोड बेस के अलग-अलग हिस्सों पर काम करते हैं. हालांकि, आम तौर पर पूरे ऐप्लिकेशन को एक ही यूनिट के तौर पर डिप्लॉय किया जाता है. जब अपडेट या बदलाव किए जाते हैं, तो पूरे ऐप्लिकेशन को फिर से डिप्लॉय किया जाता है.
संभावित चुनौतियां
- मोनोलिथिक ऐप्लिकेशन में तरक्की होने के साथ-साथ, कोडबेस जटिल होता जाता है और उसे बनाए रखना मुश्किल होता जाता है. इससे, डेवलपमेंट साइकल में ज़्यादा समय लग सकता है और पूरे कोडबेस को समझने में मुश्किल हो सकती है.
- किसी मोनोलिथिक ऐप्लिकेशन में बदलाव लागू करना जोखिम भरा हो सकता है, क्योंकि कोड के एक हिस्से में किए गए बदलाव अनजाने में ऐप्लिकेशन के दूसरे हिस्सों पर असर डाल सकते हैं. इससे डिप्लॉयमेंट की प्रोसेस लंबी और गड़बड़ी हो सकती है.
- मोनोलिथिक ऐप्लिकेशन का इस्तेमाल करना मुश्किल हो सकता है, क्योंकि उन्हें एक ही यूनिट के तौर पर इस्तेमाल किया जाता है. आपको पूरे ऐप्लिकेशन का दायरा बढ़ाना होगा, भले ही सिर्फ़ एक कॉम्पोनेंट की मांग में बढ़ोतरी हुई हो.
- मोनोलिथिक ऐप्लिकेशन अक्सर एक ही टेक्नोलॉजी स्टैक या प्रोग्रामिंग लैंग्वेज का इस्तेमाल करते हैं. इसलिए, हो सकता है कि ऐप्लिकेशन में किसी खास काम के लिए सबसे अच्छे टूल का इस्तेमाल करने की आपकी क्षमता सीमित हो.
- मांग कम होने के दौरान भी, मोनोलिथिक ऐप्लिकेशन को इस्तेमाल करने के लिए बहुत ज़्यादा संसाधनों की ज़रूरत होती है. जैसे-जैसे आवेदन की उम्र बढ़ती जाती है, वैसे-वैसे रखरखाव का खर्च भी बढ़ता जाता है. ऐसा इसलिए होता है, क्योंकि बिना किसी रिग्रेशन के, ऐप्लिकेशन को अपडेट करना और उसे पैच करना मुश्किल हो जाता है.
- एक ही तरह के ऐप्लिकेशन पर काम करने वाली डेवलपमेंट टीमें अक्सर पूरे ऐप्लिकेशन पर ही व्यवस्थित होती हैं. इससे बड़ी टीमें बनती हैं और टीम के सदस्यों का तालमेल ज़्यादा पेचीदा होता है.
सुझाया गया इस्तेमाल
मोनोलिथिक आर्किटेक्चर तब काम आता है, जब किसी ऐप्लिकेशन की शर्तें सामान्य हों और उसे डेवलप करने वाली टीम छोटी हो. जैसे-जैसे ऐप्लिकेशन जटिल होता जाता है और बड़े पैमाने पर बढ़ता है, या जब ऐप्लिकेशन के अलग-अलग हिस्सों के लिए अलग-अलग टेक्नोलॉजी या डिप्लॉयमेंट की ज़रूरत होती है, तब मोनोलिथिक आर्किटेक्चर का इस्तेमाल करना कम लचीला और मुश्किल हो जाता है.
आपके पास ऐसी वर्चुअल मशीन बनाने और उन्हें मैनेज करने का विकल्प है जो Compute Engine पर मोनोलिथिक ऐप्लिकेशन चला सकती हैं. आपके पास इन वर्चुअल मशीन के ऑपरेटिंग सिस्टम, सॉफ़्टवेयर, और मैनेजमेंट पर पूरा कंट्रोल होता है. इससे मोनोलिथिक ऐप्लिकेशन को चलाया जा सकता है.
ऐप्लिकेशन इंजन जैसी सेवा के तौर पर प्लैटफ़ॉर्म की मदद से, अपना ऐप्लिकेशन बनाया जा सकता है और उसे पूरी तरह से मैनेज किए गए इन्फ़्रास्ट्रक्चर पर चलाया जा सकता है, जो अनुरोधों के हिसाब से अपने-आप बड़ा हो जाता है.
अगर आपके मोनोलिथिक ऐप्लिकेशन को कंटेनर बनाया गया है, तो इसे Google Kubernetes Engine (GKE) या Cloud Run का इस्तेमाल करके चलाया जा सकता है. Cloud SQL या Cloud Spanner जैसी सेवाओं का इस्तेमाल, मोनोलिथिक ऐप्लिकेशन के लिए डेटा सेव करने के लिए किया जा सकता है. अपने ऐप्लिकेशन की खास ज़रूरतों को ध्यान में रखते हुए, सेवाओं और सिस्टम को इस्तेमाल करने के बारे में सोचें.
बिना सर्वर वाले आर्किटेक्चर
बिना सर्वर वाले आर्किटेक्चर का इस्तेमाल करके, फ़िज़िकल या वर्चुअल सर्वर को मैनेज किए बिना ऐप्लिकेशन बनाए और चलाए जा सकते हैं. क्लाउड की सेवा देने वाली कंपनी इन्फ़्रास्ट्रक्चर, स्केलिंग, और रिसॉर्स ऐलोकेशन को अपने-आप मैनेज करती है, ताकि वे अपने ऐप्लिकेशन के लिए कोड लिखने पर फ़ोकस कर सकें. सर्वर के बिना आर्किटेक्चर से डेवलपमेंट को आसान बनाया जा सकता है, काम का ओवरहेड कम किया जा सकता है, और सर्वर का रखरखाव करने से जुड़ी लागतों को कम किया जा सकता है. ये माइक्रोसेवाओं, रीयल-टाइम डेटा प्रोसेसिंग, वैरिएबल वर्कलोड वाले वेब ऐप्लिकेशन, और इवेंट प्रोसेसिंग में बहुत काम आती हैं.
बिना सर्वर वाले इवेंट पर आधारित आर्किटेक्चर
इवेंट पर आधारित बिना सर्वर वाला आर्किटेक्चर, बिना सर्वर वाली कंप्यूटिंग का एक खास तरह का आर्किटेक्चर है. यह फ़ंक्शन या माइक्रोसर्विस को शुरू करने के लिए इवेंट या ट्रिगर पर निर्भर करता है. सिस्टम कॉम्पोनेंट, इवेंट के ज़रिए कम्यूनिकेशन करते हैं और इवेंट की वजह से फ़ंक्शन शुरू होते हैं. ये अक्सर एसिंक्रोनस कम्यूनिकेशन पर निर्भर होते हैं, क्योंकि फ़ंक्शन ट्रिगर होने पर इवेंट ट्रिगर होते हैं. इसके बाद, इन्हें स्वतंत्र रूप से प्रोसेस किया जाता है. साथ ही, ये ऐसे इवेंट बना सकते हैं जिनसे बाद में होने वाली कार्रवाइयां ट्रिगर हो जाती हैं. बिना सर्वर वाली इस तरह की आर्किटेक्चर, बड़े पैमाने पर काम करने वाले, रिस्पॉन्सिव, और बिना रुकावट वाले सिस्टम बनाने के लिए एक अच्छा विकल्प है.
Google Cloud Functions और Firebase के लिए Cloud फ़ंक्शन की मदद से, पूरी तरह से मैनेज किए गए और बिना सर्वर वाले इवेंट-ड्रिवन फ़ंक्शन बनाए और डिप्लॉय किए जा सकते हैं. इससे आपको कई इवेंट और ट्रिगर के रिस्पॉन्स में कोड चलाने की सुविधा मिलती है. इन इवेंट और ट्रिगर में, एचटीटीपी अनुरोध, Cloud Pub/Sub मैसेज, Google Cloud Storage में बदलाव, Firebase रीयल टाइम डेटाबेस के अपडेट, और Firebase रीयल टाइम डेटाबेस के अपडेट शामिल हैं. इन्हें प्रोसेस करने के लिए, इंफ़्रास्ट्रक्चर को मैनेज करने की ज़रूरत नहीं होती. मुख्य सुविधाओं में ये सुविधाएँ शामिल हैं: कई भाषाओं में काम करने की सुविधा, स्टोरेज बढ़ाए जा सकने की योग्यता, विस्तृत बिलिंग, तीसरे पक्ष के इंटिग्रेशन, बेहतर तरीके से लॉग करने और मॉनिटर करने की सुविधा, और Google और Firebase की अन्य सेवाओं के साथ इंटिग्रेशन.
सर्वर के बिना आर्किटेक्चर, इस्तेमाल के कई उदाहरणों के लिए किफ़ायती हो सकते हैं. खास तौर पर, ऐसे ऐप्लिकेशन के लिए जिन पर अलग-अलग तरह का काम होता है, तेज़ी से डेवलपमेंट की ज़रूरतें होती हैं, और ऐसा ट्रैफ़िक होता है जिसके बारे में अनुमान न लगाया जा सकता हो. विश्वसनीयता, क्लाउड सेवा देने वाली कंपनी पर निर्भर करती है कि उसके सेवा स्तर समझौते (एसएलए) तय किए गए हैं, ताकि परफ़ॉर्मेंस और विश्वसनीयता से जुड़े टारगेट को पक्का किया जा सके. आपको अपने इस्तेमाल के खास उदाहरण और ज़रूरी शर्तों का आकलन करना चाहिए, ताकि यह तय किया जा सके कि बिना सर्वर वाला आर्किटेक्चर आपके लिए सबसे अच्छा विकल्प है या नहीं.
कन्टेनरीकरण
कंटेनराइज़ेशन की मदद से, ऐप्लिकेशन और उनकी डिपेंडेंसी को लाइटवेट, पोर्टेबल कंटेनर में पैकेज किया जा सकता है. इनसे एक जैसा ऐप्लिकेशन एनवायरमेंट मिलता है जो अलग-अलग सिस्टम और प्लैटफ़ॉर्म पर डेवलपमेंट और डिप्लॉयमेंट में मदद करता है. बिना सर्वर वाले कुछ प्लैटफ़ॉर्म में, कंटेनर वाले वर्कलोड चलाने की सुविधा होती है. बिना सर्वर वाले एनवायरमेंट में कंटेनर चलाना तब फ़ायदेमंद हो सकता है, जब आपके पास जटिल या स्टेटफ़ुल वर्कलोड होते हैं जिन्हें बेसिक फ़ंक्शन के तौर पर नहीं दिखाया जा सकता. यह सुविधा, भाषा के हिसाब से काम करती है और रनटाइम के दौरान काम करती है.
Cloud Run बिना सर्वर का एक कंप्यूटिंग प्लैटफ़ॉर्म है. इसकी मदद से डेवलपर, पूरी तरह से मैनेज किए जा रहे एनवायरमेंट में कंटेनर वाले ऐप्लिकेशन डिप्लॉय और चला सकते हैं. यह बुनियादी इन्फ़्रास्ट्रक्चर को मैनेज किए बिना, ऐप्लिकेशन बनाने, उन्हें डिप्लॉय करने, और स्केल करने का आसान तरीका देता है. यह वेब और माइक्रोसेवाएं कई तरह के ऐप्लिकेशन के लिए सही है. खास तौर पर, उन ऐप्लिकेशन के लिए जिनके वर्कलोड अलग-अलग होते हैं और जहां कंटेनराइज़ेशन से ऐप्लिकेशन पैकेजिंग और एक जैसा बनाए रखने के फ़ायदे मिलते हैं.
माइक्रोसर्विस आर्किटेक्चर
ऐप्लिकेशन को ऐसे छोटे हिस्सों में बांटा जाता है जो बिना किसी रुकावट के जोड़े जाते हैं और अलग-अलग सुविधाओं या क्षमताओं को लागू करते हैं. ये सेवाएं एसिंक्रोनस मैसेज, इवेंट-आधारित चैनलों या सीधे किसी इंटरफ़ेस को दिखाकर जानकारी दे सकती हैं. हर सेवा को कंटेनर में अलग-अलग डेवलप, टेस्ट, और स्केल किया जाता है. इसे अक्सर ऑर्केस्ट्रेशन सेवा, जैसे कि Kubernetes की मदद से मैनेज किया जाता है. इसके अलावा, Cloud Run जैसे मैनेज किए गए प्लैटफ़ॉर्म का इस्तेमाल करके भी इसे डिप्लॉय किया जाता है.
माइक्रोसर्विस डिप्लॉयमेंट, आम तौर पर बिना सर्वर वाले ऐप्लिकेशन के मॉडल का फ़ायदा उठाते हैं. ऐसा, एक ही जगह पर बनाए गए सर्वर पर निर्भर नहीं होता है.
किसी ऐप्लिकेशन को स्वायत्त सेवाओं में अलग करने से जटिल सिस्टम को आसान बनाया जा सकता है. अच्छी तरह से तय सीमाएं और मकसद, डेवलपमेंट की प्रोसेस को तेज़ कर सकते हैं और रखरखाव को बेहतर बना सकते हैं. हर माइक्रोसर्विस को सबसे असरदार फ़्रेमवर्क या टूल का इस्तेमाल करके अलग-अलग डेवलप किया जा सकता है. सेवाओं के बीच कम्यूनिकेशन को अक्सर इवेंट, पब्लिश करने की सदस्यता वाले कम्यूनिकेशन, मैसेज पाइपलाइन या gRPC जैसे रिमोट प्रोसेस कॉल का इस्तेमाल करके मैनेज किया जाता है.
माइक्रोसर्विस आर्किटेक्चर में टास्क व्यवस्थित करने के लिए, ऐसे फ़्रेमवर्क का इस्तेमाल करें जो टारगेट किए जा रहे प्लैटफ़ॉर्म के साथ काम करता हो. साथ ही, आपके ऑर्केस्ट्रा के टास्क और अलग-अलग तरह के वर्कफ़्लो के साथ काम करने वाला फ़्रेमवर्क इस्तेमाल करें. इसके अलावा, गड़बड़ियों को डीबग करने के लिए टेलीमेट्री और गड़बड़ियों को मैनेज करने के तरीके भी इस्तेमाल करें. लोकप्रिय विकल्पों में कंडक्टर या क्लाउड सेवा देने वाली कंपनी के ऑफ़र शामिल हैं, जैसे कि Google वर्कफ़्लो.
माइक्रोसर्विस पर आधारित ऐप्लिकेशन का डिस्ट्रिब्यूशन और इंट्रा-सर्विस कम्यूनिकेशन की ज़रूरत की वजह से, ऐप्लिकेशन डेवलप करना और बनाए रखना मुश्किल हो सकता है. इसलिए, डिप्लॉयमेंट, मॉनिटरिंग, और लॉगिंग को मैनेज करना, अन्य आर्किटेक्चर विकल्पों की तुलना में ज़्यादा मुश्किल है. विश्वसनीयता, अलग-अलग सेवाओं के आर्किटेक्चर पर निर्भर करती है. इसलिए, कई तरह के काम करने की वजह से आने वाली समस्याओं को हल करना आसान हो सकता है. खास तौर पर, ऐसा तब हो सकता है, जब ज़रूरी होने पर निगरानी और टेलीमेट्री को डिप्लॉय और चालू किया गया हो.
कॉन्टेंट पर आधारित वेब ऐप्लिकेशन बैकएंड के लिए अलग-अलग आर्किटेक्चर की तुलना
नीचे दी गई टेबल में, कॉन्टेंट पर आधारित वेब ऐप्लिकेशन के बैकएंड के लिए मुख्य शर्तों के साथ आर्किटेक्चर की तुलना की गई है.
| मोनोलिथिक आर्किटेक्चर | बिना सर्वर वाले इवेंट पर आधारित आर्किटेक्चर | बिना सर्वर वाली माइक्रोसर्विस आर्किटेक्चर | |
|---|---|---|---|
| जटिलता और रखरखाव |
|
|
|
| बढ़ाए जा सकने की योग्यता और परफ़ॉर्मेंस |
|
|
|
| ज़रूरत के हिसाब से बदलाव और फ़ॉलबैक की रणनीतियां |
|
|
|
| डेवलपमेंट का अनुभव |
|
|
|
| कीमत |
|
|
|
कॉन्टेंट पर आधारित वेब ऐप्लिकेशन के लिए बैकएंड आर्किटेक्चर के बारे में ज़्यादा जानें
यहां कुछ संसाधन दिए गए हैं, जिनसे कॉन्टेंट पर आधारित वेब ऐप्लिकेशन के आर्किटेक्चर के बारे में ज़्यादा जानकारी मिलती है. इनमें अपने ऐप्लिकेशन को किसी अलग आर्किटेक्चर पर माइग्रेट करने का तरीका भी शामिल है:
- ढके हुए वेब ऐप्लिकेशन के बैकएंड आर्किटेक्चर के बारे में ज़्यादा जानें. इनमें कई लेवल वाले मोनोलिथिक और बिना सर्वर वाले वेब ऐप्लिकेशन शामिल हैं.
किसी मोनोलिथिक ऐप्लिकेशन को माइक्रोसर्विस आर्किटेक्चर पर माइग्रेट करना.
बिना सर्वर वाले क्लाउड फ़ंक्शन के लिए, सामान्य इस्तेमाल के उदाहरण.