સર્વિસ મેશ: દરેક સૉફ્ટવેર એન્જિનિયરને સૌથી ગરમ તકનીક વિશે શું જાણવાની જરૂર છે

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

કોમિક થી સેબેસ્ટિયન કેસેરેસ

પરિચય

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

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

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

હું કોણ છું?

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

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

ઠીક છે, તે વસ્તુઓ ખાવાની તરફ આગળ વધવાનો સમય છે.

સેવા મેશ શું છે?

તમામ હાઇપ હોવા છતાં, સર્વિસ મેશ માળખાકીય રીતે એકદમ સરળ છે. તે ફક્ત "આગળ" સેવાઓ પર સ્થિત યુઝરસ્પેસ પ્રોક્સીઓનો સમૂહ છે (અમે પછીથી "નજીક" વિશે થોડી વાત કરીશું), ઉપરાંત નિયંત્રણ પ્રક્રિયાઓનો સમૂહ. પ્રોક્સીઓને સામૂહિક રીતે કહેવામાં આવે છે ડેટા પ્લેન, અને નિયંત્રણ પ્રક્રિયાઓ કહેવામાં આવે છે નિયંત્રણ વિમાન. ડેટા પ્લેન સેવાઓ વચ્ચેના કૉલ્સને અટકાવે છે અને તેમની સાથે "કંઈપણ અલગ" કરે છે; કંટ્રોલ પ્લેન, અનુક્રમે, પ્રોક્સીના વર્તનનું સંકલન કરે છે અને તમારા માટે ઍક્સેસ પ્રદાન કરે છે, એટલે કે. ઓપરેટર, API ને, નેટવર્કને ચાલાકી અને સમગ્ર રીતે માપવા માટે પરવાનગી આપે છે.

આ પ્રોક્સી શું છે? આ "લેયર 7-અવેર" શ્રેણીની TCP પ્રોક્સી છે (એટલે ​​​​કે OSI મોડેલના 7મા સ્તરને "ધ્યાનમાં લેવું") જેમ કે HAProxy અને NGINX. તમે તમારી રુચિ અનુસાર પ્રોક્સી પસંદ કરી શકો છો; Linkerd એક રસ્ટ પ્રોક્સીનો ઉપયોગ કરે છે, જેનું નામ જટિલ નથી લિંકર્ડ-પ્રોક્સી. અમે તેને ખાસ કરીને સર્વિસ મેશ માટે કમ્પાઈલ કર્યું છે. અન્ય મેશ અન્ય પ્રોક્સીને પસંદ કરે છે (દૂત એ સામાન્ય પસંદગી છે). જો કે, પ્રોક્સી પસંદ કરવી એ માત્ર અમલીકરણની બાબત છે.

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

તેથી, અમે ડેટા પ્લેન શોધી કાઢ્યું. કંટ્રોલ પ્લેન વધુ સરળ છે: તે એવા ઘટકોનો સમૂહ છે જે ડેટા પ્લેનને સંકલિત રીતે કામ કરવા માટે જરૂરી તમામ મિકેનિક્સ પ્રદાન કરે છે, જેમાં સેવાની શોધ, TLS પ્રમાણપત્ર જારી, મેટ્રિક્સ એકત્રીકરણ વગેરેનો સમાવેશ થાય છે. ડેટા પ્લેન નિયંત્રણ પ્લેનને તેના વિશે જાણ કરે છે. તેનું વર્તન; બદલામાં, કંટ્રોલ પ્લેન એક API પ્રદાન કરે છે જે તમને સમગ્ર ડેટા પ્લેનની વર્તણૂક બદલવા અને ટ્રૅક કરવાની મંજૂરી આપે છે.

નીચે લિંકર્ડમાં કંટ્રોલ પ્લેન અને ડેટા પ્લેનનો ડાયાગ્રામ છે. જેમ તમે જોઈ શકો છો, કંટ્રોલ પ્લેનમાં પ્રોમીથિયસ દાખલા સહિત ઘણા જુદા જુદા ઘટકોનો સમાવેશ થાય છે જે પ્રોક્સી સર્વર્સમાંથી મેટ્રિક્સ એકત્રિત કરે છે, તેમજ અન્ય ઘટકો જેમ કે destination (સેવા શોધ), identity (પ્રમાણપત્ર સત્તાધિકારી, CA) અને public-api (વેબ અને CLI માટે અંતિમ બિંદુઓ). તેનાથી વિપરીત, ડેટા પ્લેન એ એપ્લિકેશનના દાખલાની બાજુમાં એક સરળ લિંકર્ડ-પ્રોક્સી છે. આ માત્ર એક લોજિક ડાયાગ્રામ છે; વાસ્તવિક દુનિયામાં જમાવટમાં, તમારી પાસે દરેક કંટ્રોલ પ્લેન ઘટકની ત્રણ પ્રતિકૃતિઓ અને ડેટા પ્લેનમાં સેંકડો અથવા હજારો પ્રોક્સી હોઈ શકે છે.

