ડોડો IS આર્કિટેક્ચરનો ઇતિહાસ: એક પ્રારંભિક મોનોલિથ

અથવા મોનોલિથ સાથેની દરેક નાખુશ કંપની તેની રીતે નાખુશ છે.

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

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

લેખોની શ્રેણી "ડોડો IS શું છે?" વિશે કહે છે:

1. ડોડો IS (2011-2015) માં પ્રારંભિક મોનોલિથ. (તમે અહિંયા છો)

2. બેક ઓફિસ પાથ: અલગ પાયા અને બસ.

3. ક્લાયંટ સાઇડ પાથ: બેઝ ઉપર રવેશ (2016-2017). (પ્રગતિમાં...)

4. વાસ્તવિક માઇક્રોસર્વિસિસનો ઇતિહાસ. (2018-2019). (પ્રગતિમાં...)

5. મોનોલિથની સોઇંગ અને આર્કિટેક્ચરનું સ્થિરીકરણ સમાપ્ત. (પ્રગતિમાં...)

પ્રારંભિક આર્કિટેક્ચર

2011 માં, ડોડો IS આર્કિટેક્ચર આના જેવું દેખાતું હતું:

આર્કિટેક્ચરમાં પ્રથમ મોડ્યુલ ઓર્ડર સ્વીકૃતિ છે. વ્યવસાય પ્રક્રિયા હતી:

• ક્લાયંટ પિઝેરિયાને બોલાવે છે;

• મેનેજર ફોન ઉપાડે છે;

• ફોન દ્વારા ઓર્ડર સ્વીકારે છે;

• તેને ઓર્ડર સ્વીકૃતિ ઇન્ટરફેસમાં સમાંતર ભરે છે: ક્લાયંટ વિશેની માહિતી, ઓર્ડરની વિગતો પરનો ડેટા, ડિલિવરી સરનામું ધ્યાનમાં લેવામાં આવે છે. 

માહિતી સિસ્ટમનું ઇન્ટરફેસ કંઈક આના જેવું દેખાતું હતું ...

ઓક્ટોબર 2011 થી પ્રથમ સંસ્કરણ:

જાન્યુઆરી 2012માં થોડો સુધારો થયો

ડોડો પિઝા ઇન્ફર્મેશન સિસ્ટમ ડિલિવરી પિઝા રેસ્ટોરન્ટ

પ્રથમ ઓર્ડર લેતા મોડ્યુલના વિકાસ માટેના સંસાધનો મર્યાદિત હતા. અમારે ઝડપથી અને નાની ટીમ સાથે ઘણું બધું કરવાનું હતું. એક નાની ટીમ 2 વિકાસકર્તાઓ છે જેણે સમગ્ર ભાવિ સિસ્ટમ માટે પાયો નાખ્યો.

તેમના પ્રથમ નિર્ણયે ટેક્નોલોજી સ્ટેકનું ભાવિ નક્કી કર્યું:

• ASP.NET MVC, C# ભાષા પર બેકએન્ડ. વિકાસકર્તાઓ dotnetchiki હતા, આ સ્ટેક તેમના માટે પરિચિત અને સુખદ હતું.

• બુટસ્ટ્રેપ અને JQuery પર ફ્રન્ટએન્ડ: સ્વ-લેખિત શૈલીઓ અને સ્ક્રિપ્ટો પર વપરાશકર્તા ઇન્ટરફેસ. 

• MySQL ડેટાબેઝ: કોઈ લાઇસન્સ ખર્ચ નથી, ઉપયોગમાં સરળ છે.

• વિન્ડોઝ સર્વર પર સર્વર્સ, કારણ કે .NET પછી ફક્ત Windows હેઠળ હોઈ શકે છે (અમે મોનો વિશે ચર્ચા કરીશું નહીં).

શારીરિક રીતે, આ બધું "હોસ્ટર પર સમર્પિત" માં વ્યક્ત કરવામાં આવ્યું હતું. 

ઓર્ડર ઇનટેક એપ્લિકેશન આર્કિટેક્ચર

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

તે અહિયાં છે.

Asp.Net MVC એ રેઝર છે, જે ફોર્મ અથવા ક્લાયન્ટની વિનંતી પર, સર્વર રેન્ડરિંગ સાથે HTML પૃષ્ઠ રેન્ડર કરે છે. ક્લાયંટ પર, CSS અને JS સ્ક્રિપ્ટ્સ પહેલાથી જ માહિતી પ્રદર્શિત કરે છે અને જો જરૂરી હોય તો, JQuery દ્વારા AJAX વિનંતીઓ કરે છે.

