JSON-RPC? தந்திரமான ஓய்வு எடுக்கவும்

தலைப்பு ஆரோக்கியமான எதிர்வினையை ஏற்படுத்தியது என்று நான் நம்புகிறேன் - “சரி, இது மீண்டும் தொடங்கிவிட்டது...” ஆனால் உங்கள் கவனத்தை 5-10 நிமிடங்கள் ஈர்க்கிறேன், உங்கள் எதிர்பார்ப்புகளை ஏமாற்றாமல் இருக்க முயற்சிப்பேன்.

கட்டுரையின் அமைப்பு பின்வருமாறு இருக்கும்: ஒரே மாதிரியான அறிக்கை எடுக்கப்பட்டு, இந்த ஸ்டீரியோடைப்பின் தோற்றத்தின் "இயல்பு" வெளிப்படுத்தப்படுகிறது. உங்கள் திட்டங்களில் தரவு பரிமாற்ற முன்னுதாரணத்தை ஒரு புதிய கோணத்தில் பார்க்க இது உங்களை அனுமதிக்கும் என்று நம்புகிறேன்.

RPC என்றால் என்ன என்பது பற்றி தெளிவாக இருக்க, தரநிலையை பரிசீலிக்க நான் முன்மொழிகிறேன் JSON-RPC 2.0. REST உடன் எந்த தெளிவும் இல்லை. மேலும் அது இருக்கக்கூடாது. REST பற்றி நீங்கள் தெரிந்து கொள்ள வேண்டிய அனைத்தும் - இது பிரித்தறிய முடியாதது , HTTP.

RPC கோரிக்கைகள் வேகமாகவும் திறமையாகவும் இருக்கும், ஏனெனில் அவை தொகுதி கோரிக்கைகளைச் செய்ய உங்களை அனுமதிக்கின்றன.

புள்ளி என்னவென்றால், RPC இல் நீங்கள் ஒரு கோரிக்கையில் ஒரே நேரத்தில் பல நடைமுறைகளை அழைக்கலாம். எடுத்துக்காட்டாக, ஒரு பயனரை உருவாக்கவும், அவருக்கு அவதாரத்தைச் சேர்க்கவும், அதே கோரிக்கையில், சில தலைப்புகளுக்கு அவரைச் சந்தா செலுத்தவும். ஒரே ஒரு வேண்டுகோள், எவ்வளவு நன்மை!

உண்மையில், உங்களிடம் ஒரே ஒரு பின்முனை முனை இருந்தால், அது ஒரு தொகுதி கோரிக்கையுடன் வேகமாகத் தோன்றும். ஏனெனில் மூன்று 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

RPC ஐ
32
32
1
31
96

[*] சிறந்த நிலையில் (உள்ளூர் கேச் பயன்படுத்தப்பட்டால்) 1 கோரிக்கை (ஒன்று!), மோசமான நிலையில் 32 உள்வரும் கோரிக்கைகள்.

முதல் திட்டத்துடன் ஒப்பிடுகையில், வித்தியாசம் வேலைநிறுத்தம் செய்கிறது. இப்போது REST இன் நன்மை தெளிவாகிறது. ஆனால் அங்கு நிறுத்த வேண்டாம் என்று நான் பரிந்துரைக்கிறேன். வளர்ந்த உள்கட்டமைப்பில் CDN அடங்கும். பெரும்பாலும் இது DDoS மற்றும் DoS தாக்குதல்களை எதிர்கொள்ளும் சிக்கலையும் தீர்க்கிறது. நாங்கள் பெறுகிறோம்:

இங்குதான் RPC க்கு விஷயங்கள் மிகவும் மோசமாகின்றன. RPC ஆனது பணிச்சுமையை CDN க்கு வழங்க முடியாது. தாக்குதல்களை எதிர்கொள்ள நாம் அமைப்புகளை மட்டுமே நம்ப முடியும்.

