ການປະສົມປະສານແບບ BPM

ສະບາຍດີ ຮາບ!

ບໍລິສັດຂອງພວກເຮົາມີຄວາມຊ່ຽວຊານໃນການພັດທະນາຂອງ ERP-class software solutions, ສ່ວນແບ່ງຂອງຊ້າງແມ່ນ occupied ໂດຍລະບົບທຸລະກໍາທີ່ມີຈໍານວນ huge ຂອງເຫດຜົນທາງທຸລະກິດແລະເອກະສານ flow a la EDMS. ຮຸ່ນປັດຈຸບັນຂອງຜະລິດຕະພັນຂອງພວກເຮົາແມ່ນອີງໃສ່ເຕັກໂນໂລຢີ JavaEE, ແຕ່ພວກເຮົາຍັງພະຍາຍາມທົດລອງກັບ microservices ຢ່າງຈິງຈັງ. ຫນຶ່ງໃນບັນຫາທີ່ສຸດຂອງການແກ້ໄຂດັ່ງກ່າວແມ່ນການລວມເອົາລະບົບຍ່ອຍຕ່າງໆທີ່ເປັນຂອງໂດເມນທີ່ຢູ່ໃກ້ຄຽງ. ບັນຫາການເຊື່ອມໂຍງສະເຫມີເຮັດໃຫ້ພວກເຮົາເຈັບຫົວຢ່າງໃຫຍ່ຫຼວງ, ໂດຍບໍ່ຄໍານຶງເຖິງຮູບແບບສະຖາປັດຕະຍະກໍາ, stacks ເຕັກໂນໂລຢີແລະກອບທີ່ພວກເຮົາໃຊ້, ແຕ່ບໍ່ດົນມານີ້ມີຄວາມຄືບຫນ້າໃນການແກ້ໄຂບັນຫາດັ່ງກ່າວ.

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

ປະຕິເສດຄວາມຮັບຜິດຊອບ

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

BPM ເຮັດຫຍັງກັບມັນ?

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

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

• ຂຶ້ນກັບກົດໝາຍຂອງ Conway;
• ເປັນຜົນມາຈາກການ reusing ລະບົບຍ່ອຍທີ່ພັດທະນາກ່ອນຫນ້ານີ້ສໍາລັບຜະລິດຕະພັນອື່ນໆ;
• ຕາມການຕັດສິນໃຈຂອງສະຖາປະນິກ, ໂດຍອີງໃສ່ຄວາມຕ້ອງການທີ່ບໍ່ມີປະໂຫຍດ.

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

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

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

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

ນີ້ແມ່ນສິ່ງທີ່ຂະບວນການເບິ່ງຄືວ່າໃນຕອນເລີ່ມຕົ້ນຂອງໂຄງການ

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

ນີ້ແມ່ນສິ່ງທີ່ຂະບວນການເບິ່ງຄືວ່າຫຼັງຈາກຫຼາຍໆຄັ້ງຂອງການຊີ້ແຈງຄວາມຕ້ອງການ.

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

ພາກສ່ວນນ້ອຍໆຂອງຂະບວນການທຸລະກິດທີ່ສັບສົນ

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

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

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

ຂໍ້ເສຍຂອງການໂທ synchronous ເປັນຮູບແບບການເຊື່ອມໂຍງ

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

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

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

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

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

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

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

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

"Saga" ເປັນການແກ້ໄຂບັນຫາການເຮັດທຸລະກໍາ

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

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

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

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

ແຕ່ການແກ້ໄຂນີ້ຍັງມີ "ລາຄາ" ຂອງຕົນເອງ:

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

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

encapsulating ເຫດຜົນທາງທຸລະກິດໃນ microservices

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

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

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

ການສຶກສາລາຍລະອຽດເພີ່ມເຕີມໄດ້ເປີດເຜີຍຂໍ້ເສຍທີ່ສໍາຄັນຂອງວິທີການນີ້:

• ການບໍລິການແພລະຕະຟອມທີ່ປະຕິບັດເຫດຜົນທາງທຸລະກິດຂອງຫຼາຍໆໂດເມນໃນເວລາດຽວກັນມີຄວາມສ່ຽງທີ່ຍິ່ງໃຫຍ່ເປັນຈຸດດຽວຂອງຄວາມລົ້ມເຫລວ. ການປ່ຽນແປງເລື້ອຍໆກ່ຽວກັບເຫດຜົນທາງທຸລະກິດເພີ່ມຄວາມສ່ຽງຂອງຄວາມຜິດພາດທີ່ນໍາໄປສູ່ຄວາມລົ້ມເຫຼວຂອງລະບົບ;
• ບັນຫາການປະຕິບັດ: ເຫດຜົນທາງທຸລະກິດເຮັດວຽກກັບຂໍ້ມູນຂອງມັນໂດຍຜ່ານການໂຕ້ຕອບແຄບແລະຊ້າ:
  • ຂໍ້​ມູນ​ຈະ​ໄດ້​ຮັບ​ການ marshaled ອີກ​ເທື່ອ​ຫນຶ່ງ​ແລະ pumped ໂດຍ​ຜ່ານ stack ເຄືອ​ຂ່າຍ​;
  • ການບໍລິການໂດເມນມັກຈະສະຫນອງຂໍ້ມູນຫຼາຍກວ່າທີ່ຕ້ອງການສໍາລັບເຫດຜົນທາງທຸລະກິດທີ່ຈະດໍາເນີນການເນື່ອງຈາກຄວາມສາມາດທີ່ບໍ່ພຽງພໍສໍາລັບການກໍານົດການຮ້ອງຂໍໃນລະດັບ API ພາຍນອກຂອງການບໍລິການ;
  • ບາງຊິ້ນສ່ວນທີ່ເປັນເອກະລາດຂອງເຫດຜົນທາງທຸລະກິດສາມາດຮ້ອງຂໍຄືນໃຫມ່ອີກຄັ້ງສໍາລັບການປຸງແຕ່ງຂໍ້ມູນ (ບັນຫານີ້ສາມາດຫຼຸດຜ່ອນໄດ້ໂດຍການເພີ່ມອົງປະກອບຂອງເຊດຊັນທີ່ຂໍ້ມູນ cache, ແຕ່ນີ້ເຮັດໃຫ້ສະຖາປັດຕະຍະກໍາສັບສົນຫຼາຍແລະສ້າງບັນຫາຂອງຂໍ້ມູນທີ່ກ່ຽວຂ້ອງແລະ cache invalidation);
