जावा पूर्वी यूरोपीय सम्मेलन 2018: रिपोर्ट और इंप्रेशन

इगोर Masternaya, वरिष्ठ डेवलपर, DataArt जावा सामुदायिक नेता द्वारा पोस्ट किया गया

18-19 मई को, जेईईऑनफ को कीव में आयोजित किया गया था, जो पूर्वी यूरोप के पूरे जावा समुदाय के लिए सबसे प्रतीक्षित घटनाओं में से एक था। DataArt ने सम्मेलन के साथ भागीदारी की। दुनिया भर के वक्ताओं ने चार चरणों में बात की: वोल्कर सिमोनिस, जेसीपी में एसएपी प्रतिनिधि और ओपनजेडीके योगदानकर्ता, जुरगेन हॉलर, प्यिस्टल चीफ इंजीनियर, प्यारे स्प्रिंग फ्रेमवर्क के पिता, क्लाउस आइसेन, अपाचे कैमल के निर्माता, और लाइटबेंड में ह्यूग मैककी, इंजीलवादी।

शेड्यूल बहुत व्यस्त था: दो दिनों में 50 से अधिक प्रदर्शन, 45 मिनट प्रत्येक। 10 मिनट का ब्रेक - और एक नई रिपोर्ट पर चलता है। नेटवर्क पर दिखाई देने पर सभी वीडियो देखने में लंबा समय लगेगा। इसलिए, मैं उन रिपोर्टों का संक्षेप में वर्णन करूंगा जो मुझे सबसे दिलचस्प लगीं और जो मैंने व्यक्तिगत रूप से देखीं।

वसंत के 15 साल

सम्मेलन को जुरगेन होलर द्वारा खोला गया था। उन्होंने वसंत पसंदीदा के 15-वर्षीय (!) इतिहास के बारे में बात की, "पसंदीदा" XML से प्रतिक्रियाशील स्प्रिंग वेबफ्लक्स के संस्करण 0.9 में कॉन्फ़िगर किया गया, जो प्रतिक्रियाशील घोषणापत्र से प्रभावित अनुसंधान परियोजनाओं से उभरा। जुरगेन ने स्प्रिंग एमवीबी में स्प्रिंग एमवीसी और स्प्रिंग वेबफ्लक्स के सह-अस्तित्व के बारे में बात की, बताया कि उन्होंने उन्हें एक में एकीकृत नहीं करने का फैसला क्यों किया। मुद्दा यह है कि स्प्रिंग एमवीसी का मुख्य अमूर्त सर्वलेट एपीआई 3.0 और अवरुद्ध आईओ है, जबकि स्प्रिंग वेबफ्लक्स प्रतिक्रियाशील धाराओं और गैर-अवरुद्ध आईओ के अमूर्त का उपयोग करता है। आप किसी भी सर्वर पर SpringWebFlux पर अपनी सेवा चला सकते हैं जो गैर-अवरुद्ध IO का समर्थन करता है: Netty, Tomcat के नए संस्करण (> 8.5), जेट्टी। प्रतिक्रियाशील WebFlux नियंत्रकों को बनाना स्प्रिंग MVC का उपयोग करके उन्हें बनाने से बहुत अलग नहीं है, लेकिन अभी भी मतभेद हैं। उपयोगकर्ता के अनुरोध को संसाधित करना, प्रतिक्रियाशील नियंत्रक इसे सामान्य अर्थों में संसाधित नहीं करता है, लेकिन अनुरोध को संसाधित करने के लिए एक पाइपलाइन बनाता है। डिस्पैचर नियंत्रक विधि को कॉल करता है, जो एक पाइपलाइन बनाता है और तुरंत इसे प्रकाशक स्ट्रीम के रूप में देता है। प्रतिक्रियाशील वसंत में प्रकाशक धारा को दो सार के रूप में प्रस्तुत किया जाता है: फ्लक्स / मोनो। फ्लक्स वस्तुओं की एक धारा लौटाता है, जबकि मोनो हमेशा एक ही वस्तु देता है।

