रोडरनर: PHP को मरने के लिए नहीं बनाया गया है, या गोलांग को बचाव के लिए नहीं बनाया गया है

हे हबर! हम Badoo पर सक्रिय हैं PHP प्रदर्शन पर काम कर रहा हूँचूँकि हमारे पास इस भाषा में काफी बड़ी प्रणाली है और प्रदर्शन का मुद्दा पैसे बचाने का मुद्दा है। दस साल से भी पहले, हमने इसके लिए PHP-FPM बनाया, जो पहले PHP के लिए पैच का एक सेट था, और बाद में आधिकारिक वितरण में प्रवेश किया।

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

लेख का दृष्टिकोण हमारे करीब है: अपनी समस्याओं को हल करते समय, हम अक्सर PHP और Go का एक समूह का उपयोग करते हैं, दोनों भाषाओं का लाभ प्राप्त करते हैं और एक को दूसरे के पक्ष में नहीं छोड़ते हैं।

का आनंद लें!

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

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

हम आपको बताएंगे कि कैसे Go और PHP का संयोजन वास्तविक विकास समस्याओं को हल करने में मदद करता है और यह हमारे लिए एक उपकरण में कैसे बदल गया है जो इससे जुड़ी कुछ समस्याओं से छुटकारा दिला सकता है PHP डाइंग मॉडल.

आपका दैनिक PHP विकास वातावरण

इससे पहले कि हम इस बारे में बात करें कि आप PHP के लुप्त हो रहे मॉडल को पुनर्जीवित करने के लिए गो का उपयोग कैसे कर सकते हैं, आइए आपके डिफ़ॉल्ट PHP विकास वातावरण पर एक नज़र डालें।

ज्यादातर मामलों में, आप अपना एप्लिकेशन nginx वेब सर्वर और PHP-FPM सर्वर के संयोजन का उपयोग करके चलाते हैं। पहला स्थिर फ़ाइलें परोसता है और विशिष्ट अनुरोधों को PHP-FPM पर पुनर्निर्देशित करता है, जबकि PHP-FPM स्वयं PHP कोड निष्पादित करता है। आप अपाचे और mod_php के कम लोकप्रिय संयोजन का उपयोग कर रहे होंगे। हालाँकि यह थोड़ा अलग तरीके से काम करता है, सिद्धांत समान हैं।

आइए देखें कि PHP-FPM एप्लिकेशन कोड को कैसे निष्पादित करता है। जब कोई अनुरोध आता है, तो PHP-FPM एक PHP चाइल्ड प्रक्रिया प्रारंभ करता है और अनुरोध के विवरण को उसके राज्य (_GET, _POST, _SERVER, आदि) के हिस्से के रूप में पास करता है।

PHP स्क्रिप्ट निष्पादन के दौरान स्थिति नहीं बदल सकती है, इसलिए इनपुट डेटा का एक नया सेट प्राप्त करने का केवल एक ही तरीका है: प्रक्रिया मेमोरी को साफ़ करके और इसे फिर से प्रारंभ करके।

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

नियमित PHP वातावरण के नुकसान और अक्षमताएँ

यदि आप एक पेशेवर PHP डेवलपर हैं, तो आप जानते हैं कि एक नया प्रोजेक्ट कहां से शुरू करना है - एक फ्रेमवर्क के चयन के साथ। इसमें निर्भरता इंजेक्शन लाइब्रेरी, ओआरएम, अनुवाद और टेम्पलेट शामिल हैं। और, निःसंदेह, सभी उपयोगकर्ता इनपुट को आसानी से एक ऑब्जेक्ट (सिम्फनी/HttpFoundation या PSR-7) में डाला जा सकता है। फ्रेमवर्क अच्छे हैं!

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

PHP इंजीनियर चतुर आलसी-लोडिंग तकनीकों, माइक्रोफ़्रेमवर्क, अनुकूलित लाइब्रेरी, कैश इत्यादि का उपयोग करके वर्षों से इस समस्या को हल करने के तरीकों की तलाश कर रहे हैं, लेकिन अंत में, आपको अभी भी पूरे एप्लिकेशन को रीसेट करना होगा और बार-बार शुरू करना होगा . (अनुवादक का नोट: के आगमन से यह समस्या आंशिक रूप से हल हो जाएगी प्रीलोड PHP 7.4 में)

क्या गो के साथ PHP एक से अधिक अनुरोधों को झेल सकता है?

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

लेकिन लंबे समय तक चलने वाली स्क्रिप्ट विकसित करना आसान नहीं है। कोई भी त्रुटि प्रक्रिया को पूरी तरह से समाप्त कर देती है, मेमोरी लीक का निदान करना कष्टप्रद होता है, और F5 डिबगिंग अब संभव नहीं है।

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

