RoadRunner: PHP არ არის შექმნილი იმისთვის, რომ მოკვდეს, ან გოლანგი გადასარჩენად

გამარჯობა, ჰაბრ! ჩვენ აქტიურები ვართ Badoo-ში მუშაობს PHP შესრულებაზე, ვინაიდან ამ ენაში საკმაოდ დიდი სისტემა გვაქვს და შესრულების საკითხი ფულის დაზოგვის საკითხია. ათ წელზე მეტი ხნის წინ ჩვენ ამისთვის შევქმენით PHP-FPM, რომელიც თავდაპირველად იყო პაჩების ნაკრები PHP-სთვის, შემდეგ კი გახდა ოფიციალური განაწილების ნაწილი.

ბოლო წლებში PHP-მ დიდი პროგრესი განიცადა: გაუმჯობესდა ნაგვის შემგროვებელი, გაიზარდა სტაბილურობის დონე - დღეს თქვენ შეგიძლიათ უპრობლემოდ დაწეროთ დემონები და გრძელვადიანი სკრიპტები PHP-ში. ეს საშუალებას აძლევდა Spiral Scout-ს უფრო შორს წასულიყო: RoadRunner-ი, PHP-FPM-ისგან განსხვავებით, არ ასუფთავებს მეხსიერებას მოთხოვნებს შორის, რაც უზრუნველყოფს შესრულების დამატებით სარგებელს (თუმცა ეს მიდგომა ართულებს განვითარების პროცესს). ჩვენ ამჟამად ვატარებთ ამ ხელსაწყოს ექსპერიმენტებს, მაგრამ ჯერ არ გვაქვს გასაზიარებელი შედეგი. რომ უფრო სახალისო იყოს მათ ლოდინი, ჩვენ ვაქვეყნებთ RoadRunner-ის განცხადების თარგმანს Spiral Scout-ისგან.

სტატიიდან მიდგომა ჩვენთან ახლოსაა: ჩვენი პრობლემების გადაჭრისას, ჩვენ ასევე ყველაზე ხშირად ვიყენებთ PHP-ისა და Go-ს კომბინაციას, ვიღებთ ორივე ენის უპირატესობებს და არ ვუთმობთ ერთს მეორის სასარგებლოდ.

იხალისეთ!

ბოლო ათი წლის განმავლობაში ჩვენ შევქმენით აპლიკაციები კომპანიებისთვის სიიდან ბედის 500, და ბიზნესებისთვის, რომელთა აუდიტორია არ აღემატება 500 მომხმარებელს. მთელი ამ ხნის განმავლობაში, ჩვენმა ინჟინრებმა განავითარეს ბექენდი ძირითადად PHP-ში. მაგრამ ორი წლის წინ რაღაცამ დიდი გავლენა მოახდინა არა მხოლოდ ჩვენი პროდუქციის შესრულებაზე, არამედ მათ მასშტაბურობაზეც - ჩვენ გავაცანით Golang (Go) ჩვენს ტექნოლოგიურ დასტაში.

თითქმის მაშინვე აღმოვაჩინეთ, რომ Go-მ მოგვცა საშუალება შეგვექმნა უფრო დიდი აპლიკაციები 40-ჯერ უფრო სწრაფი შესრულებით. მასთან ერთად, ჩვენ შევძელით გაფართოება PHP-ზე დაწერილი არსებული პროდუქტები, გავაუმჯობესეთ ისინი ორივე ენის უპირატესობების კომბინაციით.

ჩვენ გეტყვით, თუ როგორ გეხმარება Go-სა და PHP-ის კომბინაცია რეალური განვითარების პრობლემების გადაჭრაში და როგორ იქცა ის ჩვენთვის ინსტრუმენტად, რომელსაც შეუძლია აღმოფხვრას ზოგიერთი პრობლემა PHP მომაკვდავი მოდელი.

თქვენი ყოველდღიური PHP განვითარების გარემო

სანამ ვისაუბრებთ იმაზე, თუ როგორ შეგიძლიათ გამოიყენოთ Go 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-ებისგან, თარგმანებისა და შაბლონებისგან. და რა თქმა უნდა, მომხმარებლის ყველა შეყვანა შეიძლება მოხერხებულად მოთავსდეს ერთ ობიექტში (Symfony/HttpFoundation ან PSR-7). ჩარჩოები მაგარია!

