ວິທີທີ່ພວກເຮົາເກັບກໍາຂໍ້ມູນການໂຄສະນາຈາກເວັບໄຊທ໌ອອນໄລນ໌ (ເສັ້ນທາງ thorny ກັບຜະລິດຕະພັນ)

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

ແຫຼ່ງຂໍ້ມູນ

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

ເປັນຫຍັງ?

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

ການບໍລິການເຊັ່ນ: Improvado, Roistat, Supermetrics, SegmentStream ສະເຫນີການເຊື່ອມໂຍງກັບແພລະຕະຟອມ, ເຄືອຂ່າຍສັງຄົມແລະ Google Analitycs, ແລະຍັງເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະສ້າງ dashboards ການວິເຄາະເພື່ອຄວາມສະດວກໃນການວິເຄາະແລະການຄວບຄຸມການໂຄສະນາການໂຄສະນາ. ກ່ອນທີ່ພວກເຮົາຈະເລີ່ມພັດທະນາຜະລິດຕະພັນຂອງພວກເຮົາ, ພວກເຮົາໄດ້ພະຍາຍາມໃຊ້ບາງລະບົບເຫຼົ່ານີ້ເພື່ອເກັບກໍາຂໍ້ມູນຈາກເວັບໄຊທ໌, ແຕ່ຫນ້າເສຍດາຍ, ພວກເຂົາບໍ່ສາມາດແກ້ໄຂບັນຫາຂອງພວກເຮົາໄດ້.

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

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

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

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

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

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

ແຜນໃຫຍ່

ເພື່ອເລີ່ມຕົ້ນດ້ວຍ, ພວກເຮົາໄດ້ສ້າງວິໄສທັດຂອງລະບົບທີ່ເຫມາະສົມ:

• ການໂຄສະນາການໂຄສະນາຈາກລະບົບບໍລິສັດ 1C ຄວນຈະຖືກໂຫລດໂດຍອັດຕະໂນມັດໃນມັນດ້ວຍຊື່, ໄລຍະເວລາ, ງົບປະມານແລະສະຖານທີ່ໃນເວທີຕ່າງໆ.
• ສໍາລັບແຕ່ລະການຈັດວາງພາຍໃນແຄມເປນໂຄສະນາ, ສະຖິຕິທີ່ເປັນໄປໄດ້ທັງຫມົດຄວນຈະຖືກດາວໂຫຼດໂດຍອັດຕະໂນມັດຈາກສະຖານທີ່ບ່ອນທີ່ການຈັດວາງກໍາລັງເກີດຂຶ້ນ, ເຊັ່ນ: ຈໍານວນປະທັບໃຈ, ກົດ, ເບິ່ງ, ແລະອື່ນໆ.
• ບາງແຄມເປນໂຄສະນາຖືກຕິດຕາມໂດຍໃຊ້ການຕິດຕາມຂອງພາກສ່ວນທີສາມໂດຍອັນທີ່ເອີ້ນວ່າລະບົບການໂຄສະນາເຊັ່ນ Adriver, Weborama, DCM, ແລະອື່ນໆ. ນອກຈາກນີ້ຍັງມີເຄື່ອງວັດແທກອິນເຕີເນັດອຸດສາຫະກໍາໃນລັດເຊຍ - ບໍລິສັດ Mediascope. ອີງຕາມແຜນການຂອງພວກເຮົາ, ຂໍ້ມູນຈາກການກວດສອບເອກະລາດແລະອຸດສາຫະກໍາຄວນຈະຖືກໂຫລດໂດຍອັດຕະໂນມັດເຂົ້າໃນການໂຄສະນາທີ່ສອດຄ້ອງກັນ.
• ການໂຄສະນາການໂຄສະນາສ່ວນໃຫຍ່ໃນອິນເຕີເນັດແມ່ນແນໃສ່ການປະຕິບັດເປົ້າຫມາຍທີ່ແນ່ນອນ (ການຊື້, ໂທຫາ, ລົງທະບຽນສໍາລັບການທົດສອບການຂັບຂີ່, ແລະອື່ນໆ), ເຊິ່ງຖືກຕິດຕາມໂດຍໃຊ້ Google Analytics, ແລະສະຖິຕິທີ່ມີຄວາມສໍາຄັນສໍາລັບການເຂົ້າໃຈສະຖານະພາບຂອງແຄມເປນແລະ ຄວນຈະຖືກໂຫລດເຂົ້າໄປໃນເຄື່ອງມືຂອງພວກເຮົາ.