இத்துடன் முடிக்க முடியுமா? மீண்டும், இல்லை. HTTP முறைகள், மேலே குறிப்பிட்டுள்ளபடி, அவற்றின் சொந்த "மேஜிக்" உள்ளது. GET முறை இணையத்தில் பரவலாகப் பயன்படுத்தப்படுவது காரணமின்றி இல்லை. இந்த முறையானது உள்ளடக்கத்தின் ஒரு பகுதியை அணுக முடியும் என்பதை நினைவில் கொள்ளவும், உங்கள் குறியீட்டிற்கு கட்டுப்பாட்டை மாற்றுவதற்கு முன்பு உள்கட்டமைப்பு கூறுகள் விளக்கக்கூடிய நிபந்தனைகளை அமைக்க முடியும், மற்றும் பல. இவை அனைத்தும் பெரிய அளவிலான கோரிக்கைகளை கையாளக்கூடிய நெகிழ்வான, நிர்வகிக்கக்கூடிய உள்கட்டமைப்புகளை உருவாக்க உங்களை அனுமதிக்கிறது. ஆனால் RPC இல் இந்த முறை... புறக்கணிக்கப்படுகிறது.

எனவே தொகுதி கோரிக்கைகள் (RPC) வேகமானவை என்ற கட்டுக்கதை ஏன் நீடித்தது? தனிப்பட்ட முறையில், பெரும்பாலான திட்டங்கள் REST அதன் வலிமையைக் காட்டக்கூடிய வளர்ச்சியின் அளவை எட்டவில்லை என்று எனக்குத் தோன்றுகிறது. மேலும், சிறிய திட்டங்களில், அவர் தனது பலவீனங்களைக் காட்ட மிகவும் தயாராக இருக்கிறார்.

REST அல்லது RPC இன் தேர்வு ஒரு திட்டத்தில் ஒரு தனிநபரின் விருப்பத் தேர்வு அல்ல. இந்தத் தேர்வு திட்டத்தின் தேவைகளைப் பூர்த்தி செய்ய வேண்டும். ஒரு ப்ராஜெக்ட் REST இலிருந்து உண்மையில் செய்யக்கூடிய அனைத்தையும் கசக்க முடிந்தால், அதற்கு உண்மையில் அது தேவை என்றால், REST ஒரு சிறந்த தேர்வாக இருக்கும்.

ஆனால், REST இன் அனைத்துப் பலன்களையும் பெறுவதற்கு, உள்கட்டமைப்பை விரைவாக அளவிடுவதற்கு டெவொப்ஸ் நிபுணர்களையும், உள்கட்டமைப்பை நிர்வகிக்க நிர்வாகிகளையும், WEB சேவையின் அனைத்து அடுக்குகளையும் வடிவமைக்க ஒரு கட்டிடக்கலைஞரையும் பணியமர்த்த வேண்டும். , அதே நேரத்தில், ஒரு நாளைக்கு மூன்று பேக் வெண்ணெயை விற்கிறார்... நான் RPC உடன் ஒட்டிக்கொள்வேன், ஏனென்றால்... இந்த நெறிமுறை மிகவும் பயனுள்ளது. தேக்ககங்கள் மற்றும் உள்கட்டமைப்பு எவ்வாறு செயல்படுகிறது என்பது பற்றிய ஆழமான அறிவு இதற்குத் தேவையில்லை, ஆனால் டெவலப்பருக்குத் தேவையான நடைமுறைகளுக்கு எளிமையான மற்றும் புரிந்துகொள்ளக்கூடிய அழைப்புகளில் கவனம் செலுத்தும். வியாபாரம் மகிழ்ச்சியாக இருக்கும்.

RPC கோரிக்கைகள் மிகவும் நம்பகமானவை, ஏனெனில் அவை ஒரு பரிவர்த்தனைக்குள் தொகுதி கோரிக்கைகளை செயல்படுத்த முடியும்

RPC இன் இந்த சொத்து ஒரு திட்டவட்டமான நன்மை, ஏனெனில் தரவுத்தளத்தை சீராக வைத்திருப்பது எளிது. ஆனால் REST உடன் அது மேலும் மேலும் சிக்கலானதாகிறது. கோரிக்கைகள் வெவ்வேறு பின்முனை முனைகளுக்கு முரணாக வரலாம்.

REST இன் இந்த "பாதகம்" என்பது மேலே விவரிக்கப்பட்ட அதன் நன்மையின் மறுபக்கமாகும் - அனைத்து உள்கட்டமைப்பு வளங்களையும் திறமையாகப் பயன்படுத்தும் திறன். உள்கட்டமைப்பு மோசமாக வடிவமைக்கப்பட்டிருந்தால், அதிலும் குறிப்பாக திட்டத்தின் கட்டமைப்பு மற்றும் தரவுத்தளம் மோசமாக வடிவமைக்கப்பட்டிருந்தால், இது உண்மையில் ஒரு பெரிய வேதனையாகும்.

