ఇస్టియోతో మైక్రోసర్వీస్‌కి తిరిగి వెళ్ళు. 2 వ భాగము

గమనిక. అనువాదం.: మొదటి భాగం ఈ సిరీస్ ఇస్టియో సామర్థ్యాలను పరిచయం చేయడానికి మరియు వాటిని చర్యలో ప్రదర్శించడానికి అంకితం చేయబడింది. ఇప్పుడు మేము ఈ సేవా మెష్ యొక్క కాన్ఫిగరేషన్ మరియు ఉపయోగం యొక్క మరింత సంక్లిష్టమైన అంశాల గురించి మరియు ముఖ్యంగా, చక్కగా ట్యూన్ చేయబడిన రూటింగ్ మరియు నెట్‌వర్క్ ట్రాఫిక్ నిర్వహణ గురించి మాట్లాడుతాము.

వ్యాసం రిపోజిటరీ నుండి కాన్ఫిగరేషన్‌లను (కుబెర్నెట్స్ మరియు ఇస్టియో కోసం మానిఫెస్ట్‌లు) ఉపయోగిస్తుందని కూడా మేము మీకు గుర్తు చేస్తున్నాము 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 హెడర్. డెస్టినేషన్ రూల్స్ ఉపయోగించి అమలు చేయబడింది.

గమ్యం నియమాలు

తరువాత వర్చువల్ సర్వీస్ కావలసిన సేవకు అభ్యర్థనను పంపాము, DestinationRulesని ఉపయోగించి మేము ఈ సేవ యొక్క ఉదాహరణల కోసం ఉద్దేశించిన ట్రాఫిక్‌కు వర్తించే విధానాలను నిర్వచించవచ్చు:

ఇస్టియో వనరులతో ట్రాఫిక్ నిర్వహణ

వ్యాఖ్య: నెట్‌వర్క్ ట్రాఫిక్‌పై ఇస్టియో వనరుల ప్రభావం సులభంగా అర్థం చేసుకునే విధంగా ఇక్కడ అందించబడింది. ఖచ్చితంగా చెప్పాలంటే, CRDలో కాన్ఫిగర్ చేయబడిన ఇన్‌గ్రెస్ గేట్‌వేలోని రాయబారి ద్వారా అభ్యర్థనను ఏ సందర్భంలో పంపాలనే నిర్ణయం తీసుకోబడుతుంది.

డెస్టినేషన్ రూల్స్‌తో, స్థిరమైన హ్యాష్‌లను ఉపయోగించడానికి మేము లోడ్ బ్యాలెన్సింగ్‌ను కాన్ఫిగర్ చేయవచ్చు మరియు అదే సర్వీస్ ఇన్‌స్టాన్స్ అదే వినియోగదారుకు ప్రతిస్పందిస్తుందని నిర్ధారించుకోవచ్చు. కింది కాన్ఫిగరేషన్ దీన్ని సాధించడానికి మిమ్మల్ని అనుమతిస్తుంది (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

వ్యాఖ్య: హెడర్‌లో విభిన్న విలువలను జోడించడానికి మరియు ఫలితాలను నేరుగా బ్రౌజర్‌లో పరీక్షించడానికి, మీరు ఉపయోగించవచ్చు ఈ పొడిగింపు Chromeకి (లేదా దీనితో Firefox కోసం - సుమారు. అనువాదం.).

సాధారణంగా, DestinationRules లోడ్ బ్యాలెన్సింగ్ ప్రాంతంలో మరిన్ని సామర్థ్యాలను కలిగి ఉంది - వివరాల కోసం తనిఖీ చేయండి అధికారిక డాక్యుమెంటేషన్.

VirtualServiceని మరింతగా అధ్యయనం చేయడానికి ముందు, కింది ఆదేశాలను అమలు చేయడం ద్వారా అప్లికేషన్ యొక్క "గ్రీన్ వెర్షన్" మరియు సంబంధిత ట్రాఫిక్ దిశ నియమాన్ని తొలగిస్తాము:

$ 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-లాజిక్ యొక్క రెండవ ఉదాహరణను సృష్టిద్దాం (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-subset-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

ఇప్పుడు ఉపసమితులు నిర్వచించబడ్డాయి, sa-logicకి అభ్యర్థనలకు నియమాలను వర్తింపజేయడానికి మేము VirtualServiceని కొనసాగించవచ్చు మరియు కాన్ఫిగర్ చేయవచ్చు, తద్వారా అవి:

1. ఉపసమితికి మళ్లించబడింది v1,
2. ఉపసమితికి ప్రతిబింబించబడింది v2.

కింది మానిఫెస్టో మీ ప్రణాళికలను సాధించడానికి మిమ్మల్ని అనుమతిస్తుంది (sa-logic-subsets-shadowing-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

గ్రాఫానాలోని ఫలితాలను చూద్దాం, ఇక్కడ మీరు బగ్‌లతో కూడిన సంస్కరణను చూడవచ్చు (buggy) రిక్వెస్ట్‌లలో ~60% వైఫల్యానికి దారి తీస్తుంది, అయితే ఈ వైఫల్యాలు ఏవీ అంతిమ వినియోగదారులను ప్రభావితం చేయవు, ఎందుకంటే వారు నడుస్తున్న సేవ ద్వారా ప్రతిస్పందించారు.

సా-లాజిక్ సేవ యొక్క విభిన్న సంస్కరణల విజయవంతమైన ప్రతిస్పందనలు

మా సేవల రాయబారులకు వర్చువల్ సర్వీస్ ఎలా వర్తింపజేయబడుతుందో ఇక్కడ మేము మొదట చూశాము: ఎప్పుడు sa-web-app ఒక అభ్యర్థన చేస్తుంది sa-logic, ఇది సైడ్‌కార్ ఎన్వాయ్ ద్వారా వెళుతుంది, ఇది - VirtualService ద్వారా - అభ్యర్థనను v1 ఉపసమితికి మార్చడానికి మరియు సేవ యొక్క v2 ఉపసమితికి అభ్యర్థనను ప్రతిబింబించేలా కాన్ఫిగర్ చేయబడింది sa-logic.

నాకు తెలుసు, వర్చువల్ సర్వీసెస్ చాలా సులభం అని మీరు ఇప్పటికే అనుకోవచ్చు. తదుపరి విభాగంలో, వారు కూడా నిజంగా గొప్పవారని చెప్పడం ద్వారా మేము దానిని విస్తరిస్తాము.

కానరీ రోల్‌అవుట్‌లు

కానరీ డిప్లాయ్‌మెంట్ అనేది తక్కువ సంఖ్యలో వినియోగదారులకు అప్లికేషన్ యొక్క కొత్త వెర్షన్‌ను అందించే ప్రక్రియ. విడుదలలో ఎటువంటి సమస్యలు లేవని నిర్ధారించుకోవడానికి ఇది ఉపయోగించబడుతుంది మరియు ఆ తర్వాత మాత్రమే, దాని (విడుదల) నాణ్యతపై ఇప్పటికే నమ్మకంతో, ఇతర వినియోగదారులకు పంపిణీ చేయండి.оఎక్కువ మంది ప్రేక్షకులు.

కానరీ రోల్‌అవుట్‌లను ప్రదర్శించడానికి, మేము ఉపసమితితో పని చేయడం కొనసాగిస్తాము buggy у sa-logic.

ట్రిఫ్లెస్‌పై సమయాన్ని వృథా చేయవద్దు మరియు వెంటనే 20% మంది వినియోగదారులను బగ్‌లతో వెర్షన్‌కు పంపండి (ఇది మా కానరీ రోల్‌అవుట్‌ను సూచిస్తుంది), మరియు మిగిలిన 80% సాధారణ సేవకు. దీన్ని చేయడానికి, కింది వర్చువల్ సర్వీస్‌ని ఉపయోగించండి (sa-logic-subsets-canary-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), ఇది గ్రహీతకు లేదా గ్రహీత యొక్క ఉపసమితికి పంపబడే అభ్యర్థనల శాతాన్ని నిర్దేశిస్తుంది.

దీని కోసం మునుపటి VirtualService కాన్ఫిగరేషన్‌ని అప్‌డేట్ చేద్దాం 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

VirtualServices కానరీ రోల్‌అవుట్‌లను ప్రారంభిస్తాయి: ఈ సందర్భంలో, మేము సమస్యల యొక్క సంభావ్య ప్రభావాన్ని వినియోగదారు బేస్‌లో 20%కి తగ్గించాము. అద్భుతం! ఇప్పుడు, మన కోడ్ గురించి మనకు ఖచ్చితంగా తెలియనప్పుడు ప్రతి సందర్భంలోనూ (ఇతర మాటలలో - ఎల్లప్పుడూ...), మేము మిర్రరింగ్ మరియు కానరీ రోల్‌అవుట్‌లను ఉపయోగించవచ్చు.

సమయం ముగిసింది మరియు మళ్లీ ప్రయత్నాలు

కానీ బగ్‌లు ఎల్లప్పుడూ కోడ్‌లో ముగియవు. " నుండి జాబితాలో8 డిస్ట్రిబ్యూటెడ్ కంప్యూటింగ్ గురించి అపోహలు"మొదటి స్థానంలో "నెట్‌వర్క్ నమ్మదగినది" అనే తప్పుడు నమ్మకం. వాస్తవానికి నెట్‌వర్క్ కాదు నమ్మదగినది, మరియు ఈ కారణంగా మాకు సమయం ముగిసింది (సమయం ముగిసింది) మరియు మళ్లీ ప్రయత్నిస్తుంది (మళ్లీ ప్రయత్నిస్తుంది).

ప్రదర్శన కోసం మేము అదే సమస్య సంస్కరణను ఉపయోగించడం కొనసాగిస్తాము sa-logic (buggy), మరియు మేము యాదృచ్ఛిక వైఫల్యాలతో నెట్‌వర్క్ యొక్క అవిశ్వసనీయతను అనుకరిస్తాము.

బగ్‌లతో కూడిన మా సేవ ప్రతిస్పందించడానికి ఎక్కువ సమయం తీసుకునే అవకాశం 1/3, అంతర్గత సర్వర్ లోపంతో ముగిసే అవకాశం 1/3 మరియు పేజీని విజయవంతంగా తిరిగి ఇచ్చే అవకాశం 1/3.

అటువంటి సమస్యల ప్రభావాన్ని తగ్గించడానికి మరియు వినియోగదారుల జీవితాన్ని మెరుగుపరచడానికి, మేము వీటిని చేయవచ్చు:

1. సేవ ప్రతిస్పందించడానికి 8 సెకన్ల కంటే ఎక్కువ సమయం తీసుకుంటే గడువును జోడించండి,
2. అభ్యర్థన విఫలమైతే మళ్లీ ప్రయత్నించండి.

అమలు కోసం, మేము ఈ క్రింది వనరుల నిర్వచనాన్ని ఉపయోగిస్తాము (sa-logic-retriries-timeouts-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 కింది ఆదేశాలను అమలు చేయడం ద్వారా మరియు VirtualService:

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

సర్క్యూట్ బ్రేకర్ మరియు బల్క్ హెడ్ నమూనాలు

మేము మైక్రోసర్వీస్ ఆర్కిటెక్చర్‌లోని రెండు ముఖ్యమైన నమూనాల గురించి మాట్లాడుతున్నాము, అది మిమ్మల్ని స్వీయ-రికవరీని సాధించడానికి అనుమతిస్తుంది (స్వీయ స్వస్థత) సేవలు.

<span style="font-family: Mandali; "> సర్క్యూట్ బ్రేకర్ ("సర్క్యూట్ బ్రేకర్") అనారోగ్యకరమైనదిగా పరిగణించబడే సేవకు సంబంధించిన అభ్యర్థనలను ముగించడానికి మరియు క్లయింట్ అభ్యర్థనలు ఆ సేవ యొక్క ఆరోగ్యకరమైన సందర్భాలకు దారి మళ్లించబడినప్పుడు దాన్ని పునరుద్ధరించడానికి ఉపయోగిస్తారు (ఇది విజయవంతమైన ప్రతిస్పందనల శాతాన్ని పెంచుతుంది). (గమనిక: నమూనా యొక్క మరింత వివరణాత్మక వర్ణనను కనుగొనవచ్చు, ఉదాహరణకు, ఇక్కడ.)

బల్క్హెడ్ ("విభజన") మొత్తం వ్యవస్థను ప్రభావితం చేయకుండా సేవా వైఫల్యాలను వేరు చేస్తుంది. ఉదాహరణకు, సర్వీస్ B విచ్ఛిన్నమైంది మరియు మరొక సేవ (సర్వీస్ B యొక్క క్లయింట్) సర్వీస్ Bకి ఒక అభ్యర్థనను చేస్తుంది, దీని వలన దాని థ్రెడ్ పూల్ అయిపోయింది మరియు ఇతర అభ్యర్థనలకు (అవి సర్వీస్ B నుండి కాకపోయినా) సర్వీస్ చేయలేకపోతుంది. (గమనిక: నమూనా యొక్క మరింత వివరణాత్మక వర్ణనను కనుగొనవచ్చు, ఉదాహరణకు, ఇక్కడ.)

ఈ నమూనాల అమలు వివరాలను నేను విస్మరిస్తాను ఎందుకంటే అవి సులభంగా కనుగొనబడతాయి అధికారిక డాక్యుమెంటేషన్, మరియు నేను నిజంగా ధృవీకరణ మరియు అధికారాన్ని చూపించాలనుకుంటున్నాను, ఇది వ్యాసం యొక్క తదుపరి భాగంలో చర్చించబడుతుంది.

అనువాదకుని నుండి PS

మా బ్లాగులో కూడా చదవండి:

• "ఇస్టియోతో మైక్రోసర్వీసెస్‌కి తిరిగి వెళ్ళు": పార్ట్ 1 (ప్రధాన లక్షణాల పరిచయం), భాగం 3 (ధృవీకరణ మరియు అధికారం);
• «కండ్యూట్ - కుబెర్నెట్స్ కోసం తేలికపాటి సర్వీస్ మెష్";
• «సర్వీస్ మెష్ అంటే ఏమిటి మరియు నాకు ఇది ఎందుకు అవసరం [మైక్రో సర్వీసెస్‌తో కూడిన క్లౌడ్ అప్లికేషన్ కోసం]?".

మూలం: www.habr.com