• ບັນຫາທຸລະກໍາ:
  • ຂະບວນການທຸລະກິດທີ່ມີສະຖານະຄົງທີ່, ເຊິ່ງຖືກເກັບໄວ້ໂດຍການບໍລິການເວທີ, ບໍ່ສອດຄ່ອງກັບຂໍ້ມູນໂດເມນ, ແລະບໍ່ມີວິທີງ່າຍໆທີ່ຈະແກ້ໄຂບັນຫານີ້;
  • ການຂັດຂວາງຂໍ້ມູນໂດເມນຢູ່ນອກການເຮັດທຸລະກໍາ: ຖ້າເຫດຜົນຂອງທຸລະກິດໂດເມນຕ້ອງປ່ຽນແປງຫຼັງຈາກການກວດສອບຄວາມຖືກຕ້ອງຂອງຂໍ້ມູນໃນປະຈຸບັນ, ມັນຈໍາເປັນຕ້ອງຍົກເວັ້ນຄວາມເປັນໄປໄດ້ຂອງການປ່ຽນແປງການແຂ່ງຂັນໃນຂໍ້ມູນທີ່ຖືກປຸງແຕ່ງ. ການຂັດຂວາງຂໍ້ມູນພາຍນອກສາມາດຊ່ວຍແກ້ໄຂບັນຫາໄດ້, ແຕ່ການແກ້ໄຂດັ່ງກ່າວເຮັດໃຫ້ເກີດຄວາມສ່ຽງເພີ່ມເຕີມແລະຫຼຸດຜ່ອນຄວາມຫນ້າເຊື່ອຖືໂດຍລວມຂອງລະບົບ;
• ຄວາມຫຍຸ້ງຍາກເພີ່ມເຕີມໃນເວລາທີ່ການປັບປຸງ: ໃນບາງກໍລະນີ, ການບໍລິການຄົງທີ່ແລະເຫດຜົນທາງທຸລະກິດຕ້ອງໄດ້ຮັບການປັບປຸງ synchronously ຫຼືໃນລໍາດັບທີ່ເຄັ່ງຄັດ.

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

• ມາດຕະຖານ API ແມ່ນຈໍາເປັນສໍາລັບການພົວພັນກັບເຫດຜົນທາງທຸລະກິດ (ໂດຍສະເພາະ, ເພື່ອສະຫນອງກິດຈະກໍາຂອງຜູ້ໃຊ້ເປັນສ່ວນຫນຶ່ງຂອງຂະບວນການທຸລະກິດ) ແລະບໍລິການເວທີ API; ຮຽກຮ້ອງໃຫ້ມີຄວາມສົນໃຈຢ່າງລະມັດລະວັງຕໍ່ການປ່ຽນແປງ API, ຄວາມເຂົ້າກັນໄດ້ໃນດ້ານຂ້າງແລະດ້ານຫລັງ;
• ມັນເປັນສິ່ງຈໍາເປັນທີ່ຈະເພີ່ມຫ້ອງສະຫມຸດ runtime ເພີ່ມເຕີມເພື່ອຮັບປະກັນການເຮັດວຽກຂອງເຫດຜົນທາງທຸລະກິດເປັນສ່ວນຫນຶ່ງຂອງແຕ່ລະ microservice ດັ່ງກ່າວ, ແລະນີ້ເຮັດໃຫ້ຄວາມຕ້ອງການໃຫມ່ສໍາລັບຫ້ອງສະຫມຸດດັ່ງກ່າວ: ຄວາມສະຫວ່າງແລະຕໍາ່ສຸດທີ່ຂອງ transitive dependencies;
• ນັກພັດທະນາ logic ທຸລະກິດຈໍາເປັນຕ້ອງໄດ້ຕິດຕາມກວດກາສະບັບຂອງຫ້ອງສະຫມຸດ: ຖ້າ microservice ຍັງບໍ່ທັນໄດ້ສໍາເລັດເປັນເວລາດົນນານ, ມັນອາດຈະປະກອບດ້ວຍສະບັບພາສາລ້າສະໄຫມຂອງຫ້ອງສະຫມຸດ. ນີ້ສາມາດເປັນອຸປະສັກທີ່ບໍ່ຄາດຄິດໃນການເພີ່ມຄຸນສົມບັດໃຫມ່ ແລະອາດຈະຮຽກຮ້ອງໃຫ້ມີການເຄື່ອນຍ້າຍເຫດຜົນທາງທຸລະກິດເກົ່າຂອງບໍລິການດັ່ງກ່າວໄປຫາຫ້ອງສະໝຸດສະບັບໃໝ່ ຖ້າມີການປ່ຽນແປງທີ່ບໍ່ເຂົ້າກັນລະຫວ່າງເວີຊັນຕ່າງໆ.

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

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

ການເຊື່ອມໂຍງຂະບວນການທຸລະກິດໂດຍຜ່ານສາຍຕາຂອງຜູ້ພັດທະນາແອັບພລິເຄຊັນ

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

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

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

ກົດລະບຽບຂອງເກມ:

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

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

ຂະບວນການທຸລະກິດຂອງຜູ້ນທໍາອິດ (aka ຜູ້ລິເລີ່ມຂອງເກມ) ຈະເຮັດວຽກຢູ່ໃນ app1 app:

class InitialPlayer

import ru.krista.bpm.ProcessInstance
import ru.krista.bpm.runtime.ProcessImpl
import ru.krista.bpm.runtime.constraint.UniqueConstraints
import ru.krista.bpm.runtime.dsl.processModel
import ru.krista.bpm.runtime.dsl.taskOperation
import ru.krista.bpm.runtime.instance.MessageSendInstance

