માઇક્રોસર્વિસિસ: તમારી પાસે કુબરનેટ્સ હોય તો પણ, કદ મહત્વપૂર્ણ છે

મોસ્કોમાં 19 સપ્ટેમ્બર સ્થાન લીધું પ્રથમ વિષયોની બેઠક HUG (હાઇલોડ++ વપરાશકર્તા જૂથ), જે માઇક્રોસર્વિસિસને સમર્પિત હતી. "ઓપરેટિંગ માઇક્રોસર્વિસીસ: સાઈઝ મેટર, જો તમારી પાસે કુબરનેટ્સ હોય તો પણ" એક પ્રેઝન્ટેશન હતું, જેમાં અમે માઇક્રોસર્વિસ આર્કિટેક્ચર સાથેના ઓપરેટિંગ પ્રોજેક્ટ્સમાં ફ્લાન્ટનો વ્યાપક અનુભવ શેર કર્યો હતો. સૌ પ્રથમ, તે બધા વિકાસકર્તાઓ માટે ઉપયોગી થશે જેઓ તેમના વર્તમાન અથવા ભવિષ્યના પ્રોજેક્ટમાં આ અભિગમનો ઉપયોગ કરવા વિશે વિચારી રહ્યા છે.

પરિચય અહેવાલનો વિડિયો (50 મિનિટ, લેખ કરતાં ઘણી વધુ માહિતીપ્રદ), તેમજ ટેક્સ્ટ સ્વરૂપમાં તેમાંથી મુખ્ય અર્ક.

NB: આ પોસ્ટના અંતે વિડિયો અને પ્રેઝન્ટેશન પણ ઉપલબ્ધ છે.

પરિચય

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

હું આ ગ્રાફથી શરૂઆત કરીશ, જેના લેખક (2015 માં) બન્યા માર્ટિન ફાઉલર:

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

કુબરનેટ્સનો ઉપયોગ કરવાના કેસ માટે હું આ ગ્રાફમાં ઉમેરીશ:

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

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

ઉપયોગી અને હાનિકારક સૂક્ષ્મ સેવાઓ

અને અહીં મુખ્ય વિચાર છે:

શું છે સામાન્ય માઇક્રોસર્વિસ આર્કિટેક્ચર? તે તમને વાસ્તવિક લાભો લાવશે, તમારી કાર્યક્ષમતામાં વધારો કરશે. જો આપણે ગ્રાફ પર પાછા જઈએ, તો તે અહીં છે:

જો તમે તેણીને બોલાવો ઉપયોગી, પછી ગ્રાફની બીજી બાજુ હશે હાનિકારક સૂક્ષ્મ સેવાઓ (કામમાં દખલ કરે છે):

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

શા માટે માઇક્રોસર્વિસિસ?

માઇક્રોસર્વિસિસના ફાયદા વિશેના પ્રશ્ન માટે ત્યાં છે ખૂબ ચોક્કસ જવાબ પહેલેથી જ ઉલ્લેખિત માર્ટિન ફોલર તરફથી:

1. મોડ્યુલારિટીની સ્પષ્ટ સીમાઓ;
2. સ્વતંત્ર જમાવટ;
3. તકનીકો પસંદ કરવાની સ્વતંત્રતા.

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

જો આપણે "સંવેદનાઓમાં" કેટલાક મુદ્દાઓનું વર્ણન કરીએ તો:

• મોડ્યુલોની સ્પષ્ટ સીમાઓ: અહીં આપણી પાસે એક ભયંકર મોનોલિથ છે, અને હવે બધું ગિટ રિપોઝીટરીઝમાં સરસ રીતે ગોઠવવામાં આવશે, જેમાં બધું "છાજલીઓ પર" છે, ગરમ અને નરમ મિશ્રિત નથી;
• જમાવટની સ્વતંત્રતા: અમે સેવાઓને સ્વતંત્ર રીતે રોલ આઉટ કરી શકીશું જેથી વિકાસ ઝડપથી થાય (સમાંતર નવી સુવિધાઓ પ્રકાશિત કરો);
• વિકાસની સ્વતંત્રતા: અમે આ માઇક્રોસર્વિસ એક ટીમ/ડેવલપરને આપી શકીએ છીએ, અને તે બીજાને આપી શકીએ છીએ, જેના કારણે અમે ઝડપથી વિકાસ કરી શકીએ છીએ;
• боવધુ વિશ્વસનીયતા: જો આંશિક અધોગતિ થાય છે (20 માંથી એક માઇક્રોસર્વિસ ઘટી જાય છે), તો માત્ર એક બટન કામ કરવાનું બંધ કરશે, અને સમગ્ર સિસ્ટમ કાર્ય કરવાનું ચાલુ રાખશે.

લાક્ષણિક (હાનિકારક) માઇક્રોસર્વિસ આર્કિટેક્ચર

શા માટે વાસ્તવિકતા આપણી અપેક્ષા મુજબ નથી તે સમજાવવા માટે, હું રજૂ કરીશ સામૂહિક ઘણા જુદા જુદા પ્રોજેક્ટના અનુભવના આધારે માઇક્રોસર્વિસ આર્કિટેક્ચરની છબી.

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

