ഹലോ! എന്റെ പേര് വാഡിം മാഡിസൺ, ഞാൻ Avito സിസ്റ്റം പ്ലാറ്റ്‌ഫോമിന്റെ വികസനത്തിന് നേതൃത്വം നൽകുന്നു. കമ്പനിയിൽ ഞങ്ങൾ എങ്ങനെയാണ് ഒരു മോണോലിത്തിക്ക് ആർക്കിടെക്ചറിൽ നിന്ന് മൈക്രോ സർവീസസ് ഒന്നിലേക്ക് മാറുന്നതെന്ന് ഒന്നിലധികം തവണ പറഞ്ഞിട്ടുണ്ട്. മൈക്രോസർവീസുകൾ പരമാവധി പ്രയോജനപ്പെടുത്തുന്നതിനും അവയിൽ നഷ്‌ടപ്പെടുന്നതിൽ നിന്ന് സ്വയം തടയുന്നതിനുമായി ഞങ്ങൾ ഞങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചറിനെ എങ്ങനെ മാറ്റിമറിച്ചുവെന്ന് പങ്കിടാനുള്ള സമയമാണിത്. PaaS ഞങ്ങളെ ഇവിടെ എങ്ങനെ സഹായിക്കുന്നു, ഞങ്ങൾ വിന്യാസം ലളിതമാക്കിയതും ഒരു മൈക്രോസർവീസിന്റെ സൃഷ്‌ടി ഒറ്റ ക്ലിക്കിലേക്ക് ചുരുക്കുന്നതും എങ്ങനെ - വായിക്കുക. ഞാൻ ചുവടെ എഴുതുന്നതെല്ലാം Avito-യിൽ പൂർണ്ണമായി നടപ്പിലാക്കിയിട്ടില്ല, അതിൽ ചിലത് ഞങ്ങളുടെ പ്ലാറ്റ്ഫോം എങ്ങനെ വികസിപ്പിക്കുന്നു എന്നതാണ്.

(ഈ ലേഖനത്തിന്റെ അവസാനം, മൈക്രോസർവീസ് ആർക്കിടെക്ചർ വിദഗ്ധൻ ക്രിസ് റിച്ചാർഡ്‌സണിൽ നിന്ന് മൂന്ന് ദിവസത്തെ സെമിനാറിൽ പങ്കെടുക്കാനുള്ള അവസരത്തെക്കുറിച്ച് ഞാൻ സംസാരിക്കും).

ഞങ്ങൾ എങ്ങനെയാണ് മൈക്രോസർവീസിലേക്ക് വന്നത്

ലോകത്തിലെ ഏറ്റവും വലിയ ക്ലാസിഫൈഡ് സൈറ്റുകളിൽ ഒന്നാണ് Avito; പ്രതിദിനം 15 ദശലക്ഷത്തിലധികം പുതിയ പരസ്യങ്ങൾ അതിൽ പ്രസിദ്ധീകരിക്കുന്നു. ഞങ്ങളുടെ ബാക്കെൻഡ് സെക്കൻഡിൽ 20 ആയിരത്തിലധികം അഭ്യർത്ഥനകൾ സ്വീകരിക്കുന്നു. ഞങ്ങൾക്ക് നിലവിൽ നൂറുകണക്കിന് മൈക്രോ സർവീസുകളുണ്ട്.

കുറച്ച് വർഷങ്ങളായി ഞങ്ങൾ ഒരു മൈക്രോ സർവീസ് ആർക്കിടെക്ചർ നിർമ്മിക്കുന്നു. എങ്ങനെ കൃത്യമായി - ഞങ്ങളുടെ സഹപ്രവർത്തകർ വിശദമായി പറഞ്ഞു RIT++ 2017-ലെ ഞങ്ങളുടെ വിഭാഗത്തിൽ. CodeFest 2017-ൽ (കാണുക. видео), സെർജി ഓർലോവ്, മിഖായേൽ പ്രോകോപ്‌ചുക്ക് എന്നിവർ മൈക്രോസർവീസുകളിലേക്കുള്ള മാറ്റം എന്തുകൊണ്ടാണ് ആവശ്യമായിരുന്നതെന്നും കുബർനെറ്റസ് ഇവിടെ എന്ത് പങ്കാണ് വഹിച്ചതെന്നും വിശദമായി വിശദീകരിച്ചു. ശരി, അത്തരമൊരു വാസ്തുവിദ്യയിൽ അന്തർലീനമായ സ്കെയിലിംഗ് ചെലവുകൾ കുറയ്ക്കുന്നതിന് ഞങ്ങൾ ഇപ്പോൾ എല്ലാം ചെയ്യുന്നു.

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

