रोडरनर: पीएचपी मरण्यासाठी किंवा बचावासाठी गोलंग तयार केलेले नाही

अहो हाब्र! आम्ही Badoo येथे सक्रिय आहोत PHP कामगिरीवर काम करत आहे, कारण या भाषेत आमच्याकडे बर्‍यापैकी मोठी प्रणाली आहे आणि कार्यप्रदर्शन समस्या ही पैशांची बचत करणारी समस्या आहे. दहा वर्षांपूर्वी, आम्ही यासाठी PHP-FPM तयार केले, जे प्रथम PHP साठी पॅचचा संच होता आणि नंतर अधिकृत वितरणात प्रवेश केला.

अलिकडच्या वर्षांत, PHP ने खूप प्रगती केली आहे: कचरा संग्राहक सुधारला आहे, स्थिरतेची पातळी वाढली आहे - आज आपण कोणत्याही समस्यांशिवाय PHP मध्ये डिमन आणि दीर्घकालीन स्क्रिप्ट लिहू शकता. यामुळे स्पायरल स्काउटला आणखी पुढे जाण्याची परवानगी मिळाली: रोडरनर, PHP-FPM च्या विपरीत, विनंत्यांमधील मेमरी साफ करत नाही, ज्यामुळे अतिरिक्त कार्यप्रदर्शन लाभ मिळतो (जरी हा दृष्टिकोन विकास प्रक्रिया गुंतागुंतीत करतो). आम्ही सध्या या साधनासह प्रयोग करत आहोत, परंतु आमच्याकडे अद्याप सामायिक करण्यासाठी कोणतेही परिणाम नाहीत. त्यांची वाट पाहणे अधिक मनोरंजक बनविण्यासाठी, आम्ही स्पायरल स्काउट कडून रोडरनर घोषणेचे भाषांतर प्रकाशित करतो.

लेखातील दृष्टीकोन आपल्या जवळ आहे: आमच्या समस्या सोडवताना, आम्ही बहुतेकदा PHP आणि Go चा एक समूह देखील वापरतो, दोन्ही भाषांचे फायदे मिळवितो आणि एकाला दुसर्‍याच्या बाजूने न सोडता.

आनंद घ्या!

गेल्या दहा वर्षांत आम्ही यादीतून कंपन्यांसाठी अर्ज तयार केले आहेत फॉर्च्यून 500, आणि 500 ​​पेक्षा जास्त वापरकर्ते नसलेल्या प्रेक्षक असलेल्या व्यवसायांसाठी. या सर्व काळात, आमचे अभियंते प्रामुख्याने PHP मध्ये बॅकएंड विकसित करत आहेत. परंतु दोन वर्षांपूर्वी, आमच्या उत्पादनांच्या कार्यक्षमतेवरच नव्हे तर त्यांच्या स्केलेबिलिटीवरही काही गोष्टींचा मोठा प्रभाव पडला होता - आम्ही आमच्या तंत्रज्ञान स्टॅकमध्ये गोलंग (गो) सादर केले.

जवळजवळ लगेच, आम्हाला आढळले की Go ने आम्हाला 40x पर्यंत कार्यप्रदर्शन सुधारणांसह मोठे अनुप्रयोग तयार करण्याची परवानगी दिली. यासह, आम्ही PHP मध्ये लिहिलेल्या विद्यमान उत्पादनांचा विस्तार करू शकलो, दोन्ही भाषांचे फायदे एकत्र करून त्यांना सुधारित करू शकलो.

Go आणि PHP चे संयोजन वास्तविक विकास समस्यांचे निराकरण करण्यात कशी मदत करते आणि ते आमच्यासाठी एक साधन कसे बनले आहे जे काही समस्यांपासून मुक्त होऊ शकते हे आम्ही तुम्हाला सांगू. PHP मरणार मॉडेल.

तुमचे दैनंदिन PHP विकास वातावरण

आपण PHP मरणा-या मॉडेलचे पुनरुज्जीवन करण्यासाठी गो कसे वापरू शकता याबद्दल बोलण्यापूर्वी, आपल्या डीफॉल्ट PHP विकास वातावरणावर एक नजर टाकूया.

