ປະສົບການໃນການພັດທະນາການບໍລິການເຄື່ອງມືການຄືນເງິນກັບ API asynchronous ໃນ Kafka

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

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

ການປະຕິເສດຄວາມຮັບຜິດຊອບ: ບົດຄວາມນີ້ແມ່ນອີງໃສ່ເອກະສານຈາກກອງປະຊຸມທີ່ Sergey ໄດ້ຈັດຂຶ້ນໃນເດືອນພະຈິກ 2018 ໃນ HighLoad++. ປະສົບການສົດຂອງ Lamoda ຂອງການເຮັດວຽກກັບ Kafka ໄດ້ດຶງດູດຜູ້ຟັງບໍ່ຫນ້ອຍກ່ວາບົດລາຍງານອື່ນໆໃນຕາຕະລາງ. ພວກເຮົາຄິດວ່ານີ້ແມ່ນຕົວຢ່າງທີ່ດີເລີດຂອງຄວາມຈິງທີ່ວ່າທ່ານສາມາດແລະຄວນຈະຊອກຫາຄົນທີ່ມີໃຈດຽວກັນ, ແລະຜູ້ຈັດຕັ້ງຂອງ HighLoad++ ຈະສືບຕໍ່ພະຍາຍາມສ້າງບັນຍາກາດທີ່ເອື້ອອໍານວຍ.

ກ່ຽວກັບຂະບວນການ

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

ເຄື່ອງມືການຄືນເງິນດ້ວຍ API ທີ່ຂັບເຄື່ອນເຫດການ

ຄຳ ວ່າເຫດການທີ່ຂັບເຄື່ອນແມ່ນຂ້ອນຂ້າງຖືກ hackneyed; ຕື່ມອີກ ໜ້ອຍ ໜຶ່ງ ພວກເຮົາຈະ ກຳ ນົດລາຍລະອຽດເພີ່ມເຕີມວ່າສິ່ງນີ້ ໝາຍ ຄວາມວ່າແນວໃດ. ຂ້ອຍຈະເລີ່ມຕົ້ນດ້ວຍສະພາບການທີ່ພວກເຮົາຕັດສິນໃຈທົດລອງໃຊ້ວິທີການ API ທີ່ຂັບເຄື່ອນໂດຍເຫດການໃນ Kafka.

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

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

ແຮງຈູງໃຈຂອງພວກເຮົາ:

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

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

BOB ຍັງມີການແລກປ່ຽນຫຼາຍ: ລະບົບການຈ່າຍເງິນ, ລະບົບການຈັດສົ່ງ, ລະບົບການແຈ້ງເຕືອນ, ແລະອື່ນໆ.

ດ້ານວິຊາການ BOB ແມ່ນ:

• ~ 150k ສາຍຂອງລະຫັດ + ~ 100k ສາຍຂອງການທົດສອບ;
• php7.2 + Zend 1 & Symfony ອົງປະກອບ 3;
• > 100 APIs & ~50 ການເຊື່ອມໂຍງຂາອອກ;
• 4 ປະເທດທີ່ມີເຫດຜົນທາງທຸລະກິດຂອງຕົນເອງ.

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

ຂະບວນການກັບຄືນ

ໃນເບື້ອງຕົ້ນ, ສອງລະບົບມີສ່ວນຮ່ວມໃນຂະບວນການ: BOB ແລະການຈ່າຍເງິນ. ດຽວນີ້ມີອີກສອງອັນປະກົດວ່າ:

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

ໃນປັດຈຸບັນຂະບວນການເບິ່ງຄືວ່ານີ້:

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

ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ສ້າງປະເພດຂອງລົດເມເຫດການໃນ Kafka - event-bus, ເຊິ່ງທຸກສິ່ງທຸກຢ່າງໄດ້ເລີ່ມຕົ້ນ. Hurray, ໃນປັດຈຸບັນພວກເຮົາມີຈຸດດຽວຂອງຄວາມລົ້ມເຫຼວ (sarcasm).

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

