સૂક્ષ્મ સેવાઓ: તેઓ શું છે, તેઓ શા માટે છે અને તેમને ક્યારે લાગુ કરવા

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

કોનવેનો કાયદો અને વ્યવસાય, સંસ્થા અને માહિતી સિસ્ટમ વચ્ચેનો સંબંધ

ફરી એકવાર હું મારી જાતને અવતરણ કરવાની મંજૂરી આપીશ:

"કોઈપણ સંસ્થા કે જે સિસ્ટમને ડિઝાઇન કરે છે (વ્યાપક અર્થમાં) તે એક ડિઝાઇન પ્રાપ્ત કરશે જેનું માળખું તે સંસ્થામાં ટીમોના બંધારણની નકલ કરે છે."
- મેલ્વીન કોનવે, 1967

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

માહિતી પ્રણાલીઓનું વ્યવસાયલક્ષી અભિગમ

ચાલો હું એક ઉદાહરણ સાથે સમજાવું. ચાલો કહીએ કે પિઝા વેચવાનો વ્યવસાય ગોઠવવાની વ્યવસાયિક તક છે. V1 સંસ્કરણમાં (ચાલો તેને પૂર્વ-માહિતી કહીએ), કંપની પિઝેરિયા, રોકડ રજિસ્ટર અને ડિલિવરી સેવા હતી. આ સંસ્કરણ ઓછી પર્યાવરણીય પરિવર્તનશીલતાની સ્થિતિમાં લાંબા સમય સુધી જીવતું હતું. પછી સંસ્કરણ 2 તેને બદલવા માટે આવ્યું - વધુ અદ્યતન અને એક મોનોલિથિક આર્કિટેક્ચર સાથે વ્યવસાય માટે તેના મૂળમાં માહિતી સિસ્ટમનો ઉપયોગ કરવા સક્ષમ. અને અહીં, મારા મતે, મોનોલિથ્સના સંબંધમાં ફક્ત એક ભયંકર અન્યાય છે - કથિત રીતે મોનોલિથિક આર્કિટેક્ચર ડોમેન બિઝનેસ મોડલને અનુરૂપ નથી. હા, જો આવું હોત, તો સિસ્ટમ બિલકુલ કામ કરી શકશે નહીં - સમાન કોન્વેના કાયદા અને સામાન્ય સમજ સાથે વિરોધાભાસમાં. ના, મોનોલિથિક આર્કિટેક્ચર બિઝનેસ ડેવલપમેન્ટના આ તબક્કે બિઝનેસ મોડલ સાથે સંપૂર્ણપણે સુસંગત છે - હું, અલબત્ત, તે તબક્કાનો અર્થ કરું છું જ્યારે સિસ્ટમ પહેલેથી જ બનાવવામાં આવી છે અને કાર્યરત છે. તે એકદમ અદ્ભુત હકીકત છે કે આર્કિટેક્ચરલ અભિગમને ધ્યાનમાં લીધા વિના, સર્વિસ-ઓરિએન્ટેડ આર્કિટેક્ચર વર્ઝન 3 અને માઇક્રોસર્વિસિસ આર્કિટેક્ચર વર્ઝન N બંને સમાન રીતે કામ કરશે. કેચ શું છે?

બધું વહે છે, બધું બદલાય છે, અથવા માઇક્રોસર્વિસિસ એ જટિલતા સામે લડવાનું સાધન છે?

આપણે આગળ વધીએ તે પહેલાં, ચાલો માઇક્રોસર્વિસ આર્કિટેક્ચર વિશેની કેટલીક ગેરસમજો જોઈએ.

માઇક્રોસર્વિસ અભિગમનો ઉપયોગ કરવાના સમર્થકો ઘણીવાર એવી દલીલ કરે છે કે માઇક્રોસર્વિસિસમાં મોનોલિથને તોડવાથી વ્યક્તિગત સેવાઓના કોડ બેઝને ઘટાડીને વિકાસના અભિગમને સરળ બનાવે છે. મારા મતે, આ નિવેદન સંપૂર્ણ બકવાસ છે. ગંભીરતાપૂર્વક, એક મોનોલિથ અને સજાતીય કોડની અંદર સ્પષ્ટ ક્રિયાપ્રતિક્રિયા જટિલ લાગે છે? જો આ ખરેખર કેસ હોત, તો તમામ પ્રોજેક્ટ્સ શરૂઆતમાં માઇક્રોસર્વિસિસ તરીકે બનાવવામાં આવશે, જ્યારે પ્રેક્ટિસ બતાવે છે કે મોનોલિથથી માઇક્રોસર્વિસિસમાં સ્થળાંતર વધુ સામાન્ય છે. જટિલતા અદૃશ્ય થતી નથી; તે ફક્ત વ્યક્તિગત મોડ્યુલોથી ઇન્ટરફેસ (તે ડેટા બસો, RPC, API અને અન્ય પ્રોટોકોલ હોય) અને ઓર્કેસ્ટ્રેટિંગ સિસ્ટમ્સ પર જાય છે. અને આ મુશ્કેલ છે!

વિજાતીય સ્ટેકનો ઉપયોગ કરવાનો ફાયદો પણ શંકાસ્પદ છે. હું એવી દલીલ કરીશ નહીં કે આ પણ શક્ય છે, પરંતુ વાસ્તવમાં તે ભાગ્યે જ થાય છે (આગળ જોવું - આ થવું જોઈએ - પરંતુ ફાયદાને બદલે પરિણામ તરીકે).

ઉત્પાદન જીવન ચક્ર અને સેવા જીવન ચક્ર

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

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

જટિલતાનો સામનો કરવાના સાધન તરીકે માઇક્રોસર્વિસિસ... રૂપરેખાંકન વ્યવસ્થાપન

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

તારણો

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

સોર્સ: www.habr.com