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

હેલો, હેબ્ર. આજે હું પ્રકાશનોની શ્રેણી ચાલુ રાખું છું જે મેં ખાસ કરીને કોર્સના નવા પ્રવાહની શરૂઆત માટે લખ્યા હતા. "સોફ્ટવેર આર્કિટેક્ટ".

પરિચય

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

В છેલ્લા સમય અમે મોનોલિથ સાથે વ્યવહાર કર્યો અને નિષ્કર્ષ પર આવ્યા કે મોનોલિથમાં સંખ્યાબંધ સમસ્યાઓ છે: કદ, કનેક્ટિવિટી, જમાવટ, માપનીયતા, વિશ્વસનીયતા અને કઠોરતા.

આ વખતે હું મોડ્યુલો/લાઇબ્રેરીઓ (ઘટક-લક્ષી આર્કિટેક્ચર) અથવા સેવાઓ (સેવા-લક્ષી આર્કિટેક્ચર) ના સમૂહ તરીકે સિસ્ટમ ગોઠવવાની શક્યતાઓ વિશે વાત કરવાનો પ્રસ્તાવ મૂકું છું.

ઘટક-લક્ષી આર્કિટેક્ચર

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

ઘટકોના યોગ્ય ઉપયોગ સાથે, "ગંદકીના મોટા બોલ" (મોટા કદ + ઉચ્ચ જોડાણ) ની સમસ્યા હલ થાય છે, અને ઘટકો પોતે એસેમ્બલી એકમો (મોડ્યુલો, પુસ્તકાલયો) અને જમાવટ એકમો (સેવાઓ) બંનેનું પ્રતિનિધિત્વ કરી શકે છે. ડિપ્લોયમેન્ટ યુનિટ હંમેશા ચાલી રહેલ પ્રક્રિયામાં મેપ કરવામાં આવતા નથી: ઉદાહરણ તરીકે, વેબ એપ્લિકેશન અને ડેટાબેઝ એકસાથે જમાવવામાં આવે છે.

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

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

"આદર્શ" મોનોલિથ એ તાર્કિક રીતે અલગ કરેલ મોડ્યુલોનો સમૂહ છે, જેમાંથી દરેક તેના પોતાના ડેટાબેઝમાં જુએ છે.

સેવાલક્ષી આર્કિટેક્ચર

જો સિસ્ટમ સેવાઓના સમૂહના રૂપમાં ગોઠવવામાં આવે તેવું માનવામાં આવે છે, તો અમે સેવા-લક્ષી આર્કિટેક્ચર વિશે વાત કરી રહ્યા છીએ. તેના સિદ્ધાંતો વપરાશકર્તા-કેન્દ્રિત એપ્લિકેશન ઇન્ટરઓપરેબિલિટી, બિઝનેસ સર્વિસનો પુનઃઉપયોગ, ટેક્નોલોજી સ્ટેક સ્વતંત્રતા અને સ્વાયત્તતા (સ્વતંત્ર ઉત્ક્રાંતિ, માપનીયતા અને જમાવટ) છે.

સર્વિસ-ઓરિએન્ટેડ આર્કિટેક્ચર (SOA = સર્વિસ ઓરિએન્ટેડ આર્કિટેક્ચર) એક મોનોલિથની તમામ ઓળખાયેલ સમસ્યાઓનું નિરાકરણ કરે છે: જ્યારે ફેરફાર થાય છે ત્યારે માત્ર એક જ સેવા પ્રભાવિત થાય છે, અને સારી રીતે વ્યાખ્યાયિત API ઘટકોના સારા એન્કેપ્સ્યુલેશનને સપોર્ટ કરે છે.

પરંતુ બધું એટલું સરળ નથી: SOA નવી સમસ્યાઓ બનાવે છે. રિમોટ કૉલ્સ સ્થાનિક કૉલ્સ કરતાં વધુ ખર્ચાળ છે, અને ઘટકો વચ્ચે જવાબદારીઓનું પુનઃવિતરણ નોંધપાત્ર રીતે વધુ ખર્ચાળ બની ગયું છે.

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

સેવા-લક્ષી આર્કિટેક્ચરને આર્કિટેક્ચરલ સમુદાય અને વિક્રેતાઓ દ્વારા સારી રીતે સમર્થન મળે છે. આ ઘણા અભ્યાસક્રમો અને પ્રમાણપત્રો, સારી રીતે વિકસિત પેટર્નની હાજરી સૂચવે છે. બાદમાં, ઉદાહરણ તરીકે, જાણીતી એન્ટરપ્રાઇઝ સર્વિસ બસ (ESB = એન્ટરપ્રાઇઝ સર્વિસ બસ)નો સમાવેશ થાય છે. તે જ સમયે, ESB એ વિક્રેતાઓ તરફથી એક સામાન છે; તે જરૂરી નથી કે તેનો SOA માં ઉપયોગ થાય.

સેવા-લક્ષી આર્કિટેક્ચરની લોકપ્રિયતા 2008 ની આસપાસ ચરમસીમાએ પહોંચી હતી, ત્યારબાદ તેમાં ઘટાડો થવા લાગ્યો હતો, જે માઇક્રોસર્વિસિસ (~2015) ના આગમન પછી નોંધપાત્ર રીતે વધુ નાટકીય બની હતી.

નિષ્કર્ષ

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

સોર્સ: www.habr.com