New Odnoklassniki फ्रंटेंड: जावा में रिएक्ट लॉन्च करना। भाग I

कई लोगों ने ग्रेवालम का नाम सुना है, लेकिन अभी तक सभी को उत्पादन में इस तकनीक का प्रयास करने का मौका नहीं मिला है। Odnoklassniki के लिए, यह तकनीक पहले से ही "पवित्र कब्र" बन गई है जो फ्रंट-एंड बदलती है।

इस लेख में मैं इस बारे में बात करना चाहता हूं कि कैसे हम जावा और जावास्क्रिप्ट के साथ दोस्त बनाने में कामयाब रहे, और बहुत सारी विरासत कोड के साथ एक विशाल प्रणाली की ओर पलायन करना शुरू कर दिया, और इस तरह से GraalVM कैसे मदद करता है।

लेख लिखने के समय, यह पता चला कि सामग्री का पूरा खंड HABR के पारंपरिक आकार में फिट नहीं है और यदि आप पूरे प्रकाशन को प्रकाशित करते हैं, तो इसे पढ़ने में कई घंटे लगेंगे। इसलिए, हमने लेख को 2 भागों में विभाजित करने का निर्णय लिया।

पहले भाग से आप Odnoklassniki के फ्रंट-एंड के इतिहास के बारे में जानेंगे और इसकी ऐतिहासिक विशेषताओं से परिचित होंगे, परियोजना के 11 वर्षों में हमारे सामने आई समस्याओं का समाधान खोजने के रास्ते से गुजरेंगे, और बहुत ही अंत में आप हमारे द्वारा लिए गए निर्णय के सर्वर कार्यान्वयन की तकनीकी विशेषताओं से रूबरू होंगे।

प्रागितिहास

Odnoklassniki का पहला संस्करण 13 साल पहले, 2006 में दिखाई दिया था। साइट को .NET पर बनाया गया था, तब साइट पर कोई जावास्क्रिप्ट नहीं था, सब कुछ सर्वर रेंडरिंग पर था।



एक साल बाद, Odnoklassniki के एक मिलियन से अधिक उपयोगकर्ता थे। 2007 में, ये अविश्वसनीय संख्याएं थीं, और साइट, लोड को झेलने में असमर्थ थी, गिरने लगी। डेवलपर्स ने समस्या को हल किया। लातवियाई कंपनी फोर्टिकॉम द्वारा बनाई गई वन.एलवी परियोजना की मदद से, जिसकी मुख्य दक्षताओं में जावा विकास था। इसलिए, Odnoklassniki, यह .NET से जावा को फिर से लिखने का निर्णय लिया गया था।

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

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

बेशक, न्यूनतम जावास्क्रिप्ट के बिना पर्याप्त नहीं था। पॉप-अप बनाने के लिए, जोड़तोड़ की आवश्यकता होती है: उदाहरण के लिए, एक div प्रदर्शन पर मँडरा करके: ब्लॉक को लटका दिया गया था या यह प्रदर्शन के साथ छिपा हुआ था: कोई नहीं।

लेकिन उसी समय, सर्वर से पॉप-अप की सामग्री का अनुरोध किया गया था, सभी व्यावसायिक तर्क वहां थे और जावा में थे।

2018

12 वर्षों के बाद, Odnoklassniki 70 मिलियन से अधिक उपयोगकर्ताओं के साथ एक विशाल सेवा में बदल गया। हमारे पास 4 डेटा केंद्रों में 7,000 से अधिक मशीनें हैं, और प्रति सेकंड केवल 600 हजार अनुरोध OK.RU के सामने के अंत में आते हैं।

Odnoklassniki का फ्रंट-सर्वर जावा में काम करना जारी रखता है, और अकेले मोर्चों का कोड आधार दो मिलियन लाइनों से अधिक है।



क्लाइंट साइड पर लागू की गई प्रौद्योगिकियाँ भी स्थिर नहीं रहीं: कई समाधान विभिन्न पुस्तकालयों का उपयोग करते हुए दिखाई दिए: GWT, jQuery, DotJs, आवश्यकताएँ और कई अन्य।

उस समय, React, Angular और Vue जैसे मानक सामान्य नहीं थे, प्रत्येक डेवलपर ने सभी उपलब्ध उपकरणों का उपयोग करके इष्टतम समाधान खोजने की कोशिश की।

यह स्पष्ट हो गया कि इसके साथ रहना बहुत मुश्किल है, क्योंकि बड़ी संख्या में समस्याएं जमा हुई हैं:

• कई पुराने पुस्तकालय
• एक भी ढांचा नहीं है
• कोई समसामयिकता (चूंकि बैकएंड जावा में है, क्लाइंट जेएस में है)
• क्लाइंट पर कोई एकल संरचित अनुप्रयोग नहीं है
• खराब जवाबदेही
• अपर्याप्त उपकरण
• उच्च प्रवेश दहलीज

दुनिया पहले से ही 2018 में थी और इसे बदलना आवश्यक था।

तकनीकी विचारों की सभी शक्ति का उपयोग करते हुए, हमने समस्याओं को हल करने के लिए चार बुनियादी आवश्यकताओं के माध्यम से सोचा और तैयार किया:

1. सहपाठियों के पास यूआई के लिए आइसोमॉर्फिक कोड होना चाहिए। क्योंकि जावा में सर्वर को लगातार लिखना असंभव है, और फिर, यदि आपको किसी प्रकार की गतिशीलता जोड़ने की आवश्यकता है, तो क्लाइंट पर एक ही चीज़ खेलें।
2. एक सहज संक्रमण की जरूरत है। क्योंकि Odnoklassniki के दूसरे संस्करण को जल्दी से बनाना और स्विच करना असंभव है
3. सर्वर रेंडरिंग की आवश्यकता है (उस पर और अधिक)
4. नए समाधान, लोहे की समान मात्रा पर काम करना, हमारे भार के तहत प्रदर्शन और दोष सहनशीलता को कम नहीं करना चाहिए।

सर्वर-साइड रेंडरिंग क्यों?

Odnoklassniki में कई उपयोगकर्ता हैं जो मॉस्को से बहुत दूर रहते हैं और उनके पास हमेशा अच्छा इंटरनेट नहीं है।



सर्वर रेंडरिंग से इन यूजर्स को तेजी से कंटेंट हासिल करने में मदद मिलेगी। जबकि चित्र लोड किए गए हैं, वे कुछ पढ़ना शुरू कर पाएंगे:



हमने प्रयोगों की एक श्रृंखला आयोजित की, यह समझने की कोशिश की कि क्या होगा यदि कुछ डेटा (उदाहरण के लिए, टेप) पहले से ही ग्राहक को एक उम्मीद के साथ दिया गया था। नतीजतन, यह पता चला कि यह नकारात्मक रूप से प्रभावित उपयोगकर्ता गतिविधि है।

सर्वर अब कैसे काम करता है

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

एपीआई डेटा को बाहर निकालता है, वेब को देता है। वेब जावा पेजों को जावा इंजन के साथ जेनरेट करता है और इसे ब्राउजर को देता है।

यह सब अब 200 एमएस से कम लगता है।

समाधान के लिए खोजें

सबसे पहले, विगेट्स पर आधारित प्रवासन की अवधारणा विकसित की गई थी।

आवेदन छोटे टुकड़ों में साइट पर दिए जाएंगे। अंदर उन्हें एक नए स्टैक पर लिखा जाएगा। और बाकी साइट के लिए यह केवल एक DOM तत्व होगा जिसमें कुछ प्रकार के कस्टम व्यवहार होंगे।



यह <video> टैग के समान होगा: विशेषताएँ, विधियों और घटनाओं के साथ एक कस्टम DOM तत्व। परिणामस्वरूप, DOM API बाहर स्थित होता है, जबकि विजेट कार्यक्षमता नए स्टैक पर अंदर लागू होती है।

कौन सा स्टैक चुनना है?

अब जिस अवधारणा को लागू करने की आवश्यकता थी, उन्होंने विकल्पों को छाँटना शुरू कर दिया।

Kotlin

पहला प्रोटोटाइप कोटलिन में बनाया गया था। यह विचार इस प्रकार था: नए घटकों के लिए, कोटलिन में तर्क लिखें, और XML में घटक मार्कअप का वर्णन करें। जेवीएम में मौजूदा टेम्पलेट इंजन का उपयोग करके सर्वर पर सब कुछ चलाया जा सकता है, और क्लाइंट के लिए इसे जावास्क्रिप्ट में ट्रांसपोज़ किया जा सकता है।



उच्च प्रविष्टि सीमा के साथ एक नई भाषा शुरू करने के अलावा, कोटलिन जावास्क्रिप्ट के साथ काम करने के लिए अपर्याप्त रूप से विकसित किए गए उपकरण हैं, और बहुत कुछ स्वतंत्र रूप से विकसित करना होगा।

