ການກໍ່ສ້າງຕັນຂອງຄໍາຮ້ອງສະຫມັກແຈກຢາຍ. ສູນປະມານ

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

ການນໍາສະເຫນີ

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

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

ພື້ນຖານທິດສະດີ

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

ໃຫ້ພວກເຮົາຍົກໃຫ້ເຫັນ 4 ຄວາມຕ້ອງການຕົ້ນຕໍສໍາລັບລະບົບສຸດທ້າຍ:

• Сຮັດກຸມເຫດການ.
  ລະບົບແມ່ນສະເຫມີພ້ອມທີ່ຈະຜ່ານການໄຫຼເຂົ້າຂອງເຫດການແລະປະຕິບັດການປະຕິບັດທີ່ຈໍາເປັນ;
• Мຄວາມ​ສາ​ມາດ​ຂະ​ຫຍາຍ​ຕົວ.
  ທ່ອນໄມ້ສ່ວນບຸກຄົນສາມາດປັບຂະ ໜາດ ໄດ້ທັງແນວຕັ້ງແລະແນວນອນ. ລະບົບທັງຫມົດຕ້ອງມີຄວາມສາມາດຂະຫຍາຍຕົວຕາມແນວນອນທີ່ບໍ່ມີຂອບເຂດ;
• Оຄວາມ​ທົນ​ທານ​ຄວາມ​ຜິດ​ພາດ​.
  ທຸກລະດັບແລະການບໍລິການທັງຫມົດຄວນຈະສາມາດຟື້ນຕົວໂດຍອັດຕະໂນມັດຈາກຄວາມລົ້ມເຫລວ;
• Гຮັບປະກັນເວລາຕອບສະຫນອງ.
  ເວລາແມ່ນມີຄຸນຄ່າແລະຜູ້ໃຊ້ບໍ່ຄວນລໍຖ້າດົນເກີນໄປ.

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

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

ຮັດກຸມເຫດການ

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

ຂະຫຍາຍໄດ້

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

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

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

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

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

ຄວາມ​ທົນ​ທານ​ຄວາມ​ຜິດ​ພາດ​

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

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

ການຕອບສະໜອງ

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

ບົດສະຫຼຸບເບື້ອງຕົ້ນ

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

ສິ້ນສຸດພາກທໍາອິດ.

ການ​ຖ່າຍ​ຮູບ @lucabravo.

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