ሃይ ሀብር!

በኮሮና ቫይረስ ምክንያት ከሚከሰቱት ወቅታዊ ሁኔታዎች አንፃር በርካታ የኢንተርኔት አገልግሎቶች ጭነት መጨመር ጀምረዋል። ለምሳሌ, ከዩናይትድ ኪንግደም የችርቻሮ ሰንሰለቶች አንዱ የመስመር ላይ ማዘዣ ጣቢያውን በቀላሉ አቆመ።በቂ አቅም ስላልነበረ። እና የበለጠ ኃይለኛ መሳሪያዎችን በቀላሉ በመጨመር አገልጋይን ማፋጠን ሁልጊዜ አይቻልም ነገር ግን የደንበኛ ጥያቄዎች መስተናገድ አለባቸው (ወይም ወደ ተፎካካሪዎች ይሄዳሉ)።

በዚህ ጽሑፍ ውስጥ ፈጣን እና ስህተትን የሚቋቋም አገልግሎት ለመፍጠር ስለሚያስችሏቸው ስለ ታዋቂ ልምዶች በአጭሩ እናገራለሁ. ሆኖም ግን, ሊሆኑ ከሚችሉት የእድገት እቅዶች, አሁን ያሉትን ብቻ መርጫለሁ ለመጠቀም ቀላል. ለእያንዳንዱ እቃ፣ ዝግጁ የሆኑ ቤተ-መጻሕፍት አለዎት፣ ወይም ደግሞ የደመና መድረክን በመጠቀም ችግሩን ለመፍታት እድሉ አለዎት።

አግድም ልኬት

በጣም ቀላሉ እና በጣም የታወቀው ነጥብ. በተለምዶ, በጣም የተለመዱት ሁለት የጭነት ማከፋፈያ መርሃግብሮች አግድም እና ቀጥ ያለ ቅርፊት ናቸው. በመጀመሪያው ጉዳይ ሸክሙን በመካከላቸው በማከፋፈል አገልግሎቶች በትይዩ እንዲሰሩ ትፈቅዳላችሁ። በሁለተኛው ውስጥ የበለጠ ኃይለኛ አገልጋዮችን ታዝዘዋል ወይም ኮዱን ያመቻቻሉ።

ለምሳሌ፣ የአብስትራክት የደመና ፋይል ማከማቻን፣ ማለትም፣ አንዳንድ የOwnCloud፣ OneDrive እና የመሳሰሉትን አናሎግ እወስዳለሁ።

የእንደዚህ አይነት ወረዳ መደበኛ ምስል ከዚህ በታች ነው, ነገር ግን የስርዓቱን ውስብስብነት ብቻ ያሳያል. ደግሞም አገልግሎቶቹን እንደምንም ማመሳሰል አለብን። ተጠቃሚው ፋይሉን ከጡባዊው ላይ ቢያስቀምጥ እና ከስልክ ማየት ከፈለገ ምን ይከሰታል?

በአቀራረቦች መካከል ያለው ልዩነት: በአቀባዊ ቅርፊት ውስጥ, የአንጓዎችን ኃይል ለመጨመር ዝግጁ ነን, እና በአግድም አቀማመጥ, ጭነቱን ለማሰራጨት አዲስ አንጓዎችን ለመጨመር ዝግጁ ነን.

CQRS

የትዕዛዝ መጠይቅ ሃላፊነት መለያየት የተለያዩ ደንበኞች ከተለያዩ አገልግሎቶች ጋር እንዲገናኙ ብቻ ሳይሆን ተመሳሳይ የክስተት ዥረቶችን እንዲቀበሉ ስለሚያስችል በጣም አስፈላጊ ስርዓተ-ጥለት። ጥቅሞቹ ለቀላል አፕሊኬሽን ያን ያህል ግልፅ አይደሉም፣ ነገር ግን ስራ ለሚበዛበት አገልግሎት እጅግ በጣም አስፈላጊ (እና ቀላል) ነው። ዋናው ነገር፡ ገቢ እና ወጪ የውሂብ ፍሰቶች መቆራረጥ የለባቸውም። ማለትም፣ ጥያቄ መላክ እና ምላሽ መጠበቅ አትችልም፣ በምትኩ፣ ለአገልግሎት A ጥያቄ ልከሃል፣ ነገር ግን ከአገልግሎት B ምላሽ ተቀበል።

የዚህ አቀራረብ የመጀመሪያው ጉርሻ ረጅም ጥያቄን በሚፈጽምበት ጊዜ ግንኙነቱን የማቋረጥ ችሎታ ነው (በቃሉ ሰፊ ትርጉም)። ለምሳሌ፣ የበለጠ ወይም ያነሰ መደበኛ ቅደም ተከተል እንውሰድ፡-

1. ደንበኛው ለአገልጋዩ ጥያቄ ልኳል።
2. አገልጋዩ ረጅም የማስኬጃ ጊዜ ጀምሯል።
3. አገልጋዩ በውጤቱ ለደንበኛው ምላሽ ሰጥቷል።

