ഡോഡോ IS വാസ്തുവിദ്യയുടെ ചരിത്രം: ബാക്ക് ഓഫീസ് പാത

ഹബർ ലോകത്തെ മാറ്റുകയാണ്. ഒരു വർഷത്തിലേറെയായി ഞങ്ങൾ ബ്ലോഗിംഗ് തുടങ്ങിയിട്ട്. ഏകദേശം ആറ് മാസം മുമ്പ് ഞങ്ങൾക്ക് ഖബ്രോവ്സ്ക് നിവാസികളിൽ നിന്ന് തികച്ചും യുക്തിസഹമായ ഫീഡ്ബാക്ക് ലഭിച്ചു: "ഡോഡോ, നിങ്ങൾക്ക് സ്വന്തമായി ഒരു സിസ്റ്റം ഉണ്ടെന്ന് നിങ്ങൾ എല്ലായിടത്തും പറയുന്നു. ഇത് ഏത് തരത്തിലുള്ള സംവിധാനമാണ്? പിന്നെ എന്തിനാണ് പിസേറിയ ശൃംഖലയ്ക്ക് ഇത് ആവശ്യമായി വരുന്നത്?

ഞങ്ങൾ ഇരുന്നു ചിന്തിച്ചു, നിങ്ങൾ പറഞ്ഞത് ശരിയാണെന്ന് ഞങ്ങൾ മനസ്സിലാക്കി. ഞങ്ങൾ എല്ലാം വിരലുകൾ കൊണ്ട് വിശദീകരിക്കാൻ ശ്രമിക്കുന്നു, പക്ഷേ അത് കീറിപ്പറിഞ്ഞ കഷണങ്ങളായി പുറത്തുവരുന്നു, സിസ്റ്റത്തിന്റെ പൂർണ്ണമായ വിവരണം എവിടെയും ഇല്ല. അങ്ങനെ വിവരങ്ങൾ ശേഖരിക്കാനും രചയിതാക്കളെ തിരയാനും ഡോഡോ ഐഎസിനെക്കുറിച്ചുള്ള ലേഖനങ്ങളുടെ പരമ്പര എഴുതാനുമുള്ള ഒരു നീണ്ട യാത്ര ആരംഭിച്ചു. നമുക്ക് പോകാം!

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

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

1. ഡോഡോ ഐഎസിലെ ആദ്യകാല മോണോലിത്ത് (2011-2015). (പുരോഗതിയിൽ...)
2. ബാക്ക് ഓഫീസ് പാത: പ്രത്യേക ബേസും ബസും. (നീ ഇവിടെയാണ്)
3. ക്ലയന്റ് സൈഡ് പാത്ത്: അടിത്തറയ്ക്ക് മുകളിലുള്ള മുഖം (2016-2017). (പുരോഗതിയിൽ...)
4. യഥാർത്ഥ മൈക്രോസർവീസുകളുടെ ചരിത്രം. (2018-2019). (പുരോഗതിയിൽ...)
5. മോണോലിത്തിന്റെ വെട്ടിയെടുത്ത് വാസ്തുവിദ്യയുടെ സ്ഥിരത പൂർത്തിയാക്കി. (പുരോഗതിയിൽ...)

നിങ്ങൾക്ക് മറ്റെന്തെങ്കിലും പഠിക്കാൻ താൽപ്പര്യമുണ്ടെങ്കിൽ, അഭിപ്രായങ്ങളിൽ എഴുതുക.

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

പരമ്പരാഗതമായി, ചില ലക്ഷ്യങ്ങൾ കൈവരിക്കുന്നതിന് പരസ്പരം ഇടപഴകുന്ന ഘടകങ്ങളുടെ (സാങ്കേതിക അല്ലെങ്കിൽ ഉയർന്ന തലത്തിലുള്ള) ബിസിനസ് മൊഡ്യൂളുകളായി ഞങ്ങൾ ഒരു സിസ്റ്റത്തെ കാണുന്നു. അത്തരമൊരു കാഴ്ചപ്പാട് രൂപകൽപ്പനയ്ക്ക് ന്യായമാണെങ്കിലും, വിവരണത്തിനും മനസ്സിലാക്കലിനും ഇത് പൂർണ്ണമായും അനുയോജ്യമല്ല. നിരവധി കാരണങ്ങളുണ്ട്:

• യാഥാർത്ഥ്യം കടലാസിൽ ഉള്ളതിൽ നിന്ന് വ്യത്യസ്തമാണ്. എല്ലാം ആസൂത്രണം ചെയ്തതുപോലെ പ്രവർത്തിക്കുന്നില്ല. എല്ലാം യഥാർത്ഥത്തിൽ എങ്ങനെ മാറുകയും പ്രവർത്തിക്കുകയും ചെയ്യുന്നു എന്നതിൽ ഞങ്ങൾക്ക് താൽപ്പര്യമുണ്ട്.
• വിവരങ്ങളുടെ സ്ഥിരമായ അവതരണം. വാസ്തവത്തിൽ, നിങ്ങൾക്ക് തുടക്കം മുതൽ നിലവിലെ അവസ്ഥയിലേക്ക് കാലക്രമത്തിൽ പോകാം.
• ലളിതം മുതൽ സങ്കീർണ്ണത വരെ. സാർവത്രികമല്ല, പക്ഷേ നമ്മുടെ കാര്യത്തിൽ അത് അങ്ങനെയാണ്. വാസ്തുവിദ്യ ലളിതമായ സമീപനങ്ങളിൽ നിന്ന് കൂടുതൽ സങ്കീർണ്ണമായവയിലേക്ക് നീങ്ങി. പലപ്പോഴും, സങ്കീർണ്ണതയിലൂടെ, നടപ്പാക്കൽ വേഗതയുടെയും സ്ഥിരതയുടെയും പ്രശ്നങ്ങൾ, അതുപോലെ തന്നെ പ്രവർത്തനരഹിതമായ ആവശ്യകതകളുടെ പട്ടികയിൽ നിന്നുള്ള ഡസൻ കണക്കിന് മറ്റ് പ്രോപ്പർട്ടികൾ (ഇവിടെ മറ്റ് ആവശ്യകതകളുമായി സങ്കീർണ്ണതയെ വ്യത്യസ്തമാക്കുന്നതിനെക്കുറിച്ച് നന്നായി സംസാരിച്ചു).

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

2020-ഓടെ, ഇത് കുറച്ചുകൂടി സങ്കീർണ്ണമാവുകയും ഇതുപോലെയാകുകയും ചെയ്തു:

ഈ പരിണാമം എങ്ങനെ സംഭവിച്ചു? സിസ്റ്റത്തിന്റെ വിവിധ ഭാഗങ്ങൾ ആവശ്യമായിരിക്കുന്നത് എന്തുകൊണ്ട്? എന്ത് വാസ്തുവിദ്യാ തീരുമാനങ്ങളാണ് എടുത്തത്, എന്തുകൊണ്ട്? ഈ ലേഖന പരമ്പരയിൽ നമുക്ക് കണ്ടെത്താം.

2016 ലെ ആദ്യ പ്രശ്നങ്ങൾ: എന്തുകൊണ്ടാണ് സേവനങ്ങൾ മോണോലിത്തിൽ നിന്ന് പുറത്തുപോകേണ്ടത്?

