ປະຫວັດຂອງສະຖາປັດຕະຍະກໍາ Dodo IS: ເສັ້ນທາງ Back Office

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

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

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

ຊຸດຂອງບົດຄວາມ "Dodo IS ແມ່ນຫຍັງ?" ບອກກ່ຽວກັບ:

1. ຕົ້ນ monolith ໃນ Dodo IS (2011-2015). (ກຳລັງດຳເນີນຢູ່...)
2. ເສັ້ນທາງຫລັງຫ້ອງການ: ຖານທີ່ແຍກຕ່າງຫາກແລະລົດເມ. (ເຈົ້າ​ຢູ່​ທີ່​ນີ້)
3. ເສັ້ນທາງຂ້າງລູກຄ້າ: facade ໃນໄລຍະຖານ (2016-2017). (ກຳລັງດຳເນີນຢູ່...)
4. ປະຫວັດຂອງ microservices ທີ່ແທ້ຈິງ. (2018-2019). (ກຳລັງດຳເນີນຢູ່...)
5. ສໍາເລັດການ sawing ຂອງ monolith ແລະສະຖຽນລະພາບຂອງສະຖາປັດຕະ. (ກຳລັງດຳເນີນຢູ່...)

ຖ້າທ່ານສົນໃຈຢາກຮູ້ສິ່ງອື່ນ - ຂຽນໃນຄໍາເຫັນ.

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

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

• ຄວາມເປັນຈິງແມ່ນແຕກຕ່າງຈາກສິ່ງທີ່ຢູ່ໃນເຈ້ຍ. ບໍ່ແມ່ນທຸກຢ່າງເຮັດວຽກຕາມທີ່ຕັ້ງໃຈໄວ້. ແລະພວກເຮົາມີຄວາມສົນໃຈໃນວິທີການຕົວຈິງແລ້ວໄດ້ຫັນອອກແລະເຮັດວຽກ.
• ການນໍາສະເຫນີຂໍ້ມູນຂ່າວສານທີ່ສອດຄ່ອງ. ໃນ​ຄວາມ​ເປັນ​ຈິງ, you can go chronologically from the beginning to the current state .
• ຈາກງ່າຍດາຍໄປຫາສະລັບສັບຊ້ອນ. ບໍ່ແມ່ນທົ່ວໄປ, ແຕ່ໃນກໍລະນີຂອງພວກເຮົາມັນແມ່ນ. ສະຖາປັດຕະຍະກໍາໄດ້ຍ້າຍຈາກວິທີການທີ່ງ່າຍດາຍໄປສູ່ວິທີການທີ່ສັບສົນກວ່າ. ເລື້ອຍໆໂດຍຜ່ານຄວາມສັບສົນ, ບັນຫາຂອງຄວາມໄວການປະຕິບັດແລະຄວາມຫມັ້ນຄົງໄດ້ຖືກແກ້ໄຂ, ເຊັ່ນດຽວກັນກັບຫຼາຍສິບຄຸນສົມບັດອື່ນໆຈາກບັນຊີລາຍຊື່ຂອງຄວາມຕ້ອງການທີ່ບໍ່ມີປະໂຫຍດ (ທີ່ນີ້ ບອກໄດ້ດີກ່ຽວກັບຄວາມສັບສົນທີ່ກົງກັນຂ້າມກັບຄວາມຕ້ອງການອື່ນໆ).

ໃນປີ 2011, ສະຖາປັດຕະຍະກຳ Dodo IS ມີລັກສະນະດັ່ງນີ້:

ໃນປີ 2020, ມັນໄດ້ກາຍເປັນຄວາມສັບສົນເລັກນ້ອຍແລະກາຍເປັນແບບນີ້:

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

ບັນຫາທໍາອິດຂອງປີ 2016: ເປັນຫຍັງການບໍລິການຄວນອອກຈາກ monolith

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

ຖານຂໍ້ມູນ MySql ດຽວ, ໃນທຸກຄໍາຮ້ອງສະຫມັກທີ່ມີຢູ່ໃນ Dodo IS ຂຽນບັນທຶກຂອງພວກເຂົາ. ຜົນສະທ້ອນແມ່ນ:

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