በቁጥር 2 ላይ ግንኙነቱ ተቋርጧል (ወይንም አውታረ መረቡ እንደገና ተገናኝቷል ወይም ተጠቃሚው ወደ ሌላ ገጽ ሄዶ ግንኙነቱን አቋርጧል) እናስብ። በዚህ አጋጣሚ አገልጋዩ በትክክል ምን እንደተሰራ መረጃ ለተጠቃሚው ምላሽ ለመላክ አስቸጋሪ ይሆናል። CQRS ን በመጠቀም ፣ ቅደም ተከተል ትንሽ የተለየ ይሆናል

1. ደንበኛው ለዝማኔዎች ተመዝግቧል።
2. ደንበኛው ለአገልጋዩ ጥያቄ ልኳል።
3. አገልጋዩ "ጥያቄ ተቀባይነት አለው" ሲል መለሰ።
4. አገልጋዩ ከ "1" ነጥብ በሰርጡ በኩል በውጤቱ ምላሽ ሰጥቷል.

እንደምታየው, መርሃግብሩ ትንሽ የተወሳሰበ ነው. በተጨማሪም፣ ሊታወቅ የሚችል የጥያቄ-ምላሽ አቀራረብ እዚህ ጠፍቷል። ነገር ግን፣ እንደምታየው፣ ጥያቄን በማስተናገድ ላይ እያለ የግንኙነት መቋረጥ ወደ ስህተት አይመራም። ከዚህም በላይ በእውነቱ ተጠቃሚው ከበርካታ መሳሪያዎች (ለምሳሌ ከሞባይል ስልክ እና ከጡባዊ ተኮ) ከአገልግሎቱ ጋር የተገናኘ ከሆነ ምላሹ ወደ ሁለቱም መሳሪያዎች መምጣቱን ማረጋገጥ ይችላሉ.

የሚገርመው፣ ገቢ መልዕክቶችን የማስኬድ ኮድ አንድ አይነት ይሆናል (100% አይደለም) በደንበኛው በራሱ ተጽዕኖ ለደረሰባቸው ክስተቶች እና ለሌሎች ክስተቶች፣ ከሌሎች ደንበኞች የሚመጡትንም ጨምሮ።

ሆኖም ፣ በእውነቱ ፣ ባለ አንድ አቅጣጫ ፍሰት በተግባራዊ ዘይቤ (RX እና ተመሳሳይ በመጠቀም) ማስተናገድ በመቻሉ ተጨማሪ ጉርሻ እናገኛለን። እና ይህ ቀድሞውኑ ከባድ ፕላስ ነው ፣ ምክንያቱም በመሠረቱ አፕሊኬሽኑ ሙሉ በሙሉ ምላሽ እንዲሰጥ እና እንዲሁም ተግባራዊ አቀራረብን በመጠቀም። ለስብ ፕሮግራሞች ይህ የእድገት እና የድጋፍ ሀብቶችን በእጅጉ ሊያድን ይችላል.

ይህን አካሄድ ከአግድም ሚዛን ጋር ካዋህደን፣ እንደ ጉርሻ ለአንድ አገልጋይ ጥያቄዎችን የመላክ እና ከሌላ ምላሽ የምንቀበልበት አቅም እናገኛለን። ስለዚህ ደንበኛው ለእሱ ምቹ የሆነውን አገልግሎት መምረጥ ይችላል, እና በውስጡ ያለው ስርዓት አሁንም ክስተቶችን በትክክል ማካሄድ ይችላል.

የክስተት ምንጭ

እንደምታውቁት, የተከፋፈለው ስርዓት ዋና ዋና ባህሪያት አንዱ የጋራ ጊዜ, የጋራ ወሳኝ ክፍል አለመኖር ነው. ለአንድ ሂደት፣ ማመሳሰልን (በተመሳሳይ ሙቲክስ ላይ) ማድረግ ይችላሉ፣ በዚህ ውስጥ ማንም ሰው ይህን ኮድ እየፈፀመ እንዳልሆነ እርግጠኛ ነዎት። ሆኖም ፣ ይህ ለተሰራጨው ስርዓት አደገኛ ነው ፣ ምክንያቱም ከመጠን በላይ ስለሚፈልግ እና ሁሉንም የመለጠጥ ውበት ይገድላል - ሁሉም አካላት አሁንም አንድ ይጠብቃሉ።

ከዚህ ውስጥ አንድ አስፈላጊ እውነታ እናገኛለን - ፈጣን ስርጭት ስርዓት ሊመሳሰል አይችልም, ምክንያቱም ከዚያ እኛ አፈፃፀሙን እንቀንሳለን. በሌላ በኩል, ብዙውን ጊዜ በንጥረ ነገሮች መካከል የተወሰነ ወጥነት ያስፈልገናል. እና ለዚህም አቀራረቡን ከ ጋር መጠቀም ይችላሉ ውሎ አድሮ ወጥነት, ከመጨረሻው ዝመና በኋላ ("በመጨረሻ") ለተወሰነ ጊዜ ምንም የውሂብ ለውጦች ከሌሉ ሁሉም ጥያቄዎች የመጨረሻውን የተሻሻለውን እሴት እንደሚመልሱ የተረጋገጠ ነው.

