ວິທີການ Quarkus ປະສົມປະສານການດໍາເນີນໂຄງການທີ່ຈໍາເປັນແລະປະຕິກິລິຍາ

ປີນີ້ພວກເຮົາວາງແຜນທີ່ຈະພັດທະນາຫົວຂໍ້ຕູ້ຄອນເທນເນີຢ່າງຈິງຈັງ, Cloud-Native Java и Kubernetes. ການສືບຕໍ່ຢ່າງມີເຫດຜົນຂອງຫົວຂໍ້ເຫຼົ່ານີ້ຈະເປັນເລື່ອງກ່ຽວກັບກອບ Quarkus, ແລ້ວ ພິຈາລະນາ ສຸດ Habre. ບົດຄວາມໃນມື້ນີ້ແມ່ນຫນ້ອຍກ່ຽວກັບການອອກແບບຂອງ "subatomic superfast Java" ແລະເພີ່ມເຕີມກ່ຽວກັບຄໍາສັນຍາທີ່ Quarkus ນໍາມາໃຫ້ວິສາຫະກິດ.

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

Superfast subatomic Java ໄດ້ບັນລຸລະດັບໃຫມ່!

42 ສະບັບ, 8 ເດືອນຂອງການເຮັດວຽກຂອງຊຸມຊົນແລະ 177 ຜູ້ພັດທະນາທີ່ຫນ້າອັດສະຈັນ - ຜົນໄດ້ຮັບຂອງມັນທັງຫມົດແມ່ນການປ່ອຍໃນເດືອນພະຈິກ 2019. Quarkus 1.0, ການປ່ອຍທີ່ເປັນຈຸດສໍາຄັນໃນການພັດທະນາໂຄງການແລະສະຫນອງຄຸນນະສົມບັດເຢັນຫຼາຍແລະຄວາມສາມາດ (ທ່ານສາມາດອ່ານເພີ່ມເຕີມກ່ຽວກັບພວກເຂົາໃນ ປະກາດ).

ມື້​ນີ້​ພວກ​ເຮົາ​ຈະ​ສະ​ແດງ​ໃຫ້​ທ່ານ​ເຫັນ​ວິ​ທີ​ການ Quarkus ລວມ​ຕົວ​ແບບ​ການ​ດໍາ​ເນີນ​ງານ​ທີ່​ຈໍາ​ເປັນ​ແລະ reactive ເຂົ້າ​ໄປ​ໃນ​ຫຼັກ reactive ດຽວ​. ພວກເຮົາຈະເລີ່ມຕົ້ນດ້ວຍປະຫວັດຫຍໍ້ໆ ແລະຫຼັງຈາກນັ້ນໃຫ້ລາຍລະອຽດກ່ຽວກັບວ່າ Quarkus 'reactive dualism ແມ່ນຫຍັງ ແລະແນວໃດ. Java- ນັກພັດທະນາສາມາດໃຊ້ປະໂຫຍດຈາກຜົນປະໂຫຍດເຫຼົ່ານີ້.

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

ກ່ອນອື່ນ, ໃຫ້ເບິ່ງປະຫວັດສາດ.

ສາຍນ້ໍາແລະບັນຈຸ