(આ રેખાકૃતિમાંના વાદળી બોક્સ કુબરનેટીસ પોડ્સની સરહદો દર્શાવે છે. તમે જોઈ શકો છો કે લિંકર્ડ-પ્રોક્સીવાળા કન્ટેનર એપ્લીકેશન કન્ટેનર જેવા જ પોડમાં છે. આ સ્કીમ તરીકે ઓળખાય છે. સાઇડકાર કન્ટેનર.)

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

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

1. ડેટા પ્લેનમાં પ્રોક્સીઓ હોવી જોઈએ ઝડપી, કારણ કે દરેક કૉલ માટે પ્રોક્સીને બે કૉલ્સ હોય છે: એક ક્લાયંટ બાજુ પર, એક સર્વર બાજુ પર.
2. પણ, પ્રોક્સીઓ હોવા જ જોઈએ નાનું и હલકો. દરેક મેમરી અને CPU સંસાધનોનો ઉપયોગ કરશે, અને આ વપરાશ એપ્લિકેશન સાથે રેખીય રીતે વધશે.
3. મોટી સંખ્યામાં પ્રોક્સીઓ જમાવવા અને અપડેટ કરવા માટે તમારે એક મિકેનિઝમની જરૂર પડશે. તે જાતે કરવું એ કોઈ વિકલ્પ નથી.

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

તે પ્રશ્ન માટે સમય છે "શા માટે?"

સેવા મેશ શેના માટે છે?

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

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

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

ઉદાહરણ તરીકે, Linkerd માં (મોટા ભાગના મેશની જેમ) કાર્યક્ષમતા મુખ્યત્વે HTTP/2 અને gRPC* સહિત HTTP કૉલ્સ પર કેન્દ્રિત છે. કાર્યક્ષમતા ખૂબ સમૃદ્ધ છે - તેને ત્રણ વર્ગોમાં વહેંચી શકાય છે:

1. સંબંધિત લક્ષણો વિશ્વસનીયતા. વિનંતીઓ, સમયસમાપ્તિ, કેનેરી અભિગમ (ટ્રાફિક સ્પ્લિટ/રીડાયરેક્ટ) વગેરેનો ફરી પ્રયાસ કરો.
2. સંબંધિત લક્ષણો દેખરેખ. દરેક સેવા અથવા વ્યક્તિગત ગંતવ્ય માટે સફળતા દર, વિલંબ અને વિનંતી વોલ્યુમનું એકત્રીકરણ; સેવાઓના ટોપોલોજિકલ નકશા બનાવવા વગેરે.
3. સંબંધિત લક્ષણો સુરક્ષા. મ્યુચ્યુઅલ TLS, એક્સેસ કંટ્રોલ, વગેરે.

* Linkerd ના દૃષ્ટિકોણથી, gRPC વ્યવહારીક રીતે HTTP/2 થી અલગ નથી: તે માત્ર પેલોડમાં પ્રોટોબફનો ઉપયોગ કરે છે. વિકાસકર્તાના દૃષ્ટિકોણથી, આ બે વસ્તુઓ, અલબત્ત, અલગ છે.

આમાંની ઘણી પદ્ધતિઓ વિનંતી સ્તરે કાર્ય કરે છે (તેથી "L7 પ્રોક્સી"). ઉદાહરણ તરીકે, જો સેવા ફૂ સેવા બારને HTTP કૉલ કરે છે, તો ફૂની બાજુ પરની લિંકર્ડ-પ્રોક્સી બુદ્ધિપૂર્વક લોડ-બેલેન્સ કરી શકે છે અને અવલોકન કરાયેલ વિલંબના આધારે Foo થી બાર દાખલાઓને રૂટ કરી શકે છે; જો જરૂરી હોય તો તે વિનંતીને પુનરાવર્તિત કરી શકે છે (અને જો તે નિર્બળ હોય તો); તે પ્રતિભાવ કોડ અને સમયસમાપ્તિ, વગેરે રેકોર્ડ કરી શકે છે. તેવી જ રીતે, બાર બાજુ પર લિંકર્ડ-પ્રોક્સી વિનંતીને નકારી શકે છે જો તેને મંજૂરી ન હોય અથવા વિનંતી મર્યાદા ઓળંગાઈ ગઈ હોય; તેના ભાગ પર વિલંબને ઠીક કરી શકે છે, વગેરે.

