ການແປບົດຄວາມ: ຮູບແບບການໃສ່ກະທູ້ Envoy - https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310

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

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

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

ພາບລວມຂອງກະທູ້

Envoy ໃຊ້ສາມປະເພດທີ່ແຕກຕ່າງກັນຂອງສາຍນ້ໍາ:

• ຫຼັກ: ກະທູ້ນີ້ຄວບຄຸມການເລີ່ມຕົ້ນຂະບວນການແລະການຢຸດເຊົາ, ການປຸງແຕ່ງທັງຫມົດຂອງ API XDS (xDiscovery Service), ລວມທັງ DNS, ການກວດສອບສຸຂະພາບ, ການຄຸ້ມຄອງກຸ່ມທົ່ວໄປແລະເວລາແລ່ນ, ສະຖິຕິການປັບໃຫມ່, ການບໍລິຫານແລະການຄຸ້ມຄອງຂະບວນການທົ່ວໄປ - Linux signals hot restart, ແລະອື່ນໆ. ເກີດຂຶ້ນໃນກະທູ້ນີ້ແມ່ນ asynchronous ແລະ "ບໍ່ສະກັດ". ໂດຍທົ່ວໄປ, ກະທູ້ຫຼັກປະສານງານຂະບວນການທໍາງານທີ່ສໍາຄັນທັງຫມົດທີ່ບໍ່ຈໍາເປັນຕ້ອງໃຊ້ CPU ຈໍານວນຫຼວງຫຼາຍ. ນີ້ອະນຸຍາດໃຫ້ລະຫັດຄວບຄຸມສ່ວນໃຫຍ່ຖືກຂຽນຄືກັບວ່າມັນເປັນກະທູ້ດຽວ.
• ຄົນງານ: ໂດຍຄ່າເລີ່ມຕົ້ນ, Envoy ສ້າງກະທູ້ພະນັກງານສໍາລັບແຕ່ລະຫົວຂໍ້ຮາດແວໃນລະບົບ, ນີ້ສາມາດຄວບຄຸມໄດ້ໂດຍໃຊ້ທາງເລືອກ. --concurrency. ແຕ່ລະກະທູ້ຂອງພະນັກງານດໍາເນີນການ loop ເຫດການ "ບໍ່ຕັນ", ເຊິ່ງຮັບຜິດຊອບສໍາລັບການຟັງແຕ່ລະຄົນ; ໃນເວລາຂຽນ (29 ກໍລະກົດ 2017) ບໍ່ມີການ sharding ຂອງຜູ້ຟັງ, ຍອມຮັບການເຊື່ອມຕໍ່ໃຫມ່, instantiating stack ການກັ່ນຕອງສໍາລັບ. ການ​ເຊື່ອມ​ຕໍ່​, ແລະ​ການ​ປຸງ​ແຕ່ງ​ການ​ປະ​ຕິ​ບັດ​ການ​ປ້ອນ​ຂໍ້​ມູນ / ຜົນ​ຜະ​ລິດ​ທັງ​ຫມົດ (IO​) ໃນ​ໄລ​ຍະ​ຊີ​ວິດ​ຂອງ​ການ​ເຊື່ອມ​ຕໍ່​. ອີກເທື່ອ ໜຶ່ງ, ນີ້ອະນຸຍາດໃຫ້ລະຫັດການຈັດການການເຊື່ອມຕໍ່ສ່ວນໃຫຍ່ຖືກຂຽນຄືກັບວ່າມັນເປັນກະທູ້ດຽວ.
• File flusher: ແຕ່ລະໄຟລ໌ທີ່ Envoy ຂຽນ, ສ່ວນໃຫຍ່ເຂົ້າເຖິງບັນທຶກ, ໃນປັດຈຸບັນມີກະທູ້ສະກັດເອກະລາດ. ນີ້ແມ່ນເນື່ອງມາຈາກຄວາມຈິງທີ່ວ່າການຂຽນໄຟລ໌ທີ່ຖືກເກັບໄວ້ໂດຍລະບົບໄຟລ໌ເຖິງແມ່ນວ່າໃນເວລາທີ່ໃຊ້ O_NONBLOCK ບາງຄັ້ງສາມາດຖືກສະກັດ (sigh). ໃນເວລາທີ່ກະທູ້ຂອງພະນັກງານຈໍາເປັນຕ້ອງຂຽນໃສ່ໄຟລ໌, ຕົວຈິງແລ້ວຂໍ້ມູນຖືກຍ້າຍໄປທີ່ buffer ໃນຫນ່ວຍຄວາມຈໍາບ່ອນທີ່ມັນຖືກ flushed ຜ່ານກະທູ້ໃນທີ່ສຸດ. ລ້າງໄຟລ໌. ນີ້ແມ່ນພື້ນທີ່ຫນຶ່ງຂອງລະຫັດທີ່ທາງວິຊາການທັງຫມົດກະທູ້ຂອງພະນັກງານສາມາດສະກັດ lock ດຽວກັນໃນຂະນະທີ່ພະຍາຍາມຕື່ມຂໍ້ມູນໃສ່ buffer ຫນ່ວຍຄວາມຈໍາ.

