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

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

ຍຸດທະສາດຄວາມຢືດຢຸ່ນທົ່ວໄປທີ່ສຸດລວມມີ bulkhead, cache, fallback, retry, ແລະ circuit breaker. ໃນບົດຄວາມນີ້, ຂ້າພະເຈົ້າຈະປຶກສາຫາລືໃຫ້ເຂົາເຈົ້າໃນລາຍລະອຽດເພີ່ມເຕີມ, ມີຕົວຢ່າງຂອງບັນຫາທີ່ເຂົາເຈົ້າສາມາດຊ່ວຍແກ້ໄຂ.

Bulkhead

ໃຫ້ພວກເຮົາພິຈາລະນາການຕັ້ງຄ່າຂ້າງເທິງ. ພວກເຮົາມີແອັບພລິເຄຊັນທົ່ວໄປຫຼາຍທີ່ມີ backends ຫຼາຍອັນຢູ່ຫລັງພວກເຮົາເພື່ອເອົາຂໍ້ມູນບາງຢ່າງຈາກ. ມີລູກຄ້າ HTTP ຫຼາຍອັນທີ່ເຊື່ອມຕໍ່ກັບ backends ເຫຼົ່ານີ້. ມັນ turns ໃຫ້​ເຫັນ​ວ່າ​ທັງ​ຫມົດ​ຂອງ​ເຂົາ​ເຈົ້າ​ແບ່ງ​ປັນ​ສະ​ນຸກ​ເກີ​ການ​ເຊື່ອມ​ຕໍ່​ດຽວ​ກັນ​! ແລະຊັບພະຍາກອນອື່ນໆເຊັ່ນ CPU ແລະ RAM.

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

ພວກເຮົາສາມາດໃຊ້ຮູບແບບ Bulkhead ເພື່ອແກ້ໄຂບັນຫານີ້ໄດ້ແນວໃດ?

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

1. Isolating Connection Pools ພວກເຮົາສາມາດສ້າງກຸ່ມເຊື່ອມຕໍ່ແຍກຕ່າງຫາກສໍາລັບແຕ່ລະ backend (backend1, backend2, backend3). ນີ້ຮັບປະກັນວ່າຖ້າ backend1 ກໍາລັງປະສົບກັບເວລາຕອບສະຫນອງສູງຫຼືຄວາມລົ້ມເຫລວ, ກຸ່ມການເຊື່ອມຕໍ່ຂອງມັນຈະຫມົດໄປເປັນເອກະລາດ, ເຊິ່ງເຮັດໃຫ້ການເຊື່ອມຕໍ່ສໍາລັບ backend2 ແລະ backend3 ບໍ່ໄດ້ຮັບຜົນກະທົບ. ການໂດດດ່ຽວນີ້ອະນຸຍາດໃຫ້ backends ທີ່ມີສຸຂະພາບດີສາມາດສືບຕໍ່ດໍາເນີນການຮ້ອງຂໍຕາມປົກກະຕິ.
2. ການຈໍາກັດຊັບພະຍາກອນສໍາລັບກິດຈະກໍາພື້ນຫລັງໂດຍການນໍາໃຊ້ Bulkheads, ພວກເຮົາສາມາດຈັດສັນຊັບພະຍາກອນສະເພາະສໍາລັບກິດຈະກໍາພື້ນຖານ, ເຊັ່ນ: batch processing ຫຼືວຽກງານທີ່ກໍານົດໄວ້. ນີ້ປ້ອງກັນບໍ່ໃຫ້ກິດຈະກໍາເຫຼົ່ານີ້ບໍລິໂພກຊັບພະຍາກອນທີ່ຈໍາເປັນສໍາລັບການປະຕິບັດງານໃນເວລາທີ່ແທ້ຈິງ. ຕົວຢ່າງ, ພວກເຮົາສາມາດຈໍາກັດຈໍານວນຂອງ threads ຫຼືການນໍາໃຊ້ CPU ທີ່ອຸທິດຕົນເພື່ອວຽກງານພື້ນຫລັງ, ຮັບປະກັນວ່າຊັບພະຍາກອນພຽງພໍຍັງຄົງມີຢູ່ສໍາລັບການຈັດການຄໍາຮ້ອງຂໍທີ່ເຂົ້າມາ.
3. ການກໍານົດຂໍ້ຈໍາກັດກ່ຽວກັບການຮ້ອງຂໍຂາເຂົ້າ Bulkheads ຍັງສາມາດຖືກນໍາໃຊ້ເພື່ອຈໍາກັດຈໍານວນຂອງການຮ້ອງຂໍທີ່ເຂົ້າມາໃນພາກສ່ວນທີ່ແຕກຕ່າງກັນຂອງຄໍາຮ້ອງສະຫມັກ. ຕົວຢ່າງເຊັ່ນ, ພວກເຮົາສາມາດກໍານົດຂອບເຂດຈໍາກັດສູງສຸດກ່ຽວກັບຈໍານວນການຮ້ອງຂໍທີ່ສາມາດດໍາເນີນການພ້ອມກັນສໍາລັບແຕ່ລະບໍລິການຕົ້ນນ້ໍາ. ນີ້ປ້ອງກັນບໍ່ໃຫ້ backend ໃດດຽວຈາກການ overwhelming ລະບົບແລະຮັບປະກັນວ່າ backends ອື່ນໆສາມາດສືບຕໍ່ເຮັດວຽກເຖິງແມ່ນວ່າຫນຶ່ງແມ່ນຢູ່ພາຍໃຕ້ການໂຫຼດຫນັກ.