ഈ പരമ്പരയിലെ ആദ്യ ലേഖനങ്ങൾ മോണോലിത്തിൽ നിന്ന് ആദ്യം വേർപെടുത്തിയ സേവനങ്ങളെക്കുറിച്ചായിരിക്കും. നിങ്ങളെ സന്ദർഭത്തിലേക്ക് കൊണ്ടുവരാൻ, 2016 ന്റെ തുടക്കത്തിൽ ഞങ്ങൾക്ക് സിസ്റ്റത്തിൽ ഉണ്ടായിരുന്ന പ്രശ്‌നങ്ങൾ എന്താണെന്ന് ഞാൻ നിങ്ങളോട് പറയും, സേവനങ്ങളുടെ വേർതിരിവ് ഞങ്ങൾക്ക് നേരിടേണ്ടി വന്നു.

ഡോഡോ ഐഎസിൽ അക്കാലത്ത് നിലവിലുണ്ടായിരുന്ന എല്ലാ ആപ്ലിക്കേഷനുകളും അവരുടെ റെക്കോർഡുകൾ എഴുതിയ ഒരൊറ്റ MySql ഡാറ്റാബേസ്. അനന്തരഫലങ്ങൾ ഇവയായിരുന്നു:

• കനത്ത ലോഡ് (85% അഭ്യർത്ഥനകൾ വായിച്ചു).
• അടിത്തറ വളരുകയായിരുന്നു. ഇക്കാരണത്താൽ, ചെലവും പിന്തുണയും ഒരു പ്രശ്നമായി മാറി.
• പരാജയത്തിന്റെ ഒരൊറ്റ പോയിന്റ്. ഡാറ്റാബേസിലേക്ക് എഴുതുന്ന ഒരു ആപ്ലിക്കേഷൻ പെട്ടെന്ന് കൂടുതൽ സജീവമായി ചെയ്യാൻ തുടങ്ങിയാൽ, മറ്റ് ആപ്ലിക്കേഷനുകൾ അതിന്റെ സ്വാധീനം അനുഭവിച്ചു.
• സംഭരണത്തിലും അന്വേഷണത്തിലും കാര്യക്ഷമതയില്ലായ്മ. പലപ്പോഴും ഡാറ്റ സംഭരിക്കുന്നത് ചില സാഹചര്യങ്ങൾക്ക് സൗകര്യപ്രദവും എന്നാൽ മറ്റുള്ളവയ്ക്ക് അല്ലാത്തതുമായ ചില ഘടനയിലാണ്. സൂചികകൾ ചില പ്രവർത്തനങ്ങളെ വേഗത്തിലാക്കുന്നു, എന്നാൽ മറ്റുള്ളവയെ മന്ദഗതിയിലാക്കാം.
• ചില പ്രശ്‌നങ്ങൾ തിടുക്കത്തിൽ നിർമ്മിച്ച കാഷെകളും ഡാറ്റാബേസുകളിലേക്ക് റീഡ്-റെപ്ലിക്കുകളും ഉപയോഗിച്ച് പരിഹരിച്ചു (ഇത് ഒരു പ്രത്യേക ലേഖനത്തിൽ ചർച്ചചെയ്യും), പക്ഷേ അവ സമയം നേടാൻ ഞങ്ങളെ അനുവദിച്ചു, മാത്രമല്ല അടിസ്ഥാനപരമായി പ്രശ്നം പരിഹരിച്ചില്ല.

മോണോലിത്തിന്റെ സാന്നിധ്യം തന്നെയായിരുന്നു പ്രശ്നം. അനന്തരഫലങ്ങൾ ഇവയായിരുന്നു:

• അതുല്യവും അപൂർവവുമായ റിലീസുകൾ.
• വലിയൊരു വിഭാഗം ആളുകളുടെ സഹകരണത്തോടെയുള്ള വികസനമാണ് ബുദ്ധിമുട്ട്.
• പുതിയ സാങ്കേതികവിദ്യകൾ, പുതിയ ചട്ടക്കൂടുകൾ, ലൈബ്രറികൾ എന്നിവ അവതരിപ്പിക്കാനുള്ള കഴിവില്ലായ്മ.

ബേസ്, മോണോലിത്ത് എന്നിവയിലെ പ്രശ്നങ്ങൾ പലതവണ വിവരിച്ചിട്ടുണ്ട്, ഉദാഹരണത്തിന്, 2018-ന്റെ തുടക്കത്തിൽ ക്രാഷുകളുടെ പശ്ചാത്തലത്തിൽ (മഞ്ച് പോലെയാകുക, അല്ലെങ്കിൽ സാങ്കേതിക കടത്തെക്കുറിച്ച് കുറച്ച് വാക്കുകൾ, ഡോഡോ ഐഎസ് നിർത്തിയ ദിവസം. അസിൻക്രണസ് സ്ക്രിപ്റ്റ് и ഫീനിക്സ് കുടുംബത്തിൽ നിന്നുള്ള ഡോഡോ പക്ഷിയുടെ കഥ. ഡോഡോ ഐഎസിന്റെ മഹത്തായ പതനം), അതിനാൽ ഞാൻ അധികം താമസിക്കില്ല. സേവനങ്ങൾ വികസിപ്പിക്കുമ്പോൾ കൂടുതൽ വഴക്കം നൽകാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നുവെന്ന് ഞാൻ പറയട്ടെ. ഒന്നാമതായി, ഇത് മുഴുവൻ സിസ്റ്റത്തിലും ഏറ്റവുമധികം ലോഡ് ചെയ്തതും റൂട്ട് ആയതുമായവയെക്കുറിച്ചാണ് - ഓത്ത്, ട്രാക്കർ.

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

ചാപ്റ്റർ നാവിഗേഷൻ

1. മോണോലിത്തിന്റെ സ്കീം 2016
2. ഞങ്ങൾ മോണോലിത്ത് അൺലോഡ് ചെയ്യാൻ തുടങ്ങുന്നു: ഓത്തും ട്രാക്കറും വേർതിരിക്കുന്നു
   
3. Auth എന്താണ് ചെയ്യുന്നത്?
4. ലോഡ്സ് എവിടെ നിന്ന് വരുന്നു?
5. ഓത്ത് അൺലോഡ് ചെയ്യുന്നു
6. ട്രാക്കർ എന്താണ് ചെയ്യുന്നത്?
7. ലോഡ്സ് എവിടെ നിന്ന് വരുന്നു?
8. ട്രാക്കർ അൺലോഡ് ചെയ്യുന്നു

മോണോലിത്തിന്റെ സ്കീം 2016

2016 ഡോഡോ ഐഎസ് മോണോലിത്തിന്റെ പ്രധാന ബ്ലോക്കുകൾ ഇവിടെയുണ്ട്, അവയുടെ പ്രധാന ജോലികളുടെ ഒരു തകർച്ചയാണ് ചുവടെയുള്ളത്.