ບັນຫາແມ່ນການປະກົດຕົວຂອງ monolith ຕົວຂອງມັນເອງ. ຜົນສະທ້ອນແມ່ນ:

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

ບັນຫາກ່ຽວກັບພື້ນຖານແລະ monolith ໄດ້ຖືກອະທິບາຍຫຼາຍຄັ້ງ, ສໍາລັບການຍົກຕົວຢ່າງ, ໃນສະພາບການຂອງອຸປະຕິເຫດໃນຕົ້ນປີ 2018 (ຄືກັບ Munch, ຫຼືສອງສາມຄໍາກ່ຽວກັບຫນີ້ສິນດ້ານວິຊາການ, ມື້ Dodo IS ຢຸດເຊົາ. Asynchronous Script и ເລື່ອງຂອງນົກ Dodo ຈາກຄອບຄົວ Phoenix. ການຫຼຸດລົງທີ່ຍິ່ງໃຫຍ່ຂອງ Dodo IS), ສະນັ້ນຂ້າພະເຈົ້າຈະບໍ່ອາໄສຢູ່ຫຼາຍເກີນໄປ. ໃຫ້ຂ້າພະເຈົ້າພຽງແຕ່ເວົ້າວ່າພວກເຮົາຕ້ອງການໃຫ້ຄວາມຍືດຫຍຸ່ນຫຼາຍໃນເວລາທີ່ການພັດທະນາການບໍລິການ. ກ່ອນອື່ນ ໝົດ, ສິ່ງນີ້ກ່ຽວຂ້ອງກັບຜູ້ທີ່ຖືກໂຫລດຫຼາຍທີ່ສຸດແລະຮາກໃນລະບົບທັງຫມົດ - Auth ແລະ Tracker.

ເສັ້ນທາງສໍານັກງານກັບຄືນໄປບ່ອນ: ຖານທີ່ແຍກຕ່າງຫາກແລະລົດເມ

ບົດນໍາທາງ

1. ໂຄງການ Monolith 2016
2. ເລີ່ມຕົ້ນທີ່ຈະ Unload Monolith: Auth and Tracker Separation
   
3. Auth ເຮັດຫຍັງ?
4. ໂຫຼດມາຈາກໃສ?
5. ກຳລັງຖອນການອະນຸຍາດ
6. Tracker ເຮັດຫຍັງ?
7. ໂຫຼດມາຈາກໃສ?
8. ກຳລັງຖອນຕົວຕິດຕາມ

ໂຄງການ Monolith 2016

ນີ້ແມ່ນບັນດາທ່ອນໄມ້ຕົ້ນຕໍຂອງ Dodo IS 2016 monolith, ແລະພຽງແຕ່ຂ້າງລຸ່ມນີ້ແມ່ນບົດບັນທຶກຂອງວຽກງານຕົ້ນຕໍຂອງພວກເຂົາ.

