“എന്റെ ഷൂസിൽ നടക്കുന്നു” - കാത്തിരിക്കൂ, അവ അടയാളപ്പെടുത്തിയിട്ടുണ്ടോ?

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

X5-ൽ, ലേബൽ ചെയ്‌ത സാധനങ്ങൾ ട്രാക്ക് ചെയ്യുന്നതും സംസ്ഥാനവുമായും വിതരണക്കാരുമായും ഡാറ്റ കൈമാറ്റം ചെയ്യുന്ന സിസ്റ്റത്തെ "മാർക്കസ്" എന്ന് വിളിക്കുന്നു. എങ്ങനെ, ആരാണ് ഇത് വികസിപ്പിച്ചെടുത്തത്, അതിന്റെ ടെക്നോളജി സ്റ്റാക്ക് എന്താണ്, എന്തുകൊണ്ടാണ് ഞങ്ങൾക്ക് അഭിമാനിക്കാൻ എന്തെങ്കിലും ഉള്ളത് എന്ന് ക്രമത്തിൽ പറയാം.

യഥാർത്ഥ ഹൈലോഡ്

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

ടീം എം

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

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

കൊറോണ വൈറസ് പാൻഡെമിക് കാരണം, ഞങ്ങൾ മുഴുവൻ ടീമിനെയും വിദൂര ജോലിയിലേക്ക് മാറ്റി; ഡെവലപ്‌മെന്റ് മാനേജ്‌മെന്റിനുള്ള എല്ലാ ഉപകരണങ്ങളുടെയും ലഭ്യത, ജിറയിലെയും ജിറ്റ്‌ലാബിലെയും ബിൽറ്റ് വർക്ക്ഫ്ലോ ഈ ഘട്ടം എളുപ്പത്തിൽ മറികടക്കാൻ സഹായിച്ചു. വിദൂരമായി ചെലവഴിച്ച മാസങ്ങൾ ടീമിന്റെ ഉൽപ്പാദനക്ഷമതയെ ബാധിക്കില്ലെന്ന് കാണിച്ചു; പലർക്കും, ജോലിയിലെ സുഖം വർദ്ധിച്ചു, തത്സമയ ആശയവിനിമയം മാത്രമാണ് നഷ്‌ടമായത്.

വിദൂര ടീം മീറ്റിംഗ്

വിദൂര ജോലിക്കിടയിലുള്ള മീറ്റിംഗുകൾ

പരിഹാരത്തിന്റെ സാങ്കേതിക ശേഖരം

X5-നുള്ള സ്റ്റാൻഡേർഡ് റിപ്പോസിറ്ററിയും CI/CD ടൂളും GitLab ആണ്. കോഡ് സംഭരണം, തുടർച്ചയായ പരിശോധന, ടെസ്റ്റ്, പ്രൊഡക്ഷൻ സെർവറുകളിലേക്കുള്ള വിന്യാസം എന്നിവയ്ക്കായി ഞങ്ങൾ ഇത് ഉപയോഗിക്കുന്നു. ഡവലപ്പർ കോഡിൽ വരുത്തിയ മാറ്റങ്ങൾക്ക് 2 സഹപ്രവർത്തകരെങ്കിലും അംഗീകാരം നൽകേണ്ടിവരുമ്പോൾ, ഞങ്ങൾ കോഡ് അവലോകനത്തിന്റെ രീതിയും ഉപയോഗിക്കുന്നു. സ്റ്റാറ്റിക് കോഡ് അനലൈസറുകൾ SonarQube, JaCoCo എന്നിവ ഞങ്ങളുടെ കോഡ് വൃത്തിയായി സൂക്ഷിക്കാനും ആവശ്യമായ യൂണിറ്റ് ടെസ്റ്റ് കവറേജ് ഉറപ്പാക്കാനും ഞങ്ങളെ സഹായിക്കുന്നു. കോഡിലെ എല്ലാ മാറ്റങ്ങളും ഈ പരിശോധനകളിലൂടെ കടന്നുപോകണം. സ്വമേധയാ പ്രവർത്തിപ്പിക്കുന്ന എല്ലാ ടെസ്റ്റ് സ്ക്രിപ്റ്റുകളും പിന്നീട് ഓട്ടോമേറ്റഡ് ആണ്.

"മാർക്കസ്" ബിസിനസ്സ് പ്രക്രിയകൾ വിജയകരമായി നടപ്പിലാക്കുന്നതിന്, ഓരോന്നിനും ക്രമത്തിൽ നിരവധി സാങ്കേതിക പ്രശ്നങ്ങൾ പരിഹരിക്കേണ്ടതുണ്ട്.

ടാസ്ക് 1. സിസ്റ്റത്തിന്റെ തിരശ്ചീന സ്കേലബിലിറ്റിയുടെ ആവശ്യകത

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

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

