હે હબર!

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

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

આડી સ્કેલિંગ

સૌથી સરળ અને સૌથી જાણીતો મુદ્દો. પરંપરાગત રીતે, સૌથી સામાન્ય બે લોડ વિતરણ યોજનાઓ આડી અને ઊભી સ્કેલિંગ છે. પ્રથમ કેસમાં તમે સેવાઓને સમાંતર ચલાવવાની મંજૂરી આપો છો, જેનાથી તેમની વચ્ચે લોડનું વિતરણ થાય છે. બીજામાં તમે વધુ શક્તિશાળી સર્વર્સનો ઓર્ડર આપો છો અથવા કોડને ઑપ્ટિમાઇઝ કરો છો.

ઉદાહરણ તરીકે, હું એબ્સ્ટ્રેક્ટ ક્લાઉડ ફાઇલ સ્ટોરેજ લઈશ, એટલે કે, OwnCloud, OneDrive, વગેરેના કેટલાક એનાલોગ.

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

અભિગમો વચ્ચેનો તફાવત: વર્ટિકલ સ્કેલિંગમાં, અમે નોડ્સની શક્તિ વધારવા માટે તૈયાર છીએ, અને આડી સ્કેલિંગમાં, અમે ભારને વિતરિત કરવા માટે નવા ગાંઠો ઉમેરવા માટે તૈયાર છીએ.

CQRS

આદેશ ક્વેરી જવાબદારી અલગ એક ખૂબ જ મહત્વપૂર્ણ પેટર્ન, કારણ કે તે વિવિધ ક્લાયન્ટ્સને માત્ર વિવિધ સેવાઓ સાથે જોડાવા માટે જ નહીં, પણ સમાન ઇવેન્ટ સ્ટ્રીમ્સ પ્રાપ્ત કરવાની મંજૂરી આપે છે. સરળ એપ્લિકેશન માટે તેના ફાયદા એટલા સ્પષ્ટ નથી, પરંતુ વ્યસ્ત સેવા માટે તે અત્યંત મહત્વપૂર્ણ (અને સરળ) છે. તેનો સાર: ઇનકમિંગ અને આઉટગોઇંગ ડેટા ફ્લોને છેદવું જોઈએ નહીં. એટલે કે, તમે વિનંતી મોકલી શકતા નથી અને પ્રતિસાદની અપેક્ષા રાખી શકતા નથી; તેના બદલે, તમે સેવા A ને વિનંતી મોકલો છો, પરંતુ સેવા B તરફથી પ્રતિસાદ પ્રાપ્ત કરો છો.

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

1. ક્લાયન્ટે સર્વરને વિનંતી મોકલી.
2. સર્વરે લાંબો સમય પ્રક્રિયા શરૂ કરી.
3. સર્વરે પરિણામ સાથે ક્લાયંટને જવાબ આપ્યો.

ચાલો કલ્પના કરીએ કે બિંદુ 2 માં કનેક્શન તૂટી ગયું હતું (અથવા નેટવર્ક ફરીથી કનેક્ટ થયું હતું, અથવા વપરાશકર્તા કનેક્શન તોડીને બીજા પૃષ્ઠ પર ગયો હતો). આ કિસ્સામાં, સર્વર માટે બરાબર શું પ્રક્રિયા કરવામાં આવી હતી તે વિશેની માહિતી સાથે વપરાશકર્તાને પ્રતિસાદ મોકલવો મુશ્કેલ બનશે. CQRS નો ઉપયોગ કરીને, ક્રમ થોડો અલગ હશે:

1. ક્લાયન્ટે અપડેટ્સ માટે સબ્સ્ક્રાઇબ કર્યું છે.
2. ક્લાયન્ટે સર્વરને વિનંતી મોકલી.
3. સર્વરે જવાબ આપ્યો "વિનંતી સ્વીકારાઈ."
4. સર્વરે બિંદુ "1" થી ચેનલ દ્વારા પરિણામ સાથે પ્રતિસાદ આપ્યો.

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