ለጥንታዊ የውሂብ ጎታዎች ብዙ ጊዜ ጥቅም ላይ እንደሚውል መረዳት አስፈላጊ ነው። ጠንካራ ወጥነት, እያንዳንዱ መስቀለኛ መንገድ ተመሳሳይ መረጃ ሲኖረው (ይህ ብዙውን ጊዜ ግብይቱ የተቋቋመው ሁለተኛው አገልጋይ ምላሽ ከሰጠ በኋላ ነው ተብሎ በሚታሰብበት ሁኔታ ውስጥ ይገኛል)። በመነጠል ደረጃዎች ምክንያት አንዳንድ መዝናኛዎች እዚህ አሉ ፣ ግን አጠቃላይ ሀሳቡ አንድ ነው - ሙሉ በሙሉ በተስማማ ዓለም ውስጥ መኖር ይችላሉ።

ሆኖም ወደ መጀመሪያው ተግባር እንመለስ። የስርአቱ ክፍል አብሮ ሊገነባ የሚችል ከሆነ ውሎ አድሮ ወጥነት, ከዚያ የሚከተለውን ንድፍ መገንባት እንችላለን.

የዚህ ዘዴ ጠቃሚ ባህሪዎች-

• እያንዳንዱ ገቢ ጥያቄ በአንድ ወረፋ ውስጥ ይደረጋል።
• ጥያቄን በሚሰራበት ጊዜ አገልግሎቱ በሌሎች ወረፋዎች ላይ ስራዎችን ሊያስቀምጥ ይችላል።
• እያንዳንዱ መጪ ክስተት መለያ አለው (ይህም ለመቀነስ አስፈላጊ ነው)።
• ወረፋው በርዕዮተ ዓለም የሚሰራው በ"append only" እቅድ መሰረት ነው። ኤለመንቶችን ከእሱ ማስወገድ ወይም እንደገና ማስተካከል አይችሉም.
• ወረፋው የሚሰራው በ FIFO እቅድ መሰረት ነው (ስለ ታውቶሎጂ ይቅርታ)። ትይዩ ማስፈጸሚያ ማድረግ ከፈለጉ በአንድ ደረጃ እቃዎችን ወደ ተለያዩ ወረፋዎች ማንቀሳቀስ አለብዎት።

የኦንላይን ፋይል ማከማቻ ጉዳይ እያጤንን መሆኑን ላስታውስህ። በዚህ ሁኔታ ስርዓቱ እንደዚህ ያለ ነገር ይመስላል-

በሥዕላዊ መግለጫው ውስጥ ያሉት አገልግሎቶች የግድ የተለየ አገልጋይ ማለት አለመሆኑ አስፈላጊ ነው። ሂደቱ እንኳን አንድ አይነት ሊሆን ይችላል. ሌላው አስፈላጊ ነገር: በርዕዮተ ዓለም, እነዚህ ነገሮች በአግድም አቀማመጥ በቀላሉ ሊተገበሩ በሚችሉበት መንገድ ይለያያሉ.

እና ለሁለት ተጠቃሚዎች ስዕሉ እንደዚህ ይመስላል (ለተለያዩ ተጠቃሚዎች የታቀዱ አገልግሎቶች በተለያዩ ቀለሞች ይገለጣሉ)

ከእንደዚህ አይነት ጥምረት ጉርሻዎች

• የመረጃ ማቀነባበሪያ አገልግሎቶች ተለያይተዋል። ወረፋዎቹም ተለያይተዋል። የስርዓቱን ፍሰት መጨመር ካስፈለገን ተጨማሪ አገልግሎቶችን በብዙ አገልጋዮች ላይ ማስጀመር ብቻ ያስፈልገናል።
• ከአንድ ተጠቃሚ መረጃ ስንቀበል, ውሂቡ ሙሉ በሙሉ እስኪቀመጥ ድረስ መጠበቅ የለብንም. በተቃራኒው "እሺ" ብለን መመለስ ብቻ እና ከዚያም ቀስ በቀስ መስራት እንጀምራለን. በተመሳሳይ ጊዜ ወረፋው ጫፎችን ያስተካክላል ፣ ምክንያቱም አዲስ ነገር ማከል በፍጥነት ስለሚከሰት እና ተጠቃሚው በጠቅላላው ዑደት ውስጥ ሙሉ ማለፍን መጠበቅ አያስፈልገውም።
• እንደ ምሳሌ፣ ተመሳሳይ ፋይሎችን ለማዋሃድ የሚሞክር የማባዛት አገልግሎት አክያለሁ። በ 1% ጉዳዮች ውስጥ ለረጅም ጊዜ የሚሰራ ከሆነ, ደንበኛው እምብዛም አያስተውለውም (ከላይ ይመልከቱ), ይህም ትልቅ ተጨማሪ ነው, ምክንያቱም እኛ ከአሁን በኋላ XNUMX% ፍጥነት እና አስተማማኝ መሆን አይጠበቅብንም.

ሆኖም ፣ ጉዳቶቹ ወዲያውኑ ይታያሉ-

