Microservices: ຂະຫນາດເປັນເລື່ອງສໍາຄັນ, ເຖິງແມ່ນວ່າທ່ານມີ Kubernetes

ວັນທີ 19 ກັນຍາ ຢູ່ມົສກູ ໄດ້ຈັດຂຶ້ນ ກອງປະຊຸມຫົວຂໍ້ທໍາອິດ HUG (ກຸ່ມຜູ້ໃຊ້ທີ່ສູງ ++), ເຊິ່ງອຸທິດຕົນເພື່ອການບໍລິການຈຸນລະພາກ. ມີການນໍາສະເຫນີ "Operating Microservices: Size Matters, ເຖິງແມ່ນວ່າທ່ານມີ Kubernetes," ເຊິ່ງພວກເຮົາໄດ້ແບ່ງປັນປະສົບການຢ່າງກວ້າງຂວາງຂອງ Flant ໃນໂຄງການປະຕິບັດງານທີ່ມີສະຖາປັດຕະຍະກໍາຈຸລະພາກ. ກ່ອນອື່ນ ໝົດ, ມັນຈະເປັນປະໂຫຍດຕໍ່ນັກພັດທະນາທຸກຄົນທີ່ຄິດກ່ຽວກັບການໃຊ້ວິທີການນີ້ໃນໂຄງການໃນປະຈຸບັນຫຼືໃນອະນາຄົດຂອງພວກເຂົາ.

ແນະນຳ ວິ​ດີ​ໂອ​ຂອງ​ບົດ​ລາຍ​ງານ​ (50 ນາທີ, ມີຂໍ້ມູນຫຼາຍກວ່າບົດຄວາມ), ເຊັ່ນດຽວກັນກັບສານສະກັດຈາກມັນໃນຮູບແບບຂໍ້ຄວາມ.

NB: ວິດີໂອ ແລະການນຳສະເໜີຍັງມີຢູ່ໃນຕອນທ້າຍຂອງໂພສນີ້.

ການນໍາສະເຫນີ

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

ຂ້ອຍຈະເລີ່ມຕົ້ນດ້ວຍກາຟນີ້, ຜູ້ຂຽນຂອງທີ່ (ໃນປີ 2015) ກາຍເປັນ Martin Fowler:

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

ຂ້ອຍຈະເພີ່ມໃສ່ກາຟນີ້ສໍາລັບກໍລະນີຂອງການໃຊ້ Kubernetes:

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

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

microservices ທີ່ເປັນປະໂຫຍດແລະເປັນອັນຕະລາຍ

ແລະນີ້ແມ່ນແນວຄວາມຄິດຕົ້ນຕໍ:

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

ຖ້າທ່ານໂທຫານາງ ເປັນປະໂຫຍດ, ຫຼັງຈາກນັ້ນໃນອີກດ້ານຫນຶ່ງຂອງກາຟຈະມີ ເປັນອັນຕະລາຍ microservices (ແຊກແຊງການເຮັດວຽກ):

ກັບຄືນໄປຫາ "ຄວາມຄິດຕົ້ນຕໍ": ຂ້ອຍຄວນໄວ້ວາງໃຈປະສົບການຂອງຂ້ອຍບໍ? ຕັ້ງແຕ່ຕົ້ນປີນີ້ຂ້ອຍໄດ້ເບິ່ງ 85 ໂຄງການ. ບໍ່ແມ່ນທັງຫມົດຂອງພວກເຂົາແມ່ນ microservices (ປະມານຫນຶ່ງສ່ວນສາມຫາເຄິ່ງຫນຶ່ງຂອງພວກເຂົາມີສະຖາປັດຕະຍະກໍາດັ່ງກ່າວ), ແຕ່ນີ້ຍັງເປັນຈໍານວນຂະຫນາດໃຫຍ່. ພວກເຮົາ (ບໍລິສັດ Flant) ເປັນຜູ້ຄຸ້ມຄອງເພື່ອເຂົ້າໄປເບິ່ງຄວາມຫຼາກຫຼາຍຂອງຄໍາຮ້ອງສະຫມັກທີ່ພັດທະນາທັງໃນບໍລິສັດຂະຫນາດນ້ອຍ (ມີ 5 ນັກພັດທະນາ) ແລະໃນຂະຫນາດໃຫຍ່ (~500 ນັກພັດທະນາ). ຜົນປະໂຫຍດເພີ່ມເຕີມແມ່ນວ່າພວກເຮົາເຫັນຄໍາຮ້ອງສະຫມັກເຫຼົ່ານີ້ດໍາລົງຊີວິດແລະພັດທະນາໃນໄລຍະປີ.

ເປັນຫຍັງບໍລິການຈຸລະພາກ?