રસપ્રદ વાત એ છે કે, આવનારા સંદેશાઓ પર પ્રક્રિયા કરવા માટેનો કોડ ક્લાયન્ટ દ્વારા જ પ્રભાવિત થયેલી ઘટનાઓ માટે અને અન્ય ક્લાયન્ટ્સ સહિત અન્ય ઇવેન્ટ્સ માટે સમાન (100% નહીં) બને છે.

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

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

ઇવેન્ટ સોર્સિંગ

જેમ તમે જાણો છો, વિતરિત સિસ્ટમની મુખ્ય લાક્ષણિકતાઓમાંની એક સામાન્ય સમયની ગેરહાજરી છે, એક સામાન્ય જટિલ વિભાગ. એક પ્રક્રિયા માટે, તમે સિંક્રોનાઇઝેશન (સમાન મ્યુટેક્સ પર) કરી શકો છો, જેમાં તમને ખાતરી છે કે આ કોડને અન્ય કોઈ એક્ઝિક્યુટ કરી રહ્યું નથી. જો કે, વિતરિત સિસ્ટમ માટે આ ખતરનાક છે, કારણ કે તેને ઓવરહેડની જરૂર પડશે, અને સ્કેલિંગની બધી સુંદરતાને પણ મારી નાખશે - બધા ઘટકો હજી પણ એકની રાહ જોશે.

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

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

જો કે, ચાલો મૂળ કાર્ય પર પાછા આવીએ. જો સિસ્ટમનો ભાગ સાથે બનાવી શકાય છે અંતિમ સુસંગતતા, પછી આપણે નીચેનો આકૃતિ બનાવી શકીએ છીએ.

આ અભિગમની મહત્વપૂર્ણ લાક્ષણિકતાઓ:

• દરેક ઇનકમિંગ વિનંતી એક કતારમાં મૂકવામાં આવે છે.
• વિનંતી પર પ્રક્રિયા કરતી વખતે, સેવા અન્ય કતારોમાં કાર્યો પણ મૂકી શકે છે.
• દરેક ઇનકમિંગ ઇવેન્ટમાં એક ઓળખકર્તા હોય છે (જે ડુપ્લિકેશન માટે જરૂરી છે).
• કતાર વૈચારિક રીતે "માત્ર જોડો" યોજના અનુસાર કાર્ય કરે છે. તમે તેમાંથી તત્વોને દૂર કરી શકતા નથી અથવા તેમને ફરીથી ગોઠવી શકતા નથી.
• કતાર FIFO યોજના અનુસાર કાર્ય કરે છે (ટૉટોલોજી માટે માફ કરશો). જો તમારે સમાંતર એક્ઝેક્યુશન કરવાની જરૂર હોય, તો એક તબક્કે તમારે વસ્તુઓને વિવિધ કતારોમાં ખસેડવી જોઈએ.

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

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

અને બે વપરાશકર્તાઓ માટે ડાયાગ્રામ આના જેવો દેખાશે (વિવિધ વપરાશકર્તાઓ માટે બનાવાયેલ સેવાઓ વિવિધ રંગોમાં દર્શાવેલ છે):

આવા સંયોજનમાંથી બોનસ:

• માહિતી પ્રક્રિયા સેવાઓને અલગ કરવામાં આવી છે. કતારો પણ અલગ થઈ ગઈ છે. જો આપણે સિસ્ટમ થ્રુપુટ વધારવાની જરૂર હોય, તો આપણે ફક્ત વધુ સર્વર્સ પર વધુ સેવાઓ શરૂ કરવાની જરૂર છે.
• જ્યારે અમે વપરાશકર્તા પાસેથી માહિતી પ્રાપ્ત કરીએ છીએ, ત્યારે ડેટા સંપૂર્ણ રીતે સાચવવામાં આવે ત્યાં સુધી અમારે રાહ જોવાની જરૂર નથી. તેનાથી વિપરિત, આપણે ફક્ત "ઓકે" જવાબ આપવાની જરૂર છે અને પછી ધીમે ધીમે કામ કરવાનું શરૂ કરો. તે જ સમયે, કતાર શિખરોને સરળ બનાવે છે, કારણ કે નવી ઑબ્જેક્ટ ઉમેરવાનું ઝડપથી થાય છે, અને વપરાશકર્તાને સમગ્ર ચક્રમાંથી સંપૂર્ણ પાસ થવાની રાહ જોવી પડતી નથી.
• ઉદાહરણ તરીકે, મેં એક ડીડુપ્લિકેશન સેવા ઉમેરી છે જે સમાન ફાઇલોને મર્જ કરવાનો પ્રયાસ કરે છે. જો તે 1% કેસોમાં લાંબા સમય સુધી કામ કરે છે, તો ક્લાયન્ટ ભાગ્યે જ તેની નોંધ લેશે (ઉપર જુઓ), જે એક મોટી વત્તા છે, કારણ કે આપણે હવે XNUMX% ઝડપ અને વિશ્વસનીય હોવું જરૂરી નથી.

