"ຍ່າງຢູ່ໃນເກີບຂອງຂ້ອຍ" - ລໍຖ້າ, ພວກເຂົາຖືກຫມາຍບໍ?

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

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

HighLoad ທີ່ແທ້ຈິງ

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

ທີມ ມ

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

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

ເນື່ອງຈາກການແຜ່ລະບາດຂອງໂຣກ coronavirus, ພວກເຮົາໄດ້ໂອນທີມງານທັງຫມົດໄປເຮັດວຽກຫ່າງໄກສອກຫຼີກ; ການມີເຄື່ອງມືທັງຫມົດສໍາລັບການຄຸ້ມຄອງການພັດທະນາ, ຂະບວນການເຮັດວຽກທີ່ສ້າງຂຶ້ນໃນ Jira ແລະ GitLab ເຮັດໃຫ້ສາມາດຜ່ານຂັ້ນຕອນນີ້ໄດ້ຢ່າງງ່າຍດາຍ. ຫລາຍເດືອນທີ່ໃຊ້ເວລາຫ່າງໄກສອກຫຼີກໄດ້ສະແດງໃຫ້ເຫັນວ່າຜົນຜະລິດຂອງທີມງານບໍ່ໄດ້ທົນທຸກຜົນ; ສໍາລັບຫຼາຍໆຄົນ, ຄວາມສະດວກສະບາຍໃນການເຮັດວຽກເພີ່ມຂຶ້ນ, ສິ່ງດຽວທີ່ຂາດຫາຍໄປແມ່ນການສື່ສານສົດ.

ກອງ​ປະ​ຊຸມ​ທີມ​ງານ​ທາງ​ໄກ​

ກອງ​ປະ​ຊຸມ​ໃນ​ລະ​ຫວ່າງ​ການ​ເຮັດ​ວຽກ​ຫ່າງ​ໄກ​ສອກ​ຫຼີກ​

stack ເຕັກໂນໂລຊີຂອງການແກ້ໄຂ

ຄັງເກັບມ້ຽນມາດຕະຖານແລະເຄື່ອງມື CI / CD ສໍາລັບ X5 ແມ່ນ GitLab. ພວກເຮົາໃຊ້ມັນສໍາລັບການເກັບຮັກສາລະຫັດ, ການທົດສອບຢ່າງຕໍ່ເນື່ອງ, ແລະການນໍາໃຊ້ເພື່ອທົດສອບແລະການຜະລິດເຄື່ອງແມ່ຂ່າຍ. ພວກເຮົາຍັງໃຊ້ການປະຕິບັດຂອງການກວດສອບລະຫັດ, ໃນເວລາທີ່ຢ່າງຫນ້ອຍ 2 ເພື່ອນຮ່ວມງານຈໍາເປັນຕ້ອງໄດ້ອະນຸມັດການປ່ຽນແປງທີ່ເຮັດໂດຍນັກພັດທະນາກັບລະຫັດ. ເຄື່ອງວິເຄາະລະຫັດຄົງທີ່ SonarQube ແລະ JaCoCo ຊ່ວຍພວກເຮົາຮັກສາລະຫັດຂອງພວກເຮົາໃຫ້ສະອາດແລະຮັບປະກັນລະດັບການຄຸ້ມຄອງການທົດສອບຫນ່ວຍທີ່ຈໍາເປັນ. ການປ່ຽນແປງລະຫັດທັງຫມົດຕ້ອງຜ່ານການກວດສອບເຫຼົ່ານີ້. ສະຄຣິບທົດສອບທັງໝົດທີ່ເຮັດວຽກດ້ວຍຕົນເອງແມ່ນອັດຕະໂນມັດຕໍ່ມາ.

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

ວຽກງານ 1. ຄວາມຕ້ອງການສໍາລັບການຂະຫຍາຍອອກຕາມລວງນອນຂອງລະບົບ

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

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

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

ການບໍລິການຈຸນລະພາກທັງໝົດຖືກນຳໃຊ້ຢູ່ໃນກຸ່ມ OpenShift, ເຊິ່ງສາມາດແກ້ໄຂບັນຫາການຂະຫຍາຍແຕ່ລະ microservice ແລະຊ່ວຍໃຫ້ພວກເຮົາບໍ່ໃຊ້ເຄື່ອງມື Service Discovery ຂອງພາກສ່ວນທີສາມ.

