RoadRunner: PHP ບໍ່ໄດ້ຖືກສ້າງຂຶ້ນເພື່ອຕາຍ, ຫຼື Golang ເພື່ອກູ້ໄພ

Hey Habr! ພວກເຮົາເຄື່ອນໄຫວຢູ່ Badoo ເຮັດວຽກກ່ຽວກັບການປະຕິບັດ PHP, ເນື່ອງຈາກພວກເຮົາມີລະບົບຂະຫນາດໃຫຍ່ພໍສົມຄວນໃນພາສານີ້ແລະບັນຫາການປະຕິບັດແມ່ນບັນຫາການປະຫຍັດເງິນ. ຫຼາຍກວ່າສິບປີກ່ອນຫນ້ານີ້, ພວກເຮົາໄດ້ສ້າງ PHP-FPM ສໍາລັບການນີ້, ເຊິ່ງໃນຕອນທໍາອິດແມ່ນຊຸດຂອງ patches ສໍາລັບ PHP, ແລະຕໍ່ມາໄດ້ເຂົ້າໄປໃນການແຈກຢາຍຢ່າງເປັນທາງການ.

ໃນຊຸມປີມໍ່ໆມານີ້, PHP ມີຄວາມກ້າວຫນ້າຢ່າງຫຼວງຫຼາຍ: ຜູ້ເກັບຂີ້ເຫຍື້ອໄດ້ປັບປຸງ, ລະດັບຄວາມຫມັ້ນຄົງໄດ້ເພີ່ມຂຶ້ນ - ມື້ນີ້ທ່ານສາມາດຂຽນ daemon ແລະ scripts ຍາວໃນ PHP ໂດຍບໍ່ມີບັນຫາໃດໆ. ນີ້ອະນຸຍາດໃຫ້ Spiral Scout ໄປຕື່ມອີກ: RoadRunner, ບໍ່ເຫມືອນກັບ PHP-FPM, ບໍ່ໄດ້ເຮັດຄວາມສະອາດຫນ່ວຍຄວາມຈໍາລະຫວ່າງຄໍາຮ້ອງຂໍ, ເຊິ່ງເຮັດໃຫ້ການເພີ່ມປະສິດທິພາບເພີ່ມເຕີມ (ເຖິງແມ່ນວ່າວິທີການນີ້ເຮັດໃຫ້ຂະບວນການພັດທະນາສັບສົນ). ພວກເຮົາກຳລັງທົດລອງໃຊ້ເຄື່ອງມືນີ້ຢູ່, ແຕ່ພວກເຮົາຍັງບໍ່ມີຜົນທີ່ຈະແບ່ງປັນເທື່ອ. ເພື່ອເຮັດໃຫ້ການລໍຖ້າພວກເຂົາມ່ວນຫຼາຍ, ພວກເຮົາເຜີຍແຜ່ການແປຂອງການປະກາດ RoadRunner ຈາກ Spiral Scout.

ວິທີການຈາກບົດຄວາມແມ່ນໃກ້ຊິດກັບພວກເຮົາ: ໃນເວລາທີ່ແກ້ໄຂບັນຫາຂອງພວກເຮົາ, ພວກເຮົາສ່ວນຫຼາຍມັກຈະໃຊ້ PHP ແລະ Go, ໄດ້ຮັບຜົນປະໂຫຍດຂອງທັງສອງພາສາແລະບໍ່ປະຖິ້ມຫນຶ່ງໃນເງື່ອນໄຂຂອງຄົນອື່ນ.

ມີຄວາມສຸກ!

ໃນສິບປີທີ່ຜ່ານມາ, ພວກເຮົາໄດ້ສ້າງຄໍາຮ້ອງສະຫມັກສໍາລັບບໍລິສັດຈາກບັນຊີລາຍຊື່ Fortune 500, ແລະສໍາລັບທຸລະກິດທີ່ມີຜູ້ຊົມບໍ່ເກີນ 500 ຜູ້ໃຊ້. ຕະຫຼອດເວລານີ້, ວິສະວະກອນຂອງພວກເຮົາໄດ້ພັດທະນາ backend ສ່ວນໃຫຍ່ໃນ PHP. ແຕ່ສອງປີກ່ອນຫນ້ານີ້, ບາງສິ່ງບາງຢ່າງມີຜົນກະທົບອັນໃຫຍ່ຫຼວງບໍ່ພຽງແຕ່ໃນການປະຕິບັດຂອງຜະລິດຕະພັນຂອງພວກເຮົາ, ແຕ່ຍັງກ່ຽວກັບການຂະຫຍາຍຂອງພວກເຂົາ - ພວກເຮົາໄດ້ນໍາສະເຫນີ Golang (Go) ເຂົ້າໄປໃນ stack ເຕັກໂນໂລຢີຂອງພວກເຮົາ.

