JSON-RPC? አስቸጋሪውን REST ይውሰዱ

አርእስቱ ጤናማ ምላሽ እንዳስገኘ እርግጠኛ ነኝ - "ደህና, እንደገና ተጀመረ ..." ግን ለ 5-10 ደቂቃዎች ትኩረትዎን እንድይዝ እና የሚጠበቁትን ላለማሳሳት እሞክራለሁ.

የጽሁፉ አወቃቀሩ እንደሚከተለው ይሆናል፡- stereotypical መግለጫ ተወስዷል እና የዚህ የተዛባ አመለካከት መከሰት "ተፈጥሮ" ይገለጣል. ይህ በፕሮጀክቶችዎ ውስጥ ያለውን የመረጃ ልውውጥ ዘይቤ ምርጫን ከአዲስ አቅጣጫ እንዲመለከቱ እንደሚፈቅድልዎ ተስፋ አደርጋለሁ።

RPC ምን እንደሆነ ግልጽ ለማድረግ, ደረጃውን ከግምት ውስጥ ለማስገባት ሀሳብ አቀርባለሁ JSON-RPC 2.0. ከREST ጋር ምንም ግልጽነት የለም። መሆንም የለበትም። ስለ REST ማወቅ ያለብዎት ነገር ከሱ የማይለይ መሆኑን ነው። HTTP.

የ RPC ጥያቄዎች ፈጣን እና የበለጠ ቀልጣፋ ናቸው ምክንያቱም የቡድን ጥያቄዎችን እንዲያደርጉ ያስችሉዎታል።

ነጥቡ በ RPC ውስጥ በአንድ ጥያቄ ውስጥ ብዙ ሂደቶችን በአንድ ጊዜ መደወል ይቻላል. ለምሳሌ፣ ተጠቃሚ ይፍጠሩ፣ አምሳያ ያክሉለት፣ እና በተመሳሳይ ጥያቄ ለአንዳንድ ርዕሶች ደንበኝነት ይመዝገቡ። አንድ ጥያቄ ብቻ፣ እና ስንት ጥቅማጥቅሞች!

በእርግጥ፣ አንድ የጀርባ መስቀለኛ መንገድ ብቻ ካለህ፣ በቡድን ጥያቄ ፈጣን ይመስላል። ምክንያቱም ሶስት የ REST ጥያቄዎች ግንኙነቶችን ለመመስረት ከአንድ መስቀለኛ መንገድ ሶስት እጥፍ ተጨማሪ ሀብቶችን ይፈልጋሉ።

በREST ጉዳይ የመጀመሪያው ጥያቄ ተከታይ ጥያቄዎችን ለማድረግ የተጠቃሚ መታወቂያ መመለስ እንዳለበት ልብ ይበሉ። ይህም በአጠቃላይ ውጤቱ ላይ አሉታዊ ተጽዕኖ ያሳድራል.

ነገር ግን እንደዚህ አይነት መሠረተ ልማቶች ምናልባት በቤት ውስጥ መፍትሄዎች እና ኢንተርፕራይዝ ውስጥ ሊገኙ ይችላሉ. እንደ የመጨረሻ አማራጭ፣ በትንንሽ የዌብ ፕሮጄክቶች። ነገር ግን ሙሉ የWEB መፍትሄዎች እና ሃይሎድ ተብሎ የሚጠራውም ቢሆን እንደዚያ መገንባት የለባቸውም። የእነሱ መሠረተ ልማት ለከፍተኛ ተገኝነት እና ጭነት መስፈርቶችን ማሟላት አለበት. እና ምስሉ እየተቀየረ ነው.

አረንጓዴ የመሠረተ ልማት እንቅስቃሴ ሰርጦችን በተመሳሳይ ሁኔታ ላይ ምልክት ያደርጋል። አሁን RPC እንዴት እንደሚሠራ አስተውል። ጥያቄው መሠረተ ልማቱን የሚጠቀመው ከተመጣጣኝ እስከ ጀርባው በአንድ ትከሻ ላይ ብቻ ነው። በመጀመሪያው ጥያቄ REST አሁንም ቢሸነፍም፣ ነገር ግን መላውን መሠረተ ልማት ተጠቅሞ ሲያገኝ።

