ഡോഡോ IS വാസ്തുവിദ്യയുടെ ചരിത്രം: ഒരു ആദ്യകാല മോണോലിത്ത്

അല്ലെങ്കിൽ ഒരു മോണോലിത്ത് ഉള്ള എല്ലാ അസന്തുഷ്ടരായ കമ്പനിയും അതിന്റേതായ രീതിയിൽ അസന്തുഷ്ടരാണ്.

ഡോഡോ പിസ്സ ബിസിനസ്സ് പോലെ ഡോഡോ ഐഎസ് സിസ്റ്റത്തിന്റെ വികസനം 2011 ൽ ഉടനടി ആരംഭിച്ചു. ബിസിനസ്സ് പ്രക്രിയകളുടെ പൂർണ്ണവും മൊത്തത്തിലുള്ളതുമായ ഡിജിറ്റലൈസേഷൻ എന്ന ആശയത്തെ അടിസ്ഥാനമാക്കിയുള്ളതായിരുന്നു ഇത് സ്വന്തം നിലയിൽ2011-ൽ പോലും അത് ഒരുപാട് ചോദ്യങ്ങളും സംശയങ്ങളും ഉണ്ടാക്കി. എന്നാൽ ഇപ്പോൾ 9 വർഷമായി ഞങ്ങൾ ഈ പാത പിന്തുടരുന്നു - ഞങ്ങളുടെ സ്വന്തം വികസനം, ഒരു മോണോലിത്തിൽ ആരംഭിച്ചു.

ഈ ലേഖനം "എന്തുകൊണ്ടാണ് വാസ്തുവിദ്യ മാറ്റിയെഴുതി ഇത്രയും വലിയ തോതിലുള്ള ദീർഘകാല മാറ്റങ്ങൾ വരുത്തുന്നത്?" എന്ന ചോദ്യങ്ങൾക്കുള്ള ഒരു "ഉത്തരം" ആണ്. മുൻ ലേഖനത്തിലേക്ക് മടങ്ങുക "ഡോഡോയുടെ ചരിത്രം വാസ്തുവിദ്യ: ബാക്ക് ഓഫീസിന്റെ വഴി". ഡോഡോ ഐഎസിന്റെ വികസനം എങ്ങനെ ആരംഭിച്ചു, യഥാർത്ഥ വാസ്തുവിദ്യ എങ്ങനെയായിരുന്നു, പുതിയ മൊഡ്യൂളുകൾ എങ്ങനെ പ്രത്യക്ഷപ്പെട്ടു, എന്ത് പ്രശ്‌നങ്ങൾ കാരണം വലിയ തോതിലുള്ള മാറ്റങ്ങൾ വരുത്തേണ്ടി വന്നു എന്നതിൽ നിന്ന് ഞാൻ ആരംഭിക്കും.

ലേഖനങ്ങളുടെ പരമ്പര "എന്താണ് ഡോഡോ IS?" ഇതിനെക്കുറിച്ച് പറയുന്നു:

1. ഡോഡോ ഐഎസിലെ ആദ്യകാല മോണോലിത്ത് (2011-2015). (നീ ഇവിടെയാണ്)

2. ബാക്ക് ഓഫീസ് പാത: പ്രത്യേക ബേസും ബസും.

3. ക്ലയന്റ് സൈഡ് പാത്ത്: അടിത്തറയ്ക്ക് മുകളിലുള്ള മുഖം (2016-2017). (പുരോഗതിയിൽ...)

4. യഥാർത്ഥ മൈക്രോസർവീസുകളുടെ ചരിത്രം. (2018-2019). (പുരോഗതിയിൽ...)

5. മോണോലിത്തിന്റെ വെട്ടിയെടുത്ത് വാസ്തുവിദ്യയുടെ സ്ഥിരത പൂർത്തിയാക്കി. (പുരോഗതിയിൽ...)

പ്രാരംഭ വാസ്തുവിദ്യ

2011-ൽ, ഡോഡോ ഐഎസ് വാസ്തുവിദ്യ ഇതുപോലെയായിരുന്നു:

വാസ്തുവിദ്യയിലെ ആദ്യത്തെ മൊഡ്യൂൾ ഓർഡർ സ്വീകാര്യതയാണ്. ബിസിനസ്സ് പ്രക്രിയ ഇതായിരുന്നു:

• ക്ലയന്റ് പിസ്സേറിയയെ വിളിക്കുന്നു;

• മാനേജർ ഫോൺ എടുക്കുന്നു;

• ഫോൺ വഴി ഒരു ഓർഡർ സ്വീകരിക്കുന്നു;

• ഓർഡർ സ്വീകാര്യത ഇന്റർഫേസിൽ സമാന്തരമായി ഇത് പൂരിപ്പിക്കുന്നു: ക്ലയന്റിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ, ഓർഡർ വിശദാംശങ്ങളിലെ ഡാറ്റ, ഡെലിവറി വിലാസം എന്നിവ കണക്കിലെടുക്കുന്നു. 

വിവര സംവിധാനത്തിന്റെ ഇന്റർഫേസ് ഇതുപോലെയാണ് ...

2011 ഒക്ടോബറിലെ ആദ്യ പതിപ്പ്:

2012 ജനുവരിയിൽ അൽപ്പം മെച്ചപ്പെട്ടു

ഡോഡോ പിസ്സ ഇൻഫർമേഷൻ സിസ്റ്റം ഡെലിവറി പിസ്സ റെസ്റ്റോറന്റ്

ആദ്യ ഓർഡർ എടുക്കൽ മൊഡ്യൂളിന്റെ വികസനത്തിനുള്ള വിഭവങ്ങൾ പരിമിതമായിരുന്നു. വേഗത്തിലും ഒരു ചെറിയ ടീമിനൊപ്പം ഞങ്ങൾക്ക് ഒരുപാട് കാര്യങ്ങൾ ചെയ്യേണ്ടിവന്നു. മുഴുവൻ ഭാവി സംവിധാനത്തിനും അടിത്തറ പാകിയ 2 ഡവലപ്പർമാരാണ് ഒരു ചെറിയ ടീം.

അവരുടെ ആദ്യ തീരുമാനം ടെക്നോളജി സ്റ്റാക്കിന്റെ വിധി നിർണ്ണയിച്ചു:

• ASP.NET MVC, C# ഭാഷയിലെ ബാക്കെൻഡ്. ഡവലപ്പർമാർ dotnetchiki ആയിരുന്നു, ഈ സ്റ്റാക്ക് അവർക്ക് പരിചിതവും മനോഹരവുമായിരുന്നു.

• ബൂട്ട്‌സ്‌ട്രാപ്പിലും JQuery-ലും മുൻഭാഗം: സ്വയം എഴുതിയ ശൈലികളിലും സ്‌ക്രിപ്റ്റുകളിലും ഉപയോക്തൃ ഇന്റർഫേസുകൾ. 

• MySQL ഡാറ്റാബേസ്: ലൈസൻസ് ചെലവുകളൊന്നുമില്ല, ഉപയോഗിക്കാൻ എളുപ്പമാണ്.

• വിൻഡോസ് സെർവറിലെ സെർവറുകൾ, കാരണം .NET വിൻഡോസിന് കീഴിൽ മാത്രമേ ഉണ്ടാകൂ (ഞങ്ങൾ മോണോയെക്കുറിച്ച് ചർച്ച ചെയ്യുന്നില്ല).

ശാരീരികമായി, ഇതെല്ലാം "ഹോസ്റ്ററിലെ സമർപ്പണത്തിൽ" പ്രകടിപ്പിച്ചു. 

ഇൻടേക്ക് ആപ്ലിക്കേഷൻ ആർക്കിടെക്ചർ ഓർഡർ ചെയ്യുക

അപ്പോൾ എല്ലാവരും ഇതിനകം മൈക്രോസർവീസുകളെക്കുറിച്ച് സംസാരിച്ചു, SOA 5 വർഷത്തേക്ക് വലിയ പ്രോജക്റ്റുകളിൽ ഉപയോഗിച്ചു, ഉദാഹരണത്തിന്, WCF 2006 ൽ പുറത്തിറങ്ങി. എന്നാൽ പിന്നീട് അവർ വിശ്വസനീയവും തെളിയിക്കപ്പെട്ടതുമായ ഒരു പരിഹാരം തിരഞ്ഞെടുത്തു.

ഇവിടെ ഇതാ.