ஆனால் தொகுதி கோரிக்கைகள் தோன்றும் அளவுக்கு நம்பகமானதா? ஒரு வழக்கைப் பார்ப்போம்: நாங்கள் ஒரு பயனரை உருவாக்கி, அவரது சுயவிவரத்தை சில விளக்கங்களுடன் மேம்படுத்தி, பதிவுசெய்தலை முடிக்க ரகசியத்துடன் SMS அனுப்புவோம். அந்த. ஒரு தொகுதி கோரிக்கையில் மூன்று அழைப்புகள்.

வரைபடத்தைப் பார்ப்போம். இது அதிக கிடைக்கும் கூறுகளைக் கொண்ட உள்கட்டமைப்பை வழங்குகிறது. எஸ்எம்எஸ் நுழைவாயில்களுடன் இரண்டு சுயாதீன தொடர்பு சேனல்கள் உள்ளன. ஆனால்... நாம் என்ன பார்க்கிறோம்? எஸ்எம்எஸ் அனுப்பும் போது, ​​பிழை 503 ஏற்படுகிறது - சேவை தற்காலிகமாக கிடைக்கவில்லை. ஏனெனில் SMS அனுப்புதல் ஒரு தொகுதி கோரிக்கையில் தொகுக்கப்பட்டுள்ளது, பின்னர் முழு கோரிக்கையும் திரும்பப் பெறப்பட வேண்டும். DBMS இல் செயல்கள் ரத்து செய்யப்பட்டுள்ளன. வாடிக்கையாளர் பிழையைப் பெறுகிறார்.

அடுத்த முயற்சி லாட்டரி. கோரிக்கை மீண்டும் மீண்டும் அதே முனையைத் தாக்கும், அல்லது நீங்கள் அதிர்ஷ்டசாலி மற்றும் அது செயல்படுத்தப்படும். ஆனால் முக்கிய விஷயம் என்னவென்றால், ஒரு முறையாவது எங்கள் உள்கட்டமைப்பு ஏற்கனவே வீணாக வேலை செய்துள்ளது. சுமை இருந்தது, ஆனால் லாபம் இல்லை.

சரி, கோரிக்கையை ஓரளவு வெற்றிகரமாக முடிக்கும்போது, ​​நாம் நம்மை நாமே சிரமப்படுத்திக் கொண்டு (!) விருப்பத்தின் மூலம் சிந்தித்தோம் என்று கற்பனை செய்து கொள்வோம். மேலும் சிறிது கால இடைவெளிக்குப் பிறகு மீதியை மீண்டும் முடிக்க முயற்சிப்போம் (எது? முன் முடிவு எடுக்குமா?). ஆனால் லாட்டரி அப்படியே இருந்தது. SMS அனுப்புவதற்கான கோரிக்கை மீண்டும் தோல்வியடைவதற்கு 50/50 வாய்ப்பு உள்ளது.

ஒப்புக்கொள்கிறேன், கிளையன்ட் தரப்பிலிருந்து, சேவையானது நாம் விரும்புவது போல் நம்பகமானதாகத் தெரியவில்லை... REST பற்றி என்ன?

REST ஆனது HTTP இன் மந்திரத்தை மீண்டும் பயன்படுத்துகிறது, ஆனால் இப்போது பதில் குறியீடுகளுடன். எஸ்எம்எஸ் கேட்வேயில் 503 பிழை ஏற்பட்டால், பின்தளத்தில் இந்த பிழையை பேலன்சருக்கு ஒளிபரப்புகிறது. சமநிலையாளர் இந்த பிழையைப் பெறுகிறார் மற்றும் கிளையண்டுடனான இணைப்பை உடைக்காமல், கோரிக்கையை மற்றொரு முனைக்கு அனுப்புகிறார், இது கோரிக்கையை வெற்றிகரமாக செயல்படுத்துகிறது. அந்த. வாடிக்கையாளர் எதிர்பார்த்த முடிவைப் பெறுகிறார், மேலும் உள்கட்டமைப்பு அதன் "அதிக அணுகக்கூடியது" என்ற உயர் தலைப்பை உறுதிப்படுத்துகிறது. பயனர் மகிழ்ச்சியாக இருக்கிறார்.

