മോണോലിത്തിൽ നിന്ന് മൈക്രോസർവീസിലേക്കുള്ള മാറ്റം: ചരിത്രവും പരിശീലനവും

ഈ ലേഖനത്തിൽ, ഞാൻ പ്രവർത്തിക്കുന്ന പ്രോജക്റ്റ് ഒരു വലിയ മോണോലിത്തിൽ നിന്ന് മൈക്രോസർവീസുകളുടെ ഒരു കൂട്ടമായി എങ്ങനെ രൂപാന്തരപ്പെട്ടു എന്നതിനെക്കുറിച്ച് സംസാരിക്കും.

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

ഈ കോമ്പിനേഷന്റെ ചില ഗുണങ്ങളിൽ ഒന്ന്, ഒരു ബാഹ്യ API വഴി പരസ്പരം വിളിക്കാനുള്ള സേവനങ്ങളുടെ കഴിവാണ്. കൂടുതൽ ശരിയായ സേവനത്തിലേക്കുള്ള പരിവർത്തനത്തിന് വ്യക്തമായ മുൻവ്യവസ്ഥകൾ ഉണ്ടായിരുന്നു, ഭാവിയിൽ മൈക്രോസർവീസ് ആർക്കിടെക്ചർ.

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

ഉള്ളടക്കം

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

നിലവിലുള്ള പരിഹാരത്തിന്റെ വാസ്തുവിദ്യയും പ്രശ്നങ്ങളും

തുടക്കത്തിൽ, ആർക്കിടെക്ചർ ഇതുപോലെയായിരുന്നു: UI ഒരു പ്രത്യേക ആപ്ലിക്കേഷനാണ്, മോണോലിത്തിക്ക് ഭാഗം വിഷ്വൽ ബേസിക് 6 ൽ എഴുതിയിരിക്കുന്നു, .NET ആപ്ലിക്കേഷൻ വളരെ വലിയ ഡാറ്റാബേസിൽ പ്രവർത്തിക്കുന്ന അനുബന്ധ സേവനങ്ങളുടെ ഒരു കൂട്ടമാണ്.

മുമ്പത്തെ പരിഹാരത്തിന്റെ പോരായ്മകൾ

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

മെച്ചപ്പെടുത്തലുകളുടെ ക്യൂ
ഈ പോരായ്മ തികച്ചും സംഘടനാപരമായതാണ്. ഞങ്ങളുടെ ആപ്ലിക്കേഷനിൽ ധാരാളം ഉപഭോക്താക്കളുണ്ട്, അവരെല്ലാം അത് എത്രയും വേഗം മെച്ചപ്പെടുത്താൻ ആഗ്രഹിക്കുന്നു. മുമ്പ്, ഇത് സമാന്തരമായി ചെയ്യുന്നത് അസാധ്യമായിരുന്നു, എല്ലാ ഉപഭോക്താക്കളും വരിയിൽ നിന്നു. ഈ പ്രക്രിയ ബിസിനസുകൾക്ക് പ്രതികൂലമായിരുന്നു, കാരണം അവരുടെ ചുമതല വിലപ്പെട്ടതാണെന്ന് തെളിയിക്കേണ്ടതുണ്ട്. വികസന സംഘം ഈ ക്യൂ സംഘടിപ്പിക്കാൻ സമയം ചെലവഴിച്ചു. ഇതിന് വളരെയധികം സമയവും പ്രയത്നവും വേണ്ടിവന്നു, ആത്യന്തികമായി ഉൽപ്പന്നം അവർ ആഗ്രഹിക്കുന്നത്ര വേഗത്തിൽ മാറ്റാൻ കഴിഞ്ഞില്ല.

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

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

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

മൈക്രോസർവീസുകളിൽ നിന്നുള്ള പ്രതീക്ഷകൾ

തയ്യാറാകുമ്പോൾ ഘടകങ്ങളുടെ പ്രശ്നം. ലായനി വിഘടിപ്പിക്കുകയും വ്യത്യസ്ത പ്രക്രിയകൾ വേർതിരിക്കുകയും ചെയ്തുകൊണ്ട് ഘടകങ്ങളുടെ വിതരണം തയ്യാറാകുമ്പോൾ.

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

പ്രത്യേക പ്രക്രിയകളിൽ സേവനങ്ങളുടെ ഒറ്റപ്പെടുത്തൽ. എബൌട്ട്, കണ്ടെയ്നറുകളിൽ ഇത് ഒറ്റപ്പെടുത്താൻ ഞാൻ ആഗ്രഹിച്ചു, പക്ഷേ .NET ഫ്രെയിംവർക്കിൽ എഴുതിയിരിക്കുന്ന ഒരു വലിയ എണ്ണം സേവനങ്ങൾ വിൻഡോസിൽ മാത്രം പ്രവർത്തിക്കുന്നു. .NET കോർ അടിസ്ഥാനമാക്കിയുള്ള സേവനങ്ങൾ ഇപ്പോൾ ദൃശ്യമാകുന്നു, എന്നാൽ അവയിൽ ചിലത് ഇതുവരെയുണ്ട്.

വിന്യാസ വഴക്കം. ഞങ്ങൾക്ക് ആവശ്യമുള്ള രീതിയിൽ സേവനങ്ങൾ സംയോജിപ്പിക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു, അല്ലാതെ കോഡ് നിർബന്ധിക്കുന്ന രീതിയിലല്ല.

പുതിയ സാങ്കേതികവിദ്യകളുടെ ഉപയോഗം. ഏതൊരു പ്രോഗ്രാമർക്കും ഇത് രസകരമാണ്.

പരിവർത്തന പ്രശ്നങ്ങൾ

തീർച്ചയായും, ഒരു മോണോലിത്ത് മൈക്രോസർവീസുകളായി തകർക്കുന്നത് എളുപ്പമാണെങ്കിൽ, കോൺഫറൻസുകളിൽ അതിനെക്കുറിച്ച് സംസാരിക്കുകയും ലേഖനങ്ങൾ എഴുതുകയും ചെയ്യേണ്ട ആവശ്യമില്ല. ഈ പ്രക്രിയയിൽ നിരവധി അപകടങ്ങളുണ്ട്; ഞങ്ങളെ തടസ്സപ്പെടുത്തിയ പ്രധാനവ ഞാൻ വിവരിക്കും.

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

ജോലി ആരംഭിക്കുന്ന സമയത്ത്, ശേഖരത്തിൽ 500-ലധികം പ്രോജക്റ്റുകളും 700 ആയിരത്തിലധികം കോഡുകളും ഉണ്ടായിരുന്നു. ഇത് വളരെ വലിയ തീരുമാനമാണ് ഒപ്പം രണ്ടാമത്തെ പ്രശ്നം. ഇത് ലളിതമായി എടുത്ത് മൈക്രോസർവീസുകളായി വിഭജിക്കാൻ കഴിഞ്ഞില്ല.

മൂന്നാമത്തെ പ്രശ്നം - ആവശ്യമായ അടിസ്ഥാന സൗകര്യങ്ങളുടെ അഭാവം. വാസ്തവത്തിൽ, ഞങ്ങൾ സോഴ്സ് കോഡ് സെർവറുകളിലേക്ക് സ്വമേധയാ പകർത്തുകയായിരുന്നു.

മോണോലിത്തിൽ നിന്ന് മൈക്രോസർവീസുകളിലേക്ക് എങ്ങനെ മാറാം

മൈക്രോ സർവീസുകൾ പ്രൊവിഷൻ ചെയ്യുന്നു

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

മൈക്രോസർവീസുകൾ വേർതിരിച്ചെടുക്കാൻ ഞങ്ങൾ എന്ത് രീതികളാണ് ഉപയോഗിക്കുന്നത്?

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

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

ഹോസ്റ്റുമായുള്ള അസംബ്ലി പ്രോഗ്രാം ക്ലാസിലെ കോഡിന്റെ ഒരു വരി മാത്രമാണ്. ടോപ്ഷെൽഫുമായുള്ള ജോലി ഞങ്ങൾ ഒരു ഓക്സിലറി ക്ലാസിൽ മറച്ചു.

namespace RBA.Services.Accounts.Host
{
   internal class Program
   {
      private static void Main(string[] args)
      {
        HostRunner<Accounts>.Run("RBA.Services.Accounts.Host");

       }
    }
}

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

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

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

നിങ്ങൾ UI ഭാഗത്തിന്റെ കോഡിൽ നിന്ന് ഒരു യഥാർത്ഥ ഉദാഹരണം നോക്കുകയാണെങ്കിൽ, ഈ പരിഹാരത്തിൽ ഭൂരിഭാഗവും യഥാർത്ഥ ബിസിനസ്സ് ലോജിക് ഉൾക്കൊള്ളുന്നതായി നിങ്ങൾക്ക് കാണാൻ കഴിയും, അത് UI ഫോം നിർമ്മിക്കുന്നതിന് മാത്രമല്ല, മറ്റ് പ്രക്രിയകളിൽ ഉപയോഗപ്രദമാണ്.

യഥാർത്ഥ യുഐ ലോജിക് അവസാന രണ്ട് വരികളിൽ മാത്രമേ ഉള്ളൂ. ഞങ്ങൾ അത് സെർവറിലേക്ക് മാറ്റി, അതുവഴി അത് വീണ്ടും ഉപയോഗിക്കാനും അതുവഴി യുഐ കുറയ്ക്കാനും ശരിയായ ആർക്കിടെക്ചർ നേടാനും കഴിയും.

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

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

തൽഫലമായി, അക്കൗണ്ടുകളുടെയും ഇൻഷുറൻസിന്റെയും സന്ദർഭങ്ങൾ ബന്ധിപ്പിച്ചിട്ടുണ്ടെന്ന് ഇത് മാറുന്നു. പുതിയ ആവശ്യകതകൾ ഉയർന്നുവരുമ്പോൾ, ഈ കപ്ലിംഗ് വികസനത്തിൽ ഇടപെടും, ഇതിനകം തന്നെ സങ്കീർണ്ണമായ ബിസിനസ്സ് യുക്തിയുടെ സങ്കീർണ്ണത വർദ്ധിപ്പിക്കും. ഈ പ്രശ്നം പരിഹരിക്കാൻ, നിങ്ങൾ കോഡിലെ സന്ദർഭങ്ങൾ തമ്മിലുള്ള അതിരുകൾ കണ്ടെത്തുകയും അവയുടെ ലംഘനങ്ങൾ നീക്കം ചെയ്യുകയും വേണം. ഉദാഹരണത്തിന്, ഇൻഷുറൻസ് പശ്ചാത്തലത്തിൽ, 20 അക്ക സെൻട്രൽ ബാങ്ക് അക്കൗണ്ട് നമ്പറും അക്കൗണ്ട് തുറന്ന തീയതിയും മതിയാകും.

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

വിതരണം ചെയ്ത ഇടപാടുകൾ ആവശ്യമായി വരുന്ന കോഡ് ഒഴിവാക്കില്ലെന്ന് ഞങ്ങൾ ഉറച്ചു തീരുമാനിച്ചു. ഞങ്ങളുടെ കാര്യത്തിൽ, ഈ നിയമം പിന്തുടരുന്നത് വളരെ എളുപ്പമായി മാറി. കർശനമായ വിതരണ ഇടപാടുകൾ ആവശ്യമായി വരുന്ന സാഹചര്യങ്ങൾ ഞങ്ങൾ ഇതുവരെ നേരിട്ടിട്ടില്ല - മൊഡ്യൂളുകൾ തമ്മിലുള്ള അന്തിമ സ്ഥിരത മതിയാകും.

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

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

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

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

അടുത്തതായി, ഞങ്ങൾ ഈ കോൺഫിഗറേഷൻ പ്രവർത്തനത്തിലേക്ക് വിടുന്നു, പക്ഷേ ഒരു പൈലറ്റ് അവസ്ഥയിലാണ്. ഞങ്ങളുടെ മിക്ക ഉപയോക്താക്കളും ഇപ്പോഴും പഴയ ബിസിനസ്സ് പ്രക്രിയകളിൽ പ്രവർത്തിക്കുന്നു. പുതിയ ഉപയോക്താക്കൾക്കായി, ഞങ്ങൾ മോണോലിത്തിക്ക് ആപ്ലിക്കേഷന്റെ ഒരു പുതിയ പതിപ്പ് വികസിപ്പിച്ചെടുക്കുന്നു, അതിൽ ഇനി ഈ പ്രക്രിയ അടങ്ങിയിട്ടില്ല. അടിസ്ഥാനപരമായി, പൈലറ്റായി പ്രവർത്തിക്കുന്ന ഒരു മോണോലിത്തിന്റെയും മൈക്രോ സർവീസിന്റെയും സംയോജനമാണ് ഞങ്ങളുടെ പക്കലുള്ളത്.

വിജയകരമായ ഒരു പൈലറ്റിനൊപ്പം, പുതിയ കോൺഫിഗറേഷൻ തീർച്ചയായും പ്രവർത്തനക്ഷമമാണെന്ന് ഞങ്ങൾ മനസ്സിലാക്കുന്നു, നമുക്ക് സമവാക്യത്തിൽ നിന്ന് പഴയ മോണോലിത്ത് നീക്കം ചെയ്യാനും പഴയ പരിഹാരത്തിന്റെ സ്ഥാനത്ത് പുതിയ കോൺഫിഗറേഷൻ ഉപേക്ഷിക്കാനും കഴിയും.

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

ഡാറ്റാബേസുമായി പ്രവർത്തിക്കുന്നു

ഡാറ്റാബേസ് സോഴ്സ് കോഡിനേക്കാൾ മോശമായി വിഭജിക്കാം, കാരണം അതിൽ നിലവിലെ സ്കീമ മാത്രമല്ല, ശേഖരിച്ച ചരിത്രപരമായ ഡാറ്റയും അടങ്ങിയിരിക്കുന്നു.

ഞങ്ങളുടെ ഡാറ്റാബേസിന് മറ്റ് പലരെയും പോലെ മറ്റൊരു പ്രധാന പോരായ്മയുണ്ട് - അതിന്റെ വലിയ വലിപ്പം. ഈ ഡാറ്റാബേസ് രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത് ഒരു മോണോലിത്തിന്റെ സങ്കീർണ്ണമായ ബിസിനസ്സ് ലോജിക്ക് അനുസരിച്ചാണ്, കൂടാതെ വിവിധ പരിധികളുള്ള സന്ദർഭങ്ങളുടെ പട്ടികകൾക്കിടയിൽ ശേഖരിക്കപ്പെട്ട ബന്ധങ്ങൾ.

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

കോഡിലെ പരിമിതമായ സന്ദർഭങ്ങളിലേക്കുള്ള അതേ വിഭജനം നമ്മെ വേർപെടുത്താൻ സഹായിക്കുന്നു. ഡാറ്റാബേസ് തലത്തിൽ ഞങ്ങൾ ഡാറ്റ എങ്ങനെ തകർക്കുന്നു എന്നതിനെക്കുറിച്ചുള്ള ഒരു നല്ല ആശയം ഇത് സാധാരണയായി നൽകുന്നു. ഏത് ടേബിളുകളാണ് ഒരു ബൗണ്ടഡ് കോണ്ടക്‌സ്‌റ്റിൽ ഉള്ളതെന്നും ഏതാണ് മറ്റൊന്നെന്നും ഞങ്ങൾ മനസ്സിലാക്കുന്നു.

ഡാറ്റാബേസ് പാർട്ടീഷനിംഗിന് ഞങ്ങൾ രണ്ട് ആഗോള രീതികൾ ഉപയോഗിച്ചു: നിലവിലുള്ള പട്ടികകളുടെ വിഭജനം, പ്രോസസ്സിംഗ് ഉപയോഗിച്ച് പാർട്ടീഷൻ ചെയ്യുക.

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

ബിസിനസ്സ് മോഡൽ വളരെയധികം മാറിയിരിക്കുമ്പോൾ പ്രോസസ്സിംഗ് ഉള്ള ഒരു വകുപ്പ് ആവശ്യമാണ്, കൂടാതെ പട്ടികകൾ ഇനി ഞങ്ങളെ തൃപ്തിപ്പെടുത്തുന്നില്ല.

നിലവിലുള്ള പട്ടികകൾ വിഭജിക്കുന്നു. നമ്മൾ എന്താണ് വേർതിരിക്കുന്നത് എന്ന് നിർണ്ണയിക്കേണ്ടതുണ്ട്. ഈ അറിവില്ലാതെ, ഒന്നും പ്രവർത്തിക്കില്ല, ഇവിടെ കോഡിലെ പരിമിതമായ സന്ദർഭങ്ങളുടെ വേർതിരിവ് നമ്മെ സഹായിക്കും. ഒരു ചട്ടം പോലെ, സോഴ്സ് കോഡിലെ സന്ദർഭങ്ങളുടെ അതിരുകൾ നിങ്ങൾക്ക് മനസിലാക്കാൻ കഴിയുമെങ്കിൽ, വകുപ്പിനായുള്ള പട്ടികയിൽ ഏതൊക്കെ പട്ടികകൾ ഉൾപ്പെടുത്തണമെന്ന് വ്യക്തമാകും.

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

അടുത്ത ഘട്ടം, വേർതിരിക്കപ്പെട്ട ടേബിളുകൾക്കൊപ്പം പ്രവർത്തിക്കുന്ന കോഡിന്റെ വിഭാഗത്തെ, പ്രോസസ്സിംഗ് ഉപയോഗിച്ചോ അല്ലാതെയോ, ഒരു പ്രത്യേക മൈക്രോസർവീസായി വേർതിരിക്കുകയും ഒരു പ്രത്യേക പ്രോസസ്സിൽ, ഒരു കണ്ടെയ്‌നറിൽ പ്രവർത്തിപ്പിക്കുകയും ചെയ്യാം. മോണോലിത്ത് ഡാറ്റാബേസിലേക്കും അതുമായി നേരിട്ട് ബന്ധമില്ലാത്ത പട്ടികകളിലേക്കും കണക്ഷനുള്ള ഒരു പ്രത്യേക സേവനമായിരിക്കും ഇത്. വേർപെടുത്താവുന്ന ഭാഗവുമായി മോണോലിത്ത് ഇപ്പോഴും വായനയ്ക്കായി സംവദിക്കുന്നു.

പിന്നീട് ഞങ്ങൾ ഈ കണക്ഷൻ നീക്കംചെയ്യും, അതായത്, വേർതിരിച്ച പട്ടികകളിൽ നിന്നുള്ള ഒരു മോണോലിത്തിക്ക് ആപ്ലിക്കേഷനിൽ നിന്നുള്ള ഡാറ്റ വായിക്കുന്നതും API-യിലേക്ക് മാറ്റും.

അടുത്തതായി, പുതിയ മൈക്രോസർവീസ് മാത്രം പ്രവർത്തിക്കുന്ന പട്ടികകൾ ഞങ്ങൾ പൊതുവായ ഡാറ്റാബേസിൽ നിന്ന് തിരഞ്ഞെടുക്കും. നമുക്ക് പട്ടികകൾ ഒരു പ്രത്യേക സ്കീമയിലേക്കോ ഒരു പ്രത്യേക ഫിസിക്കൽ ഡാറ്റാബേസിലേക്കോ നീക്കാൻ കഴിയും. മൈക്രോസർവീസും മോണോലിത്ത് ഡാറ്റാബേസും തമ്മിൽ ഇപ്പോഴും ഒരു വായനാ കണക്ഷനുണ്ട്, പക്ഷേ വിഷമിക്കേണ്ട കാര്യമില്ല, ഈ കോൺഫിഗറേഷനിൽ ഇതിന് വളരെക്കാലം ജീവിക്കാൻ കഴിയും.

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

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

Чтобы эта схема заработала, нам, скорее всего, потребуется переходный период.

അപ്പോൾ സാധ്യമായ രണ്ട് സമീപനങ്ങളുണ്ട്.

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

രണ്ടാമത്: ചില ബിസിനസ്സ് മാനദണ്ഡങ്ങൾക്കനുസൃതമായി ഞങ്ങൾ ഡാറ്റ വിഭജിക്കുന്നു. ഉദാഹരണത്തിന്, പഴയ ഡാറ്റാബേസിൽ സംഭരിച്ചിരിക്കുന്ന സിസ്റ്റത്തിൽ ഞങ്ങൾക്ക് 5 ഉൽപ്പന്നങ്ങൾ ഉണ്ടായിരുന്നു. ഒരു പുതിയ ഡാറ്റാബേസിൽ പുതിയ ബിസിനസ്സ് ടാസ്ക്കിനുള്ളിൽ ഞങ്ങൾ ആറാമത്തേത് സ്ഥാപിക്കുന്നു. എന്നാൽ ഞങ്ങൾക്ക് ഒരു API ഗേറ്റ്‌വേ ആവശ്യമാണ്, അത് ഈ ഡാറ്റ സമന്വയിപ്പിക്കുകയും ക്ലയന്റ് എവിടെ നിന്ന് എന്ത് നേടണമെന്ന് കാണിക്കുകയും ചെയ്യും.

രണ്ട് സമീപനങ്ങളും പ്രവർത്തിക്കുന്നു, സാഹചര്യം അനുസരിച്ച് തിരഞ്ഞെടുക്കുക.

എല്ലാം പ്രവർത്തിക്കുന്നുവെന്ന് ഞങ്ങൾക്ക് ഉറപ്പായ ശേഷം, പഴയ ഡാറ്റാബേസ് ഘടനകളിൽ പ്രവർത്തിക്കുന്ന മോണോലിത്തിന്റെ ഭാഗം പ്രവർത്തനരഹിതമാക്കാം.

പഴയ ഡാറ്റാ ഘടനകൾ നീക്കം ചെയ്യുക എന്നതാണ് അവസാന ഘട്ടം.

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

സോഴ്സ് കോഡ് ഉപയോഗിച്ച് പ്രവർത്തിക്കുന്നു

ഞങ്ങൾ മോണോലിത്തിക്ക് പ്രോജക്റ്റ് വിശകലനം ചെയ്യാൻ തുടങ്ങിയപ്പോൾ സോഴ്സ് കോഡ് ഡയഗ്രം ഇങ്ങനെയായിരുന്നു.

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

പ്രത്യേകമായി ഉപയോഗിക്കാവുന്ന അടിസ്ഥാന സൗകര്യ ലൈബ്രറികൾ ഉണ്ടായത് ഞങ്ങളുടെ ഭാഗ്യമായിരുന്നു.

ചില സാധാരണ വസ്തുക്കൾ യഥാർത്ഥത്തിൽ ഈ ലെയറിലുള്ളതല്ല, മറിച്ച് ഇൻഫ്രാസ്ട്രക്ചർ ലൈബ്രറികളായിരിക്കുമ്പോൾ ചിലപ്പോൾ ഒരു സാഹചര്യം ഉടലെടുത്തു. പേരുമാറ്റിയാണ് ഇത് പരിഹരിച്ചത്.

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

കോഡ് വിഭജന പ്രക്രിയയ്ക്കായി ഞങ്ങൾ നിരവധി നിയമങ്ങൾ രൂപപ്പെടുത്തിയിട്ടുണ്ട്.

ആദ്യത്തേത്: സേവനങ്ങൾ, പ്രവർത്തനങ്ങൾ, പ്ലഗിനുകൾ എന്നിവയ്ക്കിടയിൽ ബിസിനസ് ലോജിക് പങ്കിടാൻ ഞങ്ങൾ ഇനി ആഗ്രഹിക്കുന്നില്ല. മൈക്രോസർവീസുകളിൽ ബിസിനസ്സ് ലോജിക് സ്വതന്ത്രമാക്കാൻ ഞങ്ങൾ ആഗ്രഹിച്ചു. മറുവശത്ത്, മൈക്രോസർവീസുകൾ പൂർണ്ണമായും സ്വതന്ത്രമായി നിലനിൽക്കുന്ന സേവനങ്ങളായി കണക്കാക്കപ്പെടുന്നു. ഈ സമീപനം ഒരു പരിധിവരെ പാഴായതായി ഞാൻ വിശ്വസിക്കുന്നു, അത് നേടാൻ പ്രയാസമാണ്, കാരണം, ഉദാഹരണത്തിന്, C#-ലെ സേവനങ്ങൾ ഏത് സാഹചര്യത്തിലും ഒരു സാധാരണ ലൈബ്രറി വഴി ബന്ധിപ്പിക്കും. ഞങ്ങളുടെ സിസ്റ്റം C# ൽ എഴുതിയിരിക്കുന്നു; ഞങ്ങൾ ഇതുവരെ മറ്റ് സാങ്കേതികവിദ്യകൾ ഉപയോഗിച്ചിട്ടില്ല. അതിനാൽ, സാധാരണ സാങ്കേതിക അസംബ്ലികൾ ഉപയോഗിക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു. ബിസിനസ്സ് യുക്തിയുടെ ശകലങ്ങളൊന്നും അവയിൽ അടങ്ങിയിട്ടില്ല എന്നതാണ് പ്രധാന കാര്യം. നിങ്ങൾ ഉപയോഗിക്കുന്ന ORM-ന് മുകളിൽ ഒരു കൺവീനിയൻസ് റാപ്പർ ഉണ്ടെങ്കിൽ, അത് സേവനത്തിൽ നിന്ന് സേവനത്തിലേക്ക് പകർത്തുന്നത് വളരെ ചെലവേറിയതാണ്.

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

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

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

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

അങ്ങനെ, സോഴ്‌സ് കോഡിൽ പ്രവർത്തിക്കുന്നതിലൂടെയും ആർക്കിടെക്ചർ ചെറുതായി മാറ്റുന്നതിലൂടെയും റിപ്പോസിറ്ററികൾ വേർപെടുത്തുന്നതിലൂടെയും ഞങ്ങൾ ഞങ്ങളുടെ സേവനങ്ങളെ കൂടുതൽ സ്വതന്ത്രമാക്കുന്നു.

അടിസ്ഥാന സൗകര്യ പ്രശ്നങ്ങൾ

മൈക്രോസർവീസുകളിലേക്ക് മാറുന്നതിനുള്ള മിക്ക പോരായ്മകളും ഇൻഫ്രാസ്ട്രക്ചറുമായി ബന്ധപ്പെട്ടതാണ്. നിങ്ങൾക്ക് ഓട്ടോമേറ്റഡ് വിന്യാസം ആവശ്യമാണ്, അടിസ്ഥാന സൗകര്യങ്ങൾ പ്രവർത്തിപ്പിക്കുന്നതിന് നിങ്ങൾക്ക് പുതിയ ലൈബ്രറികൾ ആവശ്യമാണ്.

പരിസരങ്ങളിൽ സ്വമേധയാലുള്ള ഇൻസ്റ്റാളേഷൻ

തുടക്കത്തിൽ, പരിസ്ഥിതികൾക്കുള്ള പരിഹാരം ഞങ്ങൾ സ്വമേധയാ ഇൻസ്റ്റാൾ ചെയ്തു. ഈ പ്രക്രിയ ഓട്ടോമേറ്റ് ചെയ്യുന്നതിന്, ഞങ്ങൾ ഒരു CI/CD പൈപ്പ്ലൈൻ സൃഷ്ടിച്ചു. ബിസിനസ് പ്രക്രിയകളുടെ വീക്ഷണകോണിൽ നിന്ന് തുടർച്ചയായ വിന്യാസം ഞങ്ങൾക്ക് ഇതുവരെ സ്വീകാര്യമല്ലാത്തതിനാൽ ഞങ്ങൾ തുടർച്ചയായ ഡെലിവറി പ്രക്രിയ തിരഞ്ഞെടുത്തു. അതിനാൽ, പ്രവർത്തനത്തിനായി അയയ്ക്കുന്നത് ഒരു ബട്ടൺ ഉപയോഗിച്ചാണ് നടത്തുന്നത്, കൂടാതെ പരിശോധനയ്ക്കായി - സ്വയമേവ.

ഞങ്ങൾ സോഴ്‌സ് കോഡ് സംഭരണത്തിനായി അറ്റ്ലാസിയൻ, ബിറ്റ്ബക്കറ്റ്, നിർമ്മാണത്തിനായി മുള എന്നിവ ഉപയോഗിക്കുന്നു. കേക്കിൽ ബിൽഡ് സ്ക്രിപ്റ്റുകൾ എഴുതാൻ ഞങ്ങൾ ഇഷ്ടപ്പെടുന്നു, കാരണം ഇത് C# പോലെയാണ്. റെഡിമെയ്ഡ് പാക്കേജുകൾ ആർട്ടിഫാക്‌ടറിയിലേക്ക് വരുന്നു, കൂടാതെ അൻസിബിൾ സ്വയമേവ ടെസ്റ്റ് സെർവറുകളിലേക്ക് എത്തുന്നു, അതിനുശേഷം അവ ഉടനടി പരിശോധിക്കാൻ കഴിയും.

പ്രത്യേക ലോഗിംഗ്

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

Filebeat ഉപയോഗിച്ച്, സെർവറുകളിൽ നിന്ന് ഞങ്ങളുടെ ലോഗുകൾ ശേഖരിക്കാനും പിന്നീട് അവയെ രൂപാന്തരപ്പെടുത്താനും UI-യിൽ ചോദ്യങ്ങൾ നിർമ്മിക്കാനും കിബാന ഉപയോഗിക്കാനും സേവനങ്ങൾക്കിടയിൽ കോൾ എങ്ങനെ നടന്നുവെന്ന് കാണാനും ഞങ്ങൾക്ക് അവസരം ലഭിക്കും. ട്രേസ് ഐഡി ഇതിന് വളരെയധികം സഹായിക്കുന്നു.

ബന്ധപ്പെട്ട സേവനങ്ങൾ പരിശോധിക്കുന്നതും ഡീബഗ്ഗുചെയ്യുന്നതും

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

സേവനങ്ങളുടെ പ്രൊഡക്ഷൻ പതിപ്പുകൾ മാത്രം പ്രവർത്തിപ്പിക്കുന്ന സെർവറുകൾ ഉണ്ട്. വിന്യാസത്തിന് മുമ്പ് ഡെലിവറി പരിശോധിക്കുന്നതിനും ആന്തരിക പരിശീലനത്തിനും ഈ സെർവറുകൾ ആവശ്യമാണ്.

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

കൂടാതെ, ലോഡ് ടെസ്റ്റിംഗിന്റെ ആവശ്യകത വർദ്ധിച്ചു; മുമ്പ് ഇത് അപൂർവ സന്ദർഭങ്ങളിൽ മാത്രമാണ് നടത്തിയത്. ടെസ്റ്റുകൾ പ്രവർത്തിപ്പിക്കാൻ JMeter, അവ സംഭരിക്കുന്നതിന് InfluxDB, പ്രോസസ് ഗ്രാഫുകൾ നിർമ്മിക്കാൻ Grafana എന്നിവ ഞങ്ങൾ ഉപയോഗിക്കുന്നു.

നമ്മൾ എന്താണ് നേടിയത്?

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

നമ്മുടെ സിസ്റ്റത്തിൽ മാരകമായ പരാജയങ്ങളൊന്നുമില്ല. ഒരു ബഗ് ഉള്ള ഒരു മൈക്രോസർവീസ് ഞങ്ങൾ റിലീസ് ചെയ്താൽ, അതുമായി ബന്ധപ്പെട്ട പ്രവർത്തനം തകരാറിലാകും, മറ്റെല്ലാ പ്രവർത്തനങ്ങളെയും ബാധിക്കില്ല. ഇത് ഉപയോക്തൃ അനുഭവം വളരെയധികം മെച്ചപ്പെടുത്തുന്നു.

വിന്യാസ പാറ്റേൺ നമുക്ക് നിയന്ത്രിക്കാം. ആവശ്യമെങ്കിൽ, ബാക്കിയുള്ള പരിഹാരങ്ങളിൽ നിന്ന് പ്രത്യേകം സേവനങ്ങളുടെ ഗ്രൂപ്പുകൾ നിങ്ങൾക്ക് തിരഞ്ഞെടുക്കാം.

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

സംഗ്രഹം

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

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

  PS കൂടുതൽ വൈകാരികമായ ഒരു കഥ (നിങ്ങൾക്ക് വ്യക്തിപരമായി എന്നപോലെ) - അനുസരിച്ച് ലിങ്ക്.
  റിപ്പോർട്ടിന്റെ പൂർണരൂപം ഇതാ.

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