સ્થાપત્ય શૈલી પસંદ કરવી (ભાગ 1)

હેલો, હેબ્ર. નવા કોર્સ સ્ટ્રીમ માટે નોંધણી અત્યારે OTUS પર ખુલ્લી છે "સોફ્ટવેર આર્કિટેક્ટ". કોર્સની શરૂઆતની પૂર્વસંધ્યાએ, હું તમારી સાથે મારો મૂળ લેખ શેર કરવા માંગુ છું.

પરિચય

માહિતી સિસ્ટમ બનાવતી વખતે આર્કિટેક્ચરલ શૈલીની પસંદગી એ મૂળભૂત તકનીકી નિર્ણયોમાંનો એક છે. લેખોની આ શ્રેણીમાં, હું એપ્લિકેશન બનાવવા માટે સૌથી વધુ લોકપ્રિય આર્કિટેક્ચરલ શૈલીઓનું વિશ્લેષણ કરવાનો પ્રસ્તાવ મૂકું છું અને કયા આર્કિટેક્ચરલ શૈલી સૌથી વધુ પ્રાધાન્યક્ષમ છે તે પ્રશ્નનો જવાબ આપું છું. પ્રસ્તુતિની પ્રક્રિયામાં, હું એક તાર્કિક સાંકળ દોરવાનો પ્રયાસ કરીશ જે મોનોલિથ્સથી માઇક્રોસર્વિસિસ સુધીના સ્થાપત્ય શૈલીઓના વિકાસને સમજાવે છે.

ઇતિહાસ એક બીટ

જો તમે વિકાસકર્તાઓને પૂછવાનો પ્રયાસ કરો: "અમને શા માટે માઇક્રો સર્વિસીસની જરૂર છે?", તો તમને વિવિધ જવાબો મળશે. તમે સાંભળશો કે માઇક્રોસર્વિસિસ માપનીયતામાં સુધારો કરે છે, કોડને સમજવામાં સરળ બનાવે છે, ખામી સહિષ્ણુતામાં સુધારો કરે છે અને કેટલીકવાર તમે સાંભળશો કે તેઓ તમને "તમારો કોડ સાફ" કરવાની મંજૂરી આપે છે. માઇક્રોસર્વિસિસના ઉદભવ પાછળનો હેતુ સમજવા માટે ચાલો ઇતિહાસ જોઈએ.

ટૂંકમાં, અમારી વર્તમાન સમજણમાં માઇક્રોસર્વિસિસ નીચે પ્રમાણે ઉદ્ભવી: 2011 માં, જેમ્સ લુઇસે, વિવિધ કંપનીઓના કાર્યનું વિશ્લેષણ કરીને, નવી "માઇક્રો-એપ" પેટર્નના ઉદભવ તરફ ધ્યાન દોર્યું, જેણે SOA ને ઝડપી બનાવવાના સંદર્ભમાં ઑપ્ટિમાઇઝ કર્યું. સેવાઓ. થોડા સમય પછી, 2012 માં, એક આર્કિટેક્ચર સમિટમાં, પેટર્નનું નામ માઇક્રોસર્વિસ રાખવામાં આવ્યું. આમ, માઇક્રોસર્વિસિસની રજૂઆતનો પ્રારંભિક ધ્યેય બદનામને સુધારવાનો હતો બજાર નો સમય.

2015માં માઇક્રોસર્વિસિસ હાઇપ વેવ પર હતી. કેટલાક અભ્યાસો અનુસાર, માઇક્રોસર્વિસિસના વિષય પરના અહેવાલ વિના એક પણ પરિષદ પૂર્ણ થઈ ન હતી. તદુપરાંત, કેટલીક પરિષદો ફક્ત માઇક્રોસર્વિસિસને સમર્પિત હતી. આજકાલ, ઘણા પ્રોજેક્ટ્સ આ આર્કિટેક્ચરલ શૈલીનો ઉપયોગ કરવાનું શરૂ કરે છે, અને જો પ્રોજેક્ટમાં ઘણા બધા લેગસી કોડ હોય, તો પછી માઇક્રોસર્વિસિસમાં સ્થળાંતર સક્રિય રીતે હાથ ધરવામાં આવી રહ્યું છે.

ઉપરોક્ત તમામ હોવા છતાં, ખૂબ ઓછી સંખ્યામાં વિકાસકર્તાઓ હજુ પણ "માઈક્રોસર્વિસ" ના ખ્યાલને વ્યાખ્યાયિત કરી શકે છે. પણ આ વિશે થોડી વાર પછી વાત કરીશું...

મોનોલિથ

આર્કિટેક્ચરલ શૈલી કે જે માઇક્રોસર્વિસીસનો વિરોધાભાસ કરે છે તે મોનોલિથ (અથવા ઓલ-ઇન-વન) છે. મોનોલિથ શું છે તે કહેવાનો કદાચ કોઈ અર્થ નથી, તેથી હું તરત જ આ સ્થાપત્ય શૈલીના ગેરફાયદાને સૂચિબદ્ધ કરીશ, જેણે સ્થાપત્ય શૈલીઓના વધુ વિકાસની શરૂઆત કરી: કદ, જોડાણ, જમાવટ, માપનીયતા, વિશ્વસનીયતા અને કઠોરતા. નીચે હું દરેક ખામીઓને અલગથી જોવાનો પ્રસ્તાવ મૂકું છું.

કદ

