ການຫັນປ່ຽນຈາກ monolith ໄປສູ່ microservices: ປະຫວັດສາດແລະການປະຕິບັດ

ໃນບົດຄວາມນີ້, ຂ້າພະເຈົ້າຈະສົນທະນາກ່ຽວກັບວິທີໂຄງການທີ່ຂ້າພະເຈົ້າເຮັດວຽກກ່ຽວກັບການຫັນປ່ຽນຈາກ monolith ຂະຫນາດໃຫຍ່ເຂົ້າໄປໃນຊຸດຂອງ microservices.

ໂຄງ​ການ​ດັ່ງ​ກ່າວ​ໄດ້​ເລີ່ມ​ຕົ້ນ​ປະ​ຫວັດ​ສາດ​ຂອງ​ຕົນ​ເປັນ​ເວ​ລາ​ດົນ​ນານ​ກ່ອນ​ຫນ້າ​ນີ້​, ໃນ​ຕົ້ນ​ປີ 2000​. ສະ​ບັບ​ທໍາ​ອິດ​ໄດ້​ຖືກ​ຂຽນ​ໃນ Visual Basic 6​. ເມື່ອ​ເວ​ລາ​, ມັນ​ໄດ້​ກາຍ​ເປັນ​ທີ່​ຈະ​ແຈ້ງ​ວ່າ​ການ​ພັດ​ທະ​ນາ​ໃນ​ພາ​ສາ​ນີ້​ຈະ​ເປັນ​ການ​ຍາກ​ທີ່​ຈະ​ສະ​ຫນັບ​ສະ​ຫນູນ​ໃນ​ອະ​ນາ​ຄົດ​, ນັບ​ຕັ້ງ​ແຕ່ IDE ໄດ້​. ແລະ​ພາ​ສາ​ຕົວ​ມັນ​ເອງ​ພັດ​ທະ​ນາ​ບໍ່​ດີ​. ໃນຕອນທ້າຍຂອງ 2000s, ມັນໄດ້ຖືກຕັດສິນໃຈທີ່ຈະປ່ຽນໄປສູ່ C # ທີ່ມີທ່າແຮງຫຼາຍ. ສະບັບໃຫມ່ໄດ້ຖືກຂຽນໃນຂະຫນານກັບການປັບປຸງສະບັບເກົ່າ, ຄ່ອຍໆຂຽນລະຫັດຫຼາຍຂື້ນໃນ .NET. Backend ໃນ C# ໃນເບື້ອງຕົ້ນໄດ້ສຸມໃສ່ການສະຖາປັດຕະຍະການບໍລິການ, ແຕ່ໃນລະຫວ່າງການພັດທະນາ, ຫ້ອງສະຫມຸດທົ່ວໄປທີ່ມີເຫດຜົນໄດ້ຖືກນໍາໃຊ້, ແລະການບໍລິການໄດ້ຖືກເປີດຕົວໃນຂະບວນການດຽວ. ຜົນໄດ້ຮັບແມ່ນຄໍາຮ້ອງສະຫມັກທີ່ພວກເຮົາເອີ້ນວ່າ "ການບໍລິການ monolith."

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

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

ເນື້ອໃນ

• ສະຖາປັດຕະຍະກໍາແລະບັນຫາຂອງການແກ້ໄຂທີ່ມີຢູ່ແລ້ວ
• ຄວາມຄາດຫວັງຈາກບໍລິການຈຸລະພາກ
• ບັນຫາການຫັນປ່ຽນ
• ວິທີການຍ້າຍຈາກ monolith ໄປຫາ microservices
  • ວິທີທໍາອິດ
  • ວິທີທີສອງ
  • ວິທີທີສາມ
  • ທາງສີ່
• ເຮັດວຽກກັບຖານຂໍ້ມູນ
  • ການແຍກຕາຕະລາງທີ່ມີຢູ່ແລ້ວ
  • ພະແນກປຸງແຕ່ງ
• ເຮັດວຽກກັບລະຫັດແຫຼ່ງ
• ບັນຫາພື້ນຖານໂຄງລ່າງ
  • ການຕິດຕັ້ງດ້ວຍມືໃນສະພາບແວດລ້ອມ
  • ການຕັດໄມ້ແຍກຕ່າງຫາກ
  • ການທົດສອບແລະ debugging ການບໍລິການທີ່ກ່ຽວຂ້ອງ

