ຖານຂໍ້ມູນອາໄສຢູ່ໃນ Kubernetes ບໍ?

ໃນທາງປະຫວັດສາດ, ອຸດສາຫະກໍາ IT ໄດ້ຖືກແບ່ງອອກເປັນສອງ camps ເງື່ອນໄຂສໍາລັບເຫດຜົນໃດກໍ່ຕາມ: ຜູ້ທີ່ "ສໍາລັບ" ແລະຜູ້ທີ່ "ຕໍ່ຕ້ານ". ຍິ່ງ​ໄປ​ກວ່າ​ນັ້ນ​, ຫົວ​ຂໍ້​ຂອງ​ຂໍ້​ຂັດ​ແຍ່ງ​ສາ​ມາດ​ເປັນ​ຕົນ​ເອງ​ຫມົດ​. OS ໃດດີກວ່າ: Win ຫຼື Linux? ໃນໂທລະສັບສະຫຼາດ Android ຫຼື iOS? ທ່ານຄວນເກັບຮັກສາທຸກສິ່ງທຸກຢ່າງຢູ່ໃນເມຄຫຼືວາງໄວ້ໃນບ່ອນເກັບມ້ຽນ RAID ເຢັນແລະເອົາສະກູໄວ້ໃນບ່ອນປອດໄພບໍ? ຄົນ PHP ມີສິດທີ່ຈະຖືກເອີ້ນວ່ານັກຂຽນໂປລແກລມບໍ? ການຂັດແຍ້ງເຫຼົ່ານີ້ແມ່ນ, ບາງຄັ້ງ, ມີພຽງແຕ່ຢູ່ໃນທໍາມະຊາດແລະບໍ່ມີພື້ນຖານອື່ນນອກເຫນືອຈາກຄວາມສົນໃຈດ້ານກິລາ.

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

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

ດ້ານສົດໃສ

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

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

ນັ້ນແມ່ນ, ຂໍ້ມູນ. ຫົວໃຈຂອງໂຄງການໃດກໍ່ຕາມແມ່ນຂໍ້ມູນຂອງມັນ: ນີ້ສາມາດເປັນ DBMS ປົກກະຕິ - MySQL, Postgre, MongoDB, ຫຼືການເກັບຮັກສາທີ່ໃຊ້ສໍາລັບການຄົ້ນຫາ (ElasticSearch), ການເກັບຮັກສາທີ່ສໍາຄັນສໍາລັບຖານຄວາມຈໍາ - ຕົວຢ່າງ, redis, ແລະອື່ນໆ. ໃນປັດຈຸບັນພວກເຮົາບໍ່ໄດ້ ພວກເຮົາຈະເວົ້າກ່ຽວກັບທາງເລືອກການຈັດຕັ້ງປະຕິບັດ backend ທີ່ຜິດພາດເມື່ອຖານຂໍ້ມູນລົ້ມເຫລວເນື່ອງຈາກການສອບຖາມທີ່ຂຽນບໍ່ດີ, ແລະແທນທີ່ຈະພວກເຮົາຈະເວົ້າກ່ຽວກັບການຮັບປະກັນຄວາມທົນທານຕໍ່ຄວາມຜິດຂອງຖານຂໍ້ມູນນີ້ພາຍໃຕ້ການໂຫຼດຂອງລູກຄ້າ. ຫຼັງຈາກທີ່ທັງຫມົດ, ໃນເວລາທີ່ພວກເຮົາບັນຈຸຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາແລະອະນຸຍາດໃຫ້ມັນຂະຫນາດ freely ເພື່ອປະມວນຜົນຈໍານວນຂອງການຮ້ອງຂໍທີ່ເຂົ້າມາ, ນີ້ທໍາມະຊາດຈະເພີ່ມການໂຫຼດໃນຖານຂໍ້ມູນ.

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