API ຂັບເຄື່ອນເຫດການແມ່ນຫຍັງ

ຄໍາຕອບທີ່ດີສໍາລັບຄໍາຖາມນີ້ແມ່ນຢູ່ໃນບົດລາຍງານໂດຍ Martin Fowler (GOTO 2017) "ຄວາມໝາຍຫຼາຍຢ່າງຂອງສະຖາປັດຕະຍະກຳທີ່ຂັບເຄື່ອນດ້ວຍເຫດການ".

ໂດຍຫຍໍ້ສິ່ງທີ່ພວກເຮົາໄດ້ເຮັດ:

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

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

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

ການແລກປ່ຽນ Async AS IS

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

ໃນບາງບ່ອນລົດເມ ESB ຖືກນໍາໃຊ້, ບາງຄົນອາໄສຢູ່ໃນ activeMQ, ແຕ່ໂດຍທົ່ວໄປ, RabbitMQ - ມາດຕະຖານ.

ການແລກປ່ຽນ Async TO BE

ເມື່ອອອກແບບການແລກປ່ຽນຜ່ານເຫດການລົດເມ, ການປຽບທຽບສາມາດຕິດຕາມໄດ້. ພວກເຮົາອະທິບາຍຄືກັນວ່າການແລກປ່ຽນຂໍ້ມູນໃນອະນາຄົດໂດຍຜ່ານລາຍລະອຽດໂຄງສ້າງເຫດການ. ຮູບແບບ yaml, ພວກເຮົາຕ້ອງເຮັດການສ້າງລະຫັດດ້ວຍຕົນເອງ, ຜູ້ຜະລິດສ້າງ DTOs ຕາມຂໍ້ກໍານົດແລະສອນລູກຄ້າແລະເຄື່ອງແມ່ຂ່າຍທີ່ຈະເຮັດວຽກກັບພວກເຂົາ. ການ​ຜະ​ລິດ​ເຂົ້າ​ໄປ​ໃນ​ສອງ​ພາ​ສາ - golang ແລະ php. ນີ້ຊ່ວຍໃຫ້ຫ້ອງສະຫມຸດມີຄວາມສອດຄ່ອງ. ເຄື່ອງກໍາເນີດໄຟຟ້າແມ່ນຂຽນເປັນ golang, ຊຶ່ງເປັນເຫດຜົນທີ່ວ່າມັນໄດ້ຮັບຊື່ gogi.

ແຫຼ່ງເຫດການໃນ Kafka ເປັນເລື່ອງປົກກະຕິ. ມີການແກ້ໄຂຈາກສະບັບວິສາຫະກິດຕົ້ນຕໍຂອງ Kafka Confluent, ມີ ນາດີ, ການແກ້ໄຂຈາກພີ່ນ້ອງໂດເມນຂອງພວກເຮົາ Zalando. ຂອງພວກເຮົາ ແຮງຈູງໃຈທີ່ຈະເລີ່ມຕົ້ນດ້ວຍ vanilla Kafka - ນີ້ຫມາຍຄວາມວ່າການປ່ອຍໃຫ້ການແກ້ໄຂຟຣີຈົນກ່ວາພວກເຮົາຕັດສິນໃຈໃນທີ່ສຸດວ່າພວກເຮົາຈະນໍາໃຊ້ມັນຢູ່ທົ່ວທຸກແຫ່ງ, ແລະຍັງປ່ອຍໃຫ້ຕົວເຮົາເອງມີພື້ນທີ່ສໍາລັບ maneuver ແລະການປັບປຸງ: ພວກເຮົາຕ້ອງການການສະຫນັບສະຫນູນຂອງພວກເຮົາ. JSON RPC 2.0, ເຄື່ອງກໍາເນີດໄຟຟ້າສໍາລັບສອງພາສາແລະໃຫ້ເຮົາເບິ່ງວ່າມີຫຍັງອີກແດ່.

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

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

ເຫດການ - ລົດເມ

