paint-brush
ວິທີການຈັດການກັບຄວາມສັບສົນໃນເວລາທີ່ການອອກແບບລະບົບຊອບແວໂດຍ@fairday
64,488 ການອ່ານ
64,488 ການອ່ານ

ວິທີການຈັດການກັບຄວາມສັບສົນໃນເວລາທີ່ການອອກແບບລະບົບຊອບແວ

ໂດຍ Aleksei23m2024/02/05
Read on Terminal Reader
Read this story w/o Javascript

ຍາວເກີນໄປ; ອ່ານ

ຄວາມສັບສົນແມ່ນສັດຕູ! ໃຫ້ເຮົາຮຽນຮູ້ວິທີຈັດການກັບສິ່ງນັ້ນ!
featured image - ວິທີການຈັດການກັບຄວາມສັບສົນໃນເວລາທີ່ການອອກແບບລະບົບຊອບແວ
Aleksei HackerNoon profile picture

ມັນທັງຫມົດກ່ຽວກັບຫຍັງ?

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


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


Fantasy about keeping in mind a lot of bounded contexts

ກັບຄືນໄປຫາກົດຫມາຍຂອງ Conway, ຂ້າພະເຈົ້າໄດ້ພົບເຫັນບັນຫາຫຼາຍຢ່າງກັບມັນ.


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


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


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

ບານໃຫຍ່ຂອງຕົມ

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


Entertaining illustration made by ChatGPT

ເພື່ອຫຼີກເວັ້ນການສ້າງລະບົບປະເພດດັ່ງກ່າວ, ພວກເຮົາຈໍາເປັນຕ້ອງປະຕິບັດຕາມກົດລະບຽບແລະຂໍ້ຈໍາກັດສະເພາະ.

ສະຖາປັດຕະຍະກໍາລະບົບ

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


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


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


ແບບສະຖາປັດຕະຍະກໍາຊອບແວ ແມ່ນຊຸດຂອງຫຼັກການແລະຮູບແບບທີ່ກໍານົດວິທີການສ້າງຊອບແວ.


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


ສໍາລັບຕົວຢ່າງ, ເຊັ່ນ:

  1. ສະຖາປັດຕະຍະກໍາ Monolithic

  2. ການອອກແບບທີ່ຂັບເຄື່ອນໂດຍໂດເມນ

  3. ອີງໃສ່ອົງປະກອບ

  4. ການບໍລິການຈຸລະພາກ

  5. ທໍ່ແລະການກັ່ນຕອງ

  6. ເຫດການທີ່ຂັບເຄື່ອນ

  7. ໄມໂຄຣເຄນ

  8. ການບໍລິການແບບຮັດກຸມ


ແລະອື່ນໆ...


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


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