ສິ່ງ ທຳ ອິດທີ່ຂີ້ຮ້າຍແມ່ນເປັນກ້ອນ

ເນື່ອງຈາກຄວາມມຸ່ງໝັ້ນຂອງພວກເຮົາຕໍ່ກັບຫຼັກການທີ່ປ່ຽນແປງໄດ້ຂອງການພັດທະນາຊອບແວ (ວ່ອງໄວ, ທຸກສິ່ງ), ພວກເຮົາຕັດສິນໃຈພັດທະນາ MVP ທຳອິດ ແລະ ຈາກນັ້ນກ້າວໄປສູ່ເປົ້າໝາຍທີ່ຕັ້ງໄວ້ອີກຄັ້ງ.
ພວກເຮົາໄດ້ຕັດສິນໃຈສ້າງ MVP ໂດຍອີງໃສ່ຜະລິດຕະພັນຂອງພວກເຮົາ DANBo (Dentsu Aegis Network Board), ເຊິ່ງເປັນແອັບພລິເຄຊັນເວັບທີ່ມີຂໍ້ມູນທົ່ວໄປກ່ຽວກັບການໂຄສະນາຂອງລູກຄ້າຂອງພວກເຮົາ.

ສໍາລັບ MVP, ໂຄງການໄດ້ຖືກເຮັດໃຫ້ງ່າຍດາຍຫຼາຍເທົ່າທີ່ເປັນໄປໄດ້ໃນແງ່ຂອງການຈັດຕັ້ງປະຕິບັດ. ພວກເຮົາໄດ້ເລືອກບັນຊີລາຍຊື່ຈໍາກັດຂອງແພລະຕະຟອມສໍາລັບການເຊື່ອມໂຍງ. ເຫຼົ່ານີ້ແມ່ນເວທີຕົ້ນຕໍ, ເຊັ່ນ Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB, ແລະລະບົບການໂຄສະນາຕົ້ນຕໍ Adriver ແລະ Weborama.

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

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

ມັນເບິ່ງ, ກົງໄປກົງມາ, ເປັນຕາຢ້ານ:

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

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

ຂໍ້​ມູນ​ທີ່​ດາວ​ໂຫຼດ​ໄດ້​ຖືກ​ສະ​ແດງ​ຢູ່​ໃນ​ການ​ໂຕ້​ຕອບ​ໃນ​ຮູບ​ແບບ​ຂອງ dashboard custom ຂະ​ຫນາດ​ນ້ອຍ​:

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

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

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

ແນວຄິດ

ສິ່ງທໍາອິດທີ່ພວກເຮົາຕັດສິນໃຈເຮັດຄືການແຍກລະບົບການລວບລວມສະຖິຕິການໂຄສະນາການໂຄສະນາໃນອິນເຕີເນັດເປັນຜະລິດຕະພັນແຍກຕ່າງຫາກ - D1.Digital.

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

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

ເພື່ອແກ້ໄຂບັນຫານີ້, ພວກເຮົາຕ້ອງໄດ້ປະດິດລະຫັດ hashed ເປັນເອກະລັກ, DANBoID, ທີ່ຈະເຊື່ອມຕໍ່ຫນ່ວຍງານໃນລະບົບຕ່າງໆຮ່ວມກັນ, ແລະມັນສາມາດຖືກກໍານົດໄດ້ງ່າຍແລະເປັນເອກະລັກໃນຊຸດຂໍ້ມູນທີ່ດາວໂຫລດ. ຕົວລະບຸນີ້ຖືກສ້າງຂຶ້ນໃນລະບົບ 1C ພາຍໃນສໍາລັບແຕ່ລະການຈັດວາງແຕ່ລະບຸກຄົນ ແລະຖືກໂອນໄປຫາແຄມເປນ, ການຈັດວາງ ແລະເຄົາເຕີໃນທຸກເວັບໄຊ ແລະໃນທຸກລະບົບ AdServing. ການປະຕິບັດການປະຕິບັດການວາງ DANBoID ໃນສະຖານທີ່ທັງຫມົດໃຊ້ເວລາບາງ, ແຕ່ພວກເຮົາຈັດການມັນ :)

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

