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

ການ​ຕັ້ງ​ຄ່າ​: ຈາກ​ທາງ​ເຄ​ມີ​ພື້ນ​ຖານ​ກັບ​ກົນ​ໄກ​ການ quantum​

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

ລະບົບບໍ່ເຂົ້າໃຈງ່າຍ

ໃຫ້ພວກເຮົາສຸມໃສ່ການ junior ຂອງພວກເຮົາສໍາລັບປັດຈຸບັນ. ດ້ວຍຄໍາຮ້ອງສະຫມັກ monolithic, ຖ້າມີຂໍ້ຜິດພາດເກີດຂື້ນ, ມັນງ່າຍທີ່ຈະຕິດຕາມມັນລົງແລະທັນທີທັນໃດເພື່ອແກ້ໄຂບັນຫາ. ຕອນນີ້ພວກເຮົາມີບໍລິການທີ່ກໍາລັງລົມກັບບໍລິການອື່ນທີ່ກໍາລັງຈັດຄິວບາງສິ່ງບາງຢ່າງຢູ່ໃນລົດເມຂໍ້ຄວາມທີ່ກໍາລັງດໍາເນີນການບໍລິການອື່ນ - ແລະຫຼັງຈາກນັ້ນມີຂໍ້ຜິດພາດເກີດຂື້ນ. ພວກເຮົາຕ້ອງເອົາຊິ້ນສ່ວນເຫຼົ່ານີ້ທັງຫມົດຮ່ວມກັນເພື່ອຄົ້ນພົບວ່າບໍລິການ A ກໍາລັງແລ່ນເວີຊັນ 11, ແລະບໍລິການ E ກໍາລັງລໍຖ້າສໍາລັບຮຸ່ນ 12. ນີ້ແຕກຕ່າງຈາກບັນທຶກລວມມາດຕະຖານຂອງຂ້ອຍ: ຈະຕ້ອງໃຊ້ terminal / debugger ແບບໂຕ້ຕອບເພື່ອຍ່າງ. ໂດຍຜ່ານຂັ້ນຕອນໂດຍຂັ້ນຕອນ. ການດີບັ໊ກ ແລະຄວາມເຂົ້າໃຈປະກົດຂຶ້ນກາຍເປັນເລື່ອງຍາກຂຶ້ນ.

ຖ້າມັນບໍ່ສາມາດດີບັກໄດ້, ບາງທີພວກເຮົາຈະທົດສອບພວກມັນ

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

ການປະນີປະນອມທັງຫມົດມີເຫດຜົນທີ່ດີ. ສິດ?

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

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

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