ການຈັດສົ່ງເງິນສົດ. ການ​ບັນ​ຊີ​ສໍາ​ລັບ​ການ couriers​, ການ​ອອກ​ຄໍາ​ສັ່ງ​ໃຫ້ couriers​.
ຕິດຕໍ່ສູນ. ການຍອມຮັບຄໍາສັ່ງຜ່ານຜູ້ປະກອບການ.
ເວັບໄຊ. ເວັບໄຊທ໌ຂອງພວກເຮົາ (dodopizza.ru, dodopizza.co.uk, dodopizza.by, ແລະອື່ນໆ).
Auth. ການບໍລິການການອະນຸຍາດແລະການກວດສອບຄວາມຖືກຕ້ອງສໍາລັບຫ້ອງການຫລັງ.
ບົບຕິດຕາມລຸດ. ສັ່ງຕິດຕາມໃນເຮືອນຄົວ. ການບໍລິການສໍາລັບເຄື່ອງຫມາຍສະຖານະການກຽມພ້ອມໃນເວລາກະກຽມຄໍາສັ່ງ.
ໂຕະເກັບເງິນຂອງຮ້ານອາຫານ. ຮັບຄໍາສັ່ງໃນຮ້ານອາຫານ, ການໂຕ້ຕອບ cashier.
ການສົ່ງອອກ. ການອັບໂຫລດບົດລາຍງານໃນ 1C ສໍາລັບບັນຊີ.
ແຈ້ງການ ແລະໃບແຈ້ງໜີ້. ຄຳສັ່ງສຽງໃນເຮືອນຄົວ (ຕົວຢ່າງ: "Pizza ໃໝ່ມາຮອດແລ້ວ") + ການພິມໃບແຈ້ງໜີ້ສຳລັບຜູ້ຈັດສົ່ງ.
ຜູ້ຈັດການ Shift. ການໂຕ້ຕອບສໍາລັບການເຮັດວຽກຂອງຜູ້ຈັດການການປ່ຽນແປງ: ບັນຊີລາຍຊື່ຂອງຄໍາສັ່ງ, ເສັ້ນສະແດງຜົນການປະຕິບັດ, ການໂອນພະນັກງານໄປສູ່ການປ່ຽນແປງ.
ຜູ້​ຈັດ​ການ​ຫ້ອງ​ການ. ການໂຕ້ຕອບສໍາລັບການເຮັດວຽກຂອງ franchisee ແລະຜູ້ຈັດການ: ການຕ້ອນຮັບຂອງພະນັກງານ, ບົດລາຍງານກ່ຽວກັບການເຮັດວຽກຂອງ pizzeria ໄດ້.
ກະດານຄະແນນຮ້ານອາຫານ. ເມນູສະແດງຢູ່ໃນໂທລະພາບໃນ pizzerias.
admin. ການຕັ້ງຄ່າໃນ pizzeria ສະເພາະ: ເມນູ, ລາຄາ, ການບັນຊີ, ລະຫັດໂປໂມຊັ່ນ, ໂປໂມຊັ່ນ, ປ້າຍໂຄສະນາເວັບໄຊທ໌, ແລະອື່ນໆ.
ບັນຊີສ່ວນຕົວຂອງພະນັກງານ. ຕາຕະລາງການເຮັດວຽກຂອງພະນັກງານ, ຂໍ້ມູນກ່ຽວກັບພະນັກງານ.
ກະດານແຮງຈູງໃຈເຮືອນຄົວ. ຫນ້າຈໍແຍກຕ່າງຫາກທີ່ hangs ໃນເຮືອນຄົວແລະສະແດງຄວາມໄວຂອງຜູ້ຜະລິດ pizza ໄດ້.
ການສື່ສານ. ການ​ສົ່ງ sms ແລະ​ອີ​ເມລ​໌​.
ການເກັບຮັກສາໄຟລ໌. ບໍລິການຂອງຕົນເອງສໍາລັບການຮັບແລະອອກໄຟລ໌ຄົງທີ່.

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

ເລີ່ມຕົ້ນທີ່ຈະ Unload Monolith: Auth and Tracker Separation

ການບໍລິການຕົ້ນຕໍທີ່ຫຼັງຈາກນັ້ນບັນທຶກແລະອ່ານຈາກຖານຂໍ້ມູນຫຼາຍກ່ວາຄົນອື່ນ:

1. ຄວາມຖືກຕ້ອງ. ການບໍລິການການອະນຸຍາດແລະການກວດສອບຄວາມຖືກຕ້ອງສໍາລັບຫ້ອງການຫລັງ.
2. ບົບຕິດຕາມລຸດ. ສັ່ງຕິດຕາມໃນເຮືອນຄົວ. ການບໍລິການສໍາລັບເຄື່ອງຫມາຍສະຖານະການກຽມພ້ອມໃນເວລາກະກຽມຄໍາສັ່ງ.

Auth ເຮັດຫຍັງ?

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

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

ໂຫຼດມາຈາກໃສ?

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

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

ກຳລັງຖອນການອະນຸຍາດ

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

ແມ່ນ. ໂຄງ​ການ​ຕົ້ນ​ສະ​ບັບ​ຂອງ​ການ​ເຮັດ​ວຽກ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