• የእኛ ስርዓት ጥብቅ ወጥነት አጥቷል. ይህ ማለት ለምሳሌ ለተለያዩ አገልግሎቶች ከተመዘገቡ በንድፈ ሀሳብ የተለየ ሁኔታ ማግኘት ይችላሉ (ከአገልግሎቶቹ አንዱ ከውስጥ ወረፋ ማሳወቂያ ለመቀበል ጊዜ ላይኖረው ይችላል)። እንደ ሌላ ውጤት, ስርዓቱ አሁን የጋራ ጊዜ የለውም. ማለትም በአገልጋዮች መካከል ያሉት ሰዓቶች የማይመሳሰሉ ሊሆኑ ስለሚችሉ ለምሳሌ ሁሉንም ክስተቶች በመድረሻ ሰዓት መደርደር አይቻልም (በተጨማሪም በሁለት አገልጋዮች ላይ ተመሳሳይ ጊዜ ዩቶፒያ ነው)።
• ምንም ክስተቶች አሁን በቀላሉ ወደ ኋላ መመለስ አይችሉም (በመረጃ ቋት እንደሚደረገው)። በምትኩ፣ አዲስ ክስተት ማከል አለብህ - የማካካሻ ክስተት, ይህም የመጨረሻውን ሁኔታ ወደ አስፈላጊው ይለውጠዋል. ከተመሳሳዩ አካባቢ እንደ ምሳሌ፡ ታሪክን እንደገና ሳይጽፉ (በአንዳንድ ሁኔታዎች መጥፎ ነው) በ git ውስጥ መፈጸም አይችሉም ነገር ግን ልዩ ማድረግ ይችላሉ. የድጋሚ ቁርጠኝነት, ይህም በመሠረቱ የድሮውን ሁኔታ ብቻ ይመልሳል. ሆኖም፣ ሁለቱም የተሳሳቱ ድርጊቶች እና መልሶ ማግኘታቸው በታሪክ ውስጥ ይቀራሉ።
• የዳታ መርሐ ግብሩ ከልቀት ወደ ልቀት ሊለወጥ ይችላል፣ ነገር ግን የቆዩ ክስተቶች ከአሁን በኋላ ወደ አዲሱ መመዘኛ መዘመን አይችሉም (ክስተቶች በመርህ ደረጃ ሊለወጡ ስለማይችሉ)።

እንደምታየው፣ Event Sourcing ከCQRS ጋር በደንብ ይሰራል። በተጨማሪም ፣ ቀልጣፋ እና ምቹ ወረፋ ያለው ስርዓት መተግበር ፣ ግን የውሂብ ፍሰቶችን ሳይለይ ፣ ቀድሞውኑ በራሱ ከባድ ነው ፣ ምክንያቱም የወረፋዎቹን አጠቃላይ አወንታዊ ተፅእኖ የሚያስወግዱ የማመሳሰል ነጥቦችን ማከል አለብዎት። ሁለቱንም አቀራረቦች በአንድ ጊዜ መተግበር, የፕሮግራሙን ኮድ በትንሹ ማስተካከል አስፈላጊ ነው. በእኛ ሁኔታ፣ ፋይል ወደ አገልጋዩ በሚልኩበት ጊዜ ምላሹ የሚመጣው “እሺ” ብቻ ነው፣ ይህ ማለት ግን “ፋይሉን የመጨመር ተግባር ተቀምጧል” ማለት ነው። በመደበኛነት, ይህ ማለት ውሂቡ ቀድሞውኑ በሌሎች መሳሪያዎች ላይ ይገኛል ማለት አይደለም (ለምሳሌ, የማባዛት አገልግሎት ጠቋሚውን እንደገና ሊገነባ ይችላል). ነገር ግን፣ ከተወሰነ ጊዜ በኋላ ደንበኛው “ፋይል X ተቀምጧል” በሚለው ዘይቤ ማሳወቂያ ይደርሰዋል።

ከዚህ የተነሳ:

• የፋይል መላኪያ ሁኔታዎች ቁጥር እየጨመረ ነው፡ ከሚታወቀው “ፋይል ተልኳል” ይልቅ ሁለት እናገኛለን፡ “ፋይሉ በአገልጋዩ ላይ ወደ ወረፋው ተጨምሯል” እና “ፋይሉ በማከማቻ ውስጥ ተቀምጧል። የኋለኛው ማለት ሌሎች መሳሪያዎች ቀድሞውኑ ፋይሉን መቀበል ሊጀምሩ ይችላሉ (የተስተካከሉ ወረፋዎች በተለያየ ፍጥነት ይሠራሉ).
• የማስረከቢያ መረጃው አሁን በተለያዩ ቻናሎች የሚመጣ በመሆኑ፣ የፋይሉን ሂደት ሁኔታ ለመቀበል መፍትሄዎችን ማምጣት አለብን። በዚህ ምክንያት፡ ከጥንታዊው የጥያቄ-ምላሽ በተቃራኒ ፋይሉን በሚሰራበት ጊዜ ደንበኛው እንደገና መጀመር ይቻላል፣ ነገር ግን የዚህ ሂደት ሁኔታ ራሱ ትክክል ይሆናል። ከዚህም በላይ, ይህ እቃ ከሳጥኑ ውስጥ, በመሠረቱ, ይሠራል. በውጤቱም: አሁን ውድቀቶችን የበለጠ ታጋሽ ነን.

