Cloudflare ປ່ຽນຈາກ NGINX ໄປຫາຕົວແທນຂອງຕົນເອງ Pingora, ຂຽນໃນ Rust

Cloudflare ປະກາດການຫັນປ່ຽນເຄືອຂ່າຍການຈັດສົ່ງເນື້ອຫາຂອງຕົນເພື່ອໃຊ້ Pingora proxy, ຂຽນໃນພາສາ Rust. ພຣັອກຊີໃໝ່ແທນການຕັ້ງຄ່າເຊີບເວີ NGINX ດ້ວຍສະຄຣິບ Lua, ແລະປະມວນຜົນຄຳຮ້ອງຂໍຫຼາຍກວ່າໜຶ່ງພັນຕື້ຄຳຂໍຕໍ່ມື້. ມັນໄດ້ຖືກສັງເກດເຫັນວ່າການຫັນໄປສູ່ຕົວແທນພິເສດທີ່ອະນຸຍາດໃຫ້ບໍ່ພຽງແຕ່ປະຕິບັດລັກສະນະໃຫມ່ແລະເພີ່ມຄວາມປອດໄພເນື່ອງຈາກການດໍາເນີນງານທີ່ປອດໄພຂອງຫນ່ວຍຄວາມຈໍາ, ແຕ່ຍັງນໍາໄປສູ່ການເພີ່ມປະສິດທິພາບແລະການປະຫຍັດຊັບພະຍາກອນຢ່າງຫຼວງຫຼາຍ - ການແກ້ໄຂທີ່ໃຊ້ Pingora ບໍ່ຈໍາເປັນຕ້ອງໃຊ້ ຂອງ Lua, ແລະເພາະສະນັ້ນການບໍລິໂພກຊັບພະຍາກອນຫນ້ອຍ 70% CPU ແລະ 67% ຫນ່ວຍຄວາມຈໍາຫນ້ອຍໃນຂະນະທີ່ປະມວນຜົນປະລິມານດຽວກັນຂອງການຈະລາຈອນ.

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

ແທນທີ່ຈະເປັນສະຖາປັດຕະຍະກໍາທີ່ແຍກຄໍາຮ້ອງຂໍເຂົ້າໄປໃນຂະບວນການຂອງພະນັກງານແຍກຕ່າງຫາກ, Pingora ໃຊ້ແບບຈໍາລອງຫຼາຍກະທູ້, ເຊິ່ງໃນກໍລະນີການນໍາໃຊ້ Cloudflare (ຄວາມເຂັ້ມຂົ້ນສູງຂອງການຈະລາຈອນຈາກສະຖານທີ່ຕ່າງໆທີ່ມີການປ່ຽນແປງທາງສະຖິຕິຂະຫນາດໃຫຍ່) ສະແດງໃຫ້ເຫັນການແຈກຢາຍຊັບພະຍາກອນທີ່ມີປະສິດທິພາບຫຼາຍຂຶ້ນລະຫວ່າງ CPU cores. ໂດຍສະເພາະ, ການຜູກມັດຂອງ nginx ຂອງຄໍາຮ້ອງຂໍທີ່ບໍ່ສົມດຸນກັບຂະບວນການເຮັດໃຫ້ການໂຫຼດທີ່ບໍ່ສົມດຸນໃນ CPU cores, ເຮັດໃຫ້ເກີດການຮ້ອງຂໍຊັບພະຍາກອນຫຼາຍແລະການຂັດຂວາງ I / O ຊ້າລົງການປະມວນຜົນການຮ້ອງຂໍອື່ນໆ. ນອກຈາກນັ້ນ, ການຜູກມັດສະນຸກເກີການເຊື່ອມຕໍ່ກັບຂະບວນການ handler ບໍ່ອະນຸຍາດໃຫ້ໃຊ້ຄືນໃຫມ່ຂອງການເຊື່ອມຕໍ່ທີ່ຕັ້ງແລ້ວຈາກຂະບວນການ handler ອື່ນໆ, ເຊິ່ງຫຼຸດລົງປະສິດທິພາບໃນເວລາທີ່ມີຂະບວນການ handler ຈໍານວນຫລາຍ.

NGINX:

Pingora:

ການປະຕິບັດຂອງ Pingora ເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະຫຼຸດຜ່ອນຈໍານວນການຕິດຕັ້ງຂອງການເຊື່ອມຕໍ່ໃຫມ່ 160 ເທື່ອແລະເພີ່ມສ່ວນແບ່ງການສອບຖາມທີ່ໃຊ້ຄືນໃຫມ່ຈາກ 87.1% ເປັນ 99.92%. ນອກເຫນືອຈາກການຫຼຸດຜ່ອນການເຊື່ອມຕໍ່ຄືນໃຫມ່ແລະການໃຊ້ CPU cores ທີ່ມີປະສິດທິພາບຫຼາຍຂຶ້ນ, ການປັບປຸງການປະຕິບັດຂອງຕົວແທນໃຫມ່ແມ່ນສ່ວນໃຫຍ່ແມ່ນຍ້ອນການກໍາຈັດຕົວຈັບ Lua ຊ້າທີ່ໃຊ້ກັບ nginx.

ພາສາ Rust ໄດ້ຖືກເລືອກເພື່ອໃຫ້ບັນລຸປະສິດທິພາບສູງບວກກັບຄວາມພ້ອມຂອງເຄື່ອງມືເພື່ອຮັບປະກັນການເຮັດວຽກທີ່ປອດໄພກັບຫນ່ວຍຄວາມຈໍາ. ມັນໄດ້ຖືກກ່າວເຖິງວ່າເຖິງວ່າຈະມີວິສະວະກອນທີ່ມີຄຸນວຸດທິສູງຂອງ Cloudflare ແລະທົບທວນລະຫັດທີ່ຂຽນໃນພາສາ C, ມັນກໍ່ບໍ່ສາມາດຫຼີກເວັ້ນຄວາມຜິດພາດທີ່ນໍາໄປສູ່ບັນຫາຄວາມຈໍາ (ຕົວຢ່າງ, ຊ່ອງຫວ່າງໃນ HTML parser). ສໍາລັບລະຫັດໃຫມ່, ມັນເວົ້າກ່ຽວກັບກໍລະນີຂອງການວິເຄາະຄວາມລົ້ມເຫລວໃນ Pingora, ເຊິ່ງໄດ້ສະແດງໃຫ້ເຫັນວ່າບໍ່ແມ່ນຍ້ອນບັນຫາໃນແອັບພລິເຄຊັນ, ແຕ່ຍ້ອນຄວາມຜິດພາດຂອງ Linux kernel ແລະຄວາມລົ້ມເຫຼວຂອງຮາດແວ.

ນອກຈາກນັ້ນ, ພວກເຮົາສາມາດສັງເກດເຫັນຄໍາຄິດເຫັນຂອງ Linus Torvalds ທີ່ໄດ້ກ່າວມາໃນກອງປະຊຸມ Open-Source Summit Europe ທີ່ຈັດຂຶ້ນໃນມື້ນີ້, ກ່ຽວກັບການລວມເອົາການສະຫນັບສະຫນູນພາສາ Rust ໃນ Linux kernel. Patches ສໍາລັບການພັດທະນາໄດເວີອຸປະກອນໃນພາສາ Rust ບໍ່ໄດ້ຖືກລວມຢູ່ໃນ 6.0 kernel, ແຕ່ອີງຕາມ Linus, ສ່ວນຫຼາຍອາດຈະຖືກຍອມຮັບເຂົ້າໃນ 6.1 kernel; ລາວຈະບໍ່ຊັກຊ້າການເຊື່ອມໂຍງ. ເປັນແຮງຈູງໃຈສໍາລັບການເພີ່ມການສະຫນັບສະຫນູນ Rust, ນອກເຫນືອຈາກຜົນກະທົບທາງບວກຕໍ່ຄວາມປອດໄພ, Linus ຍັງອ້າງເຖິງໂອກາດທີ່ຈະເພີ່ມຄວາມສົນໃຈໃນການເຮັດວຽກໃນຫຼັກຂອງຜູ້ເຂົ້າຮ່ວມໃຫມ່, ເຊິ່ງເປັນສິ່ງສໍາຄັນໃນສະພາບການຂອງອາຍຸເກົ່າແກ່.

ແຫຼ່ງຂໍ້ມູນ: opennet.ru