സർവീസ് മെഷ്: ഏറ്റവും ചൂടേറിയ സാങ്കേതികവിദ്യയെക്കുറിച്ച് ഓരോ സോഫ്റ്റ്‌വെയർ എഞ്ചിനീയറും അറിഞ്ഞിരിക്കേണ്ട കാര്യങ്ങൾ

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

നിന്ന് കോമിക് സെബാസ്റ്റ്യൻ കാസെറസ്

ആമുഖം

നിങ്ങൾ ബാക്കെൻഡ് സിസ്റ്റങ്ങളുടെ മേഖലയിൽ എവിടെയെങ്കിലും പ്രവർത്തിക്കുന്ന ഒരു സോഫ്റ്റ്‌വെയർ എഞ്ചിനീയറാണെങ്കിൽ, "സർവീസ് മെഷ്" എന്ന പദം കഴിഞ്ഞ രണ്ട് വർഷങ്ങളായി നിങ്ങളുടെ മനസ്സിൽ ദൃഢമായി പതിഞ്ഞിട്ടുണ്ട്. വിചിത്രമായ യാദൃശ്ചികതയ്ക്ക് നന്ദി, ഈ വാചകം വ്യവസായത്തെ കൂടുതൽ കൂടുതൽ ഏറ്റെടുക്കുന്നു, കൂടാതെ ഹൈപ്പും അനുബന്ധ പ്രമോഷണൽ ഓഫറുകളും ഒരു സ്നോബോൾ പോലെ വളരുകയും കുന്നിൻ മുകളിലേക്ക് പറക്കുകയും വേഗത കുറയുന്നതിന്റെ ലക്ഷണങ്ങൾ കാണിക്കുകയും ചെയ്യുന്നു.

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

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

ഞാൻ ആരാണ്?

എല്ലാവർക്കും ഹായ്! എന്റെ പേര് വില്യം മോർഗൻ. ഞാൻ സ്രഷ്ടാക്കളുടെ കൂട്ടത്തിൽ ഒരാളാണ് ലിങ്കർഡ് - ആദ്യത്തെ സേവന മെഷ് പ്രോജക്റ്റും ഈ പദത്തിന്റെ രൂപത്തിന് കുറ്റപ്പെടുത്തുന്ന പ്രോജക്റ്റും സേവന മെഷ് അതുപോലെ (ക്ഷമിക്കണം സുഹൃത്തുക്കളെ!). (കുറിപ്പ് വിവർത്തനം.: വഴിയിൽ, ഈ പദത്തിന്റെ ഉദയത്തിൽ, 2,5 വർഷങ്ങൾക്ക് മുമ്പ്, അതേ രചയിതാവിന്റെ ആദ്യകാല മെറ്റീരിയൽ ഞങ്ങൾ ഇതിനകം വിവർത്തനം ചെയ്തു "എന്താണ് ഒരു സർവീസ് മെഷ്, എന്തുകൊണ്ട് എനിക്ക് ഇത് ആവശ്യമാണ് [മൈക്രോ സർവീസുകളുള്ള ഒരു ക്ലൗഡ് ആപ്ലിക്കേഷന്]?".) ഞാനും നയിക്കുന്നു ബൊയന്റ് Linkerd പോലുള്ള രസകരമായ സേവന മെഷ് കാര്യങ്ങൾ സൃഷ്ടിക്കുന്ന ഒരു സ്റ്റാർട്ടപ്പ് ആണ് ഡൈവിംഗ്.

ഈ വിഷയത്തിൽ എനിക്ക് വളരെ പക്ഷപാതപരവും ആത്മനിഷ്ഠവുമായ അഭിപ്രായമുണ്ടെന്ന് നിങ്ങൾക്ക് ഊഹിക്കാം. എന്നിരുന്നാലും, പക്ഷപാതം പരമാവധി കുറയ്ക്കാൻ ഞാൻ ശ്രമിക്കും (ഒരു വിഭാഗം ഒഴികെ: "എന്തുകൊണ്ടാണ് സർവീസ് മെഷിനെക്കുറിച്ച് ഇത്രയധികം സംസാരം?", - ഇതിൽ ഞാൻ എന്റെ മുൻവിധിയുള്ള ആശയങ്ങൾ പങ്കിടും). ഈ ഗൈഡ് കഴിയുന്നത്ര വസ്തുനിഷ്ഠമാക്കാൻ ഞാൻ പരമാവധി ശ്രമിക്കും. നിർദ്ദിഷ്ട ഉദാഹരണങ്ങളിൽ, മറ്റ് തരത്തിലുള്ള സേവന മെഷ് നടപ്പിലാക്കുന്നതിൽ എനിക്കറിയാവുന്ന വ്യത്യാസങ്ങൾ (എന്തെങ്കിലും ഉണ്ടെങ്കിൽ) ചൂണ്ടിക്കാണിച്ചുകൊണ്ട്, ഞാൻ പ്രധാനമായും Linkerd-ന്റെ അനുഭവത്തെ ആശ്രയിക്കും.

ശരി, നന്മകളിലേക്ക് നീങ്ങാനുള്ള സമയമായി.

എന്താണ് ഒരു സേവന മെഷ്?