बर्‍याच प्रकरणांमध्ये, तुम्ही तुमचा अनुप्रयोग nginx वेब सर्व्हर आणि PHP-FPM सर्व्हरचे संयोजन वापरून चालवता. पूवीर् स्थिर फायली सर्व्ह करते आणि विशिष्ट विनंत्या PHP-FPM वर पुनर्निर्देशित करते, तर PHP-FPM स्वतः PHP कोड कार्यान्वित करते. तुम्ही Apache आणि mod_php चे कमी लोकप्रिय संयोजन वापरत असाल. परंतु हे थोडे वेगळे कार्य करत असले तरी, तत्त्वे समान आहेत.

PHP-FPM ऍप्लिकेशन कोड कसे कार्यान्वित करते ते पाहू. जेव्हा एखादी विनंती येते, तेव्हा PHP-FPM PHP चाइल्ड प्रक्रिया सुरू करते आणि विनंतीचे तपशील त्याच्या स्थितीचा भाग म्हणून पास करते (_GET, _POST, _SERVER, इ.).

PHP स्क्रिप्टच्या अंमलबजावणीदरम्यान स्थिती बदलू शकत नाही, म्हणून इनपुट डेटाचा नवीन संच मिळविण्याचा एकच मार्ग आहे: प्रक्रिया मेमरी साफ करून आणि ते पुन्हा सुरू करून.

या अंमलबजावणी मॉडेलचे बरेच फायदे आहेत. तुम्हाला मेमरी वापराबद्दल जास्त काळजी करण्याची गरज नाही, सर्व प्रक्रिया पूर्णपणे वेगळ्या आहेत, आणि जर त्यापैकी एक "मृत्यू" असेल तर ती आपोआप पुन्हा तयार होईल आणि उर्वरित प्रक्रियांवर त्याचा परिणाम होणार नाही. परंतु या दृष्टिकोनाचे तोटे देखील आहेत जे अनुप्रयोग मोजण्याचा प्रयत्न करताना दिसतात.

नियमित PHP पर्यावरणाचे तोटे आणि अकार्यक्षमता

जर तुम्ही प्रोफेशनल PHP डेव्हलपर असाल तर फ्रेमवर्कच्या निवडीसह नवीन प्रोजेक्ट कोठे सुरू करायचा हे तुम्हाला माहीत आहे. यात अवलंबित्व इंजेक्शन लायब्ररी, ORM, भाषांतरे आणि टेम्पलेट्स असतात. आणि, अर्थातच, सर्व वापरकर्ता इनपुट एका ऑब्जेक्टमध्ये (सिम्फनी/HttpFoundation किंवा PSR-7) सोयीस्करपणे ठेवले जाऊ शकतात. फ्रेमवर्क छान आहेत!

पण प्रत्येक गोष्टीची किंमत असते. कोणत्याही एंटरप्राइझ-स्तरीय फ्रेमवर्कमध्ये, साध्या वापरकर्त्याच्या विनंतीवर प्रक्रिया करण्यासाठी किंवा डेटाबेसमध्ये प्रवेश करण्यासाठी, तुम्हाला किमान डझनभर फाइल्स लोड कराव्या लागतील, असंख्य वर्ग तयार करावे लागतील आणि अनेक कॉन्फिगरेशन पार्स कराव्या लागतील. परंतु सर्वात वाईट गोष्ट अशी आहे की प्रत्येक कार्य पूर्ण केल्यानंतर, आपल्याला सर्वकाही रीसेट करणे आणि पुन्हा प्रारंभ करणे आवश्यक आहे: आपण नुकतेच सुरू केलेले सर्व कोड निरुपयोगी ठरतात, त्याच्या मदतीने आपण यापुढे दुसर्‍या विनंतीवर प्रक्रिया करणार नाही. इतर भाषेत लिहिणाऱ्या कोणत्याही प्रोग्रामरला हे सांगा, आणि तुम्हाला त्याच्या चेहऱ्यावर विलक्षणपणा दिसेल.