ສະຖາປັດຕະຍະກໍາແລະບັນຫາຂອງການແກ້ໄຂທີ່ມີຢູ່ແລ້ວ

ໃນເບື້ອງຕົ້ນ, ສະຖາປັດຕະຍະກໍາເບິ່ງຄືດັ່ງນີ້: UI ເປັນຄໍາຮ້ອງສະຫມັກແຍກຕ່າງຫາກ, ສ່ວນ monolithic ແມ່ນລາຍລັກອັກສອນໃນ Visual Basic 6, ຄໍາຮ້ອງສະຫມັກ .NET ແມ່ນຊຸດຂອງການບໍລິການທີ່ກ່ຽວຂ້ອງເຮັດວຽກກັບຖານຂໍ້ມູນຂະຫນາດໃຫຍ່ພໍສົມຄວນ.

ຂໍ້ເສຍຂອງການແກ້ໄຂທີ່ຜ່ານມາ

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

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

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

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

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

ຄວາມຄາດຫວັງຈາກບໍລິການຈຸລະພາກ

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

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

ການແຍກການບໍລິການໃນຂະບວນການແຍກຕ່າງຫາກ. ໂດຍຫລັກການແລ້ວ, ຂ້ອຍຕ້ອງການແຍກມັນຢູ່ໃນກ່ອງບັນຈຸ, ແຕ່ການບໍລິການຈໍານວນຫລາຍທີ່ຂຽນໄວ້ໃນ .NET Framework ເຮັດວຽກຢູ່ໃນ Windows ເທົ່ານັ້ນ. ການບໍລິການທີ່ອີງໃສ່ .NET Core ກໍາລັງປະກົດຕົວໃນປັດຈຸບັນ, ແຕ່ມີຈໍານວນຫນ້ອຍຂອງພວກເຂົາ.

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

ການ​ນໍາ​ໃຊ້​ເຕັກ​ໂນ​ໂລ​ຊີ​ໃຫມ່​. ນີ້ແມ່ນຫນ້າສົນໃຈກັບນັກຂຽນໂປຼແກຼມໃດໆ.

ບັນຫາການຫັນປ່ຽນ

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

ປັນຫາ ທຳ ອິດ ປົກກະຕິສໍາລັບ monoliths ສ່ວນໃຫຍ່: ຄວາມສອດຄ່ອງຂອງເຫດຜົນທາງທຸລະກິດ. ເມື່ອພວກເຮົາຂຽນ monolith, ພວກເຮົາຕ້ອງການໃຊ້ຫ້ອງຮຽນຂອງພວກເຮົາຄືນໃຫມ່ເພື່ອບໍ່ໃຫ້ຂຽນລະຫັດທີ່ບໍ່ຈໍາເປັນ. ແລະໃນເວລາທີ່ຍ້າຍໄປ microservices, ນີ້ຈະກາຍເປັນບັນຫາ: ລະຫັດທັງຫມົດແມ່ນຂ້ອນຂ້າງແຫນ້ນ, ແລະມັນຍາກທີ່ຈະແຍກການບໍລິການ.

ໃນເວລາເລີ່ມຕົ້ນຂອງການເຮັດວຽກ, repository ມີຫຼາຍກ່ວາ 500 ໂຄງການແລະຫຼາຍກ່ວາ 700 ພັນລະຫັດຂອງສາຍ. ນີ້ແມ່ນການຕັດສິນໃຈທີ່ຂ້ອນຂ້າງໃຫຍ່ແລະ ບັນຫາທີສອງ. ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະພຽງແຕ່ເອົາມັນແລະແບ່ງອອກເປັນ microservices.

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

ວິທີການຍ້າຍຈາກ monolith ໄປຫາ microservices

ການສະໜອງບໍລິການຈຸລະພາກ

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

ພວກເຮົາໃຊ້ວິທີການໃດແດ່ເພື່ອແຍກບໍລິການຈຸລະພາກ?