ມັນເປັນຫຼາຍເຫດຜົນຫຼາຍທີ່ຈະກຸ່ມບໍ່ພຽງແຕ່ຄໍາຮ້ອງສະຫມັກຕົວມັນເອງ, ແຕ່ຍັງການບໍລິການທີ່ຮັບຜິດຊອບສໍາລັບການເກັບຮັກສາຂໍ້ມູນ. ໂດຍການຈັດກຸ່ມແລະນໍາໃຊ້ເຄື່ອງແມ່ຂ່າຍເວັບໄຊຕ໌ທີ່ເຮັດວຽກເປັນເອກະລາດແລະແຈກຢາຍການໂຫຼດລະຫວ່າງພວກເຂົາຢູ່ໃນ k8s, ພວກເຮົາກໍາລັງແກ້ໄຂບັນຫາຂອງ synchronization ຂໍ້ມູນ - ຄໍາເຫັນດຽວກັນກັບຂໍ້ຄວາມ, ຖ້າພວກເຮົາເອົາບາງແພລະຕະຟອມສື່ຫຼື blog ເປັນຕົວຢ່າງ. ໃນກໍລະນີໃດກໍ່ຕາມ, ພວກເຮົາມີ intra-cluster, ເຖິງແມ່ນວ່າ virtual, ເປັນຕົວແທນຂອງຖານຂໍ້ມູນເປັນ ExternalService. ຄໍາຖາມແມ່ນວ່າຖານຂໍ້ມູນຂອງຕົວມັນເອງຍັງບໍ່ທັນເປັນກຸ່ມ - ເຄື່ອງແມ່ຂ່າຍເວັບໄຊຕ໌ທີ່ຖືກນໍາໃຊ້ໃນ cube ເອົາຂໍ້ມູນກ່ຽວກັບການປ່ຽນແປງຈາກຖານຂໍ້ມູນ static combat ຂອງພວກເຮົາ, ເຊິ່ງ rotates ແຍກຕ່າງຫາກ.

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

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

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

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

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

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

ແລະໃນປັດຈຸບັນມັນເຖິງເວລາທີ່ຈະປ່ຽນເປັນ opponents ຂອງກຸ່ມຖານຂໍ້ມູນ.

ດ້ານ​ມືດ

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

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

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

ໂດຍທົ່ວໄປ, ມີຄວາມຄິດເຫັນວ່າ docker / cube mafia ແມ່ນ stupidly crushing ລູກຄ້າຜູ້ທີ່ outsource ບັນຫາພື້ນຖານໂຄງລ່າງເຫຼົ່ານີ້. ຫຼັງຈາກທີ່ທັງຫມົດ, ເພື່ອເຮັດວຽກກັບກຸ່ມ, ພວກເຮົາຕ້ອງການວິສະວະກອນທີ່ມີຄວາມສາມາດນີ້ແລະໂດຍທົ່ວໄປແລ້ວເຂົ້າໃຈສະຖາປັດຕະຍະກໍາຂອງການແກ້ໄຂທີ່ໄດ້ປະຕິບັດ. ພວກເຮົາເຄີຍອະທິບາຍກໍລະນີຂອງພວກເຮົາກັບສິ່ງພິມສາທາລະນະ - ຢູ່ທີ່ນັ້ນພວກເຮົາໄດ້ຝຶກອົບຮົມທີມງານຂອງລູກຄ້າໃຫ້ເຮັດວຽກຢູ່ໃນຄວາມເປັນຈິງຂອງ Kubernetis, ແລະທຸກຄົນພໍໃຈ. ແລະມັນແມ່ນການສົມຄວນ. ເລື້ອຍໆ, k8s "ຜູ້ປະຕິບັດ" ເອົາໂຄງສ້າງພື້ນຖານຂອງລູກຄ້າເປັນຕົວປະກັນ - ເພາະວ່າດຽວນີ້ພວກເຂົາເຂົ້າໃຈວິທີການເຮັດວຽກຢູ່ທີ່ນັ້ນ; ບໍ່ມີຜູ້ຊ່ຽວຊານດ້ານລູກຄ້າ.

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

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

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