ወደ ስክሪፕቱ መግባት በቂ ነው ሁለት የማበልጸግ ጥያቄዎችን ሳይሆን፣ አምስት ወይም አስር... እና “አሁን ማን ያሸንፋል?” ለሚለው ጥያቄ መልስ። የማይታይ ይሆናል።

ችግሩን ሰፋ አድርገን እንድንመለከት ሀሳብ አቀርባለሁ። ስዕሉ የመሠረተ ልማት ቻናሎች እንዴት ጥቅም ላይ እንደሚውሉ ያሳያል, ነገር ግን መሠረተ ልማት በሰርጦች ብቻ የተገደበ አይደለም. መሸጎጫዎች በጣም የተጫኑ መሠረተ ልማቶች አስፈላጊ አካል ናቸው. አሁን አንዳንድ የተጠቃሚ ቅርስ እናገኝ። በተደጋጋሚ። 32 ጊዜ እንበል።

የከፍተኛ ጭነት መስፈርቶችን ለማሟላት በ RPC ላይ ያለው መሠረተ ልማት በሚያስደንቅ ሁኔታ "እንደገና" እንዴት እንደተገኘ ይመልከቱ። ነገሩ REST ከ RPC በተለየ የኤችቲቲፒ ፕሮቶኮሉን ሙሉ ኃይል ይጠቀማል። ከላይ ባለው ሥዕል ላይ ይህ ኃይል በጥያቄ ዘዴ - GET እውን ይሆናል ።

የኤችቲቲፒ ዘዴዎች፣ ከሌሎች ነገሮች በተጨማሪ፣ የመሸጎጫ ስልቶች አሏቸው። በሰነዱ ውስጥ ልታገኛቸው ትችላለህ HTTP. ለ RPC፣ የPOST ጥያቄዎች ጥቅም ላይ ይውላሉ፣ እነሱም እንደ አቅማቸው የማይቆጠሩ፣ ማለትም፣ ተመሳሳይ የPOST ጥያቄዎች ተደጋጋሚ መደጋገም የተለያዩ ውጤቶችን ሊመልስ ይችላል (ለምሳሌ፣ እያንዳንዱ አስተያየት ከተላከ በኋላ፣ የዚህ አስተያየት ሌላ ቅጂ ይመጣል) (ምንጩ).

ስለዚህ፣ RPC የመሠረተ ልማት መሸጎጫዎችን በብቃት መጠቀም አልቻለም። ይህ ለስላሳ መሸጎጫዎች "ማስመጣት" ወደመሆኑ እውነታ ይመራል. ስዕሉ በዚህ ሚና ውስጥ Redis ያሳያል. ለስላሳው መሸጎጫ በበኩሉ ከገንቢው ተጨማሪ የኮድ ንብርብር እና በሥነ ሕንፃ ውስጥ የሚታዩ ለውጦችን ይፈልጋል።

አሁን ምን ያህል ጥያቄዎች REST እና RPC "እንደወለዱ" በመሠረተ ልማት ውስጥ እናሰላለን?

ጥያቄዎች
የገቢ መልዕክት ሳጥን
ለመደገፍ
ወደ DBMS
ለስላሳ መሸጎጫ (ሬዲስ)
ጠቅላላ

ማረት
1 / 32 *
1
1
0
3 / 35

ፒ ፒ
32
32
1
31
96

[*] በጥሩ ሁኔታ (የአካባቢው መሸጎጫ ጥቅም ላይ ከዋለ) 1 ጥያቄ (አንድ!)፣ በከፋ 32 ገቢ ጥያቄዎች።

ከመጀመሪያው እቅድ ጋር ሲነጻጸር, ልዩነቱ በጣም አስደናቂ ነው. አሁን የ REST ጥቅም ግልጽ ይሆናል. ግን እዚያ እንዳላቆም ሀሳብ አቀርባለሁ። የተገነባው መሠረተ ልማት ሲዲኤንን ያካትታል። ብዙውን ጊዜ የ DDoS እና DoS ጥቃቶችን የመቃወም ጉዳይንም ይፈታል። እናገኛለን፡-

