સેવા મેશ વપરાશ દૃશ્યો

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

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

* નૉૅધ અનુવાદ.: અહીં અને આગળ લેખમાં બરાબર આ અનુવાદ ("સેવા મેશ") હજુ પણ નવા શબ્દ સેવા મેશ માટે ઉપયોગમાં લેવાશે.

પરંતુ પ્રથમ હું થોડી ટિપ્પણીઓ કરવા માંગુ છું:

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

ટૂંકી સૂચિ:

• સેવા શોધ;
• એન્ક્રિપ્શન;
• પ્રમાણીકરણ અને અધિકૃતતા;
• લોડ સંતુલન;
• સર્કિટ બ્રેકિંગ;
• ઓટોસ્કેલિંગ;
• કેનેરી જમાવટ;
• વાદળી-લીલા જમાવટ;
• સ્વાસ્થ્ય તપાસ;
• લોડ શેડિંગ;
• ટ્રાફિક મિરરિંગ;
• ઇન્સ્યુલેશન;
• વિનંતી દર મર્યાદિત, પુનઃપ્રયાસ અને સમયસમાપ્તિ;
• ટેલિમેટ્રી;
• ઓડિટ
• વિઝ્યુલાઇઝેશન

1. સેવા શોધ

TL;DR: સરળ નામોનો ઉપયોગ કરીને નેટવર્ક પરની અન્ય સેવાઓ સાથે જોડાઓ.

સેવાઓ પર્યાપ્ત નામોનો ઉપયોગ કરીને આપમેળે એકબીજાને "શોધવામાં" સક્ષમ હોવી જોઈએ - ઉદાહરણ તરીકે, service.api.production, pets/staging અથવા cassandra. મેઘ વાતાવરણ સ્થિતિસ્થાપક છે, અને એક નામ સેવાના ઘણા ઉદાહરણો છુપાવી શકે છે. તે સ્પષ્ટ છે કે આવી સ્થિતિમાં તમામ IP એડ્રેસને હાર્ડકોડ કરવું શારીરિક રીતે અશક્ય છે.

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

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

2. એન્ક્રિપ્શન

TL;DR: સેવાઓ વચ્ચેના બિન-એન્ક્રિપ્ટેડ ટ્રાફિકથી છુટકારો મેળવો અને આ પ્રક્રિયાને સ્વચાલિત અને સ્કેલેબલ બનાવો.

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

અલબત્ત, mTLS સેવા મેશ માટે વૈકલ્પિક. દરેક સેવા તેના પોતાના TLS ની કાળજી લઈ શકે છે, પરંતુ આનો અર્થ એ છે કે તમારે પ્રમાણપત્રો જનરેટ કરવાની, તેમને સેવા હોસ્ટ પર વિતરિત કરવાની અને એપ્લિકેશનમાં કોડ શામેલ કરવાની જરૂર પડશે જે આ પ્રમાણપત્રોને ફાઇલોમાંથી લોડ કરશે. હા, નિયમિત સમયાંતરે આ પ્રમાણપત્રોનું નવીકરણ કરવાનું ભૂલશો નહીં. જેવી સિસ્ટમો સાથે સેવા સ્વચાલિત mTLS ને મેશ કરે છે SPIFFE, જે બદલામાં, પ્રમાણપત્રો જારી કરવાની અને ફેરવવાની પ્રક્રિયાને સ્વચાલિત કરે છે.

3. પ્રમાણીકરણ અને અધિકૃતતા

TL;DR: વિનંતી કરનાર કોણ છે તે સ્થાપિત કરો અને વિનંતી સેવા સુધી પહોંચે તે પહેલાં તેમને શું કરવાની મંજૂરી છે તે વ્યાખ્યાયિત કરો.

સેવાઓ વારંવાર જાણવા માંગે છે કોણ વિનંતી (પ્રમાણીકરણ) કરે છે, અને આ માહિતીનો ઉપયોગ કરીને, નિર્ણય લે છે કે આપેલ એન્ટિટીને (અધિકૃતતા) કરવાની મંજૂરી છે. આ કિસ્સામાં, સર્વનામ "કોણ" છુપાવી શકે છે:

1. અન્ય સેવાઓ. આને "ઓથેન્ટિકેશન" કહેવામાં આવે છે સાથીદાર" ઉદાહરણ તરીકે, સેવા web સેવા ઍક્સેસ કરવા માંગે છે db. સર્વિસ મેશ સામાન્ય રીતે mTLS નો ઉપયોગ કરીને આવી સમસ્યાઓનું નિરાકરણ કરે છે: આ કિસ્સામાં પ્રમાણપત્રો જરૂરી ઓળખકર્તા તરીકે કાર્ય કરે છે.
2. કેટલાક માનવ વપરાશકર્તાઓ. આને "ઓથેન્ટિકેશન" કહેવામાં આવે છે વિનંતી" ઉદાહરણ તરીકે, વપરાશકર્તા haxor69 નવો દીવો ખરીદવા માંગે છે. સર્વિસ મેશ વિવિધ મિકેનિઝમ્સ પ્રદાન કરે છે, દા.ત. જેએસઓન વેબ ટોકન્સ.

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

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

4. લોડ બેલેન્સિંગ

TL;DR: ચોક્કસ પેટર્ન અનુસાર સેવાના દાખલાઓમાં લોડનું વિતરણ કરો.

સેવા વિભાગમાં "સેવા" ઘણી વાર ઘણી સમાન ઘટનાઓ ધરાવે છે. ઉદાહરણ તરીકે, આજે સેવા cache 5 નકલો ધરાવે છે, અને આવતીકાલે તેમની સંખ્યા વધીને 11 થઈ શકે છે. વિનંતીઓ મોકલવામાં આવી છે cache, ચોક્કસ હેતુ અનુસાર વિતરિત કરવું આવશ્યક છે. ઉદાહરણ તરીકે, વિલંબને ઓછો કરો અથવા કાર્યકારી ઉદાહરણ પર પહોંચવાની સંભાવનાને મહત્તમ કરો. સૌથી સામાન્ય રીતે ઉપયોગમાં લેવાતા અલ્ગોરિધમ રાઉન્ડ-રોબિન છે, પરંતુ અન્ય ઘણા છે - ઉદાહરણ તરીકે, ભારિત પદ્ધતિ (ભારિત) પ્રશ્નો (તમે મનપસંદ લક્ષ્યો પસંદ કરી શકો છો), રિંગ કરો (રિંગ) હેશિંગ (અપસ્ટ્રીમ યજમાનો પર સતત હેશિંગનો ઉપયોગ કરીને) અથવા ઓછામાં ઓછી વિનંતી પદ્ધતિ (ઓછામાં ઓછી વિનંતીઓ સાથેના દાખલાને પ્રાધાન્ય આપવામાં આવે છે).

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

5. સર્કિટ બ્રેકિંગ

TL;DR: સમસ્યારૂપ સેવા પર ટ્રાફિક રોકો અને સૌથી ખરાબ સંજોગોમાં નુકસાનને નિયંત્રિત કરો.

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

સેવા મેશ માત્ર તમને વ્યાખ્યાયિત કરવાની મંજૂરી આપતા નથી જ્યારે શટડાઉન અનુસરશે અને કે આ અનુસરશે. આ કિસ્સામાં, "ક્યારે" માં ઉલ્લેખિત પરિમાણોના કોઈપણ સંયોજનનો સમાવેશ થઈ શકે છે: ચોક્કસ સમયગાળા માટે વિનંતીઓની કુલ સંખ્યા, સમાંતર જોડાણોની સંખ્યા, બાકી વિનંતીઓ, સક્રિય પુનઃપ્રયાસો વગેરે.

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

6. ઓટોસ્કેલિંગ

TL;DR: ઉલ્લેખિત માપદંડોને આધારે સેવાના દાખલાઓની સંખ્યામાં વધારો અથવા ઘટાડો.

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

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

7. કેનેરી જમાવટ

TL;DR: વપરાશકર્તાઓના સબસેટ પર નવી સુવિધાઓ અથવા સેવા સંસ્કરણોનું પરીક્ષણ કરો.

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

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

8. વાદળી-લીલા જમાવટ

TL;DR: એક સરસ નવી સુવિધા રજૂ કરો, પરંતુ તરત જ બધું પાછું લેવા માટે તૈયાર રહો.

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

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

નૉૅધ. અનુવાદ: તમે કુબરનેટ્સમાં વિવિધ જમાવટ વ્યૂહરચનાઓ વિશે વધુ વાંચી શકો છો (ઉલ્લેખ કરેલ કેનેરી, વાદળી/લીલો અને અન્ય સહિત) આ લેખ.

9. આરોગ્ય તપાસ

TL;DR: કયા સેવાના દાખલાઓ કાર્યરત છે તેનો ટ્રૅક રાખો અને જે હવે કાર્યરત નથી તેને પ્રતિસાદ આપો.

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

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

10. લોડ શેડિંગ

TL;DR: વપરાશમાં અસ્થાયી વૃદ્ધિના પ્રતિભાવમાં ટ્રાફિકને રીડાયરેક્ટ કરો.

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

11. ટ્રાફિક સમાંતર/મિરરિંગ

TL;DR: એક સાથે અનેક સ્થળોએ એક વિનંતી મોકલો.

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

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

12. ઇન્સ્યુલેશન

TL;DR: તમારા સર્વિસ મેશને મિની-નેટવર્કમાં તોડો.

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

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

13. દર મર્યાદા, પુનઃપ્રયાસ અને સમયસમાપ્તિની વિનંતી કરો

TL;DR: તમારે હવે તમારા કોડબેઝમાં નિટી-ગ્રીટી રિક્વેસ્ટ મેનેજમેન્ટ કાર્યોને સામેલ કરવાની જરૂર નથી.

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

આ કાર્યોને સર્વિસ મેશમાં ઑફલોડ કરવાનો અર્થ એ નથી કે સેવા વિકાસકર્તાઓએ તેમના વિશે વિચારવું પડશે નહીં, પણ તે વધુ વૈશ્વિક રીતે જોઈ શકાય છે. જો સેવાઓની જટિલ શૃંખલાનો ઉપયોગ કરવામાં આવે છે, તો A -> B -> C -> D -> E કહો, વિનંતીના સમગ્ર જીવનચક્રને ધ્યાનમાં લેવું આવશ્યક છે. જો કાર્ય સેવા C માં સમયસમાપ્તિને વિસ્તારવાનું છે, તો આ બધું એક જ સમયે કરવું તાર્કિક છે, અને ભાગોમાં નહીં: સેવા કોડને અપડેટ કરીને અને પુલ વિનંતી સ્વીકારવામાં ન આવે ત્યાં સુધી રાહ જુઓ અને CI સિસ્ટમ અપડેટ કરેલી સેવાનો ઉપયોગ કરે.

14. ટેલિમેટ્રી

TL;DR: સેવાઓમાંથી તમામ જરૂરી (અને તદ્દન નહીં) માહિતી એકત્રિત કરો.

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

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

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

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

15. ઓડિટ

TL;DR: જેઓ ઇતિહાસના પાઠ ભૂલી જાય છે તેઓ તેનું પુનરાવર્તન કરવા માટે વિનાશકારી છે.

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

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

16. વિઝ્યુલાઇઝેશન

TL;DR: લોન્ગ લાઈવ React.js - ફેન્સી ઈન્ટરફેસનો અખૂટ સ્ત્રોત.

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

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

યાદીમાં સામેલ ન હતા

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

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

નિષ્કર્ષ

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

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

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

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

• «સર્વિસ મેશ: દરેક સૉફ્ટવેર એન્જિનિયરને સૌથી ગરમ તકનીક વિશે શું જાણવાની જરૂર છે»;
• «સર્વિસ મેશ શું છે અને મને તેની [માઈક્રોસર્વિસ સાથે ક્લાઉડ એપ્લિકેશન માટે] શા માટે જરૂર છે?»;
• «Istio સાથે માઇક્રોસર્વિસિસ પર પાછા જાઓ. ભાગ 1».

સોર્સ: www.habr.com