यह लेख हमारे सॉफ़्टवेयर प्रोजेक्ट में प्रतिक्रियाशील आर्किटेक्चर से दूर जाने के हमारे निर्णय की पड़ताल करता है। हम प्रतिक्रियाशील प्रणालियों के मूल सिद्धांतों, गैर-अवरुद्ध I/O के लाभों और प्रतिक्रियाशील दृष्टिकोण के साथ हमारे सामने आने वाली चुनौतियों पर चर्चा करेंगे।

प्रतिक्रियाशील वास्तुकला शैली को समझना

रिएक्टिव में उत्तरदायी वितरित सिस्टम और अनुप्रयोगों के निर्माण के उद्देश्य से सिद्धांतों और दिशानिर्देशों का एक सेट शामिल है, जिनकी विशेषता है:

1. प्रतिक्रियाशीलता: भारी भार के तहत भी अनुरोधों को तेजी से संभालने में सक्षम।
2. लचीलापन: न्यूनतम डाउनटाइम के साथ विफलताओं से उबरने में सक्षम।
3. लोच: संसाधनों को तदनुसार बढ़ाकर बदलते कार्यभार के अनुकूल हो सकता है।
4. संदेश-संचालित: दोष सहिष्णुता को बढ़ाने और घटकों को अलग करने के लिए अतुल्यकालिक संदेश का उपयोग करता है।

प्रतिक्रियाशील प्रणालियों का एक प्रमुख लाभ गैर-अवरुद्ध I/O का उपयोग है। यह दृष्टिकोण I/O संचालन के दौरान थ्रेड को अवरुद्ध करने से बचाता है, जिससे एक थ्रेड को एक साथ कई अनुरोधों को संभालने की अनुमति मिलती है। यह पारंपरिक ब्लॉकिंग I/O की तुलना में सिस्टम दक्षता में उल्लेखनीय सुधार कर सकता है।
पारंपरिक मल्टीथ्रेडिंग में, ब्लॉकिंग ऑपरेशंस सिस्टम को अनुकूलित करने में महत्वपूर्ण चुनौतियां पेश करते हैं (चित्र 1)। अत्यधिक मेमोरी का उपभोग करने वाले लालची एप्लिकेशन अक्षम होते हैं और अन्य एप्लिकेशन को दंडित करते हैं, जिसके लिए अक्सर मेमोरी, सीपीयू या बड़ी वर्चुअल मशीन जैसे अतिरिक्त संसाधनों के लिए अनुरोध की आवश्यकता होती है।

चित्रा 1 - पारंपरिक मल्टी-थ्रेडिंग

आई/ओ संचालन आधुनिक प्रणालियों का अभिन्न अंग हैं, और लालची व्यवहार को रोकने के लिए उन्हें कुशलतापूर्वक प्रबंधित करना सर्वोपरि है। प्रतिक्रियाशील प्रणालियाँ गैर-अवरुद्ध I/O का उपयोग करती हैं, जिससे कई समवर्ती I/O परिचालनों को संभालने के लिए कम संख्या में OS थ्रेड सक्षम होते हैं।

प्रतिक्रियाशील निष्पादन मॉडल

हालांकि नॉन-ब्लॉकिंग I/O पर्याप्त लाभ प्रदान करता है, यह पारंपरिक ढांचे से अलग एक नया निष्पादन मॉडल पेश करता है। इस समस्या को हल करने के लिए रिएक्टिव प्रोग्रामिंग का उदय हुआ, क्योंकि यह ब्लॉकिंग ऑपरेशंस के दौरान निष्क्रिय पड़े प्लेटफॉर्म थ्रेड्स की अक्षमता को कम करता है (चित्रा 2)।

चित्रा 2 - रिएक्टिव इवेंट लूप

क्वार्कस और रिएक्टिव

क्वार्कस एक्लिप्स वर्ट.एक्स और नेट्टी द्वारा संचालित एक प्रतिक्रियाशील इंजन का लाभ उठाता है, जो गैर-अवरुद्ध I/O इंटरैक्शन की सुविधा प्रदान करता है। म्यूटिनी, क्वार्कस के साथ प्रतिक्रियाशील कोड लिखने के लिए पसंदीदा तरीका, एक घटना-संचालित प्रतिमान को अपनाता है, जिसमें प्राप्त घटनाओं द्वारा प्रतिक्रियाएं शुरू हो जाती हैं।

विद्रोह दो घटना-संचालित और आलसी प्रकार प्रदान करता है:

1. Uni: एक एकल घटना (एक आइटम या विफलता) उत्सर्जित करता है, जो शून्य या एक परिणाम के साथ अतुल्यकालिक क्रियाओं का प्रतिनिधित्व करने के लिए उपयुक्त है।
2. मल्टी: कई घटनाओं (एन आइटम, एक विफलता, या एक पूर्णता) का उत्सर्जन करता है, जो संभावित रूप से असीमित वस्तुओं की धाराओं का प्रतिनिधित्व करता है।

रिएक्टिव के साथ चुनौतियाँ

हालांकि प्रतिक्रियाशील सिस्टम लाभ प्रदान करते हैं, हमें विकास के दौरान कई चुनौतियों का सामना करना पड़ा:

• प्रतिमान बदलाव: प्रतिक्रियाशील प्रोग्रामिंग के लिए डेवलपर्स की मानसिकता में मौलिक बदलाव की आवश्यकता होती है, जो चुनौतीपूर्ण हो सकता है, खासकर अनिवार्य प्रोग्रामिंग के आदी डेवलपर्स के लिए। स्ट्रीम्स एपीआई जैसे सहायक उपकरणों के विपरीत, प्रतिक्रियाशील दृष्टिकोण एक संपूर्ण मानसिकता में बदलाव की मांग करता है।
• कोड पठनीयता और समझ: रिएक्टिव कोड नए डेवलपर्स के लिए समझने में कठिनाइयां पैदा करता है, जिससे इसे समझने और समझने में समय बढ़ जाता है। प्रतिक्रियाशील प्रतिमानों द्वारा प्रस्तुत जटिलता इस समस्या को जटिल बनाती है।

"वास्तव में, पढ़ने और लिखने में बिताए गए समय का अनुपात 10 से 1 से अधिक है। हम नए कोड लिखने के प्रयास के हिस्से के रूप में लगातार पुराने कोड को पढ़ रहे हैं। ...[इसलिए,] इसे पढ़ना आसान बनाता है इसे लिखना आसान है।"
- रॉबर्ट सी. मार्टिन, क्लीन कोड: ए हैंडबुक ऑफ एजाइल सॉफ्टवेयर क्राफ्ट्समैनशिप

• डिबगिंग चुनौतियां: अधिकांश कोड को लैंबडा द्वारा एनकैप्सुलेट करने के कारण मानक आईडीई डिबगर्स के साथ रिएक्टिव कोड को डिबग करना लगभग असंभव साबित होता है। इसके अतिरिक्त, अपवादों के दौरान सार्थक स्टैक ट्रेस का नुकसान डिबगिंग प्रयासों को और बाधित करता है। विकास और परीक्षण प्रयासों में वृद्धि: प्रतिक्रियाशील कोड की अंतर्निहित जटिलता लेखन, संशोधन और परीक्षण के लिए आवश्यक समय के कारण लंबे विकास चक्र को जन्म दे सकती है।

जटिलता को दर्शाने के लिए विद्रोह का उपयोग करते हुए प्रतिक्रियाशील कोड का एक उदाहरण यहां दिया गया है:

Multi.createFrom().ticks().every(Duration.ofSeconds(15))
    .onItem().invoke(() - > Multi.createFrom().iterable(configs())
    .onItem().transform(configuration - > {
  try {
    return Tuple2.of(openAPIConfiguration,
        RestClientBuilder.newBuilder()
            .baseUrl(new URL(configuration.url()))
            .build(MyReactiveRestClient.class)
            .getAPIResponse());

  } catch (MalformedURLException e) {
    log.error("Unable to create url");

  }
  return null;
}).collect().asList().toMulti().onItem().transformToMultiAndConcatenate(tuples - > {

  AtomicInteger callbackCount = new AtomicInteger();
  return Multi.createFrom().emitter(emitter - > Multi.createFrom().iterable(tuples)
      .subscribe().with(tuple - >
          tuple.getItem2().subscribe().with(response - > {
              emitter.emit(callbackCount.incrementAndGet());

  if (callbackCount.get() == tuples.size()) {
    emitter.complete();
  }
                    })
                ));

}).subscribe().with(s - > {},
Throwable::printStackTrace, () - > doSomethingUponComplete()))
    .subscribe().with(aLong - > log.info("Tic Tac with iteration: "   aLong));

फ्यूचर आउटलुक-प्रोजेक्ट लूम एंड बियॉन्ड

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

"प्रोजेक्ट लूम रिएक्टिव प्रोग्रामिंग को खत्म करने जा रहा है"
-ब्रायन गोएट्ज़

निष्कर्ष

निष्कर्ष रूप में, हमारी परियोजना की दीर्घकालिक रखरखाव के लिए प्रतिक्रियाशील वास्तुकला शैली से दूर एक व्यावहारिक दृष्टिकोण अपनाने का हमारा निर्णय। जबकि प्रतिक्रियाशील प्रणालियाँ संभावित लाभ प्रदान करती हैं, उन्होंने हमारी टीम के लिए जो चुनौतियाँ प्रस्तुत कीं, वे हमारे विशिष्ट संदर्भ में उन लाभों से कहीं अधिक थीं।

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

जैसा कि हम भविष्य की ओर देखते हैं, फोकस एक ऐसे कोडबेस के निर्माण पर रहता है जो न केवल कार्यात्मक हो बल्कि सभी अनुभव स्तरों के डेवलपर्स के लिए समझने और बनाए रखने में भी आसान हो। इससे न केवल विकास का समय कम होता है बल्कि टीम के भीतर बेहतर सहयोग और ज्ञान साझा करने को भी बढ़ावा मिलता है।

नीचे दिए गए ग्राफ़ में, X-axis हमारे कोडबेस की बढ़ती जटिलता को दर्शाता है क्योंकि यह विकसित होता है, जबकि Y-axis इन विकासात्मक परिवर्तनों के लिए आवश्यक समय को दर्शाता है।