data class PlayerInfo(val name: String, val domain: String, val id: String)

class PlayersList : ArrayList<PlayerInfo>()

// Это класс экземпляра процесса: инкапсулирует его внутреннее состояние
class InitialPlayer : ProcessImpl<InitialPlayer>(initialPlayerModel) {
    var playerName: String by persistent("Player1")
    var energy: Int by persistent(30)
    var players: PlayersList by persistent(PlayersList())
    var shotCounter: Int = 0
}

// Это декларация модели процесса: создается один раз, используется всеми
// экземплярами процесса соответствующего класса
val initialPlayerModel = processModel<InitialPlayer>(name = "InitialPlayer",
                                                     version = 1) {

    // По правилам, первый игрок является инициатором игры и должен быть единственным
    uniqueConstraint = UniqueConstraints.singleton

    // Объявляем активности, из которых состоит бизнес-процесс
    val sendNewGameSignal = signal<String>("NewGame")
    val sendStopGameSignal = signal<String>("StopGame")
    val startTask = humanTask("Start") {
        taskOperation {
            processCondition { players.size > 0 }
            confirmation { "Подключилось ${players.size} игроков. Начинаем?" }
        }
    }
    val stopTask = humanTask("Stop") {
        taskOperation {}
    }
    val waitPlayerJoin = signalWait<String>("PlayerJoin") { signal ->
        players.add(PlayerInfo(
                signal.data!!,
                signal.sender.domain,
                signal.sender.processInstanceId))
        println("... join player ${signal.data} ...")
    }
    val waitPlayerOut = signalWait<String>("PlayerOut") { signal ->
        players.remove(PlayerInfo(
                signal.data!!,
                signal.sender.domain,
                signal.sender.processInstanceId))
        println("... player ${signal.data} is out ...")
    }
    val sendPlayerOut = signal<String>("PlayerOut") {
        signalData = { playerName }
    }
    val sendHandshake = messageSend<String>("Handshake") {
        messageData = { playerName }
        activation = {
            receiverDomain = process.players.last().domain
            receiverProcessInstanceId = process.players.last().id
        }
    }
    val throwStartBall = messageSend<Int>("Ball") {
        messageData = { 1 }
        activation = { selectNextPlayer() }
    }
    val throwBall = messageSend<Int>("Ball") {
        messageData = { shotCounter + 1 }
        activation = { selectNextPlayer() }
        onEntry { energy -= 1 }
    }
    val waitBall = messageWaitData<Int>("Ball") {
        shotCounter = it
    }

    // Теперь конструируем граф процесса из объявленных активностей
    startFrom(sendNewGameSignal)
            .fork("mainFork") {
                next(startTask)
                next(waitPlayerJoin).next(sendHandshake).next(waitPlayerJoin)
                next(waitPlayerOut)
                        .branch("checkPlayers") {
                            ifTrue { players.isEmpty() }
                                    .next(sendStopGameSignal)
                                    .terminate()
                            ifElse().next(waitPlayerOut)
                        }
            }
    startTask.fork("afterStart") {
        next(throwStartBall)
                .branch("mainLoop") {
                    ifTrue { energy < 5 }.next(sendPlayerOut).next(waitBall)
                    ifElse().next(waitBall).next(throwBall).loop()
                }
        next(stopTask).next(sendStopGameSignal)
    }

    // Навешаем на активности дополнительные обработчики для логирования
    sendNewGameSignal.onExit { println("Let's play!") }
    sendStopGameSignal.onExit { println("Stop!") }
    sendPlayerOut.onExit { println("$playerName: I'm out!") }
}

private fun MessageSendInstance<InitialPlayer, Int>.selectNextPlayer() {
    val player = process.players.random()
    receiverDomain = player.domain
    receiverProcessInstanceId = player.id
    println("Step ${process.shotCounter + 1}: " +
            "${process.playerName} >>> ${player.name}")
}

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

app2 ຈະປະກອບມີຂະບວນການທຸລະກິດຂອງຜູ້ນອື່ນໆ:

ຫ້ອງຮຽນ RandomPlayer

import ru.krista.bpm.ProcessInstance
import ru.krista.bpm.runtime.ProcessImpl
import ru.krista.bpm.runtime.dsl.processModel
import ru.krista.bpm.runtime.instance.MessageSendInstance

data class PlayerInfo(val name: String, val domain: String, val id: String)

class PlayersList: ArrayList<PlayerInfo>()

class RandomPlayer : ProcessImpl<RandomPlayer>(randomPlayerModel) {

    var playerName: String by input(persistent = true, 
                                    defaultValue = "RandomPlayer")
    var energy: Int by input(persistent = true, defaultValue = 30)
    var players: PlayersList by persistent(PlayersList())
    var allPlayersOut: Boolean by persistent(false)
    var shotCounter: Int = 0

    val selfPlayer: PlayerInfo
        get() = PlayerInfo(playerName, env.eventDispatcher.domainName, id)
}