ຍຸດຕິ ທຳ, ນີ້ແມ່ນຫົວຂໍ້ທີ່ກວ້າງຂວາງຫຼາຍ, ແລະມີຫຼາຍແນວຄວາມຄິດທີ່ດີກ່ຽວກັບວິທີການສ້າງໂຄງສ້າງແລະລະບົບການວິວັດທະນາການທໍາມະຊາດ. ອີງຕາມປະສົບການຂອງຂ້ອຍ, ຂ້ອຍໄດ້ປະຕິບັດວິທີການດັ່ງຕໍ່ໄປນີ້:

  1. ເກືອບສະເຫມີເລີ່ມຕົ້ນດ້ວຍຮູບແບບສະຖາປັດຕະຍະກໍາ monolithic ນັບຕັ້ງແຕ່ມັນກໍາຈັດບັນຫາສ່ວນໃຫຍ່ທີ່ເກີດຂື້ນຍ້ອນລັກສະນະຂອງລະບົບການແຈກຢາຍ. ມັນຍັງເຮັດໃຫ້ຄວາມຮູ້ສຶກທີ່ຈະປະຕິບັດຕາມແບບໂມດູນ monolith ເພື່ອສຸມໃສ່ການສ້າງອົງປະກອບທີ່ມີຂອບເຂດທີ່ຊັດເຈນ. ການໃຊ້ວິທີການທີ່ອີງໃສ່ອົງປະກອບສາມາດຊ່ວຍໃຫ້ພວກເຂົາຕິດຕໍ່ສື່ສານກັບກັນແລະກັນໂດຍການນໍາໃຊ້ເຫດການ, ແຕ່ວ່າການໂທຫາໂດຍກົງ (aka RPC) ເຮັດໃຫ້ສິ່ງຕ່າງໆງ່າຍຂຶ້ນໃນຕອນເລີ່ມຕົ້ນ. ຢ່າງໃດກໍ່ຕາມ, ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະຕິດຕາມຄວາມເພິ່ງພາອາໄສລະຫວ່າງອົງປະກອບເພາະວ່າຖ້າອົງປະກອບ A ຮູ້ຫຼາຍກ່ຽວກັບອົງປະກອບ B, ບາງທີມັນອາດຈະເຮັດໃຫ້ຄວາມຮູ້ສຶກທີ່ຈະລວມພວກມັນເຂົ້າໄປໃນຫນຶ່ງ.
  2. ໃນເວລາທີ່ທ່ານເຂົ້າມາໃກ້ສະຖານະການໃນເວລາທີ່ທ່ານຕ້ອງການຂະຫນາດການພັດທະນາແລະລະບົບຂອງທ່ານ, ທ່ານສາມາດພິຈາລະນາປະຕິບັດຕາມຮູບແບບ Stangler ເພື່ອຄ່ອຍໆສະກັດອົງປະກອບທີ່ຈໍາເປັນຕ້ອງໄດ້ນໍາໃຊ້ຢ່າງເປັນເອກະລາດຫຼືແມ້ກະທັ້ງຂະຫນາດທີ່ມີຄວາມຕ້ອງການສະເພາະ.
  3. ດຽວນີ້, ຖ້າທ່ານມີວິໄສທັດທີ່ຈະແຈ້ງກ່ຽວກັບອະນາຄົດ, ເຊິ່ງເປັນໂຊກທີ່ບໍ່ ໜ້າ ເຊື່ອ, ທ່ານສາມາດຕັດສິນໃຈກ່ຽວກັບສະຖາປັດຕະຍະ ກຳ ທີ່ຕ້ອງການ. ໃນເວລານີ້, ທ່ານສາມາດຕັດສິນໃຈທີ່ຈະກ້າວໄປສູ່ສະຖາປັດຕະຍະກໍາຈຸລະພາກໂດຍການໃຊ້ວິທີການ Orchestration ແລະ Choreography, ການລວມເອົາຮູບແບບ CQRS ສໍາລັບການຂຽນແລະອ່ານຂະຫນາດເອກະລາດ, ຫຼືແມ້ກະທັ້ງການຕັດສິນໃຈທີ່ຈະຕິດກັບສະຖາປັດຕະຍະກໍາ monolithic ຖ້າມັນເຫມາະສົມກັບຄວາມຕ້ອງການຂອງທ່ານ.


ມັນຍັງມີຄວາມສໍາຄັນທີ່ຈະເຂົ້າໃຈຕົວເລກແລະຕົວຊີ້ວັດເຊັ່ນ DAU (ຜູ້ໃຊ້ທີ່ໃຊ້ວຽກປະຈໍາວັນ), MAU (ຜູ້ໃຊ້ປະຈໍາເດືອນ), RPC (ຄໍາຮ້ອງຂໍຕໍ່ວິນາທີ), ແລະ TPC (ການເຮັດທຸລະກໍາຕໍ່ວິນາທີ) ເພາະວ່າມັນສາມາດຊ່ວຍໃຫ້ທ່ານເລືອກເພາະວ່າສະຖາປັດຕະຍະກໍາສໍາລັບ 100 ຜູ້ໃຊ້ທີ່ໃຊ້ວຽກແລະ 100 ລ້ານຄົນທີ່ໃຊ້ວຽກແມ່ນແຕກຕ່າງກັນ.


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

ການຄັດເລືອກ stack ເຕັກໂນໂລຊີ

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