ሹልት

ከላይ እንደተገለፀው የክስተት ምንጭ ስርዓቶች ጥብቅ ወጥነት የላቸውም. ይህ ማለት ብዙ ማከማቻዎችን ያለ ምንም ማመሳሰል መጠቀም እንችላለን ማለት ነው። ወደ ችግራችን ስንቃረብ፡-

• ፋይሎችን በአይነት ይለያዩ. ለምሳሌ ስዕሎች/ቪዲዮዎች ዲኮድ ሊደረጉ እና የበለጠ ቀልጣፋ ቅርጸት ሊመረጥ ይችላል።
• መለያዎችን በአገር ይለዩ። በብዙ ህጎች ምክንያት, ይህ ሊያስፈልግ ይችላል, ነገር ግን ይህ የስነ-ህንፃ እቅድ እንዲህ ዓይነቱን እድል በራስ-ሰር ይሰጣል

ውሂብን ከአንድ ማከማቻ ወደ ሌላ ማስተላለፍ ከፈለጉ መደበኛ መንገዶች ከአሁን በኋላ በቂ አይደሉም። በሚያሳዝን ሁኔታ, በዚህ ሁኔታ, ወረፋውን ማቆም, ፍልሰትን ማድረግ እና ከዚያ መጀመር ያስፈልግዎታል. በአጠቃላይ ሁኔታ, ውሂብ "በበረራ" ሊተላለፍ አይችልም, ነገር ግን የዝግጅቱ ወረፋ ሙሉ በሙሉ ከተከማቸ እና የቀደሙት የማከማቻ ግዛቶች ቅጽበተ-ፎቶዎች ካለዎት, ክስተቶቹን በሚከተለው መልኩ እንደገና ማጫወት እንችላለን.

• በክስተት ምንጭ ውስጥ፣ እያንዳንዱ ክስተት የራሱ መለያ አለው (በሀሳብ ደረጃ፣ የማይቀንስ)። ይህ ማለት ወደ ማከማቻው መስክ ማከል እንችላለን - የመጨረሻው የተቀነባበረ ኤለመንት መታወቂያ።
• ሁሉም ክስተቶች ለብዙ ገለልተኛ ማከማቻዎች እንዲከናወኑ ወረፋውን እናባዛለን (የመጀመሪያው መረጃው አስቀድሞ የተከማቸበት ነው ፣ ሁለተኛው ደግሞ አዲስ ነው ፣ ግን አሁንም ባዶ ነው)። ሁለተኛው ወረፋ በእርግጥ ገና እየተሰራ አይደለም።
• ሁለተኛውን ወረፋ እንጀምራለን (ማለትም, ክስተቶችን እንደገና ማጫወት እንጀምራለን).
• አዲሱ ወረፋ በአንፃራዊነት ባዶ ሲሆን (ይህም አንድን ንጥረ ነገር በመጨመር እና በማውጣት መካከል ያለው አማካይ የጊዜ ልዩነት ተቀባይነት ያለው ነው) አንባቢዎችን ወደ አዲሱ ማከማቻ መቀየር መጀመር ይችላሉ።

እንደምታየው፣ በስርዓታችን ውስጥ ጥብቅ ወጥነት አልነበረንም፣ እና አሁንም የለንም። ውሎ አድሮ ቋሚነት ብቻ ነው, ማለትም, ክስተቶች በተመሳሳይ ቅደም ተከተል (ነገር ግን ከተለያዩ መዘግየቶች ጋር) እንዲከናወኑ ዋስትና ይሰጣል. እና ይህንን በመጠቀም ስርዓቱን ወደ ሌላኛው የአለም ክፍል ሳናቆም በአንፃራዊነት በቀላሉ መረጃን ማስተላለፍ እንችላለን።

ስለዚህ፣ ስለ ፋይሎች የመስመር ላይ ማከማቻ ምሳሌያችንን በመቀጠል፣ እንዲህ ያለው አርክቴክቸር አስቀድሞ ብዙ ጉርሻዎችን ይሰጠናል፡-

• በተለዋዋጭ መንገድ ዕቃዎችን ወደ ተጠቃሚዎች መቅረብ እንችላለን። በዚህ መንገድ የአገልግሎቱን ጥራት ማሻሻል ይችላሉ.
• አንዳንድ መረጃዎችን በኩባንያዎች ውስጥ ልናከማች እንችላለን። ለምሳሌ፣ የኢንተርፕራይዝ ተጠቃሚዎች ብዙ ጊዜ ውሂባቸውን በተቆጣጠሩት የመረጃ ማእከላት (የውሂብ ፍንጣቂዎችን ለማስወገድ) እንዲቀመጡ ይፈልጋሉ። በሸርዲንግ ይህንን በቀላሉ መደገፍ እንችላለን። እና ደንበኛው ተስማሚ ደመና ካለው (ለምሳሌ ፣ Azure ራስን አስተናግዷል).
• እና በጣም አስፈላጊው ነገር ይህን ማድረግ የለብንም. ከሁሉም በኋላ፣ ለመጀመር፣ ለሁሉም መለያዎች አንድ ማከማቻ (በፍጥነት መሥራት ለመጀመር) በጣም ደስተኞች እንሆናለን። እና የዚህ ስርዓት ቁልፍ ባህሪ ሊሰፋ የሚችል ቢሆንም በመነሻ ደረጃው በጣም ቀላል ነው. ከአንድ ሚሊዮን የተለየ ገለልተኛ ወረፋ ወዘተ ጋር የሚሰራ ኮድ ወዲያውኑ መጻፍ አያስፈልግም። አስፈላጊ ከሆነ, ይህ ወደፊት ሊደረግ ይችላል.

