हमने सर्वर रेंडरिंग को कैसे देखा और इसका क्या हुआ

सभी को नमस्कार! वर्ष के दौरान, हमने रिएक्ट पर स्विच किया और इस बारे में सोचा कि यह कैसे सुनिश्चित किया जाए कि हमारे उपयोगकर्ता क्लाइंट टेम्प्लाइज़ेशन के लिए इंतजार नहीं करते थे, लेकिन पेज को जितनी जल्दी हो सके देखा। इस प्रयोजन के लिए, हमने सर्वर साइड रेंडरिंग (SSR - सर्वर साइड रेंडरिंग) करने और SEO को ऑप्टिमाइज़ करने का निर्णय लिया, क्योंकि सभी सर्च इंजन JS को निष्पादित करने में सक्षम नहीं हैं, और जो निष्पादन पर समय बिताने में सक्षम हैं, और प्रत्येक साइट का रेंगने का समय सीमित है।

मैं आपको याद दिलाता हूं कि क्लाइंट रेंडरिंग HTML तैयार करने के लिए सर्वर रेंडर पर सर्वर रेंडरिंग जावास्क्रिप्ट कोड का निष्पादन है। यह उपयोगकर्ता के प्रदर्शन को प्रभावित करता है, विशेष रूप से धीमी मशीनों और धीमे इंटरनेट पर। जेएस डाउनलोड, पार्स और निष्पादित होने तक इंतजार करने की कोई जरूरत नहीं है। ब्राउज़र केवल HTML को तुरंत रेंडर कर सकता है, जेएसए की प्रतीक्षा किए बिना, उपयोगकर्ता पहले से ही सामग्री पढ़ सकता है।
इस प्रकार, निष्क्रिय प्रतीक्षा चरण कम हो जाता है। रेंडर करने के बाद, ब्राउज़र को केवल समाप्त डोम के माध्यम से जाना होगा, यह जांचें कि यह क्या प्रदान किया गया था
क्लाइंट पर, और ईवेंट श्रोताओं को जोड़ें। इस प्रक्रिया को हाइड्रेशन कहा जाता है। यदि जलयोजन की प्रक्रिया में सर्वर से सामग्री और ब्राउज़र द्वारा उत्पन्न के बीच एक विसंगति है, तो हमें कंसोल में एक चेतावनी और क्लाइंट पर एक अतिरिक्त रेंडर मिलेगा। यह नहीं होना चाहिए, यह सुनिश्चित करना आवश्यक है कि सर्वर और क्लाइंट रेंडरिंग मैच के परिणाम। यदि वे विचलन करते हैं, तो इसे बग के रूप में माना जाना चाहिए, क्योंकि यह सर्वर रेंडरिंग के फायदे को नकारता है। यदि किसी भी तत्व को मोड़ना चाहिए, तो उसमें सप्रेसहाइड्रेशन जोड़ें suppressHydrationWarning={true} जोड़ें।

इसके अलावा, वहाँ एक चेतावनी है: सर्वर पर कोई window नहीं है। कोड जो इसे एक्सेस करता है उसे जीवन चक्र विधियों में निष्पादित किया जाना चाहिए जो सर्वर साइड पर नहीं कहा जाता है। अर्थात्, आप UNSAFE_componentWillMount () या, हुक के मामले में, uselayouteffect में window का उपयोग नहीं कर सकते।

वास्तव में, सर्वर-साइड रेंडरिंग प्रक्रिया बैकएंड से आरंभिक स्टेट प्राप्त करने के लिए उबलती है, इसे renderToString() माध्यम से renderToString() , तैयार इनिशियलस्टेट और HTML को आउटपुट में उठाती है, और क्लाइंट को भेजती है।

Hh.ru में, क्लाइंट JS के हाइक को केवल अजगर के एपि गेटवे में अनुमति है। यह सुरक्षा और लोड संतुलन के लिए है। पायथन पहले से ही डेटा के लिए आवश्यक बैकएंड पर जाता है, इसे तैयार करता है और इसे ब्राउज़र को देता है। Node.js का उपयोग केवल सर्वर रेंडरिंग के लिए किया जाता है। तदनुसार, डेटा तैयार करने के बाद, अजगर को नोड के लिए एक अतिरिक्त यात्रा की आवश्यकता होती है, परिणाम की प्रतीक्षा कर रहा है और ग्राहक को प्रतिक्रिया प्रेषित कर रहा है।

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

