മൈക്രോസർവീസുകൾ: നിങ്ങൾക്ക് കുബർനെറ്റുകളുണ്ടെങ്കിൽപ്പോലും വലുപ്പം പ്രധാനമാണ്

സെപ്റ്റംബർ 19 മോസ്കോയിൽ സംഭവിച്ചു മൈക്രോസർവീസുകൾക്കായി സമർപ്പിച്ച ആദ്യത്തെ തീമാറ്റിക് മീറ്റിംഗ് HUG (ഹൈലോഡ്++ യൂസർ ഗ്രൂപ്പ്). “ഓപ്പറേറ്റിംഗ് മൈക്രോസർവീസസ്: വലുപ്പം പ്രധാനമാണ്, നിങ്ങൾക്ക് കുബർനെറ്റുകൾ ഉണ്ടെങ്കിൽ പോലും” എന്ന ഒരു അവതരണം ഉണ്ടായിരുന്നു, അതിൽ മൈക്രോ സർവീസ് ആർക്കിടെക്ചറുമായി പ്രോജക്ടുകൾ പ്രവർത്തിപ്പിക്കുന്നതിൽ ഫ്ലാന്റിന്റെ വിപുലമായ അനുഭവം ഞങ്ങൾ പങ്കിട്ടു. ഒന്നാമതായി, അവരുടെ നിലവിലുള്ള അല്ലെങ്കിൽ ഭാവി പദ്ധതിയിൽ ഈ സമീപനം ഉപയോഗിക്കുന്നതിനെക്കുറിച്ച് ചിന്തിക്കുന്ന എല്ലാ ഡവലപ്പർമാർക്കും ഇത് ഉപയോഗപ്രദമാകും.

പരിചയപ്പെടുത്തുന്നു റിപ്പോർട്ടിന്റെ വീഡിയോ (50 മിനിറ്റ്, ലേഖനത്തേക്കാൾ വളരെ വിവരദായകമാണ്), അതുപോലെ അതിൽ നിന്നുള്ള പ്രധാന എക്സ്ട്രാക്റ്റും ടെക്സ്റ്റ് രൂപത്തിൽ.

NB: ഈ പോസ്റ്റിന്റെ അവസാനം വീഡിയോയും അവതരണവും ലഭ്യമാണ്.

ആമുഖം

സാധാരണയായി ഒരു നല്ല കഥയ്ക്ക് ഒരു തുടക്കവും ഒരു പ്രധാന ഇതിവൃത്തവും ഒരു പ്രമേയവും ഉണ്ടായിരിക്കും. ഈ റിപ്പോർട്ട് ഒരു ആമുഖം പോലെയാണ്, അതൊരു ദുരന്തവുമാണ്. മൈക്രോസർവീസുകളെക്കുറിച്ചുള്ള ഒരു ബാഹ്യ വീക്ഷണം ഇത് പ്രദാനം ചെയ്യുന്നു എന്നതും ശ്രദ്ധിക്കേണ്ടതാണ്. ചൂഷണം.

ഞാൻ ഈ ഗ്രാഫിൽ നിന്ന് ആരംഭിക്കും, അതിന്റെ രചയിതാവ് (2015 ൽ) മാറി മാർട്ടിൻ ഫൗളർ:

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

Kubernetes ഉപയോഗിക്കുന്നതിന് ഞാൻ ഈ ഗ്രാഫിലേക്ക് ചേർക്കും:

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

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

ഉപയോഗപ്രദവും ദോഷകരവുമായ മൈക്രോസർവീസുകൾ

പ്രധാന ആശയം ഇതാ:

എന്താണ് സാധാരണ മൈക്രോ സർവീസ് ആർക്കിടെക്ചർ? ഇത് നിങ്ങൾക്ക് യഥാർത്ഥ നേട്ടങ്ങൾ നൽകുകയും നിങ്ങളുടെ ജോലി കാര്യക്ഷമത വർദ്ധിപ്പിക്കുകയും ചെയ്യും. നമ്മൾ ഗ്രാഫിലേക്ക് മടങ്ങുകയാണെങ്കിൽ, ഇതാ:

അവളെ വിളിച്ചാൽ ഉപയോഗപ്രദമായ, അപ്പോൾ ഗ്രാഫിന്റെ മറുവശത്ത് ഉണ്ടാകും ഹാനികരമായ microservices (ജോലിയിൽ ഇടപെടുന്നു):

"പ്രധാന ആശയത്തിലേക്ക്" മടങ്ങുന്നു: എന്റെ അനുഭവത്തെ ഞാൻ വിശ്വസിക്കണോ? ഈ വർഷം ആദ്യം മുതൽ ഞാൻ നോക്കി 85 പദ്ധതികൾ. അവയെല്ലാം മൈക്രോസർവീസുകളായിരുന്നില്ല (ഏകദേശം മൂന്നിലൊന്ന് മുതൽ പകുതി വരെ അത്തരമൊരു വാസ്തുവിദ്യ ഉണ്ടായിരുന്നു), എന്നാൽ ഇത് ഇപ്പോഴും ഒരു വലിയ സംഖ്യയാണ്. ചെറിയ കമ്പനികളിലും (5 ഡവലപ്പർമാർ ഉള്ളത്) വലിയ കമ്പനികളിലും (~500 ഡവലപ്പർമാർ) വികസിപ്പിച്ച വിവിധ തരത്തിലുള്ള ആപ്ലിക്കേഷനുകൾ ഔട്ട്‌സോഴ്‌സർമാരായ ഞങ്ങൾക്ക് (ഫ്ലാന്റ് കമ്പനി) കാണാൻ കഴിയും. ഈ ആപ്ലിക്കേഷനുകൾ വർഷങ്ങളായി തത്സമയം വികസിക്കുന്നത് ഞങ്ങൾ കാണുന്നുവെന്നതാണ് ഒരു അധിക നേട്ടം.

എന്തുകൊണ്ട് മൈക്രോസർവീസുകൾ?

മൈക്രോസർവീസിന്റെ നേട്ടങ്ങളെക്കുറിച്ചുള്ള ചോദ്യത്തിന് ഉണ്ട് വളരെ കൃത്യമായ ഉത്തരം ഇതിനകം സൂചിപ്പിച്ച മാർട്ടിൻ ഫൗളറിൽ നിന്ന്:

1. മോഡുലാരിറ്റിയുടെ വ്യക്തമായ അതിരുകൾ;
2. സ്വതന്ത്ര വിന്യാസം;
3. സാങ്കേതികവിദ്യകൾ തിരഞ്ഞെടുക്കാനുള്ള സ്വാതന്ത്ര്യം.

സോഫ്‌റ്റ്‌വെയർ ആർക്കിടെക്‌റ്റുമാരോടും ഡെവലപ്പർമാരോടും ഞാൻ ഒരുപാട് സംസാരിച്ചു, അവർക്ക് എന്തിനാണ് മൈക്രോസർവീസുകൾ വേണ്ടത് എന്ന് ചോദിച്ചു. അവരുടെ പ്രതീക്ഷകളുടെ പട്ടിക ഞാൻ തയ്യാറാക്കി. സംഭവിച്ചത് ഇതാ:

“സംവേദനങ്ങളിൽ” ചില പോയിന്റുകൾ ഞങ്ങൾ വിവരിക്കുകയാണെങ്കിൽ:

• മൊഡ്യൂളുകളുടെ വ്യക്തമായ അതിരുകൾ: ഇവിടെ നമുക്ക് ഭയങ്കരമായ ഒരു മോണോലിത്ത് ഉണ്ട്, ഇപ്പോൾ എല്ലാം Git റിപ്പോസിറ്ററികളിൽ ഭംഗിയായി ക്രമീകരിക്കും, അതിൽ എല്ലാം "അലമാരയിൽ" ഉണ്ട്, ഊഷ്മളവും മൃദുവും കലർന്നതല്ല;
• വിന്യാസ സ്വാതന്ത്ര്യം: വികസനം വേഗത്തിലാക്കാൻ ഞങ്ങൾക്ക് സ്വതന്ത്രമായി സേവനങ്ങൾ പുറത്തിറക്കാൻ കഴിയും (പുതിയ സവിശേഷതകൾ സമാന്തരമായി പ്രസിദ്ധീകരിക്കുക);
• വികസന സ്വാതന്ത്ര്യം: ഞങ്ങൾക്ക് ഈ മൈക്രോസർവീസ് ഒരു ടീമിന്/ഡെവലപ്പർക്ക് നൽകാം, അത് മറ്റൊന്നിനും, നമുക്ക് വേഗത്തിൽ വികസിപ്പിക്കാൻ കഴിയും;
• боകൂടുതൽ വിശ്വാസ്യത: ഭാഗികമായ അപചയം സംഭവിക്കുകയാണെങ്കിൽ (20-ൽ ഒരു മൈക്രോസർവീസ് വീഴുന്നു), അപ്പോൾ ഒരു ബട്ടൺ മാത്രം പ്രവർത്തിക്കുന്നത് നിർത്തും, കൂടാതെ സിസ്റ്റം മൊത്തത്തിൽ പ്രവർത്തിക്കുന്നത് തുടരും.

സാധാരണ (ഹാനികരമായ) മൈക്രോ സർവീസ് ആർക്കിടെക്ചർ

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

ആമസോണുമായോ കുറഞ്ഞത് ഓസോണുമായോ മത്സരിക്കാൻ പോകുന്ന ഒരു അമൂർത്ത ഓൺലൈൻ സ്റ്റോറാണ് ഒരു ഉദാഹരണം. ഇതിന്റെ മൈക്രോ സർവീസ് ആർക്കിടെക്ചർ ഇതുപോലെ കാണപ്പെടുന്നു:

ഒരു കൂട്ടം കാരണങ്ങളാൽ, ഈ മൈക്രോസർവീസുകൾ വ്യത്യസ്ത പ്ലാറ്റ്‌ഫോമുകളിൽ എഴുതിയിരിക്കുന്നു:

ഓരോ മൈക്രോസർവീസിനും സ്വയംഭരണാധികാരം ഉണ്ടായിരിക്കേണ്ടതിനാൽ, അവയിൽ പലർക്കും അവരുടേതായ ഡാറ്റാബേസും കാഷെയും ആവശ്യമാണ്. അന്തിമ വാസ്തുവിദ്യ ഇപ്രകാരമാണ്:

അതിന്റെ അനന്തരഫലങ്ങൾ എന്തൊക്കെയാണ്?

ഫൗളറിനും ഇത് ഉണ്ട് ഒരു ലേഖനമുണ്ട് - മൈക്രോസർവീസുകൾ ഉപയോഗിക്കുന്നതിനുള്ള "പേയ്മെന്റിനെ" കുറിച്ച്:

ഞങ്ങളുടെ പ്രതീക്ഷകൾ നിറവേറ്റപ്പെടുമോ എന്ന് നമുക്ക് നോക്കാം.

മൊഡ്യൂളുകളുടെ അതിരുകൾ മായ്‌ക്കുക...

പക്ഷേ എത്ര മൈക്രോസർവീസുകൾ നമുക്ക് ശരിയാക്കേണ്ടതുണ്ട്?മാറ്റം കൊണ്ടുവരാൻ? വിതരണം ചെയ്ത ട്രെയ്‌സർ ഇല്ലാതെ എല്ലാം എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് നമുക്ക് കണ്ടെത്താനാകുമോ (എല്ലാത്തിനുമുപരി, ഏത് അഭ്യർത്ഥനയും പകുതി മൈക്രോസർവീസുകൾ പ്രോസസ്സ് ചെയ്യുന്നു)?

ഒരു പാറ്റേൺ ഉണ്ട് "അഴുക്കിന്റെ വലിയ പിണ്ഡം“, ഇവിടെ അത് വിതരണം ചെയ്ത അഴുക്കിന്റെ പിണ്ഡമായി മാറി. ഇത് സ്ഥിരീകരിക്കുന്നതിന്, അഭ്യർത്ഥനകൾ എങ്ങനെ പോകുന്നു എന്നതിന്റെ ഏകദേശ ചിത്രീകരണം ഇതാ:

വിന്യാസ സ്വാതന്ത്ര്യം...

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

സാങ്കേതികവിദ്യ തിരഞ്ഞെടുക്കാനുള്ള സ്വാതന്ത്ര്യം...

അവൾ ആകുന്നു. സ്വാതന്ത്ര്യം പലപ്പോഴും നിയമലംഘനത്തിന്റെ അതിർവരമ്പുകളാണെന്ന് ഓർക്കുക. അവരുമായി "കളിക്കാൻ" സാങ്കേതികവിദ്യകൾ തിരഞ്ഞെടുക്കാതിരിക്കുക എന്നത് ഇവിടെ വളരെ പ്രധാനമാണ്.

വികസനത്തിന്റെ സ്വാതന്ത്ര്യം...

മുഴുവൻ ആപ്ലിക്കേഷനും (ഇത്രയും ഘടകങ്ങളുള്ള) ഒരു ടെസ്റ്റ് ലൂപ്പ് എങ്ങനെ നിർമ്മിക്കാം? എന്നാൽ നിങ്ങൾ ഇപ്പോഴും അത് കാലികമായി സൂക്ഷിക്കേണ്ടതുണ്ട്. ഇതെല്ലാം വസ്തുതയിലേക്ക് നയിക്കുന്നു ടെസ്റ്റ് സർക്യൂട്ടുകളുടെ യഥാർത്ഥ എണ്ണം, നമുക്ക് തത്വത്തിൽ ഉൾക്കൊള്ളാൻ കഴിയും, കുറഞ്ഞതായി മാറുന്നു.

ഇതെല്ലാം പ്രാദേശികമായി വിന്യസിക്കുന്നതെങ്ങനെ?.. പലപ്പോഴും ഡവലപ്പർ തന്റെ ജോലി സ്വതന്ത്രമായി ചെയ്യുന്നതായി മാറുന്നു, പക്ഷേ "യാദൃശ്ചികമായി", കാരണം സർക്യൂട്ട് പരിശോധനയ്ക്കായി സ്വതന്ത്രമാകുന്നതുവരെ കാത്തിരിക്കാൻ അദ്ദേഹം നിർബന്ധിതനാകുന്നു.

പ്രത്യേക സ്കെയിലിംഗ്...

അതെ, എന്നാൽ ഉപയോഗിക്കുന്ന DBMS ന്റെ പ്രദേശത്ത് ഇത് പരിമിതമാണ്. നൽകിയിരിക്കുന്ന ആർക്കിടെക്ചർ ഉദാഹരണത്തിൽ, കസാന്ദ്രയ്ക്ക് പ്രശ്‌നങ്ങളുണ്ടാകില്ല, പക്ഷേ MySQL, PostgreSQL എന്നിവ ഉണ്ടാകും.

Боകൂടുതൽ വിശ്വാസ്യത...

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

ലോഡ് മെഷബിലിറ്റി...

ഇത് ശരിക്കും നല്ലതാണ്.

മൈക്രോ സർവീസുകളുടെ "ലഘുത"...

നമുക്ക് വലുത് മാത്രമല്ല നെറ്റ്വർക്ക് ഓവർഹെഡ് (DNS-നുള്ള അഭ്യർത്ഥനകൾ പെരുകുന്നു, മുതലായവ), മാത്രമല്ല ഞങ്ങൾ ആരംഭിച്ച നിരവധി ഉപചോദ്യങ്ങൾ കാരണവും ഡാറ്റ പകർത്തുക (സ്റ്റോർ കാഷെകൾ), ഇത് ഗണ്യമായ അളവിലുള്ള സംഭരണത്തിലേക്ക് നയിച്ചു.

ഞങ്ങളുടെ പ്രതീക്ഷകൾ നിറവേറ്റുന്നതിന്റെ ഫലം ഇതാ:

എന്നാൽ അത് മാത്രമല്ല!

കാരണം:

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

ഇതെല്ലാം എന്തുചെയ്യണം?

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

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

എന്നാൽ നമ്മൾ ഇതിനകം ഈ അവസ്ഥയിൽ ആണെങ്കിലോ?

ഏതൊരു പ്രശ്‌നവും പരിഹരിക്കാനുള്ള ആദ്യപടി, അതിനോട് യോജിക്കുകയും അതൊരു പ്രശ്‌നമാണെന്നും ഇനി കഷ്ടപ്പെടാൻ നാം ആഗ്രഹിക്കുന്നില്ലെന്നും മനസ്സിലാക്കുക എന്നതാണ്.

പടർന്നുകയറുന്ന മോണോലിത്തിന്റെ കാര്യത്തിൽ (അതിനായി അധിക വിഭവങ്ങൾ വാങ്ങാനുള്ള അവസരം ഞങ്ങൾ ഇല്ലാതാകുമ്പോൾ), ഞങ്ങൾ അത് വെട്ടിക്കളയുകയാണെങ്കിൽ, ഈ സാഹചര്യത്തിൽ വിപരീത കഥ മാറുന്നു: അമിതമായ മൈക്രോസർവീസുകൾ ഇനി സഹായിക്കില്ല, പക്ഷേ തടസ്സപ്പെടുത്തുമ്പോൾ - അധികമായി വെട്ടി വലുതാക്കുക!

ഉദാഹരണത്തിന്, മുകളിൽ ചർച്ച ചെയ്ത കൂട്ടായ ചിത്രത്തിന്...

ഏറ്റവും സംശയാസ്പദമായ മൈക്രോസർവീസുകൾ ഒഴിവാക്കുക:

ഫ്രണ്ട് എൻഡ് ജനറേഷന് ഉത്തരവാദിത്തമുള്ള എല്ലാ മൈക്രോ സർവീസുകളും സംയോജിപ്പിക്കുക:

... ഒരു മൈക്രോസർവീസിലേക്ക്, ഒന്നിൽ എഴുതിയിരിക്കുന്നു (ആധുനികവും സാധാരണവും, നിങ്ങൾ സ്വയം കരുതുന്നതുപോലെ) ഭാഷ/ചട്ടക്കൂട്:

ഇതിന് ഒരു ORM (ഒരു DBMS) ഉം ആദ്യം രണ്ട് ആപ്ലിക്കേഷനുകളും ഉണ്ടായിരിക്കും:

... എന്നാൽ പൊതുവെ നിങ്ങൾക്ക് കൂടുതൽ കാര്യങ്ങൾ അവിടെ കൈമാറാൻ കഴിയും, ഇനിപ്പറയുന്ന ഫലം ലഭിക്കും:

മാത്രമല്ല, കുബർനെറ്റസിൽ ഞങ്ങൾ ഇതെല്ലാം പ്രത്യേക സന്ദർഭങ്ങളിൽ പ്രവർത്തിപ്പിക്കുന്നു, അതിനർത്ഥം ഞങ്ങൾക്ക് ഇപ്പോഴും ലോഡ് അളക്കാനും അവയെ വെവ്വേറെ സ്കെയിൽ ചെയ്യാനും കഴിയും.

ചുരുക്കി പറഞ്ഞാൽ

വലിയ ചിത്രം നോക്കൂ. മിക്കപ്പോഴും, മൈക്രോസർവീസുകളിലെ ഈ പ്രശ്നങ്ങളെല്ലാം ഉണ്ടാകുന്നത് ആരെങ്കിലും അവരുടെ ചുമതല ഏറ്റെടുത്തതുകൊണ്ടാണ്, പക്ഷേ “മൈക്രോ സർവീസസ് ഉപയോഗിച്ച് കളിക്കാൻ” ആഗ്രഹിച്ചു.

"മൈക്രോ സർവീസസ്" എന്ന വാക്കിൽ "മൈക്രോ" ഭാഗം അനാവശ്യമാണ്.. ഒരു വലിയ മോണോലിത്തിനെക്കാൾ ചെറുതായതിനാൽ അവ "മൈക്രോ" ആണ്. എന്നാൽ അവയെ ചെറിയ ഒന്നായി കരുതരുത്.

അവസാന ചിന്തയ്ക്കായി, നമുക്ക് യഥാർത്ഥ ചാർട്ടിലേക്ക് മടങ്ങാം:

അതിൽ എഴുതിയ ഒരു കുറിപ്പ് (മുകളിൽ വലത്) എന്ന വസ്തുതയിലേക്ക് തിളച്ചുമറിയുന്നു നിങ്ങളുടെ പ്രോജക്റ്റ് നിർമ്മിക്കുന്ന ടീമിന്റെ കഴിവുകൾ എല്ലായ്പ്പോഴും പ്രാഥമികമാണ് — മൈക്രോ സർവീസുകൾക്കും മോണോലിത്തിനും ഇടയിലുള്ള നിങ്ങളുടെ തിരഞ്ഞെടുപ്പിൽ അവ ഒരു പ്രധാന പങ്ക് വഹിക്കും. ടീമിന് മതിയായ വൈദഗ്ധ്യം ഇല്ലെങ്കിലും അത് മൈക്രോസർവീസുകൾ നിർമ്മിക്കാൻ തുടങ്ങിയാൽ, കഥ തീർച്ചയായും മാരകമായിരിക്കും.

വീഡിയോകളും സ്ലൈഡുകളും

പ്രസംഗത്തിൽ നിന്നുള്ള വീഡിയോ (~50 മിനിറ്റ്; നിർഭാഗ്യവശാൽ, ഇത് സന്ദർശകരുടെ നിരവധി വികാരങ്ങൾ അറിയിക്കുന്നില്ല, ഇത് റിപ്പോർട്ടിന്റെ മാനസികാവസ്ഥയെ പ്രധാനമായും നിർണ്ണയിച്ചു, പക്ഷേ അങ്ങനെയാണ്):

റിപ്പോർട്ടിന്റെ അവതരണം:

പി.എസ്

ഞങ്ങളുടെ ബ്ലോഗിലെ മറ്റ് റിപ്പോർട്ടുകൾ:

• «നിരീക്ഷണവും കുബർനെറ്റസും» (Dmitry Stolyarov; മെയ് 28, 2018 RootConf-ൽ);
• «കുബർനെറ്റസ്, GitLab എന്നിവയ്‌ക്കൊപ്പമുള്ള CI/CD മികച്ച രീതികൾ» (Dmitry Stolyarov; നവംബർ 7, 2017 ഹൈലോഡ്++ ൽ);
• «ചെറിയ പ്രോജക്ടുകളിൽ കുബർനെറ്റുകളുമായുള്ള ഞങ്ങളുടെ അനുഭവം» (Dmitry Stolyarov; ജൂൺ 6, 2017 RootConf-ൽ);
• «ഒരു ഡാപ്പ് ഉപയോഗിച്ച് വേഗത്തിലും സൗകര്യപ്രദമായും ഞങ്ങൾ CI/CD-യ്‌ക്കായി ഡോക്കർ ഇമേജുകൾ നിർമ്മിക്കുന്നു» (Dmitry Stolyarov; നവംബർ 8, 2016 ഹൈലോഡ്++ ൽ);
• «ഡോക്കർ ഉപയോഗിച്ചുള്ള തുടർച്ചയായ ഡെലിവറി പരിശീലനങ്ങൾ» (Dmitry Stolyarov; മെയ് 31, 2016 RootConf-ൽ).

ഇനിപ്പറയുന്ന പ്രസിദ്ധീകരണങ്ങളിലും നിങ്ങൾക്ക് താൽപ്പര്യമുണ്ടാകാം:

• «2018-ൽ മൈക്രോസർവീസ് ഭ്രാന്തിന്റെ മരണം";
• «Google-ന്റെ 7 കണ്ടെയ്‌നർ മികച്ച സമ്പ്രദായങ്ങൾ";
• «കുബർനെറ്റസ് നടപ്പിലാക്കുന്നതിലെ വെല്ലുവിളികളെക്കുറിച്ചുള്ള പുതിയ സ്റ്റാക്കിൽ നിന്നുള്ള സ്ഥിതിവിവരക്കണക്കുകൾ".

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