ഇപ്പോൾ PaaS CLI യൂട്ടിലിറ്റിയിൽ, ഒരു കമാൻഡ് ഉപയോഗിച്ച് ഒരു പുതിയ സേവനം സൃഷ്ടിക്കപ്പെടുന്നു, കൂടാതെ ഒരു പുതിയ ഡാറ്റാബേസ് രണ്ടെണ്ണം കൂടി ചേർത്ത് സ്റ്റേജിലേക്ക് വിന്യസിക്കുന്നു.

"മൈക്രോ സർവീസ് ഫ്രാഗ്മെന്റേഷൻ" യുഗത്തെ എങ്ങനെ മറികടക്കാം

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

കൂടാതെ, ഒരു മൈക്രോസർവീസ് ആർക്കിടെക്ചർ ഫലപ്രദമാകുന്നതിന്, നിരവധി പ്രക്രിയകൾ സ്ഥാപിക്കേണ്ടതുണ്ട്, അതായത്:

• ലോഗിംഗ്;
• അഭ്യർത്ഥന കണ്ടെത്തൽ (ജെയ്ഗർ);
• പിശക് കൂട്ടിച്ചേർക്കൽ (സെൻട്രി);
• കുബർനെറ്റസിൽ നിന്നുള്ള സ്റ്റാറ്റസുകൾ, സന്ദേശങ്ങൾ, ഇവന്റുകൾ (ഇവന്റ് സ്ട്രീം പ്രോസസ്സിംഗ്);
• റേസ് പരിധി / സർക്യൂട്ട് ബ്രേക്കർ (നിങ്ങൾക്ക് ഹൈസ്ട്രിക്സ് ഉപയോഗിക്കാം);
• സേവന കണക്റ്റിവിറ്റിയുടെ നിയന്ത്രണം (ഞങ്ങൾ Netramesh ഉപയോഗിക്കുന്നു);
• നിരീക്ഷണം (ഗ്രാഫാന);
• അസംബ്ലി (ടീംസിറ്റി);
• ആശയവിനിമയവും അറിയിപ്പും (സ്ലാക്ക്, ഇമെയിൽ);
• ടാസ്ക് ട്രാക്കിംഗ്; (ജിറ)
• ഡോക്യുമെന്റേഷൻ തയ്യാറാക്കൽ.

സിസ്റ്റത്തിന്റെ സമഗ്രത നഷ്‌ടപ്പെടുന്നില്ലെന്നും അത് സ്കെയിൽ ചെയ്യുമ്പോൾ ഫലപ്രദമാണെന്നും ഉറപ്പാക്കാൻ, Avito-യിലെ മൈക്രോസർവീസുകളുടെ ഓർഗനൈസേഷൻ ഞങ്ങൾ പുനർവിചിന്തനം ചെയ്തു.

ഞങ്ങൾ മൈക്രോ സർവീസുകൾ എങ്ങനെ കൈകാര്യം ചെയ്യുന്നു

നിരവധി Avito മൈക്രോ സർവീസുകൾക്കിടയിൽ ഒരു ഏകീകൃത "പാർട്ടി നയം" നടപ്പിലാക്കാൻ ഇനിപ്പറയുന്ന സഹായം:

• അടിസ്ഥാന സൗകര്യങ്ങളെ പാളികളായി വിഭജിക്കുന്നു;
• ഒരു സേവനമായി പ്ലാറ്റ്ഫോം (PaaS) ആശയം;
• മൈക്രോസർവീസുകളിൽ സംഭവിക്കുന്നതെല്ലാം നിരീക്ഷിക്കുന്നു.

ഇൻഫ്രാസ്ട്രക്ചർ അബ്‌സ്‌ട്രാക്ഷൻ ലെയറുകളിൽ മൂന്ന് പാളികൾ ഉൾപ്പെടുന്നു. നമുക്ക് മുകളിൽ നിന്ന് താഴേക്ക് പോകാം.

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

എല്ലാ ലെയറുകളും PaaS ഉപയോഗിച്ച് സംയോജിപ്പിച്ചിരിക്കുന്നു. ഈ പ്ലാറ്റ്ഫോം, അതാകട്ടെ, മൂന്ന് ഭാഗങ്ങൾ ഉൾക്കൊള്ളുന്നു.

I. ജനറേറ്ററുകൾ, ഒരു CLI യൂട്ടിലിറ്റി വഴി നിയന്ത്രിക്കപ്പെടുന്നു. ശരിയായ രീതിയിലും കുറഞ്ഞ പരിശ്രമത്തിലും ഒരു മൈക്രോസർവീസ് സൃഷ്ടിക്കാൻ ഡവലപ്പറെ സഹായിക്കുന്നത് അവളാണ്.

II. ഏകീകൃത കളക്ടർ ഒരു പൊതു ഡാഷ്‌ബോർഡിലൂടെ എല്ലാ ഉപകരണങ്ങളുടെയും നിയന്ത്രണം.

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