PHP अभियंते चतुर आळशी-लोडिंग तंत्रे, मायक्रोफ्रेमवर्क, ऑप्टिमाइझ लायब्ररी, कॅशे इ. वापरून या समस्येचे निराकरण करण्यासाठी अनेक वर्षांपासून मार्ग शोधत आहेत. परंतु शेवटी, तुम्हाला अद्याप संपूर्ण अनुप्रयोग रीसेट करावा लागेल आणि पुन्हा पुन्हा सुरू करावे लागेल. . (अनुवादकाची टीप: ही समस्या अंशतः च्या आगमनाने सोडवली जाईल प्रीलोड PHP 7.4 मध्ये)

Go सह PHP एकापेक्षा जास्त विनंती टिकून राहू शकते का?

PHP स्क्रिप्ट लिहिणे शक्य आहे जे काही मिनिटांपेक्षा जास्त काळ जगतात (तास किंवा दिवसांपर्यंत): उदाहरणार्थ, क्रॉन टास्क, CSV पार्सर, क्यू ब्रेकर्स. ते सर्व समान परिस्थितीनुसार कार्य करतात: ते कार्य पुनर्प्राप्त करतात, ते कार्यान्वित करतात आणि पुढील कार्याची प्रतीक्षा करतात. कोड नेहमी मेमरीमध्ये राहतो, मौल्यवान मिलिसेकंद वाचवतो कारण फ्रेमवर्क आणि ऍप्लिकेशन लोड करण्यासाठी अनेक अतिरिक्त पायऱ्या आवश्यक असतात.

पण दीर्घायुषी लिपी विकसित करणे सोपे नाही. कोणतीही त्रुटी प्रक्रिया पूर्णपणे नष्ट करते, मेमरी लीकचे निदान करणे त्रासदायक आहे आणि F5 डीबगिंग यापुढे शक्य नाही.

PHP 7 च्या रिलीझसह परिस्थिती सुधारली आहे: एक विश्वासार्ह कचरा संग्राहक दिसू लागला आहे, त्रुटी हाताळणे सोपे झाले आहे आणि कर्नल विस्तार आता लीक-प्रूफ आहेत. खरे आहे, अभियंत्यांना अजूनही मेमरीबद्दल सावधगिरी बाळगणे आणि कोडमधील राज्य समस्यांबद्दल जागरूक असणे आवश्यक आहे (या गोष्टींकडे दुर्लक्ष करू शकेल अशी भाषा आहे का?). तरीही, PHP 7 मध्ये आमच्यासाठी कमी आश्चर्य आहेत.

दीर्घायुषी PHP स्क्रिप्ट्ससह काम करण्याचे मॉडेल घेणे, HTTP विनंत्यांवर प्रक्रिया करणे यासारख्या क्षुल्लक कामांमध्ये ते जुळवून घेणे आणि त्याद्वारे प्रत्येक विनंतीसह सर्वकाही सुरवातीपासून लोड करण्याची गरज दूर करणे शक्य आहे का?

या समस्येचे निराकरण करण्यासाठी, आम्हाला प्रथम एक सर्व्हर ऍप्लिकेशन लागू करणे आवश्यक आहे जे HTTP विनंत्या स्वीकारू शकेल आणि त्यांना प्रत्येक वेळी न मारता PHP कार्यकर्त्याकडे एक-एक करून पुनर्निर्देशित करेल.

आम्हाला माहित आहे की आम्ही शुद्ध PHP (PHP-PM) मध्ये किंवा C विस्तार (Swoole) वापरून वेब सर्व्हर लिहू शकतो. आणि जरी प्रत्येक पद्धतीचे स्वतःचे गुण आहेत, दोन्ही पर्याय आम्हाला अनुकूल नव्हते - आम्हाला आणखी काहीतरी हवे होते. आम्हाला फक्त वेब सर्व्हरपेक्षा जास्त गरज होती - आम्हाला एक उपाय मिळण्याची अपेक्षा होती जी आम्हाला PHP मधील "हार्ड स्टार्ट" शी संबंधित समस्यांपासून वाचवू शकते, जे त्याच वेळी विशिष्ट अनुप्रयोगांसाठी सहजपणे रुपांतरित आणि विस्तारित केले जाऊ शकते. म्हणजेच, आम्हाला अॅप्लिकेशन सर्व्हरची गरज होती.