ഡെലിവറി ക്യാഷ് ഡെസ്ക്. കൊറിയറുകൾക്കുള്ള അക്കൗണ്ടിംഗ്, കൊറിയറുകൾക്ക് ഓർഡറുകൾ നൽകൽ.
കോൺടാക്റ്റ് സെന്റർ. ഓപ്പറേറ്റർ മുഖേനയുള്ള ഓർഡറുകൾ സ്വീകരിക്കുന്നു.
സൈറ്റ്. ഞങ്ങളുടെ വെബ്സൈറ്റുകൾ (dodopizza.ru, dodopizza.co.uk, dodopizza.by, മുതലായവ).
ഓത്ത്. ബാക്ക് ഓഫീസിനുള്ള അംഗീകാരവും പ്രാമാണീകരണ സേവനവും.
ട്രാക്കർ. അടുക്കള ഓർഡർ ട്രാക്കർ. ഒരു ഓർഡർ തയ്യാറാക്കുമ്പോൾ റെഡിനെസ് സ്റ്റാറ്റസുകൾ അടയാളപ്പെടുത്തുന്നതിനുള്ള സേവനം.
റെസ്റ്റോറന്റ് ക്യാഷ് ഡെസ്ക്. ഒരു റെസ്റ്റോറന്റിൽ ഓർഡറുകൾ എടുക്കൽ, കാഷ്യർ ഇന്റർഫേസുകൾ.
കയറ്റുമതി. അക്കൗണ്ടിംഗിനായി 1C-യിൽ റിപ്പോർട്ടുകൾ അപ്‌ലോഡ് ചെയ്യുന്നു.
അലേർട്ടുകളും ഇൻവോയ്സുകളും. അടുക്കളയിലെ വോയിസ് കമാൻഡുകൾ (ഉദാഹരണത്തിന്, "പുതിയ പിസ്സ എത്തി") + കൊറിയറുകൾക്കുള്ള ഇൻവോയ്സുകളുടെ പ്രിന്റിംഗ്.
ഷിഫ്റ്റ് മാനേജർ. ഒരു ഷിഫ്റ്റ് മാനേജരുടെ പ്രവർത്തനത്തിനുള്ള ഇന്റർഫേസുകൾ: ഓർഡറുകളുടെ പട്ടിക, ഉൽപ്പാദനക്ഷമത ചാർട്ടുകൾ, ജീവനക്കാരെ ഷിഫ്റ്റുകളിലേക്ക് കൊണ്ടുവരിക.
ഓഫീസ് മാനേജർ. ഫ്രാഞ്ചൈസികളുടെയും മാനേജർമാരുടെയും ജോലികൾക്കായുള്ള ഇന്റർഫേസുകൾ: ജീവനക്കാരുടെ സ്വീകരണം, പിസ്സേറിയയുടെ പ്രവർത്തനത്തെക്കുറിച്ചുള്ള റിപ്പോർട്ടുകൾ.
റെസ്റ്റോറന്റ് ബോർഡ്. പിസേറിയകളിലെ ടിവികളിൽ മെനുകൾ പ്രദർശിപ്പിക്കുന്നു.
അഡ്മിൻ. ഒരു നിർദ്ദിഷ്‌ട പിസ്സേറിയയ്‌ക്കുള്ള ക്രമീകരണങ്ങൾ: മെനു, വിലകൾ, അക്കൗണ്ടിംഗ്, പ്രൊമോഷണൽ കോഡുകൾ, പ്രമോഷനുകൾ, സൈറ്റിനായുള്ള ബാനറുകൾ മുതലായവ.
ജീവനക്കാരുടെ സ്വകാര്യ അക്കൗണ്ട്. ജീവനക്കാരുടെ ജോലി ഷെഡ്യൂളുകൾ, ജീവനക്കാരെക്കുറിച്ചുള്ള വിവരങ്ങൾ.
അടുക്കള മോട്ടിവേഷൻ ബോർഡ്. അടുക്കളയിൽ തൂങ്ങിക്കിടക്കുന്ന ഒരു പ്രത്യേക സ്ക്രീൻ, പിസ്സ നിർമ്മാതാക്കളുടെ വേഗത പ്രദർശിപ്പിക്കുന്നു.
വാര്ത്താവിനിമയം. എസ്എംഎസും ഇമെയിലും അയയ്ക്കുന്നു.
ഫയൽ സ്റ്റോറേജ്. സ്റ്റാറ്റിക് ഫയലുകൾ സ്വീകരിക്കുന്നതിനും നൽകുന്നതിനുമുള്ള സ്വന്തം സേവനം.

പ്രശ്നങ്ങൾ പരിഹരിക്കാനുള്ള ആദ്യ ശ്രമങ്ങൾ ഞങ്ങളെ സഹായിച്ചു, പക്ഷേ അവ താൽക്കാലിക ആശ്വാസം മാത്രമായിരുന്നു. അവ സിസ്റ്റം സൊല്യൂഷനുകളായി മാറിയില്ല, അതിനാൽ അടിസ്ഥാനങ്ങൾ ഉപയോഗിച്ച് എന്തെങ്കിലും ചെയ്യേണ്ടതുണ്ടെന്ന് വ്യക്തമായി. ഉദാഹരണത്തിന്, പൊതുവായ ഡാറ്റാബേസിനെ കൂടുതൽ പ്രത്യേകമായി വിഭജിക്കുക.

ഞങ്ങൾ മോണോലിത്ത് അൺലോഡ് ചെയ്യാൻ തുടങ്ങുന്നു: ഓത്തും ട്രാക്കറും വേർതിരിക്കുന്നു

മറ്റുള്ളവയേക്കാൾ കൂടുതൽ ഡാറ്റാബേസിൽ നിന്ന് എഴുതുകയും വായിക്കുകയും ചെയ്ത പ്രധാന സേവനങ്ങൾ:

1. ഓത്ത് ബാക്ക് ഓഫീസിനുള്ള അംഗീകാരവും പ്രാമാണീകരണ സേവനവും.
2. ട്രാക്കർ. അടുക്കള ഓർഡർ ട്രാക്കർ. ഒരു ഓർഡർ തയ്യാറാക്കുമ്പോൾ റെഡിനെസ് സ്റ്റാറ്റസുകൾ അടയാളപ്പെടുത്തുന്നതിനുള്ള സേവനം.

Auth എന്താണ് ചെയ്യുന്നത്?

ഉപയോക്താക്കൾ ബാക്ക് ഓഫീസിലേക്ക് ലോഗിൻ ചെയ്യുന്ന ഒരു സേവനമാണ് ഓത്ത് (ക്ലയന്റ് ഭാഗത്ത് ഒരു പ്രത്യേക സ്വതന്ത്ര ലോഗിൻ ഉണ്ട്). ശരിയായ ആക്‌സസ് അവകാശങ്ങൾ നിലവിലുണ്ടെന്നും അവസാന ലോഗിൻ മുതൽ ഈ അവകാശങ്ങൾ മാറിയിട്ടില്ലെന്നും ഉറപ്പാക്കാനുള്ള അഭ്യർത്ഥനയിലും ഇത് പരാമർശിച്ചിരിക്കുന്നു. ഉപകരണങ്ങൾ അതിലൂടെ പിസ്സേറിയയിലേക്ക് പ്രവേശിക്കുന്നു.

ഉദാഹരണത്തിന്, ഹാളിൽ തൂക്കിയിട്ടിരിക്കുന്ന ടിവിയിൽ പൂർത്തിയാക്കിയ ഓർഡറുകളുടെ സ്റ്റാറ്റസ് ഉള്ള ഒരു ഡിസ്പ്ലേ തുറക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. തുടർന്ന് ഞങ്ങൾ auth.dodopizza.ru തുറക്കുന്നു, "ഉപകരണമായി ലോഗിൻ ചെയ്യുക" തിരഞ്ഞെടുക്കുക, ഷിഫ്റ്റ് മാനേജരുടെ കമ്പ്യൂട്ടറിലെ ഒരു പ്രത്യേക പേജിൽ നൽകാവുന്ന ഒരു കോഡ് ദൃശ്യമാകും, ഇത് ഉപകരണത്തിന്റെ തരം (ഉപകരണം) സൂചിപ്പിക്കുന്നു. ടിവി തന്നെ അതിന്റെ പിസേറിയയുടെ ആവശ്യമുള്ള ഇന്റർഫേസിലേക്ക് പോയി ഓർഡറുകൾ തയ്യാറായ ഉപഭോക്താക്കളുടെ പേരുകൾ അവിടെ പ്രദർശിപ്പിക്കാൻ തുടങ്ങും.