എല്ലാ ഹൈപ്പുകളും ഉണ്ടായിരുന്നിട്ടും, സേവന മെഷ് ഘടനാപരമായി വളരെ ലളിതമാണ്. ഇത് സേവനങ്ങളുടെ "അടുത്തായി" സ്ഥിതി ചെയ്യുന്ന ഉപയോക്തൃസ്പേസ് പ്രോക്സികളുടെ ഒരു കൂട്ടം മാത്രമാണ് ("അടുത്തത്" എന്താണെന്നതിനെക്കുറിച്ച് ഞങ്ങൾ കുറച്ച് സംസാരിക്കും), കൂടാതെ ഒരു കൂട്ടം നിയന്ത്രണ പ്രക്രിയകളും. പ്രോക്സികളെ കൂട്ടായി വിളിക്കുന്നു ഡാറ്റാ വിമാനം, നിയന്ത്രണ പ്രക്രിയകൾ എന്ന് വിളിക്കുന്നു നിയന്ത്രണ തലം. സേവനങ്ങൾക്കിടയിലുള്ള കോളുകൾ ഡാറ്റാ പ്ലെയിൻ തടസ്സപ്പെടുത്തുകയും അവയുമായി "വ്യത്യസ്‌തമായ എന്തെങ്കിലും" ചെയ്യുകയും ചെയ്യുന്നു; നിയന്ത്രണ തലം, യഥാക്രമം, പ്രോക്സിയുടെ പെരുമാറ്റം ഏകോപിപ്പിക്കുകയും നിങ്ങൾക്ക് ആക്സസ് നൽകുകയും ചെയ്യുന്നു, അതായത്. ഓപ്പറേറ്റർ, API-യിലേക്ക്, നെറ്റ്‌വർക്ക് കൈകാര്യം ചെയ്യാനും മൊത്തത്തിൽ അളക്കാനും അനുവദിക്കുന്നു.

ഇത് ഏത് തരത്തിലുള്ള പ്രോക്സി ആണ്? ഇത് "ലേയർ 7-അവെയർ" വിഭാഗത്തിന്റെ TCP പ്രോക്സി ആണ് (അതായത് OSI മോഡലിന്റെ 7-ാമത്തെ ലെയർ "അക്കൗണ്ടിൽ എടുക്കുന്നു") HAProxy, NGINX എന്നിവ പോലെ. നിങ്ങളുടെ ഇഷ്ടത്തിനനുസരിച്ച് ഒരു പ്രോക്സി തിരഞ്ഞെടുക്കാം; ലിങ്കർഡ് ഒരു റസ്റ്റ് പ്രോക്സി ഉപയോഗിക്കുന്നു, സങ്കീർണ്ണമല്ലാത്ത പേരിലാണ് linkerd-proxy. സേവന മെഷിനായി ഞങ്ങൾ ഇത് പ്രത്യേകമായി സമാഹരിച്ചിരിക്കുന്നു. മറ്റ് മെഷുകൾ മറ്റ് പ്രോക്സികളെയാണ് ഇഷ്ടപ്പെടുന്നത് (ദൂതൻ ഒരു പൊതു തിരഞ്ഞെടുപ്പാണ്). എന്നിരുന്നാലും, ഒരു പ്രോക്സി തിരഞ്ഞെടുക്കുന്നത് നടപ്പാക്കലിന്റെ കാര്യം മാത്രമാണ്.

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

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

ലിങ്കർഡിലെ കൺട്രോൾ പ്ലെയിനിന്റെയും ഡാറ്റാ പ്ലെയിനിന്റെയും ഒരു ഡയഗ്രം ചുവടെയുണ്ട്. നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, കൺട്രോൾ പ്ലെയിനിൽ പ്രോക്സി സെർവറുകളിൽ നിന്ന് മെട്രിക്‌സ് ശേഖരിക്കുന്ന പ്രോമിത്യൂസ് ഉദാഹരണം ഉൾപ്പെടെ നിരവധി വ്യത്യസ്ത ഘടകങ്ങൾ ഉൾപ്പെടുന്നു, അതുപോലെ തന്നെ മറ്റ് ഘടകങ്ങളും destination (സേവന കണ്ടെത്തൽ), identity (സർട്ടിഫിക്കറ്റ് അതോറിറ്റി, സിഎ) കൂടാതെ public-api (വെബിനും CLI-നുമായുള്ള അവസാന പോയിന്റുകൾ). വിപരീതമായി, ആപ്ലിക്കേഷൻ ഇൻസ്‌റ്റൻസിന് അടുത്തുള്ള ഒരു ലളിതമായ ലിങ്കർഡ്-പ്രോക്സിയാണ് ഡാറ്റാ പ്ലെയിൻ. ഇതൊരു ലോജിക് ഡയഗ്രം മാത്രമാണ്; ഒരു യഥാർത്ഥ ലോക വിന്യാസത്തിൽ, നിങ്ങൾക്ക് ഓരോ കൺട്രോൾ പ്ലെയിൻ ഘടകത്തിന്റെയും മൂന്ന് പകർപ്പുകളും ഡാറ്റാ പ്ലെയിനിൽ നൂറുകണക്കിന് അല്ലെങ്കിൽ ആയിരക്കണക്കിന് പ്രോക്സികളും ഉണ്ടായിരിക്കാം.

(ഈ ഡയഗ്രാമിലെ നീല ബോക്സുകൾ കുബർനെറ്റസ് പോഡുകളുടെ ബോർഡറുകളെ പ്രതിനിധീകരിക്കുന്നു. ലിങ്കർഡ്-പ്രോക്സി ഉള്ള കണ്ടെയ്‌നറുകൾ ആപ്ലിക്കേഷൻ കണ്ടെയ്‌നറുകളുടെ അതേ പോഡിൽ തന്നെയാണെന്ന് നിങ്ങൾക്ക് കാണാൻ കഴിയും. ഈ സ്കീം അറിയപ്പെടുന്നത് സൈഡ്കാർ കണ്ടെയ്നർ.)

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

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

