ഹേ ഹബർ!

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

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

തിരശ്ചീന സ്കെയിലിംഗ്

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

ഉദാഹരണത്തിന്, ഞാൻ അമൂർത്തമായ ക്ലൗഡ് ഫയൽ സംഭരണം എടുക്കും, അതായത്, OwnCloud, OneDrive മുതലായവയുടെ ചില അനലോഗ്.

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

സമീപനങ്ങൾ തമ്മിലുള്ള വ്യത്യാസം: ലംബ സ്കെയിലിംഗിൽ, നോഡുകളുടെ ശക്തി വർദ്ധിപ്പിക്കാൻ ഞങ്ങൾ തയ്യാറാണ്, തിരശ്ചീന സ്കെയിലിംഗിൽ, ലോഡ് വിതരണം ചെയ്യുന്നതിന് പുതിയ നോഡുകൾ ചേർക്കാൻ ഞങ്ങൾ തയ്യാറാണ്.

CQRS

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

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

1. ക്ലയൻ്റ് സെർവറിലേക്ക് ഒരു അഭ്യർത്ഥന അയച്ചു.
2. സെർവർ ഒരു നീണ്ട പ്രോസസ്സിംഗ് സമയം ആരംഭിച്ചു.
3. ഫലവുമായി സെർവർ ക്ലയൻ്റിനോട് പ്രതികരിച്ചു.

പോയിൻ്റ് 2-ൽ കണക്ഷൻ തകരാറിലായതായി സങ്കൽപ്പിക്കുക (അല്ലെങ്കിൽ നെറ്റ്‌വർക്ക് വീണ്ടും കണക്‌റ്റ് ചെയ്‌തു, അല്ലെങ്കിൽ ഉപയോക്താവ് മറ്റൊരു പേജിലേക്ക് പോയി, കണക്ഷൻ തകർക്കുന്നു). ഈ സാഹചര്യത്തിൽ, കൃത്യമായി പ്രോസസ്സ് ചെയ്തതിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ ഉപയോഗിച്ച് ഉപയോക്താവിന് ഒരു പ്രതികരണം അയയ്ക്കുന്നത് സെർവറിന് ബുദ്ധിമുട്ടായിരിക്കും. CQRS ഉപയോഗിച്ച്, ക്രമം അല്പം വ്യത്യസ്തമായിരിക്കും:

1. ക്ലയൻ്റ് അപ്‌ഡേറ്റുകൾ സബ്‌സ്‌ക്രൈബുചെയ്‌തു.
2. ക്ലയൻ്റ് സെർവറിലേക്ക് ഒരു അഭ്യർത്ഥന അയച്ചു.
3. "അഭ്യർത്ഥന സ്വീകരിച്ചു" എന്ന് സെർവർ പ്രതികരിച്ചു.
4. "1" പോയിൻ്റിൽ നിന്നുള്ള ചാനലിലൂടെ സെർവർ ഫലവുമായി പ്രതികരിച്ചു.

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

കൗതുകകരമെന്നു പറയട്ടെ, ഇൻകമിംഗ് സന്ദേശങ്ങൾ പ്രോസസ്സ് ചെയ്യുന്നതിനുള്ള കോഡ്, ക്ലയൻ്റ് തന്നെ സ്വാധീനിച്ച ഇവൻ്റുകൾക്കും മറ്റ് ക്ലയൻ്റുകളിൽ നിന്നുള്ളവ ഉൾപ്പെടെയുള്ള മറ്റ് ഇവൻ്റുകൾക്കും സമാനമാണ് (100% അല്ല).

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

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

ഇവന്റ് സോഴ്‌സിംഗ്

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

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

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

എന്നിരുന്നാലും, നമുക്ക് യഥാർത്ഥ ടാസ്ക്കിലേക്ക് മടങ്ങാം. സിസ്റ്റത്തിൻ്റെ ഒരു ഭാഗം ഉപയോഗിച്ച് നിർമ്മിക്കാൻ കഴിയുമെങ്കിൽ ആത്യന്തികമായ സ്ഥിരത, തുടർന്ന് നമുക്ക് ഇനിപ്പറയുന്ന ഡയഗ്രം നിർമ്മിക്കാം.

