JSON-RPC? උපක්‍රමශීලී REST ගන්න

සිරස්තලය සෞඛ්‍ය සම්පන්න ප්‍රතිචාරයක් ඇති කළ බව මට විශ්වාසයි - “හොඳයි, එය නැවත ආරම්භ විය...” නමුත් මට විනාඩි 5-10 ක් ඔබේ අවධානය අල්ලා ගැනීමට ඉඩ දෙන්න, මම ඔබේ අපේක්ෂාවන් බලාපොරොත්තු සුන් නොකිරීමට උත්සාහ කරමි.

ලිපියේ ව්යුහය පහත පරිදි වනු ඇත: ඒකාකෘති ප්රකාශයක් ගෙන ඇති අතර මෙම ඒකාකෘතියේ මතුවීමේ "ස්වභාවය" හෙළිදරව් වේ. ඔබගේ ව්‍යාපෘති වල දත්ත හුවමාරු සුසමාදර්ශය තෝරා ගැනීම නව කෝණයකින් බැලීමට මෙය ඔබට ඉඩ සලසනු ඇතැයි මම බලාපොරොත්තු වෙමි.

RPC යනු කුමක්ද යන්න පැහැදිලි කිරීම සඳහා, මම සම්මතය සලකා බැලීමට යෝජනා කරමි JSON-RPC 2.0. REST සමඟ පැහැදිලි බවක් නොමැත. සහ එය නොවිය යුතුය. REST ගැන ඔබ දැනගත යුතු සියල්ල - එය වෙන්කර හඳුනාගත නොහැක HTTP.

කණ්ඩායම් ඉල්ලීම් කිරීමට ඔබට ඉඩ සලසන නිසා RPC ඉල්ලීම් වේගවත් සහ කාර්යක්ෂම වේ.

කාරණය වන්නේ RPC හි ඔබට එක් ඉල්ලීමකදී එකවර ක්රියා පටිපාටි කිහිපයක් ඇමතිය හැකිය. උදාහරණයක් ලෙස, පරිශීලකයෙකු සාදන්න, ඔහුට avatar එකක් එක් කරන්න, එම ඉල්ලීම තුළම, සමහර මාතෘකා සඳහා ඔහුව දායක කරන්න. එක් ඉල්ලීමක් පමණක්, සහ කොපමණ ප්රතිලාභයක්!

ඇත්ත වශයෙන්ම, ඔබට ඇත්තේ එක් පසුපෙළ නෝඩයක් පමණක් නම්, එය කණ්ඩායම් ඉල්ලීමක් සමඟ වේගවත් බව පෙනේ. REST ඉල්ලීම් තුනකට සම්බන්ධතා ස්ථාපනය කිරීමට එක් නෝඩයකින් තුන් ගුණයකින් වැඩි සම්පත් අවශ්‍ය වන බැවිනි.

REST නඩුවේ පළමු ඉල්ලීම පසුකාලීන ඉල්ලීම් සිදු කිරීම සඳහා පරිශීලක හැඳුනුම්පත ආපසු ලබා දිය යුතු බව සලකන්න. එය සමස්ත ප්‍රතිඵලයට ද අහිතකර ලෙස බලපායි.

නමුත් එවැනි යටිතල පහසුකම් සොයා ගත හැක්කේ අභ්යන්තර විසඳුම් සහ ව්යවසාය තුළ පමණි. අවසාන විසඳුම ලෙස, කුඩා WEB ව්‍යාපෘති වල. නමුත් සම්පූර්ණ වෙබ් විසඳුම් සහ HighLoad ලෙස හැඳින්වෙන ඒවා පවා ගොඩනඟා ගැනීමට වටින්නේ නැත. ඔවුන්ගේ යටිතල පහසුකම් ඉහළ උපයෝගිතා සහ බර පැටවීමේ නිර්ණායක සපුරාලිය යුතුය. ඒ වගේම පින්තූරය වෙනස් වෙනවා.

එකම තත්ත්වය යටතේ යටිතල පහසුකම් ක්‍රියාකාරකම් නාලිකා කොළ පැහැයෙන් සලකුණු කර ඇත. RPC දැන් හැසිරෙන ආකාරය සැලකිල්ලට ගන්න. ඉල්ලීම සමතුලිතයේ සිට පසුපෙළ දක්වා එක් පාදයක පමණක් යටිතල පහසුකම් භාවිතා කරයි. පළමු ඉල්ලීමේදී REST තවමත් අහිමි වන අතර, එය සම්පූර්ණ යටිතල පහසුකම් භාවිතා කරමින් අහිමි වූ කාලය පිරිමසා ගනී.