val randomPlayerModel = processModel<RandomPlayer>(name = "RandomPlayer", 
                                                   version = 1) {

    val waitNewGameSignal = signalWait<String>("NewGame")
    val waitStopGameSignal = signalWait<String>("StopGame")
    val sendPlayerJoin = signal<String>("PlayerJoin") {
        signalData = { playerName }
    }
    val sendPlayerOut = signal<String>("PlayerOut") {
        signalData = { playerName }
    }
    val waitPlayerJoin = signalWaitCustom<String>("PlayerJoin") {
        eventCondition = { signal ->
            signal.sender.processInstanceId != process.id 
                && !process.players.any { signal.sender.processInstanceId == it.id}
        }
        handler = { signal ->
            players.add(PlayerInfo(
                    signal.data!!,
                    signal.sender.domain,
                    signal.sender.processInstanceId))
        }
    }
    val waitPlayerOut = signalWait<String>("PlayerOut") { signal ->
        players.remove(PlayerInfo(
                signal.data!!,
                signal.sender.domain,
                signal.sender.processInstanceId))
        allPlayersOut = players.isEmpty()
    }
    val sendHandshake = messageSend<String>("Handshake") {
        messageData = { playerName }
        activation = {
            receiverDomain = process.players.last().domain
            receiverProcessInstanceId = process.players.last().id
        }
    }
    val receiveHandshake = messageWait<String>("Handshake") { message ->
        if (!players.any { message.sender.processInstanceId == it.id}) {
            players.add(PlayerInfo(
                    message.data!!, 
                    message.sender.domain, 
                    message.sender.processInstanceId))
        }
    }
    val throwBall = messageSend<Int>("Ball") {
        messageData = { shotCounter + 1 }
        activation = { selectNextPlayer() }
        onEntry { energy -= 1 }
    }
    val waitBall = messageWaitData<Int>("Ball") {
        shotCounter = it
    }

    startFrom(waitNewGameSignal)
            .fork("mainFork") {
                next(sendPlayerJoin)
                        .branch("mainLoop") {
                            ifTrue { energy < 5 || allPlayersOut }
                                    .next(sendPlayerOut)
                                    .next(waitBall)
                            ifElse()
                                    .next(waitBall)
                                    .next(throwBall)
                                    .loop()
                        }
                next(waitPlayerJoin).next(sendHandshake).next(waitPlayerJoin)
                next(waitPlayerOut).next(waitPlayerOut)
                next(receiveHandshake).next(receiveHandshake)
                next(waitStopGameSignal).terminate()
            }

    sendPlayerJoin.onExit { println("$playerName: I'm here!") }
    sendPlayerOut.onExit { println("$playerName: I'm out!") }
}

private fun MessageSendInstance<RandomPlayer, Int>.selectNextPlayer() {
    val player = if (process.players.isNotEmpty()) 
        process.players.random() 
    else 
        process.selfPlayer
    receiverDomain = player.domain
    receiverProcessInstanceId = player.id
    println("Step ${process.shotCounter + 1}: " +
            "${process.playerName} >>> ${player.name}")
}

ແຜນວາດ:

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

ຫ້ອງຮຽນ RoundRobinPlayer

import ru.krista.bpm.ProcessInstance
import ru.krista.bpm.runtime.ProcessImpl
import ru.krista.bpm.runtime.dsl.processModel
import ru.krista.bpm.runtime.instance.MessageSendInstance

data class PlayerInfo(val name: String, val domain: String, val id: String)

class PlayersList: ArrayList<PlayerInfo>()

class RoundRobinPlayer : ProcessImpl<RoundRobinPlayer>(roundRobinPlayerModel) {

    var playerName: String by input(persistent = true, 
                                    defaultValue = "RoundRobinPlayer")
    var energy: Int by input(persistent = true, defaultValue = 30)
    var players: PlayersList by persistent(PlayersList())
    var nextPlayerIndex: Int by persistent(-1)
    var allPlayersOut: Boolean by persistent(false)
    var shotCounter: Int = 0

    val selfPlayer: PlayerInfo
        get() = PlayerInfo(playerName, env.eventDispatcher.domainName, id)
}

val roundRobinPlayerModel = processModel<RoundRobinPlayer>(
        name = "RoundRobinPlayer", 
        version = 1) {

    val waitNewGameSignal = signalWait<String>("NewGame")
    val waitStopGameSignal = signalWait<String>("StopGame")
    val sendPlayerJoin = signal<String>("PlayerJoin") {
        signalData = { playerName }
    }
    val sendPlayerOut = signal<String>("PlayerOut") {
        signalData = { playerName }
    }
    val waitPlayerJoin = signalWaitCustom<String>("PlayerJoin") {
        eventCondition = { signal ->
            signal.sender.processInstanceId != process.id 
                && !process.players.any { signal.sender.processInstanceId == it.id}
        }
        handler = { signal ->
            players.add(PlayerInfo(
                    signal.data!!, 
                    signal.sender.domain, 
                    signal.sender.processInstanceId))
        }
    }
    val waitPlayerOut = signalWait<String>("PlayerOut") { signal ->
        players.remove(PlayerInfo(
                signal.data!!, 
                signal.sender.domain, 
                signal.sender.processInstanceId))
        allPlayersOut = players.isEmpty()
    }
    val sendHandshake = messageSend<String>("Handshake") {
        messageData = { playerName }
        activation = {
            receiverDomain = process.players.last().domain
            receiverProcessInstanceId = process.players.last().id
        }
    }
    val receiveHandshake = messageWait<String>("Handshake") { message ->
        if (!players.any { message.sender.processInstanceId == it.id}) {
            players.add(PlayerInfo(
                    message.data!!, 
                    message.sender.domain, 
                    message.sender.processInstanceId))
        }
    }
    val throwBall = messageSend<Int>("Ball") {
        messageData = { shotCounter + 1 }
        activation = { selectNextPlayer() }
        onEntry { energy -= 1 }
    }
    val waitBall = messageWaitData<Int>("Ball") {
        shotCounter = it
    }

    startFrom(waitNewGameSignal)
            .fork("mainFork") {
                next(sendPlayerJoin)
                        .branch("mainLoop") {
                            ifTrue { energy < 5 || allPlayersOut }
                                    .next(sendPlayerOut)
                                    .next(waitBall)
                            ifElse()
                                    .next(waitBall)
                                    .next(throwBall)
                                    .loop()
                        }
                next(waitPlayerJoin).next(sendHandshake).next(waitPlayerJoin)
                next(waitPlayerOut).next(waitPlayerOut)
                next(receiveHandshake).next(receiveHandshake)
                next(waitStopGameSignal).terminate()
            }

    sendPlayerJoin.onExit { println("$playerName: I'm here!") }
    sendPlayerOut.onExit { println("$playerName: I'm out!") }
}

private fun MessageSendInstance<RoundRobinPlayer, Int>.selectNextPlayer() {
    var idx = process.nextPlayerIndex + 1
    if (idx >= process.players.size) {
        idx = 0
    }
    process.nextPlayerIndex = idx
    val player = if (process.players.isNotEmpty()) 
        process.players[idx] 
    else 
        process.selfPlayer
    receiverDomain = player.domain
    receiverProcessInstanceId = player.id
    println("Step ${process.shotCounter + 1}: " +
            "${process.playerName} >>> ${player.name}")
}