ເລີ່ມຕົ້ນດ້ວຍຮຸ່ນ 8u131, Java ໄດ້ເລີ່ມຕົ້ນທີ່ຈະສະຫນັບສະຫນູນບັນຈຸບັນຈຸຫຼາຍຫຼືຫນ້ອຍເນື່ອງຈາກການປັບປຸງການທໍາງານຂອງ ergonomics. ໂດຍສະເພາະ, ຕອນນີ້ JVM ຮູ້ວ່າມີຈັກ processor cores ທີ່ມັນແລ່ນຢູ່ ແລະສາມາດກຳນົດຄ່າ thread pools - ໂດຍປົກກະຕິແລ້ວ fork/join pools - ຕາມ. ແນ່ນອນ, ນີ້ແມ່ນດີຫຼາຍ, ແຕ່ສົມມຸດວ່າພວກເຮົາມີຄໍາຮ້ອງສະຫມັກເວັບແບບດັ້ງເດີມທີ່ໃຊ້ HTTP servlets ແລະແລ່ນໃນ Tomcat, Jetty, ແລະອື່ນໆ. ດັ່ງນັ້ນ, ແອັບພລິເຄຊັນນີ້ຈະໃຫ້ແຕ່ລະຄໍາຮ້ອງຂໍແຍກຕ່າງຫາກແລະອະນຸຍາດໃຫ້ມັນສະກັດກະທູ້ນີ້ໃນຂະນະທີ່ລໍຖ້າການດໍາເນີນງານ I/O, ຕົວຢ່າງ, ເມື່ອເຂົ້າເຖິງຖານຂໍ້ມູນ, ໄຟລ໌ຫຼືບໍລິການອື່ນໆ. ນັ້ນແມ່ນ, ຂະຫນາດຂອງຄໍາຮ້ອງສະຫມັກດັ່ງກ່າວບໍ່ໄດ້ຂຶ້ນກັບຈໍານວນຂອງແກນທີ່ມີຢູ່, ແຕ່ຢູ່ໃນຈໍານວນຄໍາຮ້ອງຂໍພ້ອມໆກັນ. ນອກຈາກນັ້ນ, ນີ້ຫມາຍຄວາມວ່າໂຄຕ້າຫຼືຂໍ້ຈໍາກັດໃນ Kubernetes ກ່ຽວກັບຈໍານວນແກນຈະບໍ່ມີປະໂຫຍດຫຼາຍຢູ່ທີ່ນີ້, ແລະບັນຫາຈະສິ້ນສຸດລົງໃນທີ່ສຸດ.

ຄວາມຈຳໝົດ

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

ໂຄຕ້າ ແລະຂໍ້ຈຳກັດ

Java 11 ແນະນຳການຮອງຮັບໂຄຕ້າ CPU (ເຊັ່ນ PreferContainerQuotaForCPUCount). Kubernetes ຍັງສະຫນອງການສະຫນັບສະຫນູນສໍາລັບຂໍ້ຈໍາກັດແລະໂຄຕ້າ. ແມ່ນແລ້ວ, ທັງຫມົດນີ້ມີຄວາມຫມາຍ, ແຕ່ຖ້າຄໍາຮ້ອງສະຫມັກອີກເທື່ອຫນຶ່ງເກີນໂຄຕ້າທີ່ຖືກຈັດສັນ, ພວກເຮົາອີກເທື່ອຫນຶ່ງສິ້ນສຸດລົງດ້ວຍຂະຫນາດ - ເຊັ່ນດຽວກັນກັບຄໍາຮ້ອງສະຫມັກ Java ແບບດັ້ງເດີມ - ກໍານົດໂດຍຈໍານວນຂອງແກນແລະການຈັດສັນຂອງ thread ແຍກຕ່າງຫາກສໍາລັບແຕ່ລະຄົນ. ການຮ້ອງຂໍ, ຫຼັງຈາກນັ້ນມີຄວາມຮູ້ສຶກພຽງເລັກນ້ອຍໃນທັງຫມົດນີ້.
ນອກຈາກນັ້ນ, ຖ້າທ່ານໃຊ້ໂຄຕ້າແລະຂອບເຂດຈໍາກັດຫຼືຫນ້າທີ່ຂະຫນາດອອກຂອງແພລະຕະຟອມທີ່ຕິດພັນກັບ Kubernetes, ບັນຫາກໍ່ບໍ່ໄດ້ແກ້ໄຂຕົວມັນເອງ. ພວກ​ເຮົາ​ພຽງ​ແຕ່​ໃຊ້​ຈ່າຍ​ຊັບ​ພະ​ຍາ​ກອນ​ເພີ່ມ​ເຕີມ​ກ່ຽວ​ກັບ​ການ​ແກ້​ໄຂ​ບັນ​ຫາ​ຕົ້ນ​ສະ​ບັບ​ຫຼື​ສິ້ນ​ສຸດ​ການ overspending. ແລະຖ້າມັນເປັນລະບົບການໂຫຼດສູງຢູ່ໃນສາທາລະນະສາທາລະນະ, ພວກເຮົາເກືອບແນ່ນອນທີ່ຈະໃຊ້ຊັບພະຍາກອນຫຼາຍກວ່າທີ່ພວກເຮົາຕ້ອງການແທ້ໆ.