Avito-യിലെ മൈക്രോസർവീസുകൾ നടപ്പിലാക്കുന്നത് ഒരൊറ്റ സ്കീം അനുസരിച്ചാണ് നടത്തുന്നത്, ഇത് വികസനത്തിന്റെയും റിലീസിന്റെയും ഓരോ ഘട്ടത്തിലും അവയുടെ നിയന്ത്രണം ലളിതമാക്കുന്നു.

ഒരു സാധാരണ മൈക്രോസർവീസ് വികസന പൈപ്പ്ലൈൻ എങ്ങനെയാണ് പ്രവർത്തിക്കുന്നത്?

പൊതുവേ, മൈക്രോസർവീസ് സൃഷ്ടിക്കൽ ശൃംഖല ഇതുപോലെ കാണപ്പെടുന്നു:

CLI-പുഷ് → തുടർച്ചയായ സംയോജനം → ബേക്ക് → വിന്യസിക്കുക → കൃത്രിമ പരിശോധനകൾ → കാനറി ടെസ്റ്റുകൾ → സ്ക്വീസ് ടെസ്റ്റിംഗ് → ഉത്പാദനം → പരിപാലനം.

ഈ ക്രമത്തിൽ കൃത്യമായി അതിലൂടെ പോകാം.

CLI-പുഷ്

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

അവസാനം, ഒരു മൈക്രോസർവീസ് സൃഷ്ടിക്കുമ്പോൾ അടിസ്ഥാന ഘട്ടങ്ങൾ ഓട്ടോമേറ്റ് ചെയ്യുന്ന ഒരു ലളിതമായ CLI യൂട്ടിലിറ്റി ഞങ്ങൾ നിർമ്മിച്ചു. വാസ്തവത്തിൽ, ഇത് ആദ്യത്തെ ജിറ്റ് പുഷ് മാറ്റിസ്ഥാപിക്കുന്നു. അവൾ കൃത്യമായി എന്താണ് ചെയ്യുന്നതെന്ന് ഇതാ.

- ഒരു ടെംപ്ലേറ്റ് അനുസരിച്ച് ഒരു സേവനം സൃഷ്ടിക്കുന്നു - ഘട്ടം ഘട്ടമായി, "വിസാർഡ്" മോഡിൽ. Avito ബാക്കെൻഡിലെ പ്രധാന പ്രോഗ്രാമിംഗ് ഭാഷകൾക്കായി ഞങ്ങൾക്ക് ടെംപ്ലേറ്റുകൾ ഉണ്ട്: PHP, Golang, Python.

- ഒരു സമയം ഒരു കമാൻഡ് ഒരു നിർദ്ദിഷ്‌ട മെഷീനിൽ പ്രാദേശിക വികസനത്തിനായി ഒരു അന്തരീക്ഷം വിന്യസിക്കുന്നു - മിനിക്യൂബ് സമാരംഭിച്ചു, ഹെൽം ചാർട്ടുകൾ സ്വയമേവ സൃഷ്‌ടിക്കുകയും പ്രാദേശിക കുബർനെറ്റുകളിൽ സമാരംഭിക്കുകയും ചെയ്യുന്നു.

- ആവശ്യമായ ഡാറ്റാബേസ് ബന്ധിപ്പിക്കുന്നു. ഡെവലപ്പർക്ക് ആവശ്യമായ ഡാറ്റാബേസിലേക്ക് ആക്‌സസ് നേടുന്നതിന് ഐപി, ലോഗിൻ, പാസ്‌വേഡ് എന്നിവ അറിയേണ്ടതില്ല - അത് പ്രാദേശികമായോ ഘട്ടത്തിലോ നിർമ്മാണത്തിലോ ആകട്ടെ. മാത്രമല്ല, ഡാറ്റാബേസ് തകരാർ-സഹിഷ്ണുതയുള്ള കോൺഫിഗറേഷനിലും ബാലൻസിംഗിലും ഉടനടി വിന്യസിക്കുന്നു.

- ഇത് തത്സമയ അസംബ്ലി തന്നെ നടത്തുന്നു. ഒരു ഡെവലപ്പർ തന്റെ IDE വഴി മൈക്രോസർവീസിൽ എന്തെങ്കിലും തിരുത്തിയെന്ന് നമുക്ക് പറയാം. ഫയൽ സിസ്റ്റത്തിലെ മാറ്റങ്ങൾ യൂട്ടിലിറ്റി കാണുകയും അവയുടെ അടിസ്ഥാനത്തിൽ ആപ്ലിക്കേഷൻ പുനർനിർമ്മിക്കുകയും (ഗോലാങ്ങിനായി) പുനരാരംഭിക്കുകയും ചെയ്യുന്നു. PHP-യ്‌ക്കായി, ഞങ്ങൾ ക്യൂബിനുള്ളിലെ ഡയറക്‌ടറി ഫോർവേഡ് ചെയ്യുന്നു, അവിടെ തത്സമയ-റീലോഡ് "യാന്ത്രികമായി" ലഭിക്കും.

