ரோட் ரன்னர்: PHP இறப்பதற்காகவோ அல்லது கோலாங் மீட்புக்காகவோ உருவாக்கப்படவில்லை

ஹே ஹப்ர்! நாங்கள் படூவில் செயலில் உள்ளோம் PHP செயல்திறன் வேலை, இந்த மொழியில் எங்களிடம் மிகப் பெரிய அமைப்பு இருப்பதால், செயல்திறன் சிக்கல் பணத்தைச் சேமிக்கும் சிக்கலாகும். பத்து ஆண்டுகளுக்கு முன்பு, நாங்கள் இதற்காக PHP-FPM ஐ உருவாக்கினோம், இது முதலில் PHP க்கான இணைப்புகளின் தொகுப்பாக இருந்தது, பின்னர் அதிகாரப்பூர்வ விநியோகத்தில் நுழைந்தது.

சமீபத்திய ஆண்டுகளில், PHP பெரும் முன்னேற்றம் அடைந்துள்ளது: குப்பை சேகரிப்பான் மேம்பட்டுள்ளது, நிலைத்தன்மையின் நிலை அதிகரித்துள்ளது - இன்று நீங்கள் PHP இல் எந்த பிரச்சனையும் இல்லாமல் டெமான்கள் மற்றும் நீண்ட கால ஸ்கிரிப்ட்களை எழுதலாம். இது ஸ்பைரல் ஸ்கவுட்டை மேலும் செல்ல அனுமதித்தது: ரோட் ரன்னர், PHP-FPM போலல்லாமல், கோரிக்கைகளுக்கு இடையே நினைவகத்தை சுத்தம் செய்யாது, இது கூடுதல் செயல்திறன் ஆதாயத்தை அளிக்கிறது (இந்த அணுகுமுறை வளர்ச்சி செயல்முறையை சிக்கலாக்கும் என்றாலும்). நாங்கள் தற்போது இந்த கருவியை பரிசோதித்து வருகிறோம், ஆனால் பகிர்வதற்கு எங்களிடம் எந்த முடிவும் இல்லை. அவர்களுக்காகக் காத்திருப்பதை மேலும் வேடிக்கையாக மாற்ற, ரோட் ரன்னர் அறிவிப்பின் மொழிபெயர்ப்பை ஸ்பைரல் ஸ்கவுட்டிலிருந்து வெளியிடுகிறோம்.

கட்டுரையின் அணுகுமுறை எங்களுக்கு நெருக்கமானது: எங்கள் சிக்கல்களைத் தீர்க்கும்போது, ​​​​நாங்கள் பெரும்பாலும் PHP மற்றும் Go ஐப் பயன்படுத்துகிறோம், இரு மொழிகளின் நன்மைகளைப் பெறுகிறோம் மற்றும் ஒன்றை மற்றொன்றுக்கு ஆதரவாக கைவிடவில்லை.

மகிழுங்கள்!

கடந்த பத்து ஆண்டுகளில், பட்டியலில் இருந்து நிறுவனங்களுக்கான விண்ணப்பங்களை உருவாக்கியுள்ளோம் பார்ச்சூன் XX, மற்றும் 500 பயனர்களுக்கு மேல் இல்லாத பார்வையாளர்களைக் கொண்ட வணிகங்களுக்கு. இந்த நேரத்தில், எங்கள் பொறியாளர்கள் முக்கியமாக PHP இல் பின்தளத்தை உருவாக்கி வருகின்றனர். ஆனால் இரண்டு ஆண்டுகளுக்கு முன்பு, எங்கள் தயாரிப்புகளின் செயல்திறனில் மட்டும் பெரிய தாக்கத்தை ஏற்படுத்தியது, ஆனால் அவற்றின் அளவிடுதல் - எங்கள் தொழில்நுட்ப அடுக்கில் கோலாங்கை (கோ) அறிமுகப்படுத்தினோம்.

ஏறக்குறைய உடனடியாக, 40x செயல்திறன் மேம்பாடுகளுடன் பெரிய பயன்பாடுகளை உருவாக்க Go எங்களை அனுமதித்ததைக் கண்டுபிடித்தோம். அதன் மூலம், PHP இல் எழுதப்பட்ட ஏற்கனவே உள்ள தயாரிப்புகளை நீட்டிக்க முடிந்தது, இரு மொழிகளின் நன்மைகளையும் இணைப்பதன் மூலம் அவற்றை மேம்படுத்த முடிந்தது.

