ທຸກໆມື້, ທຸກໆເວລາໃນການເຮັດວຽກດ້ານວິສະວະກໍາຂອງພວກເຮົາ, ພວກເຮົາພົບກັບບັນຫາທີ່ແຕກຕ່າງກັນຫຼາຍຂອງຄວາມສັບສົນແລະສະຖານະການຕ່າງໆທີ່ພວກເຮົາຈໍາເປັນຕ້ອງຕັດສິນໃຈຫຼືເລື່ອນມັນຍ້ອນການຂາດຂໍ້ມູນ. ເມື່ອໃດກໍ່ຕາມທີ່ພວກເຮົາສ້າງການບໍລິການໃຫມ່, ກໍ່ສ້າງພື້ນຖານໂຄງລ່າງ, ຫຼືແມ້ກະທັ້ງຂະບວນການພັດທະນາ, ພວກເຮົາສໍາຜັດກັບໂລກອັນໃຫຍ່ຫຼວງຂອງສິ່ງທ້າທາຍຕ່າງໆ.
ມັນເປັນສິ່ງທ້າທາຍ, ແລະບາງທີເປັນໄປບໍ່ໄດ້, ທີ່ຈະບອກບັນຫາທັງຫມົດ. ທ່ານຈະພົບບາງບັນຫາເຫຼົ່ານີ້ພຽງແຕ່ຖ້າຫາກວ່າທ່ານເຮັດວຽກຢູ່ໃນ niche ສະເພາະ. ໃນທາງກົງກັນຂ້າມ, ມີຫຼາຍສິ່ງທີ່ພວກເຮົາທຸກຄົນຕ້ອງເຂົ້າໃຈວິທີການແກ້ໄຂ, ຍ້ອນວ່າພວກມັນມີຄວາມສໍາຄັນໃນການກໍ່ສ້າງລະບົບ IT. ມີຄວາມເປັນໄປໄດ້ສູງ, ທ່ານຈະພົບກັບພວກເຂົາໃນໂຄງການທັງຫມົດ.
ໃນບົດຄວາມນີ້, ຂ້ອຍຈະແບ່ງປັນປະສົບການຂອງຂ້ອຍກັບບາງບັນຫາທີ່ຂ້ອຍໄດ້ພົບໃນຂະນະທີ່ສ້າງໂປຼແກຼມໂປຼແກຼມ.
ຖ້າພວກເຮົາເບິ່ງໃນ Wikipedia, ພວກເຮົາຈະຊອກຫາຄໍານິຍາມຕໍ່ໄປນີ້
ໃນການພັດທະນາຊອບແວແບບຮັດກຸມ, ຄວາມກັງວົນຂ້າມຜ່ານແມ່ນລັກສະນະຂອງໂຄງການທີ່ມີຜົນກະທົບຕໍ່ຫຼາຍໆໂມດູນ, ໂດຍບໍ່ມີຄວາມເປັນໄປໄດ້ທີ່ຈະຖືກຫຸ້ມຢູ່ໃນພວກມັນ. ຄວາມກັງວົນເຫຼົ່ານີ້ມັກຈະບໍ່ສາມາດຖືກທໍາລາຍຢ່າງສະອາດຈາກສ່ວນທີ່ເຫຼືອຂອງລະບົບທັງໃນການອອກແບບແລະການຈັດຕັ້ງປະຕິບັດ, ແລະສາມາດສົ່ງຜົນໃຫ້ມີການກະແຈກກະຈາຍ (ການຊ້ໍາກັນລະຫັດ), tangling (ຄວາມຂຶ້ນກັບທີ່ສໍາຄັນລະຫວ່າງລະບົບ), ຫຼືທັງສອງ.
ມັນອະທິບາຍຢ່າງຫຼວງຫຼາຍວ່າມັນແມ່ນຫຍັງ, ແຕ່ຂ້ອຍຢາກຂະຫຍາຍແລະເຮັດໃຫ້ມັນງ່າຍເລັກນ້ອຍ:
ຄວາມກັງວົນຂ້າມຜ່ານ ແມ່ນແນວຄວາມຄິດຫຼືອົງປະກອບຂອງລະບົບ / ອົງການຈັດຕັ້ງທີ່ມີຜົນກະທົບ (ຫຼື 'ຕັດຜ່ານ') ຫຼາຍພາກສ່ວນອື່ນໆ.
ຕົວຢ່າງທີ່ດີທີ່ສຸດຂອງຄວາມກັງວົນດັ່ງກ່າວແມ່ນສະຖາປັດຕະຍະກໍາລະບົບ, ການບັນທຶກ, ຄວາມປອດໄພ, ການຈັດການທຸລະກໍາ, telemetry, ການອອກແບບຖານຂໍ້ມູນແລະອື່ນໆຈໍານວນຫຼາຍ. ພວກເຮົາກໍາລັງຈະອະທິບາຍກ່ຽວກັບຈໍານວນຫຼາຍຂອງພວກເຂົາຕໍ່ມາໃນບົດຄວາມນີ້.
ໃນລະດັບລະຫັດ, ຄວາມກັງວົນຂ້າມການຕັດແມ່ນມັກຈະຖືກປະຕິບັດໂດຍໃຊ້ເຕັກນິກເຊັ່ນ Aspect-Oriented Programming (AOP) , ບ່ອນທີ່ຄວາມກັງວົນເຫຼົ່ານີ້ຖືກ modularized ເປັນອົງປະກອບແຍກຕ່າງຫາກທີ່ສາມາດນໍາໃຊ້ໄດ້ຕະຫຼອດຄໍາຮ້ອງສະຫມັກ. ນີ້ເຮັດໃຫ້ເຫດຜົນທາງທຸລະກິດແຍກອອກຈາກຄວາມກັງວົນເຫຼົ່ານີ້, ເຮັດໃຫ້ລະຫັດສາມາດອ່ານໄດ້ແລະຮັກສາໄດ້ຫຼາຍຂຶ້ນ.
ມີຫຼາຍວິທີທີ່ຈະຈັດປະເພດລັກສະນະຕ່າງໆໂດຍການແບ່ງປະເພດພວກມັນດ້ວຍຄຸນສົມບັດທີ່ແຕກຕ່າງກັນເຊັ່ນ: ຂອບເຂດ, ຂະຫນາດ, ຫນ້າທີ່, ຄວາມສໍາຄັນ, ເປົ້າຫມາຍ, ແລະອື່ນໆ, ແຕ່ໃນບົດຄວາມນີ້, ຂ້ອຍຈະໃຊ້ການຈັດປະເພດຂອບເຂດທີ່ງ່າຍດາຍ. ໂດຍນີ້, ຂ້າພະເຈົ້າຫມາຍຄວາມວ່າບ່ອນທີ່ລັກສະນະສະເພາະນີ້ຖືກນໍາໄປບໍ່ວ່າຈະເປັນອົງການຈັດຕັ້ງທັງຫມົດ, ລະບົບສະເພາະໃດຫນຶ່ງ, ຫຼືອົງປະກອບສະເພາະຂອງລະບົບນັ້ນ.
ດັ່ງນັ້ນ, ຂ້ອຍຈະແບ່ງລັກສະນະອອກເປັນ Macro ແລະ Micro .
ໂດຍດ້ານ Macro ຂ້າພະເຈົ້າຫມາຍເຖິງການພິຈາລະນາສ່ວນໃຫຍ່ທີ່ພວກເຮົາປະຕິບັດຕາມສໍາລັບລະບົບທັງຫມົດເຊັ່ນ: ສະຖາປັດຕະຍະກໍາລະບົບທີ່ເລືອກແລະການອອກແບບຂອງມັນ (monolithic, microservices, ສະຖາປັດຕະຍະກໍາທີ່ເນັ້ນໃສ່ການບໍລິການ), stack ເຕັກໂນໂລຢີ, ໂຄງສ້າງອົງການຈັດຕັ້ງ, ແລະອື່ນໆ. Macro ສ່ວນໃຫຍ່ແມ່ນກ່ຽວຂ້ອງກັບຍຸດທະສາດແລະລະດັບສູງ. ການຕັດສິນໃຈ.
ໃນເວລານີ້, ລັກສະນະ Micro ແມ່ນໃກ້ຊິດກັບລະດັບລະຫັດແລະການພັດທະນາ. ສໍາລັບຕົວຢ່າງ, ກອບທີ່ຖືກນໍາໃຊ້ສໍາລັບການພົວພັນກັບຖານຂໍ້ມູນ, ໂຄງສ້າງໂຄງການຂອງໂຟນເດີແລະຊັ້ນຮຽນ, ຫຼືແມ້ກະທັ້ງຮູບແບບການອອກແບບວັດຖຸສະເພາະ.
ໃນຂະນະທີ່ການຈັດປະເພດນີ້ບໍ່ເຫມາະສົມ, ມັນຊ່ວຍສ້າງໂຄງສ້າງຄວາມເຂົ້າໃຈກ່ຽວກັບບັນຫາທີ່ເປັນໄປໄດ້ແລະຄວາມສໍາຄັນແລະຜົນກະທົບຂອງວິທີແກ້ໄຂທີ່ພວກເຮົາໃຊ້ກັບພວກມັນ.
ໃນບົດຄວາມນີ້, ຈຸດສຸມຕົ້ນຕໍຂອງຂ້ອຍຈະຢູ່ໃນລັກສະນະມະຫາພາກ.
ໃນເວລາທີ່ຂ້າພະເຈົ້າພຽງແຕ່ເລີ່ມຕົ້ນຮຽນຮູ້ກ່ຽວກັບສະຖາປັດຕະຍະກໍາຊອບແວ, ຂ້າພະເຈົ້າໄດ້ອ່ານບົດຄວາມທີ່ຫນ້າສົນໃຈຫຼາຍກ່ຽວກັບກົດຫມາຍຂອງ Conway ແລະຜົນກະທົບຕໍ່ໂຄງສ້າງຂອງອົງການຈັດຕັ້ງ. ໂດຍສະເພາະ ອັນນີ້ . ດັ່ງນັ້ນ, ກົດຫມາຍນີ້ລະບຸວ່າ
ອົງການຈັດຕັ້ງໃດກໍ່ຕາມທີ່ອອກແບບລະບົບ (ກໍານົດຢ່າງກວ້າງຂວາງ) ຈະຜະລິດການອອກແບບທີ່ມີໂຄງສ້າງທີ່ເປັນສໍາເນົາຂອງໂຄງສ້າງການສື່ສານຂອງອົງການຈັດຕັ້ງ.
ຂ້າພະເຈົ້າເຊື່ອສະເຫມີໄປວ່າແນວຄວາມຄິດນີ້ແມ່ນແທ້ຈິງຫຼາຍທົ່ວໄປແລະເປັນຕົວແທນຂອງກົດລະບຽບ Golden.
ຫຼັງຈາກນັ້ນ, ຂ້າພະເຈົ້າໄດ້ເລີ່ມຕົ້ນຮຽນຮູ້ວິທີການອອກແບບ Domain-Driven (DDD) ຂອງ Eric Evans ສໍາລັບລະບົບການສ້າງແບບຈໍາລອງ. Eric Evans ເນັ້ນຫນັກເຖິງຄວາມສໍາຄັນຂອງການກໍານົດຂອບເຂດທີ່ມີຂອບເຂດ. ແນວຄວາມຄິດນີ້ກ່ຽວຂ້ອງກັບການແບ່ງຕົວແບບໂດເມນທີ່ຊັບຊ້ອນອອກເປັນພາກສ່ວນທີ່ນ້ອຍກວ່າ, ສາມາດຈັດການໄດ້ຫຼາຍຂຶ້ນ, ແຕ່ລະຄົນມີຄວາມຮູ້ຈໍາກັດຂອງຕົນເອງ. ວິທີການນີ້ຊ່ວຍໃນການສື່ສານຂອງທີມງານທີ່ມີປະສິດທິພາບ, ຍ້ອນວ່າມັນຫຼຸດຜ່ອນຄວາມຕ້ອງການຄວາມຮູ້ຢ່າງກວ້າງຂວາງຂອງໂດເມນທັງຫມົດແລະຫຼຸດຜ່ອນການປ່ຽນສະພາບການ, ດັ່ງນັ້ນຈຶ່ງເຮັດໃຫ້ການສົນທະນາມີປະສິດທິພາບຫຼາຍຂຶ້ນ. ການປ່ຽນບໍລິບົດເປັນສິ່ງທີ່ຮ້າຍແຮງທີ່ສຸດ ແລະໃຊ້ຊັບພະຍາກອນຫຼາຍທີ່ສຸດເທົ່າທີ່ເຄີຍມີມາ. ເຖິງແມ່ນວ່າຄອມພິວເຕີກໍາລັງຕໍ່ສູ້ກັບມັນ. ເຖິງແມ່ນວ່າມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະບັນລຸການຂາດການປ່ຽນສະພາບການຢ່າງສົມບູນ, ຂ້າພະເຈົ້າຖືວ່ານັ້ນແມ່ນສິ່ງທີ່ພວກເຮົາຄວນພະຍາຍາມ.
ກັບຄືນໄປຫາກົດຫມາຍຂອງ Conway, ຂ້າພະເຈົ້າໄດ້ພົບເຫັນບັນຫາຫຼາຍຢ່າງກັບມັນ.
ບັນຫາທໍາອິດ ທີ່ຂ້າພະເຈົ້າໄດ້ພົບກັບກົດຫມາຍຂອງ Conway, ເຊິ່ງແນະນໍາວ່າການອອກແບບລະບົບສະທ້ອນເຖິງໂຄງສ້າງຂອງອົງການຈັດຕັ້ງ, ແມ່ນທ່າແຮງສໍາລັບການສ້າງຂອບເຂດທີ່ສັບສົນແລະຄົບຖ້ວນສົມບູນ. ຄວາມສັບສົນນີ້ເກີດຂື້ນໃນເວລາທີ່ໂຄງສ້າງຂອງອົງການຈັດຕັ້ງບໍ່ສອດຄ່ອງກັບຂອບເຂດໂດເມນ, ນໍາໄປສູ່ການກໍານົດຂອບເຂດທີ່ຂຶ້ນກັບກັນຢ່າງຫຼວງຫຼາຍແລະເຕັມໄປດ້ວຍຂໍ້ມູນ. ມັນນໍາໄປສູ່ການປ່ຽນສະພາບການເລື້ອຍໆສໍາລັບທີມງານພັດທະນາ.
ບັນຫາອີກຢ່າງຫນຶ່ງ ແມ່ນວ່າຄໍາສັບຂອງອົງການຈັດຕັ້ງຮົ່ວໄຫລໄປສູ່ລະດັບລະຫັດ. ເມື່ອໂຄງສ້າງຂອງອົງການຈັດຕັ້ງມີການປ່ຽນແປງ, ມັນຈໍາເປັນຕ້ອງມີການດັດແກ້ codebase, ການບໍລິໂພກຊັບພະຍາກອນທີ່ມີຄຸນຄ່າ.
ດັ່ງນັ້ນ, ການປະຕິບັດຕາມ Inverse Conway Maneuver ຈະຊ່ວຍສ້າງລະບົບແລະອົງການຈັດຕັ້ງທີ່ຊຸກຍູ້ໃຫ້ສະຖາປັດຕະຍະກໍາຊອບແວທີ່ຕ້ອງການ. ຢ່າງໃດກໍ່ຕາມ, ມັນເປັນທີ່ຫນ້າສັງເກດທີ່ຈະເວົ້າວ່າວິທີການນີ້ຈະບໍ່ເຮັດວຽກໄດ້ດີຫຼາຍໃນສະຖາປັດຕະຍະກໍາແລະໂຄງສ້າງທີ່ມີຮູບແບບແລ້ວນັບຕັ້ງແຕ່ການປ່ຽນແປງໃນຂັ້ນຕອນນີ້ແມ່ນຍາວນານ, ແຕ່ມັນປະຕິບັດໄດ້ພິເສດໃນການເລີ່ມຕົ້ນເພາະວ່າພວກເຂົາໄວທີ່ຈະແນະນໍາການປ່ຽນແປງໃດໆ.
ຮູບແບບນີ້ຫຼື "ການຕ້ານການຮູບແບບ" ການຂັບເຄື່ອນການກໍ່ສ້າງລະບົບໂດຍບໍ່ມີສະຖາປັດຕະ. ບໍ່ມີກົດລະບຽບ, ບໍ່ມີຂອບເຂດ, ແລະບໍ່ມີຍຸດທະສາດກ່ຽວກັບວິທີການຄວບຄຸມຄວາມສັບສົນທີ່ບໍ່ສາມາດຫຼີກເວັ້ນໄດ້. ຄວາມສັບສົນແມ່ນສັດຕູທີ່ເປັນຕາຢ້ານທີ່ສຸດໃນການເດີນທາງຂອງລະບົບຊອບແວກໍ່ສ້າງ.
ເພື່ອຫຼີກເວັ້ນການສ້າງລະບົບປະເພດດັ່ງກ່າວ, ພວກເຮົາຈໍາເປັນຕ້ອງປະຕິບັດຕາມກົດລະບຽບແລະຂໍ້ຈໍາກັດສະເພາະ.
ມີຄໍານິຍາມຫຼາຍຢ່າງສໍາລັບສະຖາປັດຕະຍະກໍາຊອບແວ. ຂ້ອຍມັກພວກເຂົາຫຼາຍນັບຕັ້ງແຕ່ພວກເຂົາກວມເອົາລັກສະນະທີ່ແຕກຕ່າງກັນຂອງມັນ. ຢ່າງໃດກໍ່ຕາມ, ເພື່ອສາມາດໃຫ້ເຫດຜົນກ່ຽວກັບສະຖາປັດຕະຍະກໍາ, ພວກເຮົາຕ້ອງການທໍາມະຊາດເພື່ອສ້າງບາງສ່ວນຂອງພວກມັນຢູ່ໃນໃຈຂອງພວກເຮົາ. ແລະມັນເປັນທີ່ຫນ້າສັງເກດທີ່ຈະເວົ້າວ່າຄໍານິຍາມນີ້ອາດຈະພັດທະນາ. ດັ່ງນັ້ນ, ຢ່າງຫນ້ອຍສໍາລັບຕອນນີ້, ຂ້ອຍມີຄໍາອະທິບາຍຕໍ່ໄປນີ້ສໍາລັບຕົນເອງ.
ສະຖາປັດຕະຍະກໍາຊອບແວ ແມ່ນກ່ຽວກັບການຕັດສິນໃຈແລະການເລືອກທີ່ທ່ານເຮັດທຸກໆມື້ທີ່ມີຜົນກະທົບຕໍ່ລະບົບທີ່ສ້າງຂຶ້ນ.
ເພື່ອຕັດສິນໃຈທີ່ທ່ານຕ້ອງມີຢູ່ໃນຫຼັກການແລະຮູບແບບ "ຖົງ" ຂອງທ່ານສໍາລັບການແກ້ໄຂບັນຫາທີ່ເກີດຂື້ນ, ມັນຍັງມີຄວາມຈໍາເປັນທີ່ຈະລະບຸວ່າການເຂົ້າໃຈຂໍ້ກໍານົດແມ່ນສໍາຄັນໃນການສ້າງສິ່ງທີ່ທຸລະກິດຕ້ອງການ. ຢ່າງໃດກໍຕາມ, ບາງຄັ້ງຄວາມຕ້ອງການບໍ່ໂປ່ງໃສຫຼືແມ້ກະທັ້ງບໍ່ໄດ້ກໍານົດ, ໃນກໍລະນີນີ້, ມັນກໍ່ດີກວ່າທີ່ຈະລໍຖ້າການຊີ້ແຈງເພີ່ມເຕີມຫຼືອີງໃສ່ປະສົບການຂອງທ່ານແລະໄວ້ວາງໃຈ intuition ຂອງທ່ານ. ແຕ່ຢ່າງໃດກໍ່ຕາມ, ທ່ານບໍ່ສາມາດຕັດສິນໃຈຢ່າງຖືກຕ້ອງຖ້າທ່ານບໍ່ມີຫຼັກການແລະຮູບແບບທີ່ຈະອີງໃສ່. ນັ້ນແມ່ນບ່ອນທີ່ຂ້ອຍມາຮອດຄໍານິຍາມຂອງ Software Architecture Style.
ແບບສະຖາປັດຕະຍະກໍາຊອບແວ ແມ່ນຊຸດຂອງຫຼັກການແລະຮູບແບບທີ່ກໍານົດວິທີການສ້າງຊອບແວ.
ມີຮູບແບບສະຖາປັດຕະຍະກໍາທີ່ແຕກຕ່າງກັນຫຼາຍທີ່ສຸມໃສ່ດ້ານຕ່າງໆຂອງສະຖາປັດຕະຍະກໍາທີ່ວາງແຜນໄວ້, ແລະການນໍາໃຊ້ຫຼາຍໆຢ່າງໃນເວລາດຽວກັນແມ່ນສະຖານະການປົກກະຕິ.
ສໍາລັບຕົວຢ່າງ, ເຊັ່ນ:
ສະຖາປັດຕະຍະກໍາ Monolithic
ການອອກແບບທີ່ຂັບເຄື່ອນໂດຍໂດເມນ
ອີງໃສ່ອົງປະກອບ
ການບໍລິການຈຸລະພາກ
ທໍ່ແລະການກັ່ນຕອງ
ເຫດການທີ່ຂັບເຄື່ອນ
ໄມໂຄຣເຄນ
ການບໍລິການແບບຮັດກຸມ
ແລະອື່ນໆ...
ແນ່ນອນ, ພວກເຂົາມີຂໍ້ດີແລະຂໍ້ເສຍຂອງພວກເຂົາ, ແຕ່ສິ່ງທີ່ສໍາຄັນທີ່ສຸດທີ່ຂ້ອຍໄດ້ຮຽນຮູ້ແມ່ນວ່າສະຖາປັດຕະຍະກໍາພັດທະນາຄ່ອຍໆໃນຂະນະທີ່ຂຶ້ນກັບບັນຫາຕົວຈິງ. ການເລີ່ມຕົ້ນດ້ວຍສະຖາປັດຕະຍະກໍາ monolithic ເປັນທາງເລືອກທີ່ດີສໍາລັບການຫຼຸດຜ່ອນຄວາມສັບສົນໃນການດໍາເນີນງານ, ເບິ່ງຄືວ່າສະຖາປັດຕະຍະກໍານີ້ຈະເຫມາະສົມກັບຄວາມຕ້ອງການຂອງເຈົ້າເຖິງແມ່ນວ່າຈະມາຮອດຂັ້ນຕອນຂອງ Product-market Fit (PMI) ໃນການສ້າງຜະລິດຕະພັນ. ໃນລະດັບ, ທ່ານອາດຈະພິຈາລະນາກ້າວໄປສູ່ວິທີການທີ່ຂັບເຄື່ອນໂດຍເຫດການແລະການບໍລິການຈຸລະພາກເພື່ອບັນລຸການປະຕິບັດແບບເອກະລາດ, ສະພາບແວດລ້ອມ stack ເຕັກໂນໂລຢີທີ່ຫລາກຫລາຍ, ແລະສະຖາປັດຕະຍະກໍາທີ່ປະສົມປະສານຫນ້ອຍລົງ (ແລະມີຄວາມໂປ່ງໃສຫນ້ອຍໃນຂະນະນີ້ເນື່ອງຈາກລັກສະນະຂອງການຂັບເຄື່ອນເຫດການແລະວິທີການ pub-sub ຖ້າ. ເຫຼົ່ານີ້ແມ່ນໄດ້ຮັບຮອງເອົາ). ຄວາມງ່າຍດາຍແລະປະສິດທິພາບແມ່ນໃກ້ຊິດແລະມີຜົນກະທົບອັນໃຫຍ່ຫຼວງຕໍ່ກັນແລະກັນ. ໂດຍປົກກະຕິແລ້ວ, ສະຖາປັດຕະຍະກໍາທີ່ສັບສົນສົ່ງຜົນກະທົບຕໍ່ຄວາມໄວໃນການພັດທະນາຂອງລັກສະນະໃຫມ່, ສະຫນັບສະຫນູນແລະຮັກສາສິ່ງທີ່ມີຢູ່ແລ້ວ, ແລະທ້າທາຍວິວັດທະນາທໍາມະຊາດຂອງລະບົບ.
ຢ່າງໃດກໍ່ຕາມ, ລະບົບສະລັບສັບຊ້ອນມັກຈະຕ້ອງການສະຖາປັດຕະຍະກໍາທີ່ຊັບຊ້ອນແລະຄົບຖ້ວນ, ເຊິ່ງເປັນສິ່ງທີ່ຫຼີກລ່ຽງບໍ່ໄດ້.
ຍຸດຕິ ທຳ, ນີ້ແມ່ນຫົວຂໍ້ທີ່ກວ້າງຂວາງຫຼາຍ, ແລະມີຫຼາຍແນວຄວາມຄິດທີ່ດີກ່ຽວກັບວິທີການສ້າງໂຄງສ້າງແລະລະບົບການວິວັດທະນາການທໍາມະຊາດ. ອີງຕາມປະສົບການຂອງຂ້ອຍ, ຂ້ອຍໄດ້ປະຕິບັດວິທີການດັ່ງຕໍ່ໄປນີ້:
ມັນຍັງມີຄວາມສໍາຄັນທີ່ຈະເຂົ້າໃຈຕົວເລກແລະຕົວຊີ້ວັດເຊັ່ນ DAU (ຜູ້ໃຊ້ທີ່ໃຊ້ວຽກປະຈໍາວັນ), MAU (ຜູ້ໃຊ້ປະຈໍາເດືອນ), RPC (ຄໍາຮ້ອງຂໍຕໍ່ວິນາທີ), ແລະ TPC (ການເຮັດທຸລະກໍາຕໍ່ວິນາທີ) ເພາະວ່າມັນສາມາດຊ່ວຍໃຫ້ທ່ານເລືອກເພາະວ່າສະຖາປັດຕະຍະກໍາສໍາລັບ 100 ຜູ້ໃຊ້ທີ່ໃຊ້ວຽກແລະ 100 ລ້ານຄົນທີ່ໃຊ້ວຽກແມ່ນແຕກຕ່າງກັນ.
ໃນຖານະເປັນບັນທຶກສຸດທ້າຍ, ຂ້າພະເຈົ້າຈະເວົ້າວ່າສະຖາປັດຕະຍະກໍາມີຜົນກະທົບຢ່າງຫຼວງຫຼາຍຕໍ່ຄວາມສໍາເລັດຂອງຜະລິດຕະພັນ. ສະຖາປັດຕະຍະກໍາທີ່ອອກແບບບໍ່ດີສໍາລັບຜະລິດຕະພັນແມ່ນຈໍາເປັນໃນການປັບຂະຫນາດ, ເຊິ່ງອາດຈະນໍາໄປສູ່ຄວາມລົ້ມເຫຼວເພາະວ່າລູກຄ້າຈະບໍ່ລໍຖ້າໃນຂະນະທີ່ທ່ານປັບຂະຫນາດຂອງລະບົບ, ພວກເຂົາຈະເລືອກເອົາຄູ່ແຂ່ງ, ດັ່ງນັ້ນພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ລ່ວງຫນ້າຂອງຂະຫນາດທີ່ມີທ່າແຮງ. ເຖິງແມ່ນວ່າຂ້າພະເຈົ້າຍອມຮັບວ່າບາງຄັ້ງມັນບໍ່ສາມາດເປັນວິທີການ lean, ແນວຄວາມຄິດແມ່ນເພື່ອໃຫ້ມີລະບົບທີ່ສາມາດປັບຂະ ໜາດ ໄດ້ແຕ່ຍັງບໍ່ທັນໄດ້ຂະ ໜາດ ໄດ້. ໃນອີກດ້ານຫນຶ່ງ, ມີລະບົບທີ່ສັບສົນຫຼາຍແລະຂະຫນາດແລ້ວບໍ່ມີລູກຄ້າຫຼືແຜນການທີ່ຈະໄດ້ຮັບຈໍານວນຫຼາຍຂອງພວກມັນຈະເຮັດໃຫ້ເຈົ້າເສຍເງິນໃນທຸລະກິດຂອງທ່ານໂດຍບໍ່ມີຫຍັງເລີຍ.
ການເລືອກ stack ເທກໂນໂລຍີຍັງເປັນການຕັດສິນໃຈໃນລະດັບມະຫາພາກເນື່ອງຈາກມັນມີອິດທິພົນຕໍ່ການຈ້າງ, ທັດສະນະວິວັດທະນາການທໍາມະຊາດຂອງລະບົບ, ການຂະຫຍາຍຂະຫນາດ, ແລະການປະຕິບັດລະບົບ.
ນີ້ແມ່ນບັນຊີລາຍຊື່ຂອງການພິຈາລະນາພື້ນຖານສໍາລັບການເລືອກ stack ເຕັກໂນໂລຢີ:
ການມີ stacks ເທກໂນໂລຍີຫຼາຍສາມາດສົ່ງຜົນກະທົບຕໍ່ການເຕີບໂຕຂອງທຸລະກິດແນວໃດ?
ຈາກທັດສະນະຫນຶ່ງ, ການແນະນໍາຫນຶ່ງ stack ເພີ່ມເຕີມສາມາດຂະຫຍາຍການຈ້າງຂອງທ່ານ, ແຕ່ໃນອີກດ້ານຫນຶ່ງ, ມັນນໍາເອົາຄ່າໃຊ້ຈ່າຍໃນການບໍາລຸງຮັກສາເພີ່ມເຕີມນັບຕັ້ງແຕ່ທ່ານຕ້ອງການສະຫນັບສະຫນູນທັງສອງ stacks. ດັ່ງນັ້ນ, ດັ່ງທີ່ຂ້າພະເຈົ້າໄດ້ເວົ້າກ່ອນຫນ້ານີ້, ໃນທັດສະນະຂອງຂ້າພະເຈົ້າ, ພຽງແຕ່ຄວາມຕ້ອງການພິເສດຄວນຈະເປັນການໂຕ້ຖຽງສໍາລັບການລວມເອົາ stacks ເຕັກໂນໂລຢີຫຼາຍ.
ແຕ່ສິ່ງທີ່ກ່ຽວກັບຫຼັກການຂອງການເລືອກເຄື່ອງມືທີ່ດີທີ່ສຸດສໍາລັບບັນຫາສະເພາະໃດຫນຶ່ງ?
ບາງຄັ້ງທ່ານບໍ່ມີທາງເລືອກອື່ນນອກຈາກການນໍາເອົາເຄື່ອງມືໃຫມ່ເພື່ອແກ້ໄຂບັນຫາສະເພາະໃດຫນຶ່ງໂດຍອີງໃສ່ການພິຈາລະນາດຽວກັນຂ້າງເທິງ, ໃນກໍລະນີດັ່ງກ່າວ, ມັນເຮັດໃຫ້ຄວາມຮູ້ສຶກທີ່ຈະເລືອກເອົາການແກ້ໄຂທີ່ດີທີ່ສຸດ.
ການສ້າງລະບົບໂດຍບໍ່ມີການເຊື່ອມຕໍ່ສູງກັບເຕັກໂນໂລຢີສະເພາະອາດຈະເປັນສິ່ງທ້າທາຍ. ຢ່າງໃດກໍຕາມ, ມັນເປັນປະໂຫຍດທີ່ຈະພະຍາຍາມສໍາລັບເງື່ອນໄຂທີ່ລະບົບບໍ່ໄດ້ປະສົມປະສານຢ່າງແຫນ້ນຫນາກັບເຕັກໂນໂລຢີ, ແລະມັນຈະບໍ່ຕາຍຖ້າມື້ອື່ນ, ກອບຫຼືເຄື່ອງມືສະເພາະໃດຫນຶ່ງຈະກາຍເປັນຄວາມສ່ຽງຫຼືແມ້ກະທັ້ງການປະຕິເສດ.
ການພິຈາລະນາທີ່ສໍາຄັນອີກອັນຫນຶ່ງແມ່ນກ່ຽວຂ້ອງກັບການຂື້ນກັບຊອບແວ open-source ແລະເປັນເຈົ້າຂອງ. ຊອບແວທີ່ເປັນເຈົ້າຂອງເຮັດໃຫ້ທ່ານມີຄວາມຍືດຫຍຸ່ນຫນ້ອຍແລະຄວາມເປັນໄປໄດ້ທີ່ຈະໄດ້ຮັບການປັບແຕ່ງ. ຢ່າງໃດກໍຕາມ, ປັດໄຈທີ່ເປັນອັນຕະລາຍທີ່ສຸດແມ່ນການລັອກຂອງຜູ້ຂາຍ, ບ່ອນທີ່ທ່ານກາຍເປັນຂຶ້ນກັບຜະລິດຕະພັນຂອງຜູ້ຂາຍ, ລາຄາ, ຂໍ້ກໍານົດ, ແລະແຜນທີ່ຖະຫນົນ. ນີ້ສາມາດມີຄວາມສ່ຽງຖ້າຜູ້ຂາຍປ່ຽນທິດທາງ, ເພີ່ມລາຄາ, ຫຼືຢຸດເຊົາການຜະລິດຕະພັນ. ຊອບແວໂອເພນຊອດຫຼຸດຜ່ອນຄວາມສ່ຽງນີ້, ຍ້ອນວ່າຫນ່ວຍງານດຽວບໍ່ໄດ້ຄວບຄຸມມັນ. ການລົບລ້າງຈຸດດຽວຂອງຄວາມລົ້ມເຫລວໃນທຸກລະດັບແມ່ນເປັນກຸນແຈໃນການກໍ່ສ້າງລະບົບທີ່ເຊື່ອຖືໄດ້ເພື່ອການເຕີບໂຕ.
ຈຸດດຽວຂອງຄວາມລົ້ມເຫຼວ (SPOF) ຫມາຍເຖິງພາກສ່ວນໃດຫນຶ່ງຂອງລະບົບທີ່, ຖ້າມັນລົ້ມເຫລວ, ຈະເຮັດໃຫ້ລະບົບທັງຫມົດຢຸດການເຮັດວຽກ. ການກໍາຈັດ SPOFs ໃນທຸກລະດັບແມ່ນສໍາຄັນສໍາລັບລະບົບໃດກໍ່ຕາມທີ່ຕ້ອງການຄວາມພ້ອມສູງ. ທຸກຢ່າງ, ລວມທັງຄວາມຮູ້, ບຸກຄະລາກອນ, ອົງປະກອບຂອງລະບົບ, ຜູ້ໃຫ້ບໍລິການຄລາວ, ແລະສາຍອິນເຕີເນັດ, ສາມາດລົ້ມເຫລວໄດ້.
ມີຫຼາຍເຕັກນິກພື້ນຖານທີ່ພວກເຮົາສາມາດນຳໃຊ້ເພື່ອລົບລ້າງຈຸດດຽວຂອງຄວາມລົ້ມເຫລວ:
ໃນບົດຄວາມນີ້, ພວກເຮົາໄດ້ກວມເອົາຫຼາຍລັກສະນະ Macro ທີ່ສໍາຄັນແລະວິທີທີ່ພວກເຮົາສາມາດຈັດການກັບຄວາມສັບສົນຂອງເຂົາເຈົ້າ.
ຂອບໃຈສໍາລັບການອ່ານ! ແລ້ວພົບກັນໃນຄັ້ງຕໍ່ໄປ!