કારણોના સંયોજન માટે, આ માઇક્રોસેવાઓ વિવિધ પ્લેટફોર્મ પર લખાયેલ છે:

દરેક માઇક્રોસર્વિસમાં સ્વાયત્તતા હોવી આવશ્યક હોવાથી, તેમાંના ઘણાને તેમના પોતાના ડેટાબેઝ અને કેશની જરૂર હોય છે. અંતિમ આર્કિટેક્ચર નીચે મુજબ છે:

તેના પરિણામો શું છે?

ફાઉલર પાસે પણ આ છે એક લેખ છે - માઇક્રો સર્વિસિસનો ઉપયોગ કરવા માટે "ચુકવણી" વિશે:

અને અમે જોશું કે અમારી અપેક્ષાઓ પૂરી થઈ કે નહીં.

મોડ્યુલોની સીમાઓ સાફ કરો...

પરંતુ આપણે વાસ્તવમાં કેટલી માઇક્રોસર્વિસિસને ઠીક કરવાની જરૂર છે?ફેરફાર રોલ આઉટ કરવા માટે? શું આપણે એ પણ શોધી શકીએ છીએ કે વિતરિત ટ્રેસર વિના બધું કેવી રીતે કાર્ય કરે છે (છેવટે, કોઈપણ વિનંતી પર અડધા માઇક્રોસર્વિસિસ દ્વારા પ્રક્રિયા કરવામાં આવે છે)?

એક પેટર્ન છે "ગંદકીનો મોટો ગઠ્ઠો", અને અહીં તે ગંદકીનો વિતરિત ગઠ્ઠો હોવાનું બહાર આવ્યું. આની પુષ્ટિ કરવા માટે, વિનંતીઓ કેવી રીતે જાય છે તેનું અંદાજિત ઉદાહરણ અહીં છે:

જમાવટની સ્વતંત્રતા...

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

ટેકનોલોજી પસંદ કરવાની સ્વતંત્રતા...

તેણી. જસ્ટ યાદ રાખો કે સ્વતંત્રતા ઘણીવાર અંધેર પર સરહદ ધરાવે છે. ફક્ત તેમની સાથે "રમવા" માટે તકનીકો પસંદ ન કરવી તે અહીં ખૂબ જ મહત્વપૂર્ણ છે.

વિકાસની સ્વતંત્રતા...

સમગ્ર એપ્લિકેશન (ઘણા ઘટકો સાથે) માટે ટેસ્ટ લૂપ કેવી રીતે બનાવવો? પરંતુ તમારે હજુ પણ તેને અદ્યતન રાખવાની જરૂર છે. આ બધું એ હકીકત તરફ દોરી જાય છે કે ટેસ્ટ સર્કિટની વાસ્તવિક સંખ્યા, જે આપણે સૈદ્ધાંતિક રીતે સમાવી શકીએ છીએ, ન્યૂનતમ હોવાનું બહાર આવ્યું છે.

આ બધું સ્થાનિક રીતે કેવી રીતે ગોઠવવું?... તે તારણ આપે છે કે ઘણીવાર વિકાસકર્તા સ્વતંત્ર રીતે તેનું કામ કરે છે, પરંતુ "રેન્ડમ", કારણ કે તેને સર્કિટ પરીક્ષણ માટે મુક્ત ન થાય ત્યાં સુધી રાહ જોવાની ફરજ પાડવામાં આવે છે.

અલગ સ્કેલિંગ...

હા, પરંતુ તે ઉપયોગમાં લેવાતા DBMS ના ક્ષેત્રમાં મર્યાદિત છે. આપેલ આર્કિટેક્ચરના ઉદાહરણમાં, કેસાન્ડ્રાને સમસ્યા નહીં હોય, પરંતુ MySQL અને PostgreSQL ને હશે.

Боવધુ વિશ્વસનીયતા...

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

લોડ માપનક્ષમતા...

આ ખરેખર સારું છે.

માઇક્રોસર્વિસિસની "હળવાશ"...

અમારી પાસે માત્ર વિશાળ નથી નેટવર્ક ઓવરહેડ (DNS માટેની વિનંતીઓ ગુણાકાર થઈ રહી છે, વગેરે), પણ અમે શરૂ કરેલી ઘણી સબક્વેરીઝને કારણે પણ ડેટાની નકલ કરો (સ્ટોર કેશ), જે નોંધપાત્ર પ્રમાણમાં સંગ્રહ તરફ દોરી જાય છે.

અને અહીં અમારી અપેક્ષાઓ પૂરી કરવાનું પરિણામ છે:

પરંતુ તે બધુ જ નથી!

કારણ કે:

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

આ બધાનું શું કરવું?

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

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

પરંતુ જો આપણે પહેલેથી જ આ પરિસ્થિતિમાં હોઈએ તો શું?

કોઈપણ સમસ્યાને ઉકેલવા માટેનું પ્રથમ પગલું એ છે કે તેની સાથે સંમત થવું અને સમજવું કે તે એક સમસ્યા છે, જેને આપણે હવે સહન કરવા માંગતા નથી.

