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

(અને આ લેખના અંતે, હું માઇક્રોસર્વિસ આર્કિટેક્ચર નિષ્ણાત ક્રિસ રિચાર્ડસનના ત્રણ દિવસીય સેમિનારમાં ભાગ લેવાની તક વિશે વાત કરીશ).

અમે કેવી રીતે માઇક્રોસર્વિસિસ પર આવ્યા

એવિટો એ વિશ્વની સૌથી મોટી વર્ગીકૃત સાઇટ્સમાંની એક છે; તેના પર દરરોજ 15 મિલિયનથી વધુ નવી જાહેરાતો પ્રકાશિત થાય છે. અમારું બેકએન્ડ પ્રતિ સેકન્ડ 20 હજારથી વધુ વિનંતીઓ સ્વીકારે છે. અમારી પાસે હાલમાં સો માઈક્રો સર્વિસ છે.

અમે ઘણા વર્ષોથી માઇક્રોસર્વિસ આર્કિટેક્ચર બનાવી રહ્યા છીએ. કેવી રીતે બરાબર - અમારા સાથીદારો વિગતવાર કહ્યું RIT++ 2017માં અમારા વિભાગમાં. કોડફેસ્ટ 2017માં (જુઓ. видео), સેર્ગેઈ ઓર્લોવ અને મિખાઇલ પ્રોકોપચુકે વિગતવાર સમજાવ્યું કે શા માટે અમને માઇક્રોસર્વિસિસમાં સંક્રમણની જરૂર છે અને કુબરનેટે અહીં શું ભૂમિકા ભજવી છે. ઠીક છે, હવે અમે સ્કેલિંગ ખર્ચને ઘટાડવા માટે બધું જ કરી રહ્યા છીએ જે આવા આર્કિટેક્ચરમાં સહજ છે.

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

હવે PaaS CLI યુટિલિટીમાં, એક આદેશ સાથે નવી સેવા બનાવવામાં આવે છે, અને વધુ બે સાથે નવો ડેટાબેઝ ઉમેરવામાં આવે છે અને સ્ટેજ પર જમાવવામાં આવે છે.

"માઈક્રો સર્વિસ ફ્રેગમેન્ટેશન" ના યુગને કેવી રીતે દૂર કરવું

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

વધુમાં, માઇક્રોસર્વિસ આર્કિટેક્ચરને અસરકારક બનાવવા માટે, ઘણી પ્રક્રિયાઓ સ્થાપિત કરવાની જરૂર છે, એટલે કે:

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

સિસ્ટમ તેની પ્રામાણિકતા ગુમાવે નહીં અને સ્કેલ કરતી વખતે અસરકારક રહે તેની ખાતરી કરવા માટે, અમે એવિટોમાં માઇક્રોસર્વિસિસના સંગઠન પર ફરીથી વિચાર કર્યો.

અમે કેવી રીતે માઇક્રોસર્વિસિસનું સંચાલન કરીએ છીએ

ઘણી અવિટો માઈક્રો સર્વિસીસ વચ્ચે એકીકૃત “પક્ષ નીતિ” ને અમલમાં મૂકવા માટે નીચેની મદદ:

• સ્તરોમાં માળખાગત વિભાજન;
• સેવા (PaaS) ખ્યાલ તરીકે પ્લેટફોર્મ;
• માઇક્રોસર્વિસિસ સાથે બનેલી દરેક વસ્તુનું નિરીક્ષણ કરવું.

ઈન્ફ્રાસ્ટ્રક્ચર એબ્સ્ટ્રેક્શન સ્તરોમાં ત્રણ સ્તરોનો સમાવેશ થાય છે. ચાલો ઉપરથી નીચે જઈએ.

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

બધા સ્તરો PaaS દ્વારા સંયુક્ત છે. અને આ પ્લેટફોર્મ, બદલામાં, ત્રણ ભાગો ધરાવે છે.

I. જનરેટર, CLI ઉપયોગિતા દ્વારા નિયંત્રિત. તે તે છે જે વિકાસકર્તાને યોગ્ય રીતે અને ઓછામાં ઓછા પ્રયત્નો સાથે માઇક્રોસર્વિસ બનાવવામાં મદદ કરે છે.