- ഓട്ടോടെസ്റ്റുകൾ സൃഷ്ടിക്കുന്നു. ശൂന്യമായ രൂപത്തിൽ, പക്ഷേ ഉപയോഗത്തിന് തികച്ചും അനുയോജ്യമാണ്.

• മൈക്രോ സർവീസ് വിന്യാസം.

ഒരു മൈക്രോസർവീസ് വിന്യസിക്കുന്നത് ഞങ്ങൾക്ക് ഒരു ജോലിയായിരുന്നു. ഇനിപ്പറയുന്നവ ആവശ്യമായിരുന്നു:

I. ഡോക്കർഫിൽ.

II. കോൺഫിഗറേഷൻ.
III. ഹെൽം ചാർട്ട്, അത് തന്നെ ബുദ്ധിമുട്ടുള്ളതും ഉൾപ്പെടുന്നു:

- ചാർട്ടുകൾ തന്നെ;
- ടെംപ്ലേറ്റുകൾ;
- വ്യത്യസ്ത പരിതസ്ഥിതികൾ കണക്കിലെടുത്ത് നിർദ്ദിഷ്ട മൂല്യങ്ങൾ.

കുബർനെറ്റസ് മാനിഫെസ്റ്റുകൾ പുനർനിർമ്മിക്കുന്നതിൽ നിന്ന് ഞങ്ങൾ വേദന ഒഴിവാക്കി, അതിനാൽ അവ ഇപ്പോൾ സ്വയമേവ ജനറേറ്റ് ചെയ്യപ്പെടുന്നു. എന്നാൽ ഏറ്റവും പ്രധാനമായി, അവർ വിന്യാസം പരിധിയിലേക്ക് ലളിതമാക്കി. ഇപ്പോൾ മുതൽ ഞങ്ങൾക്ക് ഒരു Dockerfile ഉണ്ട്, ഡെവലപ്പർ ഒരു ചെറിയ app.toml ഫയലിൽ മുഴുവൻ കോൺഫിഗും എഴുതുന്നു.

അതെ, app.toml-ൽ തന്നെ ഒരു മിനിറ്റ് നേരത്തേക്ക് ഒന്നും ചെയ്യാനില്ല. സേവനത്തിന്റെ എവിടെ, എത്ര പകർപ്പുകൾ (dev സെർവറിൽ, സ്റ്റേജിംഗിൽ, ഉൽപ്പാദനത്തിൽ) ഉയർത്തണമെന്ന് ഞങ്ങൾ വ്യക്തമാക്കുകയും അതിന്റെ ആശ്രിതത്വം സൂചിപ്പിക്കുകയും ചെയ്യുന്നു. [എഞ്ചിൻ] ബ്ലോക്കിലെ ലൈൻ വലുപ്പം = "ചെറുത്" ശ്രദ്ധിക്കുക. കുബർനെറ്റസ് വഴിയുള്ള സേവനത്തിന് അനുവദിക്കുന്ന പരിധി ഇതാണ്.

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

• അടിസ്ഥാന മൂല്യനിർണ്ണയം. അത്തരം പരിശോധനകളും ഓട്ടോമേറ്റഡ് ആണ്.
ട്രാക്ക് ചെയ്യേണ്ടത്:
- ഒരു ഡോക്കർഫയൽ ഉണ്ടോ;
— app.toml ഉണ്ടോ;
- ഡോക്യുമെന്റേഷൻ ലഭ്യമാണോ?
- ആശ്രിതത്വം ക്രമത്തിലാണോ?
- അലേർട്ട് നിയമങ്ങൾ സജ്ജീകരിച്ചിട്ടുണ്ടോ എന്ന്.
അവസാന പോയിന്റിലേക്ക്: ഏത് ഉൽപ്പന്ന അളവുകൾ നിരീക്ഷിക്കണമെന്ന് സേവനത്തിന്റെ ഉടമ തന്നെ നിർണ്ണയിക്കുന്നു.

• ഡോക്യുമെന്റേഷൻ തയ്യാറാക്കൽ.
ഇപ്പോഴും പ്രശ്നമുള്ള മേഖല. ഇത് ഏറ്റവും വ്യക്തമാണെന്ന് തോന്നുന്നു, എന്നാൽ അതേ സമയം ഇത് "പലപ്പോഴും മറന്നുപോയ" ഒരു റെക്കോർഡ് കൂടിയാണ്, അതിനാൽ ശൃംഖലയിലെ ഒരു ദുർബലമായ ലിങ്ക്.
ഓരോ മൈക്രോസർവീസിനും ഡോക്യുമെന്റേഷൻ ഉണ്ടായിരിക്കേണ്ടത് ആവശ്യമാണ്. അതിൽ ഇനിപ്പറയുന്ന ബ്ലോക്കുകൾ ഉൾപ്പെടുന്നു.