ലോഡ്സ് എവിടെ നിന്ന് വരുന്നു?

ലോഗിൻ ചെയ്‌ത ഓരോ ബാക്ക് ഓഫീസ് ഉപയോക്താവും ഓരോ അഭ്യർത്ഥനയ്‌ക്കുമുള്ള ഡാറ്റാബേസിലേക്ക്, ഉപയോക്തൃ പട്ടികയിലേക്ക് പോകുന്നു, ഒരു sql അന്വേഷണത്തിലൂടെ ഉപയോക്താവിനെ അവിടെ നിന്ന് പുറത്തെടുക്കുകയും അയാൾക്ക് ഈ പേജിലേക്ക് ആവശ്യമായ ആക്‌സസും അവകാശങ്ങളും ഉണ്ടോയെന്ന് പരിശോധിക്കുകയും ചെയ്യുന്നു.

ഓരോ ഉപകരണങ്ങളും ഉപകരണ ടേബിളിൽ മാത്രം പ്രവർത്തിക്കുന്നു, അതിന്റെ റോളും അതിന്റെ ആക്‌സസുകളും പരിശോധിക്കുക. മാസ്റ്റർ ഡാറ്റാബേസിലേക്കുള്ള ധാരാളം അഭ്യർത്ഥനകൾ ഈ പ്രവർത്തനങ്ങളിൽ അതിന്റെ ലോഡിംഗിലേക്കും പൊതുവായ ഡാറ്റാബേസ് ഉറവിടങ്ങൾ പാഴാക്കുന്നതിലേക്കും നയിക്കുന്നു.

ഓത്ത് അൺലോഡ് ചെയ്യുന്നു

Auth-ന് ഒരു ഒറ്റപ്പെട്ട ഡൊമെയ്‌ൻ ഉണ്ട്, അതായത്, ഉപയോക്താക്കൾ, ലോഗിനുകൾ അല്ലെങ്കിൽ ഉപകരണങ്ങൾ എന്നിവയെ കുറിച്ചുള്ള ഡാറ്റ സേവനത്തിൽ പ്രവേശിക്കുന്നു (നിലവിൽ ഭാവിയിൽ) അവിടെ തുടരുന്നു. ആർക്കെങ്കിലും അവരെ ആവശ്യമുണ്ടെങ്കിൽ, അവൻ ഡാറ്റയ്ക്കായി ഈ സേവനത്തിലേക്ക് പോകും.

ആയിരുന്നു. ജോലിയുടെ ഒഴുക്ക് തുടക്കത്തിൽ ഇപ്രകാരമായിരുന്നു:

ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് കുറച്ച് വിശദീകരിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു:

1. ഒരു ബാഹ്യ അഭ്യർത്ഥന ബാക്കെൻഡിലേക്ക് വരുന്നു (അവിടെ Asp.Net MVC), അതിനോടൊപ്പം ഒരു സെഷൻ കുക്കി കൊണ്ടുവരുന്നു, ഇത് Redis(1) ൽ നിന്ന് സെഷൻ ഡാറ്റ നേടുന്നതിന് ഉപയോഗിക്കുന്നു. ഒന്നുകിൽ ഇതിൽ ആക്‌സസ്സ് സംബന്ധിച്ച വിവരങ്ങൾ അടങ്ങിയിരിക്കുന്നു, തുടർന്ന് കൺട്രോളറിലേക്കുള്ള ആക്‌സസ് തുറന്നിരിക്കുന്നു (3,4), അല്ലെങ്കിൽ ഇല്ല.
2. പ്രവേശനം ഇല്ലെങ്കിൽ, നിങ്ങൾ അംഗീകാര നടപടിക്രമത്തിലൂടെ പോകേണ്ടതുണ്ട്. ഇവിടെ, ലാളിത്യത്തിനായി, അതേ ആട്രിബ്യൂട്ടിൽ പാതയുടെ ഭാഗമായി ഇത് കാണിക്കുന്നു, എന്നിരുന്നാലും ഇത് ലോഗിൻ പേജിലേക്കുള്ള ഒരു പരിവർത്തനമാണ്. ഒരു പോസിറ്റീവ് സാഹചര്യത്തിന്റെ കാര്യത്തിൽ, ഞങ്ങൾക്ക് ശരിയായി പൂരിപ്പിച്ച സെഷൻ ലഭിക്കുകയും ബാക്ക്ഓഫീസ് കൺട്രോളറിലേക്ക് പോകുകയും ചെയ്യും.
3. ഡാറ്റ ഉണ്ടെങ്കിൽ, ഉപയോക്തൃ ഡാറ്റാബേസിലെ പ്രസക്തിക്കായി നിങ്ങൾ അത് പരിശോധിക്കേണ്ടതുണ്ട്. അവന്റെ റോൾ മാറിയോ, അവനെ ഇപ്പോൾ പേജിൽ അനുവദിക്കേണ്ടതല്ലേ? ഈ സാഹചര്യത്തിൽ, സെഷൻ (1) ലഭിച്ച ശേഷം, നിങ്ങൾ നേരിട്ട് ഡാറ്റാബേസിലേക്ക് പോയി ആധികാരികത ലോജിക് ലെയർ (2) ഉപയോഗിച്ച് ഉപയോക്താവിന്റെ ആക്സസ് പരിശോധിക്കേണ്ടതുണ്ട്. അടുത്തതായി, ലോഗിൻ പേജിലേക്ക് പോകുക അല്ലെങ്കിൽ കൺട്രോളറിലേക്ക് പോകുക. ഇതൊരു ലളിതമായ സംവിധാനമാണ്, പക്ഷേ പൂർണ്ണമായും നിലവാരമുള്ളതല്ല.
4. എല്ലാ നടപടിക്രമങ്ങളും പൂർത്തിയായാൽ, കൺട്രോളറുകളിലും രീതികളിലും ഞങ്ങൾ ലോജിക്കിൽ കൂടുതൽ ഒഴിവാക്കും.

ഉപയോക്തൃ ഡാറ്റ മറ്റെല്ലാ ഡാറ്റയിൽ നിന്നും വേർതിരിച്ചിരിക്കുന്നു, അത് ഒരു പ്രത്യേക അംഗത്വ പട്ടികയിൽ സംഭരിച്ചിരിക്കുന്നു, AuthService ലോജിക് ലെയറിൽ നിന്നുള്ള പ്രവർത്തനങ്ങൾ API രീതികളായി മാറിയേക്കാം. ഡൊമെയ്‌നിന്റെ അതിരുകൾ വളരെ വ്യക്തമായി നിർവചിച്ചിരിക്കുന്നു: ഉപയോക്താക്കൾ, അവരുടെ റോളുകൾ, ആക്‌സസ് ഡാറ്റ, ഇഷ്യൂ ചെയ്യൽ, ആക്‌സസ് റദ്ദാക്കൽ. എല്ലാം ഒരു പ്രത്യേക സേവനത്തിലേക്ക് മാറ്റാൻ കഴിയുമെന്ന് തോന്നുന്നു.

