മൈക്രോസർവീസസ് - പതിപ്പുകളുടെ സംയോജിത സ്ഫോടനം

ഹലോ, ഹബ്ർ! ഞാൻ നിങ്ങളുടെ ശ്രദ്ധയിൽപ്പെടുത്തുന്നു ലേഖനത്തിന്റെ രചയിതാവിന്റെ വിവർത്തനം മൈക്രോസർവീസസ് - പതിപ്പുകളുടെ സംയോജിത സ്ഫോടനം.

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

ഈ വാചകം വായിച്ചുകൊണ്ട് നിങ്ങൾക്ക് ഇപ്പോഴും പ്രശ്നം മനസ്സിലായില്ലെങ്കിൽ, ഞാൻ വിശദീകരിക്കാം. നിങ്ങളുടെ ഉൽപ്പന്നത്തിൽ 10 മൈക്രോസർവീസുകൾ അടങ്ങിയിരിക്കുന്നുവെന്ന് പറയുക. ഇനി ഈ ഓരോ മൈക്രോസർവീസിനും 1 പുതിയ പതിപ്പ് പുറത്തിറങ്ങി എന്ന് കരുതുക. 1 പതിപ്പ് മാത്രം - ഇത് വളരെ നിസ്സാരവും നിസ്സാരവുമായ ഒരു വസ്തുതയാണെന്ന് നമുക്കെല്ലാവർക്കും അംഗീകരിക്കാൻ കഴിയുമെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു. എന്നിരുന്നാലും, ഇപ്പോൾ നമുക്ക് ഞങ്ങളുടെ ഉൽപ്പന്നത്തെക്കുറിച്ച് ഒന്നുകൂടി നോക്കാം. ഓരോ ഘടകത്തിന്റെയും ഒരു പുതിയ പതിപ്പ് ഉപയോഗിച്ച്, ഞങ്ങളുടെ ഉൽപ്പന്നം എങ്ങനെ നിർമ്മിക്കാം എന്നതിന്റെ 2^10 - അല്ലെങ്കിൽ 1024 പെർമ്യൂട്ടേഷനുകൾ ഇപ്പോൾ ഞങ്ങൾക്കുണ്ട്.

ഇനിയും എന്തെങ്കിലും തെറ്റിദ്ധാരണയുണ്ടെങ്കിൽ, ഞാൻ കണക്ക് പൊളിച്ചെഴുതട്ടെ. അതിനാൽ ഞങ്ങൾക്ക് 10 മൈക്രോ സർവീസുകളുണ്ട്, ഓരോന്നിനും ഒരു അപ്‌ഡേറ്റ് ലഭിക്കുന്നു. അതായത്, ഓരോ മൈക്രോസർവീസിനും (പഴയതോ പുതിയതോ) 2 സാധ്യമായ പതിപ്പുകൾ നമുക്ക് ലഭിക്കും. ഇപ്പോൾ, ഓരോ ഉൽപ്പന്ന ഘടകങ്ങൾക്കും, ഈ രണ്ട് പതിപ്പുകളിൽ ഏതെങ്കിലും ഒന്ന് ഉപയോഗിക്കാം. ഗണിതശാസ്ത്രപരമായി, നമുക്ക് 10 അക്കങ്ങളുടെ ബൈനറി സംഖ്യ ഉണ്ടായിരുന്നതിന് തുല്യമാണ്. ഉദാഹരണത്തിന്, 1 എന്നത് പുതിയ പതിപ്പാണെന്നും 0 എന്നത് പഴയ പതിപ്പാണെന്നും പറയാം - അപ്പോൾ സാധ്യമായ ഒരു ക്രമമാറ്റം 1001000000 ആയി സൂചിപ്പിക്കാം - ഇവിടെ 1-ഉം 4-ഉം ഘടകങ്ങൾ അപ്‌ഡേറ്റ് ചെയ്‌തിരിക്കുന്നു, മറ്റുള്ളവ അല്ല. ഒരു 10-അക്ക ബൈനറി സംഖ്യയ്ക്ക് 2^10 അല്ലെങ്കിൽ 1024 മൂല്യങ്ങൾ ഉണ്ടാകുമെന്ന് ഗണിതശാസ്ത്രത്തിൽ നിന്ന് നമുക്കറിയാം. അതായത്, ഞങ്ങൾ കൈകാര്യം ചെയ്യുന്ന സംഖ്യയുടെ സ്കെയിൽ ഞങ്ങൾ സ്ഥിരീകരിച്ചു.