इसलिए, दुर्भाग्य से, इस अवधारणा को छोड़ना पड़ा।

Node.js

एक अन्य विकल्प Node.js या दूसरा रनटाइम डालना है, उदाहरण के लिए, डार्ट। लेकिन क्या होता है?

Node.js. का उपयोग करने के दो तरीके हैं
पहला तरीका यह है कि जावा अनुप्रयोग के समान सर्वर पर चल रहे Node.js पर घटक के प्रतिपादन को सौंप दिया जाए। इस प्रकार, हम जावा में एप्लिकेशन को सेव करते हैं और बस HTML रेंडर करने की प्रक्रिया में हम स्थानीय रूप से Node.js. पर चलने वाली सेवा को कॉल करते हैं।

हालाँकि, इस दृष्टिकोण के साथ कई समस्याएं हैं:

1. Node.js को दूरस्थ कॉल में क्रमांकन / इनपुट को डीरिशियल करना शामिल है। उदाहरण के लिए, यह डेटा बहुत ही चमकदार हो सकता है, जब जेएस में एक नया घटक जावा में लागू पुराने घटक के आसपास एक आवरण होता है।
2. एक रिमोट कॉल, यहां तक ​​कि एक स्थानीय मशीन पर, मुफ्त में दूर है, और एक अतिरिक्त देरी का भी परिचय देता है। यदि पृष्ठ पर दर्जनों या सैकड़ों ऐसे घटक हैं, यहां तक ​​कि बहुत ही सरल भी हैं, तो हम उपयोगकर्ता के अनुरोध को संसाधित करने में ओवरहेड और देरी को काफी बढ़ाएंगे।
3. इसके अलावा, इस तरह की प्रणाली का संचालन काफी जटिल है, क्योंकि एक ही प्रक्रिया के बजाय हमें जावा में एक प्रक्रिया और कई प्रक्रियाओं में Node.js. तदनुसार, सभी ऑपरेशन बहुत अधिक जटिल हो जाते हैं, उदाहरण के लिए: तैनाती, परिचालन संकेतक का संग्रह, लॉग विश्लेषण, त्रुटि निगरानी, ​​आदि।

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





यह पता चला है कि Node.js को निम्नलिखित कारणों से इस्तेमाल नहीं किया जा सकता है:

• Serialization / deserialization अतिरिक्त कार्यभार और देरी है
• Node.js Odnoklassniki के विशाल वितरित सिस्टम में एक और घटक है

हमारे पास पहले से ही कई विशेषज्ञ हैं जो जानते हैं कि जावा को कैसे "पकाना" है, और अब हमें एक कर्मचारी नियुक्त करना होगा जो Node.js को संचालित करेगा और मौजूदा एक के अलावा एक और बुनियादी ढांचा तैयार करेगा।

JVM में जावास्क्रिप्ट

लेकिन क्या होगा अगर आप JVM के अंदर जावास्क्रिप्ट चलाने की कोशिश करें? यह पता चला है कि जावा और जावास्क्रिप्ट कोड को एक प्रक्रिया में निष्पादित किया जाएगा और न्यूनतम ओवरहेड के साथ बातचीत की जाएगी।

यह जावा के टुकड़ों को जावास्क्रिप्ट के साथ वर्तमान WEB के अंदर आसानी से बदल देगा।
जेएस घटकों जावा से डेटा प्राप्त करेंगे और HTML उत्पन्न करेंगे। वे ग्राहक और सर्वर दोनों पर समसामयिक रूप से काम करने में सक्षम होंगे।

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

जेवीएम के लिए कई जेएस रनटाइम हैं: दो राइनो, नैशॉर्न और राइनो (ओरेकल से एक, मोज़िला से दूसरे) और ताजा ग्रेवालम।



जेवीएम के लिए जेएस रनमाइन्स के लाभ:

• सब कुछ जेवीएम में काम करता है, और इसमें हमारी बहुत विशेषज्ञता है।
• निःशुल्क जावा और जावास्क्रिप्ट बातचीत
• सुरक्षित रनटाइम
• GraalVM के मामले में जावा कंपाइलर

आगे यह गति में इन runtimes की तुलना करने के लिए पर्याप्त था। यह पता चला कि ग्रैल् वीएम व्यापक अंतर से सभी से आगे है:

GraalVM क्या है?