गो यात मदत करू शकेल का? आम्हाला माहित आहे की हे होऊ शकते कारण भाषा एकल बायनरीमध्ये अनुप्रयोग संकलित करते; ते क्रॉस-प्लॅटफॉर्म आहे; HTTP सह कार्य करण्यासाठी स्वतःचे, अतिशय मोहक, समांतर प्रक्रिया मॉडेल (समांतर) आणि लायब्ररी वापरते; आणि शेवटी, हजारो मुक्त-स्रोत लायब्ररी आणि एकत्रीकरण आमच्यासाठी उपलब्ध असतील.

दोन प्रोग्रामिंग भाषा एकत्र करण्याच्या अडचणी

सर्व प्रथम, दोन किंवा अधिक अनुप्रयोग एकमेकांशी कसे संवाद साधतील हे निर्धारित करणे आवश्यक होते.

उदाहरणार्थ, वापरणे उत्कृष्ट लायब्ररी अॅलेक्स पॅलेस्ट्रास, PHP आणि गो प्रक्रियांमध्ये मेमरी सामायिक करणे शक्य होते (अपाचे मधील mod_php प्रमाणेच). परंतु या लायब्ररीमध्ये अशी वैशिष्ट्ये आहेत जी आमच्या समस्या सोडवण्यासाठी त्याचा वापर मर्यादित करतात.

आम्ही एक भिन्न, अधिक सामान्य दृष्टीकोन वापरण्याचे ठरविले: सॉकेट्स / पाइपलाइनद्वारे प्रक्रियांमध्ये परस्परसंवाद निर्माण करण्यासाठी. हा दृष्टीकोन गेल्या दशकांमध्ये विश्वासार्ह असल्याचे सिद्ध झाले आहे आणि ऑपरेटिंग सिस्टम स्तरावर चांगले ऑप्टिमाइझ केले गेले आहे.

सुरुवातीला, आम्ही प्रक्रिया आणि ट्रान्समिशन त्रुटी हाताळण्यासाठी डेटाची देवाणघेवाण करण्यासाठी एक साधा बायनरी प्रोटोकॉल तयार केला आहे. त्याच्या सर्वात सोप्या स्वरूपात, या प्रकारचे प्रोटोकॉल सारखेच आहे नेटस्ट्रिंग с निश्चित आकाराचे पॅकेट शीर्षलेख (आमच्या बाबतीत 17 बाइट), ज्यामध्ये पॅकेटचा प्रकार, त्याचा आकार आणि डेटाची अखंडता तपासण्यासाठी बायनरी मास्कची माहिती असते.

PHP बाजूला आम्ही वापरले पॅक फंक्शन, आणि गो बाजूला, लायब्ररी एन्कोडिंग/बायनरी.

आम्हाला असे वाटले की एक प्रोटोकॉल पुरेसे नाही - आणि आम्ही कॉल करण्याची क्षमता जोडली थेट PHP वरून नेट/आरपीसी गो सेवा. नंतर, यामुळे आम्हाला विकासात खूप मदत झाली, कारण आम्ही PHP ऍप्लिकेशन्समध्ये गो लायब्ररी सहजपणे समाकलित करू शकतो. या कार्याचा परिणाम, उदाहरणार्थ, आमच्या इतर मुक्त-स्रोत उत्पादनामध्ये दिसू शकतो गोरीज.

एकाधिक PHP कामगारांमध्ये कार्ये वितरित करणे