ແລະສິ່ງທີ່ຕ້ອງເຮັດກັບສິ່ງທັງຫມົດນີ້?

ເວົ້າງ່າຍໆ, ໃຫ້ໃຊ້ຫ້ອງສະໝຸດ I/O ແບບອະຊິງໂຄຣນັສ ແລະ ບໍ່ປິດກັ້ນ ແລະກອບວຽກເຊັ່ນ Netty, Vert.x ຫຼື Akka. ພວກມັນແມ່ນ ເໝາະ ສົມກວ່າຫຼາຍທີ່ຈະເຮັດວຽກໃນຕູ້ຄອນເທນເນີເນື່ອງຈາກລັກສະນະປະຕິກິລິຍາຂອງມັນ. ຂໍຂອບໃຈກັບ I/O ທີ່ບໍ່ປິດກັ້ນ, ກະທູ້ດຽວກັນສາມາດປະມວນຜົນຫຼາຍຄໍາຮ້ອງຂໍພ້ອມກັນ. ໃນຂະນະທີ່ຄໍາຮ້ອງຂໍຫນຶ່ງກໍາລັງລໍຖ້າຜົນ I/O, ການປະມວນຜົນກະທູ້ມັນຖືກປ່ອຍອອກມາແລະຖືກປະຕິບັດໂດຍຄໍາຮ້ອງຂໍອື່ນ. ແລະເມື່ອຜົນໄດ້ຮັບ I/O ມາຮອດສຸດທ້າຍ, ການປະມວນຜົນຄໍາຮ້ອງຂໍທໍາອິດຍັງສືບຕໍ່. ໂດຍການດໍາເນີນການ interleaved ຂອງການຮ້ອງຂໍພາຍໃນກະທູ້ດຽວກັນ, ທ່ານສາມາດຫຼຸດຜ່ອນຈໍານວນຂອງ threads ແລະຫຼຸດຜ່ອນການບໍລິໂພກຊັບພະຍາກອນສໍາລັບການຮ້ອງຂໍການປະມວນຜົນ.

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

ແນວໃດ, ທັງຫມົດ?

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

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

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

1. ໃຊ້ຊັບພະຍາກອນຢ່າງມີປະສິດທິພາບໃນພື້ນທີ່ໂຫຼດທີ່ສຸດຂອງລະບົບຊອບແວ;
2. ໃຊ້ລະຫັດຮູບແບບທີ່ງ່າຍກວ່າໃນສ່ວນທີ່ຍັງເຫຼືອຂອງມັນ.

ແນະນຳ Quarkus

ຕົວຈິງແລ້ວ, ນີ້ແມ່ນຄວາມສໍາຄັນຂອງ Quarkus - ເພື່ອສົມທົບຮູບແບບ reactive ແລະ imperative ພາຍໃນສະພາບແວດລ້ອມ runtime ດຽວ.

Quarkus ແມ່ນອີງໃສ່ Vert.x ແລະ Netty, ມີຂອບເຂດຂອງກອບການປະຕິກິລິຍາ ແລະສ່ວນຂະຫຍາຍຢູ່ດ້ານເທິງເພື່ອຊ່ວຍຜູ້ພັດທະນາ. Quarkus ຖືກອອກແບບມາສໍາລັບການກໍ່ສ້າງບໍ່ພຽງແຕ່ HTTP microservices, ແຕ່ຍັງສະຖາປັດຕະຍະກໍາທີ່ຂັບເຄື່ອນໂດຍເຫດການ. ເນື່ອງຈາກລັກສະນະປະຕິກິລິຍາຂອງມັນ, ມັນເຮັດວຽກຢ່າງມີປະສິດທິພາບກັບລະບົບການສົ່ງຂໍ້ຄວາມ (Apache Kafka, AMQP, ແລະອື່ນໆ).

