Hey Habr!

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

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

ການ​ຂະ​ຫຍາຍ​ອອກ​ຕາມ​ລວງ​ນອນ​

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

ຕົວຢ່າງ, ຂ້ອຍຈະເອົາການເກັບຮັກສາໄຟລ໌ຟັງແບບບໍ່ມີຕົວຕົນ, ນັ້ນແມ່ນ, ບາງສ່ວນຂອງ OwnCloud, OneDrive, ແລະອື່ນໆ.

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

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

CQRS

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

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

1. ລູກຄ້າໄດ້ສົ່ງຄໍາຮ້ອງຂໍໄປຫາເຄື່ອງແມ່ຂ່າຍ.
2. ເຊີບເວີເລີ່ມໃຊ້ເວລາປະມວນຜົນດົນ.
3. ເຄື່ອງແມ່ຂ່າຍຕອບສະຫນອງກັບລູກຄ້າດ້ວຍຜົນໄດ້ຮັບ.

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

1. ລູກຄ້າໄດ້ສະໝັກຮັບການອັບເດດ.
2. ລູກຄ້າໄດ້ສົ່ງຄໍາຮ້ອງຂໍໄປຫາເຄື່ອງແມ່ຂ່າຍ.
3. ເຊີບເວີໄດ້ຕອບ "ການຮ້ອງຂໍໄດ້ຮັບການຍອມຮັບ."
4. ເຊີບເວີໄດ້ຕອບສະໜອງດ້ວຍຜົນໄດ້ຮັບຜ່ານຊ່ອງທາງຈາກຈຸດ “1”.

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

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

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

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

ແຫຼ່ງເຫດການ

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

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

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

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

ຄຸນ​ນະ​ສົມ​ບັດ​ທີ່​ສໍາ​ຄັນ​ຂອງ​ວິ​ທີ​ການ​ນີ້​:

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

ຂ້າພະເຈົ້າຂໍເຕືອນທ່ານວ່າພວກເຮົາກໍາລັງພິຈາລະນາກໍລະນີຂອງການເກັບຮັກສາໄຟລ໌ອອນໄລນ໌. ໃນກໍລະນີນີ້, ລະບົບຈະມີລັກສະນະຄ້າຍຄືນີ້:

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

ແລະສໍາລັບສອງຜູ້ໃຊ້ແຜນວາດຈະມີລັກສະນະນີ້ (ການບໍລິການທີ່ມີຈຸດປະສົງສໍາລັບຜູ້ໃຊ້ທີ່ແຕກຕ່າງກັນແມ່ນສະແດງຢູ່ໃນສີທີ່ແຕກຕ່າງກັນ):

ໂບນັດຈາກການປະສົມປະສານດັ່ງກ່າວ:

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

ຢ່າງໃດກໍຕາມ, ຂໍ້ເສຍແມ່ນເຫັນໄດ້ທັນທີ:

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

ດັ່ງທີ່ທ່ານສາມາດເຫັນໄດ້, ແຫຼ່ງເຫດການເຮັດວຽກໄດ້ດີກັບ CQRS. ຍິ່ງໄປກວ່ານັ້ນ, ການປະຕິບັດລະບົບທີ່ມີແຖວທີ່ມີປະສິດທິພາບແລະສະດວກ, ແຕ່ບໍ່ມີການແຍກກະແສຂໍ້ມູນ, ແມ່ນມີຄວາມຫຍຸ້ງຍາກໃນຕົວມັນເອງ, ເພາະວ່າທ່ານຈະຕ້ອງເພີ່ມຈຸດ synchronization ທີ່ຈະເຮັດໃຫ້ຜົນກະທົບທາງບວກທັງຫມົດຂອງແຖວ. ການ​ນໍາ​ໃຊ້​ທັງ​ສອງ​ວິ​ທີ​ການ​ໃນ​ເວ​ລາ​ດຽວ​ກັນ​, ມັນ​ເປັນ​ສິ່ງ​ຈໍາ​ເປັນ​ທີ່​ຈະ​ປັບ​ລະ​ຫັດ​ໂຄງ​ການ​ເລັກ​ນ້ອຍ​. ໃນກໍລະນີຂອງພວກເຮົາ, ເມື່ອສົ່ງໄຟລ໌ໄປຫາເຄື່ອງແມ່ຂ່າຍ, ຄໍາຕອບມາພຽງແຕ່ "ok", ຊຶ່ງຫມາຍຄວາມວ່າ "ການດໍາເນີນງານຂອງການເພີ່ມໄຟລ໌ໄດ້ຖືກບັນທຶກໄວ້." ຢ່າງເປັນທາງການ, ນີ້ບໍ່ໄດ້ຫມາຍຄວາມວ່າຂໍ້ມູນມີຢູ່ແລ້ວໃນອຸປະກອນອື່ນໆ (ຕົວຢ່າງ, ການບໍລິການ deduplication ສາມາດສ້າງດັດສະນີຄືນໃຫມ່). ຢ່າງໃດກໍຕາມ, ຫຼັງຈາກເວລາໃດຫນຶ່ງ, ລູກຄ້າຈະໄດ້ຮັບການແຈ້ງເຕືອນໃນຮູບແບບຂອງ "ໄຟລ໌ X ໄດ້ຖືກບັນທຶກໄວ້."