I. സേവനത്തിന്റെ ഹ്രസ്വ വിവരണം. അക്ഷരാർത്ഥത്തിൽ അത് എന്തുചെയ്യുന്നു, എന്തുകൊണ്ട് അത് ആവശ്യമാണ് എന്നതിനെക്കുറിച്ചുള്ള കുറച്ച് വാക്യങ്ങൾ.

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

III. റൺബുക്ക്. സേവനം ആരംഭിക്കുന്നതിനെക്കുറിച്ചും അത് കൈകാര്യം ചെയ്യുന്നതിലെ സങ്കീർണതകളെക്കുറിച്ചും ഒരു ചെറിയ ഗൈഡ്.

IV. പതിവുചോദ്യങ്ങൾ, സേവനവുമായി പ്രവർത്തിക്കുമ്പോൾ നിങ്ങളുടെ സഹപ്രവർത്തകർ നേരിട്ടേക്കാവുന്ന പ്രശ്നങ്ങൾ മുൻകൂട്ടി കാണുന്നത് നല്ലതായിരിക്കും.

V. API-യുടെ അവസാന പോയിന്റുകളുടെ വിവരണം. പെട്ടെന്ന് നിങ്ങൾ ലക്ഷ്യസ്ഥാനങ്ങൾ വ്യക്തമാക്കിയിട്ടില്ലെങ്കിൽ, നിങ്ങളുടേതുമായി ബന്ധപ്പെട്ട മൈക്രോസർവീസുകളുള്ള സഹപ്രവർത്തകർ തീർച്ചയായും അതിന് പണം നൽകും. ഇപ്പോൾ ഞങ്ങൾ Swagger ഉപയോഗിക്കുന്നു, ഇതിനായി ചുരുക്കം എന്ന് വിളിക്കപ്പെടുന്ന ഞങ്ങളുടെ പരിഹാരം.

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

VII. സേവനത്തിന്റെ ഉടമ അല്ലെങ്കിൽ ഉടമ. മിക്ക കേസുകളിലും, അത് — അല്ലെങ്കിൽ അവ — PaaS ഉപയോഗിച്ച് സ്വയമേവ നിർണ്ണയിക്കാൻ കഴിയും, എന്നാൽ സുരക്ഷിതമായ വശത്തായിരിക്കാൻ, ഡെവലപ്പർ അവ സ്വമേധയാ വ്യക്തമാക്കേണ്ടതുണ്ട്.

അവസാനമായി, കോഡ് അവലോകനത്തിന് സമാനമായ ഡോക്യുമെന്റേഷൻ അവലോകനം ചെയ്യുന്നത് ഒരു നല്ല സമ്പ്രദായമാണ്.

തുടർച്ചയായ ഏകീകരണം

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

ചുടേണം

വിന്യാസത്തിന് മുമ്പുള്ള പാക്കേജിംഗ് സേവനങ്ങളാണ് അടുത്ത ഘട്ടം.

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

എക്സിക്യൂഷൻ സമയം, കുറവ് നല്ലത്. പരമാവധി: 643ms, കുറഞ്ഞത്: 42ms. ഫോട്ടോ ക്ലിക്ക് ചെയ്യാവുന്നതാണ്.

ശസ്ത്രക്രിയയ്ക്കുള്ള സമയം, കുറവ് നല്ലതാണ്. പരമാവധി: 14091 ns, കുറഞ്ഞത്: 151 ns. ഫോട്ടോ ക്ലിക്ക് ചെയ്യാവുന്നതാണ്.

അസംബ്ലി തയ്യാറാക്കൽ ഘട്ടത്തിൽ, നിങ്ങൾക്ക് ഈ വേരിയബിൾ വ്യക്തമായി സജ്ജീകരിക്കാം അല്ലെങ്കിൽ നിങ്ങൾക്ക് ലൈബ്രറി ഉപയോഗിക്കാം automaxprocs Uber-ൽ നിന്നുള്ള ആൺകുട്ടികളിൽ നിന്ന്.

വിന്യസിക്കുക

• കൺവെൻഷനുകൾ പരിശോധിക്കുന്നു. നിങ്ങൾ ഉദ്ദേശിച്ച പരിതസ്ഥിതികളിലേക്ക് സേവന അസംബ്ലികൾ വിതരണം ചെയ്യാൻ തുടങ്ങുന്നതിനുമുമ്പ്, നിങ്ങൾ ഇനിപ്പറയുന്നവ പരിശോധിക്കേണ്ടതുണ്ട്:
- API അവസാന പോയിന്റുകൾ.
- സ്കീമയുമായുള്ള API എൻഡ്‌പോയിന്റ് പ്രതികരണങ്ങൾ പാലിക്കൽ.
- ലോഗ് ഫോർമാറ്റ്.
- സേവനത്തിലേക്കുള്ള അഭ്യർത്ഥനകൾക്കായി തലക്കെട്ടുകൾ സജ്ജീകരിക്കുന്നു (നിലവിൽ ഇത് ചെയ്യുന്നത് netramesh ആണ്)
- ഇവന്റ് ബസിലേക്ക് സന്ദേശങ്ങൾ അയയ്‌ക്കുമ്പോൾ ഉടമയുടെ ടോക്കൺ സജ്ജീകരിക്കുന്നു. ബസിലുടനീളമുള്ള സേവനങ്ങളുടെ കണക്റ്റിവിറ്റി ട്രാക്ക് ചെയ്യുന്നതിന് ഇത് ആവശ്യമാണ്. സേവനങ്ങളുടെ കണക്റ്റിവിറ്റി വർദ്ധിപ്പിക്കാത്ത (ഇത് നല്ലതാണ്), സേവനങ്ങളുടെ കണക്റ്റിവിറ്റിയെ ശക്തിപ്പെടുത്തുന്ന ബിസിനസ്സ് ഡാറ്റ (ഇത് വളരെ മോശമാണ്!) എന്നിവയ്‌ക്ക് ബസിന് ഐഡമ്പറ്റന്റ് ഡാറ്റ അയയ്‌ക്കാൻ കഴിയും. ഈ കണക്റ്റിവിറ്റി ഒരു പ്രശ്‌നമായി മാറുന്ന ഘട്ടത്തിൽ, ആരാണ് ബസ് എഴുതുകയും വായിക്കുകയും ചെയ്യുന്നതെന്ന് മനസ്സിലാക്കുന്നത് സേവനങ്ങൾ ശരിയായി വേർതിരിക്കാൻ സഹായിക്കുന്നു.

Avito-യിൽ ഇതുവരെ ധാരാളം കൺവെൻഷനുകൾ ഇല്ല, പക്ഷേ അവരുടെ പൂൾ വികസിച്ചുകൊണ്ടിരിക്കുന്നു. ടീമിന് മനസ്സിലാക്കാനും മനസ്സിലാക്കാനും കഴിയുന്ന ഒരു രൂപത്തിൽ അത്തരം കൂടുതൽ കരാറുകൾ ലഭ്യമാണ്, മൈക്രോസർവീസുകൾക്കിടയിൽ സ്ഥിരത നിലനിർത്തുന്നത് എളുപ്പമാണ്.

സിന്തറ്റിക് ടെസ്റ്റുകൾ

• ക്ലോസ്ഡ് ലൂപ്പ് ടെസ്റ്റിംഗ്. ഇതിനായി ഞങ്ങൾ ഇപ്പോൾ ഓപ്പൺ സോഴ്‌സ് ഉപയോഗിക്കുന്നു Hoverfly.io. ആദ്യം, ഇത് സേവനത്തിലെ യഥാർത്ഥ ലോഡ് രേഖപ്പെടുത്തുന്നു, തുടർന്ന് - ഒരു അടച്ച ലൂപ്പിൽ - അത് അനുകരിക്കുന്നു.

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

ലോഡ് ടെസ്റ്റിംഗ് സമയത്ത്, റിസോഴ്സ് ഉപഭോഗം നിശ്ചിത പരിധികൾ പാലിക്കുന്നുണ്ടോ എന്ന് ഞങ്ങൾ പരിശോധിക്കുന്നു. ഞങ്ങൾ പ്രാഥമികമായി തീവ്രതകളിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നു.

a) ഞങ്ങൾ മൊത്തം ലോഡ് നോക്കുന്നു.
- വളരെ ചെറുത് - ലോഡ് പെട്ടെന്ന് നിരവധി തവണ കുറയുകയാണെങ്കിൽ മിക്കവാറും എന്തെങ്കിലും പ്രവർത്തിക്കില്ല.
- വളരെ വലുതാണ് - ഒപ്റ്റിമൈസേഷൻ ആവശ്യമാണ്.

b) RPS അനുസരിച്ച് ഞങ്ങൾ കട്ട്ഓഫ് നോക്കുന്നു.
നിലവിലെ പതിപ്പും മുമ്പത്തെ പതിപ്പും മൊത്തം അളവും തമ്മിലുള്ള വ്യത്യാസം ഇവിടെ നോക്കുന്നു. ഉദാഹരണത്തിന്, ഒരു സേവനം 100 ആർ‌പി‌എസ് ഉൽ‌പാദിപ്പിക്കുന്നുവെങ്കിൽ, അത് ഒന്നുകിൽ മോശമായി എഴുതിയിരിക്കുന്നു, അല്ലെങ്കിൽ ഇത് അതിന്റെ പ്രത്യേകതയാണ്, എന്നാൽ ഏത് സാഹചര്യത്തിലും, ഇത് സേവനത്തെ വളരെ അടുത്ത് കാണാനുള്ള ഒരു കാരണമാണ്.
നേരെമറിച്ച്, വളരെയധികം ആർ‌പി‌എസ് ഉണ്ടെങ്കിൽ, ഒരുപക്ഷേ എന്തെങ്കിലും തരത്തിലുള്ള ബഗ് ഉണ്ടാകാം കൂടാതെ ചില എൻഡ്‌പോയിന്റുകൾ പേലോഡ് എക്‌സിക്യൂഷൻ ചെയ്യുന്നത് നിർത്തിയിരിക്കാം, മറ്റൊന്ന് ലളിതമായി ട്രിഗർ ചെയ്യപ്പെടും return true;

കാനറി ടെസ്റ്റുകൾ

ഞങ്ങൾ സിന്തറ്റിക് ടെസ്റ്റുകൾ വിജയിച്ചതിന് ശേഷം, കുറച്ച് ഉപയോക്താക്കളിൽ ഞങ്ങൾ മൈക്രോസർവീസ് പരിശോധിക്കുന്നു. ഞങ്ങൾ ശ്രദ്ധാപൂർവം ആരംഭിക്കുന്നു, സേവനത്തിന്റെ ഉദ്ദേശിച്ച പ്രേക്ഷകരുടെ ഒരു ചെറിയ പങ്ക് - 0,1% ൽ താഴെ. ഈ ഘട്ടത്തിൽ, നിരീക്ഷണത്തിൽ ശരിയായ സാങ്കേതികവും ഉൽപ്പന്ന അളവുകളും ഉൾപ്പെടുത്തേണ്ടത് വളരെ പ്രധാനമാണ്, അതുവഴി അവർ സേവനത്തിലെ പ്രശ്നം എത്രയും വേഗം കാണിക്കും. കാനറി ടെസ്റ്റിനുള്ള ഏറ്റവും കുറഞ്ഞ സമയം 5 മിനിറ്റാണ്, പ്രധാനം 2 മണിക്കൂറാണ്. സങ്കീർണ്ണമായ സേവനങ്ങൾക്കായി, ഞങ്ങൾ സ്വമേധയാ സമയം സജ്ജമാക്കുന്നു.
നമുക്ക് വിശകലനം ചെയ്യാം:
- ഭാഷാ-നിർദ്ദിഷ്ട മെട്രിക്സ്, പ്രത്യേകിച്ച്, php-fpm തൊഴിലാളികൾ;
- സെൻട്രിയിലെ പിശകുകൾ;
- പ്രതികരണ നിലകൾ;
- പ്രതികരണ സമയം, കൃത്യവും ശരാശരിയും;
- ലേറ്റൻസി;
- ഒഴിവാക്കലുകൾ, പ്രോസസ്സ് ചെയ്തതും കൈകാര്യം ചെയ്യാത്തതും;
- ഉൽപ്പന്ന അളവുകൾ.

സ്ക്വീസ് ടെസ്റ്റിംഗ്

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

ഉത്പാദനം

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

തൽഫലമായി, സ്കെയിലിംഗ് ചെയ്യുമ്പോൾ ഞങ്ങൾ വിശകലനം ചെയ്യുന്നു:
- സിപിയു, റാം സൂചകങ്ങൾ,
- ക്യൂവിലെ അഭ്യർത്ഥനകളുടെ എണ്ണം,
- പ്രതികരണ സമയം,
- ശേഖരിച്ച ചരിത്രപരമായ ഡാറ്റയെ അടിസ്ഥാനമാക്കിയുള്ള പ്രവചനം.

ഒരു സേവനം സ്കെയിൽ ചെയ്യുമ്പോൾ, അതിന്റെ ഡിപൻഡൻസികൾ നിരീക്ഷിക്കേണ്ടതും പ്രധാനമാണ്, അതുവഴി ഞങ്ങൾ ചെയിനിലെ ആദ്യ സേവനം സ്കെയിൽ ചെയ്യാതിരിക്കുകയും അത് ആക്‌സസ് ചെയ്യുന്നവ ലോഡിൽ പരാജയപ്പെടുകയും ചെയ്യും. സേവനങ്ങളുടെ മുഴുവൻ ശേഖരത്തിനും സ്വീകാര്യമായ ഒരു ലോഡ് സ്ഥാപിക്കാൻ, ഞങ്ങൾ "അടുത്തുള്ള" ആശ്രിത സേവനത്തിന്റെ ചരിത്രപരമായ ഡാറ്റ നോക്കുന്നു (സിപിയു, റാം സൂചകങ്ങളുടെ സംയോജനത്തെ അടിസ്ഥാനമാക്കി, ആപ്പ്-നിർദ്ദിഷ്ട മെട്രിക്സുകൾക്കൊപ്പം) അവയെ ചരിത്രപരമായ ഡാറ്റയുമായി താരതമ്യം ചെയ്യുന്നു. ആരംഭിക്കുന്ന സേവനത്തിന്റെ, അങ്ങനെ "ആശ്രിത ശൃംഖല" ", മുകളിൽ നിന്ന് താഴേക്ക്.

സേവനം

മൈക്രോസർവീസ് പ്രവർത്തനക്ഷമമാക്കിയ ശേഷം, നമുക്ക് അതിൽ ട്രിഗറുകൾ അറ്റാച്ചുചെയ്യാം.

ട്രിഗറുകൾ സംഭവിക്കുന്ന സാധാരണ സാഹചര്യങ്ങൾ ഇതാ.
- അപകടകരമായ കുടിയേറ്റങ്ങൾ കണ്ടെത്തി.
- സുരക്ഷാ അപ്‌ഡേറ്റുകൾ പുറത്തിറങ്ങി.
- സേവനം തന്നെ വളരെക്കാലമായി അപ്ഡേറ്റ് ചെയ്തിട്ടില്ല.
- സേവനത്തിലെ ലോഡ് ഗണ്യമായി കുറഞ്ഞു അല്ലെങ്കിൽ അതിന്റെ ചില ഉൽപ്പന്ന അളവുകൾ സാധാരണ പരിധിക്ക് പുറത്താണ്.
— സേവനം ഇനി മുതൽ പുതിയ പ്ലാറ്റ്ഫോം ആവശ്യകതകൾ പാലിക്കുന്നില്ല.

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

ഡാഷ്ബോർഡ്

ചുരുക്കത്തിൽ, നമ്മുടെ മുഴുവൻ PaaS-ന്റെയും നിയന്ത്രണ പാനലാണ് ഡാഷ്‌ബോർഡ്.

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

ആകെ

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

HighLoad++ 2018-ന് ഈ വിഷയത്തിൽ ഞാൻ ഒരു റിപ്പോർട്ട് നൽകി, നിങ്ങൾക്കത് കാണാൻ കഴിയും видео и അവതരണം.

അവസാനം വരെ വായിക്കുന്നവർക്കുള്ള ബോണസ് ട്രാക്ക്

ഞങ്ങൾ Avito-ൽ നിന്നുള്ള ഡെവലപ്പർമാർക്കായി ഒരു ആന്തരിക ത്രിദിന പരിശീലനം സംഘടിപ്പിക്കുന്നു ക്രിസ് റിച്ചാർഡ്സൺ, മൈക്രോസർവീസ് ആർക്കിടെക്ചറിൽ വിദഗ്ധൻ. ഈ പോസ്റ്റിന്റെ വായനക്കാരിൽ ഒരാൾക്ക് അതിൽ പങ്കെടുക്കാനുള്ള അവസരം നൽകാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. ഇത് പരിശീലന പരിപാടി പോസ്റ്റ് ചെയ്തിട്ടുണ്ട്.

ഓഗസ്റ്റ് 5 മുതൽ 7 വരെ മോസ്കോയിലാണ് പരിശീലനം. ഇത് പൂർണ്ണമായും അധിനിവേശമുള്ള പ്രവൃത്തി ദിവസങ്ങളാണ്. ഉച്ചഭക്ഷണവും പരിശീലനവും ഞങ്ങളുടെ ഓഫീസിലായിരിക്കും, തിരഞ്ഞെടുത്ത പങ്കാളി യാത്രയ്ക്കും താമസത്തിനും പണം നൽകും.

പങ്കാളിത്തത്തിന് അപേക്ഷിക്കാം ഈ ഗൂഗിൾ ഫോമിൽ. നിങ്ങളിൽ നിന്ന് - എന്തുകൊണ്ടാണ് നിങ്ങൾ പരിശീലനത്തിൽ പങ്കെടുക്കേണ്ടത് എന്ന ചോദ്യത്തിനുള്ള ഉത്തരം, നിങ്ങളെ എങ്ങനെ ബന്ധപ്പെടണം എന്നതിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ. ഇംഗ്ലീഷിൽ ഉത്തരം നൽകുക, കാരണം പരിശീലനത്തിൽ പങ്കെടുക്കുന്ന പങ്കാളിയെ ക്രിസ് തിരഞ്ഞെടുക്കും.
ഈ പോസ്റ്റിലേക്കുള്ള ഒരു അപ്‌ഡേറ്റിലും ഡെവലപ്പർമാർക്കായുള്ള Avito എന്ന സോഷ്യൽ നെറ്റ്‌വർക്കുകളിലും പരിശീലന പങ്കാളിയുടെ പേര് ഞങ്ങൾ പ്രഖ്യാപിക്കും (AvitoTech in ഫേസ്ബുക്ക്, Vkontakte, ട്വിറ്റർ) ജൂലൈ 19 ന് ശേഷമല്ല.

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