પ્રોક્સીઓ કનેક્શન સ્તરે પણ "કંઈક કરી શકે છે". ઉદાહરણ તરીકે, Foo બાજુ પર લિંકર્ડ-પ્રોક્સી TLS કનેક્શન શરૂ કરી શકે છે, અને બાર બાજુ પર લિંકર્ડ-પ્રોક્સી તેને સમાપ્ત કરી શકે છે, અને બંને પક્ષો એકબીજાના TLS પ્રમાણપત્રો* ચકાસી શકે છે. આ માત્ર સેવાઓ વચ્ચે એન્ક્રિપ્શન જ નહીં, પરંતુ સેવાઓને ઓળખવાની ક્રિપ્ટોગ્રાફિકલી સુરક્ષિત રીત પણ પ્રદાન કરે છે: Foo અને Bar "સાબિત" કરી શકે છે કે તેઓ જે કહે છે તે તેઓ છે.

* "મિત્રનો મિત્ર" નો અર્થ છે કે ક્લાયંટનું પ્રમાણપત્ર પણ ચકાસાયેલ છે (પરસ્પર TLS). "ક્લાસિક" TLS માં, ઉદાહરણ તરીકે, બ્રાઉઝર અને સર્વર વચ્ચે, સામાન્ય રીતે માત્ર એક બાજુ (સર્વર)નું પ્રમાણપત્ર ચકાસવામાં આવે છે.

ભલે તેઓ વિનંતી અથવા કનેક્શન સ્તરે કાર્ય કરે છે, તે ભારપૂર્વક જણાવવું મહત્વપૂર્ણ છે કે તમામ સેવા મેશ સુવિધાઓ છે ઓપરેશનલ પાત્ર Linkerd પેલોડના અર્થશાસ્ત્રને રૂપાંતરિત કરવામાં અસમર્થ છે, જેમ કે JSON ફ્રેગમેન્ટમાં ફીલ્ડ ઉમેરવા અથવા પ્રોટોબફમાં ફેરફારો કરવા. જ્યારે આપણે ESB અને મિડલવેર વિશે વાત કરીશું ત્યારે અમે આ મહત્વપૂર્ણ સુવિધા વિશે પછીથી વાત કરીશું.

આ તે સુવિધાઓનો સમૂહ છે જે સેવા મેશ ઓફર કરે છે. પ્રશ્ન ઊભો થાય છે: શા માટે તેમને એપ્લિકેશનમાં સીધા જ અમલમાં મૂકતા નથી? અને પ્રોક્સી સાથે બિલકુલ ગડબડ શા માટે?

સર્વિસ મેશ શા માટે સારો વિચાર છે

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

ચાલો આ પ્રસ્તાવનું વિશ્લેષણ કરીએ.

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

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

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

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

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

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

સર્વિસ મેશ કોને મદદ કરે છે?

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

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

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

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

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

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