II. એકીકૃત કલેક્ટર સામાન્ય ડેશબોર્ડ દ્વારા તમામ સાધનોના નિયંત્રણ સાથે.

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

એવિટોમાં માઇક્રોસર્વિસિસનું અમલીકરણ પણ એક યોજના અનુસાર હાથ ધરવામાં આવે છે, જે વિકાસ અને પ્રકાશનના દરેક તબક્કે તેમના પર નિયંત્રણને સરળ બનાવે છે.

પ્રમાણભૂત માઇક્રોસર્વિસ ડેવલપમેન્ટ પાઇપલાઇન કેવી રીતે કાર્ય કરે છે?

સામાન્ય રીતે, માઇક્રોસર્વિસ બનાવટની સાંકળ આના જેવી દેખાય છે:

CLI-પુશ → સતત એકીકરણ → બેક → ડિપ્લોય → કૃત્રિમ પરીક્ષણો → કેનેરી પરીક્ષણો → સ્ક્વિઝ પરીક્ષણ → ઉત્પાદન → જાળવણી.

ચાલો આ ક્રમમાં બરાબર તેમાંથી પસાર થઈએ.

CLI- દબાણ

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

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

— ટેમ્પલેટ પ્રમાણે સેવા બનાવે છે — સ્ટેપ બાય સ્ટેપ, “વિઝાર્ડ” મોડમાં. અમારી પાસે એવિટો બેકએન્ડમાં મુખ્ય પ્રોગ્રામિંગ ભાષાઓ માટે નમૂનાઓ છે: PHP, ગોલાંગ અને પાયથોન.

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

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

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

- ઓટોટેસ્ટ જનરેટ કરે છે. બ્લેન્ક્સના સ્વરૂપમાં, પરંતુ ઉપયોગ માટે એકદમ યોગ્ય.

• માઇક્રોસર્વિસ જમાવટ.

માઇક્રોસર્વિસને જમાવવું એ અમારા માટે થોડું કામ હતું. નીચેના જરૂરી હતા:

I. ડોકરફાઈલ.

II. રૂપરેખા.
III. હેલ્મ ચાર્ટ, જે પોતે જ બોજારૂપ છે અને તેમાં શામેલ છે:

- ચાર્ટ પોતે;
- નમૂનાઓ;
- વિવિધ વાતાવરણને ધ્યાનમાં લેતા ચોક્કસ મૂલ્યો.

અમે કુબરનેટ્સ મેનિફેસ્ટને ફરીથી કામ કરવાથી પીડાને દૂર કરી લીધી છે જેથી તે હવે આપમેળે જનરેટ થાય છે. પરંતુ સૌથી અગત્યનું, તેઓએ જમાવટને મર્યાદા સુધી સરળ બનાવી. હવેથી અમારી પાસે એક Dockerfile છે, અને વિકાસકર્તા એક જ ટૂંકી app.toml ફાઇલમાં સમગ્ર રૂપરેખા લખે છે.

હા, અને app.toml માં જ એક મિનિટ માટે કંઈ કરવાનું નથી. અમે ઉલ્લેખિત કરીએ છીએ કે સેવાની ક્યાં અને કેટલી નકલો ઊભી કરવી (દેવ સર્વર પર, સ્ટેજિંગ પર, ઉત્પાદનમાં), અને તેની નિર્ભરતા સૂચવીએ છીએ. [એન્જિન] બ્લોકમાં લાઇનના કદ = "નાના" પર ધ્યાન આપો. આ તે મર્યાદા છે જે કુબરનેટ્સ દ્વારા સેવાને ફાળવવામાં આવશે.

પછી, રૂપરેખાના આધારે, તમામ જરૂરી હેલ્મ ચાર્ટ્સ આપમેળે જનરેટ થાય છે અને ડેટાબેઝ સાથે જોડાણો બનાવવામાં આવે છે.