परस्परसंवाद यंत्रणा कार्यान्वित केल्यानंतर, आम्ही PHP प्रक्रियांमध्ये कार्ये हस्तांतरित करण्याच्या सर्वात कार्यक्षम मार्गाबद्दल विचार करू लागलो. जेव्हा एखादे कार्य येते, तेव्हा ते कार्यान्वित करण्यासाठी अनुप्रयोग सर्व्हरने विनामूल्य कार्यकर्ता निवडणे आवश्यक आहे. एखादे कर्मचारी/प्रक्रिया त्रुटीसह बाहेर पडल्यास किंवा "मृत्यू" झाल्यास, आम्ही त्यातून सुटका करतो आणि ती बदलण्यासाठी नवीन तयार करतो. आणि जर कार्यकर्ता/प्रक्रिया यशस्वीरित्या पूर्ण झाली असेल, तर आम्ही ती कार्ये करण्यासाठी उपलब्ध कामगारांच्या पूलमध्ये परत करतो.

सक्रिय कामगारांचा पूल संचयित करण्यासाठी, आम्ही वापरले बफर केलेले चॅनेल, पूलमधून अनपेक्षितपणे "मृत" कामगारांना काढून टाकण्यासाठी, आम्ही त्रुटी आणि कामगारांच्या स्थितीचा मागोवा घेण्यासाठी एक यंत्रणा जोडली.

परिणामी, आम्हाला बायनरी स्वरूपात सादर केलेल्या कोणत्याही विनंत्यांवर प्रक्रिया करण्यास सक्षम कार्यरत PHP सर्व्हर मिळाला.

आमच्या ऍप्लिकेशनला वेब सर्व्हर म्हणून काम करण्यास सुरुवात करण्यासाठी, आम्हाला येणाऱ्या HTTP विनंत्यांचे प्रतिनिधित्व करण्यासाठी विश्वसनीय PHP मानक निवडावे लागले. आमच्या बाबतीत, आम्ही फक्त रूपांतर फॉरमॅटवर जा वरून net/http विनंती पीएसआर-एक्सNUMएक्सजेणेकरून ते आज उपलब्ध असलेल्या बहुतांश PHP फ्रेमवर्कशी सुसंगत असेल.

कारण PSR-7 अपरिवर्तनीय मानले जाते (काही तांत्रिकदृष्ट्या असे म्हणतील असे नाही), डेव्हलपरना असे ऍप्लिकेशन लिहावे लागतात जे विनंतीला तत्त्वतः जागतिक अस्तित्व मानत नाहीत. दीर्घायुषी PHP प्रक्रियेच्या संकल्पनेशी हे उत्तम प्रकारे बसते. आमचे अंतिम अंमलबजावणी, ज्याचे नाव अद्याप दिले गेले नाही, असे दिसले:

सादर करत आहोत रोडरनर - उच्च कार्यक्षमता PHP अनुप्रयोग सर्व्हर

आमचे पहिले चाचणी कार्य API बॅकएंड होते, जे अधूनमधून अप्रत्याशित विनंत्यांमध्ये (नेहमीपेक्षा बरेचदा) फुटते. जरी बहुतेक प्रकरणांमध्ये nginx पुरेसे होते, तरीही आम्ही नियमितपणे 502 त्रुटींचा सामना केला कारण लोडमध्ये अपेक्षित वाढ होण्यासाठी आम्ही प्रणालीमध्ये त्वरीत संतुलन राखू शकलो नाही.

हे समाधान बदलण्यासाठी, आम्ही आमचा पहिला PHP/Go ऍप्लिकेशन सर्व्हर 2018 च्या सुरुवातीला तैनात केला. आणि लगेचच एक अविश्वसनीय प्रभाव आला! आम्ही केवळ 502 त्रुटीपासून पूर्णपणे मुक्त झालो नाही तर आम्ही सर्व्हरची संख्या दोन-तृतियांश कमी करू शकलो, खूप पैसे वाचवले आणि अभियंते आणि उत्पादन व्यवस्थापकांसाठी डोकेदुखीच्या गोळ्या.