જો કે, ગેરફાયદા તરત જ દેખાય છે:

• અમારી સિસ્ટમે તેની કડક સુસંગતતા ગુમાવી દીધી છે. આનો અર્થ એ છે કે જો, ઉદાહરણ તરીકે, તમે વિવિધ સેવાઓ પર સબ્સ્ક્રાઇબ કરો છો, તો પછી સૈદ્ધાંતિક રીતે તમે એક અલગ રાજ્ય મેળવી શકો છો (કારણ કે સેવાઓમાંથી એકને આંતરિક કતારમાંથી સૂચના પ્રાપ્ત કરવાનો સમય ન હોઈ શકે). અન્ય પરિણામ તરીકે, સિસ્ટમ પાસે હવે સામાન્ય સમય નથી. એટલે કે, તે અશક્ય છે, ઉદાહરણ તરીકે, બધી ઇવેન્ટ્સને ફક્ત આગમનના સમય દ્વારા સૉર્ટ કરવી, કારણ કે સર્વર્સ વચ્ચેની ઘડિયાળો સિંક્રનસ ન હોઈ શકે (વધુમાં, બે સર્વર પર સમાન સમય એ યુટોપિયા છે).
• હવે કોઈ પણ ઈવેન્ટને ખાલી પાછી ખેંચી શકાતી નથી (જેમ કે ડેટાબેઝ સાથે થઈ શકે છે). તેના બદલે, તમારે નવી ઇવેન્ટ ઉમેરવાની જરૂર છે - વળતરની ઘટના, જે છેલ્લી સ્થિતિને જરૂરી સ્થિતિમાં બદલશે. સમાન વિસ્તારના ઉદાહરણ તરીકે: ઇતિહાસને પુનઃલેખ્યા વિના (જે કેટલાક કિસ્સાઓમાં ખરાબ છે), તમે ગિટમાં કમિટને રોલ બેક કરી શકતા નથી, પરંતુ તમે વિશિષ્ટ બનાવી શકો છો રોલબેક પ્રતિબદ્ધ, જે અનિવાર્યપણે ફક્ત જૂની સ્થિતિ પરત કરે છે. જો કે, ભૂલભરેલી પ્રતિબદ્ધતા અને રોલબેક બંને ઇતિહાસમાં રહેશે.
• ડેટા સ્કીમા રીલીઝથી રીલીઝમાં બદલાઈ શકે છે, પરંતુ જૂની ઈવેન્ટ્સ હવે નવા ધોરણમાં અપડેટ થઈ શકશે નહીં (કારણ કે ઈવેન્ટ્સ સૈદ્ધાંતિક રીતે બદલી શકાતી નથી).

