JSON-RPC? ພັກຜ່ອນທີ່ຫຍຸ້ງຍາກ

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

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

ເພື່ອໃຫ້ມີຄວາມຊັດເຈນກ່ຽວກັບ RPC ແມ່ນຫຍັງ, ຂ້າພະເຈົ້າສະເຫນີໃຫ້ພິຈາລະນາມາດຕະຖານ JSON-RPC 2.0. ກັບ REST ບໍ່ມີຄວາມຊັດເຈນ. ແລະມັນບໍ່ຄວນຈະເປັນ. ທຸກ​ສິ່ງ​ທຸກ​ຢ່າງ​ທີ່​ທ່ານ​ຈໍາ​ເປັນ​ຕ້ອງ​ຮູ້​ກ່ຽວ​ກັບ REST - ມັນ​ເປັນ​ການ​ແຍກ​ອອກ​ຈາກ​ HTTP.

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

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

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

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

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

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

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

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

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

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

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

ຕອນນີ້ໃຫ້ນັບຈໍານວນຄໍາຮ້ອງຂໍ REST ແລະ RPC "ໃຫ້ເກີດ" ໃນໂຄງສ້າງພື້ນຖານທີ່ກໍາລັງພິຈາລະນາ?

ການຮ້ອງຂໍ
ກ່ອງຈົດ ໝາຍ
ກັບ backend
ກັບ DBMS
ກັບ​ຖານ​ຄວາມ​ຈໍາ​ອ່ອນ (Redis​)
TOTAL

REST
1 / 32 *
1
1
0
3 / 35

CPR
32
32
1
31
96

[*] ໃນກໍລະນີທີ່ດີທີ່ສຸດ (ຖ້າແຄດທ້ອງຖິ່ນຖືກນໍາໃຊ້) 1 ຄໍາຮ້ອງຂໍ (ຫນຶ່ງ!), ໃນກໍລະນີທີ່ຮ້າຍແຮງທີ່ສຸດ 32 ຄໍາຮ້ອງຂໍທີ່ເຂົ້າມາ.

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

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

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

ດັ່ງນັ້ນເປັນຫຍັງ myth ວ່າການຮ້ອງຂໍ batch (RPC) ແມ່ນໄວຂຶ້ນຢ່າງຕໍ່ເນື່ອງ? ສ່ວນບຸກຄົນ, ມັນເບິ່ງຄືວ່າຂ້ອຍວ່າໂຄງການສ່ວນໃຫຍ່ບໍ່ສາມາດບັນລຸລະດັບການພັດທະນາທີ່ REST ສາມາດສະແດງຄວາມເຂັ້ມແຂງຂອງມັນ. ຍິ່ງໄປກວ່ານັ້ນ, ໃນໂຄງການຂະຫນາດນ້ອຍ, ລາວເຕັມໃຈທີ່ຈະສະແດງຈຸດອ່ອນຂອງລາວ.

ທາງເລືອກຂອງ REST ຫຼື RPC ບໍ່ແມ່ນການເລືອກ volitional ຂອງບຸກຄົນໃນໂຄງການ. ທາງເລືອກນີ້ຕ້ອງຕອບສະຫນອງຄວາມຕ້ອງການຂອງໂຄງການ. ຖ້າໂຄງການສາມາດບີບທຸກສິ່ງທີ່ມັນສາມາດອອກຈາກ REST, ແລະມັນກໍ່ຕ້ອງການມັນ, ຫຼັງຈາກນັ້ນ REST ຈະເປັນທາງເລືອກທີ່ດີເລີດ.

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

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

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

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

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

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

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

ໂອເຄ, ໃຫ້ຈິນຕະນາການວ່າພວກເຮົາໄດ້ເມື່ອຍຕົວເອງ (!) ແລະຄິດໂດຍຜ່ານທາງເລືອກໃນເວລາທີ່ການຮ້ອງຂໍສາມາດສໍາເລັດບາງສ່ວນຢ່າງສໍາເລັດຜົນ. ແລະພວກເຮົາຈະພະຍາຍາມສໍາເລັດສ່ວນທີ່ເຫຼືອອີກເທື່ອຫນຶ່ງຫຼັງຈາກໄລຍະຫ່າງເວລາໃດຫນຶ່ງ (ອັນໃດ? ດ້ານຫນ້າຕັດສິນໃຈບໍ?). ແຕ່ຫວຍຍັງຄືເກົ່າ. ການຮ້ອງຂໍໃຫ້ສົ່ງ SMS ມີໂອກາດ 50/50 ທີ່ຈະລົ້ມເຫລວອີກເທື່ອຫນຶ່ງ.

ຕົກລົງ, ຈາກຝ່າຍລູກຄ້າ, ການບໍລິການເບິ່ງຄືວ່າບໍ່ມີຄວາມຫນ້າເຊື່ອຖືຕາມທີ່ພວກເຮົາຕ້ອງການ ... ແມ່ນຫຍັງກ່ຽວກັບ REST?

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

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

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

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

ເກນເຂົ້າ REST ແມ່ນຕໍ່າກວ່າ

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

ດັ່ງນັ້ນເປັນຫຍັງຫຼາຍຄົນຄິດວ່າ REST ຈະງ່າຍດາຍກວ່າ? ຄວາມຄິດເຫັນສ່ວນຕົວຂອງຂ້ອຍແມ່ນວ່າຄວາມງ່າຍດາຍທີ່ປາກົດຂື້ນນີ້ແມ່ນມາຈາກ REST ສະແດງອອກດ້ວຍຕົນເອງ. ເຫຼົ່ານັ້ນ. REST ບໍ່ແມ່ນໂປຣໂຕຄໍ ແຕ່ເປັນແນວຄວາມຄິດ... REST ບໍ່ມີມາດຕະຖານ, ມີບາງຂໍ້ແນະນຳ... REST ບໍ່ສັບສົນກວ່າ HTTP. ເສລີພາບທີ່ປາກົດຂື້ນແລະຄວາມບໍ່ສະຫງົບດຶງດູດ "ນັກສິລະປິນຟຣີ".

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

ແຕ່ກ່ຽວກັບ RPC - ທ່ານສາມາດເຮັດໄດ້. ມັນພຽງພໍທີ່ຈະເອົາສະເພາະຂອງມັນ. ດັ່ງນັ້ນທ່ານຕ້ອງການ JSON-RPC ໂງ່? ຫຼືວ່າ REST ຍັງຫຍຸ້ງຍາກຢູ່ບໍ? ເຈົ້າ​ຕັດ​ສິນ​ໃຈ.

ຂ້າພະເຈົ້າຫວັງຢ່າງຈິງໃຈວ່າຂ້າພະເຈົ້າບໍ່ໄດ້ເສຍເວລາຂອງທ່ານ.

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