සාරවත් කිරීම සඳහා ඉල්ලීම් දෙකක් නොව, පහක් හෝ දහයක් කියන්න ... සහ “දැන් දිනන්නේ කවුද?” යන ප්‍රශ්නයට පිළිතුර පිටපතට ඇතුළු කිරීම ප්‍රමාණවත්ය. අපැහැදිලි වෙනවා.

ගැටලුව දෙස වඩාත් පුළුල් ලෙස බැලීමට මම යෝජනා කරමි. යටිතල පහසුකම් නාලිකා භාවිතා කරන ආකාරය රූප සටහන පෙන්වයි, නමුත් යටිතල පහසුකම් නාලිකා වලට සීමා නොවේ. අධික බර යටිතල පහසුකම්වල වැදගත් අංගයක් වන්නේ හැඹිලි ය. අපි දැන් යම් ආකාරයක පරිශීලක කෞතුක භාණ්ඩයක් ලබා ගනිමු. නැවත නැවතත්. අපි 32 වතාවක් කියමු.

RPC යටිතල ව්‍යුහය වැඩි බරක් ඇති ඉල්ලුම සපුරාලීම සඳහා සැලකිය යුතු ලෙස වැඩිදියුණු වී ඇති ආකාරය බලන්න. කාරණය වන්නේ RPC මෙන් නොව REST HTTP ප්‍රොටෝකෝලයේ සම්පූර්ණ බලය භාවිතා කිරීමයි. ඉහත රූප සටහනේ, මෙම බලය ඉල්ලීම් ක්‍රමය හරහා සාක්ෂාත් කර ගනී - GET.

HTTP ක්‍රම, වෙනත් දේ අතර, හැඹිලි උපාය මාර්ග ඇත. ඔබට ඒවා ලේඛනවල සොයාගත හැකිය HTTP. RPC සඳහා, POST ඉල්ලීම් භාවිතා කරනු ලැබේ, ඒවා දුර්වල ලෙස නොසැලකේ, එනම්, එකම POST ඉල්ලීම් නැවත නැවත සිදු කිරීමෙන් විවිධ ප්‍රතිඵල ලබා දිය හැක (උදාහරණයක් ලෙස, එක් එක් අදහස් යැවීමෙන් පසු, මෙම අදහසෙහි තවත් පිටපතක් දිස්වනු ඇත) (ප්රභවය).

එහි ප්‍රතිඵලයක් ලෙස, යටිතල පහසුකම් හැඹිලි ඵලදායි ලෙස භාවිතා කිරීමට RPC හට නොහැකි වේ. මෙය මෘදුකාංග හැඹිලි "ආනයනය" කිරීමට අවශ්ය වේ. රූප සටහනේ දැක්වෙන්නේ මෙම භූමිකාවේ රෙඩිස් ය. මෘදුකාංග හැඹිලිය, අනෙක් අතට, සංවර්ධකයාට අමතර කේත තට්ටුවක් සහ ගෘහ නිර්මාණ ශිල්පයේ කැපී පෙනෙන වෙනස්කම් එක් කිරීමට අවශ්‍ය වේ.

සලකා බලන යටිතල පහසුකම් තුළ REST සහ RPC "උපත ලබා දුන්" ඉල්ලීම් කීයක් දැන් ගණන් කරමුද?

ඉල්ලීම්
එන ලිපි
පසුපසට
DBMS වෙත
මෘදු හැඹිලියට (රෙඩිස්)
මුළු එකතුව

රෙස්ට්
1 / 32 *
1
1
0
3 / 35

ආර්පීසී
32
32
1
31
96

[*] හොඳම අවස්ථාවේදී (දේශීය හැඹිලිය භාවිතා කරන්නේ නම්) 1 ඉල්ලීමක් (එකක්!), නරකම අවස්ථාවක ලැබෙන ඉල්ලීම් 32.

පළමු යෝජනා ක්රමයට සාපේක්ෂව, වෙනස කැපී පෙනේ. දැන් REST හි ප්රතිලාභය පැහැදිලි වේ. නමුත් එතැනින් නතර නොවන ලෙස මම යෝජනා කරමි. සංවර්ධිත යටිතල පහසුකම් CDN ඇතුළත් වේ. බොහෝ විට එය DDoS සහ DoS ප්‍රහාරවලට ප්‍රතිරෝධය දැක්වීමේ ගැටලුව ද විසඳයි. අපට ලැබෙන්නේ:

RPC සඳහා දේවල් ඇත්තෙන්ම නරක වන්නේ මෙහිදීය. RPC සරලවම CDN එකකට වැඩ බර පැවරීමේ හැකියාවක් නැත. ප්‍රහාරවලට ප්‍රතිරෝධය දැක්වීම සඳහා අපට විශ්වාසය තැබිය හැක්කේ පද්ධති මත පමණි.