જેમ તમે જોઈ શકો છો, ઇવેન્ટ સોર્સિંગ CQRS સાથે સારી રીતે કામ કરે છે. તદુપરાંત, કાર્યક્ષમ અને અનુકૂળ કતારવાળી સિસ્ટમ અમલમાં મૂકવી, પરંતુ ડેટા પ્રવાહને અલગ કર્યા વિના, તે પહેલેથી જ મુશ્કેલ છે, કારણ કે તમારે સિંક્રનાઇઝેશન પોઇન્ટ ઉમેરવા પડશે જે કતારોની સંપૂર્ણ હકારાત્મક અસરને તટસ્થ કરશે. એક જ સમયે બંને અભિગમો લાગુ કરીને, પ્રોગ્રામ કોડને સહેજ સમાયોજિત કરવો જરૂરી છે. અમારા કિસ્સામાં, સર્વર પર ફાઇલ મોકલતી વખતે, પ્રતિસાદ ફક્ત "ઓકે" આવે છે, જેનો અર્થ ફક્ત એટલો જ થાય છે કે "ફાઇલ ઉમેરવાની કામગીરી સાચવવામાં આવી હતી." ઔપચારિક રીતે, આનો અર્થ એ નથી કે ડેટા પહેલેથી જ અન્ય ઉપકરણો પર ઉપલબ્ધ છે (ઉદાહરણ તરીકે, ડિડુપ્લિકેશન સેવા ઇન્ડેક્સને ફરીથી બનાવી શકે છે). જો કે, થોડા સમય પછી, ક્લાયંટને "ફાઇલ X સાચવવામાં આવી છે" ની શૈલીમાં સૂચના પ્રાપ્ત થશે.

પરિણામ સ્વરૂપ:

• ફાઇલ મોકલવાની સ્થિતિઓની સંખ્યા વધી રહી છે: ક્લાસિક "ફાઇલ મોકલેલી" ને બદલે અમને બે મળે છે: "ફાઇલ સર્વર પરની કતારમાં ઉમેરવામાં આવી છે" અને "ફાઇલ સ્ટોરેજમાં સાચવવામાં આવી છે." બાદમાંનો અર્થ એ છે કે અન્ય ઉપકરણો પહેલાથી જ ફાઇલ પ્રાપ્ત કરવાનું શરૂ કરી શકે છે (કતાર વિવિધ ઝડપે કાર્ય કરે છે તે હકીકત માટે સમાયોજિત).
• સબમિશન માહિતી હવે વિવિધ ચેનલો દ્વારા આવે છે તે હકીકતને કારણે, અમારે ફાઇલની પ્રક્રિયાની સ્થિતિ પ્રાપ્ત કરવા માટે ઉકેલો લાવવાની જરૂર છે. આના પરિણામ રૂપે: ક્લાસિક વિનંતી-પ્રતિસાદથી વિપરીત, ફાઇલની પ્રક્રિયા કરતી વખતે ક્લાયંટને પુનઃપ્રારંભ કરી શકાય છે, પરંતુ આ પ્રક્રિયાની સ્થિતિ પોતે જ સાચી હશે. વધુમાં, આ આઇટમ કામ કરે છે, આવશ્યકપણે, બૉક્સની બહાર. પરિણામે: આપણે હવે નિષ્ફળતાઓ પ્રત્યે વધુ સહનશીલ છીએ.

શેરિંગ

ઉપર વર્ણવ્યા મુજબ, ઇવેન્ટ સોર્સિંગ સિસ્ટમ્સમાં સખત સુસંગતતાનો અભાવ છે. આનો અર્થ એ છે કે અમે તેમની વચ્ચે કોઈપણ સિંક્રનાઇઝેશન વિના ઘણા સ્ટોરેજનો ઉપયોગ કરી શકીએ છીએ. અમારી સમસ્યાનો સામનો કરીને, અમે આ કરી શકીએ છીએ:

• પ્રકાર દ્વારા ફાઇલોને અલગ કરો. ઉદાહરણ તરીકે, ચિત્રો/વિડિયો ડીકોડ કરી શકાય છે અને વધુ કાર્યક્ષમ ફોર્મેટ પસંદ કરી શકાય છે.
• દેશ દ્વારા અલગ એકાઉન્ટ્સ. ઘણા કાયદાઓને લીધે, આની જરૂર પડી શકે છે, પરંતુ આ આર્કિટેક્ચર યોજના આપમેળે આવી તક પૂરી પાડે છે

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

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