ຖ້າບໍ່ດັ່ງນັ້ນ, ພຶດຕິກໍາຂອງຜູ້ນບໍ່ແຕກຕ່າງຈາກອັນທີ່ຜ່ານມາ, ດັ່ງນັ້ນແຜນວາດບໍ່ປ່ຽນແປງ.

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

ເກມທົດສອບ()

@Test
public void testGame() throws InterruptedException {
    String pl2 = startProcess(app2, "RandomPlayer", playerParams("Player2", 20));
    String pl3 = startProcess(app2, "RandomPlayer", playerParams("Player3", 40));
    String pl4 = startProcess(app3, "RoundRobinPlayer", playerParams("Player4", 25));
    String pl5 = startProcess(app3, "RoundRobinPlayer", playerParams("Player5", 35));
    String pl1 = startProcess(app1, "InitialPlayer");
    // Теперь нужно немного подождать, пока игроки "познакомятся" друг с другом.
    // Ждать через sleep - плохое решение, зато самое простое. 
    // Не делайте так в серьезных тестах!
    Thread.sleep(1000);
    // Запускаем игру, закрывая пользовательскую активность
    assertTrue(closeTask(app1, pl1, "Start"));
    app1.getWaiting().waitProcessFinished(pl1);
    app2.getWaiting().waitProcessFinished(pl2);
    app2.getWaiting().waitProcessFinished(pl3);
    app3.getWaiting().waitProcessFinished(pl4);
    app3.getWaiting().waitProcessFinished(pl5);
}

private Map<String, Object> playerParams(String name, int energy) {
    Map<String, Object> params = new HashMap<>();
    params.put("playerName", name);
    params.put("energy", energy);
    return params;
}

ໃຫ້ດໍາເນີນການທົດສອບແລະເບິ່ງບັນທຶກ:

console output

Взята блокировка ключа lock://app1/process/InitialPlayer
Let's play!
Снята блокировка ключа lock://app1/process/InitialPlayer
Player2: I'm here!
Player3: I'm here!
Player4: I'm here!
Player5: I'm here!
... join player Player2 ...
... join player Player4 ...
... join player Player3 ...
... join player Player5 ...
Step 1: Player1 >>> Player3
Step 2: Player3 >>> Player5
Step 3: Player5 >>> Player3
Step 4: Player3 >>> Player4
Step 5: Player4 >>> Player3
Step 6: Player3 >>> Player4
Step 7: Player4 >>> Player5
Step 8: Player5 >>> Player2
Step 9: Player2 >>> Player5
Step 10: Player5 >>> Player4
Step 11: Player4 >>> Player2
Step 12: Player2 >>> Player4
Step 13: Player4 >>> Player1
Step 14: Player1 >>> Player4
Step 15: Player4 >>> Player3
Step 16: Player3 >>> Player1
Step 17: Player1 >>> Player2
Step 18: Player2 >>> Player3
Step 19: Player3 >>> Player1
Step 20: Player1 >>> Player5
Step 21: Player5 >>> Player1
Step 22: Player1 >>> Player2
Step 23: Player2 >>> Player4
Step 24: Player4 >>> Player5
Step 25: Player5 >>> Player3
Step 26: Player3 >>> Player4
Step 27: Player4 >>> Player2
Step 28: Player2 >>> Player5
Step 29: Player5 >>> Player2
Step 30: Player2 >>> Player1
Step 31: Player1 >>> Player3
Step 32: Player3 >>> Player4
Step 33: Player4 >>> Player1
Step 34: Player1 >>> Player3
Step 35: Player3 >>> Player4
Step 36: Player4 >>> Player3
Step 37: Player3 >>> Player2
Step 38: Player2 >>> Player5
Step 39: Player5 >>> Player4
Step 40: Player4 >>> Player5
Step 41: Player5 >>> Player1
Step 42: Player1 >>> Player5
Step 43: Player5 >>> Player3
Step 44: Player3 >>> Player5
Step 45: Player5 >>> Player2
Step 46: Player2 >>> Player3
Step 47: Player3 >>> Player2
Step 48: Player2 >>> Player5
Step 49: Player5 >>> Player4
Step 50: Player4 >>> Player2
Step 51: Player2 >>> Player5
Step 52: Player5 >>> Player1
Step 53: Player1 >>> Player5
Step 54: Player5 >>> Player3
Step 55: Player3 >>> Player5
Step 56: Player5 >>> Player2
Step 57: Player2 >>> Player1
Step 58: Player1 >>> Player4
Step 59: Player4 >>> Player1
Step 60: Player1 >>> Player4
Step 61: Player4 >>> Player3
Step 62: Player3 >>> Player2
Step 63: Player2 >>> Player5
Step 64: Player5 >>> Player4
Step 65: Player4 >>> Player5
Step 66: Player5 >>> Player1
Step 67: Player1 >>> Player5
Step 68: Player5 >>> Player3
Step 69: Player3 >>> Player4
Step 70: Player4 >>> Player2
Step 71: Player2 >>> Player5
Step 72: Player5 >>> Player2
Step 73: Player2 >>> Player1
Step 74: Player1 >>> Player4
Step 75: Player4 >>> Player1
Step 76: Player1 >>> Player2
Step 77: Player2 >>> Player5
Step 78: Player5 >>> Player4
Step 79: Player4 >>> Player3
Step 80: Player3 >>> Player1
Step 81: Player1 >>> Player5
Step 82: Player5 >>> Player1
Step 83: Player1 >>> Player4
Step 84: Player4 >>> Player5
Step 85: Player5 >>> Player3
Step 86: Player3 >>> Player5
Step 87: Player5 >>> Player2
Step 88: Player2 >>> Player3
Player2: I'm out!
Step 89: Player3 >>> Player4
... player Player2 is out ...
Step 90: Player4 >>> Player1
Step 91: Player1 >>> Player3
Step 92: Player3 >>> Player1
Step 93: Player1 >>> Player4
Step 94: Player4 >>> Player3
Step 95: Player3 >>> Player5
Step 96: Player5 >>> Player1
Step 97: Player1 >>> Player5
Step 98: Player5 >>> Player3
Step 99: Player3 >>> Player5
Step 100: Player5 >>> Player4
Step 101: Player4 >>> Player5
Player4: I'm out!
... player Player4 is out ...
Step 102: Player5 >>> Player1
Step 103: Player1 >>> Player3
Step 104: Player3 >>> Player1
Step 105: Player1 >>> Player3
Step 106: Player3 >>> Player5
Step 107: Player5 >>> Player3
Step 108: Player3 >>> Player1
Step 109: Player1 >>> Player3
Step 110: Player3 >>> Player5
Step 111: Player5 >>> Player1
Step 112: Player1 >>> Player3
Step 113: Player3 >>> Player5
Step 114: Player5 >>> Player3
Step 115: Player3 >>> Player1
Step 116: Player1 >>> Player3
Step 117: Player3 >>> Player5
Step 118: Player5 >>> Player1
Step 119: Player1 >>> Player3
Step 120: Player3 >>> Player5
Step 121: Player5 >>> Player3
Player5: I'm out!
... player Player5 is out ...
Step 122: Player3 >>> Player5
Step 123: Player5 >>> Player1
Player5: I'm out!
Step 124: Player1 >>> Player3
... player Player5 is out ...
Step 125: Player3 >>> Player1
Step 126: Player1 >>> Player3
Player1: I'm out!
... player Player1 is out ...
Step 127: Player3 >>> Player3
Player3: I'm out!
Step 128: Player3 >>> Player3
... player Player3 is out ...
Player3: I'm out!
Stop!
Step 129: Player3 >>> Player3
Player3: I'm out!