ເຈັບ

ໃຫ້ສົມມຸດວ່າລະບົບ backend ຂອງພວກເຮົາມີຄວາມເປັນໄປໄດ້ຕໍ່າທີ່ຈະພົບຄວາມຜິດພາດສ່ວນບຸກຄົນ. ຢ່າງໃດກໍຕາມ, ເມື່ອການດໍາເນີນງານກ່ຽວຂ້ອງກັບການສອບຖາມ backends ທັງຫມົດເຫຼົ່ານີ້ໃນຂະຫນານ, ແຕ່ລະຄົນສາມາດສົ່ງຄືນຄວາມຜິດພາດເປັນເອກະລາດ. ເນື່ອງຈາກວ່າຄວາມຜິດພາດເຫຼົ່ານີ້ເກີດຂຶ້ນຢ່າງເປັນເອກະລາດ, ຄວາມເປັນໄປໄດ້ໂດຍລວມຂອງຄວາມຜິດພາດໃນຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາແມ່ນສູງກວ່າຄວາມເປັນໄປໄດ້ຂອງຄວາມຜິດພາດຂອງ backend ໃດດຽວ. ຄວາມເປັນໄປໄດ້ຂອງຄວາມຜິດພາດສະສົມສາມາດຄິດໄລ່ໄດ້ໂດຍໃຊ້ສູດ P_total=1−(1−p)^n, ເຊິ່ງ n ແມ່ນຈຳນວນຂອງລະບົບ backend.

ຕົວຢ່າງ, ຖ້າພວກເຮົາມີສິບ backends, ແຕ່ລະຄົນມີຄວາມເປັນໄປໄດ້ຂອງຄວາມຜິດພາດຂອງ p = 0.001 (ກົງກັນກັບ SLA ຂອງ 99.9%), ຄວາມເປັນໄປໄດ້ຂອງຄວາມຜິດພາດແມ່ນ:

P_total=1−(1−0.001)^10=0.009955

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

ພວກເຮົາສາມາດແກ້ໄຂມັນໄດ້ແນວໃດກັບ cache ໃນຫນ່ວຍຄວາມຈໍາ

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

ແຄດໃນໜ່ວຍຄວາມຈຳ: ແຄສສ່ວນຕົວ

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

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

ແຄດໃນໜ່ວຍຄວາມຈຳ: ການຈຳລອງຂໍ້ມູນທ້ອງຖິ່ນ

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

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

reloadable config

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

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

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

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

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

ຜົນຕອບແທນ

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

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

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

ລອງໃໝ່

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

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

ຕົວຕັດວົງຈອນ

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

ຂໍໃຫ້ຈິນຕະນາການຫນຶ່ງໃນ backends ຂອງພວກເຮົາປະສົບກັບຄວາມລົ້ມເຫລວ. ໃນສະຖານະການດັ່ງກ່າວ, ການລິເລີ່ມການພະຍາຍາມກັບຄືນໄປບ່ອນທີ່ລົ້ມເຫລວອາດຈະເຮັດໃຫ້ປະລິມານການຈະລາຈອນເພີ່ມຂຶ້ນຢ່າງຫຼວງຫຼາຍ. ການຈະລາຈອນທີ່ເພີ່ມຂຶ້ນຢ່າງກະທັນຫັນນີ້ອາດຈະ overwhelm backend, exacerbating ຄວາມລົ້ມເຫຼວແລະອາດຈະເຮັດໃຫ້ເກີດຜົນກະທົບເປັນ cascade ໃນທົ່ວລະບົບ.

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

ຫໍ່ຂຶ້ນ

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