ເກືອບທັນທີ, ພວກເຮົາຄົ້ນພົບວ່າ Go ໄດ້ອະນຸຍາດໃຫ້ພວກເຮົາສ້າງແອັບພລິເຄຊັນໃຫຍ່ຂຶ້ນດ້ວຍການປັບປຸງປະສິດທິພາບສູງສຸດ 40x. ດ້ວຍມັນ, ພວກເຮົາສາມາດຂະຫຍາຍຜະລິດຕະພັນທີ່ມີຢູ່ແລ້ວທີ່ຂຽນໃນ 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, ແລະອື່ນໆ).

ລັດບໍ່ສາມາດປ່ຽນແປງໃນລະຫວ່າງການປະຕິບັດ script PHP, ດັ່ງນັ້ນວິທີດຽວທີ່ຈະໄດ້ຮັບຊຸດຂໍ້ມູນການປ້ອນຂໍ້ມູນໃຫມ່ແມ່ນໂດຍການລ້າງຫນ່ວຍຄວາມຈໍາຂະບວນການແລະເລີ່ມຕົ້ນມັນອີກເທື່ອຫນຶ່ງ.

ຮູບແບບການປະຕິບັດນີ້ມີຂໍ້ດີຫຼາຍ. ທ່ານບໍ່ຈໍາເປັນຕ້ອງກັງວົນຫຼາຍເກີນໄປກ່ຽວກັບການບໍລິໂພກຫນ່ວຍຄວາມຈໍາ, ຂະບວນການທັງຫມົດແມ່ນຢູ່ໂດດດ່ຽວຫມົດ, ແລະຖ້າຫນຶ່ງໃນພວກມັນ "ຕາຍ", ມັນຈະຖືກສ້າງໃຫມ່ໂດຍອັດຕະໂນມັດແລະມັນຈະບໍ່ມີຜົນກະທົບຕໍ່ສ່ວນທີ່ເຫຼືອຂອງຂະບວນການ. ແຕ່ວິທີການນີ້ຍັງມີຂໍ້ເສຍທີ່ປາກົດໃນເວລາທີ່ພະຍາຍາມຂະຫນາດຄໍາຮ້ອງສະຫມັກ.

ຂໍ້ເສຍແລະຄວາມບໍ່ມີປະສິດທິພາບຂອງສະພາບແວດລ້ອມ PHP ປົກກະຕິ

ຖ້າທ່ານເປັນນັກພັດທະນາ PHP ມືອາຊີບ, ຫຼັງຈາກນັ້ນທ່ານຮູ້ບ່ອນທີ່ຈະເລີ່ມຕົ້ນໂຄງການໃຫມ່ - ດ້ວຍທາງເລືອກຂອງກອບ. ມັນປະກອບດ້ວຍຫ້ອງສະຫມຸດສີດການເພິ່ງພາອາໄສ, ORMs, ການແປແລະແມ່ແບບ. ແລະ, ແນ່ນອນ, ຂໍ້ມູນຜູ້ໃຊ້ທັງຫມົດສາມາດຖືກໃສ່ເຂົ້າໄປໃນວັດຖຸດຽວ (Symfony/HttpFoundation ຫຼື PSR-7). ກອບແມ່ນເຢັນ!