ວິທີທໍາອິດ — ຍ້າຍໂມດູນທີ່ມີຢູ່ແລ້ວເປັນການບໍລິການ. ໃນເລື່ອງນີ້, ພວກເຮົາໂຊກດີ: ມີການບໍລິການທີ່ລົງທະບຽນແລ້ວທີ່ເຮັດວຽກໂດຍໃຊ້ໂປໂຕຄອນ WCF. ພວກເຂົາເຈົ້າໄດ້ຖືກແຍກອອກເປັນສະພາແຫ່ງແຍກຕ່າງຫາກ. ພວກເຮົາ ported ໃຫ້ເຂົາເຈົ້າແຍກຕ່າງຫາກ, ເພີ່ມ launcher ຂະຫນາດນ້ອຍໃນແຕ່ລະການກໍ່ສ້າງ. ມັນໄດ້ຖືກຂຽນໂດຍໃຊ້ຫ້ອງສະຫມຸດ Topshelf ທີ່ປະເສີດ, ເຊິ່ງຊ່ວຍໃຫ້ທ່ານສາມາດດໍາເນີນການແອັບພລິເຄຊັນໄດ້ທັງເປັນບໍລິການແລະເປັນ console. ນີ້ແມ່ນສະດວກສໍາລັບການ debugging ເນື່ອງຈາກວ່າບໍ່ມີໂຄງການເພີ່ມເຕີມທີ່ຕ້ອງການໃນການແກ້ໄຂ.

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

ການປະຊຸມກັບໂຮດແມ່ນພຽງແຕ່ຫນຶ່ງເສັ້ນຂອງລະຫັດໃນຫ້ອງຮຽນ Program. ພວກເຮົາເຊື່ອງການເຮັດວຽກກັບ Topshelf ໃນຫ້ອງຮຽນຊ່ວຍ.

