ຂໍ້ມູນ dichotomy: ການຄິດຄືນຄວາມສໍາພັນລະຫວ່າງຂໍ້ມູນແລະການບໍລິການ

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

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

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

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

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

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

Encapsulation ຈະບໍ່ເປັນເພື່ອນຂອງເຈົ້າສະ ເໝີ ໄປ

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

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

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

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

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

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

ຂໍ້ມູນ dichotomy

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

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

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

ແລະໃນທີ່ນີ້ dilemma ເກີດຂຶ້ນ. ຂັດກັນ. Dichotomy. ຫຼັງຈາກທີ່ທັງຫມົດ, ລະບົບຂໍ້ມູນຂ່າວສານແມ່ນກ່ຽວກັບການສະຫນອງຂໍ້ມູນ, ແລະການບໍລິການແມ່ນກ່ຽວກັບການເຊື່ອງ.

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

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

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

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

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

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

ການສໍາເນົາຫຼາຍທີ່ສາມາດປ່ຽນແປງໄດ້, ຂໍ້ມູນຈະແຕກຕ່າງກັນໄປຕາມເວລາ.

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

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

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

ຮອບວຽນຂອງຂໍ້ມູນລົ້ມເຫຼວ

Stream: ເປັນວິທີການກະຈາຍຂໍ້ມູນ ແລະການບໍລິການ

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

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

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

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

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

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

ລົບລ້າງ dichotomy ຂໍ້ມູນໂດຍການແຍກນ້ໍາຂອງລັດທີ່ບໍ່ປ່ຽນແປງໄດ້. ຫຼັງຈາກນັ້ນ, ເພີ່ມຟັງຊັນນີ້ໃຫ້ກັບທຸກໆບໍລິການໂດຍໃຊ້ Stateful Stream Processing.

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

ແບ່ງປັນຂໍ້ມູນໂດຍບໍ່ມີການທໍາລາຍຄວາມສົມບູນຂອງມັນ. ຫຸ້ມຫໍ່ຟັງຊັນ, ບໍ່ແມ່ນແຫຼ່ງ, ໃນທຸກບໍລິການທີ່ຕ້ອງການ.

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

ດັ່ງນັ້ນ, ວິທີການປຶກສາຫາລືໃນມື້ນີ້ມີຂໍ້ໄດ້ປຽບຫຼາຍ:

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

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

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

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

ຮຽນຮູ້ເພີ່ມເຕີມກ່ຽວກັບຫຼັກສູດ.

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