હે હબર!

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

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

આડી સ્કેલિંગ

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

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

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

અભિગમો વચ્ચેનો તફાવત એ છે કે વર્ટિકલ સ્કેલિંગમાં, આપણે નોડ્સની ક્ષમતા વધારવા માટે તૈયાર છીએ, જ્યારે હોરીઝોન્ટલ સ્કેલિંગમાં, આપણે લોડનું વિતરણ કરવા માટે નવા નોડ્સ ઉમેરવા માટે તૈયાર છીએ.

CQRS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

આવા સંયોજનના બોનસ:

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

જોકે, ગેરફાયદા તરત જ સ્પષ્ટ છે:

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

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

પરિણામે:

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

શેરિંગ

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

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

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

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

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

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

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

સ્ટેટિક કન્ટેન્ટ હોસ્ટિંગ

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

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

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

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

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

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

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

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

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

નિષ્કર્ષ

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

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

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

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

સોર્સ: www.habr.com