ພວກເຮົາຄິດວ່າບໍ່ຈໍາເປັນຕ້ອງເວົ້າກ່ຽວກັບຄວາມໄວຂອງໄດເຄືອຂ່າຍ - ພວກມັນຊ້າ. ເຫຼົ່ານັ້ນ. ພວກເຮົາຍັງບໍ່ມີໂອກາດທີ່ແທ້ຈິງ, ຖ້າມີບາງສິ່ງບາງຢ່າງເກີດຂຶ້ນ, ເພື່ອ restart DBMS instance ບ່ອນທີ່ມີຫຼາຍກວ່ານັ້ນ, ຕົວຢ່າງ, ພະລັງງານຂອງໂປເຊດເຊີຫຼື RAM ຟຣີ. ພວກເຮົາຈະແລ່ນເຂົ້າໄປໃນການປະຕິບັດຂອງລະບົບຍ່ອຍແຜ່ນ virtualized ໄດ້ຢ່າງໄວວາ. ຕາມນັ້ນແລ້ວ, DBMS ຕ້ອງໄດ້ຮັບການ nailed ກັບຊຸດສ່ວນຕົວຂອງຕົນເອງຂອງເຄື່ອງຈັກທີ່ຕັ້ງຢູ່ໃກ້ໆ. ຫຼືມັນເປັນສິ່ງຈໍາເປັນເພື່ອ somehow ແຍກຕ່າງຫາກເຢັນລົງ synchronization ຂໍ້ມູນໄວພຽງພໍສໍາລັບການສະຫງວນສົມມຸດ.

ການສືບຕໍ່ຫົວຂໍ້ຂອງລະບົບໄຟລ໌ virtual: Docker Volumes, ແຕ່ຫນ້າເສຍດາຍ, ບໍ່ແມ່ນບັນຫາ. ໂດຍທົ່ວໄປ, ໃນເລື່ອງດັ່ງກ່າວເປັນການເກັບຮັກສາຂໍ້ມູນທີ່ເຊື່ອຖືໄດ້ໃນໄລຍະຍາວ, ຂ້າພະເຈົ້າຢາກຈະເຮັດກັບໂຄງການທີ່ງ່າຍດາຍທີ່ສຸດດ້ານວິຊາການ. ແລະການເພີ່ມຊັ້ນ abstraction ໃໝ່ຈາກ FS ຂອງ container ກັບ FS ຂອງແມ່ບ້ານແມ່ນຄວາມສ່ຽງໃນຕົວມັນເອງ. ​ແຕ່​ເມື່ອ​ການ​ດຳ​ເນີນ​ງານ​ຂອງ​ລະບົບ​ຮອງ​ຮັບ​ການ​ບັນຈຸ​ເຄື່ອງ​ບັນຈຸ​ຍັງ​ປະສົບ​ກັບ​ຄວາມ​ຫຍຸ້ງຍາກ​ໃນ​ການ​ສົ່ງ​ຂໍ້​ມູນ​ລະຫວ່າງ​ຊັ້ນ​ດັ່ງກ່າວ, ​ແລ້ວ​ມັນ​ກໍ່​ເປັນ​ໄພ​ພິບັດ. ໃນປັດຈຸບັນ, ບັນຫາສ່ວນໃຫຍ່ທີ່ຮູ້ຈັກກັບຄວາມກ້າວຫນ້າຂອງມະນຸດເບິ່ງຄືວ່າໄດ້ຖືກລົບລ້າງ. ແຕ່ທ່ານເຂົ້າໃຈ, ກົນໄກທີ່ສັບສົນຫຼາຍ, ມັນແຍກໄດ້ງ່າຍ.

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

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

ແທນທີ່ຜົນຜະລິດ

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

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

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