මෙතනින් ඉවර කරන්න පුලුවන්ද? නැවතත්, නැත. HTTP ක්රම, ඉහත සඳහන් කළ පරිදි, ඔවුන්ගේම "මැජික්" ඇත. GET ක්‍රමය අන්තර්ජාලයේ බහුලව භාවිතා වන්නේ හේතුවක් නොමැතිව නොවේ. මෙම ක්‍රමයට අන්තර්ගත කොටසකට ප්‍රවේශ වීමට හැකි බව සලකන්න, යටිතල පහසුකම් මූලද්‍රව්‍යවලට පාලනය ඔබේ කේතයට මාරු කිරීමට පෙර අර්ථ නිරූපණය කළ හැකි කොන්දේසි සැකසීමට සහ යනාදිය. මේ සියල්ල ඔබට විශාල ඉල්ලීම් ප්‍රවාහයන් හැසිරවිය හැකි නම්‍යශීලී, කළමනාකරණය කළ හැකි යටිතල පහසුකම් නිර්මාණය කිරීමට ඉඩ සලසයි. නමුත් RPC හි මෙම ක්‍රමය නොසලකා හරිනු ලැබේ.

එසේනම් කණ්ඩායම් ඉල්ලීම් (RPC) වේගවත්ය යන මිථ්‍යාව මෙතරම් නොනැසී පවතින්නේ ඇයි? පුද්ගලිකව, බොහෝ ව්‍යාපෘති REST හට එහි ශක්තිය පෙන්වීමට හැකි සංවර්ධන මට්ටමකට ළඟා නොවන බව මට පෙනේ. එපමණක්ද නොව, කුඩා ව්යාපෘතිවලදී, ඔහුගේ දුර්වලතා පෙන්වීමට ඔහු වැඩි කැමැත්තක් දක්වයි.

REST හෝ RPC තෝරාගැනීම ව්‍යාපෘතියක පුද්ගලයෙකුගේ ස්වේච්ඡා තේරීමක් නොවේ. මෙම තේරීම ව්යාපෘතියේ අවශ්යතා සපුරාලිය යුතුය. ව්‍යාපෘතියකට REST වෙතින් සැබවින්ම කළ හැකි සෑම දෙයක්ම මිරිකා ගැනීමට හැකි නම් සහ එයට සැබවින්ම අවශ්‍ය නම්, REST විශිෂ්ට තේරීමක් වනු ඇත.

නමුත්, REST හි සියලුම ප්‍රතිලාභ ලබා ගැනීම සඳහා, යටිතල පහසුකම් ඉක්මනින් පරිමාණය කිරීම සඳහා ව්‍යාපෘතිය සඳහා devops විශේෂඥයින් බඳවා ගැනීමට අවශ්‍ය නම්, යටිතල පහසුකම් කළමනාකරණය කිරීමට පරිපාලකයින්, WEB සේවාවේ සියලුම ස්ථර සැලසුම් කිරීමට ගෘහ නිර්මාණ ශිල්පියෙකු ... සහ ව්‍යාපෘතිය. , ඒ අතරම, දිනකට මාගරින් පැකට් තුනක් විකුණනවා ... මම RPC සමඟ රැඳී සිටිමි, මන්ද ... මෙම ප්‍රොටෝකෝලය වඩාත් ප්‍රයෝජනවත් වේ. හැඹිලි සහ යටිතල පහසුකම් ක්‍රියා කරන ආකාරය පිළිබඳ ගැඹුරු දැනුමක් අවශ්‍ය නොවනු ඇත, නමුත් සංවර්ධකයාට අවශ්‍ය ක්‍රියා පටිපාටි සඳහා සරල සහ තේරුම්ගත හැකි ඇමතුම් වෙත අවධානය යොමු කරනු ඇත. ව්‍යාපාර සතුටු වනු ඇත.

තනි ගනුදෙනුවක් තුළ කණ්ඩායම් ඉල්ලීම් ක්‍රියාත්මක කළ හැකි නිසා RPC ඉල්ලීම් වඩාත් විශ්වාසදායක වේ

RPC හි මෙම දේපල නිශ්චිත වාසියකි, මන්ද දත්ත සමුදාය ස්ථාවරව තබා ගැනීම පහසුය. නමුත් REST සමඟ එය වඩ වඩාත් සංකීර්ණ වේ. විවිධ පසුපෙළ නෝඩ් වෙත ඉල්ලීම් නොගැලපෙන ලෙස පැමිණිය හැකිය.