Go மற்றும் PHP ஆகியவற்றின் கலவையானது உண்மையான வளர்ச்சிச் சிக்கல்களைத் தீர்ப்பதற்கு எவ்வாறு உதவுகிறது மற்றும் அது தொடர்பான சில சிக்கல்களில் இருந்து விடுபடக்கூடிய ஒரு கருவியாக அது எவ்வாறு மாறியுள்ளது என்பதை நாங்கள் உங்களுக்குச் சொல்வோம். PHP இறக்கும் மாதிரி.

உங்கள் தினசரி PHP மேம்பாட்டு சூழல்

PHP இறக்கும் மாதிரியை புதுப்பிக்க Go ஐ எவ்வாறு பயன்படுத்தலாம் என்பதைப் பற்றி பேசுவதற்கு முன், உங்கள் இயல்புநிலை PHP மேம்பாட்டு சூழலைப் பார்ப்போம்.

பெரும்பாலான சந்தர்ப்பங்களில், nginx இணைய சேவையகம் மற்றும் PHP-FPM சேவையகத்தின் கலவையைப் பயன்படுத்தி உங்கள் பயன்பாட்டை இயக்குகிறீர்கள். முந்தையது நிலையான கோப்புகளை வழங்குகிறது மற்றும் குறிப்பிட்ட கோரிக்கைகளை PHP-FPM க்கு திருப்பி விடுகிறது, அதே நேரத்தில் PHP-FPM PHP குறியீட்டை இயக்குகிறது. நீங்கள் Apache மற்றும் mod_php ஆகியவற்றின் குறைவான பிரபலமான கலவையைப் பயன்படுத்துகிறீர்கள். ஆனால் இது சற்று வித்தியாசமாக வேலை செய்தாலும், கொள்கைகள் ஒன்றே.

PHP-FPM பயன்பாட்டுக் குறியீட்டை எவ்வாறு செயல்படுத்துகிறது என்பதைப் பார்ப்போம். ஒரு கோரிக்கை வரும்போது, ​​PHP-FPM ஆனது PHP சைல்டு செயல்முறையைத் தொடங்கி, கோரிக்கையின் விவரங்களை அதன் மாநிலத்தின் ஒரு பகுதியாக அனுப்புகிறது (_GET, _POST, _SERVER, முதலியன).

PHP ஸ்கிரிப்ட் செயல்பாட்டின் போது மாநிலத்தை மாற்ற முடியாது, எனவே ஒரு புதிய உள்ளீட்டு தரவைப் பெற ஒரே ஒரு வழி உள்ளது: செயல்முறை நினைவகத்தை அழித்து அதை மீண்டும் தொடங்குவதன் மூலம்.

இந்த செயல்படுத்தல் மாதிரி பல நன்மைகளைக் கொண்டுள்ளது. நினைவக நுகர்வு பற்றி நீங்கள் அதிகம் கவலைப்பட வேண்டியதில்லை, அனைத்து செயல்முறைகளும் முற்றிலும் தனிமைப்படுத்தப்படுகின்றன, மேலும் அவற்றில் ஒன்று "இறந்துவிட்டால்", அது தானாகவே மீண்டும் உருவாக்கப்படும் மற்றும் மீதமுள்ள செயல்முறைகளை பாதிக்காது. ஆனால் இந்த அணுகுமுறை பயன்பாட்டை அளவிட முயற்சிக்கும்போது தோன்றும் தீமைகளையும் கொண்டுள்ளது.

ஒரு வழக்கமான PHP சூழலின் தீமைகள் மற்றும் திறமையின்மை

நீங்கள் ஒரு தொழில்முறை PHP டெவலப்பராக இருந்தால், ஒரு புதிய திட்டத்தை எங்கு தொடங்குவது என்பது உங்களுக்குத் தெரியும் - ஒரு கட்டமைப்பைத் தேர்ந்தெடுப்பதன் மூலம். இது சார்பு ஊசி நூலகங்கள், ORMகள், மொழிபெயர்ப்புகள் மற்றும் வார்ப்புருக்கள் ஆகியவற்றைக் கொண்டுள்ளது. மேலும், நிச்சயமாக, அனைத்து பயனர் உள்ளீடுகளையும் வசதியாக ஒரு பொருளில் (Symfony/HttpFoundation அல்லது PSR-7) வைக்கலாம். கட்டமைப்புகள் அருமை!