जुरगेन ने स्प्रिंग 5.0 के साथ काम करते समय जावा 8-शैली का उपयोग करने की सुविधा का भी उल्लेख किया और जुलाई 2018 में एक रिलीज़ उम्मीदवार स्प्रिंग 5.1 और सितंबर में एक रिलीज़ का वादा किया, जो जावा 11 का समर्थन करेगा और नए स्प्रिंग 5.0 सुविधाओं के ठीक ट्यूनिंग पर काम करेगा।

पायथन / जावा एकीकरण

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

• Jython (JVM पर पायथन) आउटडेटेड कोड बेस 2.7 बनाम CPython 3.6 के कारण फिट नहीं हुआ।
• उन्होंने जावा में डेटा साइंस के तर्क को फिर से लिखने के विकल्प पर विचार किया।
• अपाचे स्पार्क ने इसे नहीं लेने का फैसला किया, क्योंकि स्पीकर ने बताया, आप जावा और पायथन में लिखे वर्कलोड को नहीं मिला सकते हैं। हालांकि यह स्पष्ट नहीं है कि यूडीएफ और यूडीएफए [ 2 ] क्यों फिट नहीं हुए। इसके अलावा, स्पार्क फिट नहीं था, क्योंकि उनके पास पहले से ही किसी प्रकार की नौकरी की रूपरेखा थी, और वे वास्तव में एक नया परिचय नहीं देना चाहते थे। और, जैसा कि यह पता चला है, उनके पास बिग डेटा या तो नहीं है, और सभी प्रसंस्करण 100 एमबी फाइल के दयनीय आंकड़ों पर आ जाते हैं।

जावा से पाइथन प्रक्रिया के साथ संचार मेमोरी मैप्ड फ़ाइलों (एक फ़ाइल को इनपुट डेटा फ़ाइल के रूप में उपयोग किया जाता है) और कमांड (दूसरी फ़ाइल पायथन प्रक्रिया का आउटपुट है) का उपयोग करके आयोजित किया गया था। इस प्रकार, संचार कुछ इस प्रकार था:

  जावा: calcExr |  1 + javaFunc (sqrt (36))
 अजगर: 1 + जावाफंक्शन | 6 |
 जावा: 1 + सफलता 64 |
 पायथन: सफलता |  65 

इस तरह के एकीकरण की मुख्य समस्याएं, तमास ने क्रमांकन और इनपुट / आउटपुट मापदंडों के विचलन के दौरान ओवरहेड कहा।

जावा 10 ऐप सी.डी.एस.

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



OpenJDK 10 में सीडीएस के साथ कैसे खेलें, इस पर विवरण: ऐप सीडीएस में पाया जा सकता है। प्रक्रियाओं के बीच आवेदन वर्गों को विभाजित करने के अलावा, भविष्य में इसे जेईपी -250 में नजरबंद तारों को साझा करने की योजना है।
AppCDS की प्रमुख सीमाएँ:

1.5 तक की कक्षाओं के साथ काम नहीं करता है।

• आप फ़ाइलों (केवल .jar अभिलेखागार) से भरी हुई कक्षाओं का उपयोग नहीं कर सकते।
• क्लास लोडर द्वारा संशोधित कक्षाओं का उपयोग नहीं किया जा सकता है।
• कई वर्ग लोडर द्वारा भरी गई कक्षाओं को केवल एक बार पुन: उपयोग किया जा सकता है।
• बाइट-कोड पुनर्लेखन काम नहीं करता है, जिससे 2% तक की प्रदर्शन ड्रॉप हो सकती है। JDK-8074345

अपाचे स्पार्क के साथ प्राकृतिक भाषा प्रसंस्करण पाइपलाइन

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



रिपोर्ट का उद्देश्य यह दिखाना था कि एमएल-कार्यों के लिए एक प्रोटोटाइप बनाने के लिए आधुनिक रूपरेखाओं का उपयोग करना काफी सरल है, हालांकि, मानक पुस्तकालयों का उपयोग करते हुए, आप अभी भी कठिनाइयों में भागते हैं। उदाहरण के लिए:

• HadoopInputFormat लाइब्रेरी का उपयोग करते हुए WARC फ़ाइलों को पढ़ने के पहले चरण में, अवैध फ़ाइल हेडर के कारण कभी-कभी IllegalStateException क्रैश हो गई, लाइब्रेरी को फिर से लिखना पड़ा और गलत फ़ाइलों को छोड़ दिया गया।
• अमरूद पर निर्भरताएँ - भाषा की परिभाषा पुस्तकालय - उन निर्भरताओं से टकरा गई जो स्पार्क खुद पर हावी हो जाती है। जावा 8 ने मदद की, जिसकी मदद से उपयोग की गई लाइब्रेरी में अमरूद पर निर्भरता फेंकना संभव था।

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

ग्रेगल, ट्रफल, सबस्ट्रेट वीएम और अन्य भत्तों: वे क्या हैं और आपको उनकी आवश्यकता क्यों है

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

सबसे पहले, जावा मशीन द्वारा कोड निष्पादित करने की प्रक्रिया को याद करें और ध्यान दें कि जावा में पहले से ही दो कंपाइलर हैं: C1 (क्लाइंट कंपाइलर) और C2 (सर्वर कंपाइलर)। ग्रिल को C2 कंपाइलर के रूप में इस्तेमाल किया जा सकता है।



यह पूछे जाने पर कि हमें ओरेकल लैब्स के कर्मचारियों में से एक डॉ। क्रिस सीटोन को एक अन्य कंपाइलर की आवश्यकता क्यों है, लेख में बहुत अच्छी तरह से समझा गया कि हाउ ग्रास वर्क्स कैसे काम करता है । संक्षेप में, ग्रेगल परियोजना, साथ ही मेट्रोपोलिस परियोजना का मूल विचार जावा में C ++ में लिखे गए JVM कोड के कुछ हिस्सों को फिर से लिखना है। यह भविष्य में कोड को आसानी से पूरक करने के लिए संभव बना देगा। उदाहरण के लिए, अनुकूलन में से एक - पी आर्टियल एस्केप एनालिसिस - पहले से ही ग्रिल में है, लेकिन हॉटस्पॉट में नहीं - क्योंकि ग्रिल कोड का विस्तार करना सी 2 कोड की तुलना में बहुत आसान है ।

यह बहुत अच्छा लगता है, लेकिन मेरी परियोजना में यह कैसे काम करेगा, आप पूछते हैं? परियोजनाओं के लिए उपयुक्त है ग्रिल:

• जो बहुत कूड़े, बहुत सारी छोटी वस्तुओं का निर्माण करते हैं।
• जावा 8 की शैली में लिखा गया है, जिसमें धाराओं और लम्बदा का एक गुच्छा है।
• विभिन्न भाषाओं का उपयोग करना: रूबी, जावा, आर।

उत्पादन में सबसे पहले, ग्रिल का उपयोग ट्विटर पर किया जाने लगा। आप इस बारे में और अधिक पढ़ सकते हैं, जो कि Habré ( interview_1 और interview_2 ) पर प्रकाशित क्रिश्चियन टैलिंगर के साथ एक साक्षात्कार में है। वहां, वे बताते हैं कि C2 को ग्रेगल के साथ बदलकर, ट्विटर ने लगभग 8% CPU उपयोग की बचत शुरू कर दी, जो संगठन के आकार को देखते हुए बहुत अच्छा है।

सम्मेलन में, हम इसके तहत एक स्कैला बेंचमार्क लॉन्च करके ग्रेगल की गति को सत्यापित करने में भी सक्षम थे - स्काला डेकोपो । नतीजतन, ग्रेगल पर, बेंचमार्क ~ 7000 एमएस में पारित हो गया, और ~ 14000 एमएस में एक नियमित जेवीएम पर! ऐसा क्यों हुआ, आप gclog परीक्षणों को देखकर देख सकते हैं। ग्रेपल का उपयोग करते समय आवंटन आवंटन की संख्या हॉटस्पॉट की तुलना में काफी कम है। हालाँकि, आप अभी भी यह नहीं कह सकते कि ग्रिल आपके जावा एप्लिकेशन की प्रदर्शन समस्याओं का समाधान होगा। ओलेग ने अपनी रिपोर्ट में विफलता की कहानी भी दिखाई, ग्रिल के तहत अपाचे इग्नाइट के काम की तुलना की और इसके बिना - ध्यान देने योग्य प्रदर्शन परिवर्तन नहीं हुआ।