მაგრამ ყველაფერს თავისი ფასი აქვს. ნებისმიერი საწარმოს დონეზე, მომხმარებლის მარტივი მოთხოვნის დასამუშავებლად ან მონაცემთა ბაზაში წვდომისთვის, მოგიწევთ მინიმუმ ათობით ფაილის ჩატვირთვა, მრავალი კლასის შექმნა და რამდენიმე კონფიგურაციის გაანალიზება. მაგრამ ყველაზე ცუდი ის არის, რომ ყოველი დავალების შესრულების შემდეგ მოგიწევთ ყველაფრის გადატვირთვა და თავიდან დაწყება: თქვენ მიერ ახლახან წამოწყებული ყველა კოდი უსარგებლო ხდება, მისი დახმარებით თქვენ აღარ დაამუშავებთ სხვა მოთხოვნას. უთხარით ეს ნებისმიერ პროგრამისტს, რომელიც სხვა ენაზე წერს და მის სახეზე დაბნეულობას დაინახავთ.

PHP ინჟინრები წლების განმავლობაში ეძებდნენ ამ პრობლემის გადაჭრის გზებს, იყენებდნენ ზარმაცი ჩატვირთვის ჭკვიანურ ტექნიკას, მიკროჩარჩოებს, ოპტიმიზებულ ბიბლიოთეკებს, ქეშებს და ა.შ. მაგრამ საბოლოო ჯამში, თქვენ მაინც უნდა გადატვირთოთ მთელი აპლიკაცია და დაიწყოთ თავიდან, ისევ და ისევ. (მთარგმნელის შენიშვნა: ეს პრობლემა ნაწილობრივ მოგვარდება მოსვლასთან ერთად preload PHP 7.4-ში)

შეუძლია თუ არა PHP-ს Go-ით ერთზე მეტი მოთხოვნის გადარჩენა?

შესაძლებელია დაწეროთ PHP სკრიპტები, რომლებიც გაგრძელდება რამდენიმე წუთზე მეტხანს (საათამდე ან დღეებამდე): მაგალითად, cron ამოცანები, CSV პარსერები, რიგის ამომწურავი. ისინი ყველა მუშაობენ ერთი და იგივე სცენარის მიხედვით: იბრუნებენ დავალებას, ასრულებენ და ელოდებიან შემდეგს. კოდი ინახება მეხსიერებაში და დაზოგავს ძვირფას მილიწამებს, რადგან ბევრი დამატებითი ნაბიჯია საჭირო ჩარჩოსა და აპლიკაციის ჩატვირთვისთვის.

მაგრამ გრძელვადიანი სკრიპტების შემუშავება არც ისე ადვილია. ნებისმიერი შეცდომა მთლიანად კლავს პროცესს, მეხსიერების გაჟონვის დიაგნოსტიკა გაგიჟებს და ვეღარ გამოიყენებ F5 გამართვას.

სიტუაცია გაუმჯობესდა PHP 7-ის გამოშვებით: გამოჩნდა სანდო ნაგვის შემგროვებელი, უფრო ადვილი გახდა შეცდომების დამუშავება და ბირთვის გაფართოებები ახლა დაცულია გაჟონვისგან. მართალია, ინჟინრებს ჯერ კიდევ სჭირდებათ მეხსიერების სიფრთხილე და კოდში არსებული მდგომარეობის საკითხების გათვალისწინება (არსებობს ენა, სადაც არ უნდა ვიფიქროთ ამ საკითხებზე?). და მაინც, PHP 7-ში ნაკლები სიურპრიზები გველოდება.

შესაძლებელია თუ არა ავიღოთ ხანგრძლივ PHP სკრიპტებთან მუშაობის მოდელი, მოერგოთ ის უფრო ტრივიალურ ამოცანებს, როგორიცაა HTTP მოთხოვნების დამუშავება და ამით აღმოვფხვრათ ყველაფრის ნულიდან ჩატვირთვის აუცილებლობა თითოეული მოთხოვნისთვის?