સર્વર પરની વિનંતીઓ *કંટ્રોલર વર્ગોમાં સમાપ્ત થાય છે, જ્યાં પદ્ધતિમાં અંતિમ HTML પૃષ્ઠની પ્રક્રિયા અને જનરેશન થાય છે. નિયંત્રકો *સેવાઓ નામના તર્કના સ્તરને વિનંતી કરે છે. દરેક સેવાઓ વ્યવસાયના કેટલાક પાસાઓને અનુરૂપ છે:

• ઉદાહરણ તરીકે, ડિપાર્ટમેન્ટ સ્ટ્રક્ચર સર્વિસે પિઝેરિયા, વિભાગો પર માહિતી આપી હતી. વિભાગ એ એક જ ફ્રેન્ચાઈઝી દ્વારા ચલાવવામાં આવતા પિઝેરિયાનું જૂથ છે.

• ReceivingOrdersService સ્વીકારી અને ઓર્ડરની રચનાની ગણતરી કરી.

• અને SmsService એપીઆઈ સેવાઓને કોલ કરીને SMS મોકલવા માટે એસએમએસ મોકલ્યો.

સેવાઓ ડેટાબેઝમાંથી પ્રોસેસ્ડ ડેટા, સ્ટોર બિઝનેસ લોજિક. દરેક સેવામાં યોગ્ય નામ સાથે એક અથવા વધુ *રિપોઝીટરીઝ હતી. તેઓ પહેલાથી જ ડેટાબેઝમાં સંગ્રહિત પ્રક્રિયાઓ અને મેપર્સના સ્તર માટે ક્વેરી ધરાવે છે. સ્ટોરેજમાં વ્યાપાર તર્ક હતો, ખાસ કરીને જેઓ રિપોર્ટિંગ ડેટા જારી કરે છે. ORM નો ઉપયોગ કરવામાં આવ્યો ન હતો, દરેક વ્યક્તિ હાથથી લખેલા sql પર આધાર રાખે છે. 

ડોમેન મોડેલ અને સામાન્ય સહાયક વર્ગોનું એક સ્તર પણ હતું, ઉદાહરણ તરીકે, ઓર્ડર વર્ગ કે જે ઓર્ડર સંગ્રહિત કરે છે. તે જ જગ્યાએ, સ્તરમાં, પસંદ કરેલ ચલણ અનુસાર ડિસ્પ્લે ટેક્સ્ટને કન્વર્ટ કરવા માટે એક સહાયક હતો.

આ બધું આવા મોડેલ દ્વારા રજૂ કરી શકાય છે:

ઓર્ડર વે

આવા ઓર્ડર બનાવવા માટે એક સરળ પ્રારંભિક રીતનો વિચાર કરો.

શરૂઆતમાં, સાઇટ સ્થિર હતી. તેના પર કિંમતો હતી, અને ટોચ પર - એક ફોન નંબર અને શિલાલેખ "જો તમને પિઝા જોઈએ છે - નંબર પર કૉલ કરો અને ઓર્ડર કરો." ઓર્ડર આપવા માટે, અમારે એક સરળ પ્રવાહ અમલમાં મૂકવાની જરૂર છે: 

• ક્લાયંટ કિંમતો સાથે સ્થિર સાઇટની મુલાકાત લે છે, ઉત્પાદનો પસંદ કરે છે અને સાઇટ પર સૂચિબદ્ધ નંબર પર કૉલ કરે છે.

• ગ્રાહક તે ઉત્પાદનોને નામ આપે છે જે તેઓ ઓર્ડરમાં ઉમેરવા માંગે છે.

• તેનું સરનામું અને નામ આપે છે.

• ઓપરેટર ઓર્ડર સ્વીકારે છે.

• ઓર્ડર સ્વીકૃત ઓર્ડર ઇન્ટરફેસમાં પ્રદર્શિત થાય છે.

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

ગ્રાહક ઉત્પાદનનું નામ આપે છે, ઓપરેટર તેના પર ક્લિક કરે છે + ઉત્પાદનની બાજુમાં, અને સર્વરને વિનંતી મોકલવામાં આવે છે. ઉત્પાદન વિશેની માહિતી ડેટાબેઝમાંથી બહાર કાઢવામાં આવે છે અને ઉત્પાદન વિશેની માહિતી કાર્ટમાં ઉમેરવામાં આવે છે.

નોંધણી. હા, અહીં તમે ડેટાબેઝમાંથી ઉત્પાદન ખેંચી શકતા નથી, પરંતુ તેને ફ્રન્ટએન્ડથી સ્થાનાંતરિત કરી શકો છો. પરંતુ સ્પષ્ટતા માટે, મેં ડેટાબેઝમાંથી બરાબર પાથ બતાવ્યો. 