• મૂળભૂત માન્યતા. આવા ચેક પણ ઓટોમેટેડ હોય છે.
ટ્રૅક કરવાની જરૂર છે:
- ત્યાં કોઈ ડોકરફાઈલ છે;
— ત્યાં app.toml છે;
- શું ત્યાં દસ્તાવેજો ઉપલબ્ધ છે?
- નિર્ભરતા ક્રમમાં છે?
- શું ચેતવણી નિયમો સેટ કરવામાં આવ્યા છે.
છેલ્લા મુદ્દા સુધી: સેવાના માલિક પોતે નક્કી કરે છે કે કયા ઉત્પાદન મેટ્રિક્સનું નિરીક્ષણ કરવું.

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

I. સેવાનું સંક્ષિપ્ત વર્ણન. તે શું કરે છે અને શા માટે તેની જરૂર છે તે વિશે શાબ્દિક રીતે થોડા વાક્યો.

II. આર્કિટેક્ચર ડાયાગ્રામ લિંક. તે મહત્વનું છે કે તેના પર એક ઝડપી નજર નાખતા તે સમજવું સરળ છે, ઉદાહરણ તરીકે, તમે કેશીંગ માટે Redisનો ઉપયોગ કરી રહ્યાં છો કે પર્સિસ્ટન્ટ મોડમાં મુખ્ય ડેટા સ્ટોર તરીકે. એવિટોમાં અત્યારે આ સંગમની લિંક છે.

III. રનબુક. સેવા શરૂ કરવા પર ટૂંકી માર્ગદર્શિકા અને તેને હેન્ડલ કરવાની જટિલતાઓ.

IV. FAQ, જ્યાં સેવા સાથે કામ કરતી વખતે તમારા સહકાર્યકરોને આવી શકે તેવી સમસ્યાઓની અપેક્ષા રાખવી સારી રહેશે.

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

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

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

છેલ્લે, કોડ સમીક્ષાની જેમ દસ્તાવેજીકરણની સમીક્ષા કરવી એ સારી પ્રથા છે.

સતત એકીકરણ

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

ગરમીથી પકવવું

આગળનો તબક્કો જમાવટ પહેલાં પેકેજિંગ સેવાઓ છે.

• એપ્લિકેશનનું નિર્માણ. ક્લાસિક અનુસાર - ડોકર છબીમાં.
• સેવા અને સંબંધિત સંસાધનો માટે હેલ્મ ચાર્ટનું નિર્માણ. ડેટાબેસેસ અને કેશ સહિત. તે app.toml રૂપરેખા અનુસાર આપમેળે બનાવવામાં આવે છે જે CLI-પુશ સ્ટેજ પર જનરેટ કરવામાં આવી હતી.
• પોર્ટ ખોલવા માટે એડમિન માટે ટિકિટો બનાવી રહ્યા છીએ (જ્યારે જરૂરી હોય ત્યારે).
• એકમ પરીક્ષણો ચલાવવું અને કોડ કવરેજની ગણતરી કરવી. જો કોડ કવરેજ નિર્દિષ્ટ થ્રેશોલ્ડથી નીચે છે, તો સંભવતઃ સેવા આગળ નહીં જાય - જમાવટ માટે. જો તે સ્વીકાર્ય થવાની ધાર પર છે, તો સેવાને "નિરાશાજનક" ગુણાંક સોંપવામાં આવશે: પછી, જો સમય જતાં સૂચકમાં કોઈ સુધારો થયો નથી, તો વિકાસકર્તાને સૂચના પ્રાપ્ત થશે કે પરીક્ષણોની દ્રષ્ટિએ કોઈ પ્રગતિ નથી ( અને તેના વિશે કંઈક કરવાની જરૂર છે).
• મેમરી અને CPU મર્યાદાઓ માટે એકાઉન્ટિંગ. અમે મુખ્યત્વે ગોલાંગમાં માઇક્રોસર્વિસ લખીએ છીએ અને તેને કુબરનેટ્સમાં ચલાવીએ છીએ. આથી ગોલાંગ ભાષાની વિશિષ્ટતા સાથે સંકળાયેલ એક સૂક્ષ્મતા: મૂળભૂત રીતે, જ્યારે તમે GOMAXPROCS વેરીએબલને સ્પષ્ટપણે સેટ ન કરો તો, મશીન પરના તમામ કોરોનો ઉપયોગ કરવામાં આવે છે, અને જ્યારે તે જ મશીન પર આવી ઘણી સેવાઓ શરૂ કરવામાં આવે છે, ત્યારે તે શરૂ થાય છે. સંસાધનો માટે સ્પર્ધા કરવા, એકબીજા સાથે દખલ કરવી. નીચે આપેલા આલેખ બતાવે છે કે જો તમે કોઈ વિવાદ વિના અને સંસાધન મોડની રેસમાં એપ્લિકેશન ચલાવો તો અમલીકરણનો સમય કેવી રીતે બદલાય છે. (ગ્રાફના સ્ત્રોતો છે અહીં).

