વિતરિત એપ્લિકેશનોના બિલ્ડીંગ બ્લોક્સ. શૂન્ય અંદાજ

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

પરિચય

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

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

સૈદ્ધાંતિક આધાર

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

ચાલો અંતિમ સિસ્ટમ માટે 4 મુખ્ય આવશ્યકતાઓને પ્રકાશિત કરીએ:

• Сઘટના લક્ષી.
  સિસ્ટમ હંમેશા ઘટનાઓના પ્રવાહમાંથી પસાર થવા અને જરૂરી ક્રિયાઓ કરવા માટે તૈયાર છે;
• Мમાપનીયતા
  વ્યક્તિગત બ્લોક્સને ઊભી અને આડી બંને રીતે માપી શકાય છે. સમગ્ર સિસ્ટમ અનંત આડી વૃદ્ધિ માટે સક્ષમ હોવી જોઈએ;
• Оસહનશીલતા દોષ.
  તમામ સ્તરો અને બધી સેવાઓ આપમેળે નિષ્ફળતાઓમાંથી પુનઃપ્રાપ્ત કરવામાં સક્ષમ હોવી જોઈએ;
• Гખાતરીપૂર્વકનો પ્રતિભાવ સમય.
  સમય મૂલ્યવાન છે અને વપરાશકર્તાઓએ વધુ રાહ જોવી જોઈએ નહીં.

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

ઇન્ફ્રાસ્ટ્રક્ચર ટૂલ અને તમામ સેવાઓ માટેના આધાર તરીકે મેસેજિંગમાં એક વધુ મુદ્દો ઉમેરવામાં આવ્યો છે: પ્રોગ્રામરો માટે ઉપયોગમાં સરળતા.

ઘટનાલક્ષી

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

માપનીયતા

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

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

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

વ્યવસાયના દૃષ્ટિકોણથી, માપનીયતા એ જોખમ વ્યવસ્થાપન સાધનોમાંનું એક છે. મુખ્ય વસ્તુ એ છે કે સાધનસામગ્રીનો શ્રેષ્ઠ ઉપયોગ કરીને ગ્રાહકની વિનંતીઓને સંતોષવી:

• જ્યારે પ્રગતિના પરિણામે સાધનોની શક્તિ વધે છે. અપૂર્ણ સોફ્ટવેરને કારણે તે નિષ્ક્રિય રહેશે નહીં. એર્લાંગ વર્ટિકલી સારી રીતે સ્કેલ કરે છે અને હંમેશા તમામ CPU કોરો અને ઉપલબ્ધ મેમરીનો ઉપયોગ કરવામાં સક્ષમ હશે;
• ક્લાઉડ વાતાવરણમાં, અમે વર્તમાન અથવા અનુમાનિત લોડ અને બાંયધરી SLA ના આધારે સાધનોની માત્રાનું સંચાલન કરી શકીએ છીએ.

સહનશીલતા દોષ

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

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

પ્રતિભાવ

નિષ્ફળતાઓને ધ્યાનમાં લીધા વિના, એપ્લિકેશને વિનંતીઓનો જવાબ આપવો જોઈએ અને SLA ને મળવું જોઈએ. વાસ્તવિકતા એ છે કે લોકો રાહ જોવા માંગતા નથી, તેથી વ્યવસાયોએ તે મુજબ અનુકૂલન કરવું આવશ્યક છે. વધુ અને વધુ એપ્લિકેશનો અત્યંત પ્રતિભાવશીલ હોવાની અપેક્ષા છે.
રિસ્પોન્સિવ એપ્લિકેશંસ નજીકના વાસ્તવિક સમયમાં કાર્ય કરે છે. Erlang VM સોફ્ટ રીઅલ-ટાઇમ મોડમાં કાર્ય કરે છે. કેટલાક ક્ષેત્રો માટે, જેમ કે સ્ટોક ટ્રેડિંગ, દવા અને ઔદ્યોગિક સાધનો નિયંત્રણ, હાર્ડ રીઅલ-ટાઇમ મોડ મહત્વપૂર્ણ છે.
રિસ્પોન્સિવ સિસ્ટમ્સ UX ને સુધારે છે અને વ્યવસાયને લાભ આપે છે.

પ્રારંભિક સારાંશ

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

પ્રથમ ભાગનો અંત.

ફોટો @લુકાબ્રાવો.

સોર્સ: www.habr.com