क्या लंबे समय तक चलने वाली PHP स्क्रिप्ट के साथ काम करने का मॉडल लेना, HTTP अनुरोधों को संसाधित करने जैसे अधिक तुच्छ कार्यों के लिए इसे अनुकूलित करना संभव है, और इस तरह प्रत्येक अनुरोध के साथ सब कुछ लोड करने की आवश्यकता से छुटकारा मिल सकता है?

इस समस्या को हल करने के लिए, हमें सबसे पहले एक सर्वर एप्लिकेशन को लागू करने की आवश्यकता थी जो HTTP अनुरोधों को स्वीकार कर सके और उन्हें हर बार बंद किए बिना PHP कार्यकर्ता पर एक-एक करके रीडायरेक्ट कर सके।

हम जानते थे कि हम एक वेब सर्वर को शुद्ध PHP (PHP-PM) में या C एक्सटेंशन (Swoole) का उपयोग करके लिख सकते हैं। और यद्यपि प्रत्येक विधि की अपनी खूबियाँ हैं, दोनों विकल्प हमारे अनुकूल नहीं थे - हम कुछ और चाहते थे। हमें सिर्फ एक वेब सर्वर से अधिक की आवश्यकता थी - हमें एक ऐसा समाधान मिलने की उम्मीद थी जो हमें PHP में "हार्ड स्टार्ट" से जुड़ी समस्याओं से बचा सके, जिसे एक ही समय में विशिष्ट अनुप्रयोगों के लिए आसानी से अनुकूलित और विस्तारित किया जा सके। यानी हमें एक एप्लिकेशन सर्वर की जरूरत थी।

क्या गो इसमें मदद कर सकता है? हम जानते थे कि ऐसा हो सकता है क्योंकि भाषा अनुप्रयोगों को एकल बायनेरिज़ में संकलित करती है; यह क्रॉस-प्लेटफ़ॉर्म है; HTTP के साथ काम करने के लिए अपने स्वयं के, बहुत ही सुंदर, समानांतर प्रसंस्करण मॉडल (संगामिति) और एक पुस्तकालय का उपयोग करता है; और अंततः, हजारों ओपन-सोर्स लाइब्रेरी और एकीकरण हमारे लिए उपलब्ध होंगे।

दो प्रोग्रामिंग भाषाओं के संयोजन की कठिनाइयाँ

सबसे पहले, यह निर्धारित करना आवश्यक था कि दो या दो से अधिक एप्लिकेशन एक दूसरे के साथ कैसे संचार करेंगे।

उदाहरण के लिए, का उपयोग करना उत्कृष्ट पुस्तकालय एलेक्स पैलेस्ट्रास, PHP और Go प्रक्रियाओं के बीच मेमोरी साझा करना संभव था (Apache में mod_php के समान)। लेकिन इस लाइब्रेरी में ऐसी विशेषताएं हैं जो हमारी समस्या को हल करने के लिए इसके उपयोग को सीमित करती हैं।

हमने एक अलग, अधिक सामान्य दृष्टिकोण का उपयोग करने का निर्णय लिया: सॉकेट/पाइपलाइन के माध्यम से प्रक्रियाओं के बीच बातचीत का निर्माण करना। यह दृष्टिकोण पिछले दशकों में विश्वसनीय साबित हुआ है और ऑपरेटिंग सिस्टम स्तर पर इसे अच्छी तरह से अनुकूलित किया गया है।

शुरुआत करने के लिए, हमने प्रक्रियाओं के बीच डेटा के आदान-प्रदान और ट्रांसमिशन त्रुटियों से निपटने के लिए एक सरल बाइनरी प्रोटोकॉल बनाया। अपने सरलतम रूप में, इस प्रकार का प्रोटोकॉल समान है नेटस्ट्रिंग с निश्चित आकार पैकेट हेडर (हमारे मामले में 17 बाइट्स), जिसमें पैकेट के प्रकार, उसके आकार और डेटा की अखंडता की जांच करने के लिए एक बाइनरी मास्क के बारे में जानकारी होती है।

PHP पक्ष पर हमने उपयोग किया पैक फ़ंक्शन, और गो साइड पर, लाइब्रेरी एन्कोडिंग/बाइनरी.

हमें ऐसा लगा कि एक प्रोटोकॉल पर्याप्त नहीं था - और हमने कॉल करने की क्षमता जोड़ दी PHP से सीधे नेट/आरपीसी गो सेवाएँ. बाद में, इससे हमें विकास में बहुत मदद मिली, क्योंकि हम आसानी से गो लाइब्रेरीज़ को PHP अनुप्रयोगों में एकीकृत कर सकते थे। इस कार्य का परिणाम, उदाहरण के लिए, हमारे अन्य ओपन-सोर्स उत्पाद में देखा जा सकता है गोरिज.

एकाधिक PHP कार्यकर्ताओं में कार्य वितरित करना

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