REST හි මෙම “අවාසිකම” යනු ඉහත විස්තර කර ඇති එහි වාසියේ අනෙක් පැත්තයි - සියලු යටිතල පහසුකම් සම්පත් කාර්යක්ෂමව භාවිතා කිරීමේ හැකියාව. යටිතල පහසුකම් දුර්වල ලෙස නිර්මාණය කර ඇත්නම්, ඊටත් වඩා ව්‍යාපෘතියේ ගෘහ නිර්මාණ ශිල්පය සහ විශේෂයෙන් දත්ත සමුදාය දුර්වල ලෙස නිර්මාණය කර ඇත්නම්, මෙය ඇත්තෙන්ම විශාල වේදනාවකි.

නමුත් කණ්ඩායම් ඉල්ලීම් පෙනෙන තරම් විශ්වාසදායකද? අපි නඩුවක් බලමු: අපි පරිශීලකයෙකු නිර්මාණය කර, ඔහුගේ පැතිකඩ යම් විස්තරයකින් පොහොසත් කර ලියාපදිංචිය සම්පූර්ණ කිරීම සඳහා රහසක් සමඟ ඔහුට කෙටි පණිවුඩයක් යවන්න. එම. එක් කණ්ඩායමක ඉල්ලීම් තුනක්.

අපි රූප සටහන දෙස බලමු. එය ඉහළ ලබා ගත හැකි මූලද්රව්ය සමඟ යටිතල පහසුකම් ඉදිරිපත් කරයි. SMS ද්වාර සහිත ස්වාධීන සන්නිවේදන නාලිකා දෙකක් ඇත. නමුත් ... අපි දකින්නේ කුමක්ද? කෙටි පණිවුඩයක් යැවීමේදී, 503 දෝෂයක් ඇතිවේ - සේවාව තාවකාලිකව ලබා ගත නොහැක. නිසා කෙටි පණිවුඩ යැවීම කණ්ඩායම් ඉල්ලීමක ඇසුරුම් කර ඇත, එවිට සම්පූර්ණ ඉල්ලීම ආපසු හැරවිය යුතුය. DBMS හි ක්‍රියා අවලංගු කර ඇත. සේවාදායකයාට දෝෂයක් ලැබේ.

ඊළඟ උත්සාහය ලොතරැයිය. එක්කෝ ඉල්ලීම එකම නෝඩයටම නැවත නැවතත් දෝෂයක් ලබා දෙනු ඇත, නැතහොත් ඔබ වාසනාවන්ත වන අතර එය ක්‍රියාත්මක වේ. නමුත් ප්රධාන දෙය නම් අවම වශයෙන් එක් වරක් අපගේ යටිතල පහසුකම් දැනටමත් නිෂ්ඵල ලෙස වැඩ කර ඇත. බඩුවක් තිබුනත් ලාභයක් නෑ.

හරි, අපි හිතමු අපි අපවම වෙහෙසට පත් කරගෙන (!) ඉල්ලීම අර්ධ වශයෙන් සාර්ථකව නිම කළ හැකි විකල්පය ගැන සිතමු. ඒ වගේම අපි යම් කාල පරතරයකින් පසුව (කුමක්ද? පෙරමුණ තීරණය කරයිද?) නැවත සම්පූර්ණ කිරීමට උත්සාහ කරමු. නමුත් ලොතරැයිය එලෙසම පැවතුනි. SMS යැවීමට ඉල්ලීම නැවත අසාර්ථක වීමට 50/50 අවස්ථාවක් ඇත.

එකඟයි, සේවාදායකයාගේ පැත්තෙන්, සේවාව අප කැමති තරම් විශ්වාසදායක නොවන බව පෙනේ ... REST ගැන කුමක් කිව හැකිද?

REST නැවතත් HTTP හි මැජික් භාවිතා කරයි, නමුත් දැන් ප්‍රතිචාර කේත සමඟ. SMS ද්වාරයෙහි 503 දෝෂයක් ඇති වූ විට, පසුපෙළ මෙම දෝෂය සමතුලිතයට විකාශනය කරයි. සමතුලිතයාට මෙම දෝෂය ලැබෙන අතර සේවාදායකයා සමඟ ඇති සම්බන්ධතාවය බිඳ දැමීමකින් තොරව, ඉල්ලීම වෙනත් නෝඩයකට යවයි, එමඟින් ඉල්ලීම සාර්ථකව ක්‍රියා කරයි. එම. සේවාලාභියා අපේක්ෂිත ප්රතිඵලය ලබා ගන්නා අතර, යටිතල පහසුකම් එහි "ඉතා ප්රවේශ විය හැකි" ඉහළ මාතෘකාව තහවුරු කරයි. පරිශීලකයා සතුටුයි.