trick ແມ່ນວິທີການນໍາໃຊ້ເຄື່ອງຈັກ reactive ດຽວກັນສໍາລັບລະຫັດ imperative ແລະ reactive.

Quarkus ເຮັດອັນນີ້ຢ່າງສະຫຼາດ. ທາງເລືອກລະຫວ່າງ imperative ແລະ reactive ແມ່ນຈະແຈ້ງ - ໃຊ້ kernel reactive ສໍາລັບທັງສອງ. ສິ່ງທີ່ມັນຊ່ວຍໄດ້ຢ່າງແທ້ຈິງແມ່ນໄວ, ລະຫັດບໍ່ຖືກບລັອກທີ່ຈັດການກັບເກືອບທຸກສິ່ງທີ່ຜ່ານກະທູ້ event-loop, aka thread IO. ແຕ່ຖ້າທ່ານມີຄໍາຮ້ອງສະຫມັກ REST ຄລາສສິກຫຼືລູກຄ້າຂ້າງຄຽງ, Quarkus ມີຮູບແບບການຂຽນໂປລແກລມທີ່ຈໍາເປັນຢູ່ໃນຄວາມພ້ອມ. ຕົວຢ່າງ, ການສະຫນັບສະຫນູນ HTTP ໃນ Quarkus ແມ່ນອີງໃສ່ການນໍາໃຊ້ເຄື່ອງຈັກທີ່ບໍ່ມີການຂັດຂວາງແລະປະຕິກິລິຍາ (Eclipse Vert.x ແລະ Netty). ການຮ້ອງຂໍ HTTP ທັງຫມົດທີ່ໄດ້ຮັບໂດຍຄໍາຮ້ອງສະຫມັກຂອງທ່ານທໍາອິດແມ່ນຜ່ານ loop ເຫດການ (IO Thread) ແລະຫຼັງຈາກນັ້ນຖືກສົ່ງໄປຫາສ່ວນຂອງລະຫັດທີ່ຈັດການຄໍາຮ້ອງຂໍ. ອີງຕາມຈຸດຫມາຍປາຍທາງ, ລະຫັດການຄຸ້ມຄອງການຮ້ອງຂໍສາມາດຖືກເອີ້ນພາຍໃນກະທູ້ແຍກຕ່າງຫາກ (ອັນທີ່ເອີ້ນວ່າ thread worker, ໃຊ້ໃນກໍລະນີຂອງ servlets ແລະ Jax-RS) ຫຼືໃຊ້ thread I/O ແຫຼ່ງ (ເສັ້ນທາງ reactive).

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

ຢູ່ໃນເວັບໄຊທ໌ Quarkus.io ນີ້ແມ່ນບົດຮຽນທີ່ດີບາງຢ່າງເພື່ອຊ່ວຍໃຫ້ທ່ານເລີ່ມຕົ້ນກັບ Quarkus:

• ການໃຊ້ Reactive Routes
• ລູກຄ້າ SQL ທີ່ມີປະຕິກິລິຍາ
• ການນໍາໃຊ້ Apache Kafka ດ້ວຍການສົ່ງຂໍ້ຄວາມແບບປະຕິກິລິຍາ
• ການ​ນໍາ​ໃຊ້ AMQP ກັບ Reactive Messaging
• ໃຊ້ Vertx API

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

ຊັບພະຍາກອນທີ່ມີປະໂຫຍດ

• 4 ເຫດຜົນເພື່ອພະຍາຍາມ Quarkus
• ເວັບໄຊທ໌ Quarkus project - quarkus.io
• ໂຄງການ Quarkus ໃນ GitHub - github.com/quarkusio/quarkus
• ໂຄງ​ການ Quarkus Twitter – twitter.com/QuarkusIO
• ການສົນທະນາໂຄງການ Quarkus - quarkusio.zulipchat.com
• ເວທີສົນທະນາໂຄງການ Quarkus - groups.google.com/forum/#!forum/quarkus-dev

10 ບົດຮຽນວິດີໂອກ່ຽວກັບ Quarkus ເພື່ອໃຫ້ຄຸ້ນເຄີຍກັບຫົວຂໍ້