ແຕ່ທຸກສິ່ງທຸກຢ່າງມີລາຄາຂອງມັນ. ໃນກອບລະດັບວິສາຫະກິດໃດກໍ່ຕາມ, ເພື່ອປະມວນຜົນຄໍາຮ້ອງຂໍຂອງຜູ້ໃຊ້ແບບງ່າຍດາຍຫຼືການເຂົ້າເຖິງຖານຂໍ້ມູນ, ທ່ານຈະຕ້ອງໂຫລດໄຟລ໌ຢ່າງຫນ້ອຍຫຼາຍສິບໄຟລ໌, ສ້າງຊັ້ນຮຽນຈໍານວນຫລາຍແລະວິເຄາະການຕັ້ງຄ່າຫຼາຍ. ແຕ່ສິ່ງທີ່ຮ້າຍແຮງທີ່ສຸດແມ່ນວ່າຫຼັງຈາກສໍາເລັດແຕ່ລະຫນ້າວຽກ, ທ່ານຈະຕ້ອງຕັ້ງທຸກສິ່ງທຸກຢ່າງໃຫມ່ແລະເລີ່ມຕົ້ນໃຫມ່: ລະຫັດທັງຫມົດທີ່ເຈົ້າຫາກໍ່ເລີ່ມກາຍເປັນບໍ່ມີປະໂຫຍດ, ດ້ວຍການຊ່ວຍເຫຼືອຂອງມັນທ່ານຈະບໍ່ດໍາເນີນການຮ້ອງຂໍອີກ. ບອກເລື່ອງນີ້ກັບນັກຂຽນໂປລແກລມທີ່ຂຽນເປັນພາສາອື່ນ, ແລະເຈົ້າຈະເຫັນຄວາມປະຫລາດໃຈໃນໃບຫນ້າຂອງລາວ.

ວິສະວະກອນ PHP ໄດ້ຊອກຫາວິທີແກ້ໄຂບັນຫານີ້ມາເປັນເວລາຫຼາຍປີແລ້ວ, ໂດຍນໍາໃຊ້ເຕັກນິກການໂຫຼດຂີ້ກຽດທີ່ສະຫລາດ, microframeworks, ຫໍສະຫມຸດທີ່ດີທີ່ສຸດ, cache, ແລະອື່ນໆ. ແຕ່ໃນທີ່ສຸດ, ທ່ານຍັງຕ້ອງປັບຄໍາຮ້ອງສະຫມັກທັງຫມົດແລະເລີ່ມຕົ້ນໃຫມ່, ອີກເທື່ອຫນຶ່ງແລະອີກຄັ້ງ. (ຫມາຍເຫດຂອງຜູ້ແປ: ບັນຫານີ້ຈະຖືກແກ້ໄຂບາງສ່ວນກັບການມາຮອດຂອງ ໂຫລດ ໃນ PHP 7.4)

PHP ກັບ Go ສາມາດຢູ່ລອດຫຼາຍກວ່າຫນຶ່ງຄໍາຮ້ອງຂໍບໍ?

ມັນເປັນໄປໄດ້ທີ່ຈະຂຽນສະຄິບ PHP ທີ່ມີຊີວິດຍາວກວ່າສອງສາມນາທີ (ເຖິງຊົ່ວໂມງຫຼືຫຼາຍມື້): ຕົວຢ່າງ, cron tasks, CSV parser, queue breakers. ພວກເຂົາທັງຫມົດເຮັດວຽກຕາມສະຖານະການດຽວກັນ: ພວກເຂົາດຶງເອົາຫນ້າວຽກ, ປະຕິບັດມັນ, ແລະລໍຖ້າຕໍ່ໄປ. ລະຫັດຢູ່ໃນຫນ່ວຍຄວາມຈໍາຕະຫຼອດເວລາ, ຊ່ວຍປະຢັດ milliseconds ທີ່ມີຄ່າຍ້ອນວ່າມີຫຼາຍຂັ້ນຕອນເພີ່ມເຕີມທີ່ຕ້ອງການເພື່ອໂຫລດກອບແລະຄໍາຮ້ອງສະຫມັກ.

ແຕ່ການພັດທະນາສະຄິບທີ່ມີອາຍຸຍາວນານບໍ່ແມ່ນເລື່ອງງ່າຍ. ຄວາມ​ຜິດ​ພາດ​ໃດ​ນຶ່ງ​ຂ້າ​ຂະ​ບວນ​ການ​ຢ່າງ​ສິ້ນ​ເຊີງ, ການ​ວິ​ນິດ​ໄສ​ການ​ຮົ່ວ​ໄຫລ​ຂອງ​ຫນ່ວຍ​ຄວາມ​ຈໍາ​ແມ່ນ infuriating, ແລະ F5 debugging ບໍ່​ເປັນ​ໄປ​ໄດ້​ອີກ​ແລ້ວ.