ટૂંકમાં, સર્વિસ મેશ, તેના બદલે, તકનીકી ઉકેલ નથી, પરંતુ સામાજિક-તકનીકી સમસ્યાઓ. (આભાર સિન્ડી શ્રીધરન આ શબ્દની રજૂઆત માટે.

શું સર્વિસ મેશ મારી બધી સમસ્યાઓ હલ કરશે?

હા. મારો મતલબ, ના!

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

સેવા મેશ દ્વારા ઓફર કરવામાં આવતી આ ક્ષેત્રોમાં સુવિધાઓનો સબસેટ સંબંધિત છે પ્લેટફોર્મ સુવિધાઓ. આ દ્વારા મારો અર્થ એવા કાર્યો છે કે:

1. વ્યવસાયના તર્કથી સ્વતંત્ર. ફૂ અને બાર વચ્ચે જે રીતે કોલ હિસ્ટોગ્રામ બનાવવામાં આવે છે તે સંપૂર્ણપણે સ્વતંત્ર છે કે કેમ શા માટે ફૂ બારને બોલાવે છે.
2. યોગ્ય રીતે અમલમાં મૂકવું મુશ્કેલ છે. Linkerd માં, પુનઃપ્રયાસોને તમામ પ્રકારની ફેન્સી સામગ્રી જેમ કે પુનઃપ્રયાસ બજેટ સાથે પરિમાણિત કરવામાં આવે છે. (બજેટનો ફરી પ્રયાસ કરો), કારણ કે આવી બાબતોને અમલમાં મૂકવા માટે એક અસંસ્કારી, મુખ્ય અભિગમ ચોક્કસપણે કહેવાતા "વિનંતોનો હિમપ્રપાત" ના ઉદભવ તરફ દોરી જશે. (તોફાન ફરી પ્રયાસ કરો) અને વિતરિત સિસ્ટમો માટે વિશિષ્ટ અન્ય સમસ્યાઓ.
3. જ્યારે સતત લાગુ કરવામાં આવે ત્યારે સૌથી વધુ અસરકારક. TLS મિકેનિઝમ માત્ર ત્યારે જ અર્થપૂર્ણ બને છે જો દરેક જગ્યાએ લાગુ કરવામાં આવે.

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

સેવા મેશ ક્ષમતાઓના ઉદાહરણો

સારાંશમાં, સર્વિસ મેશ એ વિશ્વસનીયતા, અવલોકનક્ષમતા અથવા સુરક્ષા માટે સંપૂર્ણ ઉકેલ નથી. આ ક્ષેત્રોનો અવકાશ સેવા માલિકો, Ops/SRE ટીમો અને અન્ય કંપનીના હિસ્સેદારોની ફરજિયાત ભાગીદારી સૂચવે છે. સેવા મેશ આ દરેક વિસ્તારો માટે પ્લેટફોર્મ સ્તર પર માત્ર "સ્લાઈસ" પ્રદાન કરે છે.

શા માટે સેવા મેશ હમણાં લોકપ્રિય બની છે?

તમે કદાચ અત્યારે આશ્ચર્ય પામી રહ્યા છો: ઠીક છે, જો સર્વિસ મેશ એટલી સારી છે, તો અમે દસ વર્ષ પહેલાં સ્ટેક પર લાખો પ્રોક્સીઓ કેમ જમાવવાનું શરૂ ન કર્યું?

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

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

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

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

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

ચાલો વર્તમાન તરફ જઈએ. આજે એવા સ્ટાર્ટઅપ્સ છે જ્યાં વિકાસકર્તાઓ માટે માઇક્રોસર્વિસિસનો ગુણોત્તર 5:1 (અથવા તો 10:1), અને વધુમાં, તેઓ સફળતાપૂર્વક તેમની સાથે સામનો કરે છે! જો 5 લોકોનું સ્ટાર્ટઅપ તાણ વિના 50 માઇક્રોસર્વિસિસનું સંચાલન કરવામાં સક્ષમ છે, તો કંઈક સ્પષ્ટપણે તેમના અમલીકરણની કિંમતમાં ઘટાડો કરે છે.

મોન્ઝોમાં 1500 માઇક્રોસર્વિસિસ; દરેક લાઇન એક નિર્ધારિત નેટવર્ક નિયમ છે જે ટ્રાફિકને મંજૂરી આપે છે

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

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

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

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

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

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

સેવા મેશ વિશે આટલી બધી ચર્ચા શા માટે છે?

નિવારણ: આ વિભાગમાં, હું તમામ પ્રકારની ધારણાઓ, અનુમાન, બનાવટ અને આંતરિક માહિતીનો આશરો લઉં છું.

"સર્વિસ મેશ" માટે શોધ કરો અને તમને એક ટન રિસાયકલ ઓછી કેલરી સામગ્રી, વિચિત્ર પ્રોજેક્ટ્સ અને ઇકો ચેમ્બર માટે યોગ્ય વિકૃતિનો કેલિડોસ્કોપ મળશે. કોઈપણ ફેન્સી નવી ટેકનોલોજી આ કરે છે, પરંતુ સર્વિસ મેશના કિસ્સામાં સમસ્યા ખાસ કરીને તીવ્ર છે. શા માટે?

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

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

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

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

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

1. Google દ્વારા Istio નું બાધ્યતા પ્રચાર;
2. પ્રોજેક્ટ પ્રત્યે યોગ્ય નામંજૂર, ટીકાત્મક વલણ;
3. કુબરનેટીસની તાજેતરની ગગનચુંબી લોકપ્રિયતા, જેની સ્મૃતિ હજુ પણ તાજી છે.

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

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

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

ત્યાં સુધી, આપણે બધાએ ધીરજ રાખવી પડશે.

શું સેવા મેશ મારા માટે ઉપયોગી થશે, એક સાધારણ સોફ્ટવેર એન્જિનિયર?

નીચેની પ્રશ્નાવલી આ પ્રશ્નનો જવાબ આપવામાં મદદ કરશે:

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

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

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

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

નિષ્કર્ષ

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

હું ઈચ્છું છું કે તમે Linkerd ને અજમાવો - તેને Kubernetes ક્લસ્ટરમાં ઇન્સ્ટોલ કરો (અથવા લેપટોપ પર પણ Minikube) લગભગ 60 સેકન્ડ લાગે છેઅને તમે તમારા માટે જોઈ શકો છો કે હું જેની વાત કરું છું.

FAQ

- જો હું સર્વિસ મેશની અવગણના કરું, તો શું તે અદૃશ્ય થઈ જશે?
- મારે તમને નિરાશ કરવું જોઈએ: સેવા મેશ લાંબા સમયથી અમારી સાથે છે.

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

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

- સર્વિસ મેશ API ગેટવેથી કેવી રીતે અલગ છે?
આ વિષય પર એક મિલિયન લેખો છે. ફક્ત ગૂગલ.

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

- નેટવર્ક સર્વિસ મેશ - શું તે સર્વિસ મેશ છે?
- ના. નામ હોવા છતાં, આ કોઈ સર્વિસ મેશ નથી (તમે માર્કેટિંગની અજાયબીઓ કેવી રીતે પસંદ કરો છો?).

- શું સેવા મેશ સંદેશ કતાર પર આધારિત મારી પ્રતિક્રિયાશીલ અસુમેળ સિસ્ટમમાં મદદ કરશે?
- ના, સર્વિસ મેશ તમને મદદ કરશે નહીં.

- મારે કઈ સેવા મેશનો ઉપયોગ કરવો જોઈએ?
- લિંકર્ડ, બુદ્ધિહીન.

- લેખ નકામા છે! / લેખક - સાબુ પર!
- કૃપા કરીને તેની લિંક તમારા બધા મિત્રો સાથે શેર કરો જેથી તેઓને આ અંગે ખાતરી થઈ શકે!

સ્વીકૃતિઓ

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

જ્યારે હું મારી જાતને "લિંકર્ડ ડેવલપર" કહેવાનું પસંદ કરું છું, ત્યારે વાસ્તવિકતા એ છે કે હું પ્રોજેક્ટમાં README.md ફાઇલનો વધુ જાળવણી કરનાર છું. આજે Linkerd પર કામ કરે છે ખૂબ જ, ખૂબ જ, ખૂબ જ много લોકો, અને આ પ્રોજેક્ટ ફાળો આપનારાઓ અને વપરાશકર્તાઓના અદ્ભુત સમુદાય વિના શક્ય ન હોત.

અને અંતે, Linkerd ના સર્જકનો વિશેષ આભાર, ઓલિવર ગોલ્ડ (પ્રાઈમસ ઇન્ટર પેરેસ), જેમણે ઘણા વર્ષો પહેલા મારી સાથે, સર્વિસ મેશ સાથે આ બધી હલચલમાં ડૂબકી લગાવી હતી.

અનુવાદક તરફથી પીએસ

અમારા બ્લોગ પર પણ વાંચો:

• «સર્વિસ મેશ શું છે અને મને તેની [માઈક્રોસર્વિસ સાથે ક્લાઉડ એપ્લિકેશન માટે] શા માટે જરૂર છે?»;
• «ટ્રેફિક 2.0: TCP સપોર્ટ અને નવા વેબ ઇન્ટરફેસ સાથે સર્વિસ મેશ અપડેટ»;
• «Maesh - Traefik ના લેખકો તરફથી Kubernetes માટે એક નવું સરળ સેવા મેશ»;
• «Istio સાથે માઇક્રોસર્વિસિસ પર પાછા જાઓ. ભાગ 1»;
• «નળી - કુબરનેટ્સ માટે હલકો સેવા મેશ».

સોર્સ: www.habr.com