ഈ സമീപനത്തിൻ്റെ പ്രധാന സവിശേഷതകൾ:

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

ഓൺലൈൻ ഫയൽ സംഭരണത്തിൻ്റെ കാര്യം ഞങ്ങൾ പരിഗണിക്കുന്നുണ്ടെന്ന് ഞാൻ നിങ്ങളെ ഓർമ്മിപ്പിക്കട്ടെ. ഈ സാഹചര്യത്തിൽ, സിസ്റ്റം ഇതുപോലെ കാണപ്പെടും:

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

രണ്ട് ഉപയോക്താക്കൾക്കായി ഡയഗ്രം ഇതുപോലെ കാണപ്പെടും (വ്യത്യസ്ത ഉപയോക്താക്കൾക്കായി ഉദ്ദേശിച്ചിട്ടുള്ള സേവനങ്ങൾ വ്യത്യസ്ത നിറങ്ങളിൽ സൂചിപ്പിച്ചിരിക്കുന്നു):

അത്തരമൊരു സംയോജനത്തിൽ നിന്നുള്ള ബോണസുകൾ:

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

എന്നിരുന്നാലും, പോരായ്മകൾ ഉടനടി ദൃശ്യമാകും:

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

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

തൽഫലമായി:

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

ഷാർഡിംഗ്

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

• തരം അനുസരിച്ച് ഫയലുകൾ വേർതിരിക്കുക. ഉദാഹരണത്തിന്, ചിത്രങ്ങൾ/വീഡിയോകൾ ഡീകോഡ് ചെയ്യാനും കൂടുതൽ കാര്യക്ഷമമായ ഫോർമാറ്റ് തിരഞ്ഞെടുക്കാനും കഴിയും.
• രാജ്യം അനുസരിച്ച് അക്കൗണ്ടുകൾ വേർതിരിക്കുക. നിരവധി നിയമങ്ങൾ കാരണം, ഇത് ആവശ്യമായി വന്നേക്കാം, എന്നാൽ ഈ വാസ്തുവിദ്യാ പദ്ധതി യാന്ത്രികമായി അത്തരമൊരു അവസരം നൽകുന്നു

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

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

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

അതിനാൽ, ഫയലുകൾക്കായുള്ള ഓൺലൈൻ സംഭരണത്തെക്കുറിച്ചുള്ള ഞങ്ങളുടെ ഉദാഹരണം തുടരുന്നു, അത്തരമൊരു ആർക്കിടെക്ചർ ഇതിനകം തന്നെ ഞങ്ങൾക്ക് നിരവധി ബോണസുകൾ നൽകുന്നു:

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

സ്റ്റാറ്റിക് ഉള്ളടക്ക ഹോസ്റ്റിംഗ്

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

സ്റ്റാറ്റിക് ഉള്ളടക്കത്തിൻ്റെ ഏറ്റവും ലളിതവും ഏറ്റവും സാധാരണവുമായ ഉദാഹരണം ഒരു വെബ്‌സൈറ്റിനായുള്ള സ്ക്രിപ്റ്റുകളുടെയും ചിത്രങ്ങളുടെയും ഒരു കൂട്ടമാണ്. അവരുമായി എല്ലാം ലളിതമാണ് - അവ മുൻകൂട്ടി അറിയപ്പെടുന്നു, തുടർന്ന് ആർക്കൈവ് CDN സെർവറുകളിലേക്ക് അപ്‌ലോഡ് ചെയ്യുന്നു, അവിടെ നിന്ന് അവ അന്തിമ ഉപയോക്താക്കൾക്ക് വിതരണം ചെയ്യുന്നു.

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

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

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

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

എന്നിരുന്നാലും, ഞങ്ങൾ ഞങ്ങളുടെ സിസ്റ്റത്തിലേക്ക് മടങ്ങുകയാണെങ്കിൽ, നമുക്ക് സമാനമായ ഒരു ഡയഗ്രം ലഭിക്കും:

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

