హెడ్‌లైన్ ఆరోగ్యకరమైన ప్రతిచర్యను అందించిందని నేను ఖచ్చితంగా అనుకుంటున్నాను - "అలాగే, ఇది మళ్లీ ప్రారంభమైంది ..." కానీ నన్ను 5-10 నిమిషాలు మీ దృష్టిని ఆకర్షించనివ్వండి మరియు నేను అంచనాలను మోసం చేయకుండా ప్రయత్నిస్తాను.
వ్యాసం యొక్క నిర్మాణం క్రింది విధంగా ఉంటుంది: ఒక మూస ప్రకటన తీసుకోబడింది మరియు ఈ మూస యొక్క ఆవిర్భావం యొక్క "స్వభావం" వెల్లడి చేయబడింది. మీ ప్రాజెక్ట్‌లలో డేటా మార్పిడి నమూనా ఎంపికను కొత్త కోణం నుండి చూడటానికి ఇది మిమ్మల్ని అనుమతిస్తుంది అని నేను ఆశిస్తున్నాను.
RPC అంటే ఏమిటో స్పష్టంగా తెలియాలంటే, నేను ప్రమాణాన్ని పరిగణించాలని ప్రతిపాదిస్తున్నాను . RESTతో స్పష్టత లేదు. మరియు అది ఉండకూడదు. మీరు REST గురించి తెలుసుకోవలసినది ఏమిటంటే అది వేరు చేయలేనిది .
RPC అభ్యర్థనలు వేగంగా మరియు మరింత సమర్థవంతంగా ఉంటాయి ఎందుకంటే అవి బ్యాచ్ అభ్యర్థనలను చేయడానికి మిమ్మల్ని అనుమతిస్తాయి.
పాయింట్ ఏమిటంటే RPC లో ఒక అభ్యర్థనలో ఒకేసారి అనేక విధానాలను కాల్ చేయడం సాధ్యపడుతుంది. ఉదాహరణకు, వినియోగదారుని సృష్టించి, అతనికి అవతార్‌ని జోడించి, అదే అభ్యర్థనలో కొన్ని అంశాలకు అతనిని సబ్‌స్క్రైబ్ చేయండి. కేవలం ఒక అభ్యర్థన, మరియు ఎన్ని ప్రయోజనాలు!
నిజానికి, మీకు ఒక బ్యాకెండ్ నోడ్ మాత్రమే ఉంటే, బ్యాచ్ అభ్యర్థనతో అది వేగంగా కనిపిస్తుంది. ఎందుకంటే మూడు REST అభ్యర్థనలకు కనెక్షన్‌లను ఏర్పాటు చేయడానికి ఒక నోడ్ నుండి మూడు రెట్లు ఎక్కువ వనరులు అవసరమవుతాయి.
తదుపరి అభ్యర్థనలు చేయడానికి REST విషయంలో మొదటి అభ్యర్థన తప్పనిసరిగా వినియోగదారు IDని అందించాలని గుర్తుంచుకోండి. ఇది మొత్తం ఫలితాన్ని కూడా ప్రతికూలంగా ప్రభావితం చేస్తుంది.
కానీ అలాంటి అవస్థాపనలు, బహుశా, అంతర్గత పరిష్కారాలు మరియు ఎంటర్‌ప్రైజ్‌లో కనుగొనవచ్చు. చివరి ప్రయత్నంగా, చిన్న వెబ్ ప్రాజెక్ట్‌లలో. కానీ పూర్తి స్థాయి WEB సొల్యూషన్స్ మరియు హైలోడ్ అని కూడా పిలుస్తారు, అలా నిర్మించకూడదు. వారి మౌలిక సదుపాయాలు అధిక లభ్యత మరియు లోడ్ కోసం ప్రమాణాలకు అనుగుణంగా ఉండాలి. మరియు చిత్రం మారుతోంది.
అదే దృష్టాంతంలో మౌలిక సదుపాయాల కార్యకలాపాల ఛానెల్‌లను ఆకుపచ్చ గుర్తు చేస్తుంది. RPC ఇప్పుడు ఎలా ప్రవర్తిస్తుందో గమనించండి. అభ్యర్థన బ్యాలెన్సర్ నుండి బ్యాకెండ్ వరకు ఒక భుజంపై మాత్రమే మౌలిక సదుపాయాలను ఉపయోగిస్తుంది. మొదటి అభ్యర్థనలో REST ఇప్పటికీ ఓడిపోయినప్పటికీ, మొత్తం మౌలిక సదుపాయాలను ఉపయోగించుకుంటుంది.
స్క్రిప్ట్‌లోకి సుసంపన్నం కోసం రెండు అభ్యర్థనలు కాదు, ఐదు లేదా పది చెప్పండి ... మరియు “ఇప్పుడు ఎవరు గెలుస్తారు?” అనే ప్రశ్నకు సమాధానం ఇస్తే సరిపోతుంది. అదృశ్యమవుతుంది.
నేను సమస్యను విస్తృతంగా పరిశీలించాలని ప్రతిపాదిస్తున్నాను. ఇన్‌ఫ్రాస్ట్రక్చర్ ఛానెల్‌లు ఎలా ఉపయోగించబడుతున్నాయో రేఖాచిత్రం చూపిస్తుంది, అయితే అవస్థాపన అనేది ఛానెల్‌లకు మాత్రమే పరిమితం కాదు. అధిక లోడ్ చేయబడిన మౌలిక సదుపాయాలలో కాష్‌లు ఒక ముఖ్యమైన భాగం. ఇప్పుడు కొంత వినియోగదారు కళాకృతిని పొందండి. పదేపదే. 32 సార్లు అనుకుందాం.
అధిక లోడ్ యొక్క అవసరాలను తీర్చడానికి RPCలోని అవస్థాపన ఎలా గమనించదగ్గ విధంగా "కోలుకుంది" అని చూడండి. విషయం ఏమిటంటే, REST RPC వలె కాకుండా HTTP ప్రోటోకాల్ యొక్క పూర్తి శక్తిని ఉపయోగిస్తుంది. పై రేఖాచిత్రంలో, ఈ శక్తి అభ్యర్థన పద్ధతి ద్వారా గ్రహించబడుతుంది - GET.
HTTP పద్ధతులు, ఇతర విషయాలతోపాటు, కాషింగ్ వ్యూహాలను కలిగి ఉంటాయి. మీరు వాటిని డాక్యుమెంటేషన్‌లో కనుగొనవచ్చు . RPC కోసం, POST అభ్యర్థనలు ఉపయోగించబడతాయి, అవి ఐడెంపోటెంట్‌గా పరిగణించబడవు, అంటే, అదే POST అభ్యర్థనలను పదేపదే పునరావృతం చేయడం వలన విభిన్న ఫలితాలు రావచ్చు (ఉదాహరణకు, ప్రతి వ్యాఖ్య పంపిన తర్వాత, ఈ వ్యాఖ్య యొక్క మరొక కాపీ కనిపిస్తుంది) ().
పర్యవసానంగా, RPC మౌలిక సదుపాయాల క్యాష్‌లను సమర్థవంతంగా ఉపయోగించుకోలేకపోతుంది. ఇది మీరు మృదువైన కాష్లను "దిగుమతి" చేయవలసి ఉంటుంది. రేడిస్ ఈ పాత్రలో ఉన్నట్లు రేఖాచిత్రం చూపిస్తుంది. సాఫ్ట్ కాష్‌కి, డెవలపర్ నుండి అదనపు కోడ్ లేయర్ మరియు ఆర్కిటెక్చర్‌లో గుర్తించదగిన మార్పులు అవసరం.
పరిశీలనలో ఉన్న ఇన్‌ఫ్రాస్ట్రక్చర్‌లో REST మరియు RPC ఎన్ని అభ్యర్థనలు "జన్మించాయి" అని ఇప్పుడు లెక్కిద్దాం?
అభ్యర్థనలు
ఇన్బాక్స్
బ్యాకెండ్
DBMS కు
సాఫ్ట్ కాష్‌కి (రెడిస్)
TOTAL
REST
1 / 32 *
1
1
0
3 / 35
సిపిపి
32
32
1
31
96
మొదటి పథకంతో పోలిస్తే, వ్యత్యాసం అద్భుతమైనది. ఇప్పుడు REST యొక్క ప్రయోజనం స్పష్టంగా కనిపిస్తుంది. కానీ అక్కడితో ఆగవద్దని నేను సూచిస్తున్నాను. అభివృద్ధి చెందిన మౌలిక సదుపాయాలలో CDN కూడా ఉంది. తరచుగా, ఇది DDoS మరియు DoS దాడులను ఎదుర్కొనే సమస్యను కూడా పరిష్కరిస్తుంది. మాకు దొరికింది:
ఇక్కడ RPC కోసం ప్రతిదీ చాలా దుర్భరమైనది. RPC కేవలం CDN లోడ్‌కు పనిని అప్పగించలేకపోయింది. దాడులను ఎదుర్కోవడానికి వ్యవస్థల కోసం మాత్రమే మేము ఆశిస్తున్నాము.
అక్కడితో ముగించడం సాధ్యమేనా? మరియు మళ్ళీ, లేదు. HTTP పద్ధతులు, పైన పేర్కొన్న విధంగా, వారి స్వంత "మేజిక్" కలిగి ఉంటాయి. మరియు ఇంటర్నెట్‌లో GET పద్ధతి పూర్తిగా ఉపయోగించబడటం ఏమీ కాదు. ఈ పద్ధతి కంటెంట్ భాగాన్ని యాక్సెస్ చేయగలదని గమనించండి, మీ కోడ్‌కు నియంత్రణను పంపే ముందు ఇన్‌ఫ్రాస్ట్రక్చర్ ఎలిమెంట్‌లు అర్థం చేసుకోగలిగే షరతులను సెట్ చేయగలదు మరియు మొదలైనవి. నిజంగా పెద్ద అభ్యర్థనలను నిర్వహించగలిగే సౌకర్యవంతమైన, నిర్వహించదగిన మౌలిక సదుపాయాలను సృష్టించడానికి ఇవన్నీ మిమ్మల్ని అనుమతిస్తుంది. మరియు RPC లో ఈ పద్ధతి ... విస్మరించబడింది.
కాబట్టి బ్యాచ్ అభ్యర్థనలు (RPC) వేగవంతమైనవి అనే అపోహ ఎందుకు నిరంతరంగా ఉంది? వ్యక్తిగతంగా, REST దాని బలాన్ని చూపించగలిగినప్పుడు చాలా ప్రాజెక్టులు అటువంటి అభివృద్ధి స్థాయిని చేరుకోలేవని నాకు అనిపిస్తోంది. అంతేకాదు చిన్న చిన్న ప్రాజెక్ట్స్‌లో కూడా తన బలహీనతని చూపించడానికి ఇష్టపడతాడు.
REST లేదా RPC ఎంపిక అనేది ప్రాజెక్ట్‌లో ఒక వ్యక్తి యొక్క ఇష్టపూర్వకమైన ఎంపిక కాదు. ఈ ఎంపిక తప్పనిసరిగా ప్రాజెక్ట్ యొక్క అవసరాలను తీర్చాలి. ప్రాజెక్ట్ REST నుండి నిజంగా చేయగలిగినదంతా పిండగలిగితే మరియు దానికి నిజంగా అది అవసరమైతే, REST ఒక గొప్ప ఎంపిక.
అయితే అన్ని REST లాభాలను పొందాలంటే, మీరు ప్రాజెక్ట్ కోసం డెవొప్‌లను త్వరగా స్కేల్ చేయడానికి ఇన్‌ఫ్రాస్ట్రక్చర్‌ని, ఇన్‌ఫ్రాస్ట్రక్చర్‌ని మేనేజ్ చేయడానికి అడ్మిన్‌లను, WEB సర్వీస్ యొక్క అన్ని లేయర్‌లను డిజైన్ చేయడానికి ఆర్కిటెక్ట్‌ని మరియు ప్రాజెక్ట్‌ను నియమించుకోవాలి. అదే సమయంలో, రోజుకు మూడు ప్యాక్ వనస్పతి విక్రయిస్తుంది ... నేను RPC, tk వద్ద ఆగుతాను. ఈ ప్రోటోకాల్ మరింత ప్రయోజనకరమైనది. దీనికి కాష్‌లు మరియు ఇన్‌ఫ్రాస్ట్రక్చర్ యొక్క ఆపరేషన్ గురించి లోతైన జ్ఞానం అవసరం లేదు, కానీ డెవలపర్‌కు అవసరమైన విధానాలకు సాధారణ మరియు అర్థమయ్యే కాల్‌లపై దృష్టి పెడుతుంది. వ్యాపారం ఆనందంగా సాగుతుంది.
RPC అభ్యర్థనలు మరింత విశ్వసనీయమైనవి ఎందుకంటే అవి ఒకే లావాదేవీలో బ్యాచ్ అభ్యర్థనలను అమలు చేయగలవు
RPC యొక్క ఈ ఆస్తి ఒక ఖచ్చితమైన ప్లస్, ఎందుకంటే డేటాబేస్ను స్థిరమైన స్థితిలో ఉంచడం సులభం. కానీ REST తో ఇది మరింత కష్టతరం అవుతుంది. వివిధ బ్యాకెండ్ నోడ్‌లకు అభ్యర్థనలు అస్థిరంగా రావచ్చు.
REST యొక్క ఈ "లోపం" పైన వివరించిన దాని ప్రయోజనం యొక్క రివర్స్ సైడ్ - అన్ని మౌలిక సదుపాయాల వనరులను సమర్ధవంతంగా ఉపయోగించగల సామర్థ్యం. ఇన్‌ఫ్రాస్ట్రక్చర్ పేలవంగా డిజైన్ చేయబడి ఉంటే, ఇంకా ఎక్కువగా ప్రాజెక్ట్ ఆర్కిటెక్చర్ మరియు డేటాబేస్ పేలవంగా రూపొందించబడి ఉంటే, ఇది నిజంగా పెద్ద బాధ.
అయితే బ్యాచ్ రిక్వెస్ట్‌లు కనిపించేంత నమ్మదగినవిగా ఉన్నాయా? ఒక కేసును పరిశీలిద్దాం: మేము వినియోగదారుని సృష్టిస్తాము, అతని ప్రొఫైల్‌ను కొంత వివరణతో మెరుగుపరచండి మరియు నమోదును పూర్తి చేయడానికి రహస్యంగా SMSని పంపుతాము. ఆ. ఒక బ్యాచ్ అభ్యర్థనలో మూడు కాల్స్.
ఒక రేఖాచిత్రాన్ని పరిశీలిద్దాం. ఇది అధిక లభ్యత అంశాలతో కూడిన మౌలిక సదుపాయాలను అందిస్తుంది. SMS గేట్‌వేలతో రెండు స్వతంత్ర కమ్యూనికేషన్ ఛానెల్‌లు ఉన్నాయి. కానీ... మనం ఏమి చూస్తాము? SMS పంపుతున్నప్పుడు, లోపం 503 సంభవిస్తుంది - సేవ తాత్కాలికంగా అందుబాటులో లేదు. ఎందుకంటే SMS పంపడం బ్యాచ్ అభ్యర్థనలో ప్యాక్ చేయబడింది, ఆపై మొత్తం అభ్యర్థనను వెనక్కి తీసుకోవాలి. DBMSలో చర్యలు రద్దు చేయబడ్డాయి. క్లయింట్ ఒక లోపాన్ని అందుకుంటారు.
తదుపరి ప్రయత్నం లాటరీ. అభ్యర్థన మళ్లీ అదే నోడ్‌పైకి వస్తుంది మరియు మళ్లీ ఎర్రర్‌ను అందిస్తుంది, లేదా మీరు అదృష్టవంతులు మరియు అది అమలు చేయబడుతుంది. కానీ ప్రధాన విషయం ఏమిటంటే, కనీసం ఒక్కసారైనా మా మౌలిక సదుపాయాలు ఇప్పటికే ఫలించలేదు. భారం ఉంది, కానీ లాభం లేదు.
సరే, అభ్యర్థనను పాక్షికంగా విజయవంతంగా అమలు చేయగలిగిన ఎంపిక గురించి మనం (!) టెన్షన్‌గా (!) ఆలోచించినట్లు ఊహించుకుందాం. మరియు మిగిలినవి, మేము కొంత సమయం విరామం తర్వాత మళ్లీ అమలు చేయడానికి ప్రయత్నిస్తాము (ఏమిటి? ముందు నిర్ణయిస్తుంది?). కానీ లాటరీ మాత్రం అలాగే ఉండిపోయింది. 50/50 అవకాశంతో SMS పంపాలనే అభ్యర్థన మళ్లీ విఫలమవుతుంది.
అంగీకరిస్తున్నారు, క్లయింట్ వైపు నుండి, సేవ మేము కోరుకున్నంత నమ్మదగినదిగా కనిపించడం లేదు ... కానీ 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 గురించి - మీరు చెయ్యగలరు. దాని స్పెసిఫికేషన్ తీసుకుంటే సరిపోతుంది. కాబట్టి మీకు అవసరమా ? లేదా ఇది ఇప్పటికీ గమ్మత్తైన REST ఉందా? నువ్వు నిర్ణయించు.
నేను మీ సమయాన్ని వృధా చేయలేదని నేను హృదయపూర్వకంగా ఆశిస్తున్నాను.
మూలం: www.habr.com