ວຽກງານ 2. ຄວາມຕ້ອງການທີ່ຈະຮັກສາການໂຫຼດສູງແລະການແລກປ່ຽນຂໍ້ມູນຫຼາຍຫຼາຍລະຫວ່າງການບໍລິການເວທີ: ໃນໄລຍະການເປີດຕົວໂຄງການຢ່າງດຽວ, ປະມານ 600 ການດໍາເນີນງານຕໍ່ວິນາທີແມ່ນປະຕິບັດ. ພວກເຮົາຄາດວ່າມູນຄ່ານີ້ຈະເພີ່ມຂຶ້ນເປັນ 5000 ops/sec ເນື່ອງຈາກຮ້ານຂາຍຍ່ອຍເຊື່ອມຕໍ່ກັບເວທີຂອງພວກເຮົາ.

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

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

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

ເພື່ອແກ້ໄຂບັນຫາທີສາມ, ຖານຂໍ້ມູນ NoSQL MongoDB ໄດ້ຖືກເລືອກ. ພວກເຮົາໄດ້ສ້າງ shard ຂອງ 5 nodes ແລະແຕ່ລະ node ມີ Replica Set ຂອງ 3 ເຄື່ອງແມ່ຂ່າຍ. ນີ້ຊ່ວຍໃຫ້ທ່ານສາມາດປັບຂະຫນາດລະບົບຕາມແນວນອນ, ເພີ່ມເຄື່ອງແມ່ຂ່າຍໃຫມ່ໃນກຸ່ມ, ແລະຮັບປະກັນຄວາມທົນທານຕໍ່ຄວາມຜິດຂອງມັນ. ໃນທີ່ນີ້ພວກເຮົາພົບບັນຫາອີກຢ່າງຫນຶ່ງ - ການຮັບປະກັນການເຮັດທຸລະກໍາໃນກຸ່ມ mongo, ໂດຍຄໍານຶງເຖິງການນໍາໃຊ້ microservices ທີ່ສາມາດປັບຂະຫນາດຕາມລວງນອນ. ຕົວຢ່າງ, ຫນຶ່ງໃນວຽກງານຂອງລະບົບຂອງພວກເຮົາແມ່ນເພື່ອກໍານົດຄວາມພະຍາຍາມທີ່ຈະຂາຍຄືນຜະລິດຕະພັນທີ່ມີລະຫັດປ້າຍຊື່ດຽວກັນ. ຢູ່ທີ່ນີ້, ການຊ້ອນກັນປະກົດຂຶ້ນດ້ວຍການສະແກນທີ່ຜິດພາດ ຫຼືການດຳເນີນການທີ່ຜິດພາດໂດຍພະນັກງານເກັບເງິນ. ພວກເຮົາພົບວ່າການຊໍ້າກັນດັ່ງກ່າວສາມາດເກີດຂຶ້ນໄດ້ທັງພາຍໃນໜຶ່ງຊຸດ Kafka ທີ່ຖືກປະມວນຜົນ, ແລະພາຍໃນສອງຊຸດຈະຖືກປະມວນຜົນຂະໜານກັນ. ດັ່ງນັ້ນ, ການກວດສອບການຊ້ໍາກັນໂດຍການສອບຖາມຖານຂໍ້ມູນບໍ່ໄດ້ໃຫ້ສິ່ງໃດ. ສໍາລັບແຕ່ລະບໍລິການຈຸລະພາກ, ພວກເຮົາໄດ້ແກ້ໄຂບັນຫາແຍກຕ່າງຫາກໂດຍອີງໃສ່ເຫດຜົນທາງທຸລະກິດຂອງການບໍລິການນີ້. ຕົວຢ່າງ, ສໍາລັບການກວດສອບ, ພວກເຮົາໄດ້ເພີ່ມການກວດສອບພາຍໃນ batch ແລະການປຸງແຕ່ງແຍກຕ່າງຫາກສໍາລັບຮູບລັກສະນະຂອງຊໍ້າຊ້ອນໃນເວລາທີ່ໃສ່.

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

ວຽກ​ງານ​ທີ 4: ການ​ປະ​ມວນ​ຜົນ ແລະ ການ​ຕິດ​ຕາມ​ກວດ​ກາ​ແຖວ:

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