એક્ઝેક્યુશન સમય, ઓછો સારો છે. મહત્તમ: 643ms, ન્યૂનતમ: 42ms. ફોટો ક્લિક કરવા યોગ્ય છે.

શસ્ત્રક્રિયા માટે સમય, ઓછો સારો છે. મહત્તમ: 14091 એનએસ, ન્યૂનતમ: 151 એનએસ. ફોટો ક્લિક કરવા યોગ્ય છે.

એસેમ્બલી તૈયારીના તબક્કે, તમે આ ચલને સ્પષ્ટ રીતે સેટ કરી શકો છો અથવા તમે લાઇબ્રેરીનો ઉપયોગ કરી શકો છો automaxprocs ઉબેરના લોકો પાસેથી.

જમાવટ કરો

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

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

કૃત્રિમ પરીક્ષણો

• બંધ લૂપ પરીક્ષણ. આ માટે આપણે હવે ઓપન સોર્સનો ઉપયોગ કરી રહ્યા છીએ Hoverfly.io. પ્રથમ, તે સેવા પરના વાસ્તવિક ભારને રેકોર્ડ કરે છે, પછી - ફક્ત બંધ લૂપમાં - તે તેનું અનુકરણ કરે છે.

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

લોડ પરીક્ષણ દરમિયાન, અમે તપાસીએ છીએ કે સંસાધન વપરાશ નિર્ધારિત મર્યાદાઓને પૂર્ણ કરે છે કે કેમ. અને અમે મુખ્યત્વે ચરમસીમા પર ધ્યાન કેન્દ્રિત કરીએ છીએ.

a) અમે કુલ ભારને જોઈએ છીએ.
- ખૂબ નાનું - જો ભાર અચાનક ઘણી વખત ઘટી જાય તો સંભવતઃ કંઈક કામ કરતું નથી.
- ખૂબ મોટું - ઑપ્ટિમાઇઝેશન જરૂરી છે.

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

કેનેરી પરીક્ષણો

અમે સિન્થેટિક પરીક્ષણો પાસ કર્યા પછી, અમે ઓછી સંખ્યામાં વપરાશકર્તાઓ પર માઇક્રોસર્વિસનું પરીક્ષણ કરીએ છીએ. અમે સેવાના ઉદ્દેશ્ય પ્રેક્ષકોના નાના હિસ્સા સાથે - 0,1% કરતા ઓછા સાથે, કાળજીપૂર્વક પ્રારંભ કરીએ છીએ. આ તબક્કે, તે ખૂબ જ મહત્વપૂર્ણ છે કે યોગ્ય તકનીકી અને ઉત્પાદન મેટ્રિક્સ મોનિટરિંગમાં શામેલ છે જેથી તેઓ શક્ય તેટલી ઝડપથી સેવામાં સમસ્યા દર્શાવે. કેનેરી ટેસ્ટ માટે લઘુત્તમ સમય 5 મિનિટ છે, મુખ્ય 2 કલાક છે. જટિલ સેવાઓ માટે, અમે મેન્યુઅલી સમય સેટ કરીએ છીએ.
ચાલો વિશ્લેષણ કરીએ:
— ભાષા-વિશિષ્ટ મેટ્રિક્સ, ખાસ કરીને, php-fpm કામદારો;
- સંત્રીમાં ભૂલો;
- પ્રતિભાવ સ્થિતિઓ;
- પ્રતિભાવ સમય, ચોક્કસ અને સરેરાશ;
- વિલંબતા;
- અપવાદો, પ્રોસેસ્ડ અને અનહેન્ડલ;
- ઉત્પાદન મેટ્રિક્સ.