የማይንቀሳቀስ ይዘት ማስተናገድ

ይህ ነጥብ በጣም ግልጽ ሊመስል ይችላል, ነገር ግን ብዙ ወይም ያነሰ መደበኛ ለተጫነ መተግበሪያ አሁንም አስፈላጊ ነው. ዋናው ነገር ቀላል ነው፡ ሁሉም የማይንቀሳቀሱ ይዘቶች የሚከፋፈሉት አፕሊኬሽኑ ካለበት ተመሳሳይ አገልጋይ አይደለም፣ ነገር ግን ለዚህ ተግባር ከተወሰኑ ልዩዎች ነው። በውጤቱም, እነዚህ ስራዎች በፍጥነት ይከናወናሉ (ሁኔታዊ nginx ፋይሎችን በፍጥነት እና ከጃቫ አገልጋይ ባነሰ ዋጋ ያገለግላል). በተጨማሪም የሲዲኤን አርክቴክቸር (የይዘት ማስተላለፊያ አውታረ መረብ) ፋይሎቻችንን ከዋና ተጠቃሚዎች አጠገብ እንድናገኝ ያስችለናል, ይህም ከአገልግሎቱ ጋር አብሮ ለመስራት ምቾት ላይ አዎንታዊ ተጽእኖ ይኖረዋል.

በጣም ቀላሉ እና በጣም መደበኛው የማይንቀሳቀስ ይዘት ምሳሌ ለድር ጣቢያ የስክሪፕት እና ምስሎች ስብስብ ነው። ሁሉም ነገር ከእነሱ ጋር ቀላል ነው - አስቀድመው ይታወቃሉ, ከዚያም ማህደሩ ወደ ሲዲኤን አገልጋዮች ይሰቀላል, ከየትኛውም ለዋና ተጠቃሚዎች ይሰራጫሉ.

ሆኖም፣ እንደ እውነቱ ከሆነ፣ ለስታቲክ ይዘት፣ ከላምዳ አርክቴክቸር ጋር ተመሳሳይ የሆነ አቀራረብ መጠቀም ይችላሉ። ፋይሎችን ለተጠቃሚዎች ማሰራጨት ወደምንፈልግበት ወደ ተግባራችን (የመስመር ላይ ፋይል ማከማቻ) እንመለስ። ቀላሉ መፍትሔ ለእያንዳንዱ ተጠቃሚ ጥያቄ ሁሉንም አስፈላጊ ቼኮች (ፈቃድ, ወዘተ) የሚያደርግ አገልግሎት መፍጠር እና ከዚያም ፋይሉን በቀጥታ ከማከማቻችን ማውረድ ነው. የዚህ አቀራረብ ዋነኛው ኪሳራ የማይንቀሳቀስ ይዘት (እና የተወሰነ ክለሳ ያለው ፋይል በእውነቱ የማይንቀሳቀስ ይዘት ነው) የንግድ አመክንዮ በያዘው አገልጋይ መሰራጨቱ ነው። በምትኩ፣ የሚከተለውን ንድፍ መስራት ትችላለህ፡-

• አገልጋዩ የማውረጃ URL ያቀርባል። ከፋይል_ኢድ + ቁልፍ ሊሆን ይችላል፣ ቁልፉ ሚኒ-ዲጂታል ፊርማ ሲሆን ለሚቀጥሉት XNUMX ሰዓታት ሀብቱን የማግኘት መብት የሚሰጥ ነው።
• ፋይሉ ከሚከተሉት አማራጮች ጋር በቀላል nginx ይሰራጫል፡
  • የይዘት መሸጎጫ። ይህ አገልግሎት በተለየ አገልጋይ ላይ ሊቀመጥ ስለሚችል, ሁሉንም የቅርብ ጊዜ የወረዱ ፋይሎችን በዲስክ ላይ የማከማቸት ችሎታ ለወደፊቱ እራሳችንን አስቀምጠናል.
  • ግንኙነት በሚፈጠርበት ጊዜ ቁልፉን በመፈተሽ ላይ