ຕໍ່ຄໍາຖາມກ່ຽວກັບຜົນປະໂຫຍດຂອງການບໍລິການຈຸລະພາກມີ ຄໍາຕອບສະເພາະຫຼາຍ ຈາກ Martin Fowler ທີ່ໄດ້ກ່າວມາແລ້ວ:

1. ຂອບເຂດທີ່ຊັດເຈນຂອງ modularity;
2. ການນຳໃຊ້ເອກະລາດ;
3. ສິດເສລີພາບໃນການເລືອກເຕັກໂນໂລຢີ.

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

ຖ້າພວກເຮົາອະທິບາຍບາງຈຸດ "ໃນຄວາມຮູ້ສຶກ", ຫຼັງຈາກນັ້ນ:

• ຂອບເຂດທີ່ຊັດເຈນຂອງໂມດູນ: ໃນທີ່ນີ້ພວກເຮົາມີ monolith ຂີ້ຮ້າຍ, ແລະໃນປັດຈຸບັນທຸກສິ່ງທຸກຢ່າງຈະຖືກຈັດລຽງຢ່າງເປັນລະບຽບຢູ່ໃນບ່ອນເກັບມ້ຽນ Git, ເຊິ່ງທຸກສິ່ງທຸກຢ່າງແມ່ນ "ຢູ່ເທິງຊັ້ນວາງ", ຄວາມອົບອຸ່ນແລະຄວາມອ່ອນໂຍນບໍ່ໄດ້ຖືກປະສົມ;
• deployment independence: ພວກ​ເຮົາ​ຈະ​ສາ​ມາດ​ເປີດ​ບໍ​ລິ​ການ​ເປັນ​ອິດ​ສະ​ຫຼະ​ເພື່ອ​ໃຫ້​ການ​ພັດ​ທະ​ນາ​ໄວ​ຂຶ້ນ (ເຜີຍ​ແຜ່​ລັກ​ສະ​ນະ​ໃຫມ່​ຂະ​ຫນານ​)​;
• ຄວາມເປັນເອກະລາດຂອງການພັດທະນາ: ພວກເຮົາສາມາດໃຫ້ການບໍລິການຈຸນລະພາກນີ້ໃຫ້ກັບທີມງານຫນຶ່ງ / ນັກພັດທະນາ, ແລະໃຫ້ຄົນອື່ນ, ຂອບໃຈທີ່ພວກເຮົາສາມາດພັດທະນາໄວຂຶ້ນ;
• боຄວາມຫນ້າເຊື່ອຖືຫຼາຍກວ່າເກົ່າ: ຖ້າການເຊື່ອມໂຊມບາງສ່ວນເກີດຂື້ນ (ຫນຶ່ງ microservice ອອກຈາກ 20 ຫຼຸດລົງ), ຫຼັງຈາກນັ້ນພຽງແຕ່ກົດປຸ່ມດຽວຈະຢຸດເຮັດວຽກ, ແລະລະບົບທັງຫມົດຈະສືບຕໍ່ເຮັດວຽກ.

ສະຖາປັດຕະຍະກຳບໍລິການຈຸນລະພາກແບບປົກກະຕິ (ເປັນອັນຕະລາຍ).

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

ຕົວຢ່າງອາດຈະເປັນຮ້ານອອນໄລນ໌ທີ່ບໍ່ມີຕົວຕົນທີ່ຈະແຂ່ງຂັນກັບ Amazon ຫຼືຢ່າງຫນ້ອຍ OZON. ສະຖາປັດຕະຍະກໍາ microservice ຂອງມັນມີລັກສະນະນີ້:

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

ເນື່ອງຈາກແຕ່ລະ microservice ຕ້ອງມີເອກະລາດ, ຈໍານວນຫຼາຍຂອງພວກເຂົາຕ້ອງການຖານຂໍ້ມູນແລະ cache ຂອງຕົນເອງ. ສະຖາປັດຕະຍະກໍາສຸດທ້າຍມີດັ່ງນີ້:

ຜົນສະທ້ອນຂອງມັນແມ່ນຫຍັງ?

Fowler ມີອັນນີ້ຄືກັນ ມີບົດຄວາມ — ກ່ຽວ​ກັບ "ການ​ຊໍາ​ລະ​ເງິນ​" ສໍາ​ລັບ​ການ​ນໍາ​ໃຊ້ microservices​:

ແລະພວກເຮົາຈະເບິ່ງວ່າຄວາມຄາດຫວັງຂອງພວກເຮົາຖືກບັນລຸໄດ້ຫຼືບໍ່.

ແບ່ງເຂດແດນຂອງໂມດູນ...

