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

ഹലോ, ഹാബർ. ഒരു പുതിയ കോഴ്‌സ് സ്ട്രീമിനുള്ള എൻറോൾമെന്റ് ഇപ്പോൾ OTUS-ൽ തുറന്നിരിക്കുന്നു "സോഫ്റ്റ്‌വെയർ ആർക്കിടെക്റ്റ്". കോഴ്‌സ് ആരംഭിക്കുന്നതിന്റെ തലേന്ന്, എന്റെ യഥാർത്ഥ ലേഖനം നിങ്ങളുമായി പങ്കിടാൻ ഞാൻ ആഗ്രഹിക്കുന്നു.

ആമുഖം

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

ഒരു ചെറിയ ചരിത്രം

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

ചുരുക്കത്തിൽ, ഞങ്ങളുടെ നിലവിലെ ധാരണയിലെ മൈക്രോസർവീസുകൾ ഇനിപ്പറയുന്ന രീതിയിൽ ഉടലെടുത്തു: 2011-ൽ, വിവിധ കമ്പനികളുടെ പ്രവർത്തനങ്ങൾ വിശകലനം ചെയ്തുകൊണ്ട് ജെയിംസ് ലൂയിസ് ഒരു പുതിയ "മൈക്രോ-ആപ്പ്" പാറ്റേണിന്റെ ആവിർഭാവത്തിലേക്ക് ശ്രദ്ധ ആകർഷിച്ചു, ഇത് വിന്യാസം ത്വരിതപ്പെടുത്തുന്നതിന് SOA യെ ഒപ്റ്റിമൈസ് ചെയ്തു. സേവനങ്ങള്. കുറച്ച് കഴിഞ്ഞ്, 2012-ൽ, ഒരു ആർക്കിടെക്ചർ ഉച്ചകോടിയിൽ, പാറ്റേണിനെ മൈക്രോ സർവീസ് എന്ന് പുനർനാമകരണം ചെയ്തു. അങ്ങനെ, മൈക്രോസർവീസുകൾ അവതരിപ്പിക്കുന്നതിന്റെ പ്രാരംഭ ലക്ഷ്യം കുപ്രസിദ്ധരെ മെച്ചപ്പെടുത്തുക എന്നതായിരുന്നു മാർക്കറ്റിലേക്കുള്ള സമയം.

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

മേൽപ്പറഞ്ഞവയെല്ലാം ഉണ്ടായിരുന്നിട്ടും, വളരെ കുറച്ച് ഡെവലപ്പർമാർക്ക് ഇപ്പോഴും "മൈക്രോ സർവീസ്" എന്ന ആശയം നിർവചിക്കാൻ കഴിയും. എന്നാൽ നമുക്ക് ഇതിനെക്കുറിച്ച് കുറച്ച് കഴിഞ്ഞ് സംസാരിക്കാം ...

മോണോലിത്ത്

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

വലുപ്പം

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

ബന്ധം

മോണോലിത്ത് ഒരു "ചെളിയുടെ വലിയ പന്ത്" ആണ്, അതിൽ മാറ്റങ്ങൾ പ്രവചനാതീതമായ പ്രത്യാഘാതങ്ങൾക്ക് ഇടയാക്കും. ഒരിടത്ത് മാറ്റങ്ങൾ വരുത്തുന്നതിലൂടെ, നിങ്ങൾക്ക് മറ്റൊരിടത്ത് മോണോലിത്തിന് കേടുപാടുകൾ വരുത്താം (അതേ "നിങ്ങൾ ചെവിയിൽ മാന്തികുഴിയുണ്ടാക്കി, *@ വീണു"). മോണോലിത്തിലെ ഘടകങ്ങൾക്ക് വളരെ സങ്കീർണ്ണവും, ഏറ്റവും പ്രധാനമായി, വ്യക്തമല്ലാത്തതുമായ ബന്ധങ്ങളുണ്ട് എന്നതാണ് ഇതിന് കാരണം.

വിന്യാസം

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

സ്കേലബിളിറ്റി

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

മറ്റൊരു ഉദാഹരണം (കൂടുതൽ ക്ലാസിക്): സേവനം A സേവനം B എന്നതിനേക്കാൾ വളരെ ജനപ്രിയമാണ്, അതിനാൽ 100 ​​സേവനങ്ങൾ A, 10 സേവനങ്ങൾ B എന്നിവ ഉണ്ടായിരിക്കണമെന്ന് നിങ്ങൾ ആഗ്രഹിക്കുന്നു. വീണ്ടും, രണ്ട് ഓപ്ഷനുകൾ: ഒന്നുകിൽ ഞങ്ങൾ 100 പൂർണ്ണമായ മോണോലിത്തുകൾ വിന്യസിക്കുന്നു, അല്ലെങ്കിൽ ചിലതിൽ സേവനങ്ങൾ ബി സ്വമേധയാ പ്രവർത്തനരഹിതമാക്കേണ്ടതുണ്ട്.

വിശ്വാസ്യത

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

ജഡത്വത്തെ

മോണോലിത്തിന്റെ വലിപ്പം കാരണം, പുതിയ സാങ്കേതികവിദ്യകളിലേക്ക് മാറുന്നത് ബുദ്ധിമുട്ടാണ്. തൽഫലമായി, അതേ സീനിയർ നിലനിർത്തുന്നത് ഒരു പ്രത്യേക ജോലിയാണ്. ഒരു പ്രോജക്റ്റിന്റെ തുടക്കത്തിൽ തിരഞ്ഞെടുത്ത ടെക്നോളജി സ്റ്റാക്ക് ഉൽപ്പന്നത്തിന്റെ വികസനത്തെ തടസ്സപ്പെടുത്തുന്ന ഒരു ബ്ലോക്കായി മാറിയേക്കാം.

തീരുമാനം

ഘടകങ്ങൾ, SOA എന്നിവയിലേക്ക് നീങ്ങിക്കൊണ്ട് ആളുകൾ ഈ പ്രശ്നങ്ങൾ എങ്ങനെ പരിഹരിക്കാൻ ശ്രമിച്ചു എന്നതിനെക്കുറിച്ച് അടുത്ത തവണ നമ്മൾ സംസാരിക്കും.

കൂടുതൽ വായിക്കുക:

• എന്തുകൊണ്ട് SQL സെർവർ ഓർഡർ പ്രകാരം ഫലങ്ങൾ അടുക്കുന്നതിന് ഉറപ്പുനൽകുന്നില്ല
• ഡെവലപ്പർമാർക്കും അഡ്മിനിസ്ട്രേറ്റർമാർക്കുമുള്ള വാസ്തുവിദ്യ: ആർക്കൊക്കെ എന്ത് കഴിവുകൾ ആവശ്യമാണ്?

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