ആയി. അതാണ് അവർ ചെയ്തത്:

ഈ സമീപനത്തിന് നിരവധി പ്രശ്നങ്ങളുണ്ട്. ഉദാഹരണത്തിന്, ഒരു പ്രോസസ്സിനുള്ളിലെ ഒരു രീതിയെ വിളിക്കുന്നത് http വഴി ഒരു ബാഹ്യ സേവനത്തെ വിളിക്കുന്നതിന് തുല്യമല്ല. പ്രവർത്തനത്തിന്റെ ലേറ്റൻസി, വിശ്വാസ്യത, പിന്തുണ, സുതാര്യത എന്നിവ തികച്ചും വ്യത്യസ്തമാണ്. ആൻഡ്രി മോറെവ്സ്കി തന്റെ റിപ്പോർട്ടിൽ ഈ പ്രശ്നങ്ങളെക്കുറിച്ച് കൂടുതൽ വിശദമായി സംസാരിച്ചു "50 ഷേഡുകൾ മൈക്രോസർവീസുകൾ".

പ്രാമാണീകരണ സേവനവും അതിനൊപ്പം ഉപകരണ സേവനവും ബാക്ക് ഓഫീസിനായി ഉപയോഗിക്കുന്നു, അതായത്, ഉൽ‌പാദനത്തിൽ ഉപയോഗിക്കുന്ന സേവനങ്ങൾക്കും ഇന്റർഫേസുകൾക്കുമായി. ക്ലയന്റ് സേവനങ്ങൾക്കുള്ള പ്രാമാണീകരണം (വെബ്‌സൈറ്റ് അല്ലെങ്കിൽ മൊബൈൽ ആപ്ലിക്കേഷൻ പോലുള്ളവ) ഓത്ത് ഉപയോഗിക്കാതെ പ്രത്യേകം നടക്കുന്നു. വേർപിരിയലിന് ഏകദേശം ഒരു വർഷമെടുത്തു, ഇപ്പോൾ ഞങ്ങൾ ഈ വിഷയത്തിൽ വീണ്ടും പ്രവർത്തിക്കുന്നു, സിസ്റ്റം പുതിയ പ്രാമാണീകരണ സേവനങ്ങളിലേക്ക് (സ്റ്റാൻഡേർഡ് പ്രോട്ടോക്കോളുകൾക്കൊപ്പം) കൈമാറുന്നു.

എന്തുകൊണ്ടാണ് വേർപിരിയലിന് ഇത്രയും സമയം എടുത്തത്?
വഴിയിൽ നിരവധി പ്രശ്‌നങ്ങൾ ഉണ്ടായിരുന്നു, അത് ഞങ്ങളെ മന്ദഗതിയിലാക്കി:

1. ഉപയോക്താക്കൾ, ഉപകരണങ്ങൾ, പ്രാമാണീകരണം എന്നിവയെക്കുറിച്ചുള്ള ഡാറ്റ രാജ്യ ഡാറ്റാബേസുകളിൽ നിന്ന് ഒന്നിലേക്ക് കൈമാറാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. ഇത് ചെയ്യുന്നതിന്, ഞങ്ങൾ എല്ലാ പട്ടികകളും ഉപയോഗവും int ഐഡന്റിഫയറിൽ നിന്ന് ഗ്ലോബൽ UUId ഐഡന്റിഫയറിലേക്ക് മാറ്റേണ്ടതുണ്ട് (ഞങ്ങൾ അടുത്തിടെ ഈ കോഡ് പുനർനിർമ്മിച്ചു റോമൻ ബുക്കിൻ "ഉയിദ് - ഒരു ചെറിയ ഘടനയുടെ വലിയ കഥ" കൂടാതെ ഓപ്പൺ സോഴ്സ് പ്രോജക്ടും പ്രാകൃതങ്ങൾ). ഉപയോക്തൃ ഡാറ്റ സംഭരിക്കുന്നതിന് (ഇത് വ്യക്തിഗത വിവരമായതിനാൽ) അതിന്റെ പരിമിതികളുണ്ട്, ചില രാജ്യങ്ങളിൽ ഇത് പ്രത്യേകം സംഭരിക്കേണ്ടത് ആവശ്യമാണ്. എന്നാൽ ഒരു ആഗോള ഉപയോക്തൃ ഐഡി ഉണ്ടായിരിക്കണം.
2. ഡാറ്റാബേസിലെ പല പട്ടികകളിലും ഓപ്പറേഷൻ നടത്തിയ ഉപയോക്താവിനെക്കുറിച്ചുള്ള ഓഡിറ്റ് വിവരങ്ങൾ ഉണ്ട്. സ്ഥിരത ഉറപ്പാക്കാൻ ഇതിന് ഒരു അധിക സംവിധാനം ആവശ്യമാണ്.
3. API സേവനങ്ങൾ സൃഷ്ടിച്ചതിനുശേഷം, മറ്റൊരു സിസ്റ്റത്തിലേക്ക് കൈമാറ്റം ചെയ്യുന്നതിനുള്ള ദീർഘവും ക്രമാനുഗതവുമായ കാലയളവ് ഉണ്ടായിരുന്നു. സ്വിച്ചുകൾ ഉപയോക്താക്കൾക്കും ആവശ്യമായ മാനുവൽ വർക്കിനും തടസ്സമില്ലാതെ സംഭവിക്കേണ്ടതുണ്ട്.

ഒരു പിസ്സേറിയയിൽ ഒരു ഉപകരണം രജിസ്റ്റർ ചെയ്യുന്നതിനുള്ള സ്കീം:

ഓത്ത്, ഡിവൈസുകൾ എന്നിവയുടെ സേവനത്തെ വേർതിരിക്കുന്നതിന് ശേഷമുള്ള പൊതു വാസ്തുവിദ്യ:

അഭിപായപ്പെടുക. 2020-ൽ, OAuth 2.0 അംഗീകാര നിലവാരത്തെ അടിസ്ഥാനമാക്കിയുള്ള Auth-ന്റെ പുതിയ പതിപ്പിനായി ഞങ്ങൾ പ്രവർത്തിക്കുന്നു. ഈ സ്റ്റാൻഡേർഡ് വളരെ സങ്കീർണ്ണമാണ്, എന്നാൽ ഒരു എൻഡ്-ടു-എൻഡ് പ്രാമാണീകരണ സേവനം വികസിപ്പിക്കുന്നതിന് ഉപയോഗപ്രദമാണ്. ലേഖനത്തിൽ "അംഗീകാരത്തിന്റെ സൂക്ഷ്മതകൾ: OAuth 2.0 സാങ്കേതികവിദ്യയുടെ അവലോകനം» ഞങ്ങൾ അലക്സി ചെർനിയേവ് സ്റ്റാൻഡേർഡിനെക്കുറിച്ച് കഴിയുന്നത്ര ലളിതമായും വ്യക്തമായും സംസാരിക്കാൻ ശ്രമിച്ചു, അതുവഴി നിങ്ങൾ അത് പഠിക്കാൻ സമയം ലാഭിക്കുന്നു.

ട്രാക്കർ എന്താണ് ചെയ്യുന്നത്?