ດັ່ງນັ້ນ:

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

ການຂູດ

ດັ່ງທີ່ໄດ້ອະທິບາຍໄວ້ຂ້າງເທິງ, ລະບົບແຫຼ່ງເຫດການຂາດຄວາມສອດຄ່ອງຢ່າງເຂັ້ມງວດ. ນີ້ຫມາຍຄວາມວ່າພວກເຮົາສາມາດນໍາໃຊ້ບ່ອນເກັບມ້ຽນຈໍານວນຫນຶ່ງໂດຍບໍ່ມີການ synchronization ລະຫວ່າງພວກມັນ. ການເຂົ້າຫາບັນຫາຂອງພວກເຮົາ, ພວກເຮົາສາມາດ:

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

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

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

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

ດັ່ງນັ້ນ, ການສືບຕໍ່ຕົວຢ່າງຂອງພວກເຮົາກ່ຽວກັບການເກັບຮັກສາໄຟລ໌ອອນໄລນ໌, ສະຖາປັດຕະຍະກໍາດັ່ງກ່າວເຮັດໃຫ້ພວກເຮົາມີໂບນັດຈໍານວນຫນຶ່ງ:

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

Static Content Hosting

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

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

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

• ເຊີບເວີໃຫ້ URL ດາວໂຫຼດ. ມັນສາມາດເປັນຂອງແບບຟອມ file_id + ຄີ, ບ່ອນທີ່ຄີແມ່ນລາຍເຊັນດິຈິຕອນຂະຫນາດນ້ອຍທີ່ໃຫ້ສິດໃນການເຂົ້າເຖິງຊັບພະຍາກອນສໍາລັບ XNUMX ຊົ່ວໂມງຕໍ່ໄປ.
• ໄຟລ໌ໄດ້ຖືກແຈກຢາຍໂດຍ nginx ງ່າຍດາຍທີ່ມີທາງເລືອກຕໍ່ໄປນີ້:
  • ການເກັບຮັກສາເນື້ອຫາ. ເນື່ອງຈາກການບໍລິການນີ້ສາມາດຕັ້ງຢູ່ໃນເຄື່ອງແມ່ຂ່າຍແຍກຕ່າງຫາກ, ພວກເຮົາໄດ້ປະໄວ້ຕົວເອງສໍາລັບອະນາຄົດທີ່ມີຄວາມສາມາດໃນການເກັບຮັກສາໄຟລ໌ທີ່ດາວໂຫລດຫຼ້າສຸດທັງຫມົດໃນແຜ່ນ.
  • ການກວດສອບຄີໃນເວລາທີ່ສ້າງການເຊື່ອມຕໍ່