सक्रिय कार्यकर्ताओं के पूल को संग्रहीत करने के लिए, हमने उपयोग किया बफ़र्ड चैनलपूल से अप्रत्याशित रूप से "मृत" श्रमिकों को हटाने के लिए, हमने त्रुटियों और श्रमिकों की स्थिति पर नज़र रखने के लिए एक तंत्र जोड़ा।

परिणामस्वरूप, हमें एक कार्यशील PHP सर्वर मिला जो बाइनरी रूप में प्रस्तुत किसी भी अनुरोध को संसाधित करने में सक्षम है।

हमारे एप्लिकेशन को वेब सर्वर के रूप में काम करना शुरू करने के लिए, हमें किसी भी आने वाले HTTP अनुरोध का प्रतिनिधित्व करने के लिए एक विश्वसनीय PHP मानक चुनना होगा। हमारे मामले में, हम बस परिवर्तन नेट/http अनुरोध से प्रारूप पर जाएं PSR-7ताकि यह आज उपलब्ध अधिकांश PHP फ्रेमवर्क के साथ संगत हो।

चूँकि PSR-7 को अपरिवर्तनीय माना जाता है (कुछ लोग कहेंगे कि तकनीकी रूप से यह नहीं है), डेवलपर्स को ऐसे एप्लिकेशन लिखने पड़ते हैं जो सिद्धांत रूप में अनुरोध को वैश्विक इकाई के रूप में नहीं मानते हैं। यह दीर्घकालिक PHP प्रक्रियाओं की अवधारणा के साथ अच्छी तरह से फिट बैठता है। हमारा अंतिम कार्यान्वयन, जिसे अभी तक नाम नहीं दिया गया है, इस तरह दिखता है:

रोडरनर का परिचय - उच्च प्रदर्शन PHP एप्लिकेशन सर्वर

हमारा पहला परीक्षण कार्य एक एपीआई बैकएंड था, जो समय-समय पर अप्रत्याशित अनुरोधों (सामान्य से बहुत अधिक बार) में फूटता है। हालाँकि ज्यादातर मामलों में nginx पर्याप्त था, हमें नियमित रूप से 502 त्रुटियों का सामना करना पड़ा क्योंकि हम लोड में अपेक्षित वृद्धि के लिए सिस्टम को जल्दी से संतुलित नहीं कर सके।

इस समाधान को बदलने के लिए, हमने 2018 की शुरुआत में अपना पहला PHP/Go एप्लिकेशन सर्वर तैनात किया। और तुरंत एक अविश्वसनीय प्रभाव मिला! हमने न केवल 502 त्रुटि से पूरी तरह छुटकारा पा लिया, बल्कि हम सर्वरों की संख्या को दो-तिहाई तक कम करने में सक्षम हुए, जिससे इंजीनियरों और उत्पाद प्रबंधकों के लिए बहुत सारा पैसा और सिरदर्द की गोलियाँ बच गईं।

वर्ष के मध्य तक, हमने अपने समाधान में सुधार किया, इसे MIT लाइसेंस के तहत GitHub पर प्रकाशित किया और इसे नाम दिया RoadRunner, इस प्रकार इसकी अविश्वसनीय गति और दक्षता पर जोर दिया गया।

रोडरनर आपके विकास स्टैक को कैसे बेहतर बना सकता है

आवेदन RoadRunner हमें अनुरोध के PHP तक पहुंचने से पहले JWT सत्यापन करने के लिए गो साइड पर मिडलवेयर नेट/http का उपयोग करने की अनुमति दी गई, साथ ही प्रोमेथियस में वैश्विक स्तर पर वेबसॉकेट और समग्र स्थिति को संभालने की अनुमति दी गई।

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

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

निष्कर्ष

कुछ लोग अभी भी PHP की पुरानी धारणा में फंसे हुए हैं कि PHP एक धीमी, बोझिल भाषा है जो केवल वर्डप्रेस के लिए प्लगइन्स लिखने के लिए अच्छी है। ये लोग यह भी कह सकते हैं कि PHP की एक सीमा है: जब एप्लिकेशन काफी बड़ा हो जाता है, तो आपको अधिक "परिपक्व" भाषा चुननी होगी और कई वर्षों से संचित कोड बेस को फिर से लिखना होगा।

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

Go और PHP के समूह के साथ काम करने के बाद, हम कह सकते हैं कि हम उन्हें पसंद करते हैं। हम एक को दूसरे के लिए बलिदान करने की योजना नहीं बनाते हैं - इसके विपरीत, हम इस दोहरे ढेर से और भी अधिक मूल्य प्राप्त करने के तरीकों की तलाश करेंगे।

यूपीडी: हम रोडरनर के निर्माता और मूल लेख के सह-लेखक का स्वागत करते हैं - लैकेसिस

स्रोत: www.habr.com