જેમ તમે જોઈ શકો છો, અમારી સિસ્ટમમાં કડક સુસંગતતા ન હતી, અને હજુ પણ નથી. ત્યાં માત્ર અંતિમ સુસંગતતા છે, એટલે કે, એક ગેરંટી છે કે ઘટનાઓ સમાન ક્રમમાં પ્રક્રિયા કરવામાં આવે છે (પરંતુ સંભવતઃ વિવિધ વિલંબ સાથે). અને, આનો ઉપયોગ કરીને, અમે સિસ્ટમને વિશ્વની બીજી બાજુએ રોક્યા વિના પ્રમાણમાં સરળતાથી ડેટા ટ્રાન્સફર કરી શકીએ છીએ.

આમ, ફાઇલો માટે ઑનલાઇન સ્ટોરેજ વિશે અમારું ઉદાહરણ ચાલુ રાખીને, આવા આર્કિટેક્ચર પહેલાથી જ અમને સંખ્યાબંધ બોનસ આપે છે:

• અમે ઑબ્જેક્ટ્સને ગતિશીલ રીતે વપરાશકર્તાઓની નજીક લઈ જઈ શકીએ છીએ. આ રીતે તમે સેવાની ગુણવત્તામાં સુધારો કરી શકો છો.
• અમે કંપનીઓમાં અમુક ડેટા સ્ટોર કરી શકીએ છીએ. ઉદાહરણ તરીકે, એન્ટરપ્રાઇઝ વપરાશકર્તાઓને વારંવાર તેમના ડેટાને નિયંત્રિત ડેટા કેન્દ્રોમાં સંગ્રહિત કરવાની જરૂર પડે છે (ડેટા લીક ટાળવા માટે). શાર્ડિંગ દ્વારા અમે આને સરળતાથી સમર્થન આપી શકીએ છીએ. અને જો ગ્રાહક પાસે સુસંગત ક્લાઉડ હોય તો કાર્ય વધુ સરળ છે (ઉદાહરણ તરીકે, Azure સ્વ હોસ્ટ).
• અને સૌથી મહત્વની બાબત એ છે કે આપણે આ કરવાની જરૂર નથી. છેવટે, શરૂઆત કરવા માટે, અમે બધા એકાઉન્ટ્સ માટે એક સ્ટોરેજથી ખૂબ ખુશ થઈશું (ઝડપથી કામ શરૂ કરવા માટે). અને આ સિસ્ટમની મુખ્ય વિશેષતા એ છે કે તે વિસ્તરણક્ષમ હોવા છતાં, પ્રારંભિક તબક્કે તે એકદમ સરળ છે. તમારે તરત જ કોડ લખવાની જરૂર નથી કે જે એક મિલિયન અલગ સ્વતંત્ર કતાર વગેરે સાથે કામ કરે છે. જો જરૂરી હોય તો, આ ભવિષ્યમાં કરી શકાય છે.

સ્થિર સામગ્રી હોસ્ટિંગ

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

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

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

• સર્વર ડાઉનલોડ URL પ્રદાન કરે છે. તે file_id + કી ફોર્મનું હોઈ શકે છે, જ્યાં કી એ મિની-ડિજિટલ હસ્તાક્ષર છે જે આગામી XNUMX કલાક માટે સંસાધનને ઍક્સેસ કરવાનો અધિકાર આપે છે.
• ફાઇલને નીચેના વિકલ્પો સાથે સરળ nginx દ્વારા વિતરિત કરવામાં આવે છે:
  • સામગ્રી કેશીંગ. આ સેવા અલગ સર્વર પર સ્થિત હોઈ શકે છે, તેથી અમે ડિસ્ક પર તમામ નવીનતમ ડાઉનલોડ કરેલી ફાઇલોને સંગ્રહિત કરવાની ક્ષમતા સાથે ભવિષ્ય માટે અમારી જાતને અનામત રાખી છે.
  • કનેક્શન બનાવતી વખતે કી તપાસી રહ્યું છે