ສະຖານະການໄດ້ປັບປຸງດ້ວຍການປ່ອຍ PHP 7: ຕົວເກັບຂີ້ເຫຍື້ອທີ່ຫນ້າເຊື່ອຖືໄດ້ປາກົດຂຶ້ນ, ມັນໄດ້ກາຍເປັນງ່າຍຕໍ່ການຈັດການກັບຄວາມຜິດພາດ, ແລະການຂະຫຍາຍແກ່ນຂອງແກ່ນແມ່ນປະຈຸບັນຮົ່ວໄຫຼ. ແທ້ຈິງແລ້ວ, ວິສະວະກອນຍັງຕ້ອງລະມັດລະວັງກັບຄວາມຊົງຈໍາແລະຮູ້ເຖິງບັນຫາຂອງລັດໃນລະຫັດ (ມີພາສາທີ່ສາມາດລະເລີຍສິ່ງເຫຼົ່ານີ້ບໍ?). ຢ່າງໃດກໍຕາມ, PHP 7 ມີຄວາມແປກໃຈຫນ້ອຍໃນຮ້ານສໍາລັບພວກເຮົາ.

ມັນເປັນໄປໄດ້ທີ່ຈະເອົາຮູບແບບຂອງການເຮັດວຽກກັບສະຄິບ PHP ທີ່ມີຊີວິດຊີວາ, ປັບມັນໃຫ້ເຫມາະສົມກັບວຽກງານເລັກນ້ອຍເຊັ່ນການປຸງແຕ່ງຄໍາຮ້ອງຂໍ HTTP, ແລະດັ່ງນັ້ນຈຶ່ງກໍາຈັດຄວາມຕ້ອງການທີ່ຈະໂຫລດທຸກຢ່າງຈາກຈຸດເລີ່ມຕົ້ນດ້ວຍແຕ່ລະຄໍາຮ້ອງຂໍ?

ເພື່ອແກ້ໄຂບັນຫານີ້, ທໍາອິດພວກເຮົາຈໍາເປັນຕ້ອງປະຕິບັດຄໍາຮ້ອງສະຫມັກເຊີຟເວີທີ່ສາມາດຍອມຮັບການຮ້ອງຂໍ HTTP ແລະປ່ຽນເສັ້ນທາງຫນຶ່ງໂດຍຫນຶ່ງໄປຫາພະນັກງານ PHP ໂດຍບໍ່ມີການຂ້າມັນທຸກຄັ້ງ.

ພວກເຮົາຮູ້ວ່າພວກເຮົາສາມາດຂຽນເວັບເຊີຟເວີໃນ PHP ບໍລິສຸດ (PHP-PM) ຫຼືໃຊ້ນາມສະກຸນ C (Swoole). ແລະເຖິງແມ່ນວ່າແຕ່ລະວິທີມີຄວາມດີຂອງຕົນເອງ, ທັງສອງທາງເລືອກບໍ່ເຫມາະສົມກັບພວກເຮົາ - ພວກເຮົາຕ້ອງການບາງສິ່ງບາງຢ່າງຫຼາຍ. ພວກເຮົາຕ້ອງການຫຼາຍກ່ວາພຽງແຕ່ເຄື່ອງແມ່ຂ່າຍເວັບໄຊຕ໌ - ພວກເຮົາຄາດວ່າຈະໄດ້ຮັບການແກ້ໄຂທີ່ສາມາດຊ່ວຍປະຢັດພວກເຮົາຈາກບັນຫາທີ່ກ່ຽວຂ້ອງກັບ "ການເລີ່ມຕົ້ນຍາກ" ໃນ PHP, ເຊິ່ງໃນເວລາດຽວກັນສາມາດດັດແປງໄດ້ງ່າຍແລະຂະຫຍາຍສໍາລັບຄໍາຮ້ອງສະຫມັກສະເພາະ. ນັ້ນແມ່ນ, ພວກເຮົາຕ້ອງການເຄື່ອງແມ່ຂ່າຍຂອງແອັບພລິເຄຊັນ.

Go ຊ່ວຍໃນເລື່ອງນີ້ໄດ້ບໍ? ພວກເຮົາຮູ້ວ່າມັນສາມາດເຮັດໄດ້ເພາະວ່າພາສາລວບລວມຄໍາຮ້ອງສະຫມັກເຂົ້າໄປໃນຖານສອງດຽວ; ມັນເປັນຂ້າມເວທີ; ໃຊ້ຕົວແບບການປຸງແຕ່ງຂະຫນານຂອງຕົນເອງ, ສະຫງ່າງາມຫຼາຍ (ກົງກັນ) ແລະຫ້ອງສະຫມຸດສໍາລັບການເຮັດວຽກກັບ HTTP; ແລະສຸດທ້າຍ, ຫຼາຍພັນຫ້ອງສະຫມຸດ open-source ແລະການເຊື່ອມໂຍງຈະມີໃຫ້ພວກເຮົາ.