ஆனால் எல்லாவற்றிற்கும் அதன் விலை உள்ளது. எந்தவொரு நிறுவன-நிலை கட்டமைப்பிலும், ஒரு எளிய பயனர் கோரிக்கையை அல்லது தரவுத்தளத்திற்கான அணுகலைச் செயல்படுத்த, நீங்கள் குறைந்தது டஜன் கணக்கான கோப்புகளை ஏற்ற வேண்டும், பல வகுப்புகளை உருவாக்க வேண்டும் மற்றும் பல உள்ளமைவுகளை அலச வேண்டும். ஆனால் மோசமான விஷயம் என்னவென்றால், ஒவ்வொரு பணியையும் முடித்த பிறகு, நீங்கள் எல்லாவற்றையும் மீட்டமைத்து மீண்டும் தொடங்க வேண்டும்: நீங்கள் இப்போது தொடங்கிய அனைத்து குறியீடுகளும் பயனற்றதாகிவிடும், அதன் உதவியுடன் நீங்கள் இனி மற்றொரு கோரிக்கையைச் செயல்படுத்த மாட்டீர்கள். வேறு மொழியில் எழுதும் எந்த புரோகிராமரிடம் இதைச் சொல்லுங்கள், அவருடைய முகத்தில் நீங்கள் திகைப்பைக் காண்பீர்கள்.

PHP பொறியாளர்கள் பல ஆண்டுகளாக இந்தச் சிக்கலைத் தீர்ப்பதற்கான வழிகளைத் தேடி வருகின்றனர், புத்திசாலித்தனமான சோம்பேறி ஏற்றுதல் நுட்பங்கள், மைக்ரோஃப்ரேம்வொர்க்குகள், உகந்த நூலகங்கள், தற்காலிக சேமிப்பு போன்றவற்றைப் பயன்படுத்தி. ஆனால் இறுதியில், நீங்கள் முழு பயன்பாட்டையும் மீட்டமைத்து மீண்டும் மீண்டும் தொடங்க வேண்டும். (மொழிபெயர்ப்பாளரின் குறிப்பு: இந்த பிரச்சனையின் வருகையுடன் ஓரளவு தீர்க்கப்படும் முன்னதாகவே ஏற்று PHP 7.4 இல்)

Go உடன் PHP ஒன்றுக்கு மேற்பட்ட கோரிக்கைகளைத் தக்கவைக்க முடியுமா?

PHP ஸ்கிரிப்ட்களை சில நிமிடங்களுக்கு மேல் (மணிநேரம் அல்லது நாட்கள் வரை) எழுத முடியும்: எடுத்துக்காட்டாக, கிரான் பணிகள், CSV பாகுபடுத்திகள், வரிசை பிரேக்கர்கள். அவை அனைத்தும் ஒரே காட்சியின்படி செயல்படுகின்றன: அவை ஒரு பணியை மீட்டெடுக்கின்றன, அதைச் செயல்படுத்துகின்றன, மேலும் அடுத்த பணிக்காக காத்திருக்கின்றன. குறியீடு எல்லா நேரத்திலும் நினைவகத்தில் இருக்கும், கட்டமைப்பையும் பயன்பாட்டையும் ஏற்றுவதற்கு பல கூடுதல் படிகள் தேவைப்படுவதால் விலைமதிப்பற்ற மில்லி விநாடிகளைச் சேமிக்கிறது.

ஆனால் நீண்ட கால ஸ்கிரிப்ட்களை உருவாக்குவது எளிதல்ல. எந்தவொரு பிழையும் செயல்முறையை முற்றிலுமாக அழித்துவிடும், நினைவக கசிவுகளைக் கண்டறிவது எரிச்சலூட்டும், மேலும் F5 பிழைத்திருத்தம் இனி சாத்தியமில்லை.