• વૈકલ્પિક: સ્ટ્રીમિંગ સામગ્રી પ્રક્રિયા. ઉદાહરણ તરીકે, જો આપણે સેવામાંની બધી ફાઈલોને કોમ્પ્રેસ કરીએ છીએ, તો અમે આ મોડ્યુલમાં સીધા જ અનઝિપ કરી શકીએ છીએ. પરિણામ સ્વરૂપે: IO ઓપરેશન જ્યાં તેઓ સંબંધિત છે ત્યાં કરવામાં આવે છે. જાવામાં આર્કાઇવર સરળતાથી ઘણી બધી વધારાની મેમરી ફાળવશે, પરંતુ રસ્ટ/C++ કન્ડિશનલ્સમાં બિઝનેસ લોજિક સાથે સેવાને ફરીથી લખવાનું પણ બિનઅસરકારક હોઈ શકે છે. અમારા કિસ્સામાં, વિવિધ પ્રક્રિયાઓ (અથવા તો સેવાઓ) નો ઉપયોગ કરવામાં આવે છે, અને તેથી અમે વ્યવસાયિક તર્ક અને IO કામગીરીને તદ્દન અસરકારક રીતે અલગ કરી શકીએ છીએ.

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

બીજા ઉદાહરણ તરીકે (મજબૂતીકરણ માટે): જો તમે જેનકિન્સ/ટીમસિટી સાથે કામ કર્યું હોય, તો તમે જાણો છો કે બંને ઉકેલો જાવામાં લખેલા છે. તે બંને એક જાવા પ્રક્રિયા છે જે બિલ્ડ ઓર્કેસ્ટ્રેશન અને કન્ટેન્ટ મેનેજમેન્ટ બંનેને હેન્ડલ કરે છે. ખાસ કરીને, તેઓ બંને પાસે "સર્વરમાંથી ફાઇલ/ફોલ્ડર સ્થાનાંતરિત કરો" જેવા કાર્યો છે. ઉદાહરણ તરીકે: આર્ટિફેક્ટ્સ જારી કરવી, સ્રોત કોડ ટ્રાન્સફર કરવો (જ્યારે એજન્ટ રીપોઝીટરીમાંથી કોડને સીધો ડાઉનલોડ કરતો નથી, પરંતુ સર્વર તેના માટે કરે છે), લોગની ઍક્સેસ. આ તમામ કાર્યો તેમના IO લોડમાં અલગ પડે છે. એટલે કે, તે તારણ આપે છે કે જટિલ વ્યાપાર તર્ક માટે જવાબદાર સર્વર તે જ સમયે પોતાના દ્વારા ડેટાના મોટા પ્રવાહને અસરકારક રીતે દબાણ કરવામાં સક્ષમ હોવું જોઈએ. અને સૌથી રસપ્રદ બાબત એ છે કે આવી કામગીરી બરાબર સમાન યોજના અનુસાર સમાન nginx ને સોંપી શકાય છે (સિવાય કે ડેટા કી વિનંતીમાં ઉમેરવી જોઈએ).

જો કે, જો આપણે આપણી સિસ્ટમ પર પાછા આવીએ, તો આપણને સમાન ડાયાગ્રામ મળે છે:

જેમ તમે જોઈ શકો છો, સિસ્ટમ ધરમૂળથી વધુ જટિલ બની ગઈ છે. હવે તે માત્ર એક મીની-પ્રક્રિયા નથી જે ફાઇલોને સ્થાનિક રીતે સંગ્રહિત કરે છે. હવે જે જરૂરી છે તે સરળ સપોર્ટ, API સંસ્કરણ નિયંત્રણ વગેરે નથી. તેથી, તમામ આકૃતિઓ દોરવામાં આવ્યા પછી, વિસ્તરણક્ષમતા કિંમત માટે યોગ્ય છે કે કેમ તે વિગતવાર મૂલ્યાંકન કરવું શ્રેષ્ઠ છે. જો કે, જો તમે સિસ્ટમને વિસ્તૃત કરવા માટે સક્ષમ થવા માંગતા હોવ (વપરાશકર્તાઓની વધુ સંખ્યામાં સાથે કામ કરવા સહિત), તો તમારે સમાન ઉકેલો માટે જવું પડશે. પરંતુ, પરિણામે, સિસ્ટમ વધારાના લોડ માટે આર્કિટેક્ચરલી તૈયાર છે (લગભગ દરેક ઘટકને આડી સ્કેલિંગ માટે ક્લોન કરી શકાય છે). સિસ્ટમને બંધ કર્યા વિના અપડેટ કરી શકાય છે (ફક્ત કેટલીક કામગીરી થોડી ધીમી કરવામાં આવશે).

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