ຂ້າພະເຈົ້າຢາກອະທິບາຍເລັກນ້ອຍວ່າມັນເຮັດວຽກແນວໃດ:

1. ການຮ້ອງຂໍຈາກພາຍນອກມາຮອດ backend (ມີ Asp.Net MVC), ເອົາຄຸກກີເຊດຊັນ, ເຊິ່ງຖືກນໍາໃຊ້ເພື່ອເອົາຂໍ້ມູນເຊດຊັນຈາກ Redis(1). ມັນມີຂໍ້ມູນກ່ຽວກັບການເຂົ້າເຖິງ, ແລະຫຼັງຈາກນັ້ນການເຂົ້າເຖິງຕົວຄວບຄຸມແມ່ນເປີດ (3,4), ຫຼືບໍ່.
2. ຖ້າບໍ່ມີການເຂົ້າເຖິງ, ທ່ານຈໍາເປັນຕ້ອງຜ່ານຂັ້ນຕອນການອະນຸຍາດ. ທີ່ນີ້, ສໍາລັບຄວາມງ່າຍດາຍ, ມັນຖືກສະແດງເປັນສ່ວນຫນຶ່ງຂອງເສັ້ນທາງໃນຄຸນລັກສະນະດຽວກັນ, ເຖິງແມ່ນວ່າມັນເປັນການຫັນປ່ຽນໄປຫາຫນ້າເຂົ້າສູ່ລະບົບ. ໃນກໍລະນີຂອງສະຖານະການໃນທາງບວກ, ພວກເຮົາຈະໄດ້ຮັບກອງປະຊຸມທີ່ສໍາເລັດຢ່າງຖືກຕ້ອງແລະໄປຫາ Backoffice Controller.
3. ຖ້າມີຂໍ້ມູນ, ຫຼັງຈາກນັ້ນທ່ານຈໍາເປັນຕ້ອງກວດເບິ່ງວ່າມັນມີຄວາມກ່ຽວຂ້ອງໃນຖານຂໍ້ມູນຜູ້ໃຊ້. ບົດບາດຂອງລາວໄດ້ປ່ຽນແປງ, ລາວບໍ່ຄວນຖືກອະນຸຍາດໃຫ້ຢູ່ໃນຫນ້າໃນປັດຈຸບັນບໍ? ໃນກໍລະນີນີ້, ຫຼັງຈາກໄດ້ຮັບກອງປະຊຸມ (1), ທ່ານຈໍາເປັນຕ້ອງໄດ້ໄປຫາຖານຂໍ້ມູນໂດຍກົງແລະກວດສອບການເຂົ້າເຖິງຂອງຜູ້ໃຊ້ໂດຍໃຊ້ຊັ້ນເຫດຜົນຂອງການກວດສອບຄວາມຖືກຕ້ອງ (2). ຕໍ່ໄປ, ໄປຫາຫນ້າເຂົ້າສູ່ລະບົບ, ຫຼືໄປຫາຕົວຄວບຄຸມ. ດັ່ງກ່າວເປັນລະບົບງ່າຍດາຍ, ແຕ່ບໍ່ແມ່ນມາດຕະຖານຂ້ອນຂ້າງ.
4. ຖ້າຂັ້ນຕອນທັງຫມົດຖືກຜ່ານ, ຫຼັງຈາກນັ້ນພວກເຮົາຂ້າມໄປຕື່ມອີກໃນເຫດຜົນໃນຕົວຄວບຄຸມແລະວິທີການ.

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

ກາຍ​ເປັນ. ດັ່ງນັ້ນເຂົາເຈົ້າໄດ້ເຮັດ:

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

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

ເປັນຫຍັງການແຍກຕົວຈຶ່ງໃຊ້ເວລາດົນ?
ມີ​ບັນ​ຫາ​ຈໍາ​ນວນ​ຫຼາຍ​ໃນ​ເສັ້ນ​ທາງ​ທີ່​ເຮັດ​ໃຫ້​ພວກ​ເຮົາ​ຊ້າ​ລົງ​:

1. ພວກ​ເຮົາ​ຕ້ອງ​ການ​ທີ່​ຈະ​ຍ້າຍ​ຂໍ້​ມູນ​ຜູ້​ໃຊ້​, ອຸ​ປະ​ກອນ​, ແລະ​ການ​ກວດ​ສອບ​ຈາກ​ຖານ​ຂໍ້​ມູນ​ສະ​ເພາະ​ປະ​ເທດ​ເປັນ​ຫນຶ່ງ​. ເພື່ອເຮັດສິ່ງນີ້, ພວກເຮົາຕ້ອງແປຕາຕະລາງທັງຫມົດແລະການນໍາໃຊ້ຈາກ int identifier ໄປຫາຕົວລະບຸ UUId ທົ່ວໂລກ (ບໍ່ດົນມານີ້ໄດ້ເຮັດວຽກໃຫມ່ລະຫັດນີ້. Roman Bukin "Uuid - ເລື່ອງໃຫຍ່ຂອງໂຄງສ້າງຂະຫນາດນ້ອຍ" ແລະໂຄງການແຫຼ່ງເປີດ ພື້ນຖານ). ການເກັບຮັກສາຂໍ້ມູນຜູ້ໃຊ້ (ເນື່ອງຈາກມັນເປັນຂໍ້ມູນສ່ວນບຸກຄົນ) ມີຂໍ້ຈໍາກັດຂອງມັນແລະສໍາລັບບາງປະເທດມັນຈໍາເປັນຕ້ອງເກັບຮັກສາພວກມັນແຍກຕ່າງຫາກ. ແຕ່ id ທົ່ວໂລກຂອງຜູ້ໃຊ້ຕ້ອງເປັນ.
2. ຫຼາຍໆຕາຕະລາງໃນຖານຂໍ້ມູນມີຂໍ້ມູນການກວດສອບກ່ຽວກັບຜູ້ໃຊ້ທີ່ດໍາເນີນການປະຕິບັດງານ. ນີ້ຮຽກຮ້ອງໃຫ້ມີກົນໄກເພີ່ມເຕີມສໍາລັບຄວາມສອດຄ່ອງ.
3. ຫຼັງຈາກການສ້າງການບໍລິການ api, ມີໄລຍະເວລາທີ່ຍາວນານແລະຄ່ອຍໆປ່ຽນໄປສູ່ລະບົບອື່ນ. ການສະຫຼັບຕ້ອງມີຄວາມລຽບງ່າຍສຳລັບຜູ້ໃຊ້ ແລະຕ້ອງເຮັດວຽກດ້ວຍມື.

ໂຄງການລົງທະບຽນອຸປະກອນໃນ pizzeria:

ສະຖາປັດຕະຍະກໍາທົ່ວໄປຫຼັງຈາກການສະກັດເອົາການບໍລິການ Auth ແລະອຸປະກອນ:

Примечание. ສໍາລັບປີ 2020, ພວກເຮົາກຳລັງເຮັດວຽກຢູ່ໃນເວີຊັນໃໝ່ຂອງ Auth, ເຊິ່ງອີງໃສ່ມາດຕະຖານການອະນຸຍາດ OAuth 2.0. ມາດຕະຖານນີ້ແມ່ນຂ້ອນຂ້າງສັບສົນ, ແຕ່ມັນເປັນປະໂຫຍດສໍາລັບການພັດທະນາການບໍລິການຜ່ານການກວດສອບຄວາມຖືກຕ້ອງ. ໃນບົດຄວາມ "subtleties ຂອງການອະນຸຍາດ: ພາບລວມຂອງເຕັກໂນໂລຊີ OAuth 2.0» ພວກເຮົາ Alexey Chernyaev ພະຍາຍາມບອກກ່ຽວກັບມາດຕະຖານຢ່າງງ່າຍດາຍແລະຊັດເຈນເທົ່າທີ່ເປັນໄປໄດ້ເພື່ອໃຫ້ເຈົ້າປະຫຍັດເວລາໃນການສຶກສາມັນ.

Tracker ເຮັດຫຍັງ?