• አማራጭ፡ የይዘት ሂደትን ማሰራጨት። ለምሳሌ፣ በአገልግሎቱ ውስጥ ያሉትን ሁሉንም ፋይሎች ከጨመቅን፣ በዚህ ሞጁል ውስጥ በቀጥታ ዚፕ መክፈት እንችላለን። በውጤቱም፡ የአይኦ ስራዎች የሚከናወኑት በተያዙበት ነው። በጃቫ ውስጥ ያለ ማህደር በቀላሉ ብዙ ተጨማሪ ማህደረ ትውስታን ይመድባል፣ ነገር ግን አገልግሎቱን ከቢዝነስ አመክንዮ ጋር ወደ Rust/C++ ሁኔታ እንደገና መፃፍም ውጤታማ ላይሆን ይችላል። በእኛ ሁኔታ ፣ የተለያዩ ሂደቶች (ወይም አገልግሎቶች) ጥቅም ላይ ይውላሉ ፣ እና ስለሆነም የንግድ ሥራ አመክንዮ እና IO ኦፕሬሽኖችን በትክክል መለየት እንችላለን ።

ይህ እቅድ የማይንቀሳቀስ ይዘትን ከማሰራጨት ጋር በጣም ተመሳሳይ አይደለም (ሙሉውን የማይንቀሳቀስ ጥቅል የሆነ ቦታ ስለማንሰቀል) ነገር ግን እንደ እውነቱ ከሆነ ይህ አካሄድ የማይለወጥ ውሂብን ከማሰራጨት ጋር የተያያዘ ነው። ከዚህም በላይ ይህ እቅድ ይዘቱ በቀላሉ የማይለዋወጥ ነገር ግን የማይለወጡ እና የማይሰረዙ ብሎኮች (ሊጨመሩ ቢችሉም) ሊወከሉ በሚችሉ ሌሎች ጉዳዮች ላይ ሊጠቃለል ይችላል።

እንደ ሌላ ምሳሌ (ለማጠናከሪያ): ከጄንኪንስ/TeamCity ጋር አብረው ከሰሩ ሁለቱም መፍትሄዎች በጃቫ እንደተፃፉ ያውቃሉ። ሁለቱም ሁለቱንም የግንባታ ኦርኬስትራ እና የይዘት አስተዳደርን የሚያስተናግድ የጃቫ ሂደት ናቸው። በተለይም ሁለቱም እንደ “ፋይል/አቃፊን ከአገልጋዩ ማስተላለፍ” ያሉ ተግባራት አሏቸው። እንደ ምሳሌ: ቅርሶችን መስጠት, የምንጭ ኮድ ማስተላለፍ (ወኪሉ በቀጥታ ከማከማቻው ውስጥ ኮዱን ሲያወርድ, ነገር ግን አገልጋዩ ለእሱ ሲያደርግ), የምዝግብ ማስታወሻዎች መድረስ. እነዚህ ሁሉ ተግባራት በ IO ጭነት ይለያያሉ. ያም ማለት ውስብስብ የንግድ ሥራ አመክንዮ ኃላፊነት ያለው አገልጋይ በተመሳሳይ ጊዜ ትላልቅ የውሂብ ፍሰቶችን በራሱ መግፋት መቻል አለበት ። እና በጣም የሚያስደንቀው ነገር እንዲህ ዓይነቱ ክዋኔ ልክ በተመሳሳዩ እቅድ መሰረት ወደ ተመሳሳይ nginx ሊሰጥ ይችላል (የውሂብ ቁልፉ በጥያቄው ላይ መጨመር አለበት ካልሆነ በስተቀር)።

ሆኖም ወደ ስርዓታችን ከተመለስን ተመሳሳይ ንድፍ እናገኛለን፡-

እንደሚመለከቱት, ስርዓቱ በጣም የተወሳሰበ ሆኗል. አሁን ፋይሎችን በአገር ውስጥ የሚያከማች አነስተኛ ሂደት ብቻ አይደለም። አሁን የሚፈለገው ቀላሉ ድጋፍ፣ የኤፒአይ ስሪት ቁጥጥር፣ ወዘተ አይደለም። ስለዚህ ፣ ሁሉም ሥዕላዊ መግለጫዎች ከተዘጋጁ በኋላ ፣ የተጋላጭነት ዋጋ ዋጋ ያለው መሆኑን በዝርዝር መገምገም የተሻለ ነው። ነገር ግን ስርዓቱን ማስፋፋት መቻል ከፈለጉ (ከዚህ የበለጠ ቁጥር ካለው ተጠቃሚዎች ጋር አብሮ መስራትን ጨምሮ) ወደ ተመሳሳይ መፍትሄዎች መሄድ ይኖርብዎታል። ነገር ግን ፣ በውጤቱም ፣ ስርዓቱ ለጭነት ጭነት በሥነ-ሕንፃ ዝግጁ ነው (ሁሉም አካላት ማለት ይቻላል ለአግድም ልኬት ሊዘጋ ይችላል)። ስርዓቱን ሳያቆም ሊዘመን ይችላል (በቀላሉ አንዳንድ ስራዎች በትንሹ ይቀንሳሉ)።