ການຈັດການການເຊື່ອມຕໍ່

ດັ່ງ​ທີ່​ໄດ້​ກ່າວ​ມາ​ໂດຍ​ຫຍໍ້​ຂ້າງ​ເທິງ​ນີ້, ກະ​ທູ້​ແຮງ​ງານ​ທັງ​ໝົດ​ລ້ວນ​ແຕ່​ຮັບ​ຟັງ​ຜູ້​ຟັງ​ທັງ​ໝົດ​ໂດຍ​ບໍ່​ມີ​ການ​ແບ່ງ​ແຍກ. ດັ່ງນັ້ນ, kernel ຖືກນໍາໃຊ້ເພື່ອສົ່ງ sockets ທີ່ຍອມຮັບຢ່າງສະຫງ່າງາມໄປຫາກະທູ້ພະນັກງານ. kernels ທີ່ທັນສະໄຫມໂດຍທົ່ວໄປແມ່ນດີຫຼາຍ, ພວກເຂົາໃຊ້ຄຸນສົມບັດເຊັ່ນ input / output (IO) ບູລິມະສິດການຊຸກຍູ້ເພື່ອພະຍາຍາມຕື່ມຂໍ້ມູນໃສ່ກະທູ້ກັບການເຮັດວຽກກ່ອນທີ່ມັນຈະເລີ່ມຕົ້ນການນໍາໃຊ້ threads ອື່ນໆທີ່ຍັງຟັງຢູ່ໃນເຕົ້າຮັບດຽວກັນ, ແລະບໍ່ໄດ້ໃຊ້ round robin. locking (Spinlock) ເພື່ອປະມວນຜົນແຕ່ລະຄໍາຮ້ອງຂໍ.
ເມື່ອການເຊື່ອມຕໍ່ຖືກຍອມຮັບໃນກະທູ້ຄົນງານ, ມັນຈະບໍ່ອອກຈາກກະທູ້ນັ້ນ. ການປຸງແຕ່ງການເຊື່ອມຕໍ່ເພີ່ມເຕີມທັງຫມົດແມ່ນຈັດການທັງຫມົດໃນກະທູ້ຂອງພະນັກງານ, ລວມທັງພຶດຕິກໍາການສົ່ງຕໍ່ໃດໆ.

ນີ້​ມີ​ຜົນ​ສະ​ທ້ອນ​ທີ່​ສໍາ​ຄັນ​ຈໍາ​ນວນ​ຫນຶ່ງ​:

• ສະລອຍນ້ຳເຊື່ອມຕໍ່ທັງໝົດໃນ Envoy ແມ່ນຖືກມອບໝາຍໃຫ້ກັບກະທູ້ຄົນງານ. ດັ່ງນັ້ນ, ເຖິງແມ່ນວ່າການເຊື່ອມຕໍ່ HTTP / 2 ເຊື່ອມຕໍ່ພຽງແຕ່ຫນຶ່ງການເຊື່ອມຕໍ່ກັບແຕ່ລະ host upstream ໃນເວລາດຽວ, ຖ້າມີສີ່ threads ຂອງພະນັກງານ, ຈະມີສີ່ການເຊື່ອມຕໍ່ HTTP / 2 ຕໍ່ host upstream ຢູ່ໃນສະພາບທີ່ຫມັ້ນຄົງ.
• ເຫດຜົນທີ່ Envoy ເຮັດວຽກວິທີນີ້ແມ່ນວ່າໂດຍການຮັກສາທຸກສິ່ງທຸກຢ່າງຢູ່ໃນກະທູ້ຄົນດຽວ, ເກືອບລະຫັດທັງຫມົດສາມາດຖືກຂຽນໂດຍບໍ່ມີການສະກັດແລະຄືກັບວ່າມັນເປັນກະທູ້ດຽວ. ການອອກແບບນີ້ເຮັດໃຫ້ມັນງ່າຍຕໍ່ການຂຽນລະຫັດຫຼາຍແລະຂະຫນາດໄດ້ດີ incredibly ເປັນຈໍານວນເກືອບບໍ່ຈໍາກັດຂອງກະທູ້ພະນັກງານ.
• ຢ່າງໃດກໍຕາມ, ຫນຶ່ງໃນສິ່ງທີ່ເອົາມາຕົ້ນຕໍແມ່ນວ່າຈາກສະນຸກເກີຫນ່ວຍຄວາມຈໍາແລະຈຸດປະສິດທິພາບການເຊື່ອມຕໍ່, ມັນເປັນສິ່ງສໍາຄັນຫຼາຍທີ່ຈະ configure ໄດ້. --concurrency. ການມີກະທູ້ຄົນງານຫຼາຍກວ່າຄວາມຈໍາເປັນຈະເສຍຄວາມຈໍາ, ສ້າງການເຊື່ອມຕໍ່ທີ່ບໍ່ມີປະໂຫຍດຫຼາຍ, ແລະຫຼຸດຜ່ອນອັດຕາການລວມການເຊື່ອມຕໍ່. ຢູ່ Lyft, ຕູ້ຄອນເທນເນີ sidecar ທູດຂອງພວກເຮົາແລ່ນດ້ວຍສະກຸນເງິນທີ່ຕໍ່າຫຼາຍເພື່ອໃຫ້ປະສິດທິພາບກົງກັບການບໍລິການທີ່ເຂົາເຈົ້ານັ່ງຢູ່ຄຽງຂ້າງ. ພວກເຮົາດໍາເນີນການ Envoy ເປັນຕົວແທນຂອບພຽງແຕ່ຢູ່ໃນຄວາມສອດຄ່ອງສູງສຸດ.

ການບໍ່ຂັດຂວາງຫມາຍຄວາມວ່າແນວໃດ?

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

Envoy ໃຊ້ການລັອກຂະບວນການຍາວຫຼາຍ:

• ດັ່ງທີ່ໄດ້ສົນທະນາກັນແລ້ວ, ເມື່ອຂຽນບັນທຶກການເຂົ້າເຖິງ, ກະທູ້ຂອງພະນັກງານທັງໝົດໄດ້ຮັບ lock ດຽວກັນກ່ອນທີ່ buffer log in-memory ຈະເຕັມໄປ. ເວລາຖື lock ຄວນຈະຕ່ໍາຫຼາຍ, ແຕ່ມັນເປັນໄປໄດ້ສໍາລັບການ lock ທີ່ຈະແຂ່ງຂັນໃນ concurrency ສູງແລະ throughput ສູງ.
• Envoy ໃຊ້ລະບົບທີ່ສັບສົນຫຼາຍເພື່ອຈັດການກັບສະຖິຕິທີ່ເປັນທ້ອງຖິ່ນຂອງກະທູ້. ນີ້ຈະເປັນຫົວຂໍ້ຂອງການຕອບແຍກຕ່າງຫາກ. ຢ່າງໃດກໍ່ຕາມ, ຂ້າພະເຈົ້າຈະກ່າວເຖິງສັ້ນໆວ່າເປັນສ່ວນຫນຶ່ງຂອງການປຸງແຕ່ງສະຖິຕິກະທູ້ໃນທ້ອງຖິ່ນ, ບາງຄັ້ງມັນຈໍາເປັນຕ້ອງໄດ້ມາລັອກຢູ່ໃນ "ຮ້ານສະຖິຕິ". ການລັອກນີ້ບໍ່ຄວນຖືກຕ້ອງການ.
• ກະທູ້ຫຼັກແຕ່ລະໄລຍະຈໍາເປັນຕ້ອງປະສານງານກັບກະທູ້ພະນັກງານທັງຫມົດ. ນີ້ແມ່ນເຮັດໄດ້ໂດຍການ "ເຜີຍແຜ່" ຈາກກະທູ້ຫຼັກໄປຫາກະທູ້ຂອງພະນັກງານ, ແລະບາງຄັ້ງຈາກກະທູ້ພະນັກງານກັບຄືນໄປຫາກະທູ້ຕົ້ນຕໍ. ການສົ່ງຕ້ອງການລັອກເພື່ອໃຫ້ຂໍ້ຄວາມທີ່ຖືກເຜີຍແຜ່ສາມາດຖືກຈັດຄິວສໍາລັບການຈັດສົ່ງໃນພາຍຫຼັງ. locks ເຫຼົ່ານີ້ບໍ່ຄວນຈະຖືກໂຕ້ແຍ້ງຢ່າງຈິງຈັງ, ແຕ່ພວກມັນຍັງສາມາດຖືກສະກັດທາງດ້ານວິຊາການ.
• ເມື່ອ Envoy ຂຽນບັນທຶກການຖ່າຍທອດຄວາມຜິດພາດຂອງລະບົບ (ຄວາມຜິດພາດມາດຕະຖານ), ມັນໄດ້ຮັບ lock ໃນຂະບວນການທັງຫມົດ. ໂດຍທົ່ວໄປແລ້ວ, ການລັກລອບຕັດໄມ້ໃນທ້ອງຖິ່ນຂອງ Envoy ແມ່ນຖືວ່າຂີ້ຮ້າຍຈາກຈຸດປະຕິບັດການ, ສະນັ້ນ ຍັງບໍ່ທັນໄດ້ເອົາໃຈໃສ່ຫຼາຍໃນການປັບປຸງມັນ.
• ມີການລັອກແບບສຸ່ມອີກຈຳນວນໜຶ່ງ, ແຕ່ບໍ່ມີອັນໃດອັນໃດທີ່ສຳຄັນ ແລະບໍ່ຄວນຖືກທ້າທາຍ.

ກະທູ້ເກັບຮັກສາທ້ອງຖິ່ນ

ເນື່ອງຈາກວ່າວິທີການ Envoy ແຍກຄວາມຮັບຜິດຊອບຂອງກະທູ້ຕົ້ນຕໍອອກຈາກຄວາມຮັບຜິດຊອບຂອງກະທູ້ຂອງພະນັກງານ, ມີຄວາມຕ້ອງການທີ່ຈະປຸງແຕ່ງທີ່ຊັບຊ້ອນສາມາດເຮັດໄດ້ໃນກະທູ້ຫຼັກແລະຫຼັງຈາກນັ້ນສະຫນອງໃຫ້ແຕ່ລະກະທູ້ຂອງພະນັກງານໃນລັກສະນະ concurrently. ພາກສ່ວນນີ້ອະທິບາຍເຖິງ Envoy Thread Local Storage (TLS) ໃນລະດັບສູງ. ໃນພາກຕໍ່ໄປຂ້າພະເຈົ້າຈະອະທິບາຍວິທີການທີ່ມັນຖືກນໍາໃຊ້ໃນການຄຸ້ມຄອງກຸ່ມ.


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

ລະບົບ TLS ຂອງ Envoy (Thread local storage) ເຮັດວຽກດັ່ງຕໍ່ໄປນີ້:

• ລະຫັດທີ່ເຮັດວຽກຢູ່ໃນຫົວຂໍ້ຫຼັກສາມາດຈັດສັນຊ່ອງສຽບ TLS ສໍາລັບຂະບວນການທັງຫມົດ. ເຖິງແມ່ນວ່ານີ້ແມ່ນບໍ່ມີຕົວຕົນ, ໃນທາງປະຕິບັດມັນເປັນດັດຊະນີເຂົ້າໄປໃນ vector, ສະຫນອງການເຂົ້າເຖິງ O(1).
• ກະທູ້ຕົ້ນຕໍສາມາດຕິດຕັ້ງຂໍ້ມູນ arbitrary ເຂົ້າໄປໃນຊ່ອງຂອງຕົນ. ເມື່ອອັນນີ້ສຳເລັດແລ້ວ, ຂໍ້ມູນຈະຖືກເຜີຍແຜ່ໃຫ້ແຕ່ລະກະທູ້ຂອງພະນັກງານເປັນເຫດການ loop ເຫດການປົກກະຕິ.
• ກະທູ້ຄົນງານສາມາດອ່ານໄດ້ຈາກຊ່ອງ TLS ຂອງເຂົາເຈົ້າ ແລະດຶງຂໍ້ມູນ thread-local ທີ່ມີຢູ່ໃນບ່ອນນັ້ນ.