ຫຼືລົດເມເຫດການ. ນີ້ແມ່ນພຽງແຕ່ປະຕູ http ທີ່ບໍ່ມີລັດ, ເຊິ່ງມີບົດບາດສໍາຄັນຫຼາຍ:

• ການຜະລິດຄວາມຖືກຕ້ອງ — ພວກ​ເຮົາ​ກວດ​ສອບ​ວ່າ​ກິດ​ຈະ​ກໍາ​ຕອບ​ສະ​ຫນອງ​ສະ​ເພາະ​ຂອງ​ພວກ​ເຮົາ​.
• ລະບົບແມ່ບົດເຫດການ, ນັ້ນແມ່ນ, ນີ້ແມ່ນລະບົບຕົ້ນຕໍແລະດຽວໃນບໍລິສັດທີ່ຕອບຄໍາຖາມຂອງເຫດການທີ່ມີໂຄງສ້າງໃດທີ່ຖືວ່າຖືກຕ້ອງ. ການກວດສອບພຽງແຕ່ກ່ຽວຂ້ອງກັບປະເພດຂໍ້ມູນແລະ enums ເພື່ອກໍານົດເນື້ອຫາຢ່າງເຂັ້ມງວດ.
• ຟັງຊັນ Hash ສໍາລັບ sharding - ໂຄງສ້າງຂໍ້ຄວາມ Kafka ແມ່ນ key-value ແລະການນໍາໃຊ້ hash ຂອງ key ມັນຖືກຄິດໄລ່ບ່ອນທີ່ຈະໃສ່ມັນ.

ເປັນຫຍັງ

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

1:n+1 ການແລກປ່ຽນ (ຫນຶ່ງຫາຫຼາຍ)

Kafka ເຮັດໃຫ້ມັນງ່າຍຫຼາຍໃນການເຊື່ອມຕໍ່ຜູ້ບໍລິໂພກໃຫມ່ກັບ API.

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

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

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

ຂັບເຄື່ອນດ້ວຍຂໍ້ມູນ

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

ບັນທຶກການຈໍາລອງ

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

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

ຕໍ່ໄປ, ການເລົ່າຄືນເອກະສານເລັກນ້ອຍ, ສໍາລັບຜູ້ທີ່ບໍ່ຄຸ້ນເຄີຍກັບ Kafka (ຮູບແມ່ນມາຈາກເອກະສານ)

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

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

ຕາມນັ້ນແລ້ວ, ເຫດຜົນທີ່ແຕກຕ່າງກັນສາມາດປະຕິບັດໄດ້. ຕົວຢ່າງ, ພວກເຮົາມີ BOB ໃນ 4 ຕົວຢ່າງສໍາລັບປະເທດທີ່ແຕກຕ່າງກັນ - Lamoda ແມ່ນຢູ່ໃນລັດເຊຍ, Kazakhstan, Ukraine, Belarus. ເນື່ອງຈາກພວກມັນຖືກນຳໃຊ້ແຍກຕ່າງຫາກ, ພວກເຂົາເຈົ້າມີການຕັ້ງຄ່າທີ່ແຕກຕ່າງກັນເລັກນ້ອຍ ແລະເຫດຜົນທາງທຸລະກິດຂອງຕົນເອງ. ພວກເຮົາລະບຸໃນຂໍ້ຄວາມທີ່ມັນຫມາຍເຖິງປະເທດ. ຜູ້ບໍລິໂພກ BOB ໃນແຕ່ລະປະເທດອ່ານດ້ວຍ groupId ທີ່ແຕກຕ່າງກັນ, ແລະຖ້າຂໍ້ຄວາມບໍ່ນໍາໃຊ້ກັບພວກເຂົາ, ເຂົາເຈົ້າຂ້າມມັນ, i.e. commits ທັນທີທັນໃດຊົດເຊີຍ +1. ຖ້າຫົວຂໍ້ດຽວກັນຖືກອ່ານໂດຍການບໍລິການຊໍາລະຂອງພວກເຮົາ, ມັນຈະເຮັດແນວນັ້ນກັບກຸ່ມແຍກຕ່າງຫາກ, ແລະດັ່ງນັ້ນການຊົດເຊີຍບໍ່ຕັດກັນ.