ນີ້ແມ່ນບັນຊີລາຍຊື່ຂອງການພິຈາລະນາພື້ນຖານສໍາລັບການເລືອກ stack ເຕັກໂນໂລຢີ:

  • ຄວາມຕ້ອງການໂຄງການແລະຄວາມຊັບຊ້ອນ. ຕົວຢ່າງເຊັ່ນ, ຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌ທີ່ງ່າຍດາຍສາມາດຖືກສ້າງຂຶ້ນດ້ວຍກອບ Blazor ຖ້ານັກພັດທະນາຂອງທ່ານມີປະສົບການກັບມັນ, ແຕ່ເນື່ອງຈາກຄວາມບໍ່ເປັນຜູ້ໃຫຍ່ຂອງ WebAssembly, ການເລືອກ React ແລະ Typescript ສໍາລັບຄວາມສໍາເລັດໃນໄລຍະຍາວອາດຈະເປັນການຕັດສິນໃຈທີ່ດີກວ່າ.
  • Scalability ແລະຄວາມຕ້ອງການປະສິດທິພາບ. ຖ້າທ່ານຄາດວ່າຈະໄດ້ຮັບການຈະລາຈອນຈໍານວນຫລາຍ, ການເລືອກ ASP.NET Core ໃນໄລຍະ Django ອາດຈະເປັນທາງເລືອກທີ່ສະຫລາດຍ້ອນການປະຕິບັດທີ່ເຫນືອກວ່າຂອງມັນໃນການຈັດການຄໍາຮ້ອງຂໍພ້ອມກັນ. ຢ່າງໃດກໍ່ຕາມ, ການຕັດສິນໃຈນີ້ແມ່ນຂຶ້ນກັບຂະຫນາດຂອງການຈະລາຈອນທີ່ທ່ານຄາດຫວັງ. ຖ້າທ່ານຕ້ອງການຈັດການການຮ້ອງຂໍທີ່ມີທ່າແຮງຫຼາຍຕື້ຄໍາທີ່ມີເວລາ latency ຕ່ໍາ, ການປະກົດຕົວຂອງການເກັບຂີ້ເຫຍື້ອອາດຈະເປັນສິ່ງທ້າທາຍ.
  • ຈ້າງ, ເວລາພັດທະນາ, ແລະຄ່າໃຊ້ຈ່າຍ. ໃນກໍລະນີຫຼາຍທີ່ສຸດ, ເຫຼົ່ານີ້ແມ່ນປັດໃຈທີ່ພວກເຮົາຕ້ອງເອົາໃຈໃສ່. ເວລາໃນການຕະຫຼາດ, ຄ່າໃຊ້ຈ່າຍໃນການຮັກສາ, ແລະຄວາມຫມັ້ນຄົງຂອງການຈ້າງງານເຮັດໃຫ້ຄວາມຕ້ອງການຂອງທຸລະກິດຂອງທ່ານໂດຍບໍ່ມີອຸປະສັກ.
  • ຄວາມຊໍານານຂອງທີມງານແລະຊັບພະຍາກອນ. ຊຸດທັກສະຂອງທີມງານພັດທະນາຂອງທ່ານແມ່ນປັດໃຈສໍາຄັນ. ໂດຍທົ່ວໄປແລ້ວມັນມີປະສິດທິພາບຫຼາຍຂຶ້ນໃນການນໍາໃຊ້ເຕັກໂນໂລຢີທີ່ທີມງານຂອງທ່ານຄຸ້ນເຄີຍແລ້ວ, ເວັ້ນເສຍແຕ່ວ່າມີເຫດຜົນທີ່ເຂັ້ມແຂງທີ່ຈະລົງທຶນໃນການຮຽນຮູ້ stack ໃຫມ່.
  • ຄວາມເປັນຜູ້ໃຫຍ່. ຊຸມຊົນທີ່ເຂັ້ມແຂງແລະລະບົບນິເວດທີ່ອຸດົມສົມບູນຂອງຫ້ອງສະຫມຸດແລະເຄື່ອງມືສາມາດຜ່ອນຄາຍຂະບວນການພັດທະນາຢ່າງຫຼວງຫຼາຍ. ເທກໂນໂລຍີທີ່ນິຍົມມັກຈະມີການສະຫນັບສະຫນູນຊຸມຊົນທີ່ດີກວ່າ, ເຊິ່ງສາມາດມີຄ່າສໍາລັບການແກ້ໄຂບັນຫາແລະການຊອກຫາຊັບພະຍາກອນ. ດັ່ງນັ້ນ, ທ່ານສາມາດປະຫຍັດຊັບພະຍາກອນແລະສຸມໃສ່ຜະລິດຕະພັນຕົ້ນຕໍ.
  • ການບໍາລຸງຮັກສາແລະການສະຫນັບສະຫນູນໃນໄລຍະຍາວ. ພິຈາລະນາຄວາມເປັນໄປໄດ້ໃນໄລຍະຍາວຂອງເຕັກໂນໂລຢີ. ເຕັກໂນໂລຢີທີ່ໄດ້ຮັບການຮັບຮອງເອົາຢ່າງກວ້າງຂວາງແລະສະຫນັບສະຫນູນແມ່ນຫນ້ອຍທີ່ຈະລ້າສະໄຫມແລະໂດຍທົ່ວໄປໄດ້ຮັບການປັບປຸງແລະປັບປຸງເປັນປົກກະຕິ.