ገና መጀመሪያ ላይ እንዳልኩት፣ አሁን በርካታ የኢንተርኔት አገልግሎቶች ጭነት መጨመር ጀምረዋል። እና አንዳንዶቹ በትክክል መስራት ማቆም ጀመሩ. እንደ እውነቱ ከሆነ, ንግዱ ገንዘብ ማግኘት በነበረበት ጊዜ ስርዓቱ በትክክል አልተሳካም. ይህም ማለት፣ የዘገየ አቅርቦትን ሳይሆን፣ ለደንበኞች “ለመጪዎቹ ወራት የማድረስ እቅድ ያውጡ” የሚል ሃሳብ ከማቅረብ ይልቅ ስርዓቱ በቀላሉ “ወደ ተፎካካሪዎቻችሁ ሂዱ” ይላል። እንደ እውነቱ ከሆነ ይህ ዝቅተኛ ምርታማነት ዋጋ ነው: ኪሳራዎች በትክክል የሚፈጠሩት ትርፍ ከፍተኛ በሚሆንበት ጊዜ ነው.

መደምደሚያ

እነዚህ ሁሉ ዘዴዎች ቀደም ብለው ይታወቁ ነበር. ተመሳሳዩ ቪኬ ምስሎችን ለማሳየት የስታቲክ ይዘት ማስተናገጃ ሀሳብን ለረጅም ጊዜ ሲጠቀም ቆይቷል። ብዙ የመስመር ላይ ጨዋታዎች ተጫዋቾችን ወደ ክልሎች ለመከፋፈል ወይም የጨዋታ ቦታዎችን ለመለየት የ Sharding ዘዴን ይጠቀማሉ (አለም እራሱ አንድ ከሆነ)። የክስተት ምንጭ አቀራረብ በኢሜል ውስጥ በንቃት ጥቅም ላይ ይውላል። ውሂብ ያለማቋረጥ የሚቀበልባቸው አብዛኛዎቹ የግብይት አፕሊኬሽኖች የተቀበሉትን መረጃ ለማጣራት በCQRS አቀራረብ ላይ የተገነቡ ናቸው። ደህና፣ አግድም ልኬት በብዙ አገልግሎቶች ውስጥ ለረጅም ጊዜ ጥቅም ላይ ውሏል።

ነገር ግን, ከሁሉም በላይ, እነዚህ ሁሉ ቅጦች በዘመናዊ አፕሊኬሽኖች (በእርግጥ ተገቢ ከሆኑ) ለመተግበር በጣም ቀላል ሆነዋል. Clouds ወዲያውኑ የተለያዩ የወሰኑ አገልጋዮችን በተለያዩ የመረጃ ቋቶች ውስጥ ከማዘዝ የበለጠ ቀላል የሆነውን Sharding እና horizontal scaling ይሰጣሉ። እንደ RX ባሉ የቤተ-መጻህፍት እድገት ምክንያት ከሆነ CQRS በጣም ቀላል ሆኗል ። የዛሬ 10 ዓመት ገደማ አንድ ብርቅዬ ድር ጣቢያ ይህንን ሊደግፍ ይችላል። Event Sourcing እንዲሁ በአፓቼ ካፍካ ለተዘጋጁ ኮንቴይነሮች ምስጋና ይግባው። ከ 10 ዓመታት በፊት ይህ አዲስ ነገር ይሆናል, አሁን የተለመደ ነው. ከስታቲክ ይዘት ማስተናገጃ ጋር ተመሳሳይ ነው፡ ይበልጥ ምቹ በሆኑ ቴክኖሎጂዎች ምክንያት (ዝርዝር ሰነዶች መኖራቸውን እና ትልቅ የመልሶች የውሂብ ጎታ መኖሩን ጨምሮ) ይህ አካሄድ ይበልጥ ቀላል ሆኗል።

በውጤቱም, በርካታ ውስብስብ የስነ-ህንፃ ንድፎችን መተግበሩ አሁን በጣም ቀላል ሆኗል, ይህም ማለት አስቀድሞ በቅርበት መመልከቱ የተሻለ ነው. በአስር አመት አተገባበር ውስጥ ከላይ ከተጠቀሱት መፍትሄዎች ውስጥ አንዱ በአተገባበሩ እና በአሰራር ውድነቱ ምክንያት ከተተወ ፣ አሁን ፣ በአዲስ መተግበሪያ ፣ ወይም እንደገና ከተሰራ በኋላ ፣ በሥነ-ሕንፃ ሁለቱም ሊገለጽ የሚችል አገልግሎት መፍጠር ይችላሉ ( በአፈጻጸም ረገድ) እና ከደንበኞች ለቀረቡ አዲስ ጥያቄዎች (ለምሳሌ የግል ውሂብን ለማካካስ) ዝግጁ።

እና ከሁሉም በላይ አስፈላጊ: እባክዎ ቀላል መተግበሪያ ካለዎት እነዚህን ዘዴዎች አይጠቀሙ. አዎን ፣ እነሱ ቆንጆ እና አስደሳች ናቸው ፣ ግን 100 ሰዎች ከፍተኛ ጉብኝት ላለው ጣቢያ ፣ ብዙውን ጊዜ በሚታወቀው ሞኖሊት (ቢያንስ ውጭ ፣ ውስጥ ያለው ነገር ሁሉ ወደ ሞጁሎች ሊከፋፈል ይችላል ፣ ወዘተ) ማግኘት ይችላሉ ።

ምንጭ: hab.com