Microservices - ການລະເບີດແບບປະສົມປະສານຂອງຮຸ່ນ

ສະບາຍດີ, Habr! ຂ້າພະເຈົ້ານໍາສະເຫນີຄວາມສົນໃຈຂອງທ່ານ ການແປຂອງຜູ້ຂຽນຂອງບົດຄວາມ Microservices – ການລະເບີດແບບປະສົມປະສານຂອງລຸ້ນ.

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

ຖ້າທ່ານຍັງບໍ່ເຂົ້າໃຈບັນຫາໂດຍການອ່ານຂໍ້ຄວາມນີ້, ໃຫ້ຂ້ອຍອະທິບາຍ. ໃຫ້ເວົ້າວ່າຜະລິດຕະພັນຂອງທ່ານປະກອບດ້ວຍ 10 microservices. ຕອນນີ້ໃຫ້ສົມມຸດວ່າ 1 ຮຸ່ນໃຫມ່ຖືກປ່ອຍອອກມາສໍາລັບແຕ່ລະ microservices ເຫຼົ່ານີ້. ພຽງແຕ່ 1 ສະບັບ - ຂ້າພະເຈົ້າຫວັງວ່າພວກເຮົາທຸກຄົນສາມາດຕົກລົງເຫັນດີວ່ານີ້ແມ່ນຄວາມຈິງທີ່ trivial ແລະ insignificant ຫຼາຍ. ດຽວນີ້, ແນວໃດກໍ່ຕາມ, ໃຫ້ພິຈາລະນາຜະລິດຕະພັນຂອງພວກເຮົາອີກຢ່າງ ໜຶ່ງ. ມີພຽງແຕ່ສະບັບໃຫມ່ຂອງແຕ່ລະອົງປະກອບ, ໃນປັດຈຸບັນພວກເຮົາມີ 2^10 - ຫຼື 1024 permutations ຂອງວິທີການຜະລິດຕະພັນຂອງພວກເຮົາສາມາດປະກອບ.

ຖ້າ​ຫາກ​ວ່າ​ຍັງ​ມີ​ຄວາມ​ເຂົ້າ​ໃຈ​ຜິດ​ພາດ​, ຂ້າ​ພະ​ເຈົ້າ​ຂໍ​ແບ່ງ​ປັນ​ຄະ​ນິດ​ສາດ​ໄດ້​. ດັ່ງນັ້ນພວກເຮົາມີ 10 microservices, ແຕ່ລະຄົນໄດ້ຮັບການປັບປຸງຫນຶ່ງ. ນັ້ນແມ່ນ, ພວກເຮົາໄດ້ຮັບ 2 ຮຸ່ນທີ່ເປັນໄປໄດ້ສໍາລັບແຕ່ລະ microservice (ບໍ່ວ່າຈະເກົ່າຫຼືໃຫມ່). ໃນປັດຈຸບັນ, ສໍາລັບແຕ່ລະອົງປະກອບຂອງຜະລິດຕະພັນ, ພວກເຮົາສາມາດນໍາໃຊ້ທັງສອງສະບັບນີ້. ໃນທາງຄະນິດສາດ, ມັນຄືກັນກັບວ່າພວກເຮົາມີເລກຖານສອງຂອງ 10 ຕົວເລກ. ຕົວຢ່າງ, ໃຫ້ເວົ້າວ່າ 1 ແມ່ນຮຸ່ນໃຫມ່, ແລະ 0 ແມ່ນຮຸ່ນເກົ່າ - ຫຼັງຈາກນັ້ນ, ການປ່ຽນແປງທີ່ເປັນໄປໄດ້ຫນຶ່ງສາມາດຫມາຍເຖິງ 1001000000 - ບ່ອນທີ່ອົງປະກອບທີ 1 ແລະທີ 4 ໄດ້ຖືກປັບປຸງ, ແລະອື່ນໆທັງຫມົດບໍ່ແມ່ນ. ຈາກຄະນິດສາດພວກເຮົາຮູ້ວ່າຕົວເລກຖານສອງ 10 ຕົວເລກສາມາດມີ 2^10 ຫຼື 1024 ຄ່າ. ນັ້ນແມ່ນ, ພວກເຮົາໄດ້ຢືນຢັນຂະຫນາດຂອງຕົວເລກທີ່ພວກເຮົາກໍາລັງຈັດການກັບ.

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

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

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

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

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

ລະບົບການທົດລອງດັ່ງກ່າວສາມາດມີລັກສະນະນີ້:

1. ນັກພັດທະນາຂຽນການທົດສອບ (ນີ້ແມ່ນຂັ້ນຕອນທີ່ສໍາຄັນ - ເພາະວ່າຖ້າບໍ່ດັ່ງນັ້ນພວກເຮົາບໍ່ມີເງື່ອນໄຂການປະເມີນຜົນ - ມັນຄ້າຍຄືກັບການຕິດສະຫຼາກຂໍ້ມູນໃນການຮຽນຮູ້ເຄື່ອງຈັກ).
2. ແຕ່ລະອົງປະກອບ (ໂຄງການ) ໄດ້ຮັບລະບົບ CI ຂອງຕົນເອງ - ໃນປັດຈຸບັນຂະບວນການນີ້ໄດ້ຖືກພັດທະນາດີ, ແລະບັນຫາຂອງການສ້າງລະບົບ CI ສໍາລັບອົງປະກອບດຽວໄດ້ຖືກແກ້ໄຂຢ່າງຫຼວງຫຼາຍ.
3. "ລະບົບການເຊື່ອມໂຍງທີ່ສະຫຼາດ" ລວບລວມຜົນໄດ້ຮັບຂອງລະບົບ CI ຕ່າງໆແລະປະກອບໂຄງການອົງປະກອບເຂົ້າໄປໃນຜະລິດຕະພັນສຸດທ້າຍ, ດໍາເນີນການທົດສອບແລະສຸດທ້າຍຈະຄິດໄລ່ເສັ້ນທາງທີ່ສັ້ນທີ່ສຸດທີ່ຈະໄດ້ຮັບການເຮັດວຽກຂອງຜະລິດຕະພັນທີ່ຕ້ອງການໂດຍອີງໃສ່ອົງປະກອບແລະປັດໃຈຄວາມສ່ຽງທີ່ມີຢູ່. ຖ້າການອັບເດດເປັນໄປບໍ່ໄດ້, ລະບົບນີ້ຈະແຈ້ງໃຫ້ຜູ້ພັດທະນາກ່ຽວກັບອົງປະກອບທີ່ມີຢູ່ແລ້ວ ແລະອັນໃດທີ່ເຮັດໃຫ້ເກີດຄວາມຜິດພາດ. ອີກເທື່ອ ໜຶ່ງ, ລະບົບການທົດສອບແມ່ນມີຄວາມ ສຳ ຄັນຫຼາຍຢູ່ທີ່ນີ້ - ເພາະວ່າລະບົບການເຊື່ອມໂຍງໃຊ້ການທົດສອບເປັນເງື່ອນໄຂການປະເມີນຜົນ.
4. ລະບົບ CD, ເຊິ່ງຫຼັງຈາກນັ້ນໄດ້ຮັບຂໍ້ມູນຈາກ Smart Integration System ແລະດໍາເນີນການປັບປຸງໂດຍກົງ. ຂັ້ນຕອນນີ້ສິ້ນສຸດຮອບວຽນ.

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

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

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

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