RoadRunner: PHP मर्नको लागि बनाइएको छैन, वा उद्धारको लागि Golang

हे हाबर! हामी Badoo मा सक्रिय छौं PHP performance मा काम गर्नुहुन्छ, किनकि हामीसँग यस भाषामा एकदम ठूलो प्रणाली छ र प्रदर्शन मुद्दा पैसा बचत मुद्दा हो। दस वर्ष भन्दा पहिले, हामीले यसको लागि PHP-FPM सिर्जना गर्यौं, जुन सुरुमा PHP को लागि प्याचहरूको सेट थियो, र पछि आधिकारिक वितरणमा प्रवेश गर्‍यौं।

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

लेखको दृष्टिकोण हाम्रो नजिक छ: हाम्रा समस्याहरू समाधान गर्दा, हामी प्रायः PHP र Go को गुच्छा प्रयोग गर्छौं, दुबै भाषाहरूको फाइदाहरू पाउँदै र अर्कोको पक्षमा एकलाई त्याग्दैनौं।

आनन्द लिनुहोस्!

पछिल्लो दस वर्षमा, हामीले सूचीबाट कम्पनीहरूको लागि आवेदनहरू सिर्जना गरेका छौं भाग्य 500, र 500 भन्दा बढी प्रयोगकर्ताहरू नभएका दर्शकहरू भएका व्यवसायहरूका लागि। यो सबै समय, हाम्रा ईन्जिनियरहरूले मुख्य रूपमा PHP मा ब्याकएन्ड विकास गर्दै आएका छन्। तर दुई वर्ष पहिले, कुनै कुराले हाम्रा उत्पादनहरूको कार्यसम्पादनमा मात्र नभई तिनीहरूको स्केलेबिलिटीमा पनि ठूलो प्रभाव पारेको थियो - हामीले Golang (Go) लाई हाम्रो टेक्नोलोजी स्ट्याकमा प्रस्तुत गर्‍यौं।

लगभग तुरुन्तै, हामीले पत्ता लगायौं कि 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 विकासकर्ता हुनुहुन्छ भने, तपाइँलाई थाहा छ नयाँ परियोजना कहाँ सुरु गर्ने - फ्रेमवर्कको छनोटको साथ। यसले निर्भरता इंजेक्शन पुस्तकालयहरू, ORMs, अनुवादहरू र टेम्प्लेटहरू समावेश गर्दछ। र, निस्सन्देह, सबै प्रयोगकर्ता इनपुट सजिलै एक वस्तु (Symfony/HttpFoundation वा PSR-7) मा राख्न सकिन्छ। फ्रेमवर्कहरू सुन्दर छन्!

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

PHP इन्जिनियरहरूले यो समस्या समाधान गर्ने तरिकाहरू वर्षौंदेखि खोजिरहेका छन्, चतुर अल्छी-लोडिङ प्रविधिहरू, माइक्रोफ्रेमवर्कहरू, अनुकूलित पुस्तकालयहरू, क्यास, इत्यादि प्रयोग गरेर। तर अन्तमा, तपाईंले अझै पनि सम्पूर्ण अनुप्रयोग रिसेट गर्नुपर्छ र फेरि सुरु गर्नुपर्छ। । (अनुवादकको नोट: यो समस्या को आगमन संग आंशिक रूपमा हल हुनेछ पूर्व-लोड PHP 7.4 मा)

के गो सँग PHP एक भन्दा बढी अनुरोधहरू बाँच्न सक्छ?

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

तर दीर्घकालीन लिपिहरू विकास गर्न सजिलो छैन। कुनै पनि त्रुटिले पूर्णतया प्रक्रियालाई नष्ट गर्छ, मेमोरी लीकको निदान गर्न उत्तेजित हुन्छ, र F5 डिबगिङ अब सम्भव छैन।

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

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

यो समस्या समाधान गर्नको लागि, हामीले पहिले HTTP अनुरोधहरू स्वीकार गर्न सक्ने सर्भर अनुप्रयोग लागू गर्न आवश्यक छ र तिनीहरूलाई प्रत्येक पटक नमारिकन PHP कार्यकर्तालाई एक-एक गरेर रिडिरेक्ट गर्न सक्छ।

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

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

दुई प्रोग्रामिङ भाषाहरू संयोजन गर्ने कठिनाइहरू

सबै भन्दा पहिले, यो निर्धारण गर्न आवश्यक थियो कि कसरी दुई वा बढी अनुप्रयोगहरू एकअर्कासँग कुराकानी गर्नेछन्।

उदाहरणका लागि, प्रयोग गर्दै उत्कृष्ट पुस्तकालय एलेक्स Palaestras, यो PHP र गो प्रक्रियाहरू (Apache मा mod_php जस्तै) बीच मेमोरी साझा गर्न सम्भव थियो। तर यस पुस्तकालयमा सुविधाहरू छन् जसले हाम्रो समस्या समाधान गर्न यसको प्रयोगलाई सीमित गर्दछ।

