JSON-RPC? મુશ્કેલ આરામ લો

મને ખાતરી છે કે હેડલાઇનને કારણે સ્વસ્થ પ્રતિક્રિયા થઈ છે - "સારું, તે ફરીથી શરૂ થયું છે..." પરંતુ મને 5-10 મિનિટ માટે તમારું ધ્યાન ખેંચવા દો, અને હું તમારી અપેક્ષાઓને નિરાશ ન કરવાનો પ્રયાસ કરીશ.

લેખની રચના નીચે મુજબ હશે: એક બીબાઢાળ નિવેદન લેવામાં આવે છે અને આ સ્ટીરિયોટાઇપના ઉદભવની "પ્રકૃતિ" પ્રગટ થાય છે. હું આશા રાખું છું કે આ તમને તમારા પ્રોજેક્ટ્સમાં ડેટા એક્સચેન્જ પેરાડિમની પસંદગીને નવા ખૂણાથી જોવાની મંજૂરી આપશે.

RPC શું છે તે વિશે સ્પષ્ટ થવા માટે, હું ધોરણને ધ્યાનમાં લેવાનો પ્રસ્તાવ મૂકું છું JSON-RPC 2.0. REST સાથે કોઈ સ્પષ્ટતા નથી. અને તે ન હોવું જોઈએ. તમારે REST વિશે જાણવાની જરૂર છે તે બધું - તે અસ્પષ્ટ છે HTTP.

RPC વિનંતીઓ ઝડપી અને વધુ કાર્યક્ષમ છે કારણ કે તે તમને બેચ વિનંતીઓ કરવાની મંજૂરી આપે છે.

મુદ્દો એ છે કે RPC માં તમે એક વિનંતીમાં એક સાથે અનેક પ્રક્રિયાઓ કૉલ કરી શકો છો. ઉદાહરણ તરીકે, વપરાશકર્તા બનાવો, તેના માટે અવતાર ઉમેરો અને તે જ વિનંતીમાં, તેને કેટલાક વિષયો પર સબ્સ્ક્રાઇબ કરો. બસ એક વિનંતી, અને કેટલો ફાયદો!

ખરેખર, જો તમારી પાસે માત્ર એક બેકએન્ડ નોડ છે, તો તે બેચ વિનંતી સાથે ઝડપી લાગશે. કારણ કે ત્રણ REST વિનંતીઓને જોડાણો સ્થાપિત કરવા માટે એક નોડમાંથી ત્રણ ગણા વધુ સંસાધનોની જરૂર પડશે.

નોંધ કરો કે REST ના કિસ્સામાં પ્રથમ વિનંતીએ અનુગામી વિનંતીઓ કરવા માટે વપરાશકર્તા ID પરત કરવું આવશ્યક છે. જે એકંદર પરિણામ પર પણ નકારાત્મક અસર કરે છે.

પરંતુ આવા ઇન્ફ્રાસ્ટ્રક્ચર ફક્ત ઇન-હાઉસ સોલ્યુશન્સ અને એન્ટરપ્રાઇઝમાં જ મળી શકે છે. છેલ્લા ઉપાય તરીકે, નાના WEB પ્રોજેક્ટ્સમાં. પરંતુ સંપૂર્ણ સુવિધાયુક્ત WEB સોલ્યુશન્સ, અને તે પણ જેને હાઈલોડ કહેવાય છે, તે નિર્માણ કરવા યોગ્ય નથી. તેમનું ઇન્ફ્રાસ્ટ્રક્ચર ઉચ્ચ ઉપલબ્ધતા અને લોડના માપદંડોને પૂર્ણ કરે છે. અને ચિત્ર બદલાઈ રહ્યું છે.

સમાન દૃશ્ય હેઠળ ઇન્ફ્રાસ્ટ્રક્ચર પ્રવૃત્તિ ચેનલો લીલા રંગમાં ચિહ્નિત થયેલ છે. નોંધ કરો કે હવે RPC કેવી રીતે વર્તે છે. વિનંતિ બેલેન્સરથી બેકએન્ડ સુધીના માત્ર એક પગ પર ઈન્ફ્રાસ્ટ્રક્ચરનો ઉપયોગ કરે છે. જ્યારે REST હજુ પણ પ્રથમ વિનંતીમાં ગુમાવે છે, તે સમગ્ર ઈન્ફ્રાસ્ટ્રક્ચરનો ઉપયોગ કરીને ખોવાયેલા સમયની ભરપાઈ કરે છે.

સ્ક્રિપ્ટમાં સંવર્ધન માટેની બે વિનંતીઓ નહીં, પરંતુ, કહો, પાંચ કે દસ... અને "હવે કોણ જીતે છે?" પ્રશ્નનો જવાબ દાખલ કરવા માટે તે પૂરતું છે. અસ્પષ્ટ બને છે.