Asp.Net MVC റേസർ ആണ്, ഇത് ഒരു ഫോമിൽ നിന്നോ ക്ലയന്റിൽ നിന്നോ അഭ്യർത്ഥിച്ചാൽ, സെർവർ റെൻഡറിംഗിനൊപ്പം ഒരു HTML പേജ് റെൻഡർ ചെയ്യുന്നു. ക്ലയന്റിൽ, CSS, JS സ്ക്രിപ്റ്റുകൾ ഇതിനകം വിവരങ്ങൾ പ്രദർശിപ്പിക്കുകയും ആവശ്യമെങ്കിൽ, JQuery വഴി AJAX അഭ്യർത്ഥനകൾ നടത്തുകയും ചെയ്യുന്നു.

സെർവറിലെ അഭ്യർത്ഥനകൾ *കൺട്രോളർ ക്ലാസുകളിൽ അവസാനിക്കുന്നു, അവിടെ അവസാന HTML പേജിന്റെ പ്രോസസ്സിംഗും ജനറേഷനും ഈ രീതിയിലാണ് നടക്കുന്നത്. കൺട്രോളറുകൾ ലോജിക്കിന്റെ ഒരു ലെയറിലേക്ക് അഭ്യർത്ഥനകൾ നടത്തുന്നു *സേവനങ്ങൾ. ഓരോ സേവനങ്ങളും ബിസിനസിന്റെ ചില വശങ്ങളുമായി പൊരുത്തപ്പെടുന്നു:

• ഉദാഹരണത്തിന്, ഡിപ്പാർട്ട്‌മെന്റ് സ്ട്രക്ചർ സർവീസ് ഡിപ്പാർട്ട്‌മെന്റുകളെക്കുറിച്ചുള്ള പിസേറിയകളെക്കുറിച്ചുള്ള വിവരങ്ങൾ നൽകി. ഒരു ഡിപ്പാർട്ട്‌മെന്റ് എന്നത് ഒരു ഫ്രാഞ്ചൈസി നടത്തുന്ന പിസേറിയകളുടെ ഒരു കൂട്ടമാണ്.

• ReceivingOrdersService സ്വീകരിക്കുകയും ഓർഡറിന്റെ ഘടന കണക്കാക്കുകയും ചെയ്തു.

• എസ്എംഎസ് അയയ്‌ക്കുന്നതിന് എപിഐ സേവനങ്ങളെ വിളിച്ച് എസ്എംഎസ് സേവനം എസ്എംഎസ് അയച്ചു.

സേവനങ്ങൾ ഡാറ്റാബേസിൽ നിന്നുള്ള ഡാറ്റ പ്രോസസ്സ് ചെയ്യുന്നു, സംഭരിച്ച ബിസിനസ് ലോജിക്. ഓരോ സേവനത്തിനും ഉചിതമായ പേരുള്ള ഒന്നോ അതിലധികമോ *റിപ്പോസിറ്ററികൾ ഉണ്ടായിരുന്നു. ഡാറ്റാബേസിൽ സംഭരിച്ച നടപടിക്രമങ്ങളെക്കുറിച്ചും മാപ്പർമാരുടെ ഒരു പാളിയെക്കുറിച്ചും അവ ഇതിനകം തന്നെ അന്വേഷണങ്ങൾ ഉൾക്കൊള്ളുന്നു. സ്റ്റോറേജുകളിൽ ബിസിനസ്സ് ലോജിക് ഉണ്ടായിരുന്നു, പ്രത്യേകിച്ച് റിപ്പോർട്ടിംഗ് ഡാറ്റ നൽകിയവയിൽ. ORM ഉപയോഗിച്ചില്ല, എല്ലാവരും കൈകൊണ്ട് എഴുതിയ sql-നെ ആശ്രയിച്ചു. 

ഡൊമെയ്ൻ മോഡലിന്റെയും സാധാരണ സഹായ ക്ലാസുകളുടെയും ഒരു ലെയറും ഉണ്ടായിരുന്നു, ഉദാഹരണത്തിന്, ഓർഡർ സംഭരിച്ച ഓർഡർ ക്ലാസ്. അതേ സ്ഥലത്ത്, ലെയറിൽ, തിരഞ്ഞെടുത്ത കറൻസി അനുസരിച്ച് ഡിസ്പ്ലേ ടെക്സ്റ്റ് പരിവർത്തനം ചെയ്യുന്നതിനുള്ള ഒരു സഹായി ഉണ്ടായിരുന്നു.