GraalVM एक उच्च प्रदर्शन रनटाइम है जो विभिन्न भाषाओं में कार्यक्रमों का समर्थन करता है। इसमें JVM के लिए भाषा संकलक लिखने की रूपरेखा है। इसके लिए धन्यवाद, जावा, कोटलिन, जेएस, पायथन और एक ही जेवीएम के भीतर अन्य भाषाओं में कार्यक्रमों के निष्पादन का समर्थन किया जाता है।

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

GraalVM हमें सर्वर पर UI प्रदान करने के लिए JS चलाने की अनुमति देता है। एक पुस्तकालय के रूप में हम रिएक्ट का उपयोग करते हैं।

ऐसे बंडल के फायदे:

• कोई नई भाषा नहीं जोड़ी गई: अभी भी जावा और जावास्क्रिप्ट
• बड़ा समुदाय: हर कोई रिएक्ट जानता है
• कम प्रवेश दहलीज
• आसानी से एक टीम में सहयोगियों की तलाश करें
• ऑपरेशन जटिल नहीं है

GraalVM में रनिंग रिएक्ट

GraalVM के अंदर, आप एक प्रसंग बना सकते हैं - एक अलग कंटेनर जिसमें प्रोग्राम अतिथि भाषा में चलेगा। हमारे मामले में, अतिथि भाषा JS है:

Context context = Context.create("js"); //  global   Value js = context.getBindings("js"); 

संदर्भ के साथ बातचीत करने के लिए, इसकी वैश्विक वस्तु का उपयोग किया जाता है:

 //    global js.putMember("serverProxy", serverProxy); //    global Value app = js.getMember("app"); 

आप मॉड्यूल कोड को संदर्भ में लोड कर सकते हैं:

 //     Value load = js.getMember("load"); //     load.execute(pathToModule); 

या, "zap-eval-it" कोई भी कोड है:

 context.eval("js", someCode); 

जेएस सर्वर प्रतिपादन: अवधारणा

JVM में एक जावास्क्रिप्ट संदर्भ बनाएं और उसमें रिएक्ट एप्लिकेशन मॉड्यूल कोड लोड करें। हम जावा से जेएस के लिए आवश्यक कार्यों और विधियों को फेंक देते हैं। फिर इस संदर्भ से हम इस मॉड्यूल के JS फ़ंक्शन रेंडर () का लिंक निकालते हैं, ताकि बाद में हम इसे जावा से कॉल कर सकें।



जब उपयोगकर्ता किसी पृष्ठ का अनुरोध करता है, तो सर्वर टेम्पलेट इंजन शुरू होता है, वह आवश्यक डेटा के साथ आवश्यक घटकों के रेंडर () फ़ंक्शन को कॉल करता है, उनसे HTML कोड प्राप्त करता है और उपयोगकर्ता को पूरे पृष्ठ के HTML के साथ देता है।

जेएस सर्वर प्रतिपादन: कार्यान्वयन

Odnoklassniki के सर्वर टेम्पलेट इंजन में, HTML मार्कअप के रूप में लेआउट लिखा जाता है। जेएस अनुप्रयोगों को सामान्य मार्कअप से अलग करने के लिए, हम कस्टम टैग का उपयोग करते हैं।
जब टेम्पलेट इंजन एक कस्टम टैग का सामना करता है, तो संबंधित मॉड्यूल को रेंडर करने के लिए एक कार्य बनाया जाता है। इसे थ्रेड्स के एक पूल में भेजा जाता है, जिनमें से प्रत्येक का अपना जेएस संदर्भ होता है, एक मुक्त थ्रेड पर निष्पादित होता है, इसमें एक घटक प्रदान करता है, और इसे क्लाइंट को देता है।

मुझे एक संदर्भ पूल की आवश्यकता क्यों है

घटक को एक धागे में सिंक्रोनाइज़ किया जाता है। इस समय, JS प्रतिपादन संदर्भ व्यस्त है। इसलिए, कई स्वतंत्र संदर्भों को बनाकर, आप जावा मल्टीथ्रेडिंग क्षमताओं का उपयोग करके घटक प्रतिपादन को समानांतर कर सकते हैं।



जावा डेटा अधिग्रहण कार्यों को प्रत्येक संदर्भ के संदर्भ में पारित किया जाता है। परिणाम एक प्रक्रिया के अंदर कूल बहु-थ्रेडेड जावास्क्रिप्ट है।

नए फ्रंटेंड के क्लाइंट भाग का कार्यान्वयन इस अवधारणा पर कैसे बनाया गया है, हम अगले लेख में वर्णन करेंगे।

जारी रखा जाए