സേവന മെഷ് ഉപയോഗ സാഹചര്യങ്ങൾ

കുറിപ്പ്. വിവർത്തനം.: ഈ ലേഖനത്തിന്റെ രചയിതാവ് (Luc Perkins) CNCF ഓർഗനൈസേഷനിലെ ഒരു ഡെവലപ്പർ അഭിഭാഷകനാണ്, ഇത് Linkerd, SMI (സർവീസ് മെഷ് ഇന്റർഫേസ്), കുമ (സർവീസ് മെഷ് ഇന്റർഫേസ്) തുടങ്ങിയ ഓപ്പൺ സോഴ്സ് പ്രോജക്റ്റുകളുടെ ആസ്ഥാനമാണ് (ഇസ്തിയോ എന്തുകൊണ്ടാണെന്ന് നിങ്ങൾ ചിന്തിച്ചിട്ടുണ്ടോ? ഈ ലിസ്റ്റിൽ ഇല്ലേ?.). "സർവീസ് മെഷ്" എന്ന് വിളിക്കപ്പെടുന്ന ട്രെൻഡി ഹൈപ്പിനെക്കുറിച്ച് DevOps കമ്മ്യൂണിറ്റിയെ നന്നായി മനസ്സിലാക്കാൻ ഒരിക്കൽ കൂടി ശ്രമിക്കുന്നു, അത്തരം പരിഹാരങ്ങൾ നൽകുന്ന 16 സ്വഭാവ സവിശേഷതകളെ അദ്ദേഹം പട്ടികപ്പെടുത്തുന്നു.

ഇന്ന് സേവന മെഷ് ― സോഫ്റ്റ്‌വെയർ എഞ്ചിനീയറിംഗ് മേഖലയിലെ ഏറ്റവും ചൂടേറിയ വിഷയങ്ങളിലൊന്ന് (അങ്ങനെ തന്നെ!). ഈ സാങ്കേതികവിദ്യ അവിശ്വസനീയമാംവിധം വാഗ്ദാനമാണെന്ന് ഞാൻ കരുതുന്നു, ഇത് വ്യാപകമായി സ്വീകരിക്കുന്നത് കാണാൻ ആഗ്രഹിക്കുന്നു (അത് അർത്ഥമാക്കുമ്പോൾ, തീർച്ചയായും). എന്നിരുന്നാലും, മിക്ക ആളുകൾക്കും ഇത് ഇപ്പോഴും നിഗൂഢതയുടെ ഒരു പ്രഭാവലയത്താൽ ചുറ്റപ്പെട്ടിരിക്കുന്നു. അതേ സമയം, ആർ പോലും നന്നായി അറിയപ്പെടുന്നു അതിനൊപ്പം, അതിന്റെ ഗുണങ്ങളും കൃത്യമായി എന്താണെന്നും (നിങ്ങളുടേത് ഉൾപ്പെടെ) വ്യക്തമാക്കുന്നത് പലപ്പോഴും ബുദ്ധിമുട്ടാണ്. ഈ ലേഖനത്തിൽ ഞാൻ വിവിധ ലിസ്റ്റുകൾ ഉപയോഗിച്ച് സാഹചര്യം ശരിയാക്കാൻ ശ്രമിക്കും കേസുകൾ ഉപയോഗിക്കുക "സർവീസ് മെഷുകൾ"*.

* കുറിപ്പ് transl.: ഇവിടെയും തുടർന്നും ലേഖനത്തിൽ ഈ വിവർത്തനം (“സർവീസ് മെഷ്”) ഇപ്പോഴും പുതിയ പദമായ സർവീസ് മെഷിനായി ഉപയോഗിക്കും.

എന്നാൽ ആദ്യം ഞാൻ കുറച്ച് അഭിപ്രായങ്ങൾ പറയാൻ ആഗ്രഹിക്കുന്നു:

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

ഹ്രസ്വ പട്ടിക:

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

1. സേവന കണ്ടെത്തൽ

TL;DR: ലളിതമായ പേരുകൾ ഉപയോഗിച്ച് നെറ്റ്‌വർക്കിലെ മറ്റ് സേവനങ്ങളിലേക്ക് കണക്റ്റുചെയ്യുക.

മതിയായ പേരുകൾ ഉപയോഗിച്ച് സേവനങ്ങൾക്ക് പരസ്പരം സ്വയമേവ "കണ്ടെത്താൻ" കഴിയണം - ഉദാഹരണത്തിന്, service.api.production, pets/staging അഥവാ cassandra. ക്ലൗഡ് പരിതസ്ഥിതികൾ ഇലാസ്റ്റിക് ആണ്, ഒരു പേരിന് ഒരു സേവനത്തിന്റെ നിരവധി സംഭവങ്ങൾ മറയ്ക്കാനാകും. അത്തരമൊരു സാഹചര്യത്തിൽ എല്ലാ ഐപി വിലാസങ്ങളും ഹാർഡ്കോഡ് ചെയ്യുന്നത് ശാരീരികമായി അസാധ്യമാണെന്ന് വ്യക്തമാണ്.

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

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

2. എൻക്രിപ്ഷൻ

TL;DR: സേവനങ്ങൾക്കിടയിലുള്ള എൻക്രിപ്റ്റ് ചെയ്യാത്ത ട്രാഫിക് ഒഴിവാക്കി ഈ പ്രക്രിയ സ്വയമേവയുള്ളതും അളക്കാവുന്നതുമാക്കുക.

ആക്രമണകാരികൾക്ക് നിങ്ങളുടെ ആന്തരിക നെറ്റ്‌വർക്കിലേക്ക് തുളച്ചുകയറാനാകില്ലെന്നറിയുന്നതിൽ സന്തോഷമുണ്ട്. ഫയർവാളുകൾ ഇതിൽ ഒരു മികച്ച ജോലി ചെയ്യുന്നു. എന്നാൽ ഒരു ഹാക്കർ അകത്ത് കയറിയാൽ എന്ത് സംഭവിക്കും? ഇൻട്രാ സർവീസ് ട്രാഫിക്കിൽ അയാൾ ആഗ്രഹിക്കുന്നതെന്തും ചെയ്യാൻ കഴിയുമോ? എല്ലാത്തിനുമുപരി, ഇത് സംഭവിക്കില്ലെന്ന് നമുക്ക് പ്രതീക്ഷിക്കാം. ഈ സാഹചര്യം തടയുന്നതിന്, സേവനങ്ങൾക്കിടയിലുള്ള എല്ലാ ട്രാഫിക്കും എൻക്രിപ്റ്റ് ചെയ്തിരിക്കുന്ന ഒരു സീറോ-ട്രസ്റ്റ് നെറ്റ്‌വർക്ക് നിങ്ങൾ നടപ്പിലാക്കണം. മിക്ക ആധുനിക സേവന മെഷുകളും പരസ്പരത്തിലൂടെ ഇത് നേടുന്നു TLS (പരസ്പരം TLS, mTLS). ചില സന്ദർഭങ്ങളിൽ, mTLS മുഴുവൻ മേഘങ്ങളിലും ക്ലസ്റ്ററുകളിലും പ്രവർത്തിക്കുന്നു (ഇന്റർപ്ലാനറ്ററി കമ്മ്യൂണിക്കേഷനുകൾ എന്നെങ്കിലും സമാനമായി ക്രമീകരിക്കപ്പെടുമെന്ന് ഞാൻ കരുതുന്നു).

തീർച്ചയായും, mTLS സേവന മെഷിനായി ഓപ്ഷണൽ. ഓരോ സേവനത്തിനും അതിന്റേതായ TLS പരിപാലിക്കാൻ കഴിയും, എന്നാൽ ഇതിനർത്ഥം നിങ്ങൾ സർട്ടിഫിക്കറ്റുകൾ സൃഷ്ടിക്കുന്നതിനും സേവന ഹോസ്റ്റുകളിൽ ഉടനീളം വിതരണം ചെയ്യുന്നതിനും ഫയലുകളിൽ നിന്ന് ഈ സർട്ടിഫിക്കറ്റുകൾ ലോഡ് ചെയ്യുന്ന ആപ്ലിക്കേഷനിൽ കോഡ് ഉൾപ്പെടുത്തുന്നതിനുമുള്ള ഒരു മാർഗം കണ്ടെത്തേണ്ടതുണ്ട് എന്നാണ്. അതെ, കൃത്യമായ ഇടവേളകളിൽ ഈ സർട്ടിഫിക്കറ്റുകൾ പുതുക്കാൻ മറക്കരുത്. സേവന മെഷുകൾ പോലുള്ള സിസ്റ്റങ്ങൾ ഉപയോഗിച്ച് mTLS ഓട്ടോമേറ്റ് ചെയ്യുന്നു SPIFFE, അതാകട്ടെ, സർട്ടിഫിക്കറ്റുകൾ നൽകുകയും തിരിക്കുകയും ചെയ്യുന്ന പ്രക്രിയ ഓട്ടോമേറ്റ് ചെയ്യുന്നു.

3. ആധികാരികതയും അംഗീകാരവും

TL;DR: അഭ്യർത്ഥന നടത്തുന്നയാൾ ആരാണെന്ന് സ്ഥാപിക്കുകയും അഭ്യർത്ഥന സേവനത്തിൽ എത്തുന്നതിന് മുമ്പ് അവർക്ക് എന്താണ് ചെയ്യാൻ അനുവാദമുള്ളതെന്ന് നിർവചിക്കുകയും ചെയ്യുക.

സേവനങ്ങൾ പലപ്പോഴും അറിയാൻ ആഗ്രഹിക്കുന്നു ആരാണ് അഭ്യർത്ഥന (ആധികാരികത) നിർവഹിക്കുന്നു, ഈ വിവരങ്ങൾ ഉപയോഗിച്ച് തീരുമാനിക്കുന്നു ആ തന്നിരിക്കുന്ന ഒരു സ്ഥാപനത്തെ ചെയ്യാൻ അനുവദിച്ചിരിക്കുന്നു (അംഗീകാരം). ഈ സാഹചര്യത്തിൽ, "ആരാണ്" എന്ന സർവ്വനാമം മറയ്ക്കാൻ കഴിയും:

1. മറ്റ് സേവനങ്ങൾ. ഇതിനെ "ആധികാരികത" എന്ന് വിളിക്കുന്നു സമപ്രായക്കാരൻ" ഉദാഹരണത്തിന്, സേവനം web സേവനം ആക്സസ് ചെയ്യാൻ ആഗ്രഹിക്കുന്നു db. സേവന മെഷുകൾ സാധാരണയായി mTLS ഉപയോഗിച്ച് ഇത്തരം പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നു: ഈ സാഹചര്യത്തിൽ സർട്ടിഫിക്കറ്റുകൾ ആവശ്യമായ ഐഡന്റിഫയറായി പ്രവർത്തിക്കുന്നു.
2. ചില മനുഷ്യ ഉപയോക്താക്കൾ. ഇതിനെ "ആധികാരികത" എന്ന് വിളിക്കുന്നു അഭ്യർത്ഥന" ഉദാഹരണത്തിന്, ഉപയോക്താവ് haxor69 ഒരു പുതിയ വിളക്ക് വാങ്ങാൻ ആഗ്രഹിക്കുന്നു. സേവന മെഷുകൾ വിവിധ സംവിധാനങ്ങൾ നൽകുന്നു, ഉദാ. JSON വെബ് ടോക്കണുകൾ.

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

അഭ്യർത്ഥന ആരിൽ നിന്നാണ് വന്നതെന്ന് ഞങ്ങൾ സ്ഥാപിച്ചുകഴിഞ്ഞാൽ, ഈ എന്റിറ്റിയെ എന്താണ് ചെയ്യാൻ അനുവദിക്കുന്നതെന്ന് ഞങ്ങൾ നിർണ്ണയിക്കേണ്ടതുണ്ട്. ചില സേവന മെഷുകൾ YAML ഫയലുകളായി അല്ലെങ്കിൽ കമാൻഡ് ലൈനിൽ അടിസ്ഥാന നയങ്ങൾ (ആർക്കൊക്കെ എന്തുചെയ്യാൻ കഴിയും എന്നതിനെക്കുറിച്ച്) സജ്ജീകരിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു, മറ്റുചിലത് ചട്ടക്കൂടുകളുമായുള്ള സംയോജനം വാഗ്ദാനം ചെയ്യുന്നു പോളിസി ഏജന്റ് തുറക്കുക. നിങ്ങളുടെ സേവനങ്ങൾ ഏതെങ്കിലും അഭ്യർത്ഥന സ്വീകരിക്കുക എന്നതാണ് ആത്യന്തിക ലക്ഷ്യം, അത് വിശ്വസനീയമായ ഉറവിടത്തിൽ നിന്നാണ് വരുന്നതെന്ന് സുരക്ഷിതമായി കരുതുക и ഈ പ്രവർത്തനം അനുവദനീയമാണ്.

4. ലോഡ് ബാലൻസിങ്

TL;DR: ഒരു നിർദ്ദിഷ്ട പാറ്റേൺ അനുസരിച്ച് സേവന സന്ദർഭങ്ങളിൽ ഉടനീളം ലോഡ് വിതരണം ചെയ്യുക.

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

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

5. സർക്യൂട്ട് ബ്രേക്കിംഗ്

TL;DR: പ്രശ്നമുള്ള സേവനത്തിലേക്കുള്ള ട്രാഫിക് നിർത്തുക, ഏറ്റവും മോശം സാഹചര്യങ്ങളിൽ കേടുപാടുകൾ നിയന്ത്രിക്കുക.

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

സേവന മെഷുകൾ നിങ്ങളെ നിർവചിക്കാൻ മാത്രമല്ല അനുവദിക്കുന്നത് എപ്പോൾ ഷട്ട്ഡൗൺ പിന്തുടരും ആ ഇത് പിന്തുടരും. ഈ സാഹചര്യത്തിൽ, "എപ്പോൾ" എന്നതിൽ നിർദ്ദിഷ്ട പാരാമീറ്ററുകളുടെ ഏതെങ്കിലും സംയോജനം ഉൾപ്പെടുത്താം: ഒരു നിശ്ചിത കാലയളവിലെ മൊത്തം അഭ്യർത്ഥനകളുടെ എണ്ണം, സമാന്തര കണക്ഷനുകളുടെ എണ്ണം, തീർച്ചപ്പെടുത്താത്ത അഭ്യർത്ഥനകൾ, സജീവമായ പുനരാരംഭങ്ങൾ മുതലായവ.

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

6. ഓട്ടോസ്കെയിലിംഗ്

TL;DR: നിർദ്ദിഷ്ട മാനദണ്ഡങ്ങൾക്കനുസരിച്ച് സേവന സംഭവങ്ങളുടെ എണ്ണം കൂട്ടുകയോ കുറയ്ക്കുകയോ ചെയ്യുക.

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

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

7. കാനറി വിന്യാസങ്ങൾ

TL;DR: ഉപയോക്താക്കളുടെ ഒരു ഉപവിഭാഗത്തിൽ പുതിയ ഫീച്ചറുകൾ അല്ലെങ്കിൽ സേവന പതിപ്പുകൾ പരീക്ഷിക്കുക.

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

ആപ്ലിക്കേഷന്റെ ഏത് പതിപ്പ് ആരാണ് കാണേണ്ടതെന്ന് നിർണ്ണയിക്കുന്ന മാനദണ്ഡങ്ങൾ വ്യക്തമാക്കാൻ നിങ്ങളെ അനുവദിച്ചുകൊണ്ട് സേവന മെഷുകൾ ഇത് നടപ്പിലാക്കുന്നു, അതനുസരിച്ച് ട്രാഫിക്ക് റൂട്ട് ചെയ്യുന്നു. എന്നിരുന്നാലും, സേവനങ്ങൾക്ക് തന്നെ മാറ്റമൊന്നുമില്ല. എല്ലാ അഭ്യർത്ഥനകളും അത് കാണേണ്ട ഉപയോക്താക്കളിൽ നിന്നാണ് വരുന്നതെന്ന് സേവനത്തിന്റെ പതിപ്പ് 1.0 വിശ്വസിക്കുന്നു, കൂടാതെ പതിപ്പ് 1.1 അതിന്റെ ഉപയോക്താക്കൾക്കും അങ്ങനെ തന്നെ വിശ്വസിക്കുന്നു. അതിനിടയിൽ, പഴയതും പുതിയതുമായ പതിപ്പുകൾക്കിടയിലുള്ള ട്രാഫിക്കിന്റെ ശതമാനം നിങ്ങൾക്ക് മാറ്റാനാകും, ഇത് സ്ഥിരതയോടെ പ്രവർത്തിക്കുകയും നിങ്ങളുടെ "പരീക്ഷണങ്ങൾ" മുന്നോട്ട് പോകുകയും ചെയ്താൽ, വർദ്ധിച്ചുവരുന്ന ഉപയോക്താക്കളെ പുതിയതിലേക്ക് റീഡയറക്‌ടുചെയ്യാനാകും.

8. നീല-പച്ച വിന്യാസങ്ങൾ

TL;DR: രസകരമായ ഒരു പുതിയ ഫീച്ചർ അവതരിപ്പിക്കുക, എന്നാൽ എല്ലാം ഉടനടി തിരികെ എടുക്കാൻ തയ്യാറാകുക.

അർത്ഥം നീല-പച്ച വിന്യാസങ്ങൾ പഴയ, "പച്ച" സേവനത്തിന് സമാന്തരമായി ഒരു പുതിയ "നീല" സേവനം പുറത്തിറക്കുക എന്നതാണ്. എല്ലാം സുഗമമായി നടക്കുകയും പുതിയ സേവനം മികച്ച രീതിയിൽ പ്രവർത്തിക്കുകയും ചെയ്താൽ, പഴയത് ക്രമേണ പ്രവർത്തനരഹിതമാക്കാം. (അയ്യോ, എന്നെങ്കിലും ഈ പുതിയ "നീല" സേവനം "പച്ച" ഒന്നിന്റെ വിധി ആവർത്തിക്കുകയും അപ്രത്യക്ഷമാവുകയും ചെയ്യും...) നീല-പച്ച വിന്യാസങ്ങൾ കാനറികളിൽ നിന്ന് വ്യത്യസ്തമാണ്, പുതിയ ഫംഗ്ഷൻ കവർ ചെയ്യുന്നു എല്ലാവരും ഒരേസമയം ഉപയോക്താക്കൾ (ഭാഗമല്ല); എന്തെങ്കിലും തെറ്റ് സംഭവിച്ചാൽ "സുരക്ഷിത തുറമുഖം" തയ്യാറാക്കുക എന്നതാണ് ഇവിടെ പ്രധാനം.

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

കുറിപ്പ്. വിവർത്തനം.: കുബെർനെറ്റസിലെ വ്യത്യസ്ത വിന്യാസ തന്ത്രങ്ങളെക്കുറിച്ച് നിങ്ങൾക്ക് കൂടുതൽ വായിക്കാം (പ്രസ്താവിച്ച കാനറി, നീല/പച്ച എന്നിവയും മറ്റുള്ളവയും ഉൾപ്പെടെ) ഈ ലേഖനം.

9. ആരോഗ്യ പരിശോധന

TL;DR: പ്രവർത്തനക്ഷമമായ സേവന സംഭവങ്ങളുടെ ട്രാക്ക് സൂക്ഷിക്കുക, ഇനി പ്രവർത്തനക്ഷമമല്ലാത്തവയോട് പ്രതികരിക്കുക.

ആരോഗ്യ പരിശോധന (ആരോഗ്യ പരിശോധന) ട്രാഫിക് സ്വീകരിക്കാനും പ്രോസസ്സ് ചെയ്യാനും സേവന സംഭവങ്ങൾ തയ്യാറാണോ എന്ന് തീരുമാനിക്കാൻ സഹായിക്കുന്നു. ഉദാഹരണത്തിന്, HTTP സേവനങ്ങളുടെ കാര്യത്തിൽ, ഒരു ആരോഗ്യ പരിശോധന എൻഡ്‌പോയിന്റിലേക്കുള്ള GET അഭ്യർത്ഥന പോലെയായിരിക്കാം /health. ഉത്തരം 200 OK ഉദാഹരണം ആരോഗ്യകരമാണെന്നാണ് അർത്ഥമാക്കുന്നത്, മറ്റേതെങ്കിലും - അത് ട്രാഫിക് സ്വീകരിക്കാൻ തയ്യാറല്ല എന്നാണ്. പ്രവർത്തനക്ഷമത പരിശോധിക്കേണ്ട രീതിയും ഈ പരിശോധന നടത്തേണ്ട ആവൃത്തിയും വ്യക്തമാക്കാൻ സേവന മെഷുകൾ നിങ്ങളെ അനുവദിക്കുന്നു. ഈ വിവരങ്ങൾ പിന്നീട് മറ്റ് ആവശ്യങ്ങൾക്ക് ഉപയോഗിക്കാം - ഉദാഹരണത്തിന്, ലോഡ് ബാലൻസിംഗിനും സർക്യൂട്ട് ബ്രേക്കിംഗിനും.

അതിനാൽ, ആരോഗ്യ പരിശോധന ഒരു ഒറ്റപ്പെട്ട ഉപയോഗമല്ല, മറിച്ച് മറ്റ് ലക്ഷ്യങ്ങൾ കൈവരിക്കാൻ സാധാരണയായി ഉപയോഗിക്കുന്നു. കൂടാതെ, ആരോഗ്യ പരിശോധനകളുടെ ഫലങ്ങൾ അനുസരിച്ച്, മറ്റ് സേവന മെഷ് ടാർഗെറ്റുകൾക്ക് പുറത്തുള്ള പ്രവർത്തനങ്ങൾ ആവശ്യമായി വന്നേക്കാം: ഉദാഹരണത്തിന്, സ്റ്റാറ്റസ് പേജ് അപ്ഡേറ്റ് ചെയ്യുക, GitHub-ൽ ഒരു പ്രശ്നം സൃഷ്ടിക്കുക, അല്ലെങ്കിൽ ഒരു JIRA ടിക്കറ്റ് പൂരിപ്പിക്കുക. ഇതെല്ലാം ഓട്ടോമേറ്റ് ചെയ്യുന്നതിനുള്ള സൗകര്യപ്രദമായ ഒരു സംവിധാനം സേവന മെഷ് വാഗ്ദാനം ചെയ്യുന്നു.

10. ലോഡ് ഷെഡിംഗ്

TL;DR: ഉപയോഗത്തിലെ താത്കാലിക വർദ്ധനവിന് പ്രതികരണമായി ട്രാഫിക് റീഡയറക്ട് ചെയ്യുക.

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

11. ട്രാഫിക് പാരലലൈസേഷൻ/മിററിംഗ്

TL;DR: ഒരേസമയം നിരവധി സ്ഥലങ്ങളിലേക്ക് ഒരു അഭ്യർത്ഥന അയയ്‌ക്കുക.

ചിലപ്പോൾ ഒരേസമയം നിരവധി സേവനങ്ങളിലേക്ക് ഒരു അഭ്യർത്ഥന (അല്ലെങ്കിൽ ഒരു നിശ്ചിത അഭ്യർത്ഥനകൾ) അയയ്‌ക്കേണ്ടതുണ്ട്. പ്രൊഡക്ഷൻ ട്രാഫിക്കിന്റെ ഒരു ഭാഗം ഒരു സ്റ്റേജിംഗ് സേവനത്തിലേക്ക് അയയ്ക്കുന്നതാണ് ഒരു സാധാരണ ഉദാഹരണം. പ്രധാന പ്രൊഡക്ഷൻ വെബ് സെർവർ ഡൗൺസ്ട്രീം സേവനത്തിലേക്ക് ഒരു അഭ്യർത്ഥന അയയ്ക്കുന്നു products.production അവനോട് മാത്രം. സേവന മെഷ് ഈ അഭ്യർത്ഥന ബുദ്ധിപരമായി പകർത്തി അയയ്‌ക്കുന്നു products.staging, ഇത് വെബ് സെർവറിന് പോലും അറിയില്ല.

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

12. ഇൻസുലേഷൻ

TL;DR: നിങ്ങളുടെ സേവന മെഷിനെ മിനി നെറ്റ്‌വർക്കുകളായി വിഭജിക്കുക.

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

കൂടാതെ, ആനുകൂല്യങ്ങൾ സംഘടനാപരമായിരിക്കാം. നിങ്ങളുടെ കമ്പനി ഘടനയെ അടിസ്ഥാനമാക്കി നിങ്ങളുടെ സേവനങ്ങൾ സബ്‌നെറ്റ് ചെയ്യാനും മുഴുവൻ സേവന മെഷും മനസ്സിൽ സൂക്ഷിക്കേണ്ട കോഗ്നിറ്റീവ് ലോഡിൽ നിന്ന് ഡെവലപ്പർമാരെ ഒഴിവാക്കാനും നിങ്ങൾ ആഗ്രഹിച്ചേക്കാം.

13. അഭ്യർത്ഥന നിരക്ക് പരിമിതപ്പെടുത്തൽ, വീണ്ടും ശ്രമിക്കൽ, കാലഹരണപ്പെടലുകൾ

TL;DR: നിങ്ങളുടെ കോഡ്‌ബേസിൽ ഇനി നിറ്റി-ഗ്രിറ്റി റിക്വസ്റ്റ് മാനേജ്‌മെന്റ് ടാസ്‌ക്കുകൾ ഉൾപ്പെടുത്തേണ്ടതില്ല.

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

ഈ ടാസ്‌ക്കുകൾ ഒരു സേവന മെഷിലേക്ക് ഓഫ്‌ലോഡ് ചെയ്യുന്നത് അർത്ഥമാക്കുന്നത് സേവന ഡെവലപ്പർമാർക്ക് അവയെക്കുറിച്ച് ചിന്തിക്കേണ്ടതില്ല, മാത്രമല്ല അവ കൂടുതൽ ആഗോള രീതിയിൽ കാണാനും കഴിയും. ഒരു സങ്കീർണ്ണമായ സേവന ശൃംഖല ഉപയോഗിക്കുകയാണെങ്കിൽ, A -> B -> C -> D -> E എന്ന് പറയുക, അഭ്യർത്ഥനയുടെ മുഴുവൻ ജീവിതചക്രവും കണക്കിലെടുക്കണം. സേവന സിയിൽ സമയപരിധി നീട്ടുക എന്നതാണ് ചുമതലയെങ്കിൽ, ഇത് ഭാഗികമായല്ല ഒറ്റയടിക്ക് ചെയ്യുന്നത് യുക്തിസഹമാണ്: സേവന കോഡ് അപ്‌ഡേറ്റ് ചെയ്‌ത് പുൾ അഭ്യർത്ഥന സ്വീകരിക്കുന്നതുവരെ കാത്തിരിക്കുകയും CI സിസ്റ്റം അപ്‌ഡേറ്റ് ചെയ്‌ത സേവനം വിന്യസിക്കുകയും ചെയ്യുന്നു.

14. ടെലിമെട്രി

TL;DR: സേവനങ്ങളിൽ നിന്ന് ആവശ്യമായ (തികച്ചും അല്ല) എല്ലാ വിവരങ്ങളും ശേഖരിക്കുക.

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

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

• CLI-യിലെ ഒരു നിശ്ചിത സേവനത്തിൽ നിന്നുള്ള ടെയിൽ ലോഗുകൾ;
• സേവന മെഷ് ഡാഷ്‌ബോർഡിൽ നിന്നുള്ള അഭ്യർത്ഥനകളുടെ അളവ് നിരീക്ഷിക്കുക;
• വിതരണം ചെയ്ത ട്രെയ്‌സുകൾ ശേഖരിച്ച് ജെയ്‌ഗർ പോലുള്ള ഒരു സിസ്റ്റത്തിലേക്ക് കൈമാറുക.

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

15. ഓഡിറ്റ്

TL;DR: ചരിത്രത്തിന്റെ പാഠങ്ങൾ മറക്കുന്നവർ അത് ആവർത്തിക്കാൻ വിധിക്കപ്പെട്ടവരാണ്.

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

ഓഡിറ്റിംഗ് ടെലിമെട്രിയുമായി വളരെ അടുത്ത ബന്ധമുണ്ടെന്ന് വ്യക്തമാണ്. വ്യത്യാസം എന്തെന്നാൽ, ടെലിമെട്രി സാധാരണയായി ഉൽപ്പാദനക്ഷമതയും സാങ്കേതിക സമഗ്രതയും പോലെയുള്ള കാര്യങ്ങളുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു, അതേസമയം ഓഡിറ്റിംഗിന് കർശനമായ സാങ്കേതിക മേഖലയ്ക്ക് അപ്പുറത്തുള്ള നിയമപരവും മറ്റ് പ്രശ്നങ്ങളും (ഉദാഹരണത്തിന്, GDPR-ന് അനുസൃതമായി - ഡാറ്റാ സംരക്ഷണത്തെക്കുറിച്ചുള്ള EU പൊതു നിയന്ത്രണം) ബന്ധപ്പെട്ടിരിക്കുന്നു.

16. ദൃശ്യവൽക്കരണം

TL;DR: Long live React.js - ഫാൻസി ഇന്റർഫേസുകളുടെ ഒഴിച്ചുകൂടാനാവാത്ത ഉറവിടം.

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

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

പട്ടികയിൽ ഉൾപ്പെടുത്തിയിട്ടില്ല

ലിസ്റ്റിൽ കുറച്ച് ഉപയോഗ കേസുകൾ കൂടി ഉൾപ്പെടുത്താനാണ് ഞാൻ ആദ്യം ഉദ്ദേശിച്ചത്, എന്നാൽ പിന്നീട് അത് വേണ്ടെന്ന് തീരുമാനിച്ചു. എന്റെ തീരുമാനത്തിനുള്ള കാരണങ്ങളോടൊപ്പം അവ ഇതാ:

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

തീരുമാനം

ഇപ്പോഴത്തേക്ക് ഇത്രമാത്രം! വീണ്ടും, ഈ ലിസ്റ്റ് വളരെ ഏകപക്ഷീയവും മിക്കവാറും അപൂർണ്ണവുമാണ്. എനിക്ക് എന്തെങ്കിലും നഷ്ടമായെന്നോ എന്തെങ്കിലും തെറ്റ് പറ്റിയെന്നോ നിങ്ങൾ കരുതുന്നുവെങ്കിൽ, ദയവായി എന്നെ Twitter-ൽ ബന്ധപ്പെടുക (@ലക്കർകിൻസ്). മാന്യതയുടെ നിയമങ്ങൾ ദയവായി മാനിക്കുക.

വിവർത്തകനിൽ നിന്ന് പി.എസ്

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

ഞങ്ങളുടെ ബ്ലോഗിലും വായിക്കുക:

• «സർവീസ് മെഷ്: ഏറ്റവും ചൂടേറിയ സാങ്കേതികവിദ്യയെക്കുറിച്ച് ഓരോ സോഫ്റ്റ്‌വെയർ എഞ്ചിനീയറും അറിഞ്ഞിരിക്കേണ്ട കാര്യങ്ങൾ";
• «എന്താണ് ഒരു സർവീസ് മെഷ്, എന്തുകൊണ്ട് എനിക്ക് ഇത് ആവശ്യമാണ് [മൈക്രോ സർവീസുകളുള്ള ഒരു ക്ലൗഡ് ആപ്ലിക്കേഷന്]?";
• «ഇസ്തിയോയ്‌ക്കൊപ്പം മൈക്രോസർവീസുകളിലേക്ക് മടങ്ങുക. ഭാഗം 1".

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