እዚህ ለ RPC ሁሉም ነገር በጣም አሳዛኝ ይሆናል. RPC በቀላሉ ስራን ወደ ሲዲኤን ጭነት ማስተላለፍ አልቻለም። ጥቃቶችን ለመቋቋም ስርዓቶችን ብቻ ነው ተስፋ ማድረግ የምንችለው።

እዚያ መጨረስ ይቻላል? እና እንደገና, አይሆንም. የኤችቲቲፒ ዘዴዎች, ከላይ እንደተጠቀሰው, የራሳቸው "አስማት" አላቸው. እና የ GET ዘዴ ሙሉ በሙሉ በኢንተርኔት ላይ ጥቅም ላይ የሚውለው በከንቱ አይደለም. ይህ ዘዴ አንድን የይዘት ክፍል መድረስ የሚችል፣ የመሠረተ ልማት አካላት ቁጥጥርን ወደ ኮድዎ ከማስተላለፉ በፊት ሊተረጉሟቸው የሚችሉ ሁኔታዎችን ማዘጋጀት የሚችል መሆኑን እና የመሳሰሉትን ልብ ይበሉ። ይህ ሁሉ በጣም ትልቅ ጥያቄዎችን ማስተናገድ የሚችሉ ተለዋዋጭ፣ ማቀናበር የሚችሉ መሠረተ ልማቶችን ለመፍጠር ያስችላል። እና በ RPC ይህ ዘዴ ... ችላ ይባላል.

ታዲያ ለምንድነው የባች ጥያቄዎች (RPC) በጣም ፈጣን ናቸው የሚለው አፈ ታሪክ በጣም ዘላቂ የሆነው? በግሌ፣ REST ጥንካሬውን ማሳየት ሲችል አብዛኞቹ ፕሮጀክቶች በቀላሉ እንዲህ ዓይነት የእድገት ደረጃ ላይ የማይደርሱ ይመስለኛል። ከዚህም በላይ በትንንሽ ፕሮጀክቶች ውስጥ ደካማነቱን ለማሳየት የበለጠ ፈቃደኛ ነው.

የ REST ወይም RPC ምርጫ በአንድ ፕሮጀክት ውስጥ የአንድ ግለሰብ በፈቃደኝነት ምርጫ አይደለም. ይህ ምርጫ የፕሮጀክቱን መስፈርቶች ማሟላት አለበት. ፕሮጀክቱ የሚቻለውን ሁሉ ከREST ማውጣት ከቻለ እና የሚያስፈልገው ከሆነ፣ REST ምርጥ ምርጫ ነው።

ነገር ግን ሁሉንም የ REST ትርፍ ለማግኘት ለፕሮጀክቱ በፍጥነት መሠረተ ልማቶችን ለመለካት ፣ አስተዳዳሪዎች መሠረተ ልማትን የሚያስተዳድሩ ፣ ሁሉንም የWEB አገልግሎት ንብርብሮችን ለመንደፍ አርክቴክት መቅጠር ያስፈልግዎታል ... እና ፕሮጀክቱ ፣ በ በተመሳሳይ ጊዜ, በቀን ሦስት ፓኮች ማርጋሪን ይሸጣል ... RPC ላይ አቆማለሁ, tk. ይህ ፕሮቶኮል የበለጠ ተጠቃሚ ነው። ስለ መሸጎጫዎች እና የመሠረተ ልማት አውታሮች ጥልቅ እውቀትን አይጠይቅም, ነገር ግን ገንቢውን ለሚፈልጉት ሂደቶች ቀላል እና ለመረዳት በሚቻሉ ጥሪዎች ላይ ያተኩራል. ንግድ ደስተኛ ይሆናል.

የ RPC ጥያቄዎች የበለጠ አስተማማኝ ናቸው ምክንያቱም የቡድን ጥያቄዎችን በአንድ ግብይት ውስጥ ማከናወን ይችላሉ።

ይህ የ RPC ንብረት የተወሰነ ተጨማሪ ነው, ምክንያቱም የውሂብ ጎታውን ወጥ በሆነ ሁኔታ ማቆየት ቀላል ነው። ነገር ግን በ REST የበለጠ እና የበለጠ አስቸጋሪ ይሆናል. ጥያቄዎች ወደ ተለያዩ የጀርባ አንጓዎች ወጥነት ሳይኖራቸው ሊመጡ ይችላሉ።