ഇതെല്ലാം അത്തരമൊരു മാതൃകയിലൂടെ പ്രതിനിധീകരിക്കാം:

ഓർഡർ വഴി

അത്തരമൊരു ഓർഡർ സൃഷ്ടിക്കുന്നതിനുള്ള ലളിതമായ ഒരു പ്രാരംഭ മാർഗം പരിഗണിക്കുക.

തുടക്കത്തിൽ, സൈറ്റ് സ്ഥിരമായിരുന്നു. അതിൽ വിലകൾ ഉണ്ടായിരുന്നു, മുകളിൽ - ഒരു ഫോൺ നമ്പറും ലിഖിതവും "നിങ്ങൾക്ക് പിസ്സ വേണമെങ്കിൽ - നമ്പറിൽ വിളിച്ച് ഓർഡർ ചെയ്യുക." ഓർഡർ ചെയ്യുന്നതിന്, ഞങ്ങൾ ഒരു ലളിതമായ ഫ്ലോ നടപ്പിലാക്കേണ്ടതുണ്ട്: 

• ക്ലയന്റ് വിലകളുള്ള ഒരു സ്റ്റാറ്റിക് സൈറ്റ് സന്ദർശിക്കുകയും ഉൽപ്പന്നങ്ങൾ തിരഞ്ഞെടുക്കുകയും സൈറ്റിൽ ലിസ്റ്റുചെയ്തിരിക്കുന്ന നമ്പറിലേക്ക് വിളിക്കുകയും ചെയ്യുന്നു.

• ഓർഡറിലേക്ക് ചേർക്കാൻ ആഗ്രഹിക്കുന്ന ഉൽപ്പന്നങ്ങൾക്ക് ഉപഭോക്താവ് പേരിടുന്നു.

• അവന്റെ വിലാസവും പേരും നൽകുന്നു.

• ഓപ്പറേറ്റർ ഓർഡർ സ്വീകരിക്കുന്നു.

• സ്വീകരിച്ച ഓർഡർ ഇന്റർഫേസിൽ ഓർഡർ പ്രദർശിപ്പിക്കും.

മെനു പ്രദർശിപ്പിക്കുന്നതിലൂടെയാണ് എല്ലാം ആരംഭിക്കുന്നത്. ഒരു ലോഗിൻ ചെയ്ത ഉപയോക്തൃ-ഓപ്പറേറ്റർ ഒരു സമയം ഒരു ഓർഡർ മാത്രമേ സ്വീകരിക്കുകയുള്ളൂ. അതിനാൽ, ഡ്രാഫ്റ്റ് കാർട്ട് അവന്റെ സെഷനിൽ സൂക്ഷിക്കാം (ഉപയോക്താവിന്റെ സെഷൻ മെമ്മറിയിൽ സൂക്ഷിക്കുന്നു). ഉൽപ്പന്നങ്ങളും ഉപഭോക്തൃ വിവരങ്ങളും അടങ്ങുന്ന ഒരു കാർട്ട് ഒബ്ജക്റ്റ് ഉണ്ട്.

ഉപഭോക്താവ് ഉൽപ്പന്നത്തിന് പേരിടുന്നു, ഓപ്പറേറ്റർ ക്ലിക്ക് ചെയ്യുന്നു + ഉൽപ്പന്നത്തിന് അടുത്തായി, സെർവറിലേക്ക് ഒരു അഭ്യർത്ഥന അയയ്ക്കുന്നു. ഉൽപ്പന്നത്തെക്കുറിച്ചുള്ള വിവരങ്ങൾ ഡാറ്റാബേസിൽ നിന്ന് പുറത്തെടുക്കുകയും ഉൽപ്പന്നത്തെക്കുറിച്ചുള്ള വിവരങ്ങൾ കാർട്ടിൽ ചേർക്കുകയും ചെയ്യുന്നു.

അഭിപായപ്പെടുക. അതെ, ഇവിടെ നിങ്ങൾക്ക് ഡാറ്റാബേസിൽ നിന്ന് ഉൽപ്പന്നം പിൻവലിക്കാൻ കഴിയില്ല, പക്ഷേ ഫ്രണ്ടെൻഡിൽ നിന്ന് അത് കൈമാറുക. എന്നാൽ വ്യക്തതയ്ക്കായി, ഞാൻ ഡാറ്റാബേസിൽ നിന്നുള്ള പാത കൃത്യമായി കാണിച്ചു. 