ഇപ്പോൾ ലോഡ് ചെയ്ത സേവനങ്ങളിൽ രണ്ടാമത്തേതിനെ കുറിച്ച്. ട്രാക്കർ ഇരട്ട റോൾ ചെയ്യുന്നു:

• ഒരു വശത്ത്, ഇപ്പോൾ എന്ത് ഓർഡറുകൾ പുരോഗമിക്കുന്നുവെന്നും ഇപ്പോൾ എന്ത് ഉൽപ്പന്നങ്ങൾ തയ്യാറാക്കണമെന്നും അടുക്കളയിലെ ജീവനക്കാരെ കാണിക്കുക എന്നതാണ് അതിന്റെ ചുമതല.
• മറുവശത്ത്, അടുക്കളയിലെ എല്ലാ പ്രക്രിയകളും ഡിജിറ്റൈസ് ചെയ്യുക.

ഒരു പുതിയ ഉൽപ്പന്നം (ഉദാഹരണത്തിന്, പിസ്സ) ഒരു ഓർഡറിൽ ദൃശ്യമാകുമ്പോൾ, അത് "റോളിംഗ്" ട്രാക്കർ സ്റ്റേഷനിലേക്ക് പോകുന്നു. ഈ സ്റ്റേഷനിൽ ഒരു പിസ്സ നിർമ്മാതാവ് ഉണ്ട്, അവൻ ആവശ്യമായ വലുപ്പത്തിലുള്ള ഒരു ബൺ എടുത്ത് അത് ഉരുട്ടുന്നു, അതിനുശേഷം അവൻ തന്റെ ടാസ്ക് പൂർത്തിയാക്കിയതായി ട്രാക്കർ ടാബ്‌ലെറ്റിൽ അടയാളപ്പെടുത്തുകയും ഉരുട്ടിയ കുഴെച്ചതുമുതൽ അടുത്ത സ്റ്റേഷനിലേക്ക് കൈമാറുകയും ചെയ്യുന്നു - “ഫില്ലിംഗ്”. .

അവിടെ, അടുത്ത പിസ്സ നിർമ്മാതാവ് പിസയുടെ മുകളിൽ, തുടർന്ന് ടാബ്‌ലെറ്റിൽ തന്റെ ചുമതല പൂർത്തിയാക്കിയതായി അടയാളപ്പെടുത്തുകയും പിസ്സ അടുപ്പിൽ വയ്ക്കുകയും ചെയ്യുന്നു (ഇതും ടാബ്‌ലെറ്റിൽ അടയാളപ്പെടുത്തേണ്ട ഒരു പ്രത്യേക സ്റ്റേഷനാണ്). ഡോഡോയിൽ തുടക്കം മുതൽ ഡോഡോ ഐഎസിന്റെ തുടക്കം മുതലേ ഇത്തരമൊരു സംവിധാനം നിലവിലുണ്ടായിരുന്നു. എല്ലാ പ്രവർത്തനങ്ങളും പൂർണ്ണമായി ട്രാക്ക് ചെയ്യാനും ഡിജിറ്റൈസ് ചെയ്യാനും ഇത് നിങ്ങളെ അനുവദിക്കുന്നു. കൂടാതെ, ട്രാക്കർ ഒരു പ്രത്യേക ഉൽപ്പന്നം എങ്ങനെ തയ്യാറാക്കണമെന്ന് നിർദ്ദേശിക്കുന്നു, ഓരോ തരത്തിലുള്ള ഉൽപ്പന്നവും അതിന്റെ സ്വന്തം നിർമ്മാണ സ്കീമുകൾ അനുസരിച്ച് നടപ്പിലാക്കുന്നു, ഉൽപ്പന്നത്തിന് ഏറ്റവും അനുയോജ്യമായ പാചക സമയം സംഭരിക്കുന്നു, ഉൽപ്പന്നത്തിലെ എല്ലാ പ്രവർത്തനങ്ങളും ട്രാക്കുചെയ്യുന്നു.

റാസ്‌കറ്റ്‌ക ട്രാക്കർ സ്റ്റേഷനിൽ ടാബ്‌ലെറ്റ് സ്‌ക്രീൻ ഇങ്ങനെയാണ് കാണപ്പെടുന്നത്.

ലോഡ്സ് എവിടെ നിന്ന് വരുന്നു?

ഓരോ പിസേറിയയിലും ഒരു ട്രാക്കറുള്ള അഞ്ചോളം ഗുളികകളുണ്ട്. 2016-ൽ ഞങ്ങൾക്ക് 100-ലധികം പിസ്സേറിയകൾ ഉണ്ടായിരുന്നു (ഇപ്പോൾ 600-ലധികം ഉണ്ട്). ഓരോ ടാബ്‌ലെറ്റും ഓരോ 10 സെക്കൻഡിലും ബാക്കെൻഡിലേക്ക് ഒരു അഭ്യർത്ഥന നടത്തുകയും ഓർഡർ ടേബിൾ (ക്ലയന്റും വിലാസവുമുള്ള ലിങ്ക്), ഓർഡർ കോമ്പോസിഷൻ (ഉൽപ്പന്നവും അളവിന്റെ സൂചനയും ഉള്ള ലിങ്ക്), മോട്ടിവേഷൻ ടേബിൾ (അത് ട്രാക്ക് ചെയ്യുന്നു) എന്നിവയിൽ നിന്ന് ഡാറ്റ ശേഖരിക്കുന്നു. അമർത്തുന്ന സമയം). ഒരു പിസ്സ നിർമ്മാതാവ് ട്രാക്കറിൽ ഒരു ഉൽപ്പന്നത്തിൽ ക്ലിക്കുചെയ്യുമ്പോൾ, ഈ എല്ലാ പട്ടികകളിലെയും റെക്കോർഡുകൾ അപ്ഡേറ്റ് ചെയ്യപ്പെടും. ഓർഡർ ടേബിൾ പൊതുവായതാണ്; ഒരു ഓർഡർ സ്വീകരിക്കുമ്പോൾ അതിൽ ഒരേസമയം ഉൾപ്പെടുത്തലുകൾ, സിസ്റ്റത്തിന്റെ മറ്റ് ഭാഗങ്ങളിൽ നിന്നുള്ള അപ്‌ഡേറ്റുകൾ, നിരവധി വായനകൾ എന്നിവ അടങ്ങിയിരിക്കുന്നു, ഉദാഹരണത്തിന്, ഒരു പിസേറിയയിൽ തൂക്കിയിട്ട് ഉപഭോക്താക്കൾക്ക് റെഡിമെയ്ഡ് ഓർഡറുകൾ കാണിക്കുന്ന ടിവിയിൽ.

ലോഡുകളുമായുള്ള പോരാട്ടത്തിന്റെ കാലഘട്ടത്തിൽ, എല്ലാം എല്ലാവരെയും കാഷെ ചെയ്യുകയും ഡാറ്റാബേസിന്റെ ഒരു അസിൻക്രണസ് പകർപ്പിലേക്ക് മാറ്റുകയും ചെയ്യുമ്പോൾ, ട്രാക്കറുമായുള്ള ഈ പ്രവർത്തനങ്ങൾ മാസ്റ്റർ ഡാറ്റാബേസിലേക്ക് പോകുന്നത് തുടർന്നു. ഇവിടെ കാലതാമസം ഉണ്ടാകരുത്, ഡാറ്റ കാലികമായിരിക്കണം, സമന്വയം അസ്വീകാര്യമാണ്.

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