હું સમસ્યા પર વધુ વ્યાપક દેખાવ લેવાનો પ્રસ્તાવ મૂકું છું. આકૃતિ બતાવે છે કે કેવી રીતે ઈન્ફ્રાસ્ટ્રક્ચર ચેનલોનો ઉપયોગ કરવામાં આવે છે, પરંતુ ઈન્ફ્રાસ્ટ્રક્ચર માત્ર ચેનલો સુધી મર્યાદિત નથી. હાઈ-લોડ ઈન્ફ્રાસ્ટ્રક્ચરનો એક મહત્વપૂર્ણ ઘટક કેશ છે. ચાલો હવે અમુક પ્રકારની યુઝર આર્ટિફેક્ટ મેળવીએ. વારંવાર. ચાલો 32 વખત કહીએ.

ઉચ્ચ લોડની માંગને પહોંચી વળવા માટે RPC ઈન્ફ્રાસ્ટ્રક્ચરમાં કેવી રીતે નોંધપાત્ર સુધારો થયો છે તે જુઓ. આ બાબત એ છે કે REST RPC થી વિપરીત HTTP પ્રોટોકોલની સંપૂર્ણ શક્તિનો ઉપયોગ કરે છે. ઉપરના ચિત્રમાં, આ શક્તિ વિનંતી પદ્ધતિ - GET દ્વારા અનુભવાય છે.

HTTP પદ્ધતિઓ, અન્ય વસ્તુઓની સાથે, કેશીંગ વ્યૂહરચના ધરાવે છે. તમે તેમને દસ્તાવેજીકરણમાં શોધી શકો છો HTTP. RPC માટે, POST વિનંતીઓનો ઉપયોગ કરવામાં આવે છે, જેને અયોગ્ય ગણવામાં આવતી નથી, એટલે કે, સમાન POST વિનંતીઓનું પુનરાવર્તન વિવિધ પરિણામો આપી શકે છે (ઉદાહરણ તરીકે, દરેક ટિપ્પણી મોકલ્યા પછી, આ ટિપ્પણીની બીજી નકલ દેખાશે) (સ્રોત).

પરિણામે, RPC ઈન્ફ્રાસ્ટ્રક્ચર કેશનો અસરકારક રીતે ઉપયોગ કરવામાં અસમર્થ છે. આ સોફ્ટવેર કેશને "આયાત" કરવાની જરૂરિયાત તરફ દોરી જાય છે. રેખાકૃતિ રેડિસને આ ભૂમિકામાં બતાવે છે. સોફ્ટવેર કેશ, બદલામાં, વિકાસકર્તાને કોડના વધારાના સ્તર અને આર્કિટેક્ચરમાં નોંધપાત્ર ફેરફારો ઉમેરવાની જરૂર છે.

ચાલો હવે ગણતરી કરીએ કે REST અને RPC એ વિચારણા હેઠળના ઈન્ફ્રાસ્ટ્રક્ચરમાં કેટલી વિનંતીઓને “જન્મ આપ્યો”?

વિનંતીઓ
ઇનબોક્સ
બેકએન્ડ માટે
DBMS ને
સોફ્ટ કેશમાં (રેડીસ)
કુલ

REST
1 / 32 *
1
1
0
3 / 35

આર.પી.સી.
32
32
1
31
96

[

પ્રથમ યોજનાની તુલનામાં, તફાવત આશ્ચર્યજનક છે. હવે REST નો ફાયદો સ્પષ્ટ થાય છે. પરંતુ હું ત્યાં ન રોકાવાનું સૂચન કરું છું. વિકસિત ઈન્ફ્રાસ્ટ્રક્ચરમાં સીડીએનનો સમાવેશ થાય છે. ઘણીવાર તે DDoS અને DoS હુમલાઓનો સામનો કરવાના મુદ્દાને પણ હલ કરે છે. અમને મળે છે:

આ તે છે જ્યાં વસ્તુઓ RPC માટે ખરેખર ખરાબ થાય છે. RPC ફક્ત CDN ને વર્કલોડ સોંપવામાં સક્ષમ નથી. અમે હુમલાઓનો સામનો કરવા માટે ફક્ત સિસ્ટમ્સ પર આધાર રાખી શકીએ છીએ.

શું અહીં સમાપ્ત થવું શક્ય છે? અને ફરીથી, ના. HTTP પદ્ધતિઓ, ઉપર જણાવ્યા મુજબ, તેમના પોતાના "જાદુ" છે. અને તે કારણ વિના નથી કે ઇન્ટરનેટ પર GET પદ્ધતિનો વ્યાપકપણે ઉપયોગ થાય છે. નોંધ કરો કે આ પદ્ધતિ સામગ્રીના એક ભાગને ઍક્સેસ કરવામાં સક્ષમ છે, તમારા કોડમાં નિયંત્રણ સ્થાનાંતરિત થાય તે પહેલાં ઇન્ફ્રાસ્ટ્રક્ચર તત્વો અર્થઘટન કરી શકે તેવી શરતો સેટ કરવામાં સક્ષમ છે, વગેરે. આ બધું તમને લવચીક, વ્યવસ્થિત ઇન્ફ્રાસ્ટ્રક્ચર્સ બનાવવાની મંજૂરી આપે છે જે વિનંતીઓના ખરેખર મોટા પ્રવાહને હેન્ડલ કરી શકે છે. પરંતુ RPC માં આ પદ્ધતિ... અવગણવામાં આવે છે.

તો શા માટે પૌરાણિક કથા છે કે બેચ વિનંતીઓ (RPC) એટલી ઝડપી છે? અંગત રીતે, મને એવું લાગે છે કે મોટા ભાગના પ્રોજેક્ટ્સ વિકાસના એવા સ્તરે પહોંચતા નથી જ્યાં REST તેની તાકાત બતાવવામાં સક્ષમ હોય. તદુપરાંત, નાના પ્રોજેક્ટ્સમાં, તે તેની નબળાઈઓ બતાવવા માટે વધુ તૈયાર છે.

REST અથવા RPC ની પસંદગી એ પ્રોજેક્ટમાં વ્યક્તિની સ્વૈચ્છિક પસંદગી નથી. આ પસંદગીએ પ્રોજેક્ટની જરૂરિયાતોને પૂર્ણ કરવી આવશ્યક છે. જો કોઈ પ્રોજેક્ટ RESTમાંથી જે કંઈ કરી શકે તે બધું જ સ્ક્વિઝ કરી શકે છે, અને તેને ખરેખર તેની જરૂર છે, તો REST એ ઉત્તમ પસંદગી હશે.

પરંતુ જો, REST ના તમામ લાભો મેળવવા માટે, તમારે ઇન્ફ્રાસ્ટ્રક્ચરને ઝડપથી સ્કેલ કરવા માટે પ્રોજેક્ટ માટે ડેવૉપ્સ નિષ્ણાતોને, ઇન્ફ્રાસ્ટ્રક્ચરનું સંચાલન કરવા માટે એડમિનિસ્ટ્રેટર્સ, WEB સેવાના તમામ સ્તરોને ડિઝાઇન કરવા માટે એક આર્કિટેક્ટ... અને પ્રોજેક્ટને હાયર કરવાની જરૂર છે. , તે જ સમયે, એક દિવસમાં માર્જરિનના ત્રણ પેક વેચે છે... હું RPC સાથે વળગી રહીશ, કારણ કે... આ પ્રોટોકોલ વધુ ઉપયોગિતાવાદી છે. તેને કેશ અને ઇન્ફ્રાસ્ટ્રક્ચર કેવી રીતે કાર્ય કરે છે તેના ઊંડા જ્ઞાનની જરૂર રહેશે નહીં, પરંતુ વિકાસકર્તાને તેને જરૂરી પ્રક્રિયાઓ માટે સરળ અને સમજી શકાય તેવા કૉલ્સ પર ધ્યાન કેન્દ્રિત કરશે. વ્યાપાર સુખદ રહેશે.

RPC વિનંતીઓ વધુ વિશ્વસનીય છે કારણ કે તેઓ એક જ વ્યવહારમાં બેચ વિનંતીઓ ચલાવી શકે છે

RPC ની આ મિલકત ચોક્કસ લાભ છે, કારણ કે ડેટાબેઝને સુસંગત રાખવું સરળ છે. પરંતુ REST સાથે તે વધુ ને વધુ જટિલ બને છે. વિનંતીઓ વિવિધ બેકએન્ડ નોડ્સ પર અસંગત રીતે આવી શકે છે.

REST નો આ "ગેરલાભ" ઉપર વર્ણવેલ તેના ફાયદાની બીજી બાજુ છે - તમામ માળખાકીય સંસાધનોનો અસરકારક રીતે ઉપયોગ કરવાની ક્ષમતા. જો ઈન્ફ્રાસ્ટ્રક્ચર ખરાબ રીતે ડિઝાઈન કરવામાં આવ્યું હોય, અને તેથી પણ જો પ્રોજેક્ટનું આર્કિટેક્ચર અને ખાસ કરીને ડેટાબેઝ ખરાબ રીતે ડિઝાઈન કરવામાં આવ્યું હોય, તો આ ખરેખર એક મોટી પીડા છે.

પરંતુ શું બેચની વિનંતીઓ લાગે તેટલી વિશ્વસનીય છે? ચાલો એક કેસ જોઈએ: અમે એક વપરાશકર્તા બનાવીએ છીએ, તેની પ્રોફાઇલને કેટલાક વર્ણન સાથે સમૃદ્ધ કરીએ છીએ અને તેને નોંધણી પૂર્ણ કરવા માટે એક રહસ્ય સાથે એક SMS મોકલીએ છીએ. તે. એક બેચ વિનંતીમાં ત્રણ કૉલ.

ચાલો ડાયાગ્રામ જોઈએ. તે ઉચ્ચ ઉપલબ્ધતા તત્વો સાથેનું ઇન્ફ્રાસ્ટ્રક્ચર રજૂ કરે છે. SMS ગેટવે સાથે બે સ્વતંત્ર સંચાર ચેનલો છે. પણ... આપણે શું જોઈએ છીએ? SMS મોકલતી વખતે, ભૂલ 503 થાય છે - સેવા અસ્થાયી રૂપે અનુપલબ્ધ છે. કારણ કે એસએમએસ મોકલવાનું બેચ વિનંતીમાં પેક કરવામાં આવે છે, પછી સમગ્ર વિનંતિ પાછી ફેરવવી આવશ્યક છે. DBMS માં ક્રિયાઓ રદ કરવામાં આવી છે. ક્લાયંટને ભૂલ મળે છે.

હવે પછીનો પ્રયાસ લોટરીનો છે. ક્યાં તો વિનંતી એ જ નોડ પર ફરી વળશે અને ફરીથી ભૂલ આપશે, અથવા તમે નસીબદાર બનશો અને તે ચલાવવામાં આવશે. પરંતુ મુખ્ય વસ્તુ એ છે કે ઓછામાં ઓછું એકવાર આપણું ઇન્ફ્રાસ્ટ્રક્ચર પહેલેથી જ નિરર્થક કામ કરી ચૂક્યું છે. ત્યાં એક ભાર હતો, પરંતુ કોઈ નફો.

ઠીક છે, ચાલો કલ્પના કરીએ કે આપણે આપણી જાતને તાણ (!) કરી છે અને વિકલ્પ દ્વારા વિચાર્યું છે જ્યારે વિનંતી આંશિક રીતે સફળતાપૂર્વક પૂર્ણ કરી શકાય છે. અને અમે થોડા સમયના અંતરાલ પછી ફરીથી બાકીનું પૂર્ણ કરવાનો પ્રયાસ કરીશું (કયું? શું આગળનો નિર્ણય?). પણ લોટરી તો એ જ રહી. SMS મોકલવાની વિનંતીમાં ફરીથી નિષ્ફળ થવાની 50/50 તક છે.

સંમત થાઓ, ક્લાયન્ટ તરફથી, સેવા એટલી વિશ્વસનીય લાગતી નથી જેટલી અમે ઈચ્છીએ છીએ... REST વિશે શું?

REST ફરી HTTP ના જાદુનો ઉપયોગ કરે છે, પરંતુ હવે પ્રતિભાવ કોડ સાથે. જ્યારે SMS ગેટવે પર ભૂલ 503 થાય છે, ત્યારે બેકએન્ડ આ ભૂલને બેલેન્સરને બ્રોડકાસ્ટ કરે છે. બેલેન્સરને આ ભૂલ મળે છે અને ક્લાયંટ સાથે કનેક્શન તોડ્યા વિના, વિનંતીને બીજા નોડ પર મોકલે છે, જે વિનંતી પર સફળતાપૂર્વક પ્રક્રિયા કરે છે. તે. ક્લાયન્ટ અપેક્ષિત પરિણામ મેળવે છે, અને ઇન્ફ્રાસ્ટ્રક્ચર તેના "અત્યંત સુલભ" ના ઉચ્ચ શીર્ષકની પુષ્ટિ કરે છે. વપરાશકર્તા ખુશ છે.

અને ફરીથી તે બધુ જ નથી. બેલેન્સરને માત્ર 503 નો પ્રતિસાદ કોડ પ્રાપ્ત થયો ન હતો. પ્રતિસાદ આપતી વખતે, ધોરણ મુજબ, આ કોડને "પુનઃપ્રયાસ-આફ્ટર" હેડર સાથે પ્રદાન કરવાની સલાહ આપવામાં આવે છે. હેડર બેલેન્સરને સ્પષ્ટ કરે છે કે તેણે ચોક્કસ સમય માટે આ રૂટ પર આ નોડને ખલેલ પહોંચાડવી જોઈએ નહીં. અને SMS મોકલવા માટેની આગળની વિનંતીઓ સીધા જ એવા નોડ પર મોકલવામાં આવશે કે જેને 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