ຄວາມຕ້ອງການເຫດການ:

• ຄວາມສົມບູນຂອງຂໍ້ມູນ. ຂ້ອຍຕ້ອງການໃຫ້ເຫດການມີຂໍ້ມູນພຽງພໍເພື່ອໃຫ້ມັນສາມາດປະມວນຜົນໄດ້.

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

Kafka ໃນ Lamoda

ພວກເຮົາມີສາມການຕິດຕັ້ງ Kafka:

1. ບັນທຶກ;
2. R&D;
3. ເຫດການ - ລົດເມ.

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

ຂ້າງເທິງນີ້ແມ່ນກາຟ rps. ຂະບວນການຄືນເງິນແມ່ນຫມາຍດ້ວຍເສັ້ນ turquoise (ແມ່ນ, ຫນຶ່ງໃນແກນ X), ແລະເສັ້ນສີບົວແມ່ນຂະບວນການປັບປຸງເນື້ອໃນ.

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

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

Lamoda Events ໃຊ້ກໍລະນີ

ພວກເຮົາໃຊ້ສະຖາປັດຕະຍະກໍາທີ່ສ້າງຂຶ້ນສໍາລັບການດໍາເນີນງານຕໍ່ໄປນີ້:

• ຕິດຕາມສະຖານະການກັບຄືນ: call-to-action ແລະການຕິດຕາມສະຖານະຈາກທຸກລະບົບທີ່ກ່ຽວຂ້ອງ. ການຈ່າຍເງິນ, ສະຖານະ, ງົບປະມານ, ແຈ້ງການ. ໃນທີ່ນີ້ພວກເຮົາໄດ້ທົດສອບວິທີການ, ສ້າງເຄື່ອງມື, ເກັບກໍາຂໍ້ບົກພ່ອງທັງຫມົດ, ຂຽນເອກະສານແລະບອກເພື່ອນຮ່ວມງານຂອງພວກເຮົາວິທີການນໍາໃຊ້ມັນ.
• ກຳລັງອັບເດດບັດຜະລິດຕະພັນ: ການຕັ້ງຄ່າ, meta-data, ຄຸນລັກສະນະ. ລະບົບຫນຶ່ງອ່ານ (ທີ່ສະແດງ), ແລະຂຽນຫຼາຍໆຄັ້ງ.
• ສົ່ງອີເມວ, ຊຸກຍູ້ແລະ sms: ຄໍາ​ສັ່ງ​ໄດ້​ຖືກ​ເກັບ​ກໍາ​, ຄໍາ​ສັ່ງ​ໄດ້​ມາ​ເຖິງ​, ການ​ກັບ​ຄືນ​ໄດ້​ຮັບ​ການ​ຍອມ​ຮັບ​, ແລະ​ອື່ນໆ​, ມີ​ຈໍາ​ນວນ​ຫຼາຍ​ຂອງ​ເຂົາ​ເຈົ້າ​.
• ຫຼັກຊັບ, ການຕໍ່ອາຍຸສາງ - ການປັບປຸງປະລິມານຂອງລາຍການ, ພຽງແຕ່ຕົວເລກ: ມາຮອດສາງ, ກັບຄືນ. ມັນເປັນສິ່ງຈໍາເປັນທີ່ລະບົບທັງຫມົດທີ່ກ່ຽວຂ້ອງກັບການຈອງສິນຄ້າດໍາເນີນການກັບຂໍ້ມູນໃນປະຈຸບັນຫຼາຍທີ່ສຸດ. ໃນປັດຈຸບັນ, ລະບົບການປັບປຸງຫຼັກຊັບແມ່ນຂ້ອນຂ້າງສັບສົນ; Kafka ຈະເຮັດໃຫ້ມັນງ່າຍດາຍ.
• ການ​ວິ​ເຄາະ​ຂໍ້​ມູນ (ພະແນກ R&D), ເຄື່ອງມື ML, ການວິເຄາະ, ສະຖິຕິ. ພວກເຮົາຕ້ອງການຂໍ້ມູນທີ່ມີຄວາມໂປ່ງໃສ - Kafka ແມ່ນເຫມາະສົມດີສໍາລັບການນີ້.

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