ຄວາມຫຍຸ້ງຍາກໃນການລວມສອງພາສາການຂຽນໂປຼແກຼມ

ກ່ອນອື່ນ ໝົດ, ມັນ ຈຳ ເປັນຕ້ອງ ກຳ ນົດວ່າແອັບພລິເຄຊັນສອງຫຼືຫຼາຍກວ່ານັ້ນຈະຕິດຕໍ່ສື່ສານກັນແນວໃດ.

ສໍາລັບຕົວຢ່າງ, ການນໍາໃຊ້ ຫ້ອງສະຫມຸດທີ່ດີເລີດ Alex Palaestras, ມັນເປັນໄປໄດ້ທີ່ຈະແບ່ງປັນຄວາມຊົງຈໍາລະຫວ່າງຂະບວນການ PHP ແລະ Go (ຄ້າຍຄືກັນກັບ mod_php ໃນ Apache). ແຕ່ຫ້ອງສະຫມຸດນີ້ມີຄຸນສົມບັດທີ່ຈໍາກັດການນໍາໃຊ້ຂອງມັນສໍາລັບການແກ້ໄຂບັນຫາຂອງພວກເຮົາ.

ພວກເຮົາໄດ້ຕັດສິນໃຈທີ່ຈະນໍາໃຊ້ວິທີການທີ່ແຕກຕ່າງກັນ, ທົ່ວໄປກວ່າ: ເພື່ອສ້າງການພົວພັນລະຫວ່າງຂະບວນການຜ່ານຊັອກເກັດ / ທໍ່. ວິທີການນີ້ໄດ້ພິສູດວ່າມີຄວາມຫນ້າເຊື່ອຖືໃນທົດສະວັດທີ່ຜ່ານມາແລະໄດ້ຮັບການເພີ່ມປະສິດທິພາບດີໃນລະດັບລະບົບປະຕິບັດການ.

ເພື່ອເລີ່ມຕົ້ນດ້ວຍ, ພວກເຮົາໄດ້ສ້າງໂປໂຕຄອນ binary ງ່າຍດາຍສໍາລັບການແລກປ່ຽນຂໍ້ມູນລະຫວ່າງຂະບວນການແລະການຈັດການຄວາມຜິດພາດການສົ່ງຕໍ່. ໃນຮູບແບບທີ່ງ່າຍດາຍທີ່ສຸດ, ປະເພດຂອງໂປໂຕຄອນນີ້ແມ່ນຄ້າຍຄືກັນກັບ netstring с ສ່ວນຫົວຊຸດຂະໜາດຄົງທີ່ (ໃນກໍລະນີຂອງພວກເຮົາ 17 bytes), ເຊິ່ງປະກອບດ້ວຍຂໍ້ມູນກ່ຽວກັບປະເພດຂອງແພັກເກັດ, ຂະຫນາດຂອງມັນແລະຫນ້າກາກຄູ່ເພື່ອກວດເບິ່ງຄວາມສົມບູນຂອງຂໍ້ມູນ.

ໃນດ້ານ PHP ພວກເຮົາໃຊ້ ການທໍາງານຂອງຊອງ, ແລະຢູ່ຂ້າງ Go, ຫໍສະຫມຸດ ການເຂົ້າລະຫັດ/binary.

ມັນເບິ່ງຄືວ່າພວກເຮົາວ່າພິທີການຫນຶ່ງບໍ່ພຽງພໍ - ແລະພວກເຮົາໄດ້ເພີ່ມຄວາມສາມາດໃນການໂທຫາ net/rpc ໄປບໍລິການໂດຍກົງຈາກ PHP. ຕໍ່ມາ, ນີ້ຊ່ວຍພວກເຮົາຫຼາຍໃນການພັດທະນາ, ເພາະວ່າພວກເຮົາສາມາດປະສົມປະສານ Go libraries ເຂົ້າໄປໃນຄໍາຮ້ອງສະຫມັກ PHP ໄດ້ຢ່າງງ່າຍດາຍ. ຜົນໄດ້ຮັບຂອງການເຮັດວຽກນີ້ສາມາດເຫັນໄດ້, ຕົວຢ່າງ, ໃນຜະລິດຕະພັນແຫຼ່ງເປີດອື່ນໆຂອງພວກເຮົາ Goridge.