PHP 7 இன் வெளியீட்டில் நிலைமை மேம்பட்டுள்ளது: நம்பகமான குப்பை சேகரிப்பான் தோன்றியது, பிழைகளைக் கையாள்வது எளிதாகிவிட்டது, மேலும் கர்னல் நீட்டிப்புகள் இப்போது கசிவு-ஆதாரமாக உள்ளன. உண்மை, பொறியாளர்கள் இன்னும் நினைவாற்றலில் கவனமாக இருக்க வேண்டும் மற்றும் குறியீட்டில் உள்ள மாநில சிக்கல்களைப் பற்றி எச்சரிக்கையாக இருக்க வேண்டும் (இந்த விஷயங்களைப் புறக்கணிக்கக்கூடிய மொழி இருக்கிறதா?). இருப்பினும், PHP 7 எங்களுக்காக குறைவான ஆச்சரியங்களைக் கொண்டுள்ளது.

நீண்ட கால PHP ஸ்கிரிப்ட்களுடன் பணிபுரியும் மாதிரியை எடுத்து, HTTP கோரிக்கைகளை செயலாக்குவது போன்ற மிகவும் அற்பமான பணிகளுக்கு அதை மாற்றியமைத்து, ஒவ்வொரு கோரிக்கையிலும் புதிதாக எல்லாவற்றையும் ஏற்ற வேண்டிய அவசியத்திலிருந்து விடுபட முடியுமா?

இந்தச் சிக்கலைத் தீர்க்க, முதலில் HTTP கோரிக்கைகளை ஏற்கக்கூடிய சர்வர் பயன்பாட்டைச் செயல்படுத்த வேண்டும் மற்றும் ஒவ்வொரு முறையும் அதைக் கொல்லாமல் PHP பணியாளருக்கு ஒவ்வொன்றாக திருப்பி விட வேண்டும்.

சுத்தமான PHP (PHP-PM) அல்லது C நீட்டிப்பை (ஸ்வூல்) பயன்படுத்தி இணைய சேவையகத்தை எழுதலாம் என்று எங்களுக்குத் தெரியும். ஒவ்வொரு முறைக்கும் அதன் சொந்த தகுதிகள் இருந்தாலும், இரண்டு விருப்பங்களும் எங்களுக்கு பொருந்தவில்லை - நாங்கள் இன்னும் ஏதாவது விரும்பினோம். எங்களுக்கு ஒரு வலை சேவையகத்தை விட அதிகம் தேவை - PHP இல் "கடினமான தொடக்கத்துடன்" தொடர்புடைய சிக்கல்களிலிருந்து எங்களைக் காப்பாற்றக்கூடிய ஒரு தீர்வைப் பெறுவோம் என்று நாங்கள் எதிர்பார்க்கிறோம், அதே நேரத்தில் குறிப்பிட்ட பயன்பாடுகளுக்கு எளிதாகத் தழுவி நீட்டிக்க முடியும். அதாவது, எங்களுக்கு ஒரு பயன்பாட்டு சேவையகம் தேவைப்பட்டது.

இதற்கு உதவி செய்ய முடியுமா? மொழி பயன்பாடுகளை ஒற்றை பைனரிகளாக தொகுக்கிறது என்பதால் அது முடியும் என்று எங்களுக்குத் தெரியும்; அது குறுக்கு மேடை; அதன் சொந்த, மிக நேர்த்தியான, இணையான செயலாக்க மாதிரி (ஒத்திசைவு) மற்றும் HTTP உடன் பணிபுரிய ஒரு நூலகத்தைப் பயன்படுத்துகிறது; இறுதியாக, ஆயிரக்கணக்கான திறந்த மூல நூலகங்கள் மற்றும் ஒருங்கிணைப்புகள் நமக்குக் கிடைக்கும்.

இரண்டு நிரலாக்க மொழிகளை இணைப்பதில் உள்ள சிரமங்கள்

முதலில், இரண்டு அல்லது அதற்கு மேற்பட்ட பயன்பாடுகள் ஒருவருக்கொருவர் எவ்வாறு தொடர்புகொள்வது என்பதை தீர்மானிக்க வேண்டியது அவசியம்.

