NDC ലണ്ടൻ സമ്മേളനം. മൈക്രോ സർവീസ് ദുരന്തം തടയുന്നു. ഭാഗം 1

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

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

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

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

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

പ്രാരംഭ രൂപകൽപ്പന വളരെ മനോഹരമായി കാണപ്പെട്ടു, കൂടാതെ ഒരു ടോപ്പ്-ലെവൽ സൈറ്റ് bell.com ഉം വ്യക്തിഗത ആപ്ലിക്കേഷനുകൾക്കായുള്ള നിരവധി ഉപഡൊമെയ്‌നുകളും ഉൾപ്പെടുന്നു: catalog.bell.com, accounts.bell.com, orders.bell.com, ഉൽപ്പന്ന തിരയൽ search.bell. com. ഓരോ ഉപഡൊമെയ്‌നും ASP.Net 1.0 ചട്ടക്കൂടും അതിന്റെ സ്വന്തം ഡാറ്റാബേസുകളും ഉപയോഗിച്ചു, അവയെല്ലാം സിസ്റ്റം ബാക്കെൻഡുമായി സംസാരിച്ചു. എന്നിരുന്നാലും, എല്ലാ ഓർഡറുകളും ഒരു വലിയ മെയിൻഫ്രെയിമിനുള്ളിൽ പ്രോസസ്സ് ചെയ്യുകയും നടപ്പിലാക്കുകയും ചെയ്തു, അതിൽ എല്ലാ മാലിന്യങ്ങളും അവശേഷിച്ചു, എന്നാൽ മുൻഭാഗം വ്യക്തിഗത ആപ്ലിക്കേഷനുകളും പ്രത്യേക ഡാറ്റാബേസുകളുമുള്ള പ്രത്യേക വെബ്‌സൈറ്റുകളായിരുന്നു.

അതിനാൽ സിസ്റ്റത്തിന്റെ രൂപകൽപ്പന ക്രമവും യുക്തിസഹവും ആയി കാണപ്പെട്ടു, എന്നാൽ യഥാർത്ഥ സിസ്റ്റം അടുത്ത സ്ലൈഡിൽ കാണിച്ചിരിക്കുന്നതുപോലെയായിരുന്നു.

എല്ലാ ഘടകങ്ങളും പരസ്പരം കോളുകൾ, ആക്‌സസ് ചെയ്‌ത API-കൾ, ഉൾച്ചേർത്ത മൂന്നാം കക്ഷി dll-കൾ എന്നിവയും മറ്റും. പതിപ്പ് നിയന്ത്രണ സംവിധാനങ്ങൾ മറ്റൊരാളുടെ കോഡ് പിടിച്ചെടുക്കുകയും അത് പ്രോജക്റ്റിനുള്ളിലേക്ക് തള്ളുകയും തുടർന്ന് എല്ലാം തകരുകയും ചെയ്യുന്നത് പലപ്പോഴും സംഭവിക്കാറുണ്ട്. MS SQL സെർവർ 2005 ലിങ്ക് സെർവറുകൾ എന്ന ആശയം ഉപയോഗിച്ചു, ഞാൻ സ്ലൈഡിൽ അമ്പടയാളങ്ങൾ കാണിച്ചില്ലെങ്കിലും, ഓരോ ഡാറ്റാബേസുകളും പരസ്പരം സംസാരിച്ചു, കാരണം നിരവധി ഡാറ്റാബേസുകളിൽ നിന്ന് ലഭിച്ച ഡാറ്റയെ അടിസ്ഥാനമാക്കി പട്ടികകൾ നിർമ്മിക്കുന്നതിൽ തെറ്റൊന്നുമില്ല.

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

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

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

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

സമാനമായ പ്രശ്‌നം എങ്ങനെ പരിഹരിച്ചുവെന്നറിയാൻ മറ്റ് കമ്പനികളെ നോക്കിയാണ് അവർ മികച്ച കാര്യം ചെയ്തത്. ഈ പരിഹാരങ്ങളിലൊന്നാണ് നെറ്റ്ഫ്ലിക്സ് സർവീസ് ആർക്കിടെക്ചർ, അതിൽ API വഴിയും ഒരു ബാഹ്യ ഡാറ്റാബേസ് വഴിയും ബന്ധിപ്പിച്ചിട്ടുള്ള മൈക്രോസർവീസുകൾ അടങ്ങിയിരിക്കുന്നു.

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

