Microservices: ພວກມັນແມ່ນຫຍັງ, ເປັນຫຍັງພວກມັນແມ່ນແລະເວລາທີ່ຈະປະຕິບັດພວກມັນ

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

ກົດຫມາຍຂອງ Conway ແລະຄວາມສໍາພັນລະຫວ່າງທຸລະກິດ, ອົງການຈັດຕັ້ງແລະລະບົບຂໍ້ມູນຂ່າວສານ

ອີກເທື່ອ ໜຶ່ງ ຂ້ອຍຈະປ່ອຍໃຫ້ຕົວເອງອ້າງເຖິງ:

"ອົງການໃດກໍ່ຕາມທີ່ອອກແບບລະບົບ (ໃນຄວາມຫມາຍກວ້າງ) ຈະໄດ້ຮັບການອອກແບບທີ່ມີໂຄງສ້າງທີ່ replicates ໂຄງສ້າງຂອງທີມງານໃນອົງການຈັດຕັ້ງນັ້ນ."
— Melvyn Conway, 1967

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

ທິດທາງທຸລະກິດຂອງລະບົບຂໍ້ມູນຂ່າວສານ

ໃຫ້ຂ້ອຍອະທິບາຍດ້ວຍຕົວຢ່າງ. ໃຫ້ເວົ້າວ່າມີໂອກາດທາງທຸລະກິດທີ່ຈະຈັດທຸລະກິດຂາຍ pizza. ໃນຮຸ່ນ V1 (ໃຫ້ເອີ້ນວ່າຂໍ້ມູນເບື້ອງຕົ້ນ), ບໍລິສັດແມ່ນຮ້ານ pizzeria, ບັນຊີເງິນສົດ, ແລະບໍລິການຈັດສົ່ງ. ສະບັບນີ້ແມ່ນໃຊ້ໄດ້ດົນນານໃນສະພາບທີ່ມີການປ່ຽນແປງດ້ານສິ່ງແວດລ້ອມຕໍ່າ. ຫຼັງຈາກນັ້ນ, ຮຸ່ນ 2 ເຂົ້າມາແທນມັນ - ກ້າວຫນ້າທາງດ້ານຫຼາຍແລະສາມາດນໍາໃຊ້ລະບົບຂໍ້ມູນຂ່າວສານທີ່ເປັນຫຼັກສໍາລັບທຸລະກິດທີ່ມີສະຖາປັດຕະຍະກໍາ monolithic. ແລະໃນທີ່ນີ້, ໃນຄວາມຄິດເຫັນຂອງຂ້ອຍ, ມີຄວາມບໍ່ຍຸຕິທໍາທີ່ຮ້າຍແຮງທີ່ກ່ຽວຂ້ອງກັບ monoliths - ສະຖາປັດຕະຍະກຳ monolithic ຖືກກ່າວຫາວ່າບໍ່ກົງກັບຮູບແບບທຸລະກິດຂອງໂດເມນ. ແມ່ນແລ້ວ, ຖ້າເປັນດັ່ງນັ້ນ, ລະບົບຈະບໍ່ສາມາດເຮັດວຽກໄດ້ທັງຫມົດ - ກົງກັນຂ້າມກັບກົດຫມາຍ Conway ດຽວກັນແລະຄວາມຮູ້ສຶກທົ່ວໄປ. ບໍ່, ສະຖາປັດຕະຍະກໍາ monolithic ແມ່ນສອດຄ່ອງຢ່າງເຕັມສ່ວນກັບຮູບແບບທຸລະກິດໃນຂັ້ນຕອນຂອງການພັດທະນາທຸລະກິດນີ້ - ແນ່ນອນ, ຂ້ອຍຫມາຍເຖິງຂັ້ນຕອນທີ່ລະບົບໄດ້ຖືກສ້າງຂື້ນແລະປະຕິບັດແລ້ວ. ມັນ​ເປັນ​ຄວາມ​ຈິງ​ທີ່​ດີ​ເລີດ​ທີ່​ບໍ່​ວ່າ​ວິ​ທີ​ການ​ສະ​ຖາ​ປັດ​ຕະ​, ທັງ​ສອງ​ສະ​ຖາ​ປັດ​ຕະ​ຍະ​ກໍາ​ການ​ບໍ​ລິ​ການ​ຮັດ​ກຸມ 3 ແລະ​ສະ​ຖາ​ປັດ​ຕະ​ຈຸ​ລະ​ບໍ​ລິ​ການ N ຈະ​ເຮັດ​ວຽກ​ໄດ້​ຢ່າງ​ເທົ່າ​ທຽມ​ກັນ​. ຈັບແມ່ນຫຍັງ?

ທຸກສິ່ງທຸກຢ່າງໄຫຼ, ທຸກສິ່ງທຸກຢ່າງປ່ຽນແປງ, ຫຼືແມ່ນ microservices ເປັນວິທີການຕໍ່ສູ້ກັບຄວາມສັບສົນ?

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

ຜູ້ສະຫນັບສະຫນູນການນໍາໃຊ້ວິທີການ microservice ມັກຈະໂຕ້ຖຽງວ່າການທໍາລາຍ monolith ເຂົ້າໄປໃນ microservices ເຮັດໃຫ້ວິທີການພັດທະນາງ່າຍຂຶ້ນໂດຍການຫຼຸດຜ່ອນພື້ນຖານລະຫັດຂອງການບໍລິການສ່ວນບຸກຄົນ. ໃນຄວາມຄິດເຫັນຂອງຂ້ອຍ, ຄໍາຖະແຫຼງນີ້ແມ່ນບໍ່ມີເຫດຜົນຄົບຖ້ວນ. ຢ່າງຮຸນແຮງ, ການໂຕ້ຕອບທີ່ຊັດເຈນພາຍໃນລະຫັດ monolith ແລະ homogeneous ເບິ່ງຄືວ່າສັບສົນບໍ? ຖ້າເປັນແນວນີ້ແທ້ໆ, ໂຄງການທັງໝົດຈະຖືກສ້າງເປັນບໍລິການຈຸລະພາກ, ໃນຂະນະທີ່ການປະຕິບັດສະແດງໃຫ້ເຫັນວ່າການເຄື່ອນຍ້າຍຈາກ monolith ໄປຫາ microservices ແມ່ນມີຫຼາຍທົ່ວໄປ. ຄວາມສັບສົນບໍ່ໄດ້ຫາຍໄປ; ມັນພຽງແຕ່ຍ້າຍຈາກແຕ່ລະໂມດູນໄປຫາສ່ວນຕິດຕໍ່ (ບໍ່ວ່າຈະເປັນລົດເມຂໍ້ມູນ, RPC, APIs, ແລະໂປໂຕຄອນອື່ນໆ) ແລະລະບົບ orchestrating. ແລະນີ້ແມ່ນຍາກ!

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

ວົງຈອນຊີວິດຂອງຜະລິດຕະພັນແລະວົງຈອນຊີວິດການບໍລິການ

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

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

Microservices ເປັນວິທີການຕໍ່ສູ້ກັບຄວາມສັບສົນ ... ການຈັດການການຕັ້ງຄ່າ

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

ການຄົ້ນພົບ

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

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