ആയിരുന്നു. തുടക്കത്തിൽ, വാസ്തുവിദ്യ ഇങ്ങനെയായിരുന്നു:

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

ട്രാക്കർ അൺലോഡ് ചെയ്യുന്നു

വ്യത്യസ്ത ഡാറ്റാബേസുകൾക്കിടയിൽ ഡാറ്റ സമന്വയിപ്പിക്കണം എന്നതാണ് ട്രാക്കറിന്റെ പ്രധാന പ്രശ്നം. ഓത്ത് സേവനത്തിന്റെ വിഭജനത്തിൽ നിന്നുള്ള അതിന്റെ പ്രധാന വ്യത്യാസവും ഇതാണ്; ഓർഡറും അതിന്റെ സ്റ്റാറ്റസും മാറുകയും വിവിധ സേവനങ്ങളിൽ പ്രദർശിപ്പിക്കുകയും വേണം.

റെസ്റ്റോറന്റ് ചെക്ക്ഔട്ടിൽ ഞങ്ങൾ ഓർഡറുകൾ സ്വീകരിക്കുന്നു (ഇതൊരു സേവനമാണ്), ഇത് ഡാറ്റാബേസിൽ "അംഗീകരിക്കപ്പെട്ട" സ്റ്റാറ്റസിൽ സംഭരിച്ചിരിക്കുന്നു. അതിനുശേഷം, അത് ട്രാക്കറിലേക്ക് പോകണം, അവിടെ അത് അതിന്റെ സ്റ്റാറ്റസ് നിരവധി തവണ മാറ്റും: "അടുക്കള" മുതൽ "പാക്ക്" വരെ. ഈ സാഹചര്യത്തിൽ, കാഷ്യറിൽ നിന്നോ Shift മാനേജർ ഇന്റർഫേസിൽ നിന്നോ ചില ബാഹ്യ സ്വാധീനങ്ങൾ ഓർഡറിനൊപ്പം സംഭവിക്കാം. പട്ടികയിലെ വിവരണങ്ങൾക്കൊപ്പം ഞാൻ ഓർഡർ സ്റ്റാറ്റസുകൾ നൽകും:

ഓർഡർ സ്റ്റാറ്റസ് മാറ്റ സ്കീം ഇതുപോലെ കാണപ്പെടുന്നു:

വ്യത്യസ്ത സംവിധാനങ്ങൾക്കിടയിൽ നിലകൾ മാറുന്നു. ഇവിടെ ഡാറ്റ ലോക്ക് ചെയ്തിരിക്കുന്ന അവസാന സംവിധാനമല്ല ട്രാക്കർ. അത്തരമൊരു സാഹചര്യത്തിൽ വേർപിരിയുന്നതിനുള്ള സാധ്യമായ നിരവധി സമീപനങ്ങൾ ഞങ്ങൾ കണ്ടു:

1. ഞങ്ങൾ എല്ലാ ഓർഡർ പ്രവർത്തനങ്ങളും ഒരു സേവനത്തിൽ കേന്ദ്രീകരിക്കുന്നു. ഞങ്ങളുടെ കാര്യത്തിൽ, ഓർഡർ പ്രോസസ്സ് ചെയ്യുന്നതിന് ഈ ഓപ്ഷന് വളരെയധികം സേവനം ആവശ്യമാണ്. ഞങ്ങൾ അവിടെ നിർത്തിയിരുന്നെങ്കിൽ, ഞങ്ങൾ രണ്ടാമത്തെ ഏകശിലയിൽ അവസാനിക്കുമായിരുന്നു. ഞങ്ങൾ പ്രശ്നങ്ങൾ പരിഹരിക്കില്ലായിരുന്നു.
2. ഒരു സിസ്റ്റം മറ്റൊന്നിലേക്ക് കോൾ ചെയ്യുന്നു. രണ്ടാമത്തെ ഓപ്ഷൻ കൂടുതൽ രസകരമാണ്. എന്നാൽ ഇത് ഉപയോഗിച്ച്, കോളുകളുടെ ശൃംഖല സാധ്യമാണ് (കാസ്കേഡിംഗ് പരാജയങ്ങൾ), ഘടകങ്ങളുടെ കണക്റ്റിവിറ്റി ഉയർന്നതാണ്, അത് കൈകാര്യം ചെയ്യാൻ കൂടുതൽ ബുദ്ധിമുട്ടാണ്.
3. ഞങ്ങൾ ഇവന്റുകൾ സംഘടിപ്പിക്കുകയും ഈ ഇവന്റുകളിലൂടെ ഓരോ സേവനവും പരസ്പരം കൈമാറുകയും ചെയ്യുന്നു. തൽഫലമായി, മൂന്നാമത്തെ ഓപ്ഷൻ തിരഞ്ഞെടുത്തു, അതനുസരിച്ച് എല്ലാ സേവനങ്ങളും പരസ്പരം ഇവന്റുകൾ കൈമാറാൻ തുടങ്ങുന്നു.

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

അപ്പോഴേക്കും, ഞങ്ങൾക്ക് റാബിറ്റ്എംക്യു സ്റ്റാക്കിൽ ഉണ്ടായിരുന്നു, അതിനാൽ ഇത് ഒരു സന്ദേശ ബ്രോക്കറായി ഉപയോഗിക്കാനുള്ള അന്തിമ തീരുമാനം. റെസ്റ്റോറന്റ് കാഷ്യറിൽ നിന്നുള്ള ഒരു ഓർഡർ ട്രാക്കറിലൂടെ മാറുന്നത് ഡയഗ്രം കാണിക്കുന്നു, അവിടെ അത് മാനേജറുടെ ഓർഡറുകൾ ഇന്റർഫേസിൽ അതിന്റെ സ്റ്റാറ്റസും ഡിസ്പ്ലേയും മാറ്റുന്നു. ആയി:

ഘട്ടം ഘട്ടമായുള്ള പാത ഓർഡർ ചെയ്യുക
ഓർഡർ ഉറവിട സേവനങ്ങളിലൊന്നിൽ ഓർഡർ പാത ആരംഭിക്കുന്നു. റെസ്റ്റോറന്റ് കാഷ്യർ ഇതാ:

1. ചെക്ക്ഔട്ടിൽ ഓർഡർ പൂർണ്ണമായും തയ്യാറാണ്, അത് ട്രാക്കറിലേക്ക് അയയ്ക്കാനുള്ള സമയമായി. ട്രാക്കർ സബ്‌സ്‌ക്രൈബുചെയ്‌ത ഇവന്റ് എറിയപ്പെടുന്നു.
2. ട്രാക്കർ, ഒരു ഓർഡർ സ്വീകരിച്ച്, അത് സ്വന്തം ഡാറ്റാബേസിൽ സംരക്ഷിക്കുകയും, "ട്രാക്കർ അംഗീകരിച്ച ഓർഡർ" ഇവന്റ് ഉണ്ടാക്കുകയും അത് RMQ-ലേക്ക് അയയ്ക്കുകയും ചെയ്യുന്നു.
3. ഇഷ്‌ടാനുസൃത ഇവന്റ് ബസിന്റെ നിരവധി ഹാൻഡ്‌ലർമാർ ഇതിനകം സബ്‌സ്‌ക്രൈബ് ചെയ്തിട്ടുണ്ട്. ഞങ്ങളെ സംബന്ധിച്ചിടത്തോളം, മോണോലിത്തിക്ക് ഡാറ്റാബേസുമായി സമന്വയിപ്പിക്കുന്ന ഒന്ന് പ്രധാനമാണ്.
4. ഹാൻഡ്‌ലർ ഇവന്റ് സ്വീകരിക്കുന്നു, അതിൽ നിന്ന് പ്രാധാന്യമുള്ള ഡാറ്റ തിരഞ്ഞെടുക്കുന്നു: ഞങ്ങളുടെ കാര്യത്തിൽ, ഇതാണ് ഓർഡർ സ്റ്റാറ്റസ് “ട്രാക്കർ അംഗീകരിച്ചത്” കൂടാതെ പ്രധാന ഡാറ്റാബേസിൽ അതിന്റെ ഓർഡർ എന്റിറ്റി അപ്‌ഡേറ്റ് ചെയ്യുന്നു.