આગળ, ક્લાયંટનું સરનામું અને નામ દાખલ કરો. 

જ્યારે તમે "ઑર્ડર બનાવો" ક્લિક કરો:

• વિનંતી OrderController.SaveOrder() ને મોકલવામાં આવે છે.

• અમે સત્રમાંથી કાર્ટ મેળવીએ છીએ, અમને જરૂરી જથ્થામાં ઉત્પાદનો છે.

• અમે ક્લાયન્ટ વિશેની માહિતી સાથે કાર્ટને પૂરક બનાવીએ છીએ અને તેને RecevingOrderService વર્ગની AddOrder પદ્ધતિમાં મોકલીએ છીએ, જ્યાં તે ડેટાબેઝમાં સાચવવામાં આવે છે. 

• ડેટાબેઝમાં ઓર્ડર, ઓર્ડરની રચના, ક્લાયંટ સાથે કોષ્ટકો છે અને તે બધા જોડાયેલા છે.

• ઓર્ડર ડિસ્પ્લે ઇન્ટરફેસ જાય છે અને નવીનતમ ઓર્ડર ખેંચે છે અને તેમને પ્રદર્શિત કરે છે.

નવા મોડ્યુલો

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

મોડ્યુલ એ કાર્યોનો સમૂહ છે જે અમુક સામાન્ય વ્યવસાયિક ધ્યેય દ્વારા એક થાય છે. તે જ સમયે, તેઓ શારીરિક રીતે સમાન એપ્લિકેશનમાં છે.

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

તકનીકી રીતે, મોડ્યુલોને વિસ્તાર તરીકે ડિઝાઇન કરવામાં આવ્યા હતા (આવો વિચાર તેમાં પણ રહ્યો હતો asp.net કોર). ફ્રન્ટએન્ડ, મોડેલો તેમજ તેમના પોતાના નિયંત્રક વર્ગો માટે અલગ ફાઇલો હતી. પરિણામે, આમાંથી સિસ્ટમ બદલાઈ ગઈ હતી ...

...આમાં:

કેટલાક મોડ્યુલ્સ સંપૂર્ણપણે અલગ કાર્યક્ષમતાને કારણે અને અંશતઃ થોડા અલગ, વધુ કેન્દ્રિત વિકાસને કારણે અલગ સાઇટ્સ (એક્ઝિક્યુટેબલ પ્રોજેક્ટ) દ્વારા અમલમાં મૂકવામાં આવે છે. આ:

• સાઇટ - પ્રથમ સંસ્કરણ સાઇટ dodopizza.ru.

• નિકાસ કરો: 1C માટે ડોડો IS ના અહેવાલો અપલોડ કરી રહ્યા છીએ. 

• વ્યક્તિગત - કર્મચારીનું વ્યક્તિગત ખાતું. તે અલગથી વિકસાવવામાં આવ્યું હતું અને તેનું પોતાનું એન્ટ્રી પોઈન્ટ અને અલગ ડિઝાઇન છે.

• fs - સ્ટેટિક્સ હોસ્ટ કરવા માટેનો પ્રોજેક્ટ. બાદમાં અમે તમામ સ્ટેટિક્સને અકામાઈ સીડીએન પર ખસેડીને તેનાથી દૂર ગયા. 

બાકીના બ્લોક્સ બેકઓફિસ એપ્લિકેશનમાં હતા. 

નામ સમજૂતી:

• કેશિયર - રેસ્ટોરન્ટ કેશિયર.

• ShiftManager - "Shift Manager" ભૂમિકા માટે ઇન્ટરફેસ: પિઝેરિયાના વેચાણ પરના ઓપરેશનલ આંકડા, સ્ટોપ લિસ્ટમાં ઉત્પાદનો મૂકવાની ક્ષમતા, ક્રમમાં ફેરફાર.

• ઓફિસ મેનેજર - "પિઝેરિયા મેનેજર" અને "ફ્રેન્ચાઇઝી" ભૂમિકાઓ માટે ઇન્ટરફેસ. અહીં પિઝેરિયા સેટ કરવા, તેના બોનસ પ્રમોશન, કર્મચારીઓને પ્રાપ્ત કરવા અને કામ કરવા, રિપોર્ટ્સ માટેના કાર્યો એકત્રિત કરવામાં આવ્યા છે.

• પબ્લિકસ્ક્રીન - પિઝેરિયામાં લટકતા ટીવી અને ટેબ્લેટ માટેના ઇન્ટરફેસ. ટીવી ડિલિવરી પર મેનુ, જાહેરાત માહિતી, ઓર્ડરની સ્થિતિ દર્શાવે છે. 