അടുത്തതായി, ക്ലയന്റിന്റെ വിലാസവും പേരും നൽകുക. 

നിങ്ങൾ "ഓർഡർ സൃഷ്‌ടിക്കുക" ക്ലിക്ക് ചെയ്യുമ്പോൾ:

• അഭ്യർത്ഥന OrderController.SaveOrder() എന്നതിലേക്ക് അയച്ചു.

• സെഷനിൽ നിന്ന് ഞങ്ങൾക്ക് കാർട്ട് ലഭിക്കുന്നു, ഞങ്ങൾക്ക് ആവശ്യമുള്ള അളവിൽ ഉൽപ്പന്നങ്ങളുണ്ട്.

• ഞങ്ങൾ കാർട്ടിനെ ക്ലയന്റിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ സപ്ലിമെന്റ് ചെയ്യുകയും അത് ഡാറ്റാബേസിലേക്ക് സേവ് ചെയ്യുന്ന RceivingOrderService ക്ലാസ്സിന്റെ AddOrder രീതിയിലേക്ക് കൈമാറുകയും ചെയ്യുന്നു. 

• ഡാറ്റാബേസിൽ ഓർഡർ, ഓർഡറിന്റെ ഘടന, ക്ലയന്റ് എന്നിവയുള്ള പട്ടികകളുണ്ട്, അവയെല്ലാം ബന്ധിപ്പിച്ചിരിക്കുന്നു.

• ഓർഡർ ഡിസ്പ്ലേ ഇന്റർഫേസ് പോയി ഏറ്റവും പുതിയ ഓർഡറുകൾ പുറത്തെടുത്ത് അവ പ്രദർശിപ്പിക്കുന്നു.

പുതിയ മൊഡ്യൂളുകൾ

ഓർഡർ എടുക്കൽ പ്രധാനവും ആവശ്യവുമായിരുന്നു. നിങ്ങൾക്ക് വിൽക്കാൻ ഓർഡർ ഇല്ലെങ്കിൽ നിങ്ങൾക്ക് ഒരു പിസ്സ ബിസിനസ്സ് ചെയ്യാൻ കഴിയില്ല. അതിനാൽ, സിസ്റ്റം പ്രവർത്തനക്ഷമത കൈവരിക്കാൻ തുടങ്ങി - ഏകദേശം 2012 മുതൽ 2015 വരെ. ഈ സമയത്ത്, സിസ്റ്റത്തിന്റെ വിവിധ ബ്ലോക്കുകൾ പ്രത്യക്ഷപ്പെട്ടു, അത് ഞാൻ വിളിക്കും മൊഡ്യൂളുകൾ, സേവനം അല്ലെങ്കിൽ ഉൽപ്പന്നം എന്ന ആശയത്തിന് വിരുദ്ധമായി. 

ഒരു മൊഡ്യൂൾ എന്നത് ചില പൊതു ബിസിനസ്സ് ലക്ഷ്യങ്ങളാൽ ഏകീകരിക്കപ്പെട്ട പ്രവർത്തനങ്ങളുടെ ഒരു കൂട്ടമാണ്. അതേ സമയം, അവർ ശാരീരികമായി ഒരേ പ്രയോഗത്തിലാണ്.

മൊഡ്യൂളുകളെ സിസ്റ്റം ബ്ലോക്കുകൾ എന്ന് വിളിക്കാം. ഉദാഹരണത്തിന്, ഇതൊരു റിപ്പോർട്ടിംഗ് മൊഡ്യൂൾ ആണ്, അഡ്മിൻ ഇന്റർഫേസുകൾ, അടുക്കളയിലെ ഫുഡ് ട്രാക്കർ, അംഗീകാരം. ഇവയെല്ലാം വ്യത്യസ്‌തമായ ഉപയോക്തൃ ഇന്റർഫേസുകളാണ്, ചിലതിന് വ്യത്യസ്‌ത വിഷ്വൽ ശൈലികളും ഉണ്ട്. അതേ സമയം, എല്ലാം ഒരു ആപ്ലിക്കേഷന്റെ ചട്ടക്കൂടിനുള്ളിലാണ്, ഒരു പ്രവർത്തിക്കുന്ന പ്രക്രിയ. 