ເຖິງ​ແມ່ນ​ວ່າ​ມັນ​ເປັນ​ຮູບ​ແບບ​ທີ່​ງ່າຍ​ດາຍ​ແລະ​ມີ​ອໍາ​ນາດ incredibly, ມັນ​ຄ້າຍ​ຄື​ກັນ​ຫຼາຍ​ກັບ​ແນວ​ຄວາມ​ຄິດ​ຂອງ RCU (Read-Copy-Update​) ການ​ປິດ​. ໂດຍພື້ນຖານແລ້ວ, ກະທູ້ຂອງພະນັກງານບໍ່ເຄີຍເຫັນການປ່ຽນແປງຂໍ້ມູນໃດໆໃນຊ່ອງ TLS ໃນຂະນະທີ່ເຮັດວຽກເຮັດວຽກ. ການປ່ຽນແປງເກີດຂຶ້ນພຽງແຕ່ໃນໄລຍະສ່ວນທີ່ເຫຼືອລະຫວ່າງກິດຈະກໍາການເຮັດວຽກ.

Envoy ໃຊ້ສິ່ງນີ້ໃນສອງວິທີທີ່ແຕກຕ່າງກັນ:

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

ກະທູ້ອັບເດດກຸ່ມ

ໃນພາກນີ້, ຂ້າພະເຈົ້າຈະອະທິບາຍວິທີການ TLS (Thread local storage) ຖືກໃຊ້ເພື່ອຈັດການກຸ່ມ. ການຈັດການກຸ່ມລວມມີ xDS API ແລະ/ຫຼື DNS processing, ເຊັ່ນດຽວກັນກັບການກວດສຸຂະພາບ.


ການຈັດການການໄຫຼຂອງກຸ່ມປະກອບມີອົງປະກອບ ແລະຂັ້ນຕອນຕໍ່ໄປນີ້:

1. Cluster Manager ເປັນອົງປະກອບພາຍໃນ Envoy ທີ່ຄຸ້ມຄອງທັງໝົດທີ່ຮູ້ຈັກຂອງ cluster upstreams, Cluster Discovery Service (CDS) API, the Secret Discovery Service (SDS) ແລະ Endpoint Discovery Service (EDS) APIs, DNS, ແລະ active external checking. ມັນເປັນຄວາມຮັບຜິດຊອບໃນການສ້າງທັດສະນະ "ໃນທີ່ສຸດສອດຄ່ອງ" ຂອງແຕ່ລະກຸ່ມຕົ້ນນ້ໍາ, ເຊິ່ງປະກອບມີເຈົ້າພາບທີ່ຄົ້ນພົບເຊັ່ນດຽວກັນກັບສະຖານະພາບສຸຂະພາບ.
2. ຜູ້ກວດສຸຂະພາບເຮັດການກວດສຸຂະພາບຢ່າງຫ້າວຫັນ ແລະລາຍງານການປ່ຽນແປງສະຖານະສຸຂະພາບໃຫ້ກັບຜູ້ຈັດການກຸ່ມ.
3. CDS (Cluster Discovery Service) / SDS (Secret Discovery Service) / EDS (Endpoint Discovery Service) / DNS ແມ່ນດໍາເນີນການເພື່ອກໍານົດການເປັນສະມາຊິກກຸ່ມ. ການປ່ຽນແປງຂອງລັດແມ່ນກັບຄືນໄປຫາຜູ້ຈັດການກຸ່ມ.
4. ແຕ່ລະກະທູ້ຂອງພະນັກງານປະຕິບັດການ loop ເຫດການຢ່າງຕໍ່ເນື່ອງ.
5. ເມື່ອຕົວຈັດການກຸ່ມກຳນົດວ່າສະຖານະຂອງກຸ່ມໄດ້ມີການປ່ຽນແປງ, ມັນຈະສ້າງພາບຖ່າຍໃໝ່ທີ່ອ່ານເທົ່ານັ້ນຂອງສະຖານະຂອງກຸ່ມ ແລະ ສົ່ງມັນໄປຫາແຕ່ລະກະທູ້ຂອງພະນັກງານ.
6. ໃນລະຫວ່າງໄລຍະເວລາທີ່ງຽບສະຫງົບຕໍ່ໄປ, ກະທູ້ຄົນງານຈະອັບເດດຮູບຖ່າຍໃນຊ່ອງ TLS ທີ່ຈັດສັນໄວ້.
7. ໃນລະຫວ່າງເຫດການ I/O ທີ່ຄວນຈະກໍານົດໂຮດໃນການໂຫຼດຍອດເງິນ, ຕົວດຸ່ນດ່ຽງການໂຫຼດຈະຮ້ອງຂໍຊ່ອງໃສ່ TLS (Thread local storage) ເພື່ອຂໍຂໍ້ມູນກ່ຽວກັບໂຮດ. ນີ້ບໍ່ຈໍາເປັນຕ້ອງມີ locks. ໃຫ້ສັງເກດວ່າ TLS ຍັງສາມາດກະຕຸ້ນເຫດການການປັບປຸງເພື່ອໃຫ້ຕົວດຸ່ນດ່ຽງການໂຫຼດແລະອົງປະກອບອື່ນໆສາມາດຄິດໄລ່ແຄດ, ໂຄງສ້າງຂໍ້ມູນ, ແລະອື່ນໆ. ນີ້ແມ່ນເກີນຂອບເຂດຂອງການຕອບນີ້, ແຕ່ຖືກນໍາໃຊ້ໃນສະຖານທີ່ຕ່າງໆໃນລະຫັດ.

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