ການແຈກຢາຍວຽກງານໃນທົ່ວພະນັກງານ PHP ຫຼາຍ

ຫຼັງຈາກການປະຕິບັດກົນໄກການໂຕ້ຕອບ, ພວກເຮົາເລີ່ມຄິດກ່ຽວກັບວິທີທີ່ມີປະສິດທິພາບທີ່ສຸດໃນການໂອນຫນ້າວຽກກັບຂະບວນການ PHP. ເມື່ອວຽກງານມາຮອດ, ເຄື່ອງແມ່ຂ່າຍຂອງແອັບພລິເຄຊັນຕ້ອງເລືອກພະນັກງານທີ່ບໍ່ເສຍຄ່າເພື່ອປະຕິບັດມັນ. ຖ້າຜູ້ອອກແຮງງານ / ຂະບວນການອອກດ້ວຍຄວາມຜິດພາດຫຼື "ຕາຍ", ພວກເຮົາກໍາຈັດມັນແລະສ້າງໃຫມ່ເພື່ອທົດແທນມັນ. ແລະຖ້າຜູ້ອອກແຮງງານ / ຂະບວນການສໍາເລັດຜົນ, ພວກເຮົາສົ່ງຄືນໃຫ້ຜູ້ອອກແຮງງານທີ່ມີເພື່ອປະຕິບັດວຽກງານ.

ເພື່ອເກັບຮັກສາສະນຸກເກີຂອງພະນັກງານທີ່ມີການເຄື່ອນໄຫວ, ພວກເຮົາໄດ້ນໍາໃຊ້ ຊ່ອງ buffed, ເພື່ອເອົາຄົນງານ "ຕາຍ" ທີ່ບໍ່ຄາດຄິດອອກຈາກສະນຸກເກີ, ພວກເຮົາໄດ້ເພີ່ມກົນໄກການຕິດຕາມຄວາມຜິດພາດແລະສະຖານະຂອງພະນັກງານ.

ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ຮັບເຄື່ອງແມ່ຂ່າຍ PHP ທີ່ເຮັດວຽກທີ່ມີຄວາມສາມາດໃນການປຸງແຕ່ງຄໍາຮ້ອງຂໍໃດໆທີ່ນໍາສະເຫນີໃນຮູບແບບຄູ່.

ເພື່ອໃຫ້ແອັບພລິເຄຊັນຂອງພວກເຮົາເລີ່ມເຮັດວຽກເປັນເວັບເຊີບເວີ, ພວກເຮົາຕ້ອງເລືອກມາດຕະຖານ PHP ທີ່ເຊື່ອຖືໄດ້ເພື່ອເປັນຕົວແທນຂອງຄໍາຮ້ອງຂໍ HTTP ທີ່ເຂົ້າມາ. ໃນກໍລະນີຂອງພວກເຮົາ, ພວກເຮົາພຽງແຕ່ ຫັນປ່ຽນ net/http ຮ້ອງຂໍຈາກ Go to format PSR-7ເພື່ອໃຫ້ມັນເຂົ້າກັນໄດ້ກັບກອບ PHP ສ່ວນໃຫຍ່ທີ່ມີຢູ່ໃນມື້ນີ້.

ເນື່ອງຈາກວ່າ PSR-7 ຖືກພິຈາລະນາວ່າບໍ່ສາມາດປ່ຽນແປງໄດ້ (ບາງຄົນຈະເວົ້າວ່າມັນບໍ່ແມ່ນທາງດ້ານເຕັກນິກ), ນັກພັດທະນາຕ້ອງຂຽນຄໍາຮ້ອງສະຫມັກທີ່ບໍ່ປະຕິບັດຕໍ່ຄໍາຮ້ອງຂໍເປັນຫນ່ວຍງານທົ່ວໂລກໃນຫຼັກການ. ນີ້ເຫມາະສົມກັບແນວຄວາມຄິດຂອງຂະບວນການ PHP ທີ່ມີອາຍຸຍາວນານ. ການປະຕິບັດສຸດທ້າຍຂອງພວກເຮົາ, ເຊິ່ງຍັງບໍ່ທັນມີຊື່, ເບິ່ງຄືວ່າ:

ແນະນຳ RoadRunner - ເຄື່ອງແມ່ຂ່າຍຄໍາຮ້ອງສະຫມັກ PHP ທີ່ມີປະສິດທິພາບສູງ

ວຽກງານການທົດສອບຄັ້ງທໍາອິດຂອງພວກເຮົາແມ່ນ API backend, ເຊິ່ງແຕ່ລະໄລຍະບໍ່ແນ່ນອນ (ຫຼາຍເທື່ອຫຼາຍກ່ວາປົກກະຕິ). ເຖິງແມ່ນວ່າ nginx ແມ່ນພຽງພໍໃນກໍລະນີຫຼາຍທີ່ສຸດ, ພວກເຮົາພົບຂໍ້ຜິດພາດ 502 ຢ່າງເປັນປົກກະຕິເພາະວ່າພວກເຮົາບໍ່ສາມາດດຸ່ນດ່ຽງລະບົບໄດ້ໄວພໍສໍາລັບການເພີ່ມຂຶ້ນທີ່ຄາດວ່າຈະມີໂຫຼດ.

ເພື່ອທົດແທນການແກ້ໄຂນີ້, ພວກເຮົາໄດ້ນຳໃຊ້ເຄື່ອງແມ່ຂ່າຍແອັບພລິເຄຊັນ PHP/Go ທຳອິດຂອງພວກເຮົາໃນຕົ້ນປີ 2018. ແລະທັນທີໄດ້ຮັບຜົນກະທົບ incredible! ບໍ່ພຽງແຕ່ພວກເຮົາກໍາຈັດຄວາມຜິດພາດ 502 ຢ່າງສົມບູນ, ແຕ່ພວກເຮົາສາມາດຫຼຸດຜ່ອນຈໍານວນເຄື່ອງແມ່ຂ່າຍສອງສ່ວນສາມ, ປະຫຍັດເງິນຫຼາຍແລະຢາແກ້ປວດຫົວສໍາລັບວິສະວະກອນແລະຜູ້ຈັດການຜະລິດຕະພັນ.

ໃນກາງປີ, ພວກເຮົາໄດ້ປັບປຸງການແກ້ໄຂຂອງພວກເຮົາ, ຈັດພີມມາມັນຢູ່ໃນ GitHub ພາຍໃຕ້ໃບອະນຸຍາດ MIT ແລະຕັ້ງຊື່ມັນ. ຖະ ໜົນ Runner, ດັ່ງນັ້ນຈຶ່ງເນັ້ນຫນັກໃສ່ຄວາມໄວ incredible ແລະປະສິດທິພາບຂອງຕົນ.

RoadRunner ສາມາດປັບປຸງການພັດທະນາ stack ຂອງທ່ານໄດ້ແນວໃດ

ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ ຖະ ໜົນ Runner ອະນຸຍາດໃຫ້ພວກເຮົາໃຊ້ Middleware net/http ໃນດ້ານ Go ເພື່ອດໍາເນີນການກວດສອບ JWT ກ່ອນທີ່ຄໍາຮ້ອງຂໍໄປຮອດ PHP, ເຊັ່ນດຽວກັນກັບການຈັດການ WebSockets ແລະລວມລັດທົ່ວໂລກໃນ Prometheus.

ຂໍຂອບໃຈກັບ RPC ທີ່ມີການກໍ່ສ້າງ, ທ່ານສາມາດເປີດ API ຂອງຫ້ອງສະຫມຸດ Go ໃດສໍາລັບ PHP ໂດຍບໍ່ມີການຂຽນ wrappers. ສິ່ງທີ່ ສຳ ຄັນກວ່ານັ້ນ, ດ້ວຍ RoadRunner ທ່ານສາມາດ ນຳ ໃຊ້ເຄື່ອງແມ່ຂ່າຍທີ່ບໍ່ແມ່ນ HTTP ໃໝ່. ຕົວຢ່າງປະກອບມີຕົວຈັດການແລ່ນໃນ PHP AWS Lambda, ການສ້າງ breakers ແຖວທີ່ເຊື່ອຖືໄດ້, ແລະແມ້ກະທັ້ງການເພີ່ມ ກ. ພ. ພ ກັບຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາ.