സാങ്കേതികമായി, മൊഡ്യൂളുകൾ ഒരു ഏരിയ ആയിട്ടാണ് രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത് (അത്തരം ഒരു ആശയം നിലനിന്നിരുന്നു asp.net കോർ). ഫ്രണ്ട്‌എൻഡിനും മോഡലുകൾക്കും അവരുടെ സ്വന്തം കൺട്രോളർ ക്ലാസുകൾക്കും പ്രത്യേക ഫയലുകൾ ഉണ്ടായിരുന്നു. തൽഫലമായി, സിസ്റ്റം ഇതിൽ നിന്ന് രൂപാന്തരപ്പെട്ടു ...

...ഇതിലേക്ക്:

ചില മൊഡ്യൂളുകൾ പ്രത്യേക സൈറ്റുകൾ (എക്സിക്യൂട്ടബിൾ പ്രോജക്റ്റ്) നടപ്പിലാക്കുന്നു, പൂർണ്ണമായും വേറിട്ട പ്രവർത്തനക്ഷമതയും ഭാഗികമായി അൽപ്പം വേറിട്ടതും കൂടുതൽ ശ്രദ്ധ കേന്ദ്രീകരിച്ചതുമായ വികസനം കാരണം. ഈ:

• സൈറ്റ് - പെർവയ വെർസിയ സൈറ്റ് dodopizza.ru.

• കയറ്റുമതി: ഡോഡോ ഐഎസിൽ നിന്നുള്ള റിപ്പോർട്ടുകൾ 1C നായി അപ്‌ലോഡ് ചെയ്യുന്നു. 

• വ്യക്തിപരം - ജീവനക്കാരന്റെ സ്വകാര്യ അക്കൗണ്ട്. ഇത് വെവ്വേറെ വികസിപ്പിച്ചെടുത്തു, കൂടാതെ അതിന്റേതായ എൻട്രി പോയിന്റും പ്രത്യേക രൂപകൽപ്പനയും ഉണ്ട്.

• fs — സ്റ്റാറ്റിക്സ് ഹോസ്റ്റുചെയ്യുന്നതിനുള്ള ഒരു പ്രോജക്റ്റ്. പിന്നീട് ഞങ്ങൾ അതിൽ നിന്ന് മാറി, എല്ലാ സ്റ്റാറ്റിക്സും Akamai CDN-ലേക്ക് നീക്കി. 

ബാക്കിയുള്ള ബ്ലോക്കുകൾ BackOffice ആപ്ലിക്കേഷനിൽ ഉണ്ടായിരുന്നു. 

പേരിന്റെ വിശദീകരണം:

• കാഷ്യർ - റെസ്റ്റോറന്റ് കാഷ്യർ.

• 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 ൽ റൊമാനിയയിൽ ഒരു ഓപ്പണിംഗ് ഉണ്ടായിരുന്നു, യു‌എസ്‌എയിൽ ഒരു ഓപ്പണിംഗ് തയ്യാറെടുക്കുന്നു.

ശൃംഖല വളരെ വേഗത്തിൽ വളർന്നു, പുതിയ രാജ്യങ്ങൾ തുറന്നു, പിസ്സേരിയകളുടെ പുതിയ ഫോർമാറ്റുകൾ പ്രത്യക്ഷപ്പെട്ടു, ഉദാഹരണത്തിന്, ഫുഡ് കോർട്ടിൽ ഒരു പിസ്സേറിയ തുറന്നു. ഇതിനെല്ലാം ഡോഡോ ഐഎസ് ഫംഗ്‌ഷനുകളുടെ വിപുലീകരണത്തിന് പ്രത്യേക ശ്രദ്ധ ആവശ്യമാണ്. ഈ പ്രവർത്തനങ്ങളെല്ലാം കൂടാതെ, അടുക്കളയിൽ ട്രാക്ക് ചെയ്യാതെ, സിസ്റ്റത്തിലെ ഉൽപ്പന്നങ്ങളും നഷ്ടങ്ങളും കണക്കാക്കാതെ, ഫുഡ് കോർട്ട് ഹാളിൽ ഒരു ഓർഡർ പുറപ്പെടുവിക്കുന്നത് പ്രദർശിപ്പിക്കാതെ, ഞങ്ങൾ “ശരിയായ” വാസ്തുവിദ്യയെക്കുറിച്ചും “ശരിയായ” സമീപനത്തെക്കുറിച്ചും സംസാരിക്കില്ല. ഇപ്പോൾ വികസനം.