• ທາງເລືອກ: ການປະມວນຜົນເນື້ອຫາ streaming. ຕົວຢ່າງ, ຖ້າພວກເຮົາບີບອັດໄຟລ໌ທັງຫມົດໃນການບໍລິການ, ຫຼັງຈາກນັ້ນພວກເຮົາສາມາດ unzipping ໂດຍກົງໃນໂມດູນນີ້. ຜົນສະທ້ອນ: ການດໍາເນີນງານ IO ແມ່ນເຮັດບ່ອນທີ່ພວກເຂົາເປັນ. archiver ໃນ Java ຈະຈັດສັນຄວາມຊົງຈໍາພິເສດຫຼາຍໄດ້ຢ່າງງ່າຍດາຍ, ແຕ່ການຂຽນຄືນການບໍລິການທີ່ມີເຫດຜົນທາງທຸລະກິດເຂົ້າໄປໃນເງື່ອນໄຂ Rust/C++ ອາດຈະໃຊ້ບໍ່ໄດ້ຜົນ. ໃນ​ກໍ​ລະ​ນີ​ຂອງ​ພວກ​ເຮົາ, ຂະ​ບວນ​ການ​ທີ່​ແຕກ​ຕ່າງ​ກັນ (ຫຼື​ແມ່ນ​ແຕ່​ການ​ບໍ​ລິ​ການ) ໄດ້​ຖືກ​ນໍາ​ໃຊ້, ແລະ​ດັ່ງ​ນັ້ນ​ພວກ​ເຮົາ​ຂ້ອນ​ຂ້າງ​ປະ​ສິດ​ທິ​ຜົນ​ສາ​ມາດ​ແຍກ​ຕາມ​ເຫດ​ຜົນ​ທຸ​ລະ​ກິດ​ແລະ​ການ​ດໍາ​ເນີນ​ງານ IO.

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

ເປັນຕົວຢ່າງອື່ນ (ສໍາລັບການເສີມ): ຖ້າທ່ານໄດ້ເຮັດວຽກກັບ Jenkins / TeamCity, ຫຼັງຈາກນັ້ນທ່ານຮູ້ວ່າທັງສອງວິທີແກ້ໄຂແມ່ນຂຽນໃນ Java. ທັງສອງແມ່ນຂະບວນການ Java ທີ່ຈັດການທັງການກໍ່ສ້າງ orchestration ແລະການຄຸ້ມຄອງເນື້ອຫາ. ໂດຍສະເພາະ, ພວກເຂົາທັງສອງມີວຽກງານເຊັ່ນ "ໂອນໄຟລ໌ / ໂຟນເດີຈາກເຄື່ອງແມ່ຂ່າຍ." ເປັນຕົວຢ່າງ: ການອອກສິ່ງປອມ, ການໂອນລະຫັດແຫຼ່ງ (ເມື່ອຕົວແທນບໍ່ໄດ້ດາວໂຫລດລະຫັດໂດຍກົງຈາກບ່ອນເກັບມ້ຽນ, ແຕ່ເຄື່ອງແມ່ຂ່າຍເຮັດສໍາລັບລາວ), ການເຂົ້າເຖິງບັນທຶກ. ວຽກງານທັງຫມົດເຫຼົ່ານີ້ແຕກຕ່າງກັນໃນການໂຫຼດ IO ຂອງພວກເຂົາ. ນັ້ນແມ່ນ, ມັນສະແດງໃຫ້ເຫັນວ່າເຄື່ອງແມ່ຂ່າຍທີ່ຮັບຜິດຊອບຕໍ່ເຫດຜົນທາງທຸລະກິດທີ່ສັບສົນຕ້ອງໃນເວລາດຽວກັນສາມາດຊຸກຍູ້ການໄຫຼເຂົ້າຂະຫນາດໃຫຍ່ຂອງຂໍ້ມູນຜ່ານຕົວມັນເອງ. ແລະສິ່ງທີ່ຫນ້າສົນໃຈທີ່ສຸດແມ່ນວ່າການດໍາເນີນງານດັ່ງກ່າວສາມາດຖືກມອບຫມາຍໃຫ້ nginx ດຽວກັນຕາມໂຄງການດຽວກັນຢ່າງແທ້ຈິງ (ຍົກເວັ້ນວ່າກະແຈຂໍ້ມູນຄວນຈະຖືກເພີ່ມໃສ່ຄໍາຮ້ອງຂໍ).

ຢ່າງໃດກໍຕາມ, ຖ້າພວກເຮົາກັບຄືນສູ່ລະບົບຂອງພວກເຮົາ, ພວກເຮົາໄດ້ຮັບແຜນວາດທີ່ຄ້າຍຄືກັນ:

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

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

ສະຫລຸບ