ຈາກທັງຫມົດນີ້, ພວກເຮົາສາມາດສະຫຼຸບທີ່ສໍາຄັນຈໍານວນຫນຶ່ງ:

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

ຕໍ່​ໄປ​, ພວກ​ເຮົາ​ຈະ​ເວົ້າ​ເຖິງ​ຄວາມ​ຫຍຸ້ງ​ຍາກ​ຕ່າງໆ​ຂອງ​ການ​ແກ້​ໄຂ​ຂອງ​ພວກ​ເຮົາ​, ການ​ປະ​ນີ​ປະ​ນ​ອມ​ແລະ​ຈຸດ​ອື່ນໆ​.

ຂໍ້ຄວາມທັງໝົດຢູ່ໃນຄິວດຽວ

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

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

ຮັບປະກັນຄວາມຫນ້າເຊື່ອຖືຂອງລົດເມປະສົມປະສານ

ຄວາມຫນ້າເຊື່ອຖືປະກອບດ້ວຍຫຼາຍຈຸດ:

• ນາຍຫນ້າຂໍ້ຄວາມທີ່ເລືອກແມ່ນອົງປະກອບທີ່ສໍາຄັນຂອງສະຖາປັດຕະຍະກໍາແລະຈຸດດຽວຂອງຄວາມລົ້ມເຫຼວ: ມັນຕ້ອງມີຄວາມທົນທານຕໍ່ຄວາມຜິດພຽງພໍ. ທ່ານຄວນໃຊ້ພຽງແຕ່ການປະຕິບັດການທົດສອບທີ່ໃຊ້ເວລາ, ສະຫນັບສະຫນູນທີ່ດີແລະຊຸມຊົນຂະຫນາດໃຫຍ່;
• ມັນເປັນສິ່ງຈໍາເປັນເພື່ອຮັບປະກັນຄວາມພ້ອມຂອງນາຍຫນ້າຂໍ້ຄວາມ, ເຊິ່ງມັນຕ້ອງຖືກແຍກອອກຈາກຄໍາຮ້ອງສະຫມັກປະສົມປະສານ (ຄວາມພ້ອມສູງຂອງຄໍາຮ້ອງສະຫມັກທີ່ມີເຫດຜົນທາງທຸລະກິດທີ່ນໍາໃຊ້ແມ່ນມີຄວາມຫຍຸ້ງຍາກແລະມີລາຄາແພງກວ່າເພື່ອຮັບປະກັນ);
• ນາຍຫນ້າມີພັນທະໃຫ້ "ຢ່າງຫນ້ອຍຫນຶ່ງຄັ້ງ" ການຮັບປະກັນການຈັດສົ່ງ. ນີ້ແມ່ນຄວາມຕ້ອງການບັງຄັບສໍາລັບການດໍາເນີນງານທີ່ເຊື່ອຖືໄດ້ຂອງລົດເມປະສົມປະສານ. ບໍ່ຈໍາເປັນຕ້ອງມີການຮັບປະກັນລະດັບ "ແນ່ນອນຫນຶ່ງຄັ້ງ": ຂະບວນການທຸລະກິດ, ຕາມກົດລະບຽບ, ບໍ່ມີຄວາມອ່ອນໄຫວຕໍ່ກັບການມາຮອດຂອງຂໍ້ຄວາມຫຼືເຫດການຊ້ໍາຊ້ອນ, ແລະໃນວຽກງານພິເສດທີ່ມີຄວາມສໍາຄັນ, ມັນງ່າຍທີ່ຈະເພີ່ມການກວດສອບເພີ່ມເຕີມໃຫ້ກັບທຸລະກິດ. ເຫດຜົນຫຼາຍກວ່າທີ່ຈະນໍາໃຊ້ຢ່າງຕໍ່ເນື່ອງຂ້ອນຂ້າງ "ແພງ" "ຮັບປະກັນ;
• ການສົ່ງຂໍ້ຄວາມແລະສັນຍານຕ້ອງມີສ່ວນຮ່ວມໃນທຸລະກໍາໂດຍລວມກັບການປ່ຽນແປງໃນສະຖານະຂອງຂະບວນການທຸລະກິດແລະຂໍ້ມູນໂດເມນ. ທາງເລືອກທີ່ຕ້ອງການແມ່ນການໃຊ້ຮູບແບບ ກ່ອງຂາອອກການເຮັດທຸລະກໍາ, ແຕ່ມັນຈະຮຽກຮ້ອງໃຫ້ມີຕາຕະລາງເພີ່ມເຕີມໃນຖານຂໍ້ມູນແລະ repeater. ໃນຄໍາຮ້ອງສະຫມັກ JEE, ນີ້ສາມາດງ່າຍດາຍໂດຍໃຊ້ຜູ້ຈັດການ JTA ທ້ອງຖິ່ນ, ແຕ່ການເຊື່ອມຕໍ່ກັບນາຍຫນ້າທີ່ເລືອກຕ້ອງສາມາດເຮັດວຽກໄດ້. XA;
• handlers ຂອງຂໍ້ຄວາມຂາເຂົ້າແລະເຫດການຍັງຕ້ອງໄດ້ເຮັດວຽກກັບທຸລະກໍາທີ່ມີການປ່ຽນແປງສະຖານະຂອງຂະບວນການທຸລະກິດ: ຖ້າຫາກວ່າທຸລະກໍາດັ່ງກ່າວໄດ້ຖືກມ້ວນຄືນ, ຫຼັງຈາກນັ້ນການໄດ້ຮັບຂໍ້ຄວາມຈະຕ້ອງຖືກຍົກເລີກ;
• ຂໍ້ຄວາມທີ່ບໍ່ສາມາດສົ່ງໄດ້ເນື່ອງຈາກຄວາມຜິດພາດຈະຕ້ອງຖືກເກັບໄວ້ໃນບ່ອນເກັບມ້ຽນແຍກຕ່າງຫາກ D.L.Q. (ແຖວຈົດໝາຍຕາຍ). ສໍາລັບຈຸດປະສົງນີ້, ພວກເຮົາໄດ້ສ້າງ microservice ແພລະຕະຟອມແຍກຕ່າງຫາກທີ່ເກັບຂໍ້ຄວາມດັ່ງກ່າວຢູ່ໃນບ່ອນເກັບມ້ຽນຂອງມັນ, ດັດສະນີພວກມັນໂດຍຄຸນລັກສະນະ (ສໍາລັບການຈັດກຸ່ມໄວແລະການຊອກຫາ), ແລະເປີດເຜີຍ API ສໍາລັບການເບິ່ງ, ສົ່ງຄືນໄປຫາທີ່ຢູ່ປາຍທາງ, ແລະລຶບຂໍ້ຄວາມ. ຜູ້ເບິ່ງແຍງລະບົບສາມາດເຮັດວຽກກັບບໍລິການນີ້ຜ່ານການໂຕ້ຕອບເວັບຂອງພວກເຂົາ;
• ໃນການຕັ້ງຄ່ານາຍຫນ້າ, ທ່ານຈໍາເປັນຕ້ອງປັບຈໍານວນການສົ່ງຄືນແລະການຊັກຊ້າລະຫວ່າງການຈັດສົ່ງເພື່ອຫຼຸດຜ່ອນຄວາມເປັນໄປໄດ້ຂອງຂໍ້ຄວາມທີ່ຈະເຂົ້າໄປໃນ DLQ (ມັນເກືອບເປັນໄປບໍ່ໄດ້ທີ່ຈະຄິດໄລ່ຕົວກໍານົດການທີ່ດີທີ່ສຸດ, ແຕ່ທ່ານສາມາດປະຕິບັດຕົວຈິງແລະປັບໃຫ້ເຂົາເຈົ້າໃນລະຫວ່າງການປະຕິບັດງານ. );
• ຮ້ານຄ້າ DLQ ຕ້ອງໄດ້ຮັບການຕິດຕາມຢ່າງຕໍ່ເນື່ອງ, ແລະລະບົບການຕິດຕາມຕ້ອງແຈ້ງເຕືອນຜູ້ເບິ່ງແຍງລະບົບເພື່ອວ່າເມື່ອຂໍ້ຄວາມທີ່ບໍ່ໄດ້ສົ່ງເກີດຂື້ນ, ພວກເຂົາສາມາດຕອບສະຫນອງໄດ້ໄວເທົ່າທີ່ຈະໄວໄດ້. ນີ້ຈະຫຼຸດຜ່ອນ "ພື້ນທີ່ໄດ້ຮັບຜົນກະທົບ" ຂອງຄວາມລົ້ມເຫລວຫຼືຄວາມຜິດພາດທາງເຫດຜົນທາງທຸລະກິດ;
• ລົດເມປະສົມປະສານຕ້ອງມີຄວາມອ່ອນໄຫວຕໍ່ກັບການບໍ່ມີຄໍາຮ້ອງສະຫມັກຊົ່ວຄາວ: ການສະຫມັກຫົວຂໍ້ໃດຫນຶ່ງຕ້ອງທົນທານ, ແລະຊື່ໂດເມນຂອງແອັບພລິເຄຊັນຕ້ອງເປັນເອກະລັກ, ດັ່ງນັ້ນໃນຂະນະທີ່ແອັບພລິເຄຊັນບໍ່ຢູ່, ຄົນອື່ນຈະບໍ່ພະຍາຍາມປະມວນຜົນຂໍ້ຄວາມຂອງມັນຈາກ. ຄິວ.

ຮັບປະກັນຄວາມປອດໄພກະທູ້ຂອງເຫດຜົນທາງທຸລະກິດ

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

ເຫດຜົນທາງທຸລະກິດຂອງຂະບວນການປະມວນຜົນແຕ່ລະເຫດການພາຍນອກທີ່ມີຜົນກະທົບຕໍ່ຂະບວນການທຸລະກິດນັ້ນເປັນສ່ວນບຸກຄົນ. ເຫດການດັ່ງກ່າວອາດຈະເປັນ:

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

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

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

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

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

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

ໃນຕົວຢ່າງຂອງພວກເຮົາ, ຂະບວນການທຸລະກິດ InitialPlayer ປະກອບດ້ວຍການປະກາດ

uniqueConstraint = UniqueConstraints.singleton

ດັ່ງນັ້ນ, ບັນທຶກມີຂໍ້ຄວາມກ່ຽວກັບການເອົາແລະປ່ອຍຕົວລັອກຂອງກະແຈທີ່ສອດຄ້ອງກັນ. ບໍ່ມີຂໍ້ຄວາມດັ່ງກ່າວສໍາລັບຂະບວນການທຸລະກິດອື່ນໆ: uniqueConstraint ບໍ່ໄດ້ກໍານົດ.

ບັນຫາຂອງຂະບວນການທຸລະກິດກັບສະຖານະຄົງທີ່

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

ອີງຕາມຄວາມເລິກຂອງການປ່ຽນແປງ, ທ່ານສາມາດປະຕິບັດໄດ້ສອງວິທີ:

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

ວິທີທໍາອິດແມ່ນງ່າຍດາຍກວ່າ, ແຕ່ມີຂໍ້ຈໍາກັດແລະຂໍ້ເສຍຂອງມັນ, ຕົວຢ່າງ:

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

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

• ໃນຖານຂໍ້ມູນ, ສະຖານະຄົງທີ່ຂອງຂະບວນການທຸລະກິດຖືກເກັບໄວ້ໃນຮູບແບບທີ່ສາມາດອ່ານໄດ້ແລະປຸງແຕ່ງໄດ້ງ່າຍ: ໃນຮູບແບບ JSON. ນີ້ອະນຸຍາດໃຫ້ການເຄື່ອນຍ້າຍເພື່ອປະຕິບັດທັງພາຍໃນແອັບພລິເຄຊັນແລະພາຍນອກ. ເປັນທາງເລືອກສຸດທ້າຍ, ທ່ານສາມາດແກ້ໄຂມັນດ້ວຍຕົນເອງ (ໂດຍສະເພາະແມ່ນເປັນປະໂຫຍດໃນການພັດທະນາໃນລະຫວ່າງການ debugging);
• ເຫດຜົນທາງທຸລະກິດການເຊື່ອມໂຍງບໍ່ໄດ້ໃຊ້ຊື່ຂອງຂະບວນການທາງທຸລະກິດ, ດັ່ງນັ້ນທຸກເວລາມັນເປັນໄປໄດ້ທີ່ຈະທົດແທນການຈັດຕັ້ງປະຕິບັດຂະບວນການທີ່ເຂົ້າຮ່ວມດ້ວຍຊື່ໃຫມ່ (ຕົວຢ່າງ, "InitialPlayerV2"). ການຜູກມັດເກີດຂຶ້ນໂດຍຜ່ານຂໍ້ຄວາມແລະຊື່ສັນຍານ;
• ຮູບແບບຂະບວນການມີຈໍານວນຮຸ່ນ, ທີ່ພວກເຮົາເພີ່ມຂຶ້ນຖ້າພວກເຮົາເຮັດການປ່ຽນແປງທີ່ບໍ່ເຂົ້າກັນກັບຕົວແບບນີ້, ແລະຕົວເລກນີ້ຖືກບັນທຶກໄວ້ພ້ອມກັບສະຖານະຂອງຕົວຢ່າງຂະບວນການ;
• ສະຖານະຄົງທີ່ຂອງຂະບວນການແມ່ນອ່ານຈາກຖານຂໍ້ມູນກ່ອນເຂົ້າໄປໃນຮູບແບບວັດຖຸທີ່ສະດວກ, ເຊິ່ງຂັ້ນຕອນການເຄື່ອນຍ້າຍສາມາດເຮັດວຽກໄດ້ຖ້າຕົວເລກຮຸ່ນຂອງຕົວແບບມີການປ່ຽນແປງ;
• ຂັ້ນຕອນການເຄື່ອນຍ້າຍແມ່ນຖືກຈັດໃສ່ຢູ່ຂ້າງກັບເຫດຜົນທາງທຸລະກິດແລະເອີ້ນວ່າ "lazy" ສໍາລັບແຕ່ລະຕົວຢ່າງຂອງຂະບວນການທຸລະກິດໃນເວລາທີ່ການຟື້ນຟູຈາກຖານຂໍ້ມູນ;
• ຖ້າທ່ານຕ້ອງການຍ້າຍສະຖານະຂອງຂະບວນການທັງຫມົດຢ່າງໄວວາແລະ synchronously, ວິທີແກ້ໄຂການເຄື່ອນຍ້າຍຖານຂໍ້ມູນຄລາສສິກຫຼາຍແມ່ນຖືກນໍາໃຊ້, ແຕ່ທ່ານຕ້ອງເຮັດວຽກກັບ JSON.

ທ່ານຕ້ອງການກອບອື່ນສໍາລັບຂະບວນການທຸລະກິດບໍ?

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

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

ທ່ານຕ້ອງການກອບອື່ນສໍາລັບຂະບວນການທຸລະກິດບໍ?

• 18,8%ແມ່ນແລ້ວ, ຂ້ອຍຊອກຫາສິ່ງແບບນີ້ມາດົນແລ້ວ

• 12,5%ຂ້ອຍມີຄວາມສົນໃຈໃນການຮຽນຮູ້ເພີ່ມເຕີມກ່ຽວກັບການປະຕິບັດຂອງເຈົ້າ, ມັນອາດຈະເປັນປະໂຫຍດ2

• 6,2%ພວກເຮົາໃຊ້ຫນຶ່ງໃນກອບທີ່ມີຢູ່ແລ້ວ, ແຕ່ກໍາລັງຄິດກ່ຽວກັບການປ່ຽນແທນ 1

• 18,8%ພວກເຮົາໃຊ້ຫນຶ່ງໃນກອບທີ່ມີຢູ່ແລ້ວ, ທຸກສິ່ງທຸກຢ່າງແມ່ນດີ3

• 18,8%ພວກ​ເຮົາ​ຈັດ​ການ​ໂດຍ​ບໍ່​ມີ​ຂອບ​ເຂດ 3

• 25,0%ຂຽນ​ຂອງ​ທ່ານ 4

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

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