ດ້ວຍຄວາມຊ່ອຍເຫລືອຂອງຊຸມຊົນ PHP ແລະ Go, ພວກເຮົາປັບປຸງຄວາມຫມັ້ນຄົງຂອງການແກ້ໄຂ, ເພີ່ມປະສິດທິພາບຂອງແອັບພລິເຄຊັນເຖິງ 40 ເທົ່າໃນບາງການທົດສອບ, ປັບປຸງເຄື່ອງມືແກ້ໄຂ, ປະຕິບັດການເຊື່ອມໂຍງກັບ Symfony framework, ແລະເພີ່ມການສະຫນັບສະຫນູນ HTTPS, HTTP/2, ປລັກອິນ, ແລະ PSR-17.

ສະຫລຸບ

ບາງຄົນຍັງຖືກຈັບຢູ່ໃນແນວຄິດທີ່ລ້າສະໄຫມຂອງ PHP ເປັນພາສາທີ່ຊ້າ, ບໍ່ຄ່ອຍດີພຽງແຕ່ສໍາລັບການຂຽນ plugins ສໍາລັບ WordPress. ຄົນເຫຼົ່ານີ້ອາດຈະເວົ້າວ່າ PHP ມີຂໍ້ຈໍາກັດດັ່ງກ່າວ: ເມື່ອແອັບພລິເຄຊັນໃຫຍ່ພຽງພໍ, ທ່ານຕ້ອງເລືອກພາສາທີ່ "ແກ່" ຫຼາຍຂຶ້ນແລະຂຽນຄືນພື້ນຖານລະຫັດທີ່ສະສົມມາຫຼາຍປີ.

ທັງຫມົດນີ້ຂ້າພະເຈົ້າຕ້ອງການທີ່ຈະຕອບ: ຄິດອີກເທື່ອຫນຶ່ງ. ພວກເຮົາເຊື່ອວ່າພຽງແຕ່ທ່ານກໍານົດຂໍ້ຈໍາກັດໃດໆສໍາລັບ PHP. ທ່ານ​ສາ​ມາດ​ໃຊ້​ເວ​ລາ​ທັງ​ຫມົດ​ຂອງ​ທ່ານ​ຫັນ​ປ່ຽນ​ຈາກ​ພາ​ສາ​ຫນຶ່ງ​ໄປ​ອີກ​ປະ​ການ​ຫນຶ່ງ​, ພະ​ຍາ​ຍາມ​ເພື່ອ​ຊອກ​ຫາ​ທີ່​ສົມ​ບູນ​ແບບ​ສໍາ​ລັບ​ຄວາມ​ຕ້ອງ​ການ​ຂອງ​ທ່ານ​, ຫຼື​ທ່ານ​ສາ​ມາດ​ເລີ່ມ​ຕົ້ນ​ທີ່​ຈະ​ຄິດ​ວ່າ​ພາ​ສາ​ເປັນ​ເຄື່ອງ​ມື​. ຂໍ້ບົກພ່ອງຂອງພາສາເຊັ່ນ PHP ອາດຈະເປັນເຫດຜົນສໍາລັບຄວາມສໍາເລັດຂອງມັນ. ແລະຖ້າທ່ານລວມມັນກັບພາສາອື່ນເຊັ່ນ Go, ຫຼັງຈາກນັ້ນທ່ານຈະສ້າງຜະລິດຕະພັນທີ່ມີປະສິດທິພາບຫຼາຍກ່ວາຖ້າທ່ານຖືກຈໍາກັດການໃຊ້ພາສາດຽວ.

ໂດຍໄດ້ເຮັດວຽກກັບກຸ່ມ Go ແລະ PHP, ພວກເຮົາສາມາດເວົ້າວ່າພວກເຮົາຮັກພວກເຂົາ. ພວກເຮົາບໍ່ໄດ້ວາງແຜນທີ່ຈະເສຍສະລະຫນຶ່ງສໍາລັບຄົນອື່ນ - ໃນທາງກົງກັນຂ້າມ, ພວກເຮົາຈະຊອກຫາວິທີທີ່ຈະໄດ້ຮັບມູນຄ່າຫຼາຍກວ່ານີ້ຈາກ stack ຄູ່ນີ້.

UPD: ພວກເຮົາຍິນດີຕ້ອນຮັບຜູ້ສ້າງ RoadRunner ແລະຜູ້ຂຽນຮ່ວມກັນຂອງບົດຄວາມຕົ້ນສະບັບ - Lachesis

ແຫຼ່ງຂໍ້ມູນ: www.habr.com