ດັ່ງທີ່ພວກເຂົາເວົ້າຢູ່ໃນເວັບໄຊທ໌ Quarkus.io, ໂຄກ - ນີ້ Kubernetes-oriented Java stack, ປັບແຕ່ງສໍາລັບ GraalVM ແລະ OpenJDK HotSpot ແລະປະກອບມາຈາກຫ້ອງສະຫມຸດແລະມາດຕະຖານ Java ທີ່ດີທີ່ສຸດ.

ເພື່ອຊ່ວຍໃຫ້ທ່ານເຂົ້າໃຈຫົວຂໍ້, ພວກເຮົາໄດ້ເລືອກ 10 ບົດສອນວິດີໂອທີ່ກວມເອົາລັກສະນະຕ່າງໆຂອງ Quarkus ແລະຕົວຢ່າງຂອງການນໍາໃຊ້ຂອງມັນ:

1. ແນະນຳ Quarkus: ກອບວຽກ Java ລຸ້ນຕໍ່ໄປສຳລັບ Kubernetes

ໂດຍ Thomas Qvarnstrom ແລະ Jason Greene
ເປົ້າຫມາຍຂອງໂຄງການ Quarkus ແມ່ນເພື່ອສ້າງແພລະຕະຟອມ Java ສໍາລັບ Kubernetes ແລະສະພາບແວດລ້ອມເຊີຟເວີ, ແລະການລວມຕົວແບບການຂຽນໂປລແກລມ reactive ແລະ imperative ເຂົ້າໄປໃນສະພາບແວດລ້ອມ runtime ດຽວເພື່ອໃຫ້ຜູ້ພັດທະນາສາມາດປ່ຽນແປງວິທີການຂອງພວກເຂົາໄດ້ຢ່າງຍືດຫຍຸ່ນໃນເວລາທີ່ເຮັດວຽກກັບສະຖາປັດຕະຍະກໍາຄໍາຮ້ອງສະຫມັກທີ່ແຈກຢາຍຢ່າງກວ້າງຂວາງ. ຊອກຫາຂໍ້ມູນເພີ່ມເຕີມຢູ່ໃນບົດບັນຍາຍເບື້ອງຕົ້ນຂ້າງລຸ່ມນີ້.

2. Quarkus: Superfast Subatomic Java

ໂດຍ: Burr Sutter
ວິດີໂອສອນນີ້ຈາກ DevNation Live ສະແດງໃຫ້ເຫັນວິທີການໃຊ້ Quarkus ເພື່ອເພີ່ມປະສິດທິພາບຂອງແອັບພລິເຄຊັນ Java, APIs, microservices ແລະ serverless functions ໃນສະພາບແວດລ້ອມ Kubernetes/OpenShift, ເຮັດໃຫ້ພວກມັນນ້ອຍລົງ, ໄວກວ່າ, ແລະສາມາດຂະຫຍາຍໄດ້ຫຼາຍຂຶ້ນ.

3. Quarkus ແລະ GraalVM: ເລັ່ງ Hibernate ໄປສູ່ຄວາມໄວສູງສຸດ ແລະຫຍໍ້ມັນລົງເປັນຂະໜາດຍ່ອຍ.

ຜູ້ຂຽນ: Sanne Grinovero
ຈາກການນໍາສະເຫນີທ່ານຈະໄດ້ຮຽນຮູ້ວ່າ Quarkus ມາເປັນແນວໃດ, ມັນເຮັດວຽກແນວໃດ, ແລະວິທີທີ່ມັນຊ່ວຍໃຫ້ທ່ານສ້າງຫ້ອງສະຫມຸດທີ່ສັບສົນ, ເຊັ່ນ Hibernate ORM, ເຫມາະສົມກັບຮູບພາບ GraalVM ພື້ນເມືອງ.

4. ຮຽນຮູ້ທີ່ຈະພັດທະນາແອັບພລິເຄຊັນທີ່ບໍ່ມີເຄື່ອງແມ່ຂ່າຍ