સ્ક્વિઝ ટેસ્ટિંગ

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

ઉત્પાદન

• સ્કેલિંગ. જ્યારે અમે કોઈ સેવાને ઉત્પાદન માટે રોલ આઉટ કરીએ છીએ, ત્યારે અમે તે કેવી રીતે સ્કેલ કરે છે તેનું નિરીક્ષણ કરીએ છીએ. અમારા અનુભવમાં, માત્ર CPU સૂચકાંકોનું નિરીક્ષણ કરવું બિનઅસરકારક છે. RPS બેન્ચમાર્કિંગ સાથે ઓટો સ્કેલિંગ તેના શુદ્ધ સ્વરૂપમાં કામ કરે છે, પરંતુ માત્ર અમુક સેવાઓ માટે, જેમ કે ઑનલાઇન સ્ટ્રીમિંગ. તેથી અમે એપ્લિકેશન-વિશિષ્ટ ઉત્પાદન મેટ્રિક્સને પ્રથમ જોઈએ છીએ.

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

સેવાને સ્કેલ કરતી વખતે, તેની અવલંબનનું નિરીક્ષણ કરવું પણ મહત્વપૂર્ણ છે જેથી અમે સાંકળમાં પ્રથમ સેવાને સ્કેલ ન કરીએ અને જે તે ઍક્સેસ કરે છે તે લોડ હેઠળ નિષ્ફળ જાય. સેવાઓના સમગ્ર પૂલ માટે સ્વીકાર્ય લોડ સ્થાપિત કરવા માટે, અમે "નજીકની" આશ્રિત સેવાના ઐતિહાસિક ડેટાને જોઈએ છીએ (CPU અને RAM સૂચકાંકોના સંયોજનના આધારે, એપ્લિકેશન-વિશિષ્ટ મેટ્રિક્સ સાથે જોડીને) અને ઐતિહાસિક ડેટા સાથે તેમની તુલના કરીએ છીએ. આરંભિક સેવા, અને તેથી ઉપરથી નીચે સુધી સમગ્ર “નિર્ભરતા સાંકળ” "માં.

સેવા

માઇક્રોસર્વિસ કાર્યરત થયા પછી, અમે તેની સાથે ટ્રિગર્સ જોડી શકીએ છીએ.

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

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

ડેશબોર્ડ

ટૂંકમાં, ડેશબોર્ડ એ આપણા સમગ્ર PaaSનું કંટ્રોલ પેનલ છે.

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

કુલ

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

મેં HighLoad++ 2018 માટે આ વિષય પર એક રિપોર્ટ આપ્યો છે, તમે તેને જોઈ શકો છો видео и રજૂઆત.

જેઓ અંત સુધી વાંચે છે તેમના માટે બોનસ ટ્રેક

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

આ તાલીમ મોસ્કોમાં 5 થી 7 ઓગસ્ટ દરમિયાન યોજાશે. આ કામકાજના દિવસો છે જે સંપૂર્ણ રીતે કબજે કરવામાં આવશે. બપોરના ભોજન અને તાલીમ અમારી ઓફિસમાં હશે, અને પસંદ કરેલ સહભાગી મુસાફરી અને રહેઠાણ માટે પોતે ચૂકવણી કરશે.

તમે ભાગ લેવા માટે અરજી કરી શકો છો આ ગૂગલ ફોર્મમાં. તમારા તરફથી - તમારે શા માટે તાલીમમાં હાજરી આપવાની જરૂર છે તે પ્રશ્નનો જવાબ અને તમારો સંપર્ક કેવી રીતે કરવો તેની માહિતી. અંગ્રેજીમાં જવાબ આપો, કારણ કે ક્રિસ તે સહભાગીને પસંદ કરશે જે પોતે તાલીમમાં હાજરી આપશે.
અમે આ પોસ્ટના અપડેટમાં અને વિકાસકર્તાઓ માટેના સોશિયલ નેટવર્ક્સ Avito પર તાલીમ સહભાગીનું નામ જાહેર કરીશું (AvitoTech in ફેસબુક, Вконтакте, ટ્વિટર) 19 જુલાઈ પછી નહીં.

સોર્સ: www.habr.com