ይህ የ REST "እንከን" ከላይ የተገለፀው ጥቅም የተገላቢጦሽ ነው - ሁሉንም የመሠረተ ልማት ሀብቶች በብቃት የመጠቀም ችሎታ። መሠረተ ልማቱ በደንብ ያልተነደፈ ከሆነ እና እንዲያውም የፕሮጀክት አርክቴክቸር እና የመረጃ ቋቱ በተለይ በጥሩ ሁኔታ የተነደፈ ከሆነ ይህ በእውነት ትልቅ ህመም ነው።

ግን የምድብ ጥያቄዎች የሚመስሉትን ያህል አስተማማኝ ናቸው? አንድ ጉዳይ እናስብ፡ ተጠቃሚን እንፈጥራለን፣ ፕሮፋይሉን በተወሰነ መግለጫ እናበለጽጋለን እና ምዝገባውን ለማጠናቀቅ በሚስጥር ኤስኤምኤስ እንልካለን። እነዚያ። ሶስት ጥሪዎች በአንድ ባች ጥያቄ።

ስዕላዊ መግለጫን እናስብ። ከፍተኛ ተደራሽነት ያላቸው አካላት ያለው መሠረተ ልማት ያቀርባል. ከኤስኤምኤስ መግቢያ መንገዶች ጋር ሁለት ገለልተኛ የመገናኛ መንገዶች አሉ። ግን… ምን እናያለን? ኤስኤምኤስ ሲላክ ስህተት 503 ይከሰታል - አገልግሎቱ ለጊዜው አይገኝም። ምክንያቱም ኤስ ኤም ኤስ መላክ በቡድን ጥያቄ ውስጥ የታሸገ ነው ፣ ከዚያ አጠቃላይ ጥያቄው ወደ ኋላ መመለስ አለበት። በዲቢኤምኤስ ውስጥ ያሉ እርምጃዎች ተሰርዘዋል። ደንበኛው ስህተት ይቀበላል.

ቀጣዩ ሙከራ ሎተሪ ነው። ወይ ጥያቄው እንደገና በተመሳሳይ መስቀለኛ መንገድ ላይ ይወድቃል እና እንደገና ስህተት ይመልሳል፣ አለበለዚያ እድለኛ ይሆናሉ እና ይፈጸማል። ነገር ግን ዋናው ነገር ቢያንስ አንድ ጊዜ የእኛ መሠረተ ልማት በከንቱ ሰርቷል. ሸክም ነበር, ነገር ግን ምንም ትርፍ አልነበረም.

እሺ፣ ተወጥረን (!) እና ጥያቄው በከፊል በተሳካ ሁኔታ የሚፈፀምበትን አማራጭ አስበን እናስብ። እና የተቀረው ፣ ከተወሰነ ጊዜ በኋላ እንደገና ለማስፈፀም እንሞክራለን (ምን? ግንባርን ይወስናል?) ሎተሪው ግን እንደቀጠለ ነው። ኤስኤምኤስ ከ50/50 ዕድል ጋር የመላክ ጥያቄ እንደገና አይሳካም።

እስማማለሁ፣ ከደንበኛው በኩል፣ አገልግሎቱ የምንፈልገውን ያህል አስተማማኝ አይመስልም ... ግን ስለ RESTስ?

REST እንደገና የኤችቲቲፒ "ማጂክ" ይጠቀማል፣ አሁን ግን በምላሽ ኮዶች። በኤስኤምኤስ መግቢያው ላይ 503 ስህተት ሲፈጠር፣ የጀርባው ክፍል ይህንን ስህተት ወደ ሚዛኑ ያሰራጫል። ሚዛኑ ይህንን ስህተት የሚቀበለው እና ከደንበኛው ጋር ያለውን ግንኙነት ሳያቋርጥ ጥያቄውን ወደ ሌላ መስቀለኛ መንገድ ይልካል ፣ ይህም ጥያቄውን በተሳካ ሁኔታ ያስኬዳል። እነዚያ። ደንበኛው የሚጠበቀውን ውጤት ይቀበላል, እና መሠረተ ልማቱ "በከፍተኛ ተደራሽነት" የሚለውን ከፍተኛ ማዕረግ ያረጋግጣል. ተጠቃሚው ደስተኛ ነው።