ამ პრობლემის გადასაჭრელად, ჩვენ ჯერ დაგვჭირდა სერვერის აპლიკაციის დანერგვა, რომელსაც შეეძლო მიეღო HTTP მოთხოვნები და სათითაოდ გადაგვეგზავნა ისინი PHP მუშაკთან ყოველ ჯერზე მისი მოკვლის გარეშე.

ჩვენ ვიცოდით, რომ შეგვეძლო ვებ სერვერის დაწერა სუფთა PHP (PHP-PM) ან C გაფართოების (Swoole) გამოყენებით. და მიუხედავად იმისა, რომ თითოეულ მეთოდს აქვს თავისი უპირატესობები, ორივე ვარიანტი არ ჯდება - ჩვენ გვინდოდა კიდევ რაღაც. ჩვენ გვჭირდებოდა მეტი, ვიდრე უბრალოდ ვებ სერვერი - ვიმედოვნებდით, რომ მიგვეღო გამოსავალი, რომელიც გადაგვარჩენდა PHP-ში „მძიმე დაწყებასთან“ დაკავშირებული პრობლემებისგან, რომელიც ამავდროულად შეიძლებოდა ადვილად ადაპტირდეს და გაფართოვდეს კონკრეტული აპლიკაციებისთვის. ანუ ჩვენ გვჭირდებოდა აპლიკაციის სერვერი.

შეიძლება Go დახმარება ამაში? ჩვენ ვიცოდით, რომ ეს შეიძლებოდა, რადგან ენა აგროვებს აპლიკაციებს ერთ ბინარებში; ეს არის კროს-პლატფორმული; იყენებს საკუთარ, ძალიან ელეგანტურ, პარალელური დამუშავების მოდელს (კონკურენტულობა) და ბიბლიოთეკას HTTP-თან მუშაობისთვის; და ბოლოს, ათასობით ღია ბიბლიოთეკა და ინტეგრაცია ხელმისაწვდომი იქნება ჩვენთვის.

ორი პროგრამირების ენის შერწყმის სირთულეები

პირველი ნაბიჯი იყო იმის დადგენა, თუ როგორ დაუკავშირდება ორი ან მეტი აპლიკაცია ერთმანეთთან.

მაგალითად, გამოყენებით მშვენიერი ბიბლიოთეკა ალექს პალაესტრასს შეეძლო მეხსიერების გაზიარების განხორციელება PHP და Go პროცესებს შორის (მსგავსი mod_php Apache-ში). მაგრამ ამ ბიბლიოთეკას აქვს ფუნქციები, რომლებიც ზღუდავს მის გამოყენებას ჩვენი პრობლემის გადასაჭრელად.

ჩვენ გადავწყვიტეთ გამოგვეყენებინა სხვა, უფრო გავრცელებული მიდგომა: პროცესებს შორის ურთიერთქმედების დამყარება სოკეტების/მილსადენების მეშვეობით. ამ მიდგომამ დაამტკიცა თავისი სანდოობა ბოლო ათწლეულების განმავლობაში და კარგად იყო ოპტიმიზირებული ოპერაციული სისტემის დონეზე.

დასაწყისისთვის, ჩვენ შევქმენით მარტივი ორობითი პროტოკოლი პროცესებს შორის მონაცემთა გაცვლისა და გადაცემის შეცდომების დასამუშავებლად. უმარტივესი ფორმით, ამ ტიპის პროტოკოლი მსგავსია ბადე სიმებიანი с ფიქსირებული ზომის პაკეტის სათაური (ჩვენს შემთხვევაში 17 ბაიტი), რომელიც შეიცავს ინფორმაციას პაკეტის ტიპის, მისი ზომის და ბინარული ნიღბის შესახებ მონაცემთა მთლიანობის შესამოწმებლად.

PHP მხარეს ჩვენ ვიყენებდით პაკეტის ფუნქცია, ხოლო Go მხარეს - ბიბლიოთეკა კოდირება/ორობითი.

ჩვენ გვეჩვენებოდა, რომ ერთი პროტოკოლი არ იყო საკმარისი - ამიტომ დავამატეთ დარეკვის შესაძლებლობა გადადით სერვისებზე net/rpc პირდაპირ PHP-დან. ეს მოგვიანებით ძალიან დაგვეხმარა განვითარებაში, რადგან ჩვენ მარტივად შეგვეძლო Go ბიბლიოთეკების ინტეგრირება PHP აპლიკაციებში. ამ სამუშაოს შედეგი ჩანს, მაგალითად, ჩვენს სხვა ღია კოდის პროდუქტში გორიჯი.