ໃນປັດຈຸບັນກ່ຽວກັບການທີ່ສອງຂອງການບໍລິການໂຫຼດໄດ້. ຕົວຕິດຕາມປະຕິບັດບົດບາດສອງຢ່າງ:

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

ເມື່ອຜະລິດຕະພັນໃຫມ່ປາກົດຢູ່ໃນຄໍາສັ່ງ (ຕົວຢ່າງ, pizza), ມັນຈະໄປຫາສະຖານີຕິດຕາມ Rolling out. ຢູ່ທີ່ສະຖານີນີ້, ມີຜູ້ຜະລິດ pizza ທີ່ເອົາ bun ຂອງຂະຫນາດທີ່ຕ້ອງການແລະມ້ວນມັນອອກ, ຫຼັງຈາກນັ້ນລາວໄດ້ບັນທຶກໄວ້ໃນແທັບເລັດ tracker ວ່າລາວໄດ້ສໍາເລັດວຽກງານຂອງລາວແລະໂອນພື້ນຖານ dough ມ້ວນໄປສະຖານີຕໍ່ໄປ - "ການລິເລີ່ມ" .

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

ນີ້ແມ່ນວິທີການທີ່ຫນ້າຈໍຂອງແທັບເລັດເບິ່ງຄືວ່າຢູ່ໃນສະຖານີຕິດຕາມ "Raskatka"

ໂຫຼດມາຈາກໃສ?

ແຕ່ລະ pizzerias ມີປະມານຫ້າເມັດທີ່ມີບົບຕິດຕາມລຸດ. ໃນປີ 2016, ພວກເຮົາມີຫຼາຍກວ່າ 100 pizzerias (ແລະໃນປັດຈຸບັນຫຼາຍກ່ວາ 600). ແຕ່ລະເມັດເຮັດໃຫ້ການຮ້ອງຂໍກັບ backend ທຸກໆ 10 ວິນາທີແລະຂູດຂໍ້ມູນຈາກຕາຕະລາງຄໍາສັ່ງ (ການເຊື່ອມຕໍ່ກັບລູກຄ້າແລະທີ່ຢູ່), ອົງປະກອບຄໍາສັ່ງ (ການເຊື່ອມຕໍ່ກັບຜະລິດຕະພັນແລະການຊີ້ບອກຂອງປະລິມານ), ຕາຕະລາງບັນຊີແຮງຈູງໃຈ (the ເວລາຂອງການກົດແມ່ນຕິດຕາມຢູ່ໃນມັນ). ເມື່ອຜູ້ຜະລິດ pizza ຄລິກໃສ່ຜະລິດຕະພັນໃນຕົວຕິດຕາມ, ລາຍການໃນຕາຕະລາງທັງຫມົດເຫຼົ່ານີ້ຈະຖືກປັບປຸງ. ຕາຕະລາງຄໍາສັ່ງແມ່ນທົ່ວໄປ, ມັນຍັງປະກອບດ້ວຍການໃສ່ໃນເວລາທີ່ຍອມຮັບຄໍາສັ່ງ, ການປັບປຸງຈາກພາກສ່ວນອື່ນໆຂອງລະບົບແລະການອ່ານຈໍານວນຫລາຍ, ສໍາລັບການຍົກຕົວຢ່າງ, ໃນໂທລະພາບທີ່ hangs ໃນ pizzeria ແລະສະແດງຄໍາສັ່ງສໍາເລັດຮູບກັບລູກຄ້າ.

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

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

ແມ່ນ. ສະຖາປັດຕະຍະກຳເດີມແມ່ນ:

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

ກຳລັງຖອນຕົວຕິດຕາມ

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

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

ໂຄງ​ການ​ສໍາ​ລັບ​ການ​ປ່ຽນ​ແປງ​ສະ​ຖາ​ນະ​ການ​ຄໍາ​ສັ່ງ​ເບິ່ງ​ຄື​ນີ້​:

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

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

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

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