உதாரணமாக, பயன்படுத்தி சிறந்த நூலகம் அலெக்ஸ் பேலஸ்ட்ராஸ், PHP மற்றும் Go செயல்முறைகளுக்கு இடையே நினைவகத்தைப் பகிர்ந்து கொள்ள முடிந்தது (அப்பாச்சியில் உள்ள mod_php போன்றது). ஆனால் இந்த நூலகம் நமது பிரச்சனையைத் தீர்ப்பதற்கான அதன் பயன்பாட்டைக் கட்டுப்படுத்தும் அம்சங்களைக் கொண்டுள்ளது.

வேறுபட்ட, மிகவும் பொதுவான அணுகுமுறையைப் பயன்படுத்த முடிவு செய்தோம்: சாக்கெட்டுகள் / பைப்லைன்கள் மூலம் செயல்முறைகளுக்கு இடையே தொடர்புகளை உருவாக்க. இந்த அணுகுமுறை கடந்த தசாப்தங்களாக நம்பகமானதாக நிரூபிக்கப்பட்டுள்ளது மற்றும் இயக்க முறைமை மட்டத்தில் நன்கு உகந்ததாக உள்ளது.

தொடங்குவதற்கு, செயல்முறைகளுக்கு இடையில் தரவைப் பரிமாறிக்கொள்வதற்கும் பரிமாற்றப் பிழைகளைக் கையாளுவதற்கும் ஒரு எளிய பைனரி நெறிமுறையை உருவாக்கினோம். எளிமையான வடிவத்தில், இந்த வகை நெறிமுறை ஒத்ததாகும் நெட்ஸ்ட்ரிங் с நிலையான அளவு பாக்கெட் தலைப்பு (எங்கள் விஷயத்தில் 17 பைட்டுகள்), இது பாக்கெட்டின் வகை, அதன் அளவு மற்றும் தரவின் ஒருமைப்பாட்டை சரிபார்க்க பைனரி மாஸ்க் பற்றிய தகவல்களைக் கொண்டுள்ளது.

PHP பக்கத்தில் நாங்கள் பயன்படுத்தினோம் பேக் செயல்பாடு, மற்றும் கோ பக்கத்தில், நூலகம் குறியாக்கம்/பைனரி.

ஒரு நெறிமுறை போதாது என்று எங்களுக்குத் தோன்றியது - மேலும் நாங்கள் அழைக்கும் திறனைச் சேர்த்துள்ளோம் net/rpc go சேவைகள் நேரடியாக PHP இலிருந்து. பின்னர், PHP பயன்பாடுகளில் Go நூலகங்களை எளிதாக ஒருங்கிணைக்க முடியும் என்பதால், இது வளர்ச்சியில் எங்களுக்கு மிகவும் உதவியது. இந்த வேலையின் முடிவைக் காணலாம், எடுத்துக்காட்டாக, எங்கள் மற்ற திறந்த மூல தயாரிப்பில் கோரிட்ஜ்.

பல PHP தொழிலாளர்கள் முழுவதும் பணிகளை விநியோகித்தல்

தொடர்பு பொறிமுறையை செயல்படுத்திய பிறகு, PHP செயல்முறைகளுக்கு பணிகளை மாற்றுவதற்கான மிகச் சிறந்த வழியைப் பற்றி சிந்திக்கத் தொடங்கினோம். ஒரு பணி வரும்போது, ​​அதைச் செயல்படுத்த பயன்பாட்டு சேவையகம் ஒரு இலவச பணியாளரைத் தேர்ந்தெடுக்க வேண்டும். ஒரு தொழிலாளி/செயல்முறை பிழையுடன் வெளியேறினால் அல்லது "இறந்தால்", அதை அகற்றிவிட்டு, அதற்குப் பதிலாக புதிய ஒன்றை உருவாக்குவோம். தொழிலாளி/செயல்முறை வெற்றிகரமாக முடிந்துவிட்டால், பணிகளைச் செய்ய இருக்கும் தொழிலாளர்களின் தொகுப்பிற்கு அதைத் திருப்பித் தருவோம்.

செயலில் உள்ள தொழிலாளர்களின் குளத்தை சேமிக்க, நாங்கள் பயன்படுத்தினோம் இடையக சேனல், எதிர்பாராத விதமாக "இறந்த" தொழிலாளர்களை குளத்தில் இருந்து அகற்ற, பிழைகள் மற்றும் தொழிலாளர்களின் நிலைகளைக் கண்காணிப்பதற்கான ஒரு பொறிமுறையைச் சேர்த்துள்ளோம்.