ამოცანების განაწილება რამდენიმე PHP მუშაკზე

ურთიერთქმედების მექანიზმის დანერგვის შემდეგ, დავიწყეთ ფიქრი იმაზე, თუ როგორ გადავიტანოთ ამოცანები ყველაზე ეფექტურად PHP პროცესებზე. როდესაც დავალება ჩამოდის, აპლიკაციის სერვერმა უნდა აირჩიოს თავისუფალი მუშაკი მის შესასრულებლად. თუ თანამშრომელი/პროცესი მთავრდება შეცდომით ან „მოკვდება“, ჩვენ ვაშორებთ მას და ვქმნით ახალს მის ჩასანაცვლებლად. და თუ თანამშრომელი/პროცესი წარმატებით დასრულდა, ჩვენ მას ვაბრუნებთ დავალებების შესასრულებლად ხელმისაწვდომ მუშაკთა ჯგუფს.

აქტიური მუშაკების აუზის შესანახად გამოვიყენეთ ბუფერული არხი, აუზიდან მოულოდნელად „მკვდარი“ მუშების ამოსაღებად, ჩვენ დავამატეთ შეცდომების და მუშათა მდგომარეობის თვალთვალის მექანიზმი.

შედეგად, ჩვენ მივიღეთ მოქმედი PHP სერვერი, რომელსაც შეუძლია დაამუშავოს ნებისმიერი მოთხოვნა წარმოდგენილი ორობითი ფორმით.

იმისათვის, რომ ჩვენმა აპლიკაციამ ფუნქციონირებდეს როგორც ვებ სერვერი, ჩვენ უნდა ავირჩიოთ სანდო PHP სტანდარტი, რომელიც წარმოადგენდა ნებისმიერ შემომავალ HTTP მოთხოვნას. ჩვენს შემთხვევაში ჩვენ უბრალოდ გარდაქმნას net/http მოთხოვნა გადადით ფორმატში PSR-7ასე რომ, ის თავსებადია დღეს არსებული PHP ფრეიმვერების უმეტესობასთან.

იმის გამო, რომ PSR-7 ითვლება შეუცვლელად (ზოგიერთი იტყვის, რომ ტექნიკურად ასე არ არის), დეველოპერებმა უნდა დაწერონ აპლიკაციები, რომლებიც ფუნდამენტურად არ განიხილავს მოთხოვნას, როგორც გლობალურ ერთეულს. ეს კარგად ჯდება ხანგრძლივი PHP პროცესების კონცეფციასთან. ჩვენი საბოლოო განხორციელება, რომელიც ჯერ არ იყო დასახელებული, ასე გამოიყურებოდა:

წარმოგიდგენთ RoadRunner-ს - მაღალი ხარისხის PHP აპლიკაციის სერვერი

ჩვენი პირველი სატესტო ამოცანა იყო API backend, რომელიც პერიოდულად განიცდიდა მოთხოვნის მოულოდნელ აფეთქებას (ჩვეულებრივზე ბევრად უფრო ხშირად). მიუხედავად იმისა, რომ nginx უმეტეს შემთხვევაში საკმარისი იყო, ჩვენ რეგულარულად ვხვდებოდით 502 შეცდომას, რადგან ვერ შევძელით სისტემის დაბალანსება საკმარისად სწრაფად დატვირთვის მოსალოდნელი ზრდისთვის.

ამ გადაწყვეტის ჩასანაცვლებლად, ჩვენ განვათავსეთ ჩვენი პირველი PHP/Go აპლიკაციის სერვერი 2018 წლის დასაწყისში. და მაშინვე მივიღეთ წარმოუდგენელი ეფექტი! ჩვენ არა მხოლოდ მთლიანად მოვიშორეთ 502 შეცდომა, არამედ შევძელით სერვერების რაოდენობის ორი მესამედით შემცირება, რაც დაზოგავს დიდ ფულს და თავის ტკივილს ინჟინრებისა და პროდუქტის მენეჯერებისთვის.

