आर्किटेक्चर स्टाइल और कम्युनिकेशन पैटर्न

AWS पर एप्लिकेशन विकसित करना

Ricardo Sueiras

Principal Technologist

आपके इंस्ट्रक्टर

आर्किटेक्चर पैटर्न क्या हैं?

 

 

 

• आम समस्या के लिए दोहराने योग्य समाधान.
• पैटर्न बताते हैं कि AWS सेवाएँ साथ कैसे फिट हों.
• आर्किटेक्चर तय करता है लोड में ऐप कितना अच्छा चलेगा.
• कई महत्वपूर्ण आर्किटेक्चरल पैटर्न जिन्हें आपको जानना है.

मोनोलिथ्स

 

 

 

 

• एकल, टाइटली कपल्ड यूनिट.
• एक कोडबेस, एक डिप्लॉयमेंट.
• शुरुआत में बनाना आसान.
• स्केल करना कठिन: सब कुछ साथ में स्केल करना पड़ता है.

माइक्रोसर्विसेज

 

 

• छोटे, स्वतंत्र सर्विसेज: हर एक एक बिज़नेस कैपेबिलिटी का मालिक.
• हर सर्विस को अलग से डिप्लॉय, स्केल और अपडेट करें.
• ट्रेड-ऑफ: ज़्यादा ऑपरेशनल जटिलता और सर्विस-टू-सर्विस कम्युनिकेशन मैनेज करना.

सर्वरलेस

• इंफ्रास्ट्रक्चर मैनेज नहीं करना, सिर्फ कोड और कॉन्फ़िगरेशन.
• मैनेज्ड AWS सेवाओं को कंपोज़ करके बनाएँ.
• AWS प्रोविज़निंग, स्केलिंग, और मेंटेनेंस संभालता है.
• ट्रेड-ऑफ: execution time limits, cold starts, vendor lock-in.
• लगभग शून्य ऑपरेशनल ओवरहेड और ऑटोमैटिक स्केलिंग.

 

इवेंट-ड्रिवन आर्किटेक्चर (EDA)

• कंपोनेंट्स डायरेक्ट कॉल्स नहीं, इवेंट्स से कम्युनिकेट करते हैं.
• एक इवेंट किसी घटना को रिकॉर्ड करता है (order placed, payment received, item shipped).
• प्रोड्यूसर इवेंट्स इमिट करते हैं.
• कंज़्यूमर अपनी रुचि के इवेंट्स को सब्सक्राइब करते हैं.

 

टाइटली और लूज़ली कपल्ड सिस्टम्स

• आधुनिक क्लाउड ऐप्स कई सर्विसेज से बने होते हैं.
• काम पूरा करने के लिए सर्विसेज़ को कम्युनिकेट और कोऑर्डिनेट करना होता है.
• synchronous कम्युनिकेशन टाइट कपल्ड होता है.
• asynchronous कम्युनिकेशन लूज़ली कपल्ड होता है.

सिंक्रोनस कम्युनिकेशन

 

• एक सर्विस रिक्वेस्ट भेजती है और रिस्पॉन्स का इंतज़ार करती है.
• कॉलर रिस्पॉन्स या टाइमआउट तक ब्लॉक रहता है.
• लागू करना और समझना सीधा.
• टाइट कपलिंग: डाउनस्ट्रीम स्लोनैस या फेल्योर कैस्केड कर सकता है.
• टाइमआउट्स, retries, और सर्किट ब्रेकर्स से mitigate करें.

पैटर्न: रिक्वेस्ट/रिस्पॉन्स

• ज़्यादातर एप्लिकेशन इंटरफेस की रीढ़.
• पूर्वानुमेय व्यवहार.
• यूज़र्स को तुरंत फीडबैक.

असिंक्रोनस कम्युनिकेशन

 

• सेंडर रिस्पॉन्स का इंतज़ार नहीं करता.
• मैसेज या इवेंट भेजकर आगे प्रोसेस करता रहता है.
• रिसीवर मैसेज को स्वतंत्र रूप से प्रोसेस करता है.
• लूज़ली कपल्ड: बेहतर स्केलेबिलिटी और फॉल्ट टॉलरेंस.
• ट्रैफिक स्पाइक्स और आंशिक आउटेज को सहजता से संभालता है.
• चुनौतियाँ: डुप्लिकेट मैसेज, ऑर्डरिंग, eventual consistency.

पैटर्न: queue-आधारित decoupling

• प्रोड्यूसर मैसेजेस को एक queue में भेजता है.
• कंज़्यूमर मैसेजेस को स्वतंत्र रूप से पुल और प्रोसेस करता है.
• फेल्योर को कैस्केड होने से रोकता है.
• प्रोड्यूसर और कंज़्यूमर स्वतंत्र रूप से स्केल होते हैं.

 

पैटर्न: worker queue

• कई वर्कर्स एक ही queue से मैसेज पुल करते हैं.
• मैसेजेस पैरेलल में प्रोसेस होते हैं.
• हॉरिज़ॉन्टल स्केलिंग और अधिक थ्रूपुट सक्षम.
• मैसेज ऑर्डर की गारंटी नहीं.

पैटर्न: publish/subscribe

• पब्लिशर्स मैसेजेस को SNS topic पर भेजते हैं.
• कई सब्सक्राइबर्स को वही मैसेज मिलता है.
• कई कंज़्यूमर्स तक रियल-टाइम ब्रॉडकास्टिंग.

 

पैटर्न: fan-out

• एक मैसेज कई कंज़्यूमर्स को एक साथ डिलीवर होता है.
• इवेंट-ड्रिवन आर्किटेक्चर में व्यापक रूप से प्रयुक्त.
• जब कई सर्विसेज़ को एक ही इवेंट पर रिएक्ट करना हो, तब उपयोगी.

मैसेज ऑर्डरिंग

• कुछ वर्कलोड्स में मैसेजेस सही क्रम में प्रोसेस होने चाहिए.
• Amazon SQS FIFO और Kinesis ordered प्रोसेसिंग को सपोर्ट करते हैं.
• सख्त ऑर्डरिंग थ्रूपुट घटाती है.
• शुद्धता और स्केलेबिलिटी के बीच संतुलन रखें.

अभ्यास करते हैं!

AWS पर एप्लिकेशन विकसित करना