ഞാൻ തുടക്കത്തിൽ തന്നെ പറഞ്ഞതുപോലെ, ഇപ്പോൾ നിരവധി ഇൻ്റർനെറ്റ് സേവനങ്ങൾക്ക് വർദ്ധിച്ച ലോഡ് ലഭിക്കാൻ തുടങ്ങിയിരിക്കുന്നു. അവയിൽ ചിലത് ശരിയായി പ്രവർത്തിക്കുന്നത് നിർത്താൻ തുടങ്ങി. വാസ്തവത്തിൽ, ബിസിനസ്സ് പണം സമ്പാദിക്കുമെന്ന് കരുതിയ നിമിഷത്തിൽ സിസ്റ്റങ്ങൾ കൃത്യമായി പരാജയപ്പെട്ടു. അതായത്, മാറ്റിവെച്ച ഡെലിവറിക്ക് പകരം, "വരും മാസങ്ങളിൽ നിങ്ങളുടെ ഡെലിവറി ആസൂത്രണം ചെയ്യുക" എന്ന് ഉപഭോക്താക്കൾക്ക് നിർദ്ദേശിക്കുന്നതിന് പകരം "നിങ്ങളുടെ എതിരാളികളിലേക്ക് പോകുക" എന്ന് സിസ്റ്റം പറഞ്ഞു. വാസ്തവത്തിൽ, ഇത് കുറഞ്ഞ ഉൽപ്പാദനക്ഷമതയുടെ വിലയാണ്: ലാഭം ഏറ്റവും ഉയർന്നതായിരിക്കുമ്പോൾ നഷ്ടം സംഭവിക്കും.

തീരുമാനം

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

എന്നിരുന്നാലും, ഏറ്റവും പ്രധാനമായി, ഈ പാറ്റേണുകളെല്ലാം ആധുനിക ആപ്ലിക്കേഷനുകളിൽ പ്രയോഗിക്കാൻ വളരെ എളുപ്പമാണ് (അവ ഉചിതമാണെങ്കിൽ, തീർച്ചയായും). ക്ലൗഡുകൾ ഉടനടി ഷാർഡിംഗും തിരശ്ചീന സ്കെയിലിംഗും വാഗ്ദാനം ചെയ്യുന്നു, ഇത് വ്യത്യസ്ത ഡാറ്റാ സെൻ്ററുകളിൽ വ്യത്യസ്ത സമർപ്പിത സെർവറുകൾ ഓർഡർ ചെയ്യുന്നതിനേക്കാൾ വളരെ എളുപ്പമാണ്. RX പോലുള്ള ലൈബ്രറികളുടെ വികസനം കൊണ്ട് മാത്രം CQRS വളരെ എളുപ്പമായിരിക്കുന്നു. ഏകദേശം 10 വർഷം മുമ്പ്, ഒരു അപൂർവ വെബ്‌സൈറ്റ് ഇതിനെ പിന്തുണയ്ക്കാൻ കഴിയും. Apache Kafka ഉള്ള റെഡിമെയ്ഡ് കണ്ടെയ്‌നറുകൾക്ക് നന്ദി, ഇവൻ്റ് സോഴ്‌സിംഗ് സജ്ജീകരിക്കാനും അവിശ്വസനീയമാംവിധം എളുപ്പമാണ്. 10 വർഷം മുമ്പ് ഇതൊരു നവീകരണമാകുമായിരുന്നു, ഇപ്പോൾ ഇത് സാധാരണമാണ്. സ്റ്റാറ്റിക് ഉള്ളടക്ക ഹോസ്റ്റിംഗിൻ്റെ കാര്യത്തിലും ഇത് സമാനമാണ്: കൂടുതൽ സൗകര്യപ്രദമായ സാങ്കേതികവിദ്യകൾ കാരണം (വിശദമായ ഡോക്യുമെൻ്റേഷനും ഉത്തരങ്ങളുടെ ഒരു വലിയ ഡാറ്റാബേസും ഉണ്ട് എന്ന വസ്തുത ഉൾപ്പെടെ), ഈ സമീപനം കൂടുതൽ ലളിതമാണ്.

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

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

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