ຜູ້ຂຽນ: Martin Luther
ວິດີໂອຂ້າງລຸ່ມນີ້ສະແດງໃຫ້ເຫັນວິທີການສ້າງຄໍາຮ້ອງສະຫມັກ Java ແບບງ່າຍດາຍໂດຍໃຊ້ Quarkus ແລະນໍາໃຊ້ມັນເປັນຄໍາຮ້ອງສະຫມັກທີ່ບໍ່ມີເຄື່ອງແມ່ຂ່າຍໃນ Knative.

5. Quarkus: ມີຄວາມມ່ວນ coding

ຜູ້ຂຽນ: Edson Yanaga
ຄູ່ມືວິດີໂອໃນການສ້າງໂຄງການ Quarkus ທໍາອິດຂອງທ່ານ, ຊ່ວຍໃຫ້ທ່ານເຂົ້າໃຈວ່າເປັນຫຍັງ Quarkus ຈຶ່ງຊະນະໃຈຂອງນັກພັດທະນາ.

6. Java ແລະ containers - ອະນາຄົດຂອງພວກເຂົາຮ່ວມກັນຈະເປັນແນວໃດ

ປະກາດໂດຍ Mark Little
ການນໍາສະເຫນີນີ້ແນະນໍາປະຫວັດສາດຂອງ Java ແລະອະທິບາຍວ່າເປັນຫຍັງ Quarkus ເປັນອະນາຄົດຂອງ Java.

7. Quarkus: Superfast Subatomic Java

ຜູ້ຂຽນ: Dimitris Andreadis
ພາບລວມຂອງຂໍ້ດີຂອງ Quarkus ທີ່ໄດ້ຮັບການຍອມຮັບຈາກນັກພັດທະນາ: ຄວາມງ່າຍດາຍ, ຄວາມໄວສູງສຸດ, ຫ້ອງສະຫມຸດແລະມາດຕະຖານທີ່ດີທີ່ສຸດ.

8. ລະບົບລູກສອນໄຟ Quarkus ແລະ subatomic

ຜູ້ຂຽນ: Clement Escoffier
ໂດຍຜ່ານການເຊື່ອມໂຍງກັບ GraalVM, Quarkus ສະຫນອງປະສົບການການພັດທະນາທີ່ໄວທີ່ສຸດແລະສະພາບແວດລ້ອມການແລ່ນ subatomic. ຜູ້ຂຽນເວົ້າກ່ຽວກັບດ້ານ reactive ຂອງ Quarkus ແລະວິທີການນໍາໃຊ້ມັນເພື່ອສ້າງຄໍາຮ້ອງສະຫມັກ reactive ແລະ streaming.

9. Quarkus ແລະການພັດທະນາຄໍາຮ້ອງສະຫມັກຢ່າງໄວວາໃນ Eclipse MicroProfile

ຜູ້ຂຽນ: John Clingan
ໂດຍການລວມເອົາ Eclipse MicroProfile ແລະ Quarkus, ນັກພັດທະນາສາມາດສ້າງແອັບພລິເຄຊັນ MicroProfile ທີ່ບັນຈຸບັນຈຸທີ່ມີຄຸນສົມບັດເຕັມທີ່ທີ່ຈະເປີດຕົວໃນຫຼາຍສິບມິນລິວິນາທີ. ວິດີໂອໄດ້ເຂົ້າໄປໃນລາຍລະອຽດກ່ຽວກັບວິທີການລະຫັດຄໍາຮ້ອງສະຫມັກ MicroProfile ບັນຈຸສໍາລັບການນໍາໃຊ້ໃນເວທີ Kubernetes.

10. Java, "Turbo" ສະບັບ

ຜູ້ຂຽນ: Marcus Biel
ຜູ້ຂຽນສະແດງໃຫ້ເຫັນວິທີການນໍາໃຊ້ Quarkus ເພື່ອສ້າງຖັງ Java ຂະຫນາດນ້ອຍ, ໄວທີ່ສຸດທີ່ສາມາດເຮັດໃຫ້ການບຸກທະລຸທີ່ແທ້ຈິງ, ໂດຍສະເພາະໃນສະພາບແວດລ້ອມທີ່ບໍ່ມີເຄື່ອງແມ່ຂ່າຍ.

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