ແຕ່ວ່າ ພວກເຮົາຕ້ອງການແກ້ໄຂ microservices ຫຼາຍປານໃດ?ເປີດຕົວການປ່ຽນແປງ? ພວກເຮົາສາມາດຄິດອອກໄດ້ວ່າທຸກຢ່າງເຮັດວຽກແນວໃດໂດຍບໍ່ມີການຕິດຕາມທີ່ແຈກຢາຍ (ຫຼັງຈາກທັງຫມົດ, ການຮ້ອງຂໍໃດໆແມ່ນດໍາເນີນການໂດຍເຄິ່ງຫນຶ່ງຂອງ microservices)?

ມີຮູບແບບ "ກ້ອນໃຫຍ່ຂອງຝຸ່ນ“, ແລະໃນທີ່ນີ້ມັນໄດ້ກາຍມາເປັນກ້ອນຝຸ່ນແຈກຢາຍ. ເພື່ອຢືນຢັນເລື່ອງນີ້, ນີ້ແມ່ນຕົວຢ່າງໂດຍປະມານຂອງວິທີການຮ້ອງຂໍໄປ:

ການ​ປະ​ຕິ​ບັດ​ເປັນ​ເອ​ກະ​ລາດ...

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

ເສລີພາບໃນການເລືອກເຕັກໂນໂລຊີ...

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

​ເອກະລາດ​ແຫ່ງ​ການ​ພັດທະນາ...

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

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

ການ​ປັບ​ຂະ​ຫນາດ​ແຍກ...

ແມ່ນແລ້ວ, ແຕ່ມັນຈໍາກັດຢູ່ໃນພື້ນທີ່ຂອງ DBMS ທີ່ໃຊ້. ໃນຕົວຢ່າງສະຖາປັດຕະຍະກໍາ, Cassandra ຈະບໍ່ມີບັນຫາ, ແຕ່ MySQL ແລະ PostgreSQL ຈະ.

Боຄວາມຫນ້າເຊື່ອຖືຫຼາຍກວ່າເກົ່າ ...

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

ການວັດແທກການໂຫຼດ...

ນີ້ແມ່ນດີແທ້ໆ.

"ຄວາມສະຫວ່າງ" ຂອງ microservices ...

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

ແລະນີ້ແມ່ນຜົນຂອງການຕອບສະຫນອງຄວາມຄາດຫວັງຂອງພວກເຮົາ:

ແຕ່ນັ້ນບໍ່ແມ່ນທັງຫມົດ!

ເນື່ອງຈາກວ່າ:

• ສ່ວນຫຼາຍແລ້ວພວກເຮົາຈະຕ້ອງການລົດເມຂໍ້ຄວາມ.
• ເຮັດແນວໃດເພື່ອເຮັດໃຫ້ການສໍາຮອງຂໍ້ມູນທີ່ສອດຄ່ອງໃນປັດຈຸບັນທີ່ເຫມາະສົມໃນເວລາ? ຄົນດຽວ ທີ່ແທ້ຈິງ ທາງເລືອກແມ່ນເພື່ອປິດການຈະລາຈອນສໍາລັບການນີ້. ແຕ່ວິທີການເຮັດແນວນີ້ໃນການຜະລິດ?
• ຖ້າພວກເຮົາເວົ້າກ່ຽວກັບການສະໜັບສະໜູນຫຼາຍຂົງເຂດ, ການຈັດຕັ້ງຄວາມຍືນຍົງໃນແຕ່ລະພາກແມ່ນວຽກງານທີ່ຕ້ອງໃຊ້ແຮງງານຫຼາຍ.
• ບັນຫາຂອງການປ່ຽນແປງສູນກາງເກີດຂື້ນ. ຕົວຢ່າງ, ຖ້າພວກເຮົາຕ້ອງການປັບປຸງສະບັບ PHP, ພວກເຮົາຈະຕ້ອງສັນຍາກັບແຕ່ລະ repository (ແລະມີຫຼາຍສິບຂອງພວກເຂົາ).
• ການຂະຫຍາຍຕົວຂອງຄວາມສັບສົນໃນການດໍາເນີນງານແມ່ນ, offhand, exponential.

ຈະເຮັດແນວໃດກັບທັງຫມົດນີ້?

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

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

ແຕ່ຖ້າພວກເຮົາຢູ່ໃນສະຖານະການນີ້ແລ້ວຈະເຮັດແນວໃດ?

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

ຖ້າຫາກວ່າ, ໃນກໍລະນີຂອງ monolith overgrown (ໃນເວລາທີ່ພວກເຮົາໄດ້ຫມົດໂອກາດທີ່ຈະຊື້ຊັບພະຍາກອນເພີ່ມເຕີມສໍາລັບມັນ), ພວກເຮົາຕັດມັນ, ຫຼັງຈາກນັ້ນ, ໃນກໍລະນີນີ້ເລື່ອງກົງກັນຂ້າມ turns ອອກ: ເມື່ອ microservices ຫຼາຍເກີນໄປບໍ່ໄດ້ຊ່ວຍ, ແຕ່ຂັດຂວາງ - ຕັດສ່ວນເກີນແລະຂະຫຍາຍ!