නැවතත් එය සියල්ලම නොවේ. සමතුලිතයට 503 ප්‍රතිචාර කේතයක් පමණක් ලැබුණේ නැත. ප්‍රතිචාර දැක්වීමේදී, ප්‍රමිතියට අනුව, මෙම කේතය “නැවත උත්සාහ-පසු” ශීර්ෂය සමඟ සැපයීම සුදුසුය. නිශ්චිත කාලයක් සඳහා මෙම මාර්ගයේ මෙම නෝඩය බාධා කිරීම වටින්නේ නැති බව ශීර්ෂකය තුලනය කරන්නාට පැහැදිලි වේ. කෙටි පණිවුඩ යැවීමට ඊළඟ ඉල්ලීම් SMS ද්වාරය සමඟ කිසිදු ගැටළුවක් නොමැති නෝඩයකට කෙලින්ම යවනු ලැබේ.

අපට පෙනෙන පරිදි, JSON-RPC හි විශ්වසනීයත්වය අධිතක්සේරු කර ඇත. ඇත්ත වශයෙන්ම, දත්ත සමුදායේ අනුකූලතාව සංවිධානය කිරීම පහසුය. නමුත් පූජාව, මේ අවස්ථාවේ දී, සමස්තයක් ලෙස පද්ධතියේ විශ්වසනීයත්වය වනු ඇත.

නිගමනය බොහෝ දුරට පෙර එකට සමාන ය. යටිතල පහසුකම් සරල වන විට, JSON-RPC හි පැහැදිලි බව නිසැකවම ප්ලස් වේ. ව්‍යාපෘතියට ඉහළ බරක් සහිත ඉහළ ලබා ගැනීමේ හැකියාවක් ඇතුළත් වන්නේ නම්, REST වඩාත් සංකීර්ණ වුවද වඩාත් නිවැරදි විසඳුමක් ලෙස පෙනේ.

REST වෙත ඇතුල් වීමේ සීමාව අඩුය

ඉහත විශ්ලේෂණය, RPC පිළිබඳ ස්ථාපිත ඒකාකෘති නිෂ්ප්‍රභ කරමින්, REST වෙත ප්‍රවේශ වීමේ සීමාව RPC වෙතට වඩා නිසැකවම ඉහළ බව පැහැදිලිව පෙන්නුම් කළ බව මම සිතමි. මෙයට හේතුව HTTP ක්‍රියා කරන ආකාරය පිළිබඳ ගැඹුරු අවබෝධයක් මෙන්ම, WEB ව්‍යාපෘතිවල භාවිතා කළ හැකි සහ භාවිතා කළ යුතු පවතින යටිතල පහසුකම් පිළිබඳ ප්‍රමාණවත් දැනුමක් තිබීමේ අවශ්‍යතාවයයි.

ඉතින් බොහෝ අය සිතන්නේ REST සරල වනු ඇති බවයි? මගේ පෞද්ගලික මතය නම් මෙම පෙනෙන සරල බව REST ප්‍රකාශනයෙන් ලැබෙන බවයි. එම. REST යනු ප්‍රොටෝකෝලයක් නොව සංකල්පයකි... REST වලට ප්‍රමිතියක් නැත, මාර්ගෝපදේශ කිහිපයක් තිබේ... REST HTTP වලට වඩා සංකීර්ණ නොවේ. පෙනෙන නිදහස සහ අරාජිකත්වය "නිදහස් කලාකරුවන්" ආකර්ෂණය කරයි.

ඇත්ත වශයෙන්ම, REST HTTP වලට වඩා සංකීර්ණ නොවේ. නමුත් HTTP යනු දශක ගණනාවක් තිස්සේ එහි වටිනාකම ඔප්පු කර ඇති හොඳින් සැලසුම් කරන ලද ප්‍රොටෝකෝලයකි. HTTP පිළිබඳ ගැඹුරු අවබෝධයක් නොමැති නම්, REST විනිශ්චය කළ නොහැක.

නමුත් RPC ගැන - ඔබට පුළුවන්. එහි පිරිවිතර ගැනීම ප්රමාණවත්ය. ඉතින් ඔබට අවශ්යයි මෝඩ JSON-RPC? නැතහොත් එය තවමත් උපක්‍රමශීලී REST ද? ඔබ තීරණය කරන්න.

මම ඔබේ කාලය නාස්ති නොකළ බව මම අවංකවම බලාපොරොත්තු වෙමි.

මූලාශ්රය: www.habr.com