वर्षाच्या मध्यापर्यंत, आम्ही आमचे समाधान सुधारले होते, ते MIT परवान्याअंतर्गत GitHub वर प्रकाशित केले आणि त्याचे नाव दिले रोडरनर, अशा प्रकारे त्याच्या अविश्वसनीय गती आणि कार्यक्षमतेवर जोर देते.

रोडरनर तुमचा विकास स्टॅक कसा सुधारू शकतो

अर्ज रोडरनर विनंती PHP पर्यंत पोहोचण्याआधी JWT पडताळणी करण्यासाठी, तसेच Prometheus मध्ये WebSockets आणि जागतिक स्तरावर एकूण स्थिती हाताळण्यासाठी Go side वर मिडलवेअर नेट/http वापरण्याची परवानगी दिली.

अंगभूत RPC बद्दल धन्यवाद, तुम्ही विस्तार रॅपर न लिहिता PHP साठी कोणत्याही Go लायब्ररीचे API उघडू शकता. अधिक महत्त्वाचे म्हणजे, रोडरनरसह तुम्ही नवीन नॉन-एचटीटीपी सर्व्हर तैनात करू शकता. उदाहरणांमध्ये PHP मध्ये चालणारे हँडलर्स समाविष्ट आहेत एडब्ल्यूएस लंबडा, विश्वासार्ह रांग ब्रेकर तयार करणे, आणि जोडणे देखील gRPC आमच्या अर्जांना.

PHP आणि Go समुदायांच्या मदतीने, आम्ही सोल्यूशनची स्थिरता सुधारली, काही चाचण्यांमध्ये ऍप्लिकेशन कार्यप्रदर्शन 40 पट वाढवले, सुधारित डीबगिंग टूल्स, सिम्फनी फ्रेमवर्कसह एकीकरण लागू केले आणि HTTPS, HTTP/2 साठी समर्थन जोडले, प्लगइन आणि PSR-17.

निष्कर्ष

काही लोक अजूनही PHP च्या कालबाह्य कल्पनेत अडकले आहेत ही एक संथ, अनाठायी भाषा आहे जी केवळ WordPress साठी प्लगइन लिहिण्यासाठी चांगली आहे. हे लोक असेही म्हणू शकतात की PHP ला अशी मर्यादा आहे: जेव्हा अनुप्रयोग पुरेसा मोठा होतो, तेव्हा तुम्हाला अधिक "परिपक्व" भाषा निवडावी लागेल आणि बर्याच वर्षांपासून जमा केलेला कोड बेस पुन्हा लिहावा लागेल.

या सर्वांसाठी मला उत्तर द्यायचे आहे: पुन्हा विचार करा. आमचा विश्वास आहे की फक्त तुम्ही PHP साठी कोणतेही निर्बंध सेट करता. तुम्ही तुमचे संपूर्ण आयुष्य एका भाषेतून दुसर्‍या भाषेत बदलण्यात घालवू शकता, तुमच्या गरजांसाठी योग्य जुळणी शोधण्याचा प्रयत्न करू शकता किंवा तुम्ही भाषांना साधने म्हणून विचार करायला सुरुवात करू शकता. PHP सारख्या भाषेतील कथित दोष हे त्याच्या यशाचे खरे कारण असू शकतात. आणि जर तुम्ही ते Go सारख्या दुसर्‍या भाषेसह एकत्र केले तर तुम्ही कोणतीही एक भाषा वापरण्यापुरते मर्यादित असल्‍यापेक्षा कितीतरी अधिक शक्तिशाली उत्‍पादने तयार कराल.

Go आणि PHP च्या समूहासह काम केल्यावर, आम्ही असे म्हणू शकतो की आम्हाला ते आवडतात. आम्ही दुसऱ्यासाठी एकाचा त्याग करण्याची योजना करत नाही - उलट, आम्ही या दुहेरी स्टॅकमधून आणखी मूल्य मिळविण्याचे मार्ग शोधू.

UPD: आम्ही RoadRunner च्या निर्मात्याचे आणि मूळ लेखाच्या सह-लेखकाचे स्वागत करतो - लॅचेसिस

स्त्रोत: www.habr.com