እና እንደገና, ያ ብቻ አይደለም. ሚዛኑ የ 503 የምላሽ ኮድ ብቻ አልተቀበለም።በደረጃው መሰረት፣ ምላሽ በሚሰጥበት ጊዜ ይህንን ኮድ ከ"እንደገና ሞክር" አርዕስት ጋር ማቅረብ ተገቢ ነው። ርዕሱ በተጠቀሰው ጊዜ ውስጥ ይህ መስቀለኛ መንገድ በዚህ መንገድ ላይ መታወክ እንደሌለበት ለታዛኙ ግልጽ ያደርገዋል። እና ኤስኤምኤስ ለመላክ የሚቀጥሉት ጥያቄዎች በኤስኤምኤስ መግቢያ ላይ ምንም ችግር ወደሌለው መስቀለኛ መንገድ ወዲያውኑ ይላካሉ።

እንደምናየው፣ የ JSON-RPC አስተማማኝነት ከመጠን በላይ ነው። በእርግጥም በመረጃ ቋቱ ውስጥ ወጥነትን ማደራጀት ቀላል ነው። ነገር ግን ተጎጂው, በዚህ ሁኔታ, በአጠቃላይ የስርዓቱ አስተማማኝነት ይሆናል.

መደምደሚያው በአብዛኛው ከቀዳሚው ጋር ተመሳሳይ ነው. መሰረተ ልማቱ ቀላል ሲሆን የJSON-RPC ግልፅነት በእርግጠኝነት ተጨማሪ ነው። ፕሮጀክቱ ከከፍተኛ ጭነት ጋር ከፍተኛ አቅርቦትን የሚያካትት ከሆነ, REST የበለጠ ትክክለኛ, ምንም እንኳን ውስብስብ መፍትሄ ይመስላል.

REST የመግቢያ ገደብ ዝቅተኛ

እኔ እንደማስበው ከላይ ያለው ትንታኔ ስለ RPC የተመሰረቱትን አመለካከቶች በማቃለል ለ REST የመግቢያ ገደብ ከ RPC እንደሚበልጥ በግልፅ ያሳየ ይመስለኛል። ይህ የሆነበት ምክንያት የኤችቲቲፒ ስራን በጥልቀት በመረዳት እንዲሁም በWEB ፕሮጀክቶች ውስጥ ጥቅም ላይ ሊውሉ ስለሚችሉ እና ስለነባር የመሠረተ ልማት አካላት በቂ እውቀት እንዲኖረን ስለሚያስፈልግ ነው።

ታዲያ ለምን ብዙ ሰዎች REST ቀላል ይሆናል ብለው ያስባሉ? የእኔ የግል አስተያየት ይህ ግልጽነት ከ REST እራሱን ያሳያል። እነዚያ። REST ፕሮቶኮል አይደለም፣ ግን ጽንሰ-ሀሳብ… REST ደረጃ የለውም፣ አንዳንድ መመሪያዎች አሉ… REST ከኤችቲቲፒ የበለጠ የተወሳሰበ አይደለም። ነፃነት እና ስርዓት አልበኝነት መስሎ "ነጻ አርቲስቶችን" ይስባል።

ያለ ጥርጥር፣ REST ከኤችቲቲፒ የበለጠ የተወሳሰበ አይደለም። ነገር ግን ኤችቲቲፒ ራሱ ለብዙ አሥርተ ዓመታት ጠቃሚነቱን ያረጋገጠ በደንብ የታሰበበት ፕሮቶኮል ነው። ስለ HTTP ራሱ ጥልቅ ግንዛቤ ከሌለ፣ REST ሊፈረድበት አይችልም።

ግን ስለ RPC - ይችላሉ. መግለጫውን መውሰድ በቂ ነው. ስለዚህ ያስፈልግዎታል ደደብ JSON-RPC? ወይስ አሁንም REST አስቸጋሪ ነው? አንተ ወስን.

ጊዜህን እንዳላጠፋ ከልቤ ተስፋ አደርጋለሁ።

ምንጭ: hab.com