Istio સાથે માઇક્રોસર્વિસિસ પર પાછા જાઓ. ભાગ 2

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

અમે તમને એ પણ યાદ અપાવીએ છીએ કે લેખ રીપોઝીટરીમાંથી રૂપરેખાંકનો (કુબરનેટ્સ અને ઇસ્ટિઓ માટે મેનિફેસ્ટ) નો ઉપયોગ કરે છે istio-નિપુણતા.

ટ્રાફિક વ્યવસ્થાપન

Istio સાથે, પ્રદાન કરવા માટે ક્લસ્ટરમાં નવી ક્ષમતાઓ દેખાય છે:

• ગતિશીલ વિનંતી રૂટીંગ: કેનેરી રોલઆઉટ્સ, A/B પરીક્ષણ;
• લોડ બેલેન્સિંગ: સરળ અને સુસંગત, હેશ પર આધારિત;
• ધોધ પછી પુનઃપ્રાપ્તિ: સમયસમાપ્તિ, ફરી પ્રયાસો, સર્કિટ બ્રેકર્સ;
• ક્ષતિઓ દાખલ કરવી: વિલંબ, ડ્રોપ વિનંતીઓ, વગેરે.

જેમ જેમ લેખ ચાલુ રહેશે તેમ, આ ક્ષમતાઓને પસંદ કરેલ એપ્લિકેશનનો ઉપયોગ કરીને ઉદાહરણ તરીકે દર્શાવવામાં આવશે અને રસ્તામાં નવી વિભાવનાઓ રજૂ કરવામાં આવશે. આવો પહેલો કોન્સેપ્ટ હશે DestinationRules (એટલે ​​​​કે ટ્રાફિક/વિનંતીઓના પ્રાપ્તકર્તા વિશેના નિયમો - આશરે અનુવાદ.), જેની મદદથી અમે A/B પરીક્ષણ સક્રિય કરીએ છીએ.

A/B પરીક્ષણ: પ્રેક્ટિસમાં ગંતવ્ય નિયમો

A/B પરીક્ષણનો ઉપયોગ એવા કિસ્સાઓમાં થાય છે કે જ્યાં એપ્લિકેશનના બે સંસ્કરણો હોય છે (સામાન્ય રીતે તે દૃષ્ટિની રીતે અલગ હોય છે) અને અમને 100% ખાતરી નથી કે કયું વપરાશકર્તા અનુભવ સુધારશે. તેથી, અમે બંને સંસ્કરણો એકસાથે ચલાવીએ છીએ અને મેટ્રિક્સ એકત્રિત કરીએ છીએ.

A/B પરીક્ષણ દર્શાવવા માટે જરૂરી ફ્રન્ટએન્ડના બીજા સંસ્કરણને જમાવવા માટે, નીચેનો આદેશ ચલાવો:

$ kubectl apply -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml
deployment.extensions/sa-frontend-green created

ગ્રીન વર્ઝન માટે ડિપ્લોયમેન્ટ મેનિફેસ્ટ બે જગ્યાએ અલગ છે:

1. છબી એક અલગ ટેગ પર આધારિત છે - istio-green,
2. શીંગોનું લેબલ હોય છે version: green.

બંને જમાવટમાં લેબલ હોવાથી app: sa-frontend,વર્ચ્યુઅલ સેવા દ્વારા રૂટ કરાયેલ વિનંતીઓ sa-external-services સેવા માટે sa-frontend, તેના તમામ ઉદાહરણો પર રીડાયરેક્ટ કરવામાં આવશે અને લોડ દ્વારા વિતરિત કરવામાં આવશે રાઉન્ડ-રોબિન અલ્ગોરિધમ, જે નીચેની પરિસ્થિતિ તરફ દોરી જશે:

વિનંતી કરેલી ફાઇલો મળી નથી

આ ફાઇલો મળી ન હતી કારણ કે તેઓને એપ્લિકેશનના વિવિધ સંસ્કરણોમાં અલગ રીતે નામ આપવામાં આવ્યું છે. ચાલો આની ખાતરી કરીએ:

$ curl --silent http://$EXTERNAL_IP/ | tr '"' 'n' | grep main
/static/css/main.c7071b22.css
/static/js/main.059f8e9c.js
$ curl --silent http://$EXTERNAL_IP/ | tr '"' 'n' | grep main
/static/css/main.f87cd8c9.css
/static/js/main.f7659dbb.js

તેનો અર્થ એ છે કે index.html, સ્ટેટિક ફાઇલોના એક સંસ્કરણની વિનંતી કરીને, લોડ બેલેન્સર દ્વારા પોડ્સ પર મોકલી શકાય છે જેનું એક અલગ સંસ્કરણ છે, જ્યાં, સ્પષ્ટ કારણોસર, આવી ફાઇલો અસ્તિત્વમાં નથી. તેથી, એપ્લિકેશન કાર્ય કરવા માટે, અમારે એક પ્રતિબંધ સેટ કરવાની જરૂર છે: “એપ્લીકેશનનું એ જ વર્ઝન કે જે index.html ને સેવા આપે છે તે અનુગામી વિનંતીઓ પૂરી પાડવી જોઈએ».

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

ગંતવ્ય નિયમો

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

Istio સંસાધનો સાથે ટ્રાફિક વ્યવસ્થાપન

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

ગંતવ્ય નિયમો સાથે, અમે સતત હેશનો ઉપયોગ કરવા માટે લોડ બેલેન્સિંગને ગોઠવી શકીએ છીએ અને ખાતરી કરી શકીએ છીએ કે સમાન સેવાનો દાખલો સમાન વપરાશકર્તાને પ્રતિસાદ આપે છે. નીચેનું રૂપરેખાંકન તમને આ પ્રાપ્ત કરવા માટે પરવાનગી આપે છે (destinationrule-sa-frontend.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: sa-frontend
spec:
  host: sa-frontend
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpHeaderName: version   # 1

1 - HTTP હેડરની સામગ્રીના આધારે હેશ જનરેટ થશે version.

નીચેના આદેશ સાથે રૂપરેખાંકન લાગુ કરો:

$ kubectl apply -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml
destinationrule.networking.istio.io/sa-frontend created

હવે નીચેનો આદેશ ચલાવો અને ખાતરી કરો કે જ્યારે તમે હેડરનો ઉલ્લેખ કરો ત્યારે તમને યોગ્ય ફાઇલો મળે છે version:

$ curl --silent -H "version: yogo" http://$EXTERNAL_IP/ | tr '"' 'n' | grep main

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

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

વર્ચ્યુઅલ સર્વિસનો વધુ અભ્યાસ કરતા પહેલા, ચાલો નીચે આપેલા આદેશો ચલાવીને એપ્લિકેશનનું "ગ્રીન વર્ઝન" અને અનુરૂપ ટ્રાફિક દિશા નિયમ કાઢી નાખીએ:

$ kubectl delete -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml
deployment.extensions “sa-frontend-green” deleted
$ kubectl delete -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml
destinationrule.networking.istio.io “sa-frontend” deleted

મિરરિંગ: વ્યવહારમાં વર્ચ્યુઅલ સેવાઓ

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

આ દૃશ્યને ક્રિયામાં ચકાસવા માટે, ચાલો બગ્સ સાથે SA-Logic નો બીજો દાખલો બનાવીએ (buggy) નીચેનો આદેશ ચલાવીને:

$ kubectl apply -f resource-manifests/kube/shadowing/sa-logic-service-buggy.yaml
deployment.extensions/sa-logic-buggy created

અને હવે ચાલો આદેશ ચલાવીએ તેની ખાતરી કરવા માટે કે તમામ ઉદાહરણો સાથે app=sa-logic તેમની પાસે અનુરૂપ સંસ્કરણો સાથે લેબલ્સ પણ છે:

$ kubectl get pods -l app=sa-logic --show-labels
NAME                              READY   LABELS
sa-logic-568498cb4d-2sjwj         2/2     app=sa-logic,version=v1
sa-logic-568498cb4d-p4f8c         2/2     app=sa-logic,version=v1
sa-logic-buggy-76dff55847-2fl66   2/2     app=sa-logic,version=v2
sa-logic-buggy-76dff55847-kx8zz   2/2     app=sa-logic,version=v2

સેવા sa-logic એક લેબલ સાથે શીંગોને લક્ષ્ય બનાવે છે app=sa-logic, તેથી બધી વિનંતીઓ તમામ ઉદાહરણો વચ્ચે વિતરિત કરવામાં આવશે:

... પરંતુ અમે ઇચ્છીએ છીએ કે વિનંતીઓ v1 દાખલાઓ પર મોકલવામાં આવે અને v2 દાખલાઓ પર પ્રતિબિંબિત થાય:

અમે DestinationRule સાથે સંયોજનમાં VirtualService દ્વારા આ હાંસલ કરીશું, જ્યાં નિયમો ચોક્કસ સબસેટ માટે VirtualService ના સબસેટ્સ અને રૂટ્સ નક્કી કરશે.

ગંતવ્ય નિયમોમાં સબસેટ્સને વ્યાખ્યાયિત કરવું

સબસેટ્સ (સબસેટ) નીચેના રૂપરેખાંકન દ્વારા નક્કી કરવામાં આવે છે (sa-logic-સબસેટ્સ-destinationrule.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: sa-logic
spec:
  host: sa-logic    # 1
  subsets:
  - name: v1        # 2
    labels:
      version: v1   # 3
  - name: v2
    labels:
      version: v2

1. યજમાન (host) વ્યાખ્યાયિત કરે છે કે આ નિયમ ફક્ત એવા કિસ્સાઓમાં લાગુ પડે છે જ્યારે માર્ગ સેવા તરફ જાય છે sa-logic;
2. શીર્ષકો (name) સબસેટનો ઉપયોગ સબસેટ દાખલાઓ પર રૂટ કરતી વખતે થાય છે;
3. લેબલ (label) કી-મૂલ્ય જોડીને વ્યાખ્યાયિત કરે છે કે જે દાખલાઓ સબસેટનો ભાગ બનવા માટે મેળ ખાતી હોવી જોઈએ.

નીચેના આદેશ સાથે રૂપરેખાંકન લાગુ કરો:

$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-destinationrule.yaml
destinationrule.networking.istio.io/sa-logic created

હવે જ્યારે સબસેટ્સ વ્યાખ્યાયિત કરવામાં આવ્યા છે, અમે આગળ વધી શકીએ છીએ અને સા-તર્કની વિનંતીઓ પર નિયમો લાગુ કરવા માટે વર્ચ્યુઅલ સર્વિસને ગોઠવી શકીએ છીએ જેથી તેઓ:

1. સબસેટ પર રૂટ કર્યો v1,
2. સબસેટ પર પ્રતિબિંબિત v2.

નીચેનો મેનિફેસ્ટો તમને તમારી યોજનાઓ હાંસલ કરવાની મંજૂરી આપે છે (sa-તર્ક-સબસેટ્સ-શેડોઇંગ-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic          
  http:
  - route:
    - destination:
        host: sa-logic  
        subset: v1      
    mirror:             
      host: sa-logic     
      subset: v2

અહીં કોઈ સમજૂતીની જરૂર નથી, તેથી ચાલો તેને ક્રિયામાં જોઈએ:

$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-shadowing-vs.yaml
virtualservice.networking.istio.io/sa-logic created

ચાલો નીચેના આદેશને કૉલ કરીને લોડ ઉમેરીએ:

$ while true; do curl -v http://$EXTERNAL_IP/sentiment 
    -H "Content-type: application/json" 
    -d '{"sentence": "I love yogobella"}'; 
    sleep .8; done

ચાલો Grafana માં પરિણામો જોઈએ, જ્યાં તમે જોઈ શકો છો કે ભૂલો સાથેનું સંસ્કરણ (buggy) ~60% વિનંતીઓ માટે નિષ્ફળતામાં પરિણમે છે, પરંતુ આમાંની કોઈપણ નિષ્ફળતા અંતિમ વપરાશકર્તાઓને અસર કરે છે કારણ કે તેઓને ચાલી રહેલી સેવા દ્વારા પ્રતિસાદ આપવામાં આવે છે.

સા-તર્ક સેવાના વિવિધ સંસ્કરણોના સફળ પ્રતિભાવો

અહીં આપણે સૌપ્રથમ જોયું કે કેવી રીતે વર્ચ્યુઅલ સર્વિસ અમારી સેવાઓના દૂત પર લાગુ થાય છે: ક્યારે sa-web-app માટે વિનંતી કરે છે sa-logic, તે સાઇડકાર એન્વોય દ્વારા જાય છે, જે - વર્ચ્યુઅલ સર્વિસ દ્વારા - વિનંતીને v1 સબસેટ પર રૂટ કરવા અને સેવાના v2 સબસેટની વિનંતીને પ્રતિબિંબિત કરવા માટે ગોઠવવામાં આવે છે. sa-logic.

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

કેનેરી રોલઆઉટ્સ

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

કેનેરી રોલઆઉટ્સ દર્શાવવા માટે, અમે સબસેટ સાથે કામ કરવાનું ચાલુ રાખીશું buggy у sa-logic.

ચાલો નાનકડી વાતો પર સમય ન બગાડો અને તરત જ 20% વપરાશકર્તાઓને બગ્સ સાથે સંસ્કરણ પર મોકલીએ (આ અમારા કેનેરી રોલઆઉટનું પ્રતિનિધિત્વ કરશે), અને બાકીના 80% સામાન્ય સેવામાં. આ કરવા માટે, નીચેની વર્ચ્યુઅલ સર્વિસનો ઉપયોગ કરો (sa-તર્ક-સબસેટ્સ-કેનરી-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic    
  http:
  - route: 
    - destination: 
        host: sa-logic
        subset: v1
      weight: 80         # 1
    - destination: 
        host: sa-logic
        subset: v2
      weight: 20 # 1

1 વજન છે (weight), જે વિનંતીઓની ટકાવારીનો ઉલ્લેખ કરે છે જે પ્રાપ્તકર્તા અથવા પ્રાપ્તકર્તાના સબસેટને નિર્દેશિત કરવામાં આવશે.

ચાલો પહેલાની વર્ચ્યુઅલ સર્વિસ કન્ફિગરેશનને અપડેટ કરીએ sa-logic નીચેના આદેશ સાથે:

$ kubectl apply -f resource-manifests/istio/canary/sa-logic-subsets-canary-vs.yaml
virtualservice.networking.istio.io/sa-logic configured

... અને અમે તરત જ જોશું કે કેટલીક વિનંતીઓ નિષ્ફળતા તરફ દોરી જાય છે:

$ while true; do 
   curl -i http://$EXTERNAL_IP/sentiment 
   -H "Content-type: application/json" 
   -d '{"sentence": "I love yogobella"}' 
   --silent -w "Time: %{time_total}s t Status: %{http_code}n" 
   -o /dev/null; sleep .1; done
Time: 0.153075s Status: 200
Time: 0.137581s Status: 200
Time: 0.139345s Status: 200
Time: 30.291806s Status: 500

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

સમયસમાપ્તિ અને ફરી પ્રયાસો

પરંતુ ભૂલો હંમેશા કોડમાં સમાપ્ત થતી નથી. યાદીમાં "ડિસ્ટ્રિબ્યુટેડ કમ્પ્યુટિંગ વિશે 8 ગેરસમજો"પ્રથમ સ્થાને ભૂલભરેલી માન્યતા છે કે "નેટવર્ક વિશ્વસનીય છે." વાસ્તવમાં નેટવર્ક નથી વિશ્વસનીય, અને આ કારણોસર અમને સમયસમાપ્તિની જરૂર છે (સમયસમાપ્ત) અને ફરી પ્રયાસ કરે છે (પુનઃપ્રયાસ).

નિદર્શન માટે અમે સમાન સમસ્યા સંસ્કરણનો ઉપયોગ કરવાનું ચાલુ રાખીશું sa-logic (buggy), અને અમે રેન્ડમ નિષ્ફળતાઓ સાથે નેટવર્કની અવિશ્વસનીયતાનું અનુકરણ કરીશું.

ભૂલો સાથેની અમારી સેવાને પ્રતિસાદ આપવામાં ઘણો સમય લાગવાની 1/3 તક, આંતરિક સર્વર ભૂલ સાથે સમાપ્ત થવાની 1/3 તક અને પૃષ્ઠને સફળતાપૂર્વક પરત કરવાની 1/3 તક દો.

આવી સમસ્યાઓના પ્રભાવને ઘટાડવા અને વપરાશકર્તાઓ માટે જીવન બહેતર બનાવવા માટે, અમે આ કરી શકીએ છીએ:

1. જો સેવાને પ્રતિસાદ આપવામાં 8 સેકન્ડ કરતાં વધુ સમય લાગે તો સમયસમાપ્તિ ઉમેરો,
2. જો વિનંતી નિષ્ફળ જાય તો ફરી પ્રયાસ કરો.

અમલીકરણ માટે, અમે નીચેની સંસાધન વ્યાખ્યાનો ઉપયોગ કરીશું (sa-તર્ક-પુનઃપ્રયાસ-સમયઆઉટ-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic
  http:
  - route: 
    - destination: 
        host: sa-logic
        subset: v1
      weight: 50
    - destination: 
        host: sa-logic
        subset: v2
      weight: 50
    timeout: 8s           # 1
    retries:
      attempts: 3         # 2
      perTryTimeout: 3s # 3

1. વિનંતી માટે સમયસમાપ્તિ 8 સેકન્ડ પર સેટ છે;
2. વિનંતીઓ 3 વખત ફરીથી પ્રયાસ કરવામાં આવે છે;
3. અને જો પ્રતિભાવ સમય 3 સેકન્ડથી વધી જાય તો દરેક પ્રયાસને અસફળ ગણવામાં આવે છે.

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

નીચેના આદેશ સાથે અપડેટ કરેલ રૂપરેખાંકન લાગુ કરો:

$ kubectl apply -f resource-manifests/istio/retries/sa-logic-retries-timeouts-vs.yaml
virtualservice.networking.istio.io/sa-logic configured

અને ગ્રાફના ગ્રાફમાં તપાસો કે સફળ પ્રતિભાવોની સંખ્યા ઉપર વધી છે:

સમયસમાપ્તિ અને પુનઃપ્રયાસો ઉમેર્યા પછી સફળ પ્રતિસાદના આંકડામાં સુધારો

આગલા વિભાગમાં આગળ વધતા પહેલા (અથવા તેના બદલે, લેખના આગળના ભાગમાં, કારણ કે આમાં કોઈ વધુ વ્યવહારુ પ્રયોગો હશે નહીં - આશરે અનુવાદ.), કાઢી નાખો sa-logic-buggy અને નીચેના આદેશો ચલાવીને વર્ચ્યુઅલ સર્વિસ:

$ kubectl delete deployment sa-logic-buggy
deployment.extensions “sa-logic-buggy” deleted
$ kubectl delete virtualservice sa-logic
virtualservice.networking.istio.io “sa-logic” deleted

સર્કિટ બ્રેકર અને બલ્કહેડ પેટર્ન

અમે માઇક્રોસર્વિસ આર્કિટેક્ચરમાં બે મહત્વપૂર્ણ પેટર્ન વિશે વાત કરી રહ્યા છીએ જે તમને સ્વ-પુનઃપ્રાપ્તિ પ્રાપ્ત કરવાની મંજૂરી આપે છે (સ્વ-ઉપચાર) સેવાઓ.

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

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

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

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

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

• "ઇસ્ટિઓ સાથે માઇક્રોસર્વિસિસ પર પાછા": ભાગ 1 (મુખ્ય લક્ષણોનો પરિચય), ભાગ 3 (પ્રમાણીકરણ અને અધિકૃતતા);
• «નળી - કુબરનેટ્સ માટે હલકો સેવા મેશ»;
• «સર્વિસ મેશ શું છે અને મને તેની [માઈક્રોસર્વિસ સાથે ક્લાઉડ એપ્લિકેશન માટે] શા માટે જરૂર છે?».

સોર્સ: www.habr.com