ການມີ stacks ເທກໂນໂລຍີຫຼາຍສາມາດສົ່ງຜົນກະທົບຕໍ່ການເຕີບໂຕຂອງທຸລະກິດແນວໃດ?

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


ແຕ່ສິ່ງທີ່ກ່ຽວກັບຫຼັກການຂອງການເລືອກເຄື່ອງມືທີ່ດີທີ່ສຸດສໍາລັບບັນຫາສະເພາະໃດຫນຶ່ງ?

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


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


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

ຈຸດດຽວຂອງຄວາມລົ້ມເຫລວ (SPOF)

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


ມີຫຼາຍເຕັກນິກພື້ນຖານທີ່ພວກເຮົາສາມາດນຳໃຊ້ເພື່ອລົບລ້າງຈຸດດຽວຂອງຄວາມລົ້ມເຫລວ:

  1. ຊ້ຳຊ້ອນ. ປະຕິບັດການຊ້ໍາຊ້ອນສໍາລັບອົງປະກອບທີ່ສໍາຄັນ. ນີ້ຫມາຍຄວາມວ່າມີສ່ວນປະກອບສໍາຮອງທີ່ສາມາດປະຕິບັດໄດ້ຖ້າຫາກວ່າອົງປະກອບຕົ້ນຕໍລົ້ມເຫລວ. ການຊໍ້າຊ້ອນສາມາດຖືກນໍາໃຊ້ໃນທົ່ວຊັ້ນຕ່າງໆຂອງລະບົບ, ລວມທັງຮາດແວ (ເຄື່ອງແມ່ຂ່າຍ, ແຜ່ນ), ເຄືອຂ່າຍ (ການເຊື່ອມຕໍ່, ສະຫຼັບ), ແລະຊອບແວ (ຖານຂໍ້ມູນ, ເຄື່ອງແມ່ຂ່າຍຂອງຄໍາຮ້ອງສະຫມັກ). ຖ້າທ່ານກໍາລັງໂຮດທຸກສິ່ງທຸກຢ່າງຢູ່ໃນຜູ້ໃຫ້ບໍລິການ Cloud ຫນຶ່ງແລະແມ້ກະທັ້ງມີການສໍາຮອງຂໍ້ມູນຢູ່ທີ່ນັ້ນ, ພິຈາລະນາສ້າງການສໍາຮອງຂໍ້ມູນປົກກະຕິເພີ່ມເຕີມໃນບ່ອນອື່ນເພື່ອຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍທີ່ສູນເສຍຂອງທ່ານໃນກໍລະນີໄພພິບັດ.
  2. ສູນຂໍ້ມູນ. ແຈກຢາຍລະບົບຂອງທ່ານໃນທົ່ວສະຖານທີ່ທາງດ້ານຮ່າງກາຍ, ເຊັ່ນ: ສູນຂໍ້ມູນຫຼືພາກພື້ນຟັງ. ວິທີການນີ້ປົກປ້ອງລະບົບຂອງທ່ານຈາກຄວາມລົ້ມເຫຼວຂອງສະຖານທີ່ສະເພາະເຊັ່ນ: ໄຟໄຫມ້ຫຼືໄພພິບັດທໍາມະຊາດ.
  3. ລົ້ມເຫລວ. ນຳໃຊ້ວິທີການລົ້ມເຫລວສຳລັບອົງປະກອບທັງໝົດຂອງທ່ານ (DNS, CDN, Load balancers, Kubernetes, API Gateways ແລະ Databases). ເນື່ອງຈາກບັນຫາສາມາດເກີດຂຶ້ນໄດ້ໂດຍບໍ່ຄາດຄິດ, ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະຕ້ອງມີແຜນການສຳຮອງເພື່ອທົດແທນອົງປະກອບໃດນຶ່ງດ້ວຍຕົວໂຄນຂອງມັນຕາມຄວາມຕ້ອງການຢ່າງວ່ອງໄວ.
  4. ການບໍລິການທີ່ມີໃຫ້ສູງ. ໃຫ້ແນ່ໃຈວ່າການບໍລິການຂອງທ່ານຖືກສ້າງຂຶ້ນເພື່ອໃຫ້ສາມາດຂະຫຍາຍໄດ້ຕາມລວງນອນ ແລະມີຢູ່ສູງຕັ້ງແຕ່ເລີ່ມຕົ້ນໂດຍການປະຕິບັດຕາມຫຼັກການຕໍ່ໄປນີ້:
    • ປະຕິບັດການບໍລິການທີ່ບໍ່ມີລັດແລະຫຼີກເວັ້ນການເກັບຮັກສາເຊດຊັນຂອງຜູ້ໃຊ້ໄວ້ໃນແຄດໃນຫນ່ວຍຄວາມຈໍາ. ແທນທີ່ຈະ, ໃຊ້ລະບົບ cache ທີ່ແຈກຢາຍ, ເຊັ່ນ Redis.
    • ຫຼີກເວັ້ນການອີງໃສ່ຄໍາສັ່ງ chronological ຂອງການບໍລິໂພກຂໍ້ຄວາມໃນເວລາທີ່ການພັດທະນາຕາມເຫດຜົນ.
    • ຫຼຸດຜ່ອນການປ່ຽນແປງທີ່ແຕກຫັກເພື່ອປ້ອງກັນການລົບກວນຜູ້ບໍລິໂພກ API. ຖ້າເປັນໄປໄດ້, ເລືອກການປ່ຽນແປງທີ່ເຂົ້າກັນໄດ້ກັບຫຼັງ. ນອກຈາກນັ້ນ, ພິຈາລະນາຄ່າໃຊ້ຈ່າຍນັບຕັ້ງແຕ່ບາງຄັ້ງ, ການປະຕິບັດການປ່ຽນແປງທີ່ແຕກຫັກອາດຈະເປັນຄ່າໃຊ້ຈ່າຍຫຼາຍ.
    • ລວມເອົາການປະຕິບັດການເຄື່ອນຍ້າຍເຂົ້າໄປໃນທໍ່ສົ່ງ.
    • ສ້າງຍຸດທະສາດສໍາລັບການຈັດການຄໍາຮ້ອງຂໍພ້ອມກັນ.
    • ປະຕິບັດການຄົ້ນພົບການບໍລິການ, ການຕິດຕາມ, ແລະການຕັດໄມ້ເພື່ອເພີ່ມຄວາມຫນ້າເຊື່ອຖືແລະການສັງເກດການ.
    • ພັດທະນາເຫດຜົນທາງທຸລະກິດໃຫ້ເປັນ ideempotent, ຍອມຮັບວ່າຄວາມລົ້ມເຫຼວຂອງເຄືອຂ່າຍແມ່ນ inevitable.
  5. ການທົບທວນຄືນການເພິ່ງພາອາໄສ. ທົບທວນເປັນປົກກະຕິແລະຫຼຸດຜ່ອນການຂຶ້ນກັບພາຍນອກ. ແຕ່ລະການເພິ່ງພາອາໄສພາຍນອກສາມາດແນະນໍາ SPOFs ທີ່ມີທ່າແຮງ, ດັ່ງນັ້ນມັນເປັນສິ່ງຈໍາເປັນທີ່ຈະເຂົ້າໃຈແລະຫຼຸດຜ່ອນຄວາມສ່ຽງເຫຼົ່ານີ້.
  6. ແບ່ງປັນຄວາມຮູ້ເປັນປົກກະຕິ. ຢ່າລືມຄວາມສໍາຄັນຂອງການເຜີຍແຜ່ຄວາມຮູ້ພາຍໃນອົງການຂອງເຈົ້າ. ຄົນເຮົາບໍ່ສາມາດຄາດເດົາໄດ້, ແລະການເພິ່ງພາຄົນດຽວແມ່ນມີຄວາມສ່ຽງ. ຊຸກຍູ້ໃຫ້ສະມາຊິກທີມສ້າງຄວາມຮູ້ຂອງເຂົາເຈົ້າເປັນດິຈິຕອນຜ່ານເອກະສານ. ຢ່າງໃດກໍຕາມ, ຈົ່ງເອົາໃຈໃສ່ກັບເອກະສານຫຼາຍເກີນໄປ. ໃຊ້ເຄື່ອງມື AI ຕ່າງໆເພື່ອເຮັດໃຫ້ຂະບວນການນີ້ງ່າຍຂຶ້ນ.

ສະຫຼຸບ

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


ຂອບໃຈສໍາລັບການອ່ານ! ແລ້ວພົບກັນໃນຄັ້ງຕໍ່ໄປ!

L O A D I N G
. . . comments & more!

About Author

Aleksei HackerNoon profile picture
Aleksei@fairday
Hey, I am Alex, a dedicated Software Development Engineer with experience in the .NET environment and architecture

ວາງປ້າຍ

ບົດ​ຄວາມ​ນີ້​ໄດ້​ຖືກ​ນໍາ​ສະ​ເຫນີ​ໃນ...