വാസ്തുവിദ്യാ ശൈലിയുടെ തിരഞ്ഞെടുപ്പ് (ഭാഗം 2)

ഹലോ, ഹബ്ർ. കോഴ്‌സിന്റെ ഒരു പുതിയ സ്ട്രീം ആരംഭിക്കുന്നതിനായി ഞാൻ പ്രത്യേകമായി എഴുതിയ പ്രസിദ്ധീകരണങ്ങളുടെ ഒരു പരമ്പര ഇന്ന് ഞാൻ തുടരുന്നു. "സോഫ്റ്റ്‌വെയർ ആർക്കിടെക്റ്റ്".

ആമുഖം

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

В അവസാന സമയം ഞങ്ങൾ മോണോലിത്ത് കൈകാര്യം ചെയ്യുകയും മോണോലിത്തിന് നിരവധി പ്രശ്‌നങ്ങളുണ്ടെന്ന നിഗമനത്തിലെത്തി: വലുപ്പം, കണക്റ്റിവിറ്റി, വിന്യാസം, സ്കേലബിളിറ്റി, വിശ്വാസ്യത, കാഠിന്യം.

മൊഡ്യൂളുകൾ/ലൈബ്രറികൾ (ഘടക-അധിഷ്ഠിത ആർക്കിടെക്ചർ) അല്ലെങ്കിൽ സേവനങ്ങൾ (സേവന-അധിഷ്ഠിത ആർക്കിടെക്ചർ) ആയി ഒരു സിസ്റ്റം സംഘടിപ്പിക്കുന്നതിനുള്ള സാധ്യതകളെക്കുറിച്ച് സംസാരിക്കാൻ ഞാൻ ഇത്തവണ നിർദ്ദേശിക്കുന്നു.

ഘടക-അധിഷ്ഠിത വാസ്തുവിദ്യ

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

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

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

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

"അനുയോജ്യമായ" മോണോലിത്ത് എന്നത് യുക്തിസഹമായി വേർതിരിച്ച മൊഡ്യൂളുകളുടെ ഒരു കൂട്ടമാണ്, അവ ഓരോന്നും സ്വന്തം ഡാറ്റാബേസിലേക്ക് നോക്കുന്നു.

സേവന-അധിഷ്ഠിത വാസ്തുവിദ്യ

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

സേവന-അധിഷ്‌ഠിത ആർക്കിടെക്‌ചർ (SOA = സർവീസ് ഓറിയന്റഡ് ആർക്കിടെക്‌ചർ) ഒരു മോണോലിത്തിന്റെ തിരിച്ചറിഞ്ഞ എല്ലാ പ്രശ്‌നങ്ങളും പരിഹരിക്കുന്നു: ഒരു മാറ്റം സംഭവിക്കുമ്പോൾ ഒരു സേവനത്തെ മാത്രമേ ബാധിക്കുകയുള്ളൂ, നന്നായി നിർവചിക്കപ്പെട്ട API ഘടകങ്ങളുടെ നല്ല എൻക്യാപ്‌സലേഷനെ പിന്തുണയ്‌ക്കുന്നു.

എന്നാൽ എല്ലാം അത്ര സുഗമമല്ല: SOA പുതിയ പ്രശ്നങ്ങൾ സൃഷ്ടിക്കുന്നു. റിമോട്ട് കോളുകൾ ലോക്കൽ കോളുകളേക്കാൾ ചെലവേറിയതാണ്, ഘടകങ്ങൾ തമ്മിലുള്ള ഉത്തരവാദിത്തങ്ങൾ പുനർവിതരണം ചെയ്യുന്നത് വളരെ ചെലവേറിയതായി മാറിയിരിക്കുന്നു.

വഴിയിൽ, സ്വതന്ത്ര വിന്യാസത്തിന്റെ സാധ്യത സേവനത്തിന്റെ വളരെ പ്രധാനപ്പെട്ട സവിശേഷതയാണ്. സേവനങ്ങൾ ഒരുമിച്ച് വിന്യസിക്കുകയോ അല്ലെങ്കിൽ, ഒരു നിശ്ചിത ക്രമത്തിൽ വിന്യസിക്കുകയോ ചെയ്യേണ്ടതുണ്ടെങ്കിൽ, സിസ്റ്റം സേവനാധിഷ്ഠിതമായി കണക്കാക്കാനാവില്ല. ഈ സാഹചര്യത്തിൽ, അവർ വിതരണം ചെയ്ത മോണോലിത്തിനെക്കുറിച്ച് സംസാരിക്കുന്നു (എസ്ഒഎയുടെ വീക്ഷണകോണിൽ നിന്ന് മാത്രമല്ല, മൈക്രോസർവീസ് ആർക്കിടെക്ചറിന്റെ വീക്ഷണകോണിൽ നിന്നും ഒരു ആന്റി-പാറ്റേൺ കണക്കാക്കപ്പെടുന്നു).

സേവന-അധിഷ്ഠിത വാസ്തുവിദ്യയെ വാസ്തുവിദ്യാ സമൂഹവും വെണ്ടർമാരും നന്നായി പിന്തുണയ്ക്കുന്നു. ഇത് നിരവധി കോഴ്സുകളുടെയും സർട്ടിഫിക്കേഷനുകളുടെയും സാന്നിധ്യം, നന്നായി വികസിപ്പിച്ച പാറ്റേണുകൾ എന്നിവയെ സൂചിപ്പിക്കുന്നു. രണ്ടാമത്തേതിൽ, ഉദാഹരണത്തിന്, അറിയപ്പെടുന്ന എന്റർപ്രൈസ് സർവീസ് ബസ് (ESB = എന്റർപ്രൈസ് സർവീസ് ബസ്) ഉൾപ്പെടുന്നു. അതേ സമയം, ESB വെണ്ടർമാരിൽ നിന്നുള്ള ഒരു ലഗേജാണ്; അത് SOA-യിൽ ഉപയോഗിക്കണമെന്നില്ല.

സേവന-അധിഷ്ഠിത വാസ്തുവിദ്യയുടെ ജനപ്രീതി 2008-ഓടെ ഉയർന്നു, അതിനുശേഷം അത് കുറയാൻ തുടങ്ങി, മൈക്രോസർവീസുകളുടെ (~2015) വരവിനുശേഷം ഇത് കൂടുതൽ നാടകീയമായി.

തീരുമാനം

സേവനങ്ങളുടെയും മൊഡ്യൂളുകളുടെയും രൂപത്തിൽ വിവര സംവിധാനങ്ങൾ സംഘടിപ്പിക്കുന്നതിനുള്ള സാധ്യതകളെക്കുറിച്ച് ഞങ്ങൾ ചർച്ച ചെയ്ത ശേഷം, മൈക്രോസർവീസ് ആർക്കിടെക്ചറിന്റെ തത്വങ്ങളിലേക്ക് പോകാനും അടുത്ത ഭാഗത്ത് മൈക്രോ സർവീസ് ആർക്കിടെക്ചറും സേവന-അധിഷ്ഠിത ആർക്കിടെക്ചറും തമ്മിലുള്ള വ്യത്യാസത്തിൽ പ്രത്യേക ശ്രദ്ധ നൽകാനും ഞാൻ നിർദ്ദേശിക്കുന്നു.

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