ബാഹ്യ സംവിധാനങ്ങളുമായുള്ള ആശയവിനിമയത്തിനുള്ള മൊഡ്യൂളുകൾ പ്രത്യേക സേവനങ്ങളായി വേർതിരിക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു. ബിസിനസ്സ് പ്രവർത്തനക്ഷമതയുള്ള സേവനങ്ങളിൽ ഫലത്തിൽ യാതൊരു സ്വാധീനവുമില്ലാതെ, ബാഹ്യ സിസ്റ്റങ്ങളുടെ എപിഐകൾ ഇടയ്ക്കിടെ മാറുന്ന പ്രശ്നം പരിഹരിക്കാൻ ഇത് സാധ്യമാക്കി.

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

ടാസ്ക് 2. പ്ലാറ്റ്ഫോം സേവനങ്ങൾക്കിടയിൽ ഉയർന്ന ലോഡും വളരെ തീവ്രമായ ഡാറ്റാ കൈമാറ്റവും നിലനിർത്തേണ്ടതിന്റെ ആവശ്യകത: പ്രോജക്റ്റ് ലോഞ്ച് ഘട്ടത്തിൽ മാത്രം സെക്കൻഡിൽ 600 ഓപ്പറേഷനുകൾ നടത്തുന്നു. റീട്ടെയിൽ ഔട്ട്‌ലെറ്റുകൾ ഞങ്ങളുടെ പ്ലാറ്റ്‌ഫോമിലേക്ക് കണക്‌റ്റ് ചെയ്യുന്നതിനാൽ ഈ മൂല്യം 5000 ഓപ്‌സ്/സെക്കന്റ് ആയി വർദ്ധിക്കുമെന്ന് ഞങ്ങൾ പ്രതീക്ഷിക്കുന്നു.

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

സേവനങ്ങളുടെ പ്രവർത്തന സമയത്തോ കാഫ്ക ബാച്ചിനൊപ്പം പ്രവർത്തിക്കുമ്പോഴോ ഒഴിവാക്കലുകൾ സംഭവിക്കുമ്പോൾ അവയുടെ TraceId നഷ്‌ടപ്പെടാതിരിക്കാൻ ലോഗുകൾ കണ്ടെത്തുന്നതിൽ വളരെയധികം ശ്രദ്ധ ചെലുത്തി. ആദ്യത്തേതിൽ പ്രത്യേക പ്രശ്‌നങ്ങളൊന്നും ഉണ്ടായിരുന്നില്ലെങ്കിൽ, രണ്ടാമത്തെ കേസിൽ ബാച്ച് വന്ന എല്ലാ TraceId-കളും ലോഗ് ചെയ്യാനും ട്രെയ്‌സിംഗ് തുടരാൻ ഒരെണ്ണം തിരഞ്ഞെടുക്കാനും ഞങ്ങൾ നിർബന്ധിതരാകുന്നു. തുടർന്ന്, യഥാർത്ഥ TraceId ഉപയോഗിച്ച് തിരയുമ്പോൾ, ഏത് ട്രെയ്‌സിംഗ് തുടർന്നുവെന്ന് ഉപയോക്താവിന് എളുപ്പത്തിൽ കണ്ടെത്താനാകും.

ടാസ്ക് 3. വലിയ അളവിൽ ഡാറ്റ സംഭരിക്കേണ്ടതിന്റെ ആവശ്യകത: പുകയിലയ്ക്ക് മാത്രം പ്രതിവർഷം 1 ബില്ല്യണിലധികം ലേബലുകൾ X5-ലേക്ക് വരുന്നു. അവർക്ക് സ്ഥിരവും വേഗത്തിലുള്ളതുമായ ആക്സസ് ആവശ്യമാണ്. മൊത്തത്തിൽ, ഈ ലേബൽ ചെയ്ത വസ്തുക്കളുടെ ചലന ചരിത്രത്തിന്റെ ഏകദേശം 10 ബില്ല്യൺ റെക്കോർഡുകൾ സിസ്റ്റം പ്രോസസ്സ് ചെയ്യണം.

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

പ്രവർത്തനങ്ങളുടെ ചരിത്രവുമായുള്ള ഉപയോക്താക്കളുടെ പ്രവർത്തനം ഒരു തരത്തിലും ഏറ്റവും പ്രധാനപ്പെട്ട കാര്യത്തെ ബാധിക്കുന്നില്ലെന്ന് ഉറപ്പാക്കാൻ - ഞങ്ങളുടെ ബിസിനസ്സ് പ്രക്രിയകളുടെ പ്രവർത്തനത്തെ, ഞങ്ങൾ എല്ലാ ചരിത്രപരമായ ഡാറ്റയും ഒരു പ്രത്യേക ഡാറ്റാബേസുള്ള ഒരു പ്രത്യേക സേവനമായി വേർതിരിക്കുന്നു, അത് കാഫ്ക വഴിയും വിവരങ്ങൾ സ്വീകരിക്കുന്നു. . ഈ രീതിയിൽ, നിലവിലുള്ള പ്രവർത്തനങ്ങൾക്കായി ഡാറ്റ പ്രോസസ്സ് ചെയ്യുന്ന സേവനങ്ങളെ ബാധിക്കാതെ ഉപയോക്താക്കൾ ഒരു ഒറ്റപ്പെട്ട സേവനത്തിൽ പ്രവർത്തിക്കുന്നു.

ടാസ്ക് 4: ക്യൂ റീപ്രോസസ് ചെയ്യലും നിരീക്ഷണവും:

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

അത്തരമൊരു സ്കീം നടപ്പിലാക്കാൻ, ഞങ്ങൾക്ക് ഇനിപ്പറയുന്നവ ആവശ്യമാണ്: ഈ പരിഹാരം സ്പ്രിംഗുമായി സമന്വയിപ്പിക്കാനും കോഡ് ഡ്യൂപ്ലിക്കേഷൻ ഒഴിവാക്കാനും. വെബിൽ സർഫിംഗ് ചെയ്യുമ്പോൾ, Spring BeanPostProccessor അടിസ്ഥാനമാക്കിയുള്ള സമാനമായ ഒരു പരിഹാരം ഞങ്ങൾ കാണാനിടയായി, പക്ഷേ അത് ഞങ്ങൾക്ക് അനാവശ്യമായി ബുദ്ധിമുട്ടുള്ളതായി തോന്നി. ഉപഭോക്താക്കളെ സൃഷ്‌ടിക്കുന്നതിനും ഉപഭോക്താക്കൾക്ക് വീണ്ടും ശ്രമിക്കുന്നതിനുമായി സ്‌പ്രിംഗ് സൈക്കിളിൽ സംയോജിപ്പിക്കാൻ ഞങ്ങളെ അനുവദിക്കുന്ന ലളിതമായ ഒരു പരിഹാരം ഞങ്ങളുടെ ടീം ഉണ്ടാക്കിയിട്ടുണ്ട്. ഞങ്ങളുടെ പരിഹാരത്തിന്റെ ഒരു പ്രോട്ടോടൈപ്പ് ഞങ്ങൾ സ്പ്രിംഗ് ടീമിന് വാഗ്ദാനം ചെയ്തു, നിങ്ങൾക്ക് അത് കാണാൻ കഴിയും ഇവിടെ. വീണ്ടും ശ്രമിക്കുക ഉപഭോക്താക്കളുടെ എണ്ണവും ഓരോ ഉപഭോക്താവിനുമുള്ള ശ്രമങ്ങളുടെ എണ്ണവും, ബിസിനസ്സ് പ്രക്രിയയുടെ ആവശ്യകതയെ ആശ്രയിച്ച്, പാരാമീറ്ററുകളിലൂടെ കോൺഫിഗർ ചെയ്‌തിരിക്കുന്നു, എല്ലാം പ്രവർത്തിക്കുന്നതിന്, org.springframework.kafka.annotation.KafkaListener എന്ന വ്യാഖ്യാനം ചേർക്കുന്നത് മാത്രമാണ് അവശേഷിക്കുന്നത്. , ഇത് എല്ലാ സ്പ്രിംഗ് ഡെവലപ്പർമാർക്കും പരിചിതമാണ്.

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

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

പ്ലാറ്റ്ഫോം പ്രവർത്തനം

പ്ലാറ്റ്ഫോം ഇതിനകം തന്നെ ഉൽപ്പാദനക്ഷമമായ പ്രവർത്തനത്തിലാണ്, എല്ലാ ദിവസവും ഞങ്ങൾ ഡെലിവറികളും ഷിപ്പ്മെന്റുകളും നടത്തുന്നു, പുതിയ വിതരണ കേന്ദ്രങ്ങളെയും സ്റ്റോറുകളെയും ബന്ധിപ്പിക്കുന്നു. പൈലറ്റിന്റെ ഭാഗമായി, സിസ്റ്റം "പുകയില", "ഷൂസ്" ഉൽപ്പന്ന ഗ്രൂപ്പുകളുമായി പ്രവർത്തിക്കുന്നു.

ഞങ്ങളുടെ മുഴുവൻ ടീമും പൈലറ്റുമാരെ നടത്തുന്നതിൽ പങ്കെടുക്കുന്നു, ഉയർന്നുവരുന്ന പ്രശ്നങ്ങൾ വിശകലനം ചെയ്യുന്നു, ലോഗുകൾ മെച്ചപ്പെടുത്തുന്നത് മുതൽ മാറ്റുന്ന പ്രക്രിയകൾ വരെ ഞങ്ങളുടെ ഉൽപ്പന്നം മെച്ചപ്പെടുത്തുന്നതിനുള്ള നിർദ്ദേശങ്ങൾ നൽകുന്നു.

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

ഇപ്പോൾ ഞങ്ങൾ ഞങ്ങളുടെ പ്ലാറ്റ്‌ഫോം വികസിപ്പിക്കുകയും മെച്ചപ്പെടുത്തുകയും ചെയ്യുന്നത് തുടരുകയും പുതിയ വെല്ലുവിളികളെ നിരന്തരം അഭിമുഖീകരിക്കുകയും ചെയ്യുന്നു. നിങ്ങൾക്ക് താൽപ്പര്യമുണ്ടെങ്കിൽ, ഇനിപ്പറയുന്ന ലേഖനങ്ങളിൽ ഞങ്ങളുടെ പരിഹാരങ്ങളെക്കുറിച്ച് ഞങ്ങൾ സംസാരിക്കും.

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