ລະບົບຍ່ອຍອື່ນໆທີ່ນໍາໃຊ້ TLS

TLS (Thread local storage) ແລະ RCU (Read Copy Update) ຖືກນໍາໃຊ້ຢ່າງກວ້າງຂວາງໃນ Envoy.

ຕົວຢ່າງຂອງການ ນຳ ໃຊ້:

• ກົນໄກການປ່ຽນແປງການເຮັດວຽກໃນລະຫວ່າງການປະຕິບັດ: ບັນຊີລາຍຊື່ຂອງການເຮັດວຽກທີ່ເປີດໃຊ້ໃນປັດຈຸບັນແມ່ນຄິດໄລ່ຢູ່ໃນຫົວຂໍ້ຕົ້ນຕໍ. ຫຼັງຈາກນັ້ນ, ແຕ່ລະກະທູ້ຂອງພະນັກງານແມ່ນໄດ້ຮັບພາບຖ່າຍແບບອ່ານເທົ່ານັ້ນໂດຍໃຊ້ RCU semantics.
• ການປ່ຽນຕາຕະລາງເສັ້ນທາງ: ສໍາລັບຕາຕະລາງເສັ້ນທາງທີ່ສະຫນອງໂດຍ RDS (Route Discovery Service), ຕາຕະລາງເສັ້ນທາງແມ່ນຖືກສ້າງຂຶ້ນໃນຫົວຂໍ້ຕົ້ນຕໍ. ພາບຖ່າຍແບບອ່ານຢ່າງດຽວຈະຖືກສະໜອງໃຫ້ແຕ່ລະກະທູ້ຂອງພະນັກງານໃນພາຍຫຼັງໂດຍໃຊ້ RCU (Read Copy Update) semantics. ນີ້ເຮັດໃຫ້ການປ່ຽນແປງຕາຕະລາງເສັ້ນທາງມີປະສິດທິພາບປະລໍາມະນູ.
• HTTP header caching: ຍ້ອນວ່າມັນຫັນອອກ, ການຄິດໄລ່ສ່ວນຫົວ HTTP ສໍາລັບແຕ່ລະຄໍາຮ້ອງຂໍ (ໃນຂະນະທີ່ແລ່ນ ~ 25K + RPS ຕໍ່ຫຼັກ) ແມ່ນຂ້ອນຂ້າງແພງ. Envoy ສູນກາງຄິດໄລ່ສ່ວນຫົວປະມານທຸກໆເຄິ່ງວິນາທີແລະສະຫນອງມັນໃຫ້ແຕ່ລະພະນັກງານໂດຍຜ່ານ TLS ແລະ RCU.

