سلام، حبر! موږ په بدو کې فعال یو ، ځکه چې موږ پدې ژبه کې خورا لوی سیسټم لرو او د فعالیت مسله د پیسو سپمولو مسله ده. لس کاله دمخه، موږ د دې لپاره PHP-FPM جوړ کړ، کوم چې په لومړي سر کې د پی ایچ پی لپاره د پیچونو سیټ و، او وروسته د رسمي ویش برخه شوه.
په وروستیو کلونو کې، PHP لوی پرمختګ کړی دی: د کثافاتو راټولونکی ښه شوی، د ثبات کچه لوړه شوې - نن ورځ تاسو کولی شئ په PHP کې پرته له کومې ستونزې ډیمونونه او اوږدمهاله سکریپټونه ولیکئ. دې سرپل سکاوټ ته اجازه ورکړه چې نور لاړ شي: RoadRunner، د PHP-FPM برعکس، د غوښتنو ترمنځ حافظه نه پاکوي، کوم چې د فعالیت اضافي ګټې وړاندې کوي (که څه هم دا طریقه د پراختیا پروسه پیچلې کوي). موږ اوس مهال د دې وسیلې سره تجربه کوو، مګر موږ تر اوسه د شریکولو لپاره کومه پایله نه لرو. د دې لپاره چې دوی ته انتظار کول ډیر ساتیري کړي، موږ د سرپل سکاوټ څخه د RoadRunner اعلان ژباړه خپروو.
د مقالې طریقه موږ ته نږدې ده: کله چې زموږ ستونزې حل کوو، موږ ډیری وختونه د PHP او Go ترکیب هم کاروو، د دواړو ژبو ګټې ترلاسه کوو او یو د بل په ګټه نه پریږدو.
خوند!
په تیرو لسو کلونو کې، موږ د لیست څخه د شرکتونو لپاره غوښتنلیکونه جوړ کړي دي ، او د سوداګرۍ لپاره چې لیدونکي یې له 500 څخه ډیر کاروونکي نلري. دا ټول وخت، زموږ انجنیرانو په عمده توګه په پی ایچ پی کې پس منظر ته وده ورکړه. مګر دوه کاله دمخه ، یو څه نه یوازې زموږ د محصولاتو په فعالیت ، بلکه د دوی په توزیع کولو باندې هم لوی تاثیر وکړ - موږ زموږ د ټیکنالوژۍ سټیک ته ګولنګ (ګو) معرفي کړ.
نږدې سمدلاسه ، موږ وموندله چې Go موږ ته اجازه راکړه چې تر 40x ګړندي فعالیت سره لوی غوښتنلیکونه جوړ کړو. د دې سره، موږ وتوانیدو چې په PHP کې لیکل شوي موجوده محصولات پراخ کړو، د دواړو ژبو ګټو سره یوځای کولو سره یې ښه کړو.
موږ به تاسو ته ووایو چې څنګه د Go او PHP ترکیب د ریښتیني پراختیا ستونزې حل کولو کې مرسته کوي او دا څنګه زموږ لپاره په یوه وسیله بدل شوی چې کولی شي ځینې ستونزې له منځه یوسي. .
ستاسو هره ورځ د پی ایچ پی پرمختیا چاپیریال
مخکې لدې چې موږ د دې په اړه وغږیږو چې تاسو څنګه کولی شئ د PHP مړ شوي ماډل ژوندي کولو لپاره Go وکاروئ ، راځئ چې ستاسو د PHP معیاري پراختیا چاپیریال ته یو نظر وګورو.
په ډیری قضیو کې ، تاسو غوښتنلیک د نګینکس ویب سرور او PHP-FPM سرور ترکیب په کارولو سره پرمخ وړئ. لومړی جامد فایلونه خدمت کوي او ځانګړي غوښتنې PHP-FPM ته لیږدوي، او PHP-FPM پخپله د PHP کوډ اجرا کوي. شاید تاسو د Apache او mod_php څخه لږ مشهور ترکیب کاروئ. مګر که څه هم دا یو څه مختلف کار کوي، اصول ورته دي.
راځئ وګورو چې څنګه PHP-FPM د غوښتنلیک کوډ اجرا کوي. کله چې غوښتنه راشي، PHP-FPM د ماشوم PHP پروسه پیلوي او د غوښتنې توضیحات د دې حالت (_GET، _POST، _SERVER، او نور) برخې په توګه لیږدوي.
دولت نشي کولی د PHP سکریپټ اجرا کولو په جریان کې بدلون ومومي، نو د ان پټ ډیټا نوي سیټ ترلاسه کولو لپاره یوازې یوه لاره شتون لري: د پروسې حافظې پاکول او بیا پیل کول.
د دې اعدام ماډل ډیری ګټې لري. تاسو اړتیا نلرئ د حافظې مصرف په اړه ډیر اندیښنه ولرئ، ټولې پروسې په بشپړه توګه جلا شوي، او که یو له دوی څخه مړ شي، دا به په اتوماتيک ډول بیا جوړ شي پرته له دې چې پاتې پروسې اغیزه وکړي. مګر دا طریقه هم زیانونه لري چې د غوښتنلیک اندازه کولو هڅه کولو پرمهال څرګندیږي.
د منظم پی ایچ پی چاپیریال نیمګړتیاوې او بې کفایتي
که تاسو په PHP کې مسلکي پرمختګ کې بوخت یاست، نو تاسو پوهیږئ چې کومه نوې پروژه پیل کړئ - د چوکاټ غوره کولو سره. دا د انحصار انجیکشن، ORMs، ژباړې او ټیمپلیټونو لپاره کتابتونونه لري. او البته، د کاروونکي ټول معلومات په اسانۍ سره په یوه څیز کې کیښودل کیدی شي (سیمفوني/HttpFoundation یا PSR-7). چوکاټونه ښه دي!
مګر هرڅه خپل قیمت لري. د هرې تصدۍ کچې چوکاټ کې ، د ساده کارونکي غوښتنې پروسس کولو یا ډیټابیس ته لاسرسي لپاره ، تاسو باید لږترلږه لسګونه فایلونه پورته کړئ ، ډیری ټولګي رامینځته کړئ او ډیری تشکیلات پارس کړئ. مګر ترټولو بد شی دا دی چې د هر کار بشپړولو وروسته تاسو اړتیا لرئ هرڅه له سره تنظیم کړئ او بیا یې پیل کړئ: ټول هغه کوډ چې تاسو یې پیل کړی بې ګټې کیږي، د هغې په مرسته تاسو به نور غوښتنه ونه کړئ. دا هر پروګرامر ته ووایاست چې په بله ژبه لیکي، او تاسو به د هغه په مخ کې حیرانتیا وګورئ.
د پی ایچ پی انجینرانو کلونه د دې ستونزې د حل کولو لارو په لټه کې تیر کړي ، د هوښیار سست بار کولو تخنیکونو ، مایکرو فریم ورکونو ، مطلوب کتابتونونو ، کیچونو او نورو په کارولو سره. (د ژباړونکي یادونه: دا ستونزه به تر یوې اندازې پورې حل شي په پی ایچ پی 7.4 کې)
ایا د Go سره PHP کولی شي له یوې څخه ډیرې غوښتنې ژوندي وساتي؟
دا ممکنه ده چې د PHP سکریپټونه ولیکئ چې د څو دقیقو څخه ډیر اوږد وي (تر ساعتونو یا ورځو پورې): د مثال په توګه، کرون دندې، CSV پارسر، قطار بسټرونه. دوی ټول د ورته سناریو سره سم کار کوي: دوی یو کار بیرته ترلاسه کوي، اجرا کوي، او بل ته انتظار کوي. کوډ په حافظه کې پاتې کیږي، قیمتي ملیسیکنډونه خوندي کوي ځکه چې د چوکاټ او غوښتنلیک بارولو لپاره ډیری اضافي ګامونو ته اړتیا ده.
مګر د اوږدمهاله سکریپټونو رامینځته کول دومره اسانه ندي. هره تېروتنه پروسه په بشپړه توګه وژني، د حافظې لیک تشخیص کول تاسو لیونی کوي، او تاسو نور نشي کولی د F5 ډیبګینګ وکاروئ.
د PHP 7 په خپرولو سره وضعیت ښه شوی: د باور وړ کثافاتو راټولونکی څرګند شوی ، د غلطیو اداره کول اسانه شوي ، او د کرنل توسیع اوس د لیک څخه خوندي دي. ریښتیا ، انجینران لاهم اړتیا لري د حافظې سره محتاط وي او په کوډ کې د دولت مسلو څخه خبر وي (ایا کومه ژبه شتون لري چیرې چې موږ د دې شیانو په اړه اندیښنه نلرو؟). او بیا هم، په پی ایچ پی 7 کې، لږ حیرانتیاوې زموږ په تمه دي.
ایا دا ممکنه ده چې د اوږدمهاله پی ایچ پی سکریپټونو سره د کار کولو ماډل واخلئ، دا د HTTP غوښتنو پروسس کولو په څیر نورو کوچنیو دندو ته تطبیق کړئ، او په دې توګه د هرې غوښتنې لپاره د سکریچ څخه هرڅه پورته کولو اړتیا له منځه یوسي؟
د دې ستونزې د حل کولو لپاره، موږ لومړی د سرور غوښتنلیک پلي کولو ته اړتیا لرو چې کولی شي د HTTP غوښتنې ومني او هر ځل یې له وژلو پرته د پی ایچ پی کارکونکي ته یو له بل سره ولېږدوي.
موږ پوهیږو چې موږ کولی شو د ویب سرور په خالص پی ایچ پی (PHP-PM) کې یا د C توسیع (Swoole) په کارولو سره ولیکو. او که څه هم هره طریقه خپل ځانګړتیاوې لري، دواړه اختیارونه موږ ته مناسب نه و - موږ یو څه نور غواړو. موږ یوازې د ویب سرور څخه ډیر څه ته اړتیا درلوده - موږ هیله درلوده چې داسې حل ترلاسه کړو چې کولی شي موږ په PHP کې د "سخت پیل" سره تړلو ستونزو څخه وژغورو، کوم چې په ورته وخت کې د ځانګړو غوښتنلیکونو لپاره په اسانۍ سره تطبیق او پراخ کیدی شي. دا دی، موږ د غوښتنلیک سرور ته اړتیا لرو.
کولی شئ پدې کې مرسته وکړئ؟ موږ پوهیږو چې دا کیدی شي ځکه چې ژبه غوښتنلیکونه په واحد بائنریونو کې راټولوي؛ دا کراس پلیټ فارم دی؛ د HTTP سره د کار کولو لپاره خپل، خورا ښکلی، موازي پروسس کولو ماډل (متوازن) او کتابتون کاروي؛ او په نهایت کې ، په زرګونو خلاصې سرچینې کتابتونونه او ادغام به موږ ته شتون ولري.
د دوو پروګرامینګ ژبو د یوځای کولو ستونزې
لومړی ګام دا و چې دا معلومه کړي چې دوه یا ډیر غوښتنلیکونه به د یو بل سره څنګه اړیکه ونیسي.
د مثال په توګه، کارول الیکس پالیسټراس کولی شي د پی ایچ پی او ګو پروسو ترمنځ د حافظې شریکول پلي کړي (په اپاچي کې mod_php ته ورته). مګر دا کتابتون داسې ځانګړتیاوې لري چې زموږ د ستونزې د حل لپاره یې کارول محدودوي.
موږ پریکړه وکړه چې یو بل، ډیر عام، طریقه وکاروو: د ساکټ / پایپ لاینونو له لارې د پروسو ترمنځ تعامل رامینځته کول. دې طریقې په تیرو لسیزو کې خپل اعتبار ثابت کړی او د عملیاتي سیسټم په کچه ښه ښه شوی.
د پیل کولو لپاره، موږ د پروسو ترمنځ د معلوماتو تبادلې او د لیږد غلطیو اداره کولو لپاره یو ساده بائنری پروتوکول جوړ کړ. په ساده بڼه کې، دا ډول پروتوکول ورته دی с (زموږ په قضیه کې 17 بایټ) ، کوم چې د کڅوړې ډول ، د هغې اندازې او د معلوماتو بشپړتیا چک کولو لپاره بائنری ماسک په اړه معلومات لري.
د پی ایچ پی اړخ کې موږ کارولی شو ، او د تګ په لور - یو کتابتون.
دا موږ ته داسې بریښي چې یو پروتوکول کافي نه و - نو موږ د زنګ وهلو وړتیا اضافه کړه. دا وروسته زموږ سره په پراختیا کې ډیره مرسته وکړه، ځکه چې موږ کولی شو په اسانۍ سره د PHP غوښتنلیکونو کې د Go کتابتونونه مدغم کړو. د دې کار پایله لیدل کیدی شي، د بیلګې په توګه، زموږ په بل خلاص سرچینې محصول کې.
د ډیری پی ایچ پی کارمندانو په اوږدو کې د دندو ویش
د متقابل عمل میکانیزم پلي کولو وروسته، موږ د دې په اړه فکر پیل کړ چې څنګه د پی ایچ پی پروسو ته دندې په خورا اغیزمنه توګه انتقال کړو. کله چې یو کار راشي، د غوښتنلیک سرور باید د بشپړولو لپاره وړیا کارګر غوره کړي. که چیرې یو کارګر/پروسیجر د غلطۍ سره پای ته ورسیږي یا "مړ شي،" موږ له هغې څخه ځان خلاصوو او د هغې د ځای په ځای کولو لپاره یو نوی جوړوو. او که چیرې کارګر/پروسیجر په بریالیتوب سره بشپړ شوی وي، موږ یې د دندو د ترسره کولو لپاره د کارګرانو حوض ته بیرته ورکوو.
د فعالو کارمندانو د حوض ذخیره کولو لپاره موږ کارولی، د حوض څخه په ناڅاپي ډول "مړ" کارګران لرې کولو لپاره ، موږ د غلطیو او کارګر حالتونو تعقیب لپاره میکانیزم اضافه کړ.
د پایلې په توګه، موږ یو کاري PHP سرور ترلاسه کړ چې په بائنری بڼه کې وړاندې شوي هرې غوښتنې پروسس کولو توان لري.
د دې لپاره چې زموږ غوښتنلیک د ویب سرور په توګه کار وکړي، موږ باید د PHP د اعتبار وړ معیار غوره کړو ترڅو د راتلونکو HTTP غوښتنو استازیتوب وکړو. زموږ په قضیه کې موږ یوازې د net/http غوښتنه فارمیټ ته لاړ شئنو دا د نن ورځې د ډیری پی ایچ پی چوکاټونو سره مطابقت لري.
ځکه چې PSR-7 بدلیدونکی ګ . دا د اوږدمهاله PHP پروسو مفهوم سره په ښه توګه فټ کوي. زموږ وروستی تطبیق، چې تراوسه یې نوم نه دی اخیستل شوی، داسې ښکاري:
د روډ رنر معرفي کول -
زموږ لومړنۍ ازموینې دنده د API بیکینډ وه، کوم چې په منظمه توګه د غیر متوقع غوښتنو سره مخامخ کیږي (د معمول په پرتله ډیر ځله). که څه هم نګینکس په ډیری قضیو کې کافي و، موږ په منظمه توګه د 502 غلطیو سره مخ شو ځکه چې موږ نشو کولی سیسټم په چټکۍ سره د متوقع زیاتوالي لپاره توازن کړو.
د دې حل بدلولو لپاره، موږ د 2018 په پیل کې زموږ لومړی PHP/Go غوښتنلیک سرور ځای پرځای کړ. او سمدلاسه موږ د نه منلو وړ اغیزه ترلاسه کړه! نه یوازې موږ د 502 تېروتنې څخه په بشپړه توګه خلاص شو، مګر موږ د دې توان هم درلود چې د سرورونو شمیر دوه پر دریمه برخه راټیټ کړي، د انجنیرانو او محصول مدیرانو لپاره ډیرې پیسې او سر دردونه خوندي کړي.
د کال په نیمایي کې، موږ خپل حل بشپړ کړی و، دا یې د MIT جواز لاندې په GitHub کې خپور کړ، او دا یې نومول. ، په دې توګه د دې په نه منلو وړ سرعت او موثریت ټینګار کوي.
څنګه روډ رنر کولی شي ستاسو د پراختیا سټیک ته وده ورکړي
کاریال موږ ته اجازه راکړئ چې د JWT تایید ترسره کولو لپاره په Go اړخ کې د Middleware net/http څخه کار واخلو مخکې لدې چې غوښتنه حتی PHP ته زیان ورسوي ، په بیله بیا په Prometheus کې د WebSockets او نړیوال دولت مجموعه اداره کولو لپاره.
د جوړ شوي RPC څخه مننه ، تاسو کولی شئ د PHP لپاره د هر ډول Go کتابتون API خلاص کړئ پرته لدې چې د توسیع ریپرونو لیکلو. تر ټولو مهم، د روډ رنر د نوي غیر HTTP سرورونو ځای پرځای کولو لپاره کارول کیدی شي. په مثالونو کې په PHP کې د هینډلرونو پیل کول شامل دي، د باور وړ کتار بسټرونه رامینځته کول او حتی اضافه کول زموږ غوښتنلیکونو ته.
د PHP او Go ټولنو په مرسته، موږ د حل ثبات زیات کړی، په ځینو ازموینو کې د غوښتنلیک فعالیت تر 40 ځله زیات کړی، د ډیبګ کولو وسیلې یې ښه کړي، د سیمفوني چوکاټ سره یوځای کول پلي کړي، او د HTTPS، HTTP/ لپاره ملاتړ اضافه کړي. 2، پلگ ان، او PSR-17.
پایلې
ځینې خلک لاهم د PHP په زوړ لید کې د ورو ، پیچلې ژبې په توګه نیول شوي یوازې د ورڈپریس پلگ انونو لیکلو لپاره ښه دي. دا خلک ممکن حتی ووایی چې PHP یو محدودیت لري: کله چې غوښتنلیک خورا لوی شي ، تاسو باید ډیر "بالغ" ژبه غوره کړئ او د کوډ اساس بیا ولیکئ چې د ډیری کلونو راهیسې راټول شوی.
دې ټولو ته زه غواړم ځواب ورکړم: بیا فکر وکړئ. موږ باور لرو چې یوازې تاسو کولی شئ د PHP لپاره کوم محدودیتونه تنظیم کړئ. تاسو کولی شئ خپل ټول ژوند له یوې ژبې څخه بلې ژبې ته په کودتا کې تیر کړئ، د خپلو اړتیاو لپاره د مناسب میچ موندلو هڅه وکړئ، یا تاسو کولی شئ د وسیلو په توګه د ژبې فکر پیل کړئ. د پی ایچ پی په څیر د ژبې پیژندل شوي نیمګړتیاوې ممکن واقعیا د هغې د بریا لاملونه وي. او که تاسو دا د بلې ژبې سره یوځای کړئ لکه Go، تاسو کولی شئ ډیر پیاوړي محصولات جوړ کړئ که تاسو یوازې یوې ژبې پورې محدود یاست.
د Go او PHP ترکیب سره کار کولو سره ، موږ کولی شو ووایو چې موږ له دوی سره مینه لرو. موږ پلان نه لرو چې یو د بل لپاره قرباني کړو ، بلکه د دې دوه ګوني سټیک څخه د لا ډیر ارزښت ترلاسه کولو لارې لټوو.
UPD: موږ د RoadRunner جوړونکي او د اصلي مقالې شریک لیکوال ته ښه راغلاست وایو -
سرچینه: www.habr.com