નિષ્કર્ષ

આ તમામ અભિગમો પહેલાથી જાણીતા હતા. એ જ VK લાંબા સમયથી છબીઓ પ્રદર્શિત કરવા માટે સ્ટેટિક કન્ટેન્ટ હોસ્ટિંગના વિચારનો ઉપયોગ કરી રહ્યો છે. ઘણી બધી ઓનલાઈન ગેમ્સ શાર્ડિંગ સ્કીમનો ઉપયોગ ખેલાડીઓને પ્રદેશોમાં વિભાજીત કરવા અથવા રમતના સ્થળોને અલગ કરવા માટે કરે છે (જો વિશ્વ પોતે એક છે). ઈમેલમાં ઈવેન્ટ સોર્સિંગનો અભિગમ સક્રિયપણે ઉપયોગમાં લેવાય છે. મોટાભાગની ટ્રેડિંગ એપ્લીકેશનો જ્યાં ડેટા સતત પ્રાપ્ત થતો હોય છે તે વાસ્તવમાં પ્રાપ્ત ડેટાને ફિલ્ટર કરવામાં સક્ષમ થવા માટે CQRS અભિગમ પર બનાવવામાં આવે છે. ઠીક છે, ઘણા લાંબા સમયથી આડી સ્કેલિંગનો ઉપયોગ ઘણી સેવાઓમાં કરવામાં આવે છે.

જો કે, સૌથી અગત્યનું, આ તમામ પેટર્ન આધુનિક એપ્લિકેશનોમાં લાગુ કરવા માટે ખૂબ જ સરળ બની ગયા છે (જો તે યોગ્ય હોય તો, અલબત્ત). ક્લાઉડ્સ તરત જ શાર્ડિંગ અને હોરિઝોન્ટલ સ્કેલિંગ ઑફર કરે છે, જે વિવિધ ડેટા સેન્ટર્સમાં અલગ-અલગ ડેડિકેટેડ સર્વર્સને જાતે ઓર્ડર કરવા કરતાં ઘણું સરળ છે. CQRS ખૂબ સરળ બની ગયું છે, જો માત્ર RX જેવી લાઇબ્રેરીઓના વિકાસને કારણે. લગભગ 10 વર્ષ પહેલાં, એક દુર્લભ વેબસાઇટ આને સમર્થન આપી શકે છે. Apache Kafka સાથે તૈયાર કન્ટેનરને કારણે ઇવેન્ટ સોર્સિંગ સેટઅપ કરવું પણ અતિ સરળ છે. 10 વર્ષ પહેલા આ એક નવીનતા હશે, હવે તે સામાન્ય છે. તે સ્ટેટિક કન્ટેન્ટ હોસ્ટિંગ સાથે સમાન છે: વધુ અનુકૂળ તકનીકોને કારણે (વિગતવાર દસ્તાવેજીકરણ અને જવાબોનો મોટો ડેટાબેઝ છે તે હકીકત સહિત), આ અભિગમ વધુ સરળ બન્યો છે.

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

અને સૌથી અગત્યનું: જો તમારી પાસે સરળ એપ્લિકેશન હોય તો કૃપા કરીને આ અભિગમોનો ઉપયોગ કરશો નહીં. હા, તે સુંદર અને રસપ્રદ છે, પરંતુ 100 લોકોની ટોચની મુલાકાતવાળી સાઇટ માટે, તમે ઘણીવાર ક્લાસિક મોનોલિથ સાથે મેળવી શકો છો (ઓછામાં ઓછું બહારની બાજુએ, અંદરની દરેક વસ્તુને મોડ્યુલોમાં વિભાજિત કરી શકાય છે, વગેરે).

સોર્સ: www.habr.com