તેઓએ એક સામાન્ય સેવા સ્તર, એક સામાન્ય Dodo.Core ડોમેન વર્ગ બ્લોક અને સામાન્ય આધારનો ઉપયોગ કર્યો. કેટલીકવાર તેઓ હજી પણ સંક્રમણો સાથે એકબીજા તરફ દોરી શકે છે. વ્યક્તિગત સાઇટ્સ સહિત, જેમ કે dodopizza.ru અથવા personal.dodopizza.ru, સામાન્ય સેવાઓ પર ગયા.

જ્યારે નવા મોડ્યુલ્સ દેખાયા, ત્યારે અમે ડેટાબેઝમાં પહેલાથી બનાવેલ સેવાઓના કોડ, સંગ્રહિત પ્રક્રિયાઓ અને કોષ્ટકોનો મહત્તમ ઉપયોગ કરવાનો પ્રયાસ કર્યો. 

સિસ્ટમમાં બનાવેલા મોડ્યુલોના સ્કેલની વધુ સારી સમજણ માટે, અહીં વિકાસ યોજનાઓ સાથે 2012 ની આકૃતિ છે:

2015 સુધીમાં, બધું નકશા પર હતું અને તેનાથી પણ વધુ ઉત્પાદનમાં હતું.

• ઑર્ડર સ્વીકૃતિ સંપર્ક કેન્દ્રના એક અલગ બ્લોકમાં વિકસિત થઈ છે, જ્યાં ઑપરેટર દ્વારા ઑર્ડર સ્વીકારવામાં આવે છે.

• પિઝેરિયામાં મેનૂ અને માહિતી લટકતી જાહેર સ્ક્રીનો હતી.

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

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

સમાંતર, 2012 થી 2015 સુધી, 10 થી વધુ વિકાસકર્તાઓ દેખાયા, 35 પિઝેરિયા ખોલ્યા, સિસ્ટમને રોમાનિયામાં તૈનાત કરી અને યુનાઇટેડ સ્ટેટ્સમાં આઉટલેટ્સ ખોલવાની તૈયારી કરી. વિકાસકર્તાઓ હવે તમામ કાર્યો સાથે વ્યવહાર કરતા નથી, પરંતુ ટીમોમાં વહેંચાયેલા હતા. દરેક સિસ્ટમના પોતાના ભાગમાં વિશિષ્ટ છે. 

સમસ્યાઓ

આર્કિટેક્ચરને કારણે (પરંતુ માત્ર નહીં) સહિત.

આધાર માં અંધાધૂંધી

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

પરંતુ વિકાસના 4 વર્ષોમાં, ડેટાબેઝમાં લગભગ 600 કોષ્ટકો, 1500 સંગ્રહિત પ્રક્રિયાઓ હોવાનું બહાર આવ્યું, જેમાંથી ઘણામાં તર્ક પણ હતા. અરે, MySQL સાથે કામ કરતી વખતે સંગ્રહિત પ્રક્રિયાઓ વધુ લાભ લાવતી નથી. તેઓ આધાર દ્વારા કેશ થયેલ નથી, અને તેમાં તર્ક સંગ્રહિત કરવાથી વિકાસ અને ડીબગીંગ જટિલ બને છે. કોડ પુનઃઉપયોગ પણ મુશ્કેલ છે.

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

કોષ્ટકોમાંનો ડેટા હંમેશા સૌથી યોગ્ય સ્વરૂપમાં ન હતો. ક્યાંક ડીનોર્મલાઈઝેશન કરવું જરૂરી હતું. નિયમિત રીતે પ્રાપ્ત થતા ડેટાનો એક ભાગ XML સ્ટ્રક્ચરના રૂપમાં કૉલમમાં હતો, આનાથી અમલીકરણનો સમય વધ્યો, પ્રશ્નો લંબાયા અને વિકાસને જટિલ બનાવ્યો.

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

ડેટા એકત્ર કરવામાં આવ્યો ન હતો અને આધારનો ઉપયોગ કરીને ઘણી ગણતરીઓ ફ્લાય પર થઈ. આનાથી બિનજરૂરી ગણતરીઓ અને વધારાનો ભાર ઊભો થયો. 

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

કોડમાં સુસંગતતા અને અસ્પષ્ટતા

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

સેવાઓ (એક મોનોલિથિક મોટા પ્રોજેક્ટની અંદરના વર્ગો) તેમના ડેટાને સમૃદ્ધ બનાવવા માટે એકબીજાને કૉલ કરી શકે છે.

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