डिजाइनिंग फॉल्ट टॉलेरेंट माइक्रोसिस्टर्सेज

AppsFlyer से Orkhan Gasimov द्वारा विफल-सुरक्षित माइक्रोसवर्क वास्तुकला पर एक और रिपोर्ट पढ़ी गई। उन्होंने वितरित अनुप्रयोगों के निर्माण के लिए लोकप्रिय डिज़ाइन पैटर्न पेश किए। हम उनमें से कई को अच्छी तरह से जान सकते हैं, लेकिन घूमना और उनमें से प्रत्येक को याद करना बिल्कुल भी दुख नहीं होगा।

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

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

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

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

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

वर्णित पैटर्न के अलावा, निम्नलिखित उल्लिखित थे:

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

एक्का और जावा के साथ क्लस्टरिंग इवेंट सोर्सिंग और सीक्यूआरएस

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



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

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

आइए अक्का और CQRS पर बैंकिंग प्रणाली के प्रोटोटाइप के लिए वापस आएं। सिस्टम में बैंक / खाते / संभावित टीम के प्रत्येक ग्राहक को एक (!) अभिनेता द्वारा दर्शाया जाएगा। एक बड़ा बैंक सैकड़ों हजारों खातों का समर्थन कर सकता है, और यह अक्का के लिए कोई समस्या नहीं होगी। आउट-ऑफ-द-बॉक्स फ्रेमवर्क क्लस्टरिंग का समर्थन करता है और सैकड़ों जेवीएम पर चलाया जा सकता है। यदि क्लस्टर में एक मशीन विफल हो जाती है, तो अक्का विशेष तंत्र प्रदान करता है जो स्वचालित रूप से ऐसी स्थितियों का जवाब देता है: हमारे मामले में, क्लाइंट के अभिनेता को क्लस्टर में किसी भी उपलब्ध मशीन पर फिर से बनाया जा सकता है, और इसकी स्थिति रिपॉजिटरी से फिर से पढ़ी जाएगी।

एक अभिनेता के लिए एक अलग धागा नहीं बनाया गया है - यह एक जेवीएम के भीतर दसियों हजारों अभिनेताओं का समर्थन करना संभव बनाता है। उसी समय, अभिनेता गारंटी देता है कि अनुरोधों की प्राप्ति के क्रम में प्रत्येक अनुरोध को अलग से (!) संसाधित किया जाएगा। यह गारंटी स्वचालित रूप से संभावित दौड़ की शर्तों को समाप्त कर देती है जब प्रसंस्करण अनुरोध। आप GitHub में लिंक का उपयोग करके इसके कोड को खोलकर सिस्टम के प्रोटोटाइप को अधिक विस्तार से समझ सकते हैं। प्रत्येक उपप्रोजेक्ट एक प्रोटोटाइप के निर्माण के सबसे जटिल चरणों के कार्यान्वयन को दर्शाता है:

• वितरित एक्टर्स एक्का क्लस्टरिंग अक्का क्लस्टर ' ए ' बनाने का एक सरल उदाहरण है।
• अक्का क्लस्टर सिंगलटन दिखाता है कि एक वितरित अक्का वातावरण में एक सिंगलटन पैटर्न कैसे लागू किया जाए।
• इकाई वितरित शार्पिंग अक्का क्लस्टर शेरिंग एक क्लस्टर में संस्थाओं के वितरण के प्रबंधन और क्लाइंट अनुरोधों के मार्ग का एक उदाहरण है।
• CQRS - साइड एक्का दृढ़ता लिखें - रिपॉजिटरी में रिकॉर्ड घटनाओं।
• CQRS - साइड एक्का दृढ़ता प्रश्न - प्रसंस्करण क्लाइंट अनुरोध पढ़ें

HAVO।

सभी रिपोर्टों के रिकॉर्ड कुछ हफ्तों के भीतर ऑनलाइन दिखाई देंगे। मुझे उम्मीद है कि यह लेख आपको देखने के क्रम को निर्धारित करने में मदद करेगा, खासकर जब से मुझे लगता है कि यह प्रदर्शन देखने लायक है।