വാസ്തുവിദ്യയുടെ സമയോചിതമായ പുനരവലോകനത്തിനും സാങ്കേതിക പ്രശ്‌നങ്ങളിൽ പൊതുവെ ശ്രദ്ധിക്കുന്നതിനുമുള്ള മറ്റൊരു തടസ്സം 2014 ലെ പ്രതിസന്ധിയായിരുന്നു. ഇതുപോലുള്ള കാര്യങ്ങൾ ടീമുകൾക്ക് വളരാനുള്ള അവസരങ്ങളെ, പ്രത്യേകിച്ച് ഡോഡോ പിസ്സയെപ്പോലുള്ള ഒരു യുവ ബിസിനസിന് സാരമായി ബാധിച്ചു.

സഹായിച്ച ദ്രുത പരിഹാരങ്ങൾ

പ്രശ്നങ്ങൾക്ക് പരിഹാരം ആവശ്യമാണ്. പരമ്പരാഗതമായി, പരിഹാരങ്ങളെ 2 ഗ്രൂപ്പുകളായി തിരിക്കാം:

• തീ കെടുത്തുകയും സുരക്ഷിതത്വത്തിന്റെ ഒരു ചെറിയ മാർജിൻ നൽകുകയും നമുക്ക് മാറാൻ സമയം വാങ്ങുകയും ചെയ്യുന്ന വേഗതയേറിയവ.

• വ്യവസ്ഥാപിതവും, അതിനാൽ, നീളവും. നിരവധി മൊഡ്യൂളുകളുടെ പുനർനിർമ്മാണം, ഒരു മോണോലിത്തിക്ക് ആർക്കിടെക്ചറിനെ പ്രത്യേക സേവനങ്ങളായി വിഭജിക്കുക (അവയിൽ മിക്കതും മൈക്രോ അല്ല, മറിച്ച് മാക്രോ സേവനങ്ങളാണ്, അതിൽ ചിലത് ഉണ്ട്. ആൻഡ്രി മോറെവ്സ്കിയുടെ റിപ്പോർട്ട്). 

പെട്ടെന്നുള്ള മാറ്റങ്ങളുടെ വരണ്ട പട്ടിക ഇപ്രകാരമാണ്:

അടിസ്ഥാന മാസ്റ്റർ സ്കെയിൽ അപ്പ് ചെയ്യുക

തീർച്ചയായും, ലോഡുകളെ നേരിടാൻ ആദ്യം ചെയ്യുന്നത് സെർവറിന്റെ ശേഷി വർദ്ധിപ്പിക്കുക എന്നതാണ്. മാസ്റ്റർ ഡാറ്റാബേസിനും വെബ് സെർവറിനുമായി ഇത് ചെയ്തു. അയ്യോ, ഇത് ഒരു നിശ്ചിത പരിധി വരെ മാത്രമേ സാധ്യമാകൂ, അപ്പോൾ അത് വളരെ ചെലവേറിയതായിത്തീരുന്നു.

2014 മുതൽ, ഞങ്ങൾ അസുറിലേക്ക് മാറി, ഈ വിഷയത്തെക്കുറിച്ചും ഞങ്ങൾ ലേഖനത്തിൽ എഴുതി.മൈക്രോസോഫ്റ്റ് അസ്യൂർ ക്ലൗഡ് ഉപയോഗിച്ച് ഡോഡോ പിസ്സ എങ്ങനെയാണ് പിസ്സ വിതരണം ചെയ്യുന്നത്". എന്നാൽ അടിസ്ഥാനത്തിനായുള്ള സെർവറിലെ വർദ്ധനവിന് ശേഷം, അവർ ചെലവിനെതിരെ രംഗത്തെത്തി. 

വായനയ്ക്കുള്ള അടിസ്ഥാന പകർപ്പുകൾ

അടിത്തറയ്ക്കായി രണ്ട് പകർപ്പുകൾ നിർമ്മിച്ചു:

ReadReplica റഫറൻസ് അഭ്യർത്ഥനകൾക്കായി. ഡയറക്‌ടറികൾ, തരം, നഗരം, തെരുവ്, പിസ്സേരിയ, ഉൽപ്പന്നങ്ങൾ (പതുക്കെ മാറിയ ഡൊമെയ്‌ൻ), കൂടാതെ ചെറിയ കാലതാമസം സ്വീകാര്യമായ ഇന്റർഫേസുകളിൽ വായിക്കാൻ ഇത് ഉപയോഗിക്കുന്നു. ഈ പകർപ്പുകളിൽ 2 എണ്ണം ഉണ്ടായിരുന്നു, മാസ്റ്റേഴ്സിന്റെ അതേ രീതിയിൽ ഞങ്ങൾ അവയുടെ ലഭ്യത ഉറപ്പാക്കി.

റിപ്പോർട്ട് അഭ്യർത്ഥനകൾക്കായുള്ള റെപ്ലിക്ക. ഈ ഡാറ്റാബേസിന് ലഭ്യത കുറവായിരുന്നു, എന്നാൽ എല്ലാ റിപ്പോർട്ടുകളും അതിലേക്ക് പോയി. വലിയ ഡാറ്റാ വീണ്ടും കണക്കുകൂട്ടലുകൾക്കായി അവർക്ക് കനത്ത അഭ്യർത്ഥനകൾ ഉണ്ടാകട്ടെ, പക്ഷേ അവ പ്രധാന ഡാറ്റാബേസിനെയും പ്രവർത്തന ഇന്റർഫേസുകളെയും ബാധിക്കില്ല. 

കോഡിലെ കാഷെകൾ

കോഡിൽ എവിടെയും കാഷെകൾ ഇല്ലായിരുന്നു (എല്ലാം). ഇത് ലോഡുചെയ്ത ഡാറ്റാബേസിലേക്കുള്ള അധിക അഭ്യർത്ഥനകളിലേക്ക് നയിച്ചു, എല്ലായ്പ്പോഴും ആവശ്യമില്ല. കാഷെകൾ ആദ്യം മെമ്മറിയിലും ഒരു ബാഹ്യ കാഷെ സേവനത്തിലും ആയിരുന്നു, അത് Redis ആയിരുന്നു. കാലക്രമേണ എല്ലാം അസാധുവായി, ക്രമീകരണങ്ങൾ കോഡിൽ വ്യക്തമാക്കിയിട്ടുണ്ട്.

ഒന്നിലധികം ബാക്കെൻഡ് സെർവറുകൾ

വർദ്ധിച്ച ജോലിഭാരം കൈകാര്യം ചെയ്യാൻ ആപ്ലിക്കേഷന്റെ ബാക്കെൻഡും സ്കെയിൽ ചെയ്യേണ്ടതുണ്ട്. ഒരു ഐഐഎസ്-സെർവറിൽ നിന്ന് ഒരു ക്ലസ്റ്റർ നിർമ്മിക്കേണ്ടത് ആവശ്യമാണ്. ഞങ്ങൾ വീണ്ടും ഷെഡ്യൂൾ ചെയ്തു അപേക്ഷാ സെഷൻ മെമ്മറി മുതൽ RedisCache വരെ, ഇത് റൗണ്ട് റോബിൻ ഉപയോഗിച്ച് ലളിതമായ ലോഡ് ബാലൻസറിന് പിന്നിൽ നിരവധി സെർവറുകൾ നിർമ്മിക്കുന്നത് സാധ്യമാക്കി. ആദ്യം, കാഷെകൾക്കായി അതേ റെഡിസ് ഉപയോഗിച്ചു, പിന്നീട് അത് പലതായി വിഭജിച്ചു. 

തൽഫലമായി, വാസ്തുവിദ്യ കൂടുതൽ സങ്കീർണ്ണമായി ...

… എന്നാൽ കുറച്ച് പിരിമുറുക്കം നീങ്ങി.

തുടർന്ന് ഞങ്ങൾ ഏറ്റെടുത്ത ലോഡ് ചെയ്ത ഘടകങ്ങൾ വീണ്ടും ചെയ്യേണ്ടത് ആവശ്യമാണ്. അടുത്ത ഭാഗത്തിൽ നമ്മൾ ഇതിനെക്കുറിച്ച് സംസാരിക്കും.

അവലംബം: www.habr.com