1. ഡാറ്റാ പ്ലെയിനിലെ പ്രോക്സികൾ ആയിരിക്കണം വേഗം, ഓരോ കോളിനും പ്രോക്സിയിലേക്ക് രണ്ട് കോളുകൾ ഉണ്ട്: ഒന്ന് ക്ലയന്റ് വശത്ത്, ഒന്ന് സെർവർ വശത്ത്.
2. പ്രോക്സികളും ആയിരിക്കണം ചെറിയ и ഭാരം കുറഞ്ഞ. ഓരോന്നും മെമ്മറിയും സിപിയു ഉറവിടങ്ങളും ഉപയോഗിക്കും, ഈ ഉപഭോഗം ആപ്ലിക്കേഷനുമായി രേഖീയമായി വളരും.
3. ധാരാളം പ്രോക്സികൾ വിന്യസിക്കാനും അപ്ഡേറ്റ് ചെയ്യാനും നിങ്ങൾക്ക് ഒരു സംവിധാനം ആവശ്യമാണ്. ഇത് സ്വമേധയാ ചെയ്യുന്നത് ഒരു ഓപ്ഷനല്ല.

പൊതുവേ, സേവന മെഷ് ഇതുപോലെയാണ് കാണപ്പെടുന്നത് (കുറഞ്ഞത് ഒരു പക്ഷിയുടെ കാഴ്ചയിൽ നിന്നെങ്കിലും): നിങ്ങൾ ഇന്റേണൽ, ഇന്റർ-സർവീസ് ട്രാഫിക്കിൽ "എന്തെങ്കിലും ചെയ്യുന്ന" ഒരു കൂട്ടം ഉപയോക്തൃ സ്പേസ് പ്രോക്സികളെ വിന്യസിക്കുന്നു, അവ നിരീക്ഷിക്കാനും നിയന്ത്രിക്കാനും കൺട്രോൾ പ്ലെയിൻ ഉപയോഗിക്കുക.

"എന്തുകൊണ്ട്?" എന്ന ചോദ്യത്തിനുള്ള സമയമാണിത്.

ഒരു സേവന മെഷ് എന്തിനുവേണ്ടിയാണ്?

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

ഈ ചോദ്യത്തിനുള്ള ഉത്തരത്തിന് രണ്ട് ഭാഗങ്ങളുണ്ട്. ഒന്നാമതായി, ആവാസവ്യവസ്ഥയിൽ സംഭവിക്കുന്ന ചില മാറ്റങ്ങൾ കാരണം ഈ പ്രോക്സികളെ വിന്യസിക്കുന്നതുമായി ബന്ധപ്പെട്ട ഇടപാട് ചെലവുകൾ ഗണ്യമായി കുറയ്ക്കാൻ കഴിയും (ഇതിൽ പിന്നീട് കൂടുതൽ).

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

ഉദാഹരണത്തിന്, Linkerd-ൽ (മിക്ക മെഷുകളിലെയും പോലെ) പ്രവർത്തനം പ്രധാനമായും HTTP കോളുകളിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നു, HTTP/2, gRPC* എന്നിവയുൾപ്പെടെ. പ്രവർത്തനം വളരെ സമ്പന്നമാണ് - അതിനെ മൂന്ന് ക്ലാസുകളായി തിരിക്കാം:

1. ബന്ധപ്പെട്ട സവിശേഷതകൾ വിശ്വാസ്യത. വീണ്ടും ശ്രമിക്കൂ അഭ്യർത്ഥനകൾ, കാലഹരണപ്പെടലുകൾ, കാനറി സമീപനം (ട്രാഫിക് സ്പ്ലിറ്റ് / റീഡയറക്‌ട്) മുതലായവ.
2. ബന്ധപ്പെട്ട സവിശേഷതകൾ നിരീക്ഷണം. ഓരോ സേവനത്തിനോ വ്യക്തിഗത ലക്ഷ്യസ്ഥാനങ്ങൾക്കോ ​​​​വിജയ നിരക്ക്, കാലതാമസം, അഭ്യർത്ഥന വോള്യങ്ങൾ എന്നിവയുടെ സംഗ്രഹം; സേവനങ്ങളുടെ ടോപ്പോളജിക്കൽ മാപ്പുകൾ നിർമ്മിക്കുക മുതലായവ.
3. ബന്ധപ്പെട്ട സവിശേഷതകൾ സുരക്ഷ. മ്യൂച്വൽ TLS, ആക്സസ് കൺട്രോൾ മുതലായവ.

* Linkerd-ന്റെ വീക്ഷണകോണിൽ നിന്ന്, gRPC പ്രായോഗികമായി HTTP/2 ൽ നിന്ന് വ്യത്യസ്തമല്ല: ഇത് പേലോഡിൽ പ്രോട്ടോബഫ് ഉപയോഗിക്കുന്നു. ഒരു ഡെവലപ്പറുടെ കാഴ്ചപ്പാടിൽ, ഈ രണ്ട് കാര്യങ്ങളും തീർച്ചയായും വ്യത്യസ്തമാണ്.

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

കണക്ഷൻ തലത്തിലും പ്രോക്സികൾക്ക് "എന്തെങ്കിലും ചെയ്യാൻ" കഴിയും. ഉദാഹരണത്തിന്, Foo വശത്തുള്ള ഒരു ലിങ്കർഡ്-പ്രോക്സിക്ക് ഒരു TLS കണക്ഷൻ ആരംഭിക്കാൻ കഴിയും, കൂടാതെ ബാർ വശത്തുള്ള ഒരു ലിങ്കർഡ്-പ്രോക്സിക്ക് അത് അവസാനിപ്പിക്കാൻ കഴിയും, കൂടാതെ ഇരുവശത്തും പരസ്പരം TLS സർട്ടിഫിക്കറ്റുകൾ പരിശോധിക്കാൻ കഴിയും*. ഇത് സേവനങ്ങൾക്കിടയിൽ എൻക്രിപ്ഷൻ മാത്രമല്ല, സേവനങ്ങൾ തിരിച്ചറിയുന്നതിനുള്ള ഒരു ക്രിപ്റ്റോഗ്രാഫിക്കലി സുരക്ഷിതമായ മാർഗവും നൽകുന്നു: ഫൂയ്ക്കും ബാറിനും അവർ പറയുന്നവരാണെന്ന് "തെളിയിക്കാൻ" കഴിയും.

* "ഒരു സുഹൃത്തിന്റെ സുഹൃത്ത്" എന്നതിനർത്ഥം ക്ലയന്റിൻറെ സർട്ടിഫിക്കറ്റും പരിശോധിച്ചു എന്നാണ് (മ്യൂച്വൽ TLS). "ക്ലാസിക്" TLS-ൽ, ഉദാഹരണത്തിന്, ഒരു ബ്രൗസറിനും സെർവറിനും ഇടയിൽ, ഒരു വശത്തിന്റെ (സെർവർ) സർട്ടിഫിക്കറ്റ് സാധാരണയായി പരിശോധിച്ചുറപ്പിക്കപ്പെടുന്നു.

അവ പ്രവർത്തിക്കുന്നത് അഭ്യർത്ഥനയിലോ കണക്ഷൻ തലത്തിലോ ആകട്ടെ, എല്ലാ സേവന മെഷ് സവിശേഷതകളും ഉണ്ടെന്ന് ഊന്നിപ്പറയേണ്ടത് പ്രധാനമാണ് പ്രവർത്തനക്ഷമമായ സ്വഭാവം. ഒരു JSON ശകലത്തിലേക്ക് ഫീൽഡുകൾ ചേർക്കുന്നതോ പ്രോട്ടോബഫിൽ മാറ്റങ്ങൾ വരുത്തുന്നതോ പോലുള്ള പേലോഡിന്റെ സെമാന്റിക്‌സ് രൂപാന്തരപ്പെടുത്താൻ Linkerd-ന് കഴിയുന്നില്ല. ESB, മിഡിൽവെയർ എന്നിവയെക്കുറിച്ച് സംസാരിക്കുമ്പോൾ ഈ പ്രധാന സവിശേഷതയെക്കുറിച്ച് ഞങ്ങൾ പിന്നീട് സംസാരിക്കും.

സേവന മെഷ് വാഗ്ദാനം ചെയ്യുന്ന ഫീച്ചറുകളുടെ കൂട്ടമാണിത്. ചോദ്യം ഉയർന്നുവരുന്നു: എന്തുകൊണ്ടാണ് അവ നേരിട്ട് ആപ്ലിക്കേഷനിൽ നടപ്പിലാക്കാത്തത്? പിന്നെ എന്തിനാണ് ഒരു പ്രോക്‌സിയിൽ കുഴപ്പമുണ്ടാക്കുന്നത്?

എന്തുകൊണ്ടാണ് ഒരു സേവന മെഷ് ഒരു നല്ല ആശയം

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

ഈ നിർദ്ദേശം നമുക്ക് വിശകലനം ചെയ്യാം.

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

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

«മുഴുവൻ സ്റ്റാക്കിനും യൂണിഫോം" ഒരു സർവീസ് മെഷ് നൽകുന്ന പ്രവർത്തനം കേവലം ദൗത്യം നിർണായകമല്ല. അവർ ഏത് ഭാഷയിലാണ് എഴുതിയിരിക്കുന്നത്, ഏത് ചട്ടക്കൂട് ഉപയോഗിക്കുന്നു, ആരാണ് അവ എഴുതിയത്, എങ്ങനെ വിന്യസിച്ചു, അവയുടെ വികസനത്തിന്റെയും ഉപയോഗത്തിന്റെയും മറ്റെല്ലാ സൂക്ഷ്മതകളും പരിഗണിക്കാതെ തന്നെ, ആപ്ലിക്കേഷനിലെ എല്ലാ സേവനങ്ങൾക്കും അവ ബാധകമാണ്.

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

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

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

സേവന മെഷ് ആരെയാണ് സഹായിക്കുന്നത്?

ഒരു സാങ്കേതിക വിദ്യ ആവാസവ്യവസ്ഥയുടെ ഒരു പ്രധാന ഭാഗമാകണമെങ്കിൽ അത് അസൗകര്യം പോലെയാണെങ്കിലും അത് ജനങ്ങൾ അംഗീകരിക്കണം. അപ്പോൾ ഒരു സേവന മെഷിൽ ആർക്കാണ് താൽപ്പര്യമുള്ളത്? അതിന്റെ ഉപയോഗത്തിൽ നിന്ന് ആർക്കാണ് പ്രയോജനം?

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

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

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

പ്ലാറ്റ്‌ഫോമുകളുടെയും സേവനങ്ങളുടെയും ഉടമകൾ തമ്മിലുള്ള അത്തരമൊരു വിഭജനത്തിന്റെ സംഘടനാ മൂല്യം അമിതമായി കണക്കാക്കാനാവില്ല. അവൾ സംഭാവന ചെയ്യുമെന്ന് ഞാൻ കരുതുന്നു പ്രധാനം സേവന മെഷിന്റെ മൂല്യത്തിലേക്കുള്ള സംഭാവന.

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

ചുരുക്കത്തിൽ, ഒരു സേവന മെഷ് ഒരു പരിഹാരമാണ്, സാങ്കേതികമായ ഒന്നല്ല, പക്ഷേ സാമൂഹിക-സാങ്കേതിക പ്രശ്നങ്ങൾ. (നന്ദി സിനി ശ്രീധരൻ ഈ പദം അവതരിപ്പിക്കുന്നതിന്.

സർവീസ് മെഷ് എന്റെ എല്ലാ പ്രശ്നങ്ങളും പരിഹരിക്കുമോ?

അതെ. ഞാൻ അർത്ഥമാക്കുന്നത്, ഇല്ല!

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

സേവന മെഷ് നൽകുന്ന ഈ മേഖലകളിലെ ഫീച്ചറുകളുടെ ഒരു ഉപവിഭാഗം ബന്ധപ്പെട്ടിരിക്കുന്നു പ്ലാറ്റ്ഫോം സവിശേഷതകൾ. ഇതിലൂടെ ഞാൻ ഉദ്ദേശിക്കുന്നത് ഇനിപ്പറയുന്ന പ്രവർത്തനങ്ങൾ:

1. ബിസിനസ്സ് യുക്തിയിൽ നിന്ന് സ്വതന്ത്രമാണ്. ഫൂവിനും ബാറിനും ഇടയിൽ കോൾ ഹിസ്റ്റോഗ്രാമുകൾ നിർമ്മിക്കുന്ന രീതി പൂർണ്ണമായും സ്വതന്ത്രമാണ് എന്തുകൊണ്ട് ഫൂ ബാറിനെ വിളിക്കുന്നു.
2. ശരിയായി നടപ്പിലാക്കാൻ ബുദ്ധിമുട്ട്. Linkerd-ൽ, വീണ്ടും ശ്രമങ്ങൾ ബജറ്റുകൾ പോലെയുള്ള എല്ലാത്തരം ഫാൻസി സ്റ്റഫുകളും ഉപയോഗിച്ച് പാരാമീറ്റർ ചെയ്തിരിക്കുന്നു. (ബജറ്റുകൾ വീണ്ടും ശ്രമിക്കുക), കാരണം അത്തരം കാര്യങ്ങൾ നടപ്പിലാക്കുന്നതിനുള്ള ലളിതമായ സമീപനം തീർച്ചയായും "അഭ്യർത്ഥനകളുടെ ഹിമപാതം" എന്ന് വിളിക്കപ്പെടുന്നതിന്റെ ആവിർഭാവത്തിലേക്ക് നയിക്കും. (കൊടുങ്കാറ്റ് വീണ്ടും ശ്രമിക്കുക) ഡിസ്ട്രിബ്യൂട്ടഡ് സിസ്റ്റങ്ങളുടെ പ്രത്യേക പ്രശ്നങ്ങളും.
3. സ്ഥിരമായി പ്രയോഗിക്കുമ്പോൾ ഏറ്റവും ഫലപ്രദമാണ്. എല്ലായിടത്തും പ്രയോഗിച്ചാൽ മാത്രമേ TLS മെക്കാനിസം അർത്ഥമാക്കൂ.

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

സേവന മെഷ് കഴിവുകളുടെ ഉദാഹരണങ്ങൾ

ചുരുക്കത്തിൽ, ഒരു സേവന മെഷ് എന്നത് വിശ്വാസ്യതയ്‌ക്കോ നിരീക്ഷണക്ഷമതയ്‌ക്കോ സുരക്ഷയ്‌ക്കോ ഉള്ള പൂർണ്ണമായ പരിഹാരമല്ല. ഈ മേഖലകളുടെ വ്യാപ്തി, സേവന ഉടമകൾ, Ops / SRE ടീമുകൾ, മറ്റ് കമ്പനി പങ്കാളികൾ എന്നിവരുടെ നിർബന്ധിത പങ്കാളിത്തത്തെ സൂചിപ്പിക്കുന്നു. ഈ ഓരോ മേഖലയ്ക്കും പ്ലാറ്റ്‌ഫോം തലത്തിൽ സേവന മെഷ് ഒരു "സ്ലൈസ്" മാത്രമേ നൽകുന്നുള്ളൂ.

എന്തുകൊണ്ടാണ് സേവന മെഷ് ഇപ്പോൾ ജനപ്രിയമായത്?

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

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

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

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

അങ്ങനെ, പത്ത് വർഷം മുമ്പ് മൈക്രോസർവീസുകൾ മാത്രമല്ല, ഇന്ന് സർവീസ് മെഷ് പരിഹരിക്കുന്ന അതേ പ്രശ്നങ്ങൾ പരിഹരിക്കുന്ന പ്രത്യേക പ്രോട്ടോ-സർവീസ്-മെഷ് ലൈബ്രറികളും ഉണ്ടായിരുന്നു. എന്നിരുന്നാലും, സേവന മെഷ് തന്നെ അന്ന് നിലവിലില്ല. അവൾ പ്രത്യക്ഷപ്പെടുന്നതിന് മുമ്പ് മറ്റൊരു ഷിഫ്റ്റ് ഉണ്ടായിരിക്കണം.

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

നമുക്ക് വർത്തമാനകാലത്തിലേക്ക് പോകാം. മൈക്രോസർവീസുകളുടെയും ഡെവലപ്പർമാരുടെയും അനുപാതം 5:1 (അല്ലെങ്കിൽ പോലും.) ഉള്ള സ്റ്റാർട്ടപ്പുകൾ ഇന്ന് ഉണ്ട് 10:1), കൂടാതെ, അവർ അവരെ വിജയകരമായി നേരിടുന്നു! 5 ആളുകളുടെ ഒരു സ്റ്റാർട്ടപ്പിന് 50 മൈക്രോ സർവീസുകൾ ബുദ്ധിമുട്ടില്ലാതെ പ്രവർത്തിപ്പിക്കാൻ കഴിയുമെങ്കിൽ, അവ നടപ്പിലാക്കുന്നതിനുള്ള ചിലവ് എന്തെങ്കിലും വ്യക്തമായി കുറച്ചു.

മോൺസോയിലെ 1500 മൈക്രോ സർവീസുകൾ; ഓരോ വരിയും ട്രാഫിക് അനുവദിക്കുന്ന ഒരു നിശ്ചിത നെറ്റ്‌വർക്ക് നിയമമാണ്

മൈക്രോസർവീസുകളുടെ പ്രവർത്തനച്ചെലവിലെ നാടകീയമായ കുറവ് ഒരൊറ്റ പ്രക്രിയയുടെ ഫലമാണ്: കണ്ടെയ്നറുകളുടെ വർദ്ധിച്ചുവരുന്ന ജനപ്രീതി и ഓർക്കസ്ട്രേറ്റർമാർ. സേവന മെഷിന്റെ ആവിർഭാവത്തിന് എന്ത് സംഭാവന നൽകി എന്ന ചോദ്യത്തിനുള്ള ആഴത്തിലുള്ള ഉത്തരമാണിത്. ഇതേ സാങ്കേതികവിദ്യ സേവന മെഷുകളെയും മൈക്രോ സർവീസുകളെയും ആകർഷകമാക്കി: കുബർനെറ്റസും ഡോക്കറും.

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

കുബർനെറ്റസ് എല്ലാം അടുത്ത ഘട്ടത്തിലേക്ക് കൊണ്ടുപോകുന്നു. ഇപ്പോൾ ഒരു കൂട്ടം "എക്സിക്യൂട്ടബിൾ കാര്യങ്ങൾ" ഉള്ളതിനാൽ അവ പ്രവർത്തിപ്പിക്കുന്നതിന് നിരവധി മെഷീനുകൾ ഉണ്ട്, അവ പരസ്പരം പൊരുത്തപ്പെടുത്താൻ കഴിയുന്ന ഒരു ഉപകരണത്തിന്റെ ആവശ്യകതയുണ്ട്. വിശാലമായ അർത്ഥത്തിൽ, നിങ്ങൾ Kubernetes-ന് നിരവധി കണ്ടെയ്‌നറുകളും നിരവധി മെഷീനുകളും നൽകുന്നു, അത് അവ പരസ്പരം പൊരുത്തപ്പെടുന്നു (തീർച്ചയായും, ഇത് ചലനാത്മകവും നിരന്തരം മാറിക്കൊണ്ടിരിക്കുന്നതുമായ ഒരു പ്രക്രിയയാണ്: പുതിയ കണ്ടെയ്‌നറുകൾ സിസ്റ്റത്തിന് ചുറ്റും നീങ്ങുന്നു, മെഷീനുകൾ ആരംഭിക്കുകയും നിർത്തുകയും ചെയ്യുന്നു. എന്നിരുന്നാലും, കുബെർനെറ്റസ് ഇതെല്ലാം കണക്കിലെടുക്കുന്നു ).

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

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

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

എന്തുകൊണ്ടാണ് സേവന മെഷിനെക്കുറിച്ച് ഇത്രയധികം സംസാരം?

പ്രതിരോധം: ഈ വിഭാഗത്തിൽ, ഞാൻ എല്ലാത്തരം അനുമാനങ്ങളും അനുമാനങ്ങളും കെട്ടിച്ചമക്കലുകളും ആന്തരിക വിവരങ്ങളും അവലംബിക്കുന്നു.

"സർവീസ് മെഷ്" എന്നതിനായി തിരയുന്നത് റീസൈക്കിൾ ചെയ്‌തതും കുറഞ്ഞ കലോറി ഉള്ളടക്കവും വിചിത്രമായ പ്രോജക്‌ടുകളും ഒരു എക്കോ ചേമ്പറിന് യോഗ്യമായ ഒരു കലിഡോസ്‌കോപ്പും കണ്ടെത്തും. ഏതൊരു ട്രെൻഡി പുതിയ സാങ്കേതികവിദ്യയ്ക്കും ഇത് ഉണ്ട്, എന്നാൽ സേവന മെഷിന്റെ കാര്യത്തിൽ, പ്രശ്നം പ്രത്യേകിച്ച് നിശിതമാണ്. എന്തുകൊണ്ട്?

ശരി, ഇത് ഭാഗികമായി എന്റെ തെറ്റാണ്. ഇതുപോലുള്ള എണ്ണമറ്റ ബ്ലോഗ് പോസ്റ്റുകളിലൂടെയും ലേഖനങ്ങളിലൂടെയും എല്ലാ അവസരങ്ങളിലും Linkerd ഉം സർവീസ് മെഷും പ്രൊമോട്ട് ചെയ്യാൻ ഞാൻ പരമാവധി ശ്രമിച്ചിട്ടുണ്ട്. പക്ഷെ ഞാൻ അത്ര ശക്തനല്ല. ഈ ചോദ്യത്തിന് ശരിക്കും ഉത്തരം നൽകാൻ, പൊതുവായ സാഹചര്യത്തെക്കുറിച്ച് കുറച്ച് സംസാരിക്കേണ്ടതുണ്ട്. ഒരു പ്രോജക്റ്റ് പരാമർശിക്കാതെ അതിനെക്കുറിച്ച് സംസാരിക്കുന്നത് അസാധ്യമാണ്: ഇസ്തോ Google, IBM, Lyft എന്നിവർ സംയുക്തമായി വികസിപ്പിച്ചെടുത്ത ഒരു ഓപ്പൺ സോഴ്‌സ് സേവന മെഷ് ആണ്.

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

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

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

എന്തുകൊണ്ടാണ് ഇത് സംഭവിച്ചത് എന്നതിനെക്കുറിച്ചുള്ള എന്റെ സിദ്ധാന്തങ്ങൾ മാറ്റിനിർത്തിയാൽ, സേവന മെഷിനെ ചുറ്റിപ്പറ്റിയുള്ള ഓഫ്-സ്കെയിൽ ഹൈപ്പ് ഗൂഗിളിന്റെ പങ്കാളിത്തം മൂലമാണെന്ന് ഞാൻ വിശ്വസിക്കുന്നു. അതായത്, ഇനിപ്പറയുന്ന മൂന്ന് ഘടകങ്ങളുടെ സംയോജനം:

1. ഗൂഗിളിന്റെ ഇസ്തിയോയുടെ ഒബ്സസീവ് പ്രൊമോഷൻ;
2. പദ്ധതിയോടുള്ള ഉചിതമായ വിസമ്മതവും വിമർശനാത്മക മനോഭാവവും;
3. കുബെർനെറ്റസിന്റെ ജനപ്രീതിയിലെ സമീപകാല ഉൽക്കാശില വർദ്ധനവ്, അതിന്റെ ഓർമ്മകൾ ഇപ്പോഴും പുതുമയുള്ളതാണ്.

ഈ ഘടകങ്ങളെല്ലാം ചേർന്ന്, ഒരുതരം ലഹരി, അനോക്‌സിക് പരിതസ്ഥിതിയിൽ കൂടിച്ചേരുന്നു, അതിൽ യുക്തിസഹമായ വിധിന്യായത്തിനുള്ള കഴിവ് ക്ഷയിക്കുകയും വിചിത്രമായ വൈവിധ്യങ്ങൾ മാത്രം അവശേഷിപ്പിക്കുകയും ചെയ്യുന്നു. തുലിപ് മാനിയ.

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

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

അതുവരെ നമ്മൾ എല്ലാവരും ക്ഷമയോടെ കാത്തിരിക്കണം.

ഒരു എളിമയുള്ള സോഫ്റ്റ്‌വെയർ എഞ്ചിനീയറായ എനിക്ക് സർവീസ് മെഷ് ഉപയോഗപ്രദമാകുമോ?

ഈ ചോദ്യത്തിന് ഉത്തരം നൽകാൻ ഇനിപ്പറയുന്ന ചോദ്യാവലി സഹായിക്കും:

ബിസിനസ്സ് ലോജിക് നടപ്പിലാക്കുന്നതിൽ നിങ്ങൾ പ്രത്യേകമായി ഇടപെടുന്നുണ്ടോ? ഈ സാഹചര്യത്തിൽ, സേവന മെഷ് നിങ്ങൾക്ക് ഉപയോഗപ്രദമാകില്ല. അതായത്, തീർച്ചയായും, നിങ്ങൾക്ക് അതിൽ താൽപ്പര്യമുണ്ടാകാം, പക്ഷേ സേവന മെഷ് നിങ്ങളുടെ പരിതസ്ഥിതിയിൽ നേരിട്ട് ഒന്നും ബാധിക്കരുത്. നിങ്ങൾക്ക് പ്രതിഫലം ലഭിക്കുന്നതിന് വേണ്ടി പ്രവർത്തിക്കുന്നത് തുടരുക.

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

Kubernetes ഉപയോഗിക്കാത്തതും എന്നാൽ മൈക്രോ സർവീസുകൾ ഉപയോഗിക്കുന്നതുമായ ഒരു കമ്പനിക്ക് വേണ്ടി നിങ്ങൾ ഒരു പ്ലാറ്റ്ഫോം പ്രവർത്തിപ്പിക്കുന്നുണ്ടോ? ഈ സാഹചര്യത്തിൽ, സേവന മെഷ് നിങ്ങൾക്ക് ഉപയോഗപ്രദമാകും, പക്ഷേ അതിന്റെ ഉപയോഗം നിസ്സാരമല്ല. തീർച്ചയായും നിങ്ങൾക്ക് കഴിയും അനുകരിക്കുക ഒരു കൂട്ടം പ്രോക്‌സികൾ ഹോസ്റ്റുചെയ്യുന്നതിലൂടെ സേവന മെഷ്, എന്നാൽ കുബർനെറ്റസിന്റെ ഒരു പ്രധാന നേട്ടം കൃത്യമായി വിന്യാസ മാതൃകയാണ്: ഈ പ്രോക്സികൾ സ്വമേധയാ പരിപാലിക്കുന്നതിന് കൂടുതൽ സമയവും പരിശ്രമവും ചെലവും ആവശ്യമാണ്.

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

തീരുമാനം

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

നിങ്ങൾ ലിങ്കർഡ് പരീക്ഷിക്കണമെന്ന് ഞാൻ ആഗ്രഹിക്കുന്നു - ഇത് ഒരു കുബർനെറ്റസ് ക്ലസ്റ്ററിൽ ഇൻസ്റ്റാൾ ചെയ്യുന്നു (അല്ലെങ്കിൽ ഒരു ലാപ്‌ടോപ്പിൽ മിനിക്യൂബ് പോലും) ഏകദേശം 60 സെക്കൻഡ് എടുക്കുംഞാൻ എന്താണ് സംസാരിക്കുന്നതെന്ന് നിങ്ങൾക്ക് സ്വയം കാണാനാകും.

പതിവുചോദ്യങ്ങൾ

- ഞാൻ സേവന മെഷ് അവഗണിക്കുകയാണെങ്കിൽ, അത് അപ്രത്യക്ഷമാകുമോ?
- ഞാൻ നിങ്ങളെ നിരാശപ്പെടുത്തണം: സേവന മെഷ് വളരെക്കാലമായി ഞങ്ങളോടൊപ്പമുണ്ട്.

— എന്നാൽ ഒരു സേവന മെഷ് ഉപയോഗിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നില്ല!
- ശരി, അത് ആവശ്യമില്ല! മുകളിലുള്ള എന്റെ ചോദ്യാവലി വായിക്കുക, അതിന്റെ അടിസ്ഥാനകാര്യങ്ങൾ നിങ്ങൾ സ്വയം പരിചയപ്പെടണമോ എന്ന്.

— പുതിയ സോസ് ഉള്ള നല്ല പഴയ ESB/മിഡിൽവെയർ അല്ലേ?
- സെമാന്റിക് അല്ല, പ്രവർത്തന ലോജിക്കാണ് സർവീസ് മെഷ് കൈകാര്യം ചെയ്യുന്നത്. ഇതായിരുന്നു പ്രധാന പോരായ്മ എന്റർപ്രൈസ് സർവീസ് ബസ് (ഇ.എസ്.ബി). ഈ വേർതിരിവ് നിലനിർത്തുന്നത് സേവന മെഷിനെ അതേ വിധി ഒഴിവാക്കാൻ സഹായിക്കുന്നു.

- API ഗേറ്റ്‌വേകളിൽ നിന്ന് ഒരു സേവന മെഷ് എങ്ങനെ വ്യത്യാസപ്പെട്ടിരിക്കുന്നു?
ഈ വിഷയത്തിൽ ഒരു ദശലക്ഷം ലേഖനങ്ങളുണ്ട്. വെറും ഗൂഗിൾ.

- ദൂതൻ ഒരു സേവന മെഷ് ആണോ?
- ഇല്ല, എൻവോയ് ഒരു സേവന മെഷ് അല്ല, ഇതൊരു പ്രോക്സി സെർവറാണ്. ഒരു സേവന മെഷ് ഓർഗനൈസുചെയ്യാൻ ഇത് ഉപയോഗിക്കാം (കൂടുതൽ കൂടുതൽ - ഇത് ഒരു പൊതു ആവശ്യ പ്രോക്സിയാണ്). എന്നാൽ സ്വയം, ഇത് ഒരു സേവന മെഷ് അല്ല.

- നെറ്റ്‌വർക്ക് സർവീസ് മെഷ് - ഇതൊരു സർവീസ് മെഷ് ആണോ?
- ഇല്ല. പേര് ഉണ്ടായിരുന്നിട്ടും, ഇതൊരു സേവന മെഷ് അല്ല (വിപണനത്തിന്റെ അത്ഭുതങ്ങൾ നിങ്ങൾ എങ്ങനെ ഇഷ്ടപ്പെടുന്നു?).

- സന്ദേശ ക്യൂവിനെ അടിസ്ഥാനമാക്കിയുള്ള എന്റെ റിയാക്ടീവ് അസിൻക്രണസ് സിസ്റ്റത്തെ സർവീസ് മെഷ് സഹായിക്കുമോ?
- ഇല്ല, സേവന മെഷ് നിങ്ങളെ സഹായിക്കില്ല.

— ഞാൻ ഏത് സേവന മെഷ് ഉപയോഗിക്കണം?
- ലിങ്കർഡ്, ബുദ്ധിയില്ല.

- ലേഖനം മോശമാണ്! / രചയിതാവ് - സോപ്പിൽ!
— നിങ്ങളുടെ എല്ലാ ചങ്ങാതിമാരുമായും ഇതിലേക്കുള്ള ലിങ്ക് പങ്കിടുക, അതുവഴി അവർക്ക് ഇത് ബോധ്യപ്പെടാൻ കഴിയും!

അംഗീകാരങ്ങൾ

തലക്കെട്ടിൽ നിന്ന് നിങ്ങൾ ഊഹിക്കുന്നതുപോലെ, ഈ ലേഖനം ജെയ് ക്രെപ്സിന്റെ അതിശയകരമായ ഗ്രന്ഥത്തിൽ നിന്ന് പ്രചോദനം ഉൾക്കൊണ്ടതാണ് "ലോഗ്: തത്സമയ ഡാറ്റയുടെ ഏകീകൃത അമൂർത്തീകരണത്തെക്കുറിച്ച് ഓരോ സോഫ്റ്റ്‌വെയർ എഞ്ചിനീയറും അറിഞ്ഞിരിക്കേണ്ട കാര്യങ്ങൾ". പത്ത് വർഷം മുമ്പ് ലിങ്ക്ഡ് ഇൻ എന്ന ചാനലിൽ ഒരു അഭിമുഖം നടത്തുന്നതിനിടയിൽ ഞാൻ ജയയെ കണ്ടുമുട്ടി, അന്നുമുതൽ അദ്ദേഹം എനിക്ക് ഒരു പ്രചോദനമാണ്.

"ലിങ്കർഡ് ഡെവലപ്പർ" എന്ന് സ്വയം വിളിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു, ഒരു പ്രോജക്റ്റിലെ README.md ഫയൽ പരിപാലിക്കുന്ന ആളാണ് ഞാൻ എന്നതാണ് യാഥാർത്ഥ്യം. ഇന്ന് Linkerd-ൽ പ്രവർത്തിക്കുന്നു വളരെ, വളരെ, വളരെ много ആളുകൾ, ഒപ്പം സംഭാവന ചെയ്യുന്നവരുടെയും ഉപയോക്താക്കളുടെയും അതിശയകരമായ കമ്മ്യൂണിറ്റി ഇല്ലാതെ ഈ പ്രോജക്റ്റ് സാധ്യമാകുമായിരുന്നില്ല.

അവസാനമായി, ലിങ്കർഡിന്റെ സ്രഷ്ടാവിന് പ്രത്യേക നന്ദി, ഒലിവർ ഗൗൾഡ് (പ്രൈമസ് ഇന്റർ പാരെസ്), എത്രയോ വർഷങ്ങൾക്ക് മുമ്പ് എന്നോടൊപ്പം, സർവീസ് മെഷ് ഉപയോഗിച്ച് ഈ കോലാഹലങ്ങളിലെല്ലാം തലകുനിച്ചു.

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

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

• «എന്താണ് ഒരു സർവീസ് മെഷ്, എന്തുകൊണ്ട് എനിക്ക് ഇത് ആവശ്യമാണ് [മൈക്രോ സർവീസുകളുള്ള ഒരു ക്ലൗഡ് ആപ്ലിക്കേഷന്]?";
• «Traefik 2.0: TCP പിന്തുണയും പുതിയ വെബ് ഇന്റർഫേസും ഉള്ള സർവീസ് മെഷ് അപ്‌ഡേറ്റ്";
• «Maesh - Traefik-ന്റെ രചയിതാക്കളിൽ നിന്നുള്ള കുബർനെറ്റസിനായുള്ള ഒരു പുതിയ ലളിതമായ സേവന മെഷ്";
• «ഇസ്തിയോയ്‌ക്കൊപ്പം മൈക്രോസർവീസുകളിലേക്ക് മടങ്ങുക. ഭാഗം 1";
• «ചാലകം - കുബെർനെറ്റസിനുള്ള ലൈറ്റ്വെയ്റ്റ് സർവീസ് മെഷ്".

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