ໃນຂັ້ນຕອນນີ້, ພວກເຮົາໄດ້ຕັດສິນໃຈຫຼຸດລົງຢ່າງຫຼວງຫຼາຍໃນບັນຊີລາຍຊື່ຂອງເວທີການເຊື່ອມໂຍງແລະສຸມໃສ່ເວທີຕົ້ນຕໍທີ່ມີສ່ວນຮ່ວມໃນການໂຄສະນາການໂຄສະນາສ່ວນໃຫຍ່. ບັນຊີລາຍຊື່ນີ້ປະກອບມີຜູ້ຫຼິ້ນທີ່ໃຫຍ່ທີ່ສຸດທັງຫມົດໃນຕະຫຼາດໂຄສະນາ (Google, Yandex, Mail.ru), ເຄືອຂ່າຍສັງຄົມ (VK, Facebook, Twitter), ລະບົບ AdServing ແລະການວິເຄາະທີ່ສໍາຄັນ (DCM, Adriver, Weborama, Google Analytics) ແລະເວທີອື່ນໆ.

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

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

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

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

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

ສະຖາປັດຕະຍະກຳການແກ້ໄຂ 1.0

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

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

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

ເພື່ອຕິດຕໍ່ສື່ສານລະຫວ່າງຕົວເຊື່ອມຕໍ່ແລະແອັບພລິເຄຊັນເວັບ, ພວກເຮົາຕ້ອງສ້າງບໍລິການເພີ່ມເຕີມ, ເຊິ່ງພວກເຮົາເອີ້ນວ່າ Connector Proxy. ມັນປະຕິບັດຫນ້າທີ່ຂອງ Service Discovery ແລະ Task Scheduler. ບໍລິການນີ້ດໍາເນີນການເກັບກໍາຂໍ້ມູນສໍາລັບແຕ່ລະຕົວເຊື່ອມຕໍ່ທຸກໆຄືນ. ການຂຽນຊັ້ນການບໍລິການແມ່ນງ່າຍກວ່າການເຊື່ອມຕໍ່ນາຍຫນ້າຂໍ້ຄວາມ, ແລະສໍາລັບພວກເຮົາມັນເປັນສິ່ງສໍາຄັນທີ່ຈະໄດ້ຮັບຜົນໄດ້ຮັບໄວເທົ່າທີ່ຈະໄວໄດ້.

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

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

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

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

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

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

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

ສະຖາປັດຕະຍະກຳການແກ້ໄຂ 2.0

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

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

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

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

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

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

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

ຂ້ອນຂ້າງໄວທີ່ພວກເຮົາຮັບຮູ້ວ່າ Kubernetes ແມ່ນສະດວກ, ແລະພາຍໃນຫົກເດືອນພວກເຮົາໄດ້ໂອນ 7 ຕົວເຊື່ອມຕໍ່ແລະ Connectors Proxy, ເຊິ່ງໃຊ້ຊັບພະຍາກອນຫຼາຍທີ່ສຸດ, ໄປຫາກຸ່ມການຜະລິດ.

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

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

ເພື່ອແກ້ໄຂບັນຫາເຫຼົ່ານີ້, ພວກເຮົາໄດ້ພັດທະນາສະຖາປັດຕະຍະກໍາ 2.0.

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

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

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

ດຽວນີ້ພວກເຮົາຢູ່ໃສ

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

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

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

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

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

ໂດຍທົ່ວໄປ, ແຜນການແມ່ນຍິ່ງໃຫຍ່, ໃຫ້ກ້າວຕໍ່ໄປ :)

ຜູ້ຂຽນບົດຄວາມ R&D Dentsu Aegis Network Russia: Georgy Ostapenko (shmiigaa), Mikhail Kotsik (hitexx)

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