இதன் விளைவாக, பைனரி வடிவத்தில் வழங்கப்பட்ட எந்தவொரு கோரிக்கையையும் செயலாக்கும் திறன் கொண்ட ஒரு வேலை செய்யும் PHP சேவையகத்தைப் பெற்றுள்ளோம்.

எங்கள் பயன்பாடு ஒரு வலை சேவையகமாக செயல்படத் தொடங்க, உள்வரும் HTTP கோரிக்கைகளை பிரதிநிதித்துவப்படுத்த நம்பகமான PHP தரநிலையை நாங்கள் தேர்வு செய்ய வேண்டும். எங்கள் விஷயத்தில், நாங்கள் தான் மாற்றம் Go to format இலிருந்து net/http கோரிக்கை பி.எஸ்.ஆர்-7இன்று கிடைக்கும் பெரும்பாலான PHP கட்டமைப்புகளுடன் இது இணக்கமாக உள்ளது.

PSR-7 மாறாததாகக் கருதப்படுவதால் (தொழில்நுட்ப ரீதியாக அது இல்லை என்று சிலர் கூறுவார்கள்), டெவலப்பர்கள் கோரிக்கையை உலகளாவிய நிறுவனமாகக் கருதாத பயன்பாடுகளை எழுத வேண்டும். இது நீண்ட கால PHP செயல்முறைகளின் கருத்துடன் நன்றாகப் பொருந்துகிறது. இன்னும் பெயரிடப்படாத எங்கள் இறுதி செயலாக்கம் இப்படி இருந்தது:

ரோட் ரன்னர் அறிமுகம் - உயர் செயல்திறன் PHP பயன்பாட்டு சேவையகம்

எங்களின் முதல் சோதனைப் பணி API பின்தளம் ஆகும், இது அவ்வப்போது எதிர்பாராத விதமாக வெடிக்கும் (வழக்கத்தை விட அடிக்கடி). பெரும்பாலான சந்தர்ப்பங்களில் nginx போதுமானதாக இருந்தபோதிலும், நாங்கள் தொடர்ந்து 502 பிழைகளை எதிர்கொண்டோம், ஏனெனில் சுமைகளில் எதிர்பார்க்கப்படும் அதிகரிப்புக்கு கணினியை விரைவாக சமநிலைப்படுத்த முடியவில்லை.

இந்த தீர்வை மாற்ற, 2018 ஆம் ஆண்டின் தொடக்கத்தில் எங்களின் முதல் PHP/Go பயன்பாட்டு சேவையகத்தைப் பயன்படுத்தினோம். உடனடியாக ஒரு நம்பமுடியாத விளைவு கிடைத்தது! 502 பிழையை முற்றிலுமாக அகற்றியது மட்டுமல்லாமல், சேவையகங்களின் எண்ணிக்கையை மூன்றில் இரண்டு பங்கு குறைக்க முடிந்தது, பொறியாளர்கள் மற்றும் தயாரிப்பு மேலாளர்களுக்கு நிறைய பணத்தையும் தலைவலி மாத்திரைகளையும் மிச்சப்படுத்தியது.

ஆண்டின் நடுப்பகுதியில், நாங்கள் எங்கள் தீர்வை மேம்படுத்தி, MIT உரிமத்தின் கீழ் GitHub இல் வெளியிட்டு அதற்குப் பெயரிட்டோம். ரோட்ரன்னர், இதனால் அதன் நம்பமுடியாத வேகம் மற்றும் செயல்திறனை வலியுறுத்துகிறது.

RoadRunner உங்கள் டெவலப்மெண்ட் ஸ்டேக்கை எவ்வாறு மேம்படுத்தலாம்

விண்ணப்ப ரோட்ரன்னர் கோரிக்கை PHP ஐ அடையும் முன் JWT சரிபார்ப்பைச் செய்ய Go பக்கத்தில் Middleware net/http ஐப் பயன்படுத்த அனுமதித்தது, அத்துடன் WebSockets ஐக் கையாளவும் மற்றும் ப்ரோமிதியஸில் உலகளவில் ஒட்டுமொத்த நிலையைக் கையாளவும் அனுமதித்தது.