ວິທີການທັງຫມົດເຫຼົ່ານີ້ເປັນທີ່ຮູ້ຈັກກ່ອນ. VK ດຽວກັນໄດ້ໃຊ້ແນວຄວາມຄິດຂອງ Static Content Hosting ມາເປັນເວລາດົນນານເພື່ອສະແດງຮູບພາບ. ຫຼາຍເກມອອນໄລນ໌ໃຊ້ Sharding scheme ເພື່ອແບ່ງຜູ້ນອອກເປັນພາກພື້ນຫຼືເພື່ອແຍກສະຖານທີ່ເກມ (ຖ້າຫາກວ່າໂລກຂອງຕົນເອງເປັນຫນຶ່ງ). ວິທີການຈັດຫາແຫຼ່ງເຫດການແມ່ນໃຊ້ຢ່າງຫ້າວຫັນໃນອີເມວ. ຄໍາຮ້ອງສະຫມັກການຄ້າສ່ວນໃຫຍ່ທີ່ຂໍ້ມູນໄດ້ຮັບຢ່າງຕໍ່ເນື່ອງແມ່ນຖືກສ້າງຂຶ້ນໃນວິທີການ CQRS ເພື່ອຈະສາມາດກັ່ນຕອງຂໍ້ມູນທີ່ໄດ້ຮັບ. ດີ, ການປັບຂະຫນາດຕາມແນວນອນໄດ້ຖືກນໍາໃຊ້ໃນການບໍລິການຈໍານວນຫຼາຍສໍາລັບເວລາດົນນານ.

ຢ່າງໃດກໍ່ຕາມ, ສໍາຄັນທີ່ສຸດ, ຮູບແບບທັງຫມົດເຫຼົ່ານີ້ໄດ້ກາຍເປັນເລື່ອງງ່າຍທີ່ຈະນໍາໃຊ້ໃນຄໍາຮ້ອງສະຫມັກທີ່ທັນສະໄຫມ (ຖ້າພວກເຂົາເຫມາະສົມ, ແນ່ນອນ). Clouds ສະເຫນີ Sharding ແລະການປັບຂະຫນາດຕາມແນວນອນທັນທີ, ເຊິ່ງງ່າຍກວ່າການສັ່ງໃຫ້ເຄື່ອງແມ່ຂ່າຍທີ່ອຸທິດຕົນທີ່ແຕກຕ່າງກັນຢູ່ໃນສູນຂໍ້ມູນທີ່ແຕກຕ່າງກັນດ້ວຍຕົວທ່ານເອງ. CQRS ໄດ້ກາຍເປັນຫຼາຍງ່າຍຂຶ້ນ, ຖ້າຫາກວ່າພຽງແຕ່ຍ້ອນການພັດທະນາຂອງຫ້ອງສະຫມຸດເຊັ່ນ RX. ປະມານ 10 ປີກ່ອນຫນ້ານີ້, ເວັບໄຊທ໌ທີ່ຫາຍາກສາມາດສະຫນັບສະຫນູນນີ້. ການຈັດຫາແຫຼ່ງເຫດການແມ່ນຍັງງ່າຍຢ່າງບໍ່ຫນ້າເຊື່ອໃນການຕິດຕັ້ງຂໍຂອບໃຈກັບພາຊະນະທີ່ພ້ອມທີ່ຈະເຮັດດ້ວຍ Apache Kafka. ເມື່ອ 10 ປີ​ກ່ອນ​ນີ້​ຈະ​ເປັນ​ນະ​ວັດ​ຕະ​ກໍາ​, ປະ​ຈຸ​ບັນ​ມັນ​ເປັນ​ເລື່ອງ​ທໍາ​ມະ​ດາ​. ມັນຄືກັນກັບ Static Content Hosting: ເນື່ອງຈາກເຕັກໂນໂລຢີທີ່ສະດວກກວ່າ (ລວມທັງຄວາມຈິງທີ່ວ່າມີເອກະສານລາຍລະອຽດແລະຖານຂໍ້ມູນຄໍາຕອບຂະຫນາດໃຫຍ່), ວິທີການນີ້ໄດ້ກາຍເປັນເລື່ອງທີ່ງ່າຍດາຍກວ່າ.

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

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

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