ບັນຫາການອອກແບບ

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

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

ກະແສຂໍ້ມູນ

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

ໃນຫົວຂໍ້ຫນຶ່ງຫຼືໃນຫົວຂໍ້ທີ່ແຕກຕ່າງກັນ?

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

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

ພາກສະຫນາມໃຫມ່ຫຼືເຫດການໃຫມ່?

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

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

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

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

ເວີຊັນເຫດການ

ເພື່ອກວດສອບຂໍ້ຄວາມໃນ Kafka ທ່ານສາມາດນໍາໃຊ້ Avro, ແຕ່ມັນຈໍາເປັນຕ້ອງວາງມັນທັນທີແລະໃຊ້ Confluent. ໃນກໍລະນີຂອງພວກເຮົາ, ພວກເຮົາຕ້ອງລະມັດລະວັງກັບສະບັບ. ມັນຈະບໍ່ເປັນໄປໄດ້ສະເໝີທີ່ຈະອ່ານຂໍ້ຄວາມຈາກບັນທຶກການຈຳລອງຄືນໃໝ່ ເພາະວ່າຕົວແບບມີ “ຊ້າຍ”. ໂດຍພື້ນຖານແລ້ວ, ມັນຫັນອອກການກໍ່ສ້າງສະບັບເພື່ອໃຫ້ຮູບແບບແມ່ນເຂົ້າກັນໄດ້ກັບຫລັງ: ຕົວຢ່າງ, ເຮັດໃຫ້ພາກສະຫນາມເປັນທາງເລືອກຊົ່ວຄາວ. ຖ້າຄວາມແຕກຕ່າງທີ່ເຂັ້ມແຂງເກີນໄປ, ພວກເຮົາເລີ່ມຕົ້ນຂຽນໃນຫົວຂໍ້ໃຫມ່, ແລະໂອນລູກຄ້າເມື່ອພວກເຂົາອ່ານຫົວຂໍ້ເກົ່າ.

ການ​ຮັບ​ປະ​ກັນ​ການ​ອ່ານ​ຄໍາ​ສັ່ງ​ຂອງ​ການ​ແບ່ງ​ປັນ​

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

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

Kafka ແບ່ງພວກມັນແນວໃດ? ແຕ່ລະຂໍ້ຄວາມມີເນື້ອໃນ (ທີ່ພວກເຮົາເກັບຮັກສາ JSON) ແລະກະແຈ. ທ່ານສາມາດແນບຟັງຊັນ hash ກັບກະແຈນີ້, ເຊິ່ງຈະກໍານົດວ່າການແບ່ງປັນຂໍ້ຄວາມໃດຈະເຂົ້າໄປໃນ.

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

ເຫດການທຽບກັບຄໍາສັ່ງ

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

ແຕ່ປົກກະຕິແລ້ວ, ໃນເວລາທີ່ທ່ານອອກແບບເຫດການ, ທ່ານບໍ່ຕ້ອງການທີ່ຈະຂຽນໃຫ້ເຂົາເຈົ້າບໍ່ມີປະໂຍດ - ທ່ານອີງໃສ່ຄວາມຈິງທີ່ວ່າຜູ້ໃດຜູ້ຫນຶ່ງຈະອ່ານໃຫ້ເຂົາເຈົ້າ. ມີການລໍ້ລວງສູງທີ່ຈະຂຽນບໍ່ບາງສິ່ງບາງຢ່າງ_happened (item_canceled, refund_refunded), ແຕ່ບາງສິ່ງບາງຢ່າງ_should_be_done. ຕົວຢ່າງ, ລາຍການແມ່ນພ້ອມທີ່ຈະຖືກສົ່ງຄືນ.

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