അങ്ങനെ, 18 മാസത്തിനുള്ളിൽ, അവർ ഈ അടിസ്ഥാന തത്വങ്ങളെ ചുറ്റിപ്പറ്റിയുള്ള സിസ്റ്റം നിർമ്മിക്കുകയും പ്രീ-പ്രൊഡക്ഷനിലേക്ക് കൊണ്ടുവരികയും ചെയ്തു. വാരാന്ത്യത്തിന് ശേഷം ജോലിയിലേക്ക് മടങ്ങി, ഡവലപ്പർമാർ ഒത്തുചേർന്ന് പുതിയ സിസ്റ്റം കണക്റ്റുചെയ്‌തിരിക്കുന്ന എല്ലാ സെർവറുകളും ഓണാക്കി. 18 മാസത്തെ ജോലി, നൂറുകണക്കിന് ഡെവലപ്പർമാർ, ഏറ്റവും ആധുനികമായ ബെൽ ഹാർഡ്‌വെയർ - പോസിറ്റീവ് ഫലമില്ല! നിരവധി ആളുകളെ ഇത് നിരാശരാക്കിയിട്ടുണ്ട്, കാരണം അവർ ഈ സംവിധാനം അവരുടെ ലാപ്‌ടോപ്പുകളിൽ നിരവധി തവണ പ്രവർത്തിപ്പിച്ചിട്ടുണ്ട്, എല്ലാം ശരിയായിരുന്നു.

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

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

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

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

ഞങ്ങൾ കുറച്ച് കണക്ക് ചെയ്തു. ഓരോ API കോളിനും 150 ms-ൽ കൂടാത്ത SLA-ഉം 99,9% പ്രവർത്തന സമയവും ഉണ്ടായിരുന്നു. ഒരു അഭ്യർത്ഥന 200 വ്യത്യസ്ത കോളുകൾക്ക് കാരണമായി, മികച്ച സാഹചര്യത്തിൽ, പേജ് 200 x 150 ms = 30 സെക്കൻഡിൽ കാണിക്കാം. സ്വാഭാവികമായും, ഇത് നല്ലതായിരുന്നില്ല. 99,9% പ്രവർത്തനസമയത്തെ 200 കൊണ്ട് ഗുണിച്ചാൽ, ഞങ്ങൾക്ക് 0% ലഭ്യത ലഭിച്ചു. ഈ വാസ്തുവിദ്യ തുടക്കം മുതൽ തന്നെ പരാജയത്തിലേക്ക് നയിക്കപ്പെട്ടുവെന്ന് ഇത് മാറുന്നു.

18 മാസത്തെ ജോലിക്ക് ശേഷവും ഈ പ്രശ്നം തിരിച്ചറിയുന്നതിൽ എങ്ങനെയാണ് പരാജയപ്പെട്ടതെന്ന് ഞങ്ങൾ ഡവലപ്പർമാരോട് ചോദിച്ചു? അവർ പ്രവർത്തിപ്പിക്കുന്ന കോഡിന് SLA മാത്രമേ കണക്കാക്കിയിട്ടുള്ളൂ, എന്നാൽ അവരുടെ സേവനം മറ്റൊരു സേവനത്തെ വിളിച്ചാൽ, അവർ അവരുടെ SLA-യിൽ ആ സമയം കണക്കാക്കില്ല. ഒരു പ്രോസസിനുള്ളിൽ സമാരംഭിച്ചതെല്ലാം 150 ms മൂല്യത്തോട് ചേർന്നുനിൽക്കുന്നു, എന്നാൽ മറ്റ് സേവന പ്രക്രിയകളിലേക്കുള്ള പ്രവേശനം മൊത്തം കാലതാമസത്തെ പല മടങ്ങ് വർദ്ധിപ്പിച്ചു. പഠിച്ച ആദ്യ പാഠം ഇതായിരുന്നു: "നിങ്ങളുടെ SLA യുടെ നിയന്ത്രണത്തിലാണോ അതോ SLA നിങ്ങളുടെ നിയന്ത്രണത്തിലാണോ?" ഞങ്ങളുടെ കാര്യത്തിൽ, അത് അവസാനത്തേതായിരുന്നു.

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

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

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

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

ഒരു മോണോലിത്തിൽ നിന്ന് മൈക്രോസർവീസുകളിലേക്ക് മാറാൻ MS എങ്ങനെ ശുപാർശ ചെയ്യുന്നുവെന്ന് ഇനിപ്പറയുന്ന ചിത്രം കാണിക്കുന്നു - ഓരോ പ്രധാന സേവനങ്ങളെയും പ്രത്യേക മൈക്രോസർവീസുകളായി വിഭജിക്കുക. ഈ പദ്ധതി നടപ്പാക്കുന്നതിനിടെയാണ് ബെല്ലിന് പിഴച്ചത്.

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

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