ആർക്കെങ്കിലും മോണോലിത്തിക്ക് ഓർഡർ ടേബിളിൽ നിന്ന് പ്രത്യേകമായി ഒരു ഓർഡർ ആവശ്യമുണ്ടെങ്കിൽ, അവർക്ക് അത് അവിടെനിന്നും വായിക്കാം. ഉദാഹരണത്തിന്, Shift മാനേജറിലെ ഓർഡർ ഇന്റർഫേസിന് ഇത് ആവശ്യമാണ്:

മറ്റെല്ലാ സേവനങ്ങൾക്കും ഇവന്റുകൾ തങ്ങൾക്കായി ഉപയോഗിക്കുന്നതിന് ട്രാക്കറിൽ നിന്ന് ഓർഡർ ചെയ്യാനും വരിക്കാരാകാനാകും.

കുറച്ച് സമയത്തിന് ശേഷം ഒരു ഓർഡർ പ്രൊഡക്ഷനിലേക്ക് എടുത്താൽ, അതിന്റെ സ്റ്റാറ്റസ് ആദ്യം അതിന്റെ ഡാറ്റാബേസിൽ (ട്രാക്കർ ഡാറ്റാബേസ്) മാറുന്നു, തുടർന്ന് "OrderInWork" ഇവന്റ് ഉടനടി സൃഷ്ടിക്കപ്പെടും. ഇത് ഒരു മോണോലിത്തിക്ക് ഡാറ്റാബേസിൽ സമന്വയിപ്പിച്ച് മറ്റ് സേവനങ്ങളിലേക്ക് എത്തിക്കുന്ന RMQ-ലേക്ക് പ്രവേശിക്കുന്നു. ഈ പാതയിൽ വിവിധ പ്രശ്നങ്ങൾ ഉണ്ടാകാം; അവയെക്കുറിച്ചുള്ള കൂടുതൽ വിശദാംശങ്ങൾ ഷെനിയ പെഷ്കോവിന്റെ റിപ്പോർട്ടിൽ കാണാം ട്രാക്കറിലെ അന്തിമ സ്ഥിരത നടപ്പിലാക്കൽ വിശദാംശങ്ങളെക്കുറിച്ച്.

ഓത്ത്, ട്രാക്കർ എന്നിവയിലെ മാറ്റങ്ങൾക്ക് ശേഷമുള്ള അന്തിമ ആർക്കിടെക്ചർ

ചുരുക്കി പറഞ്ഞാൽ: തുടക്കത്തിൽ, ഡോഡോ ഐഎസ് സിസ്റ്റത്തിന്റെ ഒമ്പത് വർഷത്തെ ചരിത്രം ഒരു ലേഖനത്തിലേക്ക് പാക്കേജുചെയ്യാനുള്ള ആശയം എനിക്കുണ്ടായിരുന്നു. പരിണാമത്തിന്റെ ഘട്ടങ്ങളെക്കുറിച്ച് വേഗത്തിലും ലളിതമായും സംസാരിക്കാൻ ഞാൻ ആഗ്രഹിച്ചു. എന്നിരുന്നാലും, മെറ്റീരിയൽ പഠിക്കാൻ ഇരുന്നപ്പോൾ, എല്ലാം തോന്നുന്നതിനേക്കാൾ സങ്കീർണ്ണവും രസകരവുമാണെന്ന് ഞാൻ മനസ്സിലാക്കി.

അത്തരം മെറ്റീരിയലുകളുടെ നേട്ടങ്ങളെ (അല്ലെങ്കിൽ അതിന്റെ അഭാവം) പ്രതിഫലിപ്പിക്കുമ്പോൾ, സംഭവങ്ങളുടെ പൂർണ്ണമായ ക്രോണിക്കിളുകൾ, വിശദമായ മുൻകാല തീരുമാനങ്ങൾ, ഒരാളുടെ മുൻകാല തീരുമാനങ്ങളുടെ വിശകലനം എന്നിവ കൂടാതെ തുടർച്ചയായ വികസനം അസാധ്യമാണ് എന്ന നിഗമനത്തിലെത്തി.

ഞങ്ങളുടെ യാത്രയെക്കുറിച്ച് പഠിക്കുന്നത് നിങ്ങൾക്ക് ഉപയോഗപ്രദവും രസകരവുമാണെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു. ഡോഡോ ഐഎസ് സിസ്റ്റത്തിന്റെ ഏത് ഭാഗമാണ് അടുത്ത ലേഖനത്തിൽ വിവരിക്കേണ്ടത് എന്ന തിരഞ്ഞെടുപ്പിനെ ഞാൻ അഭിമുഖീകരിക്കുന്നു: അഭിപ്രായങ്ങളിൽ എഴുതുക അല്ലെങ്കിൽ വോട്ട് ചെയ്യുക.

രജിസ്റ്റർ ചെയ്ത ഉപയോക്താക്കൾക്ക് മാത്രമേ സർവേയിൽ പങ്കെടുക്കാൻ കഴിയൂ. സൈൻ ഇൻദയവായി.

ഡോഡോ ഐഎസിന്റെ ഏത് ഭാഗത്തെക്കുറിച്ചാണ് അടുത്ത ലേഖനത്തിൽ നിങ്ങൾ പഠിക്കാൻ ആഗ്രഹിക്കുന്നത്?

• 24,1%ഡോഡോ ഐഎസിലെ ആദ്യകാല മോണോലിത്ത് (2011-2015)14

• 24,1%ആദ്യ പ്രശ്നങ്ങളും അവയുടെ പരിഹാരങ്ങളും (2015-2016)14

• 20,7%ക്ലയന്റ് ഭാഗത്തിന്റെ പാത: അടിത്തറയ്ക്ക് മുകളിലുള്ള മുഖം (2016-2017)12

• 36,2%യഥാർത്ഥ മൈക്രോസർവീസുകളുടെ ചരിത്രം (2018-2019)21

• 44,8%മോണോലിത്തിന്റെ മുറിക്കലും വാസ്തുവിദ്യയുടെ സ്ഥിരതയും പൂർത്തിയായി26

• 29,3%സിസ്റ്റത്തിന്റെ വികസനത്തിനായുള്ള കൂടുതൽ പദ്ധതികളെക്കുറിച്ച് 17

• 19,0%Dodo IS11 നെ കുറിച്ച് എനിക്ക് ഒന്നും അറിയാൻ താൽപ്പര്യമില്ല

58 ഉപയോക്താക്കൾ വോട്ട് ചെയ്തു. 6 ഉപയോക്താക്കൾ വിട്ടുനിന്നു.

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