namespace RBA.Services.Accounts.Host
{
   internal class Program
   {
      private static void Main(string[] args)
      {
        HostRunner<Accounts>.Run("RBA.Services.Accounts.Host");

       }
    }
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ເຮັດວຽກກັບຖານຂໍ້ມູນ

ຖານຂໍ້ມູນສາມາດແບ່ງອອກໄດ້ຮ້າຍແຮງກວ່າລະຫັດແຫຼ່ງ, ເນື່ອງຈາກວ່າມັນບໍ່ພຽງແຕ່ປະກອບດ້ວຍ schema ໃນປະຈຸບັນ, ແຕ່ຍັງເກັບກໍາຂໍ້ມູນປະຫວັດສາດ.

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

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

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

ພວກ​ເຮົາ​ໄດ້​ນໍາ​ໃຊ້​ສອງ​ວິ​ທີ​ການ​ທົ່ວ​ໂລກ​ຂອງ​ການ​ແບ່ງ​ປັນ​ຖານ​ຂໍ້​ມູນ​: ການ​ແບ່ງ​ປັນ​ຕາ​ຕະ​ລາງ​ທີ່​ມີ​ຢູ່​ແລ້ວ​ແລະ​ການ​ແບ່ງ​ປັນ​ກັບ​ການ​ປຸງ​ແຕ່ງ​.

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

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

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

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

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

ຕໍ່ມາພວກເຮົາຈະເອົາການເຊື່ອມຕໍ່ນີ້, ນັ້ນແມ່ນ, ການອ່ານຂໍ້ມູນຈາກຄໍາຮ້ອງສະຫມັກ monolithic ຈາກຕາຕະລາງທີ່ແຍກຕ່າງຫາກຈະຖືກໂອນໄປຫາ API.

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

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

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

ເພື່ອໃຫ້ໂຄງການນີ້ເຮັດວຽກ, ພວກເຮົາອາດຈະຕ້ອງການໄລຍະການປ່ຽນແປງ.

ຫຼັງຈາກນັ້ນ, ມີສອງວິທີການທີ່ເປັນໄປໄດ້.

ທໍາອິດ: ພວກເຮົາສຳເນົາຂໍ້ມູນທັງໝົດໃນຖານຂໍ້ມູນໃໝ່ ແລະ ເກົ່າ. ໃນ​ກໍ​ລະ​ນີ​ນີ້​, ພວກ​ເຮົາ​ມີ​ຂໍ້​ມູນ redundancy ແລະ​ບັນ​ຫາ synchronization ອາດ​ຈະ​ເກີດ​ຂຶ້ນ​. ແຕ່ພວກເຮົາສາມາດເອົາສອງລູກຄ້າທີ່ແຕກຕ່າງກັນ. ອັນໜຶ່ງຈະເຮັດວຽກກັບລຸ້ນໃໝ່, ອີກອັນໜຶ່ງກັບລຸ້ນເກົ່າ.

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

ວິທີການທັງສອງເຮັດວຽກ, ເລືອກຂຶ້ນຢູ່ກັບສະຖານະການ.

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

ຂັ້ນຕອນສຸດທ້າຍແມ່ນເພື່ອເອົາໂຄງສ້າງຂໍ້ມູນເກົ່າອອກ.

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

ເຮັດວຽກກັບລະຫັດແຫຼ່ງ

ນີ້ແມ່ນສິ່ງທີ່ແຜນວາດລະຫັດແຫຼ່ງເບິ່ງຄືເມື່ອພວກເຮົາເລີ່ມວິເຄາະໂຄງການ monolithic.

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

ພວກເຮົາໂຊກດີທີ່ມີຫ້ອງສະຫມຸດໂຄງສ້າງພື້ນຖານທີ່ສາມາດຖືກນໍາໃຊ້ແຍກຕ່າງຫາກ.

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

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

ພວກເຮົາໄດ້ສ້າງກົດລະບຽບຈໍານວນຫນຶ່ງສໍາລັບຂະບວນການແຍກລະຫັດ.

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

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

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

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

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

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

ບັນຫາພື້ນຖານໂຄງລ່າງ

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

ການຕິດຕັ້ງດ້ວຍມືໃນສະພາບແວດລ້ອມ

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

ພວກເຮົາໃຊ້ Atlassian, Bitbucket ສໍາລັບການເກັບຮັກສາລະຫັດແຫຼ່ງແລະໄມ້ໄຜ່ສໍາລັບການກໍ່ສ້າງ. ພວກເຮົາມັກຂຽນຕົວສ້າງໃນ Cake ເພາະວ່າມັນຄືກັນກັບ C#. ແພກເກດທີ່ກຽມພ້ອມມາຮອດ Artifactory, ແລະ Ansible ໄປຫາເຄື່ອງແມ່ຂ່າຍການທົດສອບໂດຍອັດຕະໂນມັດ, ຫຼັງຈາກນັ້ນພວກເຂົາສາມາດທົດສອບໄດ້ທັນທີ.

ການຕັດໄມ້ແຍກຕ່າງຫາກ

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

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

ການທົດສອບແລະ debugging ການບໍລິການທີ່ກ່ຽວຂ້ອງ

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

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

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

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

ພວກເຮົາບັນລຸໄດ້ຫຍັງແດ່?

ກ່ອນອື່ນ ໝົດ, ພວກເຮົາ ກຳ ຈັດແນວຄວາມຄິດຂອງ "ການປົດປ່ອຍ". ຫມົດແມ່ນການປ່ອຍ monstrous ສອງເດືອນໃນເວລາທີ່ colossus ນີ້ໄດ້ຖືກນໍາໄປໃຊ້ໃນສະພາບແວດລ້ອມການຜະລິດ, ຂັດຂວາງຂະບວນການທຸລະກິດຊົ່ວຄາວ. ຕອນນີ້ພວກເຮົານຳໃຊ້ການບໍລິການໂດຍສະເລ່ຍໃນທຸກໆ 1,5 ມື້, ຈັດກຸ່ມພວກມັນເພາະວ່າພວກມັນດຳເນີນງານຫຼັງຈາກການອະນຸມັດ.

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

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

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

Summary

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

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

  P.S. ເລື່ອງທີ່ມີຄວາມຮູ້ສຶກຫຼາຍ (ແລະເປັນຖ້າຫາກວ່າທ່ານສ່ວນບຸກຄົນ) - ອີງຕາມການ ການເຊື່ອມຕໍ່.
  ນີ້ແມ່ນສະບັບເຕັມຂອງບົດລາຍງານ.

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