મોનોલિથ ખૂબ વિશાળ છે. અને તે સામાન્ય રીતે ખૂબ મોટા ડેટાબેઝ સાથે વાતચીત કરે છે. એપ્લિકેશન એક વિકાસકર્તા માટે બિલકુલ સમજી શકતી નથી તેટલી મોટી બની જાય છે. ફક્ત તે જ જેમણે આ કોડ પર કામ કરવામાં ઘણો સમય વિતાવ્યો છે તે મોનોલિથ સાથે સારી રીતે કામ કરી શકે છે, જ્યારે નવા નિશાળીયા મોનોલિથને આકૃતિ કરવાનો પ્રયાસ કરવામાં ઘણો સમય વિતાવશે અને ત્યાં કોઈ ગેરેંટી નથી કે તેઓ તેને શોધી કાઢશે. સામાન્ય રીતે, મોનોલિથ સાથે કામ કરતી વખતે, હંમેશા કેટલાક "શરતી" વરિષ્ઠ હોય છે જેઓ મોનોલિથને વધુ કે ઓછા સારી રીતે જાણે છે અને દોઢ વર્ષમાં અન્ય નવા વિકાસકર્તાઓના હાથને હરાવે છે. સ્વાભાવિક રીતે, આવા શરતી વરિષ્ઠ એ નિષ્ફળતાનો એક જ મુદ્દો છે, અને તેના પ્રસ્થાનથી મોનોલિથની મૃત્યુ થઈ શકે છે.

જોડાણ

મોનોલિથ એ "કાદવનો મોટો બોલ" છે, જેમાં ફેરફારો અણધારી પરિણામો તરફ દોરી શકે છે. એક જગ્યાએ ફેરફાર કરીને, તમે બીજી જગ્યાએ મોનોલિથને નુકસાન પહોંચાડી શકો છો (તે જ "તમે તમારા કાનને ખંજવાળ્યા, *@ પડી ગયા"). આ એ હકીકતને કારણે છે કે મોનોલિથના ઘટકો ખૂબ જટિલ અને સૌથી અગત્યનું, બિન-સ્પષ્ટ સંબંધો ધરાવે છે.

જમાવટ

તેના ઘટકો વચ્ચેના જટિલ સંબંધોને કારણે, મોનોલિથની જમાવટ એ તેની પોતાની ધાર્મિક વિધિ સાથે લાંબી પ્રક્રિયા છે. આવી ધાર્મિક વિધિ સામાન્ય રીતે સંપૂર્ણપણે પ્રમાણિત હોતી નથી અને તેને "મૌખિક રીતે" પસાર કરવામાં આવે છે.

માપનીયતા

મોનોલિથ મોડ્યુલમાં વિરોધાભાસી સંસાધન જરૂરિયાતો હોઈ શકે છે, જેમાં હાર્ડવેરના સંદર્ભમાં સમાધાન કરવાની જરૂર છે. કલ્પના કરો કે તમારી પાસે એક મોનોલિથ છે જેમાં A અને B સેવાઓનો સમાવેશ થાય છે. સેવા A હાર્ડ ડ્રાઇવના કદ પર માંગ કરી રહી છે, અને સેવા B RAM પર માંગ કરી રહી છે. આ કિસ્સામાં, ક્યાં તો મશીન કે જેના પર મોનોલિથ ઇન્સ્ટોલ કરેલું છે તે બંને સેવાઓની આવશ્યકતાઓને સમર્થન આપવું આવશ્યક છે, અથવા તમારે મેન્યુઅલી, કૃત્રિમ રીતે એક સેવાને અક્ષમ કરવી પડશે.

બીજું ઉદાહરણ (વધુ ક્લાસિક): સેવા A એ સેવા B કરતાં વધુ લોકપ્રિય છે, તેથી તમે ઇચ્છો છો કે ત્યાં 100 સેવાઓ A, અને 10 સેવાઓ B હોય. ફરીથી, બે વિકલ્પો: કાં તો અમે 100 સંપૂર્ણ મોનોલિથ જમાવીએ છીએ, અથવા અમુક પર સેવાઓ B ને મેન્યુઅલી અક્ષમ કરવી પડશે.

વિશ્વસનીયતા

બધી સેવાઓ એકસાથે સ્થિત હોવાથી, જો મોનોલિથ પડી જાય, તો બધી સેવાઓ એક સાથે પડી જાય છે. વાસ્તવમાં, આ એટલું ખરાબ ન હોઈ શકે, ઓછામાં ઓછું વિતરિત સિસ્ટમમાં કોઈ આંશિક નિષ્ફળતાઓ નહીં હોય, પરંતુ બીજી બાજુ, 0.001% વપરાશકર્તાઓ દ્વારા ઉપયોગમાં લેવામાં આવતી કાર્યક્ષમતામાં ખામીને કારણે, તમે બધા વપરાશકર્તાઓને ગુમાવી શકો છો. તમારી સિસ્ટમની.

જડતા

મોનોલિથના કદને લીધે, નવી તકનીકો પર સ્વિચ કરવું મુશ્કેલ છે. પરિણામે, તે જ વરિષ્ઠને જાળવી રાખવું એ એક અલગ કાર્ય છે. પ્રોજેક્ટની શરૂઆતમાં પસંદ કરવામાં આવેલ ટેક્નોલોજી સ્ટેક એક બ્લોક બની શકે છે જે ઉત્પાદનના વિકાસને અવરોધે છે.

નિષ્કર્ષ

આગલી વખતે આપણે એ વિશે વાત કરીશું કે લોકોએ ઘટકો અને SOA પર જઈને આ સમસ્યાઓને કેવી રીતે ઉકેલવાનો પ્રયાસ કર્યો છે.

વધુ વાંચો:

• શા માટે SQL સર્વર ORDER BY વગર પરિણામોને સૉર્ટ કરવાની ખાતરી આપતું નથી
• વિકાસકર્તાઓ અને સંચાલકો માટે આર્કિટેક્ચર: કોને કઈ કુશળતાની જરૂર છે?

સોર્સ: www.habr.com