உள்ளமைக்கப்பட்ட RPCக்கு நன்றி, நீட்டிப்பு ரேப்பர்களை எழுதாமல் PHPக்கான எந்த Go லைப்ரரிகளின் APIயையும் திறக்கலாம். மிக முக்கியமாக, RoadRunner மூலம் நீங்கள் புதிய HTTP அல்லாத சேவையகங்களை வரிசைப்படுத்தலாம். எடுத்துக்காட்டுகளில் PHP இல் இயங்கும் ஹேண்ட்லர்கள் அடங்கும் AWS லாம்ப்டா, நம்பகமான க்யூ பிரேக்கர்களை உருவாக்குதல், மேலும் சேர்க்கிறது gRPC எங்கள் விண்ணப்பங்களுக்கு.

PHP மற்றும் Go சமூகங்களின் உதவியுடன், தீர்வின் நிலைத்தன்மையை மேம்படுத்தினோம், சில சோதனைகளில் பயன்பாட்டின் செயல்திறனை 40 மடங்கு வரை அதிகரித்துள்ளோம், மேம்படுத்தப்பட்ட பிழைத்திருத்தக் கருவிகள், சிம்ஃபோனி கட்டமைப்புடன் செயல்படுத்தப்பட்ட ஒருங்கிணைப்பு மற்றும் HTTPS, HTTP/2 க்கான ஆதரவைச் சேர்த்துள்ளோம். செருகுநிரல்கள் மற்றும் PSR-17.

முடிவுக்கு

வேர்ட்பிரஸ்ஸிற்கான செருகுநிரல்களை எழுதுவதற்கு மட்டுமே சிறந்த, மெதுவான, அசாத்தியமான மொழியாக PHP இன் காலாவதியான எண்ணத்தில் சிலர் இன்னும் சிக்கியுள்ளனர். இந்த நபர்கள் PHP க்கு அத்தகைய வரம்பு இருப்பதாகக் கூட கூறலாம்: பயன்பாடு போதுமானதாக இருக்கும்போது, ​​​​நீங்கள் மிகவும் "முதிர்ந்த" மொழியைத் தேர்வுசெய்து பல ஆண்டுகளாக திரட்டப்பட்ட குறியீட்டு தளத்தை மீண்டும் எழுத வேண்டும்.

இவை அனைத்திற்கும் நான் பதிலளிக்க விரும்புகிறேன்: மீண்டும் சிந்தியுங்கள். PHP க்கு நீங்கள் மட்டுமே கட்டுப்பாடுகளை அமைத்துள்ளீர்கள் என்று நாங்கள் நம்புகிறோம். உங்கள் முழு வாழ்க்கையையும் ஒரு மொழியிலிருந்து மற்றொரு மொழிக்கு மாற்றலாம், உங்கள் தேவைகளுக்கு சரியான பொருத்தத்தைக் கண்டறிய முயற்சி செய்யலாம் அல்லது மொழிகளைக் கருவிகளாகக் கருதத் தொடங்கலாம். PHP போன்ற மொழியின் கூறப்படும் குறைபாடுகள் உண்மையில் அதன் வெற்றிக்கு காரணமாக இருக்கலாம். நீங்கள் அதை Go போன்ற மற்றொரு மொழியுடன் இணைத்தால், நீங்கள் எந்த ஒரு மொழியையும் பயன்படுத்துவதை விட மிகவும் சக்திவாய்ந்த தயாரிப்புகளை உருவாக்குவீர்கள்.

Go மற்றும் PHP ஆகியவற்றுடன் பணிபுரிந்ததால், நாங்கள் அவர்களை விரும்புகிறோம் என்று சொல்லலாம். ஒன்றை மற்றொன்றிற்காக தியாகம் செய்ய நாங்கள் திட்டமிடவில்லை - மாறாக, இந்த இரட்டை அடுக்கிலிருந்து இன்னும் அதிக மதிப்பைப் பெறுவதற்கான வழிகளைத் தேடுவோம்.

UPD: RoadRunner ஐ உருவாக்கியவர் மற்றும் அசல் கட்டுரையின் இணை ஆசிரியரை வரவேற்கிறோம் - Lachesis

ஆதாரம்: www.habr.com