ການລວບລວມຂໍ້ມູນພື້ນເມືອງໃນ Quarkus - ເປັນຫຍັງມັນຈຶ່ງສໍາຄັນ

ສະບາຍດີທຸກຄົນ! ນີ້ແມ່ນບົດຄວາມທີສອງໃນຊຸດຂອງພວກເຮົາກ່ຽວກັບ Quarkus - ມື້ນີ້ພວກເຮົາຈະເວົ້າກ່ຽວກັບການລວບລວມພື້ນເມືອງ.

ໂຄກ ແມ່ນ Java stack ປັບແຕ່ງສໍາລັບ Kubernetes. ໃນຂະນະທີ່ແນ່ນອນວ່າມີຫຼາຍຢ່າງທີ່ຕ້ອງເຮັດຢູ່ທີ່ນີ້, ພວກເຮົາໄດ້ເຮັດວຽກທີ່ດີຫຼາຍໃນຫຼາຍດ້ານ, ລວມທັງການເພີ່ມປະສິດທິພາບ JVM ແລະກອບຈໍານວນຫນຶ່ງ. ຄຸນລັກສະນະອັນໜຶ່ງຂອງ Quarkus ທີ່ໄດ້ຮັບຄວາມສົນໃຈຈາກນັກພັດທະນາແມ່ນວິທີການທີ່ສົມບູນ, ລຽບງ່າຍໃນການປ່ຽນລະຫັດ Java ໃຫ້ເປັນໄຟລ໌ທີ່ສາມາດປະຕິບັດໄດ້ສໍາລັບລະບົບປະຕິບັດການສະເພາະ (ອັນທີ່ເອີ້ນວ່າ "ການລວບລວມຂໍ້ມູນພື້ນເມືອງ"), ຄ້າຍຄືກັບ C ແລະ C ++, ບ່ອນທີ່ການລວບລວມຂໍ້ມູນດັ່ງກ່າວ. ປົກກະຕິແລ້ວເກີດຂຶ້ນໃນຕອນທ້າຍຂອງວົງຈອນຂອງການກໍ່ສ້າງ, ການທົດສອບ, ແລະການນໍາໃຊ້.

ແລະໃນຂະນະທີ່ການລວບລວມຂໍ້ມູນພື້ນເມືອງມີຄວາມສໍາຄັນ, ດັ່ງທີ່ພວກເຮົາຈະສະແດງຂ້າງລຸ່ມນີ້, ມັນຄວນຈະສັງເກດວ່າ Quarkus ເຮັດວຽກໄດ້ດີໃນເຄື່ອງ Java ທົ່ວໄປທີ່ສຸດ, OpenJDK Hotspot, ຍ້ອນການປັບປຸງການປະຕິບັດທີ່ພວກເຮົາໄດ້ປະຕິບັດຕະຫຼອດ stack. ດັ່ງນັ້ນ, ການລວບລວມພື້ນເມືອງຄວນໄດ້ຮັບການພິຈາລະນາເປັນໂບນັດເພີ່ມເຕີມທີ່ສາມາດນໍາໃຊ້ໄດ້ຕາມຄວາມຕ້ອງການຫຼືມີຄວາມຈໍາເປັນ. ໃນຄວາມເປັນຈິງ, Quarkus ອີງໃສ່ OpenJDK ຢ່າງຫຼວງຫຼາຍເມື່ອເວົ້າເຖິງຮູບພາບພື້ນເມືອງ. ແລະໂຫມດ dev, ໄດ້ຮັບການຍອມຮັບຢ່າງອົບອຸ່ນຈາກນັກພັດທະນາ, ຮັບປະກັນການທົດສອບການປ່ຽນແປງເກືອບທັນທີເນື່ອງຈາກຄວາມສາມາດຂັ້ນສູງຂອງການປະຕິບັດລະຫັດແບບເຄື່ອນໄຫວທີ່ປະຕິບັດຢູ່ໃນ Hotspot. ນອກຈາກນັ້ນ, ເມື່ອສ້າງຮູບພາບ GraalVM ແບບພື້ນເມືອງ, ຫ້ອງສະຫມຸດຊັ້ນຮຽນ OpenJDK ແລະຄວາມສາມາດຂອງ HotSpot ໄດ້ຖືກນໍາໃຊ້.

ດັ່ງນັ້ນເປັນຫຍັງທ່ານຕ້ອງການການລວບລວມຂໍ້ມູນພື້ນເມືອງຖ້າທຸກສິ່ງທຸກຢ່າງຖືກປັບປຸງຢ່າງສົມບູນແລ້ວ? ພວກເຮົາຈະພະຍາຍາມຕອບຄໍາຖາມນີ້ຂ້າງລຸ່ມນີ້.