ໃນການແລກປ່ຽນ asynchronous ໃນ RabbitMQ, ເມື່ອທ່ານອ່ານຂໍ້ຄວາມ, ໄປທີ່ http, ທ່ານມີຄໍາຕອບ - ຢ່າງຫນ້ອຍວ່າຂໍ້ຄວາມໄດ້ຮັບ. ໃນເວລາທີ່ທ່ານຂຽນໄປຫາ Kafka, ມີຂໍ້ຄວາມທີ່ທ່ານຂຽນໄປຫາ Kafka, ແຕ່ທ່ານບໍ່ຮູ້ຫຍັງກ່ຽວກັບວິທີການປຸງແຕ່ງມັນ.

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

Nuances

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

ພວກ​ເຮົາ​ຮູ້​ກ່ຽວ​ກັບ​ມັນ, ພວກ​ເຮົາ​ນັບ​ຖື​ກ່ຽວ​ກັບ​ມັນ, ແລະ​ທັນ​ທີ​ມັນ​ເກີດ​ຂຶ້ນ. ແລະນີ້ເກີດຂຶ້ນເນື່ອງຈາກວ່າເຫດການແມ່ນຖືກຕ້ອງຈາກທັດສະນະຂອງເຫດການ -bus, ເຫດການແມ່ນຖືກຕ້ອງຈາກທັດສະນະຂອງຜູ້ກວດສອບຄໍາຮ້ອງສະຫມັກ, ແຕ່ມັນບໍ່ຖືກຕ້ອງຈາກທັດສະນະຂອງ PostgreSQL, ເພາະວ່າໃນລະບົບດຽວຂອງພວກເຮົາ. MySQL ກັບ UNSIGNED INT, ແລະໃນການຂຽນໃຫມ່ລະບົບມີ PostgreSQL ພຽງແຕ່ກັບ INT. ຂະຫນາດຂອງລາວແມ່ນນ້ອຍກວ່າ, ແລະ Id ບໍ່ເຫມາະ. Symfony ໄດ້ເສຍຊີວິດດ້ວຍຂໍ້ຍົກເວັ້ນ. ພວກເຮົາ, ແນ່ນອນ, ຈັບຂໍ້ຍົກເວັ້ນເພາະວ່າພວກເຮົາອີງໃສ່ມັນ, ແລະກໍາລັງຈະປະຕິບັດການຊົດເຊີຍນີ້, ແຕ່ກ່ອນຫນ້ານັ້ນພວກເຮົາຕ້ອງການເພີ່ມທະວີການຕ້ານບັນຫາ, ເນື່ອງຈາກວ່າຂໍ້ຄວາມໄດ້ຖືກປະມວນຜົນບໍ່ສໍາເລັດ. ເຄົາເຕີໃນໂຄງການນີ້ຍັງຢູ່ໃນຖານຂໍ້ມູນ, ແລະ Symfony ໄດ້ປິດການສື່ສານກັບຖານຂໍ້ມູນແລ້ວ, ແລະຂໍ້ຍົກເວັ້ນທີສອງໄດ້ຂ້າຂະບວນການທັງຫມົດໂດຍບໍ່ມີໂອກາດທີ່ຈະຊົດເຊີຍ.

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

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

nuance ອີກ​ປະ​ການ​ຫນຶ່ງ - ບັນທຶກການຈໍາລອງທຽບກັບ rdkafka.so - ແມ່ນກ່ຽວຂ້ອງກັບສະເພາະຂອງໂຄງການຂອງພວກເຮົາ. ພວກເຮົາໃຊ້ PHP, ແລະໃນ PHP, ຕາມກົດລະບຽບ, ຫ້ອງສະຫມຸດທັງຫມົດຕິດຕໍ່ກັບ Kafka ຜ່ານ repository rdkafka.so, ແລະຫຼັງຈາກນັ້ນມີບາງປະເພດຂອງ wrapper. ບາງທີສິ່ງເຫຼົ່ານີ້ແມ່ນຄວາມຫຍຸ້ງຍາກສ່ວນຕົວຂອງພວກເຮົາ, ແຕ່ມັນໄດ້ຫັນອອກວ່າການອ່ານຄືນໃຫມ່ຂອງສິ່ງທີ່ພວກເຮົາໄດ້ອ່ານແລ້ວບໍ່ແມ່ນເລື່ອງງ່າຍ. ໂດຍທົ່ວໄປ, ມີບັນຫາຊອບແວ.

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