ເພື່ອປະຕິບັດໂຄງການດັ່ງກ່າວ, ພວກເຮົາຕ້ອງການສິ່ງຕໍ່ໄປນີ້: ເພື່ອປະສົມປະສານການແກ້ໄຂນີ້ກັບ Spring ແລະຫຼີກເວັ້ນການຊ້ໍາກັນຂອງລະຫັດ. ໃນຂະນະທີ່ທ່ອງເວັບ, ພວກເຮົາໄດ້ພົບການແກ້ໄຂທີ່ຄ້າຍຄືກັນໂດຍອີງໃສ່ Spring BeanPostProccessor, ແຕ່ເບິ່ງຄືວ່າມັນເປັນເລື່ອງທີ່ບໍ່ຈໍາເປັນສໍາລັບພວກເຮົາ. ທີມງານຂອງພວກເຮົາໄດ້ເຮັດການແກ້ໄຂທີ່ງ່າຍດາຍກວ່າທີ່ຊ່ວຍໃຫ້ພວກເຮົາປະສົມປະສານເຂົ້າໃນວົງຈອນ Spring ເພື່ອສ້າງຜູ້ບໍລິໂພກແລະເພີ່ມ Retry Consumers. ພວກ​ເຮົາ​ໄດ້​ສະ​ເຫນີ​ຕົ້ນ​ແບບ​ຂອງ​ການ​ແກ້​ໄຂ​ຂອງ​ພວກ​ເຮົາ​ກັບ​ທີມ​ງານ Spring​, ທ່ານ​ສາ​ມາດ​ເບິ່ງ​ໄດ້​ ທີ່ນີ້. ຈໍານວນ Retry Consumers ແລະຈໍານວນຄວາມພະຍາຍາມສໍາລັບຜູ້ບໍລິໂພກແຕ່ລະຄົນຖືກຕັ້ງຄ່າຜ່ານພາລາມິເຕີ, ຂຶ້ນກັບຄວາມຕ້ອງການຂອງຂະບວນການທຸລະກິດ, ແລະສໍາລັບທຸກສິ່ງທຸກຢ່າງທີ່ຈະເຮັດວຽກ, ທັງຫມົດທີ່ຍັງເຫຼືອແມ່ນການເພີ່ມຄໍາບັນຍາຍ org.springframework.kafka.annotation.KafkaListener , ເຊິ່ງຄຸ້ນເຄີຍກັບນັກພັດທະນາ Spring ທັງຫມົດ.

ຖ້າຂໍ້ຄວາມບໍ່ສາມາດດໍາເນີນການໄດ້ຫຼັງຈາກຄວາມພະຍາຍາມທັງຫມົດ, ມັນຈະໄປຫາ DLT (ຫົວຂໍ້ຈົດຫມາຍຕາຍ) ໂດຍໃຊ້ Spring DeadLetterPublishingRecoverer. ຕາມການຮ້ອງຂໍການສະຫນັບສະຫນູນ, ພວກເຮົາໄດ້ຂະຫຍາຍການເຮັດວຽກນີ້ແລະສ້າງບໍລິການແຍກຕ່າງຫາກທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດເບິ່ງຂໍ້ຄວາມທີ່ລວມຢູ່ໃນ DLT, stackTrace, traceId ແລະຂໍ້ມູນທີ່ເປັນປະໂຫຍດອື່ນໆກ່ຽວກັບພວກມັນ. ນອກຈາກນັ້ນ, ການຕິດຕາມແລະການແຈ້ງເຕືອນໄດ້ຖືກເພີ່ມເຂົ້າໃນຫົວຂໍ້ DLT ທັງຫມົດ, ແລະໃນປັດຈຸບັນ, ໃນຄວາມເປັນຈິງ, ຮູບລັກສະນະຂອງຂໍ້ຄວາມໃນຫົວຂໍ້ DLT ແມ່ນເຫດຜົນທີ່ຈະວິເຄາະແລະແກ້ໄຂຂໍ້ບົກພ່ອງ. ນີ້ແມ່ນສະດວກຫຼາຍ - ໂດຍຊື່ຂອງຫົວຂໍ້, ພວກເຮົາເຂົ້າໃຈທັນທີທັນໃດໃນຂັ້ນຕອນຂອງຂະບວນການທີ່ບັນຫາເກີດຂື້ນ, ເຊິ່ງເລັ່ງການຄົ້ນຫາສາເຫດຂອງມັນຢ່າງຫຼວງຫຼາຍ.

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

ການດໍາເນີນງານຂອງເວທີ

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

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

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

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

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