നമുക്ക് നമ്മുടെ ന്യായവാദം തുടരാം - നമുക്ക് 100 മൈക്രോ സർവീസുകളും ഓരോന്നിനും സാധ്യമായ 10 പതിപ്പുകളും ഉണ്ടെങ്കിൽ എന്ത് സംഭവിക്കും? മുഴുവൻ സാഹചര്യവും തികച്ചും അരോചകമായിത്തീരുന്നു - ഇപ്പോൾ നമുക്ക് 10^100 ക്രമമാറ്റങ്ങൾ ഉണ്ട് - ഇത് ഒരു വലിയ സംഖ്യയാണ്. എന്നിരുന്നാലും, ഈ സാഹചര്യത്തെ ഈ രീതിയിൽ ലേബൽ ചെയ്യാനാണ് ഞാൻ ഇഷ്ടപ്പെടുന്നത്, കാരണം ഇപ്പോൾ നമ്മൾ "കുബർനെറ്റസ്" പോലുള്ള വാക്കുകൾക്ക് പിന്നിൽ ഒളിച്ചിരിക്കുകയല്ല, മറിച്ച് പ്രശ്‌നത്തെ അതേപടി അഭിമുഖീകരിക്കുകയാണ്.

എന്തുകൊണ്ടാണ് ഞാൻ ഈ പ്രശ്നത്തിൽ ആകൃഷ്ടനാകുന്നത്? ഭാഗികമായി കാരണം, മുമ്പ് എൻ‌എൽ‌പിയുടെയും എ‌ഐയുടെയും ലോകത്ത് പ്രവർത്തിച്ചതിനാൽ, ഏകദേശം 5-6 വർഷം മുമ്പ് ഞങ്ങൾ കോമ്പിനേറ്റോറിയൽ സ്‌ഫോടനത്തിന്റെ പ്രശ്‌നത്തെക്കുറിച്ച് വളരെയധികം ചർച്ച ചെയ്തിട്ടുണ്ട്. പതിപ്പുകൾക്ക് പകരം ഞങ്ങൾക്ക് വ്യക്തിഗത വാക്കുകളും ഉൽപ്പന്നങ്ങൾക്ക് പകരം വാക്യങ്ങളും ഖണ്ഡികകളും ഉണ്ടായിരുന്നു. NLP, AI എന്നിവയുടെ പ്രശ്‌നങ്ങൾ ഏറെക്കുറെ പരിഹരിക്കപ്പെട്ടിട്ടില്ലെങ്കിലും, കഴിഞ്ഞ കുറച്ച് വർഷങ്ങളായി കാര്യമായ പുരോഗതി കൈവരിച്ചിട്ടുണ്ടെന്ന് സമ്മതിക്കണം. (എന്റെ അഭിപ്രായത്തിൽ, പുരോഗതി കൈവരിക്കാൻ കഴിയുംоഇൻഡസ്ട്രിയിലുള്ള ആളുകൾ മെഷീൻ ലേണിംഗിൽ കുറച്ച് ശ്രദ്ധയും മറ്റ് ടെക്നിക്കുകളിൽ കുറച്ചുകൂടി ശ്രദ്ധയും നൽകിയാൽ നന്നായിരിക്കും - എന്നാൽ ഇത് ഇതിനകം വിഷയമല്ല).

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

സഹായിച്ചേക്കാവുന്ന ഒരു കാര്യം ഞാൻ കഴിഞ്ഞ വർഷം എഴുതിയതാണ് ക്ലയന്റുകൾക്കായി പോസ്റ്റുചെയ്ത പതിപ്പുകൾ തമ്മിലുള്ള ഏറ്റവും കുറഞ്ഞ വ്യത്യാസം നിലനിർത്തേണ്ടതിന്റെ ആവശ്യകതയെക്കുറിച്ച്. നന്നായി രൂപകല്പന ചെയ്ത CI/CD പ്രക്രിയ വ്യതിയാനം കുറയ്ക്കുന്നതിന് വളരെയധികം സഹായിക്കുന്നു എന്നതും ശ്രദ്ധിക്കേണ്ടതാണ്. എന്നിരുന്നാലും, CI/CD-യുടെ നിലവിലെ അവസ്ഥ, അക്കൗണ്ടിംഗിനും ഘടകങ്ങൾ ട്രാക്കുചെയ്യുന്നതിനുമുള്ള അധിക ടൂളുകളില്ലാതെ ക്രമപ്പെടുത്തലുകളുടെ പ്രശ്നം പരിഹരിക്കാൻ പര്യാപ്തമല്ല.

നമുക്ക് വേണ്ടത് സംയോജന ഘട്ടത്തിലെ ഒരു പരീക്ഷണ സംവിധാനമാണ്, അവിടെ ഓരോ ഘടകത്തിനും അപകടസാധ്യതയുള്ള ഘടകം നിർണ്ണയിക്കാൻ കഴിയും, കൂടാതെ വിവിധ ഘടകങ്ങൾ അപ്‌ഡേറ്റ് ചെയ്യുന്നതിനും ഓപ്പറേറ്റർ ഇടപെടാതെ പരിശോധിക്കുന്നതിനുമുള്ള ഒരു ഓട്ടോമേറ്റഡ് പ്രക്രിയയും ഉണ്ട് - എന്താണ് പ്രവർത്തിക്കുന്നത്, എന്താണ് പ്രവർത്തിക്കാത്തത് എന്ന് കാണാൻ.

അത്തരമൊരു പരീക്ഷണ സംവിധാനം ഇതുപോലെയാകാം:

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

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

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

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

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