ໃຫ້ເລີ່ມຕົ້ນດ້ວຍຄວາມຊັດເຈນ: Red Hat ມີປະສົບການຢ່າງກວ້າງຂວາງໃນການເພີ່ມປະສິດທິພາບ JVMs, stacks ແລະກອບໃນລະຫວ່າງການພັດທະນາໂຄງການ JBoss, ລວມທັງ:

• ເຄື່ອງແມ່ຂ່າຍຂອງແອັບພລິເຄຊັນທໍາອິດທີ່ເຮັດວຽກຢູ່ໃນເມຄໃນເວທີ RedHat OpenShift.
• ເຊີບເວີແອັບພລິເຄຊັນທຳອິດທີ່ໃຊ້ໃນຄອມພິວເຕີ ສຽບ PC.
• ແອັບພລິເຄຊັນເຊີບເວີທຳອິດທີ່ຈະເປີດໃຊ້ Raspberry Pi.
• ລະດັບໂຄງການທີ່ເຮັດວຽກຢູ່ໃນອຸປະກອນ Android.

ພວກເຮົາໄດ້ຈັດການກັບສິ່ງທ້າທາຍຂອງການໃຊ້ Java ໃນ cloud ແລະອຸປະກອນທີ່ມີຂໍ້ຈໍາກັດຂອງຊັບພະຍາກອນ (ອ່ານ: IoT) ສໍາລັບເວລາຫຼາຍປີແລະໄດ້ຮຽນຮູ້ເພື່ອໃຊ້ JVM ຫຼາຍທີ່ສຸດໃນດ້ານການປະຕິບັດແລະການເພີ່ມປະສິດທິພາບຂອງຫນ່ວຍຄວາມຈໍາ. ເຊັ່ນດຽວກັນກັບຄົນອື່ນຈໍານວນຫຼາຍ, ພວກເຮົາໄດ້ເຮັດວຽກກັບການລວບລວມຕົ້ນສະບັບຂອງຄໍາຮ້ອງສະຫມັກ Java ສໍາລັບເວລາດົນນານຜ່ານ G.C.J., ອາວເບ, Excelsior JET ແລະເຖິງແມ່ນວ່າ DALVIK ແລະພວກເຮົາຮູ້ດີກ່ຽວກັບຂໍ້ດີແລະຂໍ້ເສຍຂອງວິທີການນີ້ (ຕົວຢ່າງ, ຄວາມຫຍຸ້ງຍາກໃນການເລືອກລະຫວ່າງວິທະຍາໄລຂອງ "ສ້າງຫນຶ່ງຄັ້ງ - ແລ່ນຢູ່ບ່ອນໃດກໍໄດ້" ແລະຄວາມຈິງທີ່ວ່າຄໍາຮ້ອງສະຫມັກທີ່ລວບລວມມີຂະຫນາດນ້ອຍກວ່າແລະແລ່ນໄວ).

ເປັນຫຍັງມັນຈຶ່ງສໍາຄັນທີ່ຈະພິຈາລະນາຂໍ້ດີ ແລະຂໍ້ເສຍເຫຼົ່ານີ້? ເນື່ອງຈາກວ່າໃນບາງສະຖານະການອັດຕາສ່ວນຂອງພວກເຂົາກາຍເປັນການຕັດສິນໃຈ:

• ຕົວຢ່າງ, ໃນສະພາບແວດລ້ອມເຊີບເວີ / ເຫດການທີ່ຂັບເຄື່ອນໂດຍບ່ອນທີ່ ການບໍລິການພຽງແຕ່ຕ້ອງເລີ່ມຕົ້ນ ໃນເວລາທີ່ແທ້ຈິງ (ຍາກຫຼືອ່ອນ) ເພື່ອໃຫ້ມີເວລາຕອບສະຫນອງຕໍ່ເຫດການ. ບໍ່ເຫມືອນກັບການບໍລິການຄົງທີ່ທີ່ມີອາຍຸຍືນຍາວ, ຢູ່ທີ່ນີ້ໄລຍະເວລາຂອງການເລີ່ມຕົ້ນເຢັນຈະເພີ່ມເວລາຕອບສະຫນອງຕໍ່ການຮ້ອງຂໍ. JVM ຍັງໃຊ້ເວລາຢ່າງຫຼວງຫຼາຍເພື່ອເລີ່ມຕົ້ນ, ແລະໃນຂະນະທີ່ນີ້ສາມາດຫຼຸດລົງໃນບາງກໍລະນີໂດຍວິທີການຮາດແວທີ່ບໍລິສຸດ, ຄວາມແຕກຕ່າງລະຫວ່າງຫນຶ່ງວິນາທີແລະ 5 milliseconds ສາມາດເປັນຄວາມແຕກຕ່າງລະຫວ່າງຊີວິດແລະຄວາມຕາຍ. ແມ່ນແລ້ວ, ໃນທີ່ນີ້ທ່ານສາມາດຫຼີ້ນກັບການສ້າງສະຫງວນຮ້ອນຂອງເຄື່ອງຈັກ Java (ເຊິ່ງ, ຕົວຢ່າງ, ພວກເຮົາໄດ້ເຮັດກັບ ສົ່ງ OpenWhisk ໄປຫາ Knative), ແຕ່ນີ້ຢູ່ໃນຕົວຂອງມັນເອງບໍ່ໄດ້ຮັບປະກັນວ່າຈະມີ JVMs ພຽງພໍທີ່ຈະດໍາເນີນການຮ້ອງຂໍເປັນຂະຫນາດການໂຫຼດ. ແລະຈາກທັດສະນະທາງດ້ານເສດຖະກິດ, ນີ້ອາດຈະບໍ່ແມ່ນທາງເລືອກທີ່ຖືກຕ້ອງທີ່ສຸດ.
• ນອກຈາກນັ້ນ, ມີລັກສະນະອື່ນທີ່ມັກຈະປາກົດຂຶ້ນ: multitenancy. ເຖິງວ່າຈະມີຄວາມຈິງທີ່ວ່າ JVMs ໄດ້ເຂົ້າມາໃກ້ຊິດກັບລະບົບປະຕິບັດການໃນຄວາມສາມາດຂອງພວກເຂົາ, ພວກເຂົາຍັງບໍ່ສາມາດເຮັດສິ່ງທີ່ພວກເຮົາຄຸ້ນເຄີຍກັບ Linux - isolating processes . ດັ່ງນັ້ນ, ຄວາມລົ້ມເຫຼວຂອງຫນຶ່ງກະທູ້ສາມາດເຮັດໃຫ້ເຄື່ອງ Java ທັງຫມົດຫຼຸດລົງ. ຫຼາຍຄົນພະຍາຍາມຫາຈຸດອ່ອນນີ້ໂດຍການອຸທິດ JVM ແຍກຕ່າງຫາກສໍາລັບຄໍາຮ້ອງສະຫມັກຂອງຜູ້ໃຊ້ແຕ່ລະຄົນເພື່ອຫຼຸດຜ່ອນຜົນສະທ້ອນຂອງຄວາມລົ້ມເຫລວ. ນີ້ແມ່ນຂ້ອນຂ້າງສົມເຫດສົມຜົນ, ແຕ່ບໍ່ເຫມາະສົມກັບການປັບຂະຫນາດ.
• ນອກຈາກນັ້ນ, ສໍາລັບຄໍາຮ້ອງສະຫມັກທີ່ຮັດກຸມຟັງ, ຕົວຊີ້ວັດທີ່ສໍາຄັນແມ່ນຄວາມຫນາແຫນ້ນຂອງການບໍລິການໃນເຈົ້າພາບ. ການຫັນປ່ຽນໄປສູ່ວິທີການ 12 ປັດໄຈການສະຫມັກ, microservices ແລະ Kubernetes ເພີ່ມຈໍານວນເຄື່ອງ Java ຕໍ່ຄໍາຮ້ອງສະຫມັກ. ນັ້ນແມ່ນ, ໃນດ້ານຫນຶ່ງ, ທັງຫມົດນີ້ສະຫນອງຄວາມຍືດຫຍຸ່ນແລະຄວາມຫນ້າເຊື່ອຖື, ແຕ່ໃນເວລາດຽວກັນການບໍລິໂພກຂອງຫນ່ວຍຄວາມຈໍາພື້ນຖານໃນການບໍລິການຍັງເພີ່ມຂຶ້ນ, ແລະບາງຄ່າໃຊ້ຈ່າຍເຫຼົ່ານີ້ບໍ່ຈໍາເປັນຢ່າງເຂັ້ມງວດ. ໄຟລ໌ປະຕິບັດການລວບລວມສະຖິຕິໄດ້ຮັບຜົນປະໂຫຍດຢູ່ທີ່ນີ້ເນື່ອງຈາກເຕັກນິກການເພີ່ມປະສິດທິພາບຕ່າງໆ, ເຊັ່ນ: ການກໍາຈັດລະຫັດຕາຍໃນລະດັບຕ່ໍາ, ເມື່ອຮູບພາບສຸດທ້າຍປະກອບມີພຽງແຕ່ພາກສ່ວນເຫຼົ່ານັ້ນຂອງກອບ (ລວມທັງ JDK ຕົວມັນເອງ) ທີ່ບໍລິການຕົວຈິງໃຊ້. ດັ່ງນັ້ນ, ການລວບລວມຂໍ້ມູນພື້ນເມືອງ Quarkus ຈະຊ່ວຍຈັດວາງຕົວຢ່າງການບໍລິການຢ່າງຫນາແຫນ້ນຢູ່ໃນໂຮດໂດຍບໍ່ມີການທໍາລາຍຄວາມປອດໄພ.

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

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

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