रिएक्टर, वेबफ्लक्स, कोटलिन कॉरआउट, या एक सरल उदाहरण के साथ अतुल्यकालिक

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

जेवीएम की दुनिया में, चीजें थोड़ी अधिक जटिल हैं। उपयोग किए जाने पर थ्रेड्स को ब्लॉक करने वाले बड़ी संख्या में चौखटे और लाइब्रेरी हैं। तो stdlib खुद भी कई बार यही काम कर सकता है। और जावा में गोलंग में गोरोइटिन के समान कोई तंत्र नहीं है।

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

मैं प्रस्ताव करता हूं, एक कार्ड से दूसरे कार्ड में पैसे ट्रांसफर करने के लिए एक छोटी सी सेवा के उदाहरण का उपयोग करते हुए, कई बाहरी सेवाओं के साथ एकीकरण के लिए स्प्रिंग बूट 2.2 और कोटलिन पर एक आवेदन लिखने के लिए।

यह अच्छा है यदि आप पहले से ही जावा, कोटलिन, ग्रैडल, स्प्रिंग, स्प्रिंग बूट 2, रिएक्टर, वेब फ्लक्स, टॉमकैट, नेट्टी, कोटलिन oroutines, ग्रैडल कोटलिन डीएसएल या यहां तक ​​कि पीएचडी से परिचित हैं। लेकिन यदि नहीं, तो यह बात नहीं है। कोड को अधिकतम रूप से सरल बनाया जाएगा, और यहां तक ​​कि अगर आप JVM दुनिया से नहीं हैं, तो मुझे उम्मीद है कि सब कुछ आपके लिए स्पष्ट हो जाएगा।

यदि आप स्वयं एक सेवा लिखने की योजना बनाते हैं, तो सुनिश्चित करें कि आपकी ज़रूरत की हर चीज़ स्थापित है:

• जावा 8+
• डॉकर और डॉकर कम्पोज़;
• cURL और अधिमानतः jq ;
• git;
• अधिमानतः कोटलिन के लिए एक IDE (Intellij Idea, Eclipse, VS, vim , आदि)। लेकिन यह एक नोटबुक में संभव है।

उदाहरणों में सेवा में कार्यान्वयन के लिए दोनों रिक्त स्थान होंगे, और पहले से ही लिखित कार्यान्वयन। सबसे पहले, इंस्टॉलेशन और असेंबली चलाएं और सेवाओं और उनके एपीआई पर करीब से नज़र डालें।

सेवाओं और एपीआई का उदाहरण केवल चित्रण प्रयोजनों के लिए बनाया गया है; अपने ठेस के लिए सभी AS IS स्थानांतरित न करें!

सबसे पहले, हम रिपॉजिटरी को स्वयं के लिए सेवाओं के साथ क्लोन करते हैं, जिस एकीकरण के साथ हम इसे करेंगे, और निर्देशिका में जाएंगे:

 git clone https://github.com/evgzakharov/spring-demo-services && cd spring-demo-services 

एक अलग टर्मिनल में, हम gradle का उपयोग करके सभी एप्लिकेशन एकत्र करते हैं, जहां एक सफल निर्माण के बाद सभी सेवाओं को docker-compose का उपयोग करके लॉन्च किया जाएगा।

 ./gradlew build && docker-compose up 

जबकि सब कुछ डाउनलोड और इंस्टॉल किया गया है, सेवाओं के साथ एक परियोजना पर विचार करें।

टोकन के साथ एक अनुरोध, स्थानांतरण के लिए कार्ड नंबर और कार्ड के बीच हस्तांतरित की जाने वाली राशि सेवा के प्रवेश द्वार पर प्राप्त की जाएगी (डेमो सेवा):

 { "authToken": "auth-token1", "cardFrom": "55593478", "cardTo": "55592020", "amount": "10.1" } 

authToken टोकन के अनुसार, authToken AUTH सेवा में जाने और userId प्राप्त करने की आवश्यकता है, जिसके साथ आप तब USER अनुरोध कर सकते हैं और उपयोगकर्ता पर सभी अतिरिक्त जानकारी निकाल सकते हैं। AUTH उन तीन सेवाओं के बारे में भी जानकारी देगा जो हम एक्सेस कर सकते हैं। AUTH से नमूना प्रतिक्रिया:

 { "userId": 158, "cardAccess": true, "paymentAccess": true, "userAccess": true } 