જો, અતિશય વૃદ્ધિ પામેલા મોનોલિથના કિસ્સામાં (જ્યારે આપણે તેના માટે વધારાના સંસાધનો ખરીદવાની તક ગુમાવી દીધી હોય), તો અમે તેને કાપી નાખીએ છીએ, તો આ કિસ્સામાં વિપરીત વાર્તા બહાર આવે છે: જ્યારે અતિશય માઇક્રોસર્વિસિસ હવે મદદ કરશે નહીં, પરંતુ અવરોધે છે - વધારાનું કાપી નાખો અને મોટું કરો!

ઉદાહરણ તરીકે, ઉપર ચર્ચા કરેલ સામૂહિક છબી માટે...

સૌથી શંકાસ્પદ માઇક્રોસેવાઓથી છુટકારો મેળવો:

ફ્રન્ટએન્ડ જનરેશન માટે જવાબદાર તમામ માઇક્રોસેવાઓને જોડો:

... એક માઇક્રોસર્વિસમાં, એકમાં લખાયેલ (આધુનિક અને સામાન્ય, જેમ તમે જાતે વિચારો છો) ભાષા/ફ્રેમવર્ક:

તેમાં એક ORM (એક DBMS) અને પહેલા બે એપ્લિકેશન હશે:

... પરંતુ સામાન્ય રીતે તમે નીચેનું પરિણામ મેળવીને ત્યાં ઘણું બધું સ્થાનાંતરિત કરી શકો છો:

તદુપરાંત, કુબરનેટ્સમાં આપણે આ બધું અલગ-અલગ ઉદાહરણોમાં ચલાવીએ છીએ, જેનો અર્થ છે કે આપણે હજુ પણ ભારને માપી શકીએ છીએ અને તેને અલગથી માપી શકીએ છીએ.

સારાંશ માટે

મોટા ચિત્ર જુઓ. ઘણી વાર, માઇક્રોસર્વિસિસ સાથેની આ બધી સમસ્યાઓ ઊભી થાય છે કારણ કે કોઈએ તેમનું કાર્ય લીધું હતું, પરંતુ "માઇક્રોસર્વિસિસ સાથે રમવા" ઇચ્છતા હતા.

"માઈક્રો સર્વિસીસ" શબ્દમાં "માઈક્રો" ભાગ રીડન્ડન્ટ છે.. તેઓ "સૂક્ષ્મ" છે કારણ કે તેઓ વિશાળ મોનોલિથ કરતા નાના છે. પરંતુ તેમને કંઈક નાનું ન સમજો.

અને અંતિમ વિચાર માટે, ચાલો મૂળ ચાર્ટ પર પાછા આવીએ:

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

વિડિઓઝ અને સ્લાઇડ્સ

ભાષણમાંથી વિડિઓ (~50 મિનિટ; કમનસીબે, તે મુલાકાતીઓની અસંખ્ય લાગણીઓને વ્યક્ત કરતું નથી, જેણે મોટાભાગે અહેવાલનો મૂડ નક્કી કર્યો હતો, પરંતુ તે આ રીતે છે):

અહેવાલની રજૂઆત:

PS

અમારા બ્લોગ પર અન્ય અહેવાલો:

• «મોનિટરિંગ અને કુબરનેટ્સ» (દિમિત્રી સ્ટોલ્યારોવ; રૂટકોન્ફ ખાતે 28 મે, 2018);
• «કુબરનેટ્સ અને ગિટલેબ સાથે CI/CD શ્રેષ્ઠ વ્યવહારો» (દિમિત્રી સ્ટોલ્યારોવ; હાઇલોડ++ પર નવેમ્બર 7, 2017);
• «નાના પ્રોજેક્ટ્સમાં કુબરનેટ્સ સાથેનો અમારો અનુભવ» (દિમિત્રી સ્ટોલ્યારોવ; રૂટકોન્ફ ખાતે જૂન 6, 2017);
• «અમે સીઆઈ/સીડી માટે ડોકર ઈમેજીસ ઝડપથી અને સગવડતાથી ડીએપી સાથે બનાવીએ છીએ» (દિમિત્રી સ્ટોલ્યારોવ; હાઇલોડ++ પર નવેમ્બર 8, 2016);
• «ડોકર સાથે સતત ડિલિવરી પ્રેક્ટિસ» (દિમિત્રી સ્ટોલ્યારોવ; રૂટકોન્ફ ખાતે 31 મે, 2016).

તમને નીચેના પ્રકાશનોમાં પણ રસ હોઈ શકે છે:

• «2018 માં માઇક્રોસર્વિસ ગાંડપણનું મૃત્યુ»;
• «Google અનુસાર કન્ટેનરનો ઉપયોગ કરવા માટેની 7 શ્રેષ્ઠ પદ્ધતિઓ»;
• «કુબરનેટ્સના અમલીકરણના પડકારો પર ધ ન્યૂ સ્ટેકના આંકડા».

સોર્સ: www.habr.com