તર્ક કાં તો નિયંત્રકો અથવા સેવા વર્ગોમાં હતો. 

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

મોટા વિકાસની જટિલતા

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

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

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

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

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

પાવર ઓફ ધ માઇન્ડ બ્લોગ રેસ્ટોરાંમાં રોકડ રજિસ્ટર કેવી રીતે મૂકે છે

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

બ્લોગમાં "મન શક્તિ” એ એક વિજેટ હતું જે સમગ્ર નેટવર્કના વર્ષ માટે આવક પરનો ડેટા દર્શાવે છે. વિજેટ ડોડો સાર્વજનિક API ને ઍક્સેસ કરે છે, જે આ ડેટા પ્રદાન કરે છે. આ આંકડા હાલમાં ઉપલબ્ધ છે http://dodopizzastory.com/. વિજેટ દરેક પૃષ્ઠ પર બતાવવામાં આવ્યું હતું અને દર 20 સેકન્ડે ટાઈમર પર વિનંતીઓ કરવામાં આવી હતી. વિનંતી api.dodopizza.ru પર ગઈ અને વિનંતી કરી:

• નેટવર્કમાં પિઝેરિયાની સંખ્યા;

• વર્ષની શરૂઆતથી કુલ નેટવર્ક આવક;

• આજની આવક.

આવક પરના આંકડા માટેની વિનંતી સીધી ડેટાબેઝમાં ગઈ અને ઓર્ડર પરના ડેટાની વિનંતી કરવાનું શરૂ કર્યું, ફ્લાય પર ડેટા એકત્ર કરીને અને રકમ આપવાનું શરૂ કર્યું. 

રેસ્ટોરાંમાં કેશ ડેસ્ક ઓર્ડરના સમાન ટેબલ પર ગયા, આજ માટે પ્રાપ્ત ઓર્ડરની સૂચિને અનલોડ કરી અને તેમાં નવા ઓર્ડર ઉમેરવામાં આવ્યા. કેશ રજિસ્ટર દર 5 સેકન્ડે અથવા પેજ રિફ્રેશ પર તેમની વિનંતીઓ કરે છે.

આકૃતિ આના જેવી દેખાતી હતી:

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

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

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

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

ઝડપી વ્યવસાય વૃદ્ધિ

તે તરત કેમ ન કરી શકાય? ફક્ત નીચેના ચાર્ટ્સ જુઓ.

2014-2015માં પણ રોમાનિયામાં ઓપનિંગ થયું હતું અને યુએસએમાં ઓપનિંગ તૈયાર થઈ રહ્યું હતું.

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

આર્કિટેક્ચરના સમયસર સુધારણા અને સામાન્ય રીતે તકનીકી સમસ્યાઓ તરફ ધ્યાન આપવામાં અન્ય અવરોધ 2014 ની કટોકટી હતી. આના જેવી બાબતો ટીમો માટે વિકાસની તકો પર સખત અસર કરે છે, ખાસ કરીને ડોડો પિઝા જેવા યુવાન વ્યવસાય માટે.

ઝડપી ઉકેલો જેણે મદદ કરી

સમસ્યાઓના ઉકેલની જરૂર છે. પરંપરાગત રીતે, ઉકેલોને 2 જૂથોમાં વહેંચી શકાય છે:

• ઝડપી લોકો કે જે આગને કાબૂમાં રાખે છે અને સલામતીનો નાનો માર્જિન આપે છે અને અમને બદલવા માટે સમય ખરીદે છે.

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

ઝડપી ફેરફારોની સૂકી સૂચિ નીચે મુજબ છે:

બેઝ માસ્ટરને સ્કેલ અપ કરો

અલબત્ત, લોડ સાથે વ્યવહાર કરવા માટે જે પ્રથમ વસ્તુ કરવામાં આવે છે તે સર્વરની ક્ષમતા વધારવી છે. આ માસ્ટર ડેટાબેઝ અને વેબ સર્વર્સ માટે કરવામાં આવ્યું હતું. અરે, આ એક ચોક્કસ મર્યાદા સુધી જ શક્ય છે, પછી તે ખૂબ મોંઘું થઈ જાય છે.

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

વાંચન માટે આધાર પ્રતિકૃતિઓ

બેઝ માટે બે પ્રતિકૃતિઓ બનાવવામાં આવી હતી:

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

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

કોડમાં કેશ

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

બહુવિધ બેકએન્ડ સર્વર્સ

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

પરિણામે, આર્કિટેક્ચર વધુ જટિલ બની ગયું છે ...

…પણ થોડું ટેન્શન દૂર થયું.

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

સોર્સ: www.habr.com