हमने अपनी सेवा को रोल आउट करने का तरीका जानने के बाद, हमने KOA पर सबसे सरल कोड लिखा, जो 200 देने में सक्षम था, और इसे ठेस पर अपलोड कर दिया। ऐसा लग रहा था:

 const Koa = require('koa'); const app = new Koa(); const SERVER_PORT = 9400; app.use(async (ctx) => { ctx.body = 'Hello World'; }); app.listen(SERVER_PORT); 

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

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

फिर हमने राउटिंग सर्वर सीखा। उचित संतुलन के लिए, आपको यह जानना होगा कि कौन से सर्वर इंस्टेंस जीवित हैं। इसे जांचने के लिए, हर कुछ सेकंड में ऑपरेशनल हार्ट बीट /status जाता है और प्रतिक्रिया में 200 प्राप्त करने की उम्मीद करता है। यदि सर्वर कॉन्फ़िगरेशन में निर्दिष्ट समय की संख्या से अधिक प्रतिक्रिया नहीं देता है, तो इसे संतुलन से हटा दिया जाता है। यह एक सरल कार्य, कुछ पंक्तियों और तैयार मार्ग के रूप में निकला:

 export default async function(ctx, next) { if (routeMap[ctx.request.path]) { routeMap[ctx.request.path](ctx); } else { ctx.throw(NOT_FOUND, getStatusText(NOT_FOUND)); } next(); } 

और हम सही url पर 200 का उत्तर देते हैं:

 export default (ctx) => { ctx.status = 200; ctx.body = '200'; }; 

उसके बाद, हमने एक प्रिमिटिव सर्वर बनाया जो <script> में स्टेट लौटा और HTML तैयार।

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

तब एक सुंदर शटडाउन के लिए प्रदान करना आवश्यक था - जब सर्वर बीमार हो जाता है, या जब रिलीज रोल करता है, तो सर्वर किसी भी अधिक आने वाले कनेक्शन को स्वीकार नहीं करता है, लेकिन उस पर लटकाए गए सभी अनुरोधों को करता है। एक नोड के लिए कई तैयार किए गए समाधान हैं। उन्होंने gracefulShutdown(app.listen(SERVER_PORT)) -शटडाउन लिया , जो कुछ भी करना था वह gracefulShutdown(app.listen(SERVER_PORT)) कॉल gracefulShutdown(app.listen(SERVER_PORT)) को लपेटने के लिए किया गया था।

इस बिंदु पर, हमें एक उत्पादन-तैयार समाधान मिला। यह कैसे काम करता है यह जांचने के लिए, उन्होंने एक पृष्ठ पर 5% उपयोगकर्ताओं के लिए सर्वर रेंडरिंग चालू किया। हमने मेट्रिक्स को देखा, महसूस किया कि उन्होंने मोबाइल फोन के लिए एफएमपी में काफी सुधार किया है, डेस्कटॉप के लिए मूल्य नहीं बदला है। उन्होंने प्रदर्शन का परीक्षण करना शुरू किया, पता चला कि एक सर्वर ~ 20 आरपीएस रखता है (यह तथ्य जाविस्टों के लिए बहुत ही मनोरंजक था)। ऐसा होने के कारणों का पता लगाया:

• मुख्य समस्याओं में से एक यह निकला कि वे NODE_ENV = उत्पादन के बिना बनाए गए थे (हम सर्वर निर्माण के लिए आवश्यक ईएनवी सेट करते हैं)। इस मामले में, प्रतिक्रिया गैर-उत्पादन विधानसभा देती है, जो लगभग 30% धीमी गति से चलती है।

  
  

• हमने नोड के संस्करण को 8 से 10 तक बढ़ा दिया, प्रदर्शन का एक और 20-25% मिला।

  
  

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

  
  

 if (cluster.isMaster) { cluster.on('exit', (worker, exitCode) => { if (exitCode !== SUCCESS) { cluster.fork(); } }); for (let i = 0; i < serverConfig.cpuCores; i++) { cluster.fork(); } } else { runApp(); } 

इस कोड में, मास्टर प्रक्रिया शुरू होती है, सर्वर के लिए आवंटित सीपीयू की संख्या के अनुसार प्रक्रियाएं शुरू होती हैं। यदि बच्चा प्रक्रिया में से एक क्रैश करता है - तो निकास कोड 0 नहीं है (हम खुद सर्वर बंद कर देते हैं), मास्टर प्रक्रिया इसे पुनरारंभ करती है।
और सर्वर के लिए आवंटित सीपीयू की संख्या के बारे में प्रदर्शन बढ़ता है।

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