წლის შუა რიცხვებისთვის ჩვენ დავასრულეთ ჩვენი გადაწყვეტა, გამოვაქვეყნეთ იგი GitHub-ზე MIT ლიცენზიით და დავარქვათ ROADRUNNER, ამით ხაზს უსვამს მის წარმოუდგენელ სიჩქარეს და ეფექტურობას.

როგორ შეიძლება RoadRunner-მა გააუმჯობესოს თქვენი განვითარების სტეკი

განაცხადის ROADRUNNER მოგვცა საშუალება გამოგვეყენებინა Middleware net/http Go-ს მხარეს JWT ვერიფიკაციის შესასრულებლად, სანამ მოთხოვნა PHP-ს მოხვდება, ასევე WebSockets და გლობალური სახელმწიფოების აგრეგაცია Prometheus-ში.

ჩაშენებული RPC-ის წყალობით, თქვენ შეგიძლიათ გახსნათ ნებისმიერი Go ბიბლიოთეკის API PHP-სთვის გაფართოების შეფუთვის ჩაწერის გარეშე. რაც მთავარია, RoadRunner შეიძლება გამოყენებულ იქნას ახალი არა-HTTP სერვერების განსათავსებლად. მაგალითები მოიცავს PHP-ში დამმუშავებლების გაშვებას AWS ლამბდა, საიმედო რიგების დამსხვრევის შექმნა და დამატებაც კი gRPC ჩვენს აპლიკაციებზე.

PHP და Go საზოგადოებების დახმარებით, ჩვენ გავზარდეთ გადაწყვეტის სტაბილურობა, 40-ჯერ გავზარდეთ აპლიკაციის შესრულება ზოგიერთ ტესტში, გავაუმჯობესეთ გამართვის ხელსაწყოები, განვახორციელეთ ინტეგრაცია Symfony ფრეიმორიკთან და დავამატეთ მხარდაჭერა HTTPS, HTTP/. 2, დანამატები და PSR-17.

დასკვნა

ზოგიერთი ადამიანი კვლავ მოძველებულია PHP-ის, როგორც ნელი, შრომატევადი ენის, მხოლოდ WordPress დანამატების დასაწერად. ამ ადამიანებმა შეიძლება თქვან კიდეც, რომ PHP-ს აქვს შეზღუდვა: როდესაც აპლიკაცია საკმარისად დიდი ხდება, თქვენ უნდა აირჩიოთ უფრო „მომწიფებული“ ენა და გადაწეროთ მრავალი წლის განმავლობაში დაგროვილი კოდის ბაზა.

ამ ყველაფერზე მინდა ვუპასუხო: კიდევ ერთხელ დაფიქრდი. ჩვენ გვჯერა, რომ მხოლოდ თქვენ შეგიძლიათ დააყენოთ რაიმე შეზღუდვა PHP-სთვის. თქვენ შეგიძლიათ მთელი ცხოვრება გაატაროთ ერთი ენიდან მეორეზე გადახტომაში, ცდილობთ იპოვოთ სრულყოფილი შესატყვისი თქვენი საჭიროებისთვის, ან შეგიძლიათ დაიწყოთ ენებზე ფიქრი, როგორც ინსტრუმენტები. PHP-ის მსგავსი ენის აღქმული ნაკლოვანებები შეიძლება რეალურად იყოს მისი წარმატების მიზეზი. და თუ დააკავშირებთ მას სხვა ენასთან, როგორიცაა Go, შეგიძლიათ შექმნათ ბევრად უფრო ძლიერი პროდუქტები, ვიდრე მხოლოდ ერთი ენით შემოიფარგლებოდით.

Go-სა და PHP-ის კომბინაციასთან მუშაობისას, შეგვიძლია ვთქვათ, რომ გვიყვარს ისინი. ჩვენ არ ვგეგმავთ ერთის მსხვერპლად გაღებას მეორისთვის, არამედ ვეძებთ გზებს ამ ორმაგი დასტადან კიდევ უფრო მეტი ღირებულების მისაღებად.

UPD: მივესალმებით RoadRunner-ის შემქმნელს და ორიგინალური სტატიის თანაავტორს - ლაჩესისი

წყარო: www.habr.com