ສັ່ງ​ຊື້​ສິນ​ຄ້າ​ຂັ້ນ​ຕອນ​ທີ​
ເສັ້ນທາງຄໍາສັ່ງເລີ່ມຕົ້ນທີ່ຫນຶ່ງໃນການບໍລິການແຫຼ່ງຄໍາສັ່ງ. ນີ້ແມ່ນ Cashier ຂອງຮ້ານອາຫານ:

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

ຖ້າໃຜຜູ້ຫນຶ່ງຕ້ອງການຄໍາສັ່ງຈາກຄໍາສັ່ງຂອງຕາຕະລາງ monolithic, ຫຼັງຈາກນັ້ນທ່ານສາມາດອ່ານມັນຈາກບ່ອນນັ້ນເຊັ່ນກັນ. ຕົວຢ່າງ, ການໂຕ້ຕອບຄໍາສັ່ງໃນ Shift Manager ຕ້ອງການນີ້:

ການບໍລິການອື່ນໆທັງຫມົດຍັງສາມາດຈອງເພື່ອສັ່ງເຫດການຈາກຕົວຕິດຕາມເພື່ອໃຊ້ພວກມັນສໍາລັບຕົວເອງ.

ຖ້າຫຼັງຈາກນັ້ນໄລຍະຫນຶ່ງຄໍາສັ່ງຖືກປະຕິບັດ, ຫຼັງຈາກນັ້ນສະຖານະພາບຂອງມັນທໍາອິດປ່ຽນແປງໃນຖານຂໍ້ມູນຂອງມັນ (ຖານຂໍ້ມູນ Tracker), ແລະຫຼັງຈາກນັ້ນເຫດການ "OrderIn Progress" ຈະຖືກສ້າງຂື້ນທັນທີ. ມັນຍັງເຂົ້າໄປໃນ RMQ, ຈາກບ່ອນທີ່ມັນຖືກ synchronized ໃນຖານຂໍ້ມູນ monolithic ແລະສົ່ງໃຫ້ການບໍລິການອື່ນໆ. ອາດຈະມີບັນຫາຕ່າງໆຕາມທາງ, ລາຍລະອຽດເພີ່ມເຕີມກ່ຽວກັບພວກມັນສາມາດພົບໄດ້ໃນບົດລາຍງານຂອງ Zhenya Peshkov ກ່ຽວກັບລາຍລະອຽດການປະຕິບັດຂອງຄວາມສອດຄ່ອງໃນທີ່ສຸດໃນຕົວຕິດຕາມ.

ສະຖາປັດຕະຍະກໍາສຸດທ້າຍຫຼັງຈາກການປ່ຽນແປງໃນ Auth ແລະ Tracker

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

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

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

ພຽງແຕ່ຜູ້ໃຊ້ລົງທະບຽນສາມາດເຂົ້າຮ່ວມໃນການສໍາຫຼວດ. ເຂົ້າ​ສູ່​ລະ​ບົບກະລຸນາ.

ທ່ານຢາກຮູ້ກ່ຽວກັບພາກສ່ວນໃດຂອງ Dodo IS ໃນບົດຄວາມຕໍ່ໄປ?

• 24,1%ຕົ້ນ monolith ໃນ Dodo IS (2011-2015)14

• 24,1%ບັນຫາທຳອິດ ແລະ ວິທີແກ້ໄຂ (2015-2016)14

• 20,7%ເສັ້ນທາງຂ້າງລູກຄ້າ: facade over base (2016-2017)12

• 36,2%ປະຫວັດຂອງການບໍລິການຈຸນລະພາກທີ່ແທ້ຈິງ (2018-2019)21

• 44,8%ສໍາເລັດການ sawing ຂອງ monolith ແລະສະຖຽນລະພາບຂອງສະຖາປັດຕະ26

• 29,3%ກ່ຽວ​ກັບ​ແຜນ​ການ​ໃນ​ການ​ພັດ​ທະ​ນາ​ຂອງ​ລະ​ບົບ 17

• 19,0%ຂ້ອຍບໍ່ຢາກຮູ້ຫຍັງກ່ຽວກັບ Dodo IS11

58 ຜູ້ໃຊ້ລົງຄະແນນສຽງ. 6 ຜູ້ໃຊ້ງົດ.

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