മൈക്രോസർവീസുകൾ: അവ എന്തൊക്കെയാണ്, അവ എന്തിനാണ്, എപ്പോൾ നടപ്പിലാക്കണം

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

കോൺവേയുടെ നിയമവും ബിസിനസ്സ്, ഓർഗനൈസേഷൻ, ഇൻഫർമേഷൻ സിസ്റ്റം എന്നിവ തമ്മിലുള്ള ബന്ധവും

ഒരിക്കൽ കൂടി ഉദ്ധരിക്കാൻ ഞാൻ എന്നെ അനുവദിക്കും:

"ഒരു സിസ്റ്റം രൂപകൽപ്പന ചെയ്യുന്ന ഏതൊരു ഓർഗനൈസേഷനും (വിശാലമായ അർത്ഥത്തിൽ) ഒരു ഡിസൈൻ ലഭിക്കും, അതിൻ്റെ ഘടന ആ ഓർഗനൈസേഷനിലെ ടീമുകളുടെ ഘടനയെ ആവർത്തിക്കുന്നു."
- മെൽവിൻ കോൺവേ, 1967

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

വിവര സംവിധാനങ്ങളുടെ ബിസിനസ് ഓറിയൻ്റേഷൻ

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

എല്ലാം ഒഴുകുന്നു, എല്ലാം മാറുന്നു, അല്ലെങ്കിൽ മൈക്രോ സർവീസുകൾ സങ്കീർണ്ണതയെ ചെറുക്കാനുള്ള മാർഗമാണോ?

നമ്മൾ തുടരുന്നതിന് മുമ്പ്, മൈക്രോസർവീസ് ആർക്കിടെക്ചറിനെക്കുറിച്ചുള്ള ചില തെറ്റിദ്ധാരണകൾ നോക്കാം.

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

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

ഉൽപ്പന്ന ജീവിത ചക്രവും സേവന ജീവിത ചക്രവും

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

വിവര സംവിധാനങ്ങളുടെ പരിണാമത്തിൻ്റെ അടുത്ത ഘട്ടത്തിലേക്ക് നമുക്ക് പോകാം - SOA യുടെ സേവന-അധിഷ്ഠിത വാസ്തുവിദ്യയിലേക്ക്. അതിനാൽ, ചില പ്രത്യേക ഘട്ടങ്ങളിൽ ഞങ്ങൾ ഞങ്ങളുടെ ഉൽപ്പന്നത്തിൽ ഹൈലൈറ്റ് ചെയ്തു ദീർഘകാല സേവനങ്ങൾ - ഒരു ഉൽപ്പന്നത്തിൻ്റെ പതിപ്പുകൾക്കിടയിൽ നീങ്ങുമ്പോൾ, സേവനത്തിൻ്റെ ജീവിത ചക്രം ഉൽപ്പന്നത്തിൻ്റെ അടുത്ത പതിപ്പിൻ്റെ ജീവിത ചക്രത്തേക്കാൾ ദൈർഘ്യമേറിയതായിരിക്കാനുള്ള അവസരമുണ്ട് എന്ന അർത്ഥത്തിൽ ദീർഘകാലം ജീവിച്ചിരിക്കുന്നു. അവ മാറ്റാതിരിക്കുന്നത് യുക്തിസഹമാണ് - ഞങ്ങൾ അടുത്ത പതിപ്പിലേക്കുള്ള പരിവർത്തനത്തിൻ്റെ വേഗതയാണ് പ്രധാനം. പക്ഷേ, അയ്യോ, സേവനങ്ങളിൽ നിരന്തരമായ മാറ്റങ്ങൾ വരുത്താൻ ഞങ്ങൾ നിർബന്ധിതരാകുന്നു - ഇവിടെ എല്ലാം ഞങ്ങൾക്ക് വേണ്ടി പ്രവർത്തിക്കുന്നു, DevOps പ്രാക്ടീസുകൾ, കണ്ടെയ്നറൈസേഷൻ, അങ്ങനെ പലതും - മനസ്സിൽ വരുന്ന എല്ലാം. എന്നാൽ ഇവ ഇപ്പോഴും മൈക്രോസർവീസുകളല്ല!

സങ്കീർണ്ണതയെ ചെറുക്കാനുള്ള ഉപാധിയായി മൈക്രോ സർവീസുകൾ... കോൺഫിഗറേഷൻ മാനേജ്മെൻ്റ്

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

കണ്ടെത്തലുകൾ

• സിസ്റ്റത്തിൻ്റെ വാസ്തുവിദ്യ അതിൻ്റെ ഘടകങ്ങളുടെ ജീവിത ചക്രം അനുസരിച്ചായിരിക്കണം. ഒരു ഘടകം ഒരു ഉൽപ്പന്ന പതിപ്പിനുള്ളിൽ താമസിക്കുന്നുണ്ടെങ്കിൽ, മൈക്രോ സർവീസ് സമീപനം ഉപയോഗിച്ച് സിസ്റ്റത്തിൻ്റെ സങ്കീർണ്ണത വർദ്ധിപ്പിക്കുന്നതിൽ അർത്ഥമില്ല.
• മൈക്രോസർവീസ് ആർക്കിടെക്ചർ ഡൊമെയ്ൻ മോഡലിനെ അടിസ്ഥാനമാക്കിയുള്ളതായിരിക്കണം - കാരണം ബിസിനസ് അവസരമാണ് ഏറ്റവും കൂടുതൽ കാലം നിലനിൽക്കുന്ന ഡൊമെയ്ൻ
• ഡെലിവറി പ്രാക്ടീസുകളും (DevOps പ്രാക്ടീസുകളും) ഓർക്കസ്ട്രേഷനും മൈക്രോസർവീസ് ആർക്കിടെക്ചറിന് ഏറ്റവും പ്രധാനപ്പെട്ട ഒന്നാണ് - ഘടകങ്ങളുടെ മാറ്റത്തിൻ്റെ നിരക്കിലെ വർദ്ധനവ് ഡെലിവറി വേഗതയിലും ഗുണനിലവാരത്തിലും ആവശ്യകതകൾ വർദ്ധിപ്പിക്കുന്നു.

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