ຕົວຢ່າງ, ສໍາລັບຮູບພາບລວມທີ່ສົນທະນາຂ້າງເທິງ ...

ກໍາຈັດການບໍລິການຈຸລະພາກທີ່ມີຄໍາຖາມຫຼາຍທີ່ສຸດ:

ສົມທົບການບໍລິການຈຸນລະພາກທັງໝົດທີ່ຮັບຜິດຊອບໃນການຜະລິດແຖວໜ້າ:

... ເຂົ້າໄປໃນບໍລິການຈຸລະພາກດຽວ, ຂຽນເປັນອັນດຽວ (ທັນສະໄຫມ ແລະປົກກະຕິ, ຕາມທີ່ເຈົ້າຄິດເອງ) ພາສາ/ກອບ:

ມັນຈະມີຫນຶ່ງ ORM (ຫນຶ່ງ DBMS) ແລະທໍາອິດສອງສາມຄໍາຮ້ອງສະຫມັກ:

... ແຕ່ໂດຍທົ່ວໄປທ່ານສາມາດໂອນໄດ້ຫຼາຍຢູ່ທີ່ນັ້ນ, ໄດ້ຮັບຜົນໄດ້ຮັບດັ່ງຕໍ່ໄປນີ້:

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

ເພື່ອສະຫຼຸບ

ເບິ່ງຮູບທີ່ໃຫຍ່ກວ່າ. ເລື້ອຍໆ, ບັນຫາທັງຫມົດເຫຼົ່ານີ້ກັບ microservices ເກີດຂື້ນເພາະວ່າຜູ້ໃດຜູ້ຫນຶ່ງໄດ້ປະຕິບັດຫນ້າທີ່ຂອງເຂົາເຈົ້າ, ແຕ່ຕ້ອງການ "ຫຼິ້ນກັບ microservices".

ໃນຄໍາວ່າ "ບໍລິການຈຸລະພາກ" ສ່ວນ "ຈຸນລະພາກ" ແມ່ນຊ້ໍາຊ້ອນ.. ພວກເຂົາເຈົ້າແມ່ນ "ຈຸນລະພາກ" ພຽງແຕ່ຍ້ອນວ່າພວກເຂົາມີຂະຫນາດນ້ອຍກວ່າ monolith ໃຫຍ່. ແຕ່ຢ່າຄິດວ່າພວກມັນເປັນເລື່ອງນ້ອຍໆ.

ແລະສໍາລັບຄວາມຄິດສຸດທ້າຍ, ໃຫ້ກັບຄືນໄປຫາຕາຕະລາງຕົ້ນສະບັບ:

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

ວິດີໂອ ແລະສະໄລ້

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

ການ​ນໍາ​ສະ​ເຫນີ​ບົດ​ລາຍ​ງານ​:

PS

ບົດລາຍງານອື່ນໆກ່ຽວກັບ blog ຂອງພວກເຮົາ:

• «ການຕິດຕາມແລະ Kubernetes» (Dmitry Stolyarov; 28 ພຶດສະພາ 2018 ຢູ່ RootConf);
• «CI/CD ການປະຕິບັດທີ່ດີທີ່ສຸດກັບ Kubernetes ແລະ GitLab» (Dmitry Stolyarov; ເດືອນພະຈິກ 7, 2017 on HighLoad++);
• «ປະສົບການຂອງພວກເຮົາກັບ Kubernetes ໃນໂຄງການຂະຫນາດນ້ອຍ» (Dmitry Stolyarov; 6 ເດືອນມິຖຸນາ 2017 ຢູ່ RootConf);
• «ພວກເຮົາສ້າງຮູບພາບ Docker ສໍາລັບ CI/CD ຢ່າງວ່ອງໄວແລະສະດວກດ້ວຍ dapp» (Dmitry Stolyarov; ເດືອນພະຈິກ 8, 2016 on HighLoad++);
• «ການປະຕິບັດການຈັດສົ່ງຢ່າງຕໍ່ເນື່ອງກັບ Docker» (Dmitry Stolyarov; 31 ພຶດສະພາ 2016 ຢູ່ RootConf).

ເຈົ້າອາດຈະສົນໃຈໃນສິ່ງພິມຕໍ່ໄປນີ້:

• «ການເສຍຊີວິດຂອງບ້າບໍລິການຈຸລະພາກໃນປີ 2018"
• «7 ການປະຕິບັດທີ່ດີທີ່ສຸດສໍາລັບການນໍາໃຊ້ containers ອີງຕາມ Google"
• «ສະຖິຕິຈາກ The New Stack ກ່ຽວກັບສິ່ງທ້າທາຍຂອງການປະຕິບັດ Kubernetes".

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