हामीले एक फरक, अधिक सामान्य दृष्टिकोण प्रयोग गर्ने निर्णय गर्यौं: सकेट / पाइपलाइनहरू मार्फत प्रक्रियाहरू बीच अन्तरक्रिया निर्माण गर्न। यो दृष्टिकोण विगत दशकहरूमा भरपर्दो साबित भएको छ र अपरेटिङ सिस्टम स्तरमा राम्रोसँग अनुकूलित गरिएको छ।

सुरुमा, हामीले प्रक्रियाहरू र प्रसारण त्रुटिहरू ह्यान्डलिङ बीच डाटा आदानप्रदान गर्नको लागि एक साधारण बाइनरी प्रोटोकल सिर्जना गर्यौं। यसको सरल रूप मा, प्रोटोकल को यो प्रकार को समान छ netstring с निश्चित आकार प्याकेट हेडर (हाम्रो मामलामा 17 बाइट्स), जसमा प्याकेटको प्रकार, यसको साइज र डाटाको अखण्डता जाँच गर्न बाइनरी मास्कको बारेमा जानकारी समावेश छ।

PHP पक्षमा हामीले प्रयोग गर्यौं प्याक प्रकार्य, र गो साइडमा, पुस्तकालय एन्कोडिङ/बाइनरी.

यो हामीलाई लाग्थ्यो कि एउटा प्रोटोकल पर्याप्त थिएन - र हामीले कल गर्ने क्षमता थप्यौं नेट/आरपीसी गो सेवाहरू सीधा PHP बाट। पछि, यसले हामीलाई विकासमा धेरै मद्दत गर्‍यो, किनकि हामीले गो लाइब्रेरीहरूलाई PHP अनुप्रयोगहरूमा सजिलैसँग एकीकृत गर्न सक्छौं। यस कामको नतिजा देख्न सकिन्छ, उदाहरणका लागि, हाम्रो अन्य खुला स्रोत उत्पादनमा गोरिज.

धेरै PHP कार्यकर्ताहरूमा कार्यहरू वितरण गर्दै

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

सक्रिय कार्यकर्ताहरूको पोखरी भण्डारण गर्न, हामीले प्रयोग गर्यौं बफर गरिएको च्यानल, पूलबाट अप्रत्याशित रूपमा "मृत" कामदारहरूलाई हटाउन, हामीले त्रुटिहरू र कामदारहरूको अवस्था ट्र्याक गर्ने संयन्त्र थप्यौं।

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

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

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

रोडरनर प्रस्तुत गर्दै - उच्च प्रदर्शन PHP अनुप्रयोग सर्भर

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

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

वर्षको मध्यमा, हामीले हाम्रो समाधान सुधार गरेका थियौं, यसलाई MIT लाइसेन्स अन्तर्गत GitHub मा प्रकाशित गर्‍यौं र यसको नाम राख्यौं। Roadrunner, यसरी यसको अविश्वसनीय गति र दक्षतालाई जोड दिँदै।

कसरी RoadRunner तपाईंको विकास स्ट्याक सुधार गर्न सक्छ

आवेदन Roadrunner हामीलाई अनुरोध PHP मा पुग्नु अघि JWT प्रमाणीकरण गर्न गो साइडमा मिडलवेयर नेट/http प्रयोग गर्न अनुमति दियो, साथै Prometheus मा WebSockets र विश्वव्यापी रूपमा समग्र स्थिति ह्यान्डल गर्न।

बिल्ट-इन RPC को लागी धन्यवाद, तपाइँ PHP को लागी कुनै पनि गो लाइब्रेरी को एपीआई खोल्न सक्नुहुन्छ एक्स्टेन्सन र्यापरहरू नलिई। अझ महत्त्वपूर्ण कुरा, RoadRunner को साथ तपाईले नयाँ गैर-HTTP सर्भरहरू प्रयोग गर्न सक्नुहुन्छ। उदाहरणहरूमा PHP मा चलिरहेको ह्यान्डलरहरू समावेश छन् AWS Lambda, भरपर्दो लाम ब्रेकरहरू सिर्जना गर्दै, र थप्दै पनि gRPC हाम्रो अनुप्रयोगहरूमा।

PHP र Go समुदायहरूको सहयोगमा, हामीले समाधानको स्थिरता सुधार गर्‍यौं, केही परीक्षणहरूमा 40 गुणासम्म अनुप्रयोगको कार्यसम्पादन बढायो, सुधारिएको डिबगिङ उपकरणहरू, Symfony फ्रेमवर्कसँग लागू गरिएको एकीकरण, र HTTPS, HTTP/2 को लागि समर्थन थपियो। प्लगइनहरू, र PSR-17।

निष्कर्षमा

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

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

Go र PHP को एक समूहसँग काम गरिसकेपछि, हामी भन्न सक्छौं कि हामी तिनीहरूलाई माया गर्छौं। हामी एक अर्काको लागि बलिदान गर्ने योजना गर्दैनौं - यसको विपरित, हामी यस दोहोरो स्ट्याकबाट अझ बढी मूल्य प्राप्त गर्ने तरिकाहरू खोज्नेछौं।

UPD: हामी RoadRunner को सिर्जनाकर्ता र मूल लेखको सह-लेखकलाई स्वागत गर्दछौं - Lachesis

स्रोत: www.habr.com