ການຕິດຕາມ

ຂ້າພະເຈົ້າຄິດວ່າວິທີທີ່ພວກເຮົາຕິດຕາມມັນຈະຊັດເຈນກວ່າວ່າບັນຫາໃດຢູ່ໃນວິທີການທີ່ມີຢູ່.

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

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

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

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

ນີ້ແມ່ນສິ່ງທີ່ການຕອບສະຫນອງ API ເບິ່ງຄືວ່າ. ນີ້ແມ່ນກຸ່ມ bob-live-fifa, partition refund.update.v1, ສະຖານະ OK, lag 0 - ສຸດທ້າຍ offset ດັ່ງກ່າວແລະອື່ນໆ.

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

ເພື່ອສະຫຼຸບ, ການນໍາໃຊ້ເຫດການແມ່ນສະດວກໃນເວລາທີ່:

• ຂໍ້ມູນແມ່ນຕ້ອງການໂດຍລະບົບຫຼາຍ;
• ຜົນໄດ້ຮັບຂອງການປຸງແຕ່ງແມ່ນບໍ່ສໍາຄັນ;
• ມີເຫດການເລັກນ້ອຍຫຼືເຫດການນ້ອຍໆ.

ມັນຈະເບິ່ງຄືວ່າບົດຄວາມມີຫົວຂໍ້ສະເພາະຫຼາຍ - asynchronous API on Kafka, ແຕ່ໃນການເຊື່ອມຕໍ່ກັບມັນຂ້າພະເຈົ້າຢາກຈະແນະນໍາຫຼາຍສິ່ງໃນເວລາດຽວກັນ.
ທໍາອິດ, ຕໍ່ໄປ ໂຫຼດສູງ ++ ພວກເຮົາຈໍາເປັນຕ້ອງລໍຖ້າຈົນກ່ວາເດືອນພະຈິກ; ໃນເດືອນເມສາຈະມີສະບັບ St. Petersburg, ແລະໃນເດືອນມິຖຸນາພວກເຮົາຈະເວົ້າກ່ຽວກັບການໂຫຼດສູງໃນ Novosibirsk.
ອັນທີສອງ, ຜູ້ຂຽນບົດລາຍງານ, Sergei Zaika, ເປັນສະມາຊິກຂອງຄະນະກໍາມະການໂຄງການຂອງກອງປະຊຸມໃຫມ່ຂອງພວກເຮົາກ່ຽວກັບການຄຸ້ມຄອງຄວາມຮູ້. KnowledgeConf. ກອງ​ປະ​ຊຸມ​ແມ່ນ​ຫນຶ່ງ​ມື້​, ຈະ​ຈັດ​ຂຶ້ນ​ໃນ​ວັນ​ທີ 26 ເມ​ສາ​, ແຕ່​ໂຄງ​ການ​ຂອງ​ຕົນ​ແມ່ນ​ເຂັ້ມ​ແຂງ​.
ແລະມັນຈະຢູ່ໃນເດືອນພຶດສະພາ PHP ລັດເຊຍ и RIT++ (ມີ DevOpsConf ລວມ) - ທ່ານຍັງສາມາດແນະນໍາຫົວຂໍ້ຂອງທ່ານຢູ່ທີ່ນັ້ນ, ສົນທະນາກ່ຽວກັບປະສົບການຂອງທ່ານແລະຈົ່ມກ່ຽວກັບໂກນ stuffed ຂອງທ່ານ.

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