ສະຖາປັດຕະຍະກໍາຊອບແວ ແລະການອອກແບບລະບົບ: ຄູ່ມືຮູບພາບໃຫຍ່ ແລະຊັບພະຍາກອນ

ສະບາຍດີເພື່ອນຮ່ວມງານ.

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

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

ພາບຖ່າຍ ອີຊາກ ສະມິດ ຈາກ Unsplash

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

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

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

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

ກໍານົດລະດັບເບື້ອງຕົ້ນ

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

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

ຕົກລົງ, ສະນັ້ນບ່ອນທີ່ຈະເລີ່ມຕົ້ນ? U Donna Martina ມີ repository ໃນ GitHub ເອີ້ນວ່າ system-design-primer, ຈາກທີ່ທ່ານສາມາດຮຽນຮູ້ວິທີການອອກແບບລະບົບຂະຫນາດໃຫຍ່, ເຊັ່ນດຽວກັນກັບການກະກຽມສໍາລັບການສໍາພາດໃນຫົວຂໍ້ນີ້. ຄັງເກັບມ້ຽນມີພາກທີ່ມີຕົວຢ່າງ ສະຖາປັດຕະຍະກໍາທີ່ແທ້ຈິງ, ບ່ອນທີ່, ໂດຍສະເພາະ, ມັນໄດ້ຖືກພິຈາລະນາວິທີການທີ່ເຂົາເຈົ້າເຂົ້າຫາການອອກແບບຂອງລະບົບຂອງພວກເຂົາ ບາງບໍລິສັດທີ່ຮູ້ຈັກກັນດີເຊັ່ນ Twitter, Uber, ແລະອື່ນໆ.

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

ສ້າງຄວາມຮູ້ກ່ຽວກັບການເກັບຮັກສາແລະດຶງຂໍ້ມູນ

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

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

ພາບຖ່າຍ ຊາມູເອນ ເຊວເລີ ຈາກ Unsplash

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

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

ຮູບແບບການສື່ສານ

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

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

ພາບຖ່າຍ Tony Stoddard ຈາກ Unsplash

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

ການແຜ່ກະຈາຍການເຊື່ອມຕໍ່

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

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

ການແຈກຢາຍນີ້ແມ່ນອີງໃສ່ຊື່ສຽງ ລະບົບຊື່ໂດເມນ (DNS). ລະບົບດັ່ງກ່າວອະນຸຍາດໃຫ້ມີການຫັນປ່ຽນຊື່ໂດເມນເຊັ່ນ: ນ້ໍາຫນັກຮອບ robin ແລະວິທີການໂດຍອີງໃສ່ latency ເພື່ອຊ່ວຍແຈກຢາຍການໂຫຼດ.

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

ທ່ານກໍ່ຄວນຈະຮູ້ກ່ຽວກັບ ເຄືອຂ່າຍການຈັດສົ່ງເນື້ອຫາ (CDN). CDN ແມ່ນເຄືອຂ່າຍເຊີບເວີພຣັອກຊີທີ່ແຈກຢາຍທົ່ວໂລກທີ່ສົ່ງຂໍ້ມູນຈາກໂນດທີ່ຢູ່ທາງພູມສາດທີ່ຢູ່ໃກ້ກັບຜູ້ໃຊ້ສະເພາະ. CDNs ແມ່ນດີທີ່ຈະໃຊ້ຖ້າທ່ານເຮັດວຽກກັບໄຟລ໌ຄົງທີ່ຂຽນໃນ JavaScript, CSS ແລະ HTML. ນອກຈາກນັ້ນ, ການບໍລິການຄລາວທີ່ໃຫ້ຜູ້ຈັດການການຈະລາຈອນແມ່ນທົ່ວໄປໃນມື້ນີ້, ສໍາລັບການຍົກຕົວຢ່າງ, Azure Traffic Manager, ໃຫ້ທ່ານແຈກຢາຍທົ່ວໂລກແລະຫຼຸດຜ່ອນເວລາ latency ເມື່ອເຮັດວຽກກັບເນື້ອຫາແບບເຄື່ອນໄຫວ. ຢ່າງໃດກໍ່ຕາມ, ການບໍລິການດັ່ງກ່າວປົກກະຕິແລ້ວເປັນປະໂຫຍດໃນກໍລະນີທີ່ທ່ານຕ້ອງເຮັດວຽກກັບການບໍລິການເວັບທີ່ບໍ່ມີລັດ.

ໃຫ້ເວົ້າກ່ຽວກັບເຫດຜົນທາງທຸລະກິດ. ໂຄງສ້າງຕາມເຫດຜົນທາງທຸລະກິດ, ກະແສວຽກ ແລະອົງປະກອບ

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

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

• ຫຼັກການແຂງ
• ແນວຄິດ ການອອກແບບທີ່ຂັບເຄື່ອນໂດຍໂດເມນ, ໂດຍ​ສະ​ເພາະ, ໜ່ວຍ, ທີມ​ງານ​ແລະ​ກິດ​ຈະ​ກໍາ​
• ສະຖາປັດຕະຍະກໍາຫົກຫລ່ຽມ
• ການ​ແບ່ງ​ຄວາມ​ຮັບ​ຜິດ​ຊອບ​ອອກ​ເປັນ​ຄໍາ​ສັ່ງ​ແລະ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ (CQRS​)
• ການລົງທະບຽນເຫດການ
• ຕົວແບບນັກສະແດງ
• ຮູບແບບການອອກແບບ MVC, MVVM ແລະ MVP

ວິທີການຮ່ວມມື

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

ພາບຖ່າຍ ຄາເລຕິໂກ ຈາກ Unsplash

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

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

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