ມີກໍລະນີອື່ນໆ, ແຕ່ຕົວຢ່າງທີ່ຜ່ານມາຄວນໃຫ້ຄວາມເຂົ້າໃຈດີກ່ຽວກັບສິ່ງທີ່ TLS ຖືກນໍາໃຊ້ສໍາລັບ.

ຄວາມຜິດພາດການປະຕິບັດທີ່ຮູ້ຈັກ

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

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

ສະຫຼຸບ

ຮູບແບບການໃສ່ກະທູ້ຂອງ Envoy ຖືກອອກແບບມາເພື່ອສະຫນອງຄວາມງ່າຍຂອງການຂຽນໂປລແກລມແລະການຂະຫນານອັນໃຫຍ່ຫຼວງໂດຍຄ່າໃຊ້ຈ່າຍຂອງຫນ່ວຍຄວາມຈໍາແລະການເຊື່ອມຕໍ່ທີ່ອາດຈະສູນເສຍໄປຖ້າບໍ່ໄດ້ຕັ້ງຄ່າຢ່າງຖືກຕ້ອງ. ຮູບແບບນີ້ອະນຸຍາດໃຫ້ມັນປະຕິບັດໄດ້ດີຫຼາຍໃນຈໍານວນ thread ສູງຫຼາຍແລະ throughput.
ດັ່ງທີ່ຂ້າພະເຈົ້າໄດ້ກ່າວມາສັ້ນໆໃນ Twitter, ການອອກແບບຍັງສາມາດດໍາເນີນການຢູ່ເທິງສຸດຂອງເຄືອຂ່າຍຮູບແບບຜູ້ໃຊ້ແບບເຕັມຮູບແບບເຊັ່ນ DPDK (Data Plane Development Kit), ເຊິ່ງສາມາດສົ່ງຜົນໃຫ້ເຄື່ອງແມ່ຂ່າຍແບບດັ້ງເດີມຈັດການຫຼາຍລ້ານຄໍາຮ້ອງຂໍຕໍ່ວິນາທີດ້ວຍການປະມວນຜົນເຕັມ L7. ມັນຈະເປັນຫນ້າສົນໃຈຫຼາຍທີ່ຈະເຫັນສິ່ງທີ່ສ້າງຂຶ້ນໃນສອງສາມປີຂ້າງຫນ້າ.
ຄໍາເຫັນສັ້ນໆຄັ້ງສຸດທ້າຍ: ຂ້ອຍຖືກຖາມຫຼາຍຄັ້ງວ່າເປັນຫຍັງພວກເຮົາເລືອກ C ++ ສໍາລັບ Envoy. ເຫດຜົນຍັງຄົງຢູ່ວ່າມັນຍັງເປັນພຽງແຕ່ພາສາຊັ້ນຮຽນອຸດສາຫະກໍາທີ່ໃຊ້ກັນຢ່າງກວ້າງຂວາງເຊິ່ງສະຖາປັດຕະຍະກໍາທີ່ອະທິບາຍໄວ້ໃນຂໍ້ຄວາມນີ້ສາມາດສ້າງໄດ້. C ++ ແນ່ນອນບໍ່ ເໝາະ ສົມກັບໂຄງການທັງ ໝົດ ຫຼືຫຼາຍໂຄງການ, ແຕ່ ສຳ ລັບບາງກໍລະນີທີ່ໃຊ້ມັນຍັງເປັນເຄື່ອງມືດຽວທີ່ຈະເຮັດວຽກໃຫ້ສຳເລັດ.

ລິ້ງຫາລະຫັດ

ລິ້ງຫາໄຟລ໌ທີ່ມີສ່ວນຕິດຕໍ່ ແລະການປະຕິບັດສ່ວນຫົວທີ່ສົນທະນາໃນໂພສນີ້:

• github.com/lyft/envoy/blob/master/include/envoy/thread_local/thread_local.h
• github.com/lyft/envoy/blob/master/source/common/thread_local/thread_local_impl.h
• github.com/lyft/envoy/blob/master/include/envoy/upstream/cluster_manager.h
• github.com/lyft/envoy/blob/master/source/common/upstream/cluster_manager_impl.h

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