कार्डों के बीच स्थानांतरण करने के लिए, पहले कार्ड में प्रत्येक कार्ड नंबर के साथ जाएं। अनुरोधों के जवाब में, हम cardId प्राप्त cardId , फिर उनके साथ हम PAYMENT लिए एक अनुरोध भेजेंगे और एक हस्तांतरण करेंगे। और अंतिम - एक बार फिर से हम एक अनुरोध भेज कर सकते हैं के साथ fromCardId और वर्तमान शेष राशि का पता लगाएं।

सेवाओं में एक छोटी सी देरी का अनुकरण करने के लिए, टाइमटाइम पर्यावरण चर का मूल्य सभी कंटेनरों में फेंका जाता है, जिसमें प्रतिक्रिया देरी मिलीसेकंड में सेट की जाती है। और AUTH से प्रतिक्रियाओं में विविधता लाने के लिए, SUCCESS_RATE के मूल्य में SUCCESS_RATE करना संभव है, जो सेवा के लिए एक true प्रतिक्रिया की संभावना को नियंत्रित करता है।

डॉकटर-कंपोज.माइल फ़ाइल:

 version: '3' services: service-auth: build: service-auth image: service-auth:1.0.0 environment: - SUCCESS_RATE=1.0 - TIMEOUT=100 ports: - "8081:8080" service-card: build: service-card image: service-card:1.0.0 environment: - TIMEOUT=100 ports: - "8082:8080" service-payment: build: service-payment image: service-payment:1.0.0 environment: - TIMEOUT=100 ports: - "8083:8080" service-user: build: service-user image: service-user:1.0.0 environment: - TIMEOUT=100 ports: - "8084:8080" 

सभी सेवाओं के लिए, 8081 से 8084 तक पोर्ट अग्रेषण आसानी से सीधे उन तक पहुंचने के लिए किया जाता है।

Demo service लिखने के लिए आगे बढ़ते हैं। पहले, आइए, अतुल्यकालिक और संगामिति के बिना जितना संभव हो सके अनाड़ी लिखने का प्रयास करें। ऐसा करने के लिए, स्प्रिंग बूट 2.2.1, कोटलिन और सेवा के लिए एक रिक्त स्थान लें। हम रिपॉजिटरी का क्लोन बनाते हैं और spring-mvc-start शाखा में जाते हैं:

 git clone https://github.com/evgzakharov/demo-service && cd demo-service && git checkout spring-mvc-start 

demo.Controller फाइल पर जाएं। इसके पास एकमात्र खाली processRequest है, जिसके लिए एक कार्यान्वयन विधि लिखी जानी चाहिए।

  @PostMapping fun processRequest(@RequestBody serviceRequest: ServiceRequest): Response { .. } 

विधि के प्रवेश द्वार पर कार्डों के बीच स्थानांतरण का अनुरोध प्राप्त होगा।

 data class ServiceRequest( val authToken: String, val cardFrom: String, val cardTo: String, val amount: BigDecimal ) 

इसे आसान बनाने के लिए, अन्य सेवाओं के साथ एकीकरण के सभी तरीके पहले से ही बनाए गए हैं, आपको बस उन्हें सही ढंग से कनेक्ट करने की आवश्यकता है। केवल पाँच विधियाँ हैं, प्रत्येक क्रिया के लिए एक। अन्य सेवाओं के लिए कॉल स्वयं स्प्रिंग RestTemplate ब्लॉकिंग कॉल पर कार्यान्वित की जाती हैं।

AUTH को कॉल करने के लिए उदाहरण विधि:

 private fun getAuthInfo(token: String): AuthInfo { log.info("getAuthInfo") return restTemplate.getForEntity("${demoConfig.auth}/{token}", AuthInfo::class.java, token) .body ?: throw RuntimeException("couldn't find user by token='$token'") } 

चलो विधि के कार्यान्वयन के लिए आगे बढ़ते हैं। टिप्पणी प्रक्रिया को दर्शाती है और आउटपुट पर क्या प्रतिक्रिया अपेक्षित है:

  @PostMapping fun processRequest(@RequestBody serviceRequest: ServiceRequest): Response { //1) get auth info from service by token -> userId //2) find user info by userId from 1. //3) 4) find cards info for each card in serviceRequest // 5) make transaction for known cards by calling sendMoney(id1, id2, amount) // 6) after payment get payment info by fromCardId TODO("return SuccessResponse") // SuccessResponse( // amount = , // userName = , // userSurname = , // userAge = // ) } 

सबसे पहले, हम विधि को यथासंभव सरल लागू करते हैं, बिना इस बात का ध्यान AUTH कि AUTH हमें अन्य सेवाओं तक पहुँच से वंचित कर सकता है। इसे स्वयं करने का प्रयास करें। जब यह निकलता है (या spring-mvc शाखा में जाने के बाद), तो आप निम्नानुसार सेवा के संचालन की जांच कर सकते हैं:

 fun processRequest(@RequestBody serviceRequest: ServiceRequest): Response { val authInfo = getAuthInfo(serviceRequest.authToken) val userInfo = findUser(authInfo.userId) val cardFromInfo = findCardInfo(serviceRequest.cardFrom) val cardToInfo = findCardInfo(serviceRequest.cardTo) sendMoney(cardFromInfo.cardId, cardToInfo.cardId, serviceRequest.amount) val paymentInfo = getPaymentInfo(cardFromInfo.cardId) return SuccessResponse( amount = paymentInfo.currentAmount, userName = userInfo.name, userSurname = userInfo.surname, userAge = userInfo.age ) } 

सेवा शुरू करें (डेमो-सर्विस फ़ोल्डर से):

 ./gradlew bootRun 

हम समापन बिंदु के लिए एक अनुरोध भेजते हैं:

 ./demo-request.sh 

जवाब में, हमें ऐसा कुछ मिलता है:

 ➜ demo-service git:(spring-mvc) ✗ ./demo-request.sh + curl -XPOST http://localhost:8080/ -d @demo-payment-request.json -H 'Content-Type: application/json; charset=UTF-8' + jq . % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 182 0 85 100 97 20 23 0:00:04 0:00:04 --:--:-- 23 { "amount": 989.9, "userName": "Vasia", "userSurname": "Pupkin", "userAge": 18, "status": true } 

कुल मिलाकर, आपको सेवा को लागू करने के लिए 6 अनुरोध करने की आवश्यकता है। और यह देखते हुए कि उनमें से प्रत्येक 100 एमएस की देरी के साथ प्रतिक्रिया करता है, कुल समय 600 एमएस से कम नहीं हो सकता है। वास्तव में, यह 700 एमएस के बारे में पता चलता है, सभी ओवरहेड को ध्यान में रखते हुए। अब तक कोड काफी सरल है, और अगर हम अब अन्य सेवाओं तक पहुंचने के लिए एक AUTH प्रतिक्रिया जांच जोड़ना चाहते हैं, तो ऐसा करना मुश्किल नहीं होगा (किसी भी अन्य रिफैक्टरिंग की तरह)।

लेकिन आइए विचार करें कि आप क्वेरी निष्पादन को कैसे गति दे सकते हैं। यदि आप AUTH से प्रतिक्रिया के सत्यापन को ध्यान में नहीं रखते हैं, तो हमारे पास 2 स्वतंत्र कार्य हैं:

• उपयोगकर्ता प्राप्त करना और USER से डेटा का अनुरोध करना;
• प्रत्येक कार्ड के लिए cardId प्राप्त करना, भुगतान करना और कुल राशि प्राप्त करना।

ये कार्य एक दूसरे से स्वतंत्र रूप से किए जा सकते हैं। फिर कुल निष्पादन का समय कॉल की सबसे लंबी श्रृंखला पर निर्भर करेगा (इस मामले में, दूसरा) और 300 एमएस + एक्स एमएस ओवरहेड के लिए कुल में निष्पादित किया जाएगा।

यह देखते हुए कि कॉल स्वयं अवरुद्ध हो रही हैं, समानांतर अनुरोधों को निष्पादित करने का एकमात्र तरीका उन्हें अलग-अलग थ्रेड पर चलाना है। आप प्रत्येक कॉल के लिए एक अलग थ्रेड बना सकते हैं, लेकिन यह बहुत महंगा होगा। एक अन्य तरीका है थ्रेडपूल पर कार्य चलाना। पहली नज़र में, ऐसा समाधान उचित लगता है, और समय वास्तव में कम हो जाएगा। उदाहरण के लिए, हम कंप्लीटटेबल सिवनी पर प्रश्नों को निष्पादित कर सकते हैं। यह आपको async पोस्टफिक्स के साथ तरीकों को कॉल करके पृष्ठभूमि कार्यों को चलाने की अनुमति देता है। और यदि आप किसी विशिष्ट ForkJoinPool.commonPool() निर्दिष्ट नहीं करते हैं, तो कॉलिंग के तरीके, कार्यों को ForkJoinPool.commonPool() पर लॉन्च किया जाएगा। अपने आप को एक कार्यान्वयन लिखने की कोशिश करें या spring-mvc-async शाखा पर जाएं।

 fun processRequest(@RequestBody serviceRequest: ServiceRequest): Response { val authInfoFuture = CompletableFuture.supplyAsync { getAuthInfo(serviceRequest.authToken) } val userInfoFuture = authInfoFuture.thenApplyAsync { findUser(it.userId) } val cardFromInfo = CompletableFuture.supplyAsync { findCardInfo(serviceRequest.cardFrom) } val cardToInfo = CompletableFuture.supplyAsync { findCardInfo(serviceRequest.cardTo) } val waitAll = CompletableFuture.allOf(cardFromInfo, cardToInfo) val paymentInfoFuture = waitAll .thenApplyAsync { sendMoney(cardFromInfo.get().cardId, cardToInfo.get().cardId, serviceRequest.amount) } .thenApplyAsync { getPaymentInfo(cardFromInfo.get().cardId) } val paymentInfo = paymentInfoFuture.get() val userInfo = userInfoFuture.get() log.info("result") return SuccessResponse( amount = paymentInfo.currentAmount, userName = userInfo.name, userSurname = userInfo.surname, userAge = userInfo.age ) } 

यदि हम अब अनुरोध समय को मापते हैं, तो यह 360 ms के क्षेत्र में होगा। मूल संस्करण की तुलना में, कुल समय लगभग 2 गुना कम हो गया। कोड स्वयं थोड़ा और अधिक जटिल हो गया है, लेकिन अभी तक इसे संशोधित करना मुश्किल नहीं है। और अगर यहां हम AUTH से एक प्रतिक्रिया चेक जोड़ना चाहते हैं, तो यह मुश्किल नहीं है।

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

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

क्या अब हम सेवा पर भारी बोझ का सामना कर सकते हैं? इस प्रश्न का उत्तर देने के लिए, Tomcat पर एक करीब से नज़र डालें, जो कि स्टार्टर org.springframework.boot:spring-boot-starter-web में स्प्रिंग बूट 2.2.1 में प्रयुक्त होता है org.springframework.boot:spring-boot-starter-web । इसे बनाया गया है ताकि थ्रेडपूल से एक धागा इसके प्रसंस्करण के लिए आने वाले प्रत्येक अनुरोध के लिए आवंटित किया जाए। और मुक्त प्रवाह की अनुपस्थिति में, नए अनुरोध प्रतीक्षा की "कतार" बन जाएंगे। लेकिन हमारी सेवा ही अन्य सेवाओं के लिए अनुरोध भेजती है। इसके तहत एक पूरी धारा आवंटित करना और इसे तब तक रोकना, जब तक कि सभी के जवाब नहीं आते, दिखता है, इसे हल्के ढंग से, शानदार रूप से प्रस्तुत करने के लिए।

सौभाग्य से, स्प्रिंग ने हाल ही में Netty या Undertow के आधार पर एक गैर-अवरुद्ध वेब सर्वर का उपयोग करना संभव बना दिया। ऐसा करने के लिए, आपको केवल spring-boot-starter-web को spring-boot-starter-webflux बदलना होगा और प्रसंस्करण अनुरोधों के लिए विधि को थोड़ा बदलना होगा जिसमें अनुरोध और प्रतिक्रिया मोनो में "लिपटे" होंगे। यह इस तथ्य के कारण है कि वेबफ्लक्स रिएक्टर के आधार पर बनाया गया है, और इसलिए अब विधि में आपको मोनो परिवर्तन की एक श्रृंखला बनाने की आवश्यकता है।

विधि का अपना गैर-अवरोधक कार्यान्वयन लिखने का प्रयास करें। ऐसा करने के लिए, spring-webflux-start शाखा पर जाएं। कृपया ध्यान दें कि स्प्रिंग बूट के लिए स्टार्टर बदल गया है, जहां अब वेबफ्लक्स के साथ संस्करण का उपयोग किया जाता है, और गैर-अवरुद्ध वेबक्लाइंट का उपयोग करने के लिए फिर से लिखे गए अन्य सेवाओं के अनुरोधों का कार्यान्वयन भी बदल गया है।

AUTH को कॉल करने के लिए उदाहरण विधि:

 private fun getAuthInfo(token: String): Mono<AuthInfo> { log.info("getAuthInfo") return WebClient.create().get() .uri("${demoConfig.auth}/$token") .retrieve() .bodyToMono(AuthInfo::class.java) } 

पहले उदाहरण के कार्यान्वयन को एक टिप्पणी में processRequest विधि की सामग्री में डाला गया है। रिएक्टर पर स्वयं इसे फिर से लिखने का प्रयास करें। पिछली बार की तरह, पहले AUTH से चेक को ध्यान में AUTH बिना संस्करण बनाएं, और फिर देखें कि उन्हें जोड़ना कितना मुश्किल है:

 fun processRequest(@RequestBody serviceRequest: Mono<ServiceRequest>): Mono<Response> { // val authInfo = getAuthInfo(serviceRequest.authToken) // // val userInfo = findUser(authInfo.userId) // // val cardFromInfo = findCardInfo(serviceRequest.cardFrom) // val cardToInfo = findCardInfo(serviceRequest.cardTo) // // sendMoney(cardFromInfo.cardId, cardToInfo.cardId, serviceRequest.amount) // // val paymentInfo = getPaymentInfo(cardFromInfo.cardId) // // log.info("result") // // return SuccessResponse( // amount = paymentInfo.currentAmount, // userName = userInfo.name, // userSurname = userInfo.surname, // userAge = userInfo.age // ) TODO() } 

इससे निपटने के बाद, आप spring-webflux से मेरे कार्यान्वयन की तुलना कर सकते हैं:

 fun processRequest(@RequestBody serviceRequest: Mono<ServiceRequest>): Mono<Response> { val cacheRequest = serviceRequest.cache() val userInfoMono = cacheRequest.flatMap { getAuthInfo(it.authToken) }.flatMap { findUser(it.userId) } val cardFromInfoMono = cacheRequest.flatMap { findCardInfo(it.cardFrom) } val cardToInfoMono = cacheRequest.flatMap { findCardInfo(it.cardTo) } val paymentInfoMono = cardFromInfoMono.zipWith(cardToInfoMono) .flatMap { (cardFromInfo, cardToInfo) -> cacheRequest.flatMap { request -> sendMoney(cardFromInfo.cardId, cardToInfo.cardId, request.amount).map { cardFromInfo } } }.flatMap { getPaymentInfo(it.cardId) } return userInfoMono.zipWith(paymentInfoMono) .map { (userInfo, paymentInfo) -> log.info("result") SuccessResponse( amount = paymentInfo.currentAmount, userName = userInfo.name, userSurname = userInfo.surname, userAge = userInfo.age ) } } 

सहमत हूं कि अब एक कार्यान्वयन (पिछले अवरुद्ध दृष्टिकोण की तुलना में) लिखना अधिक कठिन हो गया है। और अगर हम AUTH से "भूल" चेक जोड़ना चाहते हैं, तो यह करना इतना आसान नहीं होगा।

यह प्रतिक्रियाशील दृष्टिकोण का सार है। यह असंबद्ध प्रसंस्करण श्रृंखलाओं के निर्माण के लिए बहुत अच्छा है। लेकिन अगर ब्रांचिंग दिखाई देती है, तो कोड अब इतना सरल नहीं है।

Kotlin coroutines, जो किसी भी एसिंक्रोनस / प्रतिक्रियाशील कोड के साथ बहुत अनुकूल हैं, यहां मदद कर सकते हैं। इसके अलावा, रिएक्टर , कंप्लीटटेबल सीमेंट , आदि के लिए बड़ी संख्या में लिखित रैपर हैं। लेकिन भले ही आपको सही न मिले, विशेष बिल्डरों का उपयोग करके, आप इसे हमेशा स्वयं लिख सकते हैं।

आइए हम अपने दम पर कोरटाइन पर कार्यान्वयन को फिर से लिखें। ऐसा करने के लिए, spring-webflux-coroutines-start शाखा पर जाएं। आवश्यक निर्भरता build.gradle.kts में इसे जोड़ा जाता है:

 implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:$kotlinCoroutinesVersion") implementation("org.jetbrains.kotlinx:kotlinx-coroutines-reactive:$kotlinCoroutinesVersion") implementation("org.jetbrains.kotlinx:kotlinx-coroutines-reactor:$kotlinCoroutinesVersion") 

और processRequest तरीका processRequest बदल जाता है:

 suspend fun processRequest(@RequestBody serviceRequest: ServiceRequest): Response = coroutineScope { //TODO() } 

इसे अब मोनो की आवश्यकता नहीं है और बस एक निलंबित समारोह (वसंत और कोटलिन के एकीकरण के लिए धन्यवाद) में अनुवाद करता है। यह ध्यान में रखते हुए कि हम विधि में अतिरिक्त coroutines बनाएंगे, हमें एक चाइल्ड स्काउट coroutineScope बनाने की आवश्यकता होगी (एक अतिरिक्त गुंजाइश बनाने के कारणों की समझ के लिए, संरचित संगणना पर रोमन एलिसेरोव का पोस्ट देखें)। कृपया ध्यान दें कि अन्य सेवा कॉल बिल्कुल नहीं बदले हैं। वे उसी मोनो को लौटाते हैं जिस पर क्वेरी के परिणाम के लिए वाट्सएप suspend विधि को "प्रतीक्षा" कहा जा सकता है।

यदि आपके लिए कॉरटॉयन्स अभी भी एक नई अवधारणा है, तो एक विस्तृत विवरण के साथ एक अद्भुत मार्गदर्शिका है । processRequest अपने स्वयं के कार्यान्वयन को लिखने की कोशिश करें। अधिक से अधिक विधि या spring-webflux-coroutines शाखा पर जाएं:

 suspend fun processRequest(@RequestBody serviceRequest: ServiceRequest): Response = coroutineScope { log.info("start") val userInfoDeferred = async { val authInfo = getAuthInfo(serviceRequest.authToken).awaitFirst() findUser(authInfo.userId).awaitFirst() } val paymentInfoDeferred = async { val cardFromInfoDeferred = async { findCardInfo(serviceRequest.cardFrom).awaitFirst() } val cardToInfoDeferred = async { findCardInfo(serviceRequest.cardTo).awaitFirst() } val cardFromInfo = cardFromInfoDeferred.await() sendMoney(cardFromInfo.cardId, cardToInfoDeferred.await().cardId, serviceRequest.amount).awaitFirst() getPaymentInfo(cardFromInfo.cardId).awaitFirst() } val userInfo = userInfoDeferred.await() val paymentInfo = paymentInfoDeferred.await() log.info("result") SuccessResponse( amount = paymentInfo.currentAmount, userName = userInfo.name, userSurname = userInfo.surname, userAge = userInfo.age ) } 

आप प्रतिक्रियात्मक दृष्टिकोण के साथ कोड की तुलना कर सकते हैं। कोरआउट के साथ, आपको अग्रिम में सभी शाखा बिंदुओं के बारे में नहीं सोचना होगा। हम सिर्फ await विधियों को कॉल कर सकते हैं और सही स्थानों में एसिंक्रोनस में अतुल्यकालिक कार्यों को शाखा कर सकते हैं। कोड मूल सीधा संस्करण के समान संभव है, जो बदलना मुश्किल नहीं है। और एक महत्वपूर्ण कारक यह है कि कोराउटीन बस प्रतिक्रियाशील कोड में एम्बेडेड होते हैं।

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

मैं यहां समाप्त करना चाहता हूं और अंत में उपयोगी लिंक छोड़ता हूं:

• Coroutine गाइड
• Coroutines रिएक्टर
• Coroutines CompletableFuture
• कोरटाइन के बारे में रोमन एलिसारोव
• कोटलिन फ्लो और कोराटाइन
• संरचित संगति
• स्प्रिंग बूट कोटलिन से प्यार है

मुझे आशा है कि आप रुचि रखते थे और आप सभी तरीकों के लिए विधि के कार्यान्वयन को स्वयं लिखने में कामयाब रहे। और, निश्चित रूप से, मैं यह विश्वास दिलाना चाहता हूं कि आपको कोरटाइन के साथ विकल्प अधिक पसंद है =)

अंत तक पढ़ने वाले सभी को धन्यवाद!