மீண்டும் அது எல்லாம் இல்லை. சமநிலையாளர் 503 இன் மறுமொழிக் குறியீட்டைப் பெறவில்லை. தரநிலையின்படி பதிலளிக்கும் போது, ​​இந்தக் குறியீட்டை “மீண்டும் முயற்சிக்கவும்” என்ற தலைப்புடன் வழங்குவது நல்லது. ஒரு குறிப்பிட்ட நேரத்திற்கு இந்த பாதையில் இந்த முனையை தொந்தரவு செய்வது மதிப்புக்குரியது அல்ல என்பதை தலைப்பு சமநிலையாளருக்கு தெளிவுபடுத்துகிறது. எஸ்எம்எஸ் அனுப்புவதற்கான அடுத்த கோரிக்கைகள் எஸ்எம்எஸ் கேட்வேயில் எந்த பிரச்சனையும் இல்லாத ஒரு முனைக்கு நேரடியாக அனுப்பப்படும்.

நாம் பார்க்க முடியும் என, JSON-RPC இன் நம்பகத்தன்மை மிகைப்படுத்தப்பட்டுள்ளது. உண்மையில், தரவுத்தளத்தில் நிலைத்தன்மையை ஒழுங்கமைப்பது எளிது. ஆனால் தியாகம், இந்த விஷயத்தில், ஒட்டுமொத்த அமைப்பின் நம்பகத்தன்மையாக இருக்கும்.

முடிவு பெரும்பாலும் முந்தையதைப் போன்றது. உள்கட்டமைப்பு எளிமையாக இருக்கும்போது, ​​JSON-RPC இன் வெளிப்படையான தன்மை நிச்சயமாக ஒரு ப்ளஸ் ஆகும். திட்டமானது அதிக சுமையுடன் அதிக கிடைக்கும் தன்மையை உள்ளடக்கியதாக இருந்தால், REST என்பது மிகவும் சிக்கலான தீர்வாக இருந்தாலும், மிகவும் சரியானதாக இருக்கும்.

RESTக்கான நுழைவு வரம்பு குறைவாக உள்ளது

மேலே உள்ள பகுப்பாய்வு, RPC பற்றி நிறுவப்பட்ட ஸ்டீரியோடைப்களை நீக்கி, REST இல் நுழைவதற்கான நுழைவு RPC ஐ விட சந்தேகத்திற்கு இடமின்றி அதிகமாக இருப்பதை தெளிவாகக் காட்டியது என்று நான் நினைக்கிறேன். HTTP எவ்வாறு செயல்படுகிறது என்பதைப் பற்றிய ஆழமான புரிதல் தேவை, அத்துடன் WEB திட்டங்களில் பயன்படுத்தக்கூடிய மற்றும் பயன்படுத்தப்பட வேண்டிய உள்கட்டமைப்பு கூறுகள் பற்றி போதுமான அறிவு இருக்க வேண்டியதன் அவசியமே இதற்குக் காரணம்.

REST எளிமையானதாக இருக்கும் என்று பலர் ஏன் நினைக்கிறார்கள்? எனது தனிப்பட்ட கருத்து என்னவென்றால், இந்த வெளிப்படையான எளிமை REST வெளிப்பாட்டிலிருந்து வருகிறது. அந்த. REST என்பது ஒரு நெறிமுறை அல்ல, ஒரு கருத்து... REST க்கு ஒரு தரநிலை இல்லை, சில வழிகாட்டுதல்கள் உள்ளன... REST என்பது HTTPயை விட சிக்கலானது அல்ல. வெளிப்படையான சுதந்திரம் மற்றும் அராஜகம் "சுதந்திர கலைஞர்களை" ஈர்க்கின்றன.

நிச்சயமாக, HTTP ஐ விட REST மிகவும் சிக்கலானது அல்ல. ஆனால் HTTP என்பது நன்கு வடிவமைக்கப்பட்ட நெறிமுறையாகும், இது பல தசாப்தங்களாக அதன் மதிப்பை நிரூபித்துள்ளது. HTTP பற்றிய ஆழமான புரிதல் இல்லை என்றால், REST ஐ தீர்மானிக்க முடியாது.

ஆனால் RPC பற்றி - உங்களால் முடியும். அதன் விவரக்குறிப்பை எடுத்துக் கொண்டால் போதும். எனவே உங்களுக்கு தேவையா முட்டாள் JSON-RPC? அல்லது இன்னும் தந்திரமான REST உள்ளதா? நீங்கள் முடிவு செய்யுங்கள்.

நான் உங்கள் நேரத்தை வீணடிக்கவில்லை என்று நான் உண்மையிலேயே நம்புகிறேன்.

ஆதாரம்: www.habr.com