അവരുടെ ആന്തരിക എൻ-ടയർ ഫിസിക്കൽ ലെയർ ഇൻഫ്രാസ്ട്രക്ചർ എടുത്ത് അതിൽ ഡോക്കർ ഒട്ടിക്കുന്നത് പോലെ മൈക്രോസർവീസുകളിലേക്ക് നീങ്ങുന്നത് എളുപ്പമാണെന്ന് അവർ വിശ്വസിച്ചു. പരമ്പരാഗത എൻ-ടയർ ആർക്കിടെക്ചർ എങ്ങനെയുണ്ടെന്ന് നോക്കാം.

ഇതിൽ 4 ലെവലുകൾ അടങ്ങിയിരിക്കുന്നു: യുഐ ഉപയോക്തൃ ഇന്റർഫേസ് ലെവൽ, ബിസിനസ് ലോജിക് ലെവൽ, ഡാറ്റ ആക്‌സസ് ലെവൽ, ഡാറ്റാബേസ്. കൂടുതൽ പുരോഗമനപരമായത് DDD (ഡൊമെയ്ൻ-ഡ്രൈവൻ ഡിസൈൻ), അല്ലെങ്കിൽ സോഫ്റ്റ്‌വെയർ അധിഷ്ഠിത ആർക്കിടെക്ചർ ആണ്, ഇവിടെ രണ്ട് മധ്യ തലങ്ങൾ ഡൊമെയ്ൻ ഒബ്ജക്റ്റുകളും ഒരു ശേഖരവുമാണ്.

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

മാറ്റത്തിന്റെ ഈ മേഖലകളുടെ അതിരുകൾ ബിസിനസ്സ് ലോജിക് ലെവലിനെ മാത്രമല്ല, ഡാറ്റാബേസിലേക്കും വ്യാപിപ്പിക്കുന്നു എന്നതാണ് ഈ സ്കീമിന്റെ പ്രത്യേകത.

ഒരു സേവനം എന്നതിന്റെ അർത്ഥമെന്താണെന്ന് നോക്കാം. ഒരു സേവന നിർവചനത്തിന് 6 സ്വഭാവ സവിശേഷതകളുണ്ട് - ഇത് സോഫ്റ്റ്‌വെയറാണ്:

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

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

ഇപ്പോൾ മൈക്രോസർവീസുകളുടെ നിർവചനം നോക്കാം:

• ഒരു മൈക്രോ സർവീസ് വലുപ്പത്തിൽ ചെറുതും ഒരു പ്രത്യേക പ്രശ്നം പരിഹരിക്കാൻ രൂപകൽപ്പന ചെയ്തതുമാണ്;
• മൈക്രോസർവീസ് സ്വയംഭരണാധികാരമുള്ളതാണ്;
• ഒരു മൈക്രോസർവീസ് ആർക്കിടെക്ചർ സൃഷ്ടിക്കുമ്പോൾ, ടൗൺ പ്ലാനിംഗ് മെറ്റാഫോർ ഉപയോഗിക്കുന്നു. സാം ന്യൂമാന്റെ ബിൽഡിംഗ് മൈക്രോ സർവീസസ് എന്ന പുസ്തകത്തിൽ നിന്നുള്ള നിർവചനമാണിത്.

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

ലളിതമായി പറഞ്ഞാൽ, ഒരു പ്രത്യേക മൊഡ്യൂൾ ഉപയോഗിക്കാനാകുന്ന വ്യാപ്തിയെ ഒരു ബൗണ്ടഡ് കോൺടെക്സ്റ്റ് സൂചിപ്പിക്കുന്നു. ഈ സന്ദർഭത്തിനുള്ളിൽ, നിങ്ങളുടെ ബിസിനസ്സ് ഡൊമെയ്നിൽ കാണാൻ കഴിയുന്ന ഒരു യുക്തിസഹമായ ഏകീകൃത മാതൃകയുണ്ട്. ഓർഡറുകളിൽ ഏർപ്പെട്ടിരിക്കുന്ന ഉദ്യോഗസ്ഥരോട് "ആരാണ് ഒരു ക്ലയന്റ്" എന്ന് നിങ്ങൾ ചോദിച്ചാൽ, നിങ്ങൾക്ക് ഒരു നിർവചനം ലഭിക്കും, നിങ്ങൾ വിൽപ്പനയിൽ ഏർപ്പെട്ടിരിക്കുന്നവരോട് ചോദിച്ചാൽ, നിങ്ങൾക്ക് മറ്റൊന്ന് ലഭിക്കും, കൂടാതെ പ്രകടനം നടത്തുന്നവർ നിങ്ങൾക്ക് മൂന്നാമത്തെ നിർവചനം നൽകും.

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

ഒരു മൈക്രോസർവീസിന്റെ അടുത്ത നിർവചനം, ഏതെങ്കിലും തരത്തിലുള്ള ആന്തരിക പ്രവർത്തനങ്ങളുടെ എൻക്യാപ്സുലേഷൻ ആണ്, ഇത് പരിസ്ഥിതിയിലേക്ക് ജോലി പ്രക്രിയയുടെ ഘടകങ്ങളുടെ "ചോർച്ച" തടയുന്നു. അടുത്തതായി വരുന്നത് "ബാഹ്യ ഇടപെടലുകൾ അല്ലെങ്കിൽ ബാഹ്യ ആശയവിനിമയങ്ങൾക്കായുള്ള വ്യക്തമായ കരാറുകളുടെ നിർവചനം", ഇത് SLA-കളിൽ നിന്ന് മടങ്ങിവരുന്ന കരാറുകളുടെ ആശയം പ്രതിനിധീകരിക്കുന്നു. അവസാന നിർവചനം ഒരു സെല്ലിന്റെ അല്ലെങ്കിൽ സെല്ലിന്റെ രൂപകമാണ്, അതിനർത്ഥം ഒരു മൈക്രോ സർവീസിനുള്ളിലെ ഒരു കൂട്ടം പ്രവർത്തനങ്ങളുടെ പൂർണ്ണമായ എൻക്യാപ്‌സുലേഷനും പുറം ലോകവുമായുള്ള ആശയവിനിമയത്തിനുള്ള റിസപ്റ്ററുകളുടെ സാന്നിധ്യവുമാണ്.

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

22:30 മിനിറ്റ്

ഉടൻ തന്നെ തുടരും...

ഒരു ചെറിയ പരസ്യം

ഞങ്ങളോടൊപ്പം താമസിച്ചതിന് നന്ദി. ഞങ്ങളുടെ ലേഖനങ്ങൾ നിങ്ങൾക്ക് ഇഷ്ടമാണോ? കൂടുതൽ രസകരമായ ഉള്ളടക്കം കാണാൻ ആഗ്രഹിക്കുന്നുണ്ടോ? ഒരു ഓർഡർ നൽകി അല്ലെങ്കിൽ സുഹൃത്തുക്കൾക്ക് ശുപാർശ ചെയ്തുകൊണ്ട് ഞങ്ങളെ പിന്തുണയ്ക്കുക, $4.99 മുതൽ ഡെവലപ്പർമാർക്കുള്ള ക്ലൗഡ് VPS, എൻട്രി ലെവൽ സെർവറുകളുടെ ഒരു അദ്വിതീയ അനലോഗ്, നിങ്ങൾക്കായി ഞങ്ങൾ കണ്ടുപിടിച്ചതാണ്: VPS (KVM) E5-2697 v3 (6 കോറുകൾ) 10GB DDR4 480GB SSD 1Gbps-നെക്കുറിച്ചുള്ള മുഴുവൻ സത്യവും $19 മുതൽ അല്ലെങ്കിൽ എങ്ങനെ ഒരു സെർവർ പങ്കിടാം? (RAID1, RAID10 എന്നിവയ്‌ക്കൊപ്പം 24 കോറുകൾ വരെയും 40GB DDR4 വരെയും ലഭ്യമാണ്).

ആംസ്റ്റർഡാമിലെ Equinix Tier IV ഡാറ്റാ സെന്ററിൽ Dell R730xd 2 മടങ്ങ് വിലക്കുറവാണോ? ഇവിടെ മാത്രം 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV $199 മുതൽ നെതർലാൻഡിൽ! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 മുതൽ! കുറിച്ച് വായിക്കുക ഇൻഫ്രാസ്ട്രക്ചർ കോർപ്പറേഷൻ എങ്ങനെ നിർമ്മിക്കാം. ഒരു പൈസയ്ക്ക് 730 യൂറോ വിലയുള്ള Dell R5xd E2650-4 v9000 സെർവറുകൾ ഉപയോഗിക്കുന്ന ക്ലാസ്?

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