ከኢስቲዮ ጋር ወደ ማይክሮ አገልግሎቶች ተመለስ። ክፍል 2

ከኢስቲዮ ጋር ወደ ማይክሮ አገልግሎቶች ተመለስ። ክፍል 2

ማስታወሻ. ትርጉም: የመጀመሪያ ክፍል ይህ ዑደት የኢስቲኦን ችሎታዎች ለመተዋወቅ እና በተግባር ለማሳየት ያተኮረ ነበር። አሁን ይህንን የአገልግሎት መረብን ስለማዋቀር እና ስለመጠቀም እና በተለይም ስለ ጥሩ የተስተካከለ ማዞሪያ እና የአውታረ መረብ ትራፊክ አስተዳደር የበለጠ ውስብስብ ገጽታዎች እንነጋገራለን ።

እንዲሁም ጽሑፉ ከማጠራቀሚያው ውስጥ አወቃቀሮችን (ለ Kubernetes እና Istio መግለጫዎች) እንደሚጠቀም እናስታውስዎታለን። ኢስቲዮ-ማስተር.

የትራፊክ አስተዳደር

በIstio፣ ለማቅረብ አዳዲስ ባህሪያት ወደ ክላስተር ታክለዋል፡-

  • ተለዋዋጭ የጥያቄ ማዘዋወር: canary rollouts, 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, ወደ ሁሉም አጋጣሚዎች ይዛወራሉ እና ጭነቱ ይሰራጫል ክብ-ሮቢን አልጎሪዝም, ይህም ወደሚከተለው ሁኔታ ይመራል.

ከኢስቲዮ ጋር ወደ ማይክሮ አገልግሎቶች ተመለስ። ክፍል 2
የተጠየቁ ፋይሎች አልተገኙም።

እነዚህ ፋይሎች በተለያዩ የመተግበሪያው ስሪቶች ውስጥ በተለያየ መንገድ የተሰየሙ በመሆናቸው አልተገኙም። እስቲ እንፈትሸው፡-

$ 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 የተመለሰው የመተግበሪያው ተመሳሳይ ስሪት ተከታይ ጥያቄዎችን ማቅረብ አለበት።».

ሃሽ ላይ በተመሰረተ ተከታታይ ጭነት ማመጣጠን ግባችን ላይ እናሳካለን። (ተለዋዋጭ የሃሽ ጭነት ማመጣጠን)… በዚህ ረገድ ከተመሳሳዩ ደንበኛ የሚቀርቡ ጥያቄዎች ወደ ተመሳሳዩ የኋላ ምሳሌ ይላካሉአስቀድሞ የተወሰነ ንብረት ጥቅም ላይ የሚውልበት - ለምሳሌ የኤችቲቲፒ ራስጌ። DestinationRulesን በመጠቀም የተተገበረ።

የመድረሻ ደንቦች

በኋላ ምናባዊ አገልግሎት ጥያቄን ወደሚፈለገው አገልግሎት ልከናል፣የDestinationRulesን በመጠቀም ለዚህ አገልግሎት በተዘጋጁ ትራፊክ ላይ ተፈጻሚነት ያላቸውን ፖሊሲዎች መግለፅ እንችላለን፡

ከኢስቲዮ ጋር ወደ ማይክሮ አገልግሎቶች ተመለስ። ክፍል 2
የትራፊክ አስተዳደር ከኢስቲዮ ሀብቶች ጋር

አመለከተ: የኢስቲዮ ሀብቶች በኔትወርክ ትራፊክ ላይ የሚያሳድሩት ተጽእኖ እዚህ ላይ ለግንዛቤ ቀለል ባለ መልኩ ቀርቧል። በትክክል ለመናገር፣ ጥያቄውን በምን አይነት ሁኔታ እንደሚልክ የሚወስነው በ CRD ውስጥ የተዋቀረው በ Ingress Gateway ውስጥ በEnvoy ነው።

በመዳረሻ ሕጎች፣ ወጥነት ያለው ሃሽ ለመጠቀም እና ተመሳሳይ የአገልግሎት ምሳሌ ለተመሳሳይ ተጠቃሚ ምላሽ እንደሚሰጥ ለማረጋገጥ የጭነት ማመጣጠንን ማዋቀር እንችላለን። የሚከተለው ውቅር ይህንን ያሳካል (መድረሻ ደንብ-ሳ-frontend.yaml):

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

1 - ሃሽ የሚመነጨው በኤችቲቲፒ አርዕስት ይዘት ላይ በመመስረት ነው። 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 (ወይም ከዚህ ጋር ለፋየርፎክስ - በግምት. መተርጎም).

በአጠቃላይ, 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ስለዚህ ሁሉም ጥያቄዎች በሁሉም ሁኔታዎች ውስጥ ይሰራጫሉ፡-

ከኢስቲዮ ጋር ወደ ማይክሮ አገልግሎቶች ተመለስ። ክፍል 2

ነገር ግን ጥያቄዎች ወደ v1 አጋጣሚዎች እንዲተላለፉ እና ወደ v2 አጋጣሚዎች እንዲታዩ እንፈልጋለን፡

ከኢስቲዮ ጋር ወደ ማይክሮ አገልግሎቶች ተመለስ። ክፍል 2

ይህንን የምናሳካው በቨርቹዋል ሰርቪስ ከDestinationRule ጋር በማጣመር ሲሆን ህጎቹ የቨርቹዋል አገልግሎቱን ንዑስ ስብስቦች እና መንገዶችን ወደ አንድ የተወሰነ ክፍል የሚገልጹበት ነው።

በመዳረሻ ደንቦች ውስጥ ንዑስ ክፍሎችን መግለጽ

ንዑስ ስብስቦች (ንዑስ ስብስቦች) በሚከተለው ውቅር ይገለጻል (sa-logic-ንዑሳን-መዳረሻ ደንብ.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 ጥያቄዎች ደንቦችን እንዲተገበር ማዋቀር እንችላለን፡-

  1. ወደ ንዑስ ስብስብ ተዘዋውሯል። v1,
  2. ወደ ንዑስ ስብስብ ተንጸባርቋል v2.

የሚከተለው አንጸባራቂ ግቦችዎን እንዲያሳኩ ይፈቅድልዎታል (ሳ-ሎጂክ-ንዑሳን-መከላከያ-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% ጥያቄዎች አይሳካም ፣ ግን ከእነዚህ ውድቀቶች ውስጥ አንዳቸውም በዋና ተጠቃሚው ላይ በሚሰራ አገልግሎት ምላሽ ስለሚያገኙ አይጎዱም።

ከኢስቲዮ ጋር ወደ ማይክሮ አገልግሎቶች ተመለስ። ክፍል 2
የሳ-ሎጂክ አገልግሎት የተለያዩ ስሪቶች ምላሾች ስኬት

ቨርቹዋል ሰርቪስ በአገልግሎታችን መልእክተኞች ላይ እንዴት እንደሚተገበር ለመጀመሪያ ጊዜ የተመለከትንበት ይህ ነው። sa-web-app የሚል ጥያቄ ያቀርባል sa-logic, በጎን መኪና ኤንቮይ በኩል ያልፋል ፣ እሱም - በቨርቹዋል ሰርቪስ - ጥያቄውን ወደ v1 ንዑስ ስብስብ ለማድረስ እና ጥያቄውን ወደ v2 የአገልግሎቱ ንዑስ ክፍል ለማንፀባረቅ የተዋቀረ ነው። sa-logic.

አውቃለሁ፡ ቨርቹዋል አገልግሎቶች ቀላል እንደሆኑ ለማሰብ አስቀድመው ጊዜ ነበራችሁ። በሚቀጥለው ክፍል, እነሱም በእውነት ታላቅ ናቸው በማለት ይህንን አስተያየት እናሰፋዋለን.

የካናሪ ልቀቶች

Canary Deployment የመተግበሪያውን አዲስ ስሪት ለጥቂቶች ቁጥር ተጠቃሚዎች የማውጣት ሂደት ነው። በተለቀቀው ውስጥ ምንም ችግሮች አለመኖራቸውን ለማረጋገጥ ጥቅም ላይ ይውላል, እና ከዚያ በኋላ ብቻ, በቂ (የተለቀቀ) ጥራቱን ቀድሞውኑ እርግጠኛ በመሆን, ያሰራጩት.оትልቅ ታዳሚ።

የካናሪ ልቀቶችን ለማሳየት፣ በንዑስ ስብስብ እንቀጥላለን buggy у sa-logic.

በጥቃቅን ነገሮች ጊዜ አናባክን እና ወዲያውኑ 20% ተጠቃሚዎችን ወደ ስሪቱ እንልክላቸው (ይህ የእኛን የካናሪ ልቀት ይወክላል) እና ቀሪው 80% ወደ መደበኛ አገልግሎት። ይህንን ለማድረግ የሚከተለውን ምናባዊ አገልግሎት ተግብር (sa-logic-ንዑሳን-ካናሪ-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), እና የአውታረ መረቡ አስተማማኝነት በዘፈቀደ ውድቀቶች ተመስሏል.

የእኛ buggy አገልግሎታችን በጣም ረጅም ምላሽ የመስጠት እድል 1/3፣ በውስጥ አገልጋይ ስህተት 1/3 የሚያበቃ፣ እና 1/3 ገጹን በተሳካ ሁኔታ የመስጠት እድል ይኑረው።

የእነዚህን ጉዳዮች ተፅእኖ ለመቀነስ እና የተጠቃሚዎቻችንን ህይወት ለማሻሻል፣ እኛ እንችላለን፡-

  1. አገልግሎቱ ከ 8 ሰከንድ በላይ ምላሽ ከሰጠ የጊዜ ማብቂያ ይጨምሩ ፣
  2. ጥያቄው ካልተሳካ እንደገና ይሞክሩ።

ለትግበራ፣ የሚከተለውን የንብረት ፍቺ እንጠቀማለን (sa-logic-reries-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

እና የተሳካላቸው ምላሾች ቁጥር ማለቁን በግራፋና ገበታዎች ላይ ያረጋግጡ፡

ከኢስቲዮ ጋር ወደ ማይክሮ አገልግሎቶች ተመለስ። ክፍል 2
የጊዜ ማብቂያዎችን እና ሙከራዎችን ካከሉ ​​በኋላ የስኬት ስታቲስቲክስ ማሻሻያዎች

ወደ ቀጣዩ ክፍል ከመቀጠልዎ በፊት (በይበልጥ በትክክል - ቀድሞውኑ ወደ ቀጣዩ የጽሁፉ ክፍል, ምክንያቱም በዚህ ተግባራዊ ሙከራዎች ውስጥ ምንም ተጨማሪ አይሆንም - በግምት. ተርጓሚ.)፣ ሰርዝ 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

የወረዳ ሰባሪ እና የጅምላ ራስ ቅጦች

ስለ ሁለት አስፈላጊ ቅጦች እየተነጋገርን ያለነው በማይክሮ ሰርቪስ አርክቴክቸር ውስጥ እራስን ወደነበረበት መመለስ እንዲችሉ ነው። (ራስን መፈወስ) አገልግሎቶች

ቆጣሪ ("ቆጣሪ") ወደ አገልግሎት ምሳሌ የሚመጡትን ጥያቄዎች ጤናማ አይደለም ተብሎ ወደነበረበት ለመመለስ እና የደንበኛ ጥያቄዎች ወደ አገልግሎቱ ጤናማ ሁኔታዎች ሲዘዋወሩ (የስኬት መጠኑን ይጨምራል) ወደነበረበት ለመመለስ ይጠቅማል። (ትርጉም ማስታወሻ፡- የስርዓተ-ጥለት የበለጠ ዝርዝር መግለጫ ሊገኝ ይችላል፣ ለምሳሌ፣ እዚህ.)

ጅምላ ("ክፍልፋይ") በአገልግሎቶች ውስጥ ያሉ ውድቀቶችን ከጠቅላላው ስርዓት ሽንፈት ይለያል። ለምሳሌ አገልግሎት B ተበላሽቷል፣ እና ሌላ አገልግሎት (የአገልግሎት ደንበኛ B) ለአገልግሎት B ጥያቄ ያቀርባል፣ ይህም ክር ገንዳውን እንዲጠቀም እና ሌሎች ጥያቄዎችን እንዳያቀርብ (የአገልግሎት አባል ባይሆኑም እንኳ) ለ) (ትርጉም ማስታወሻ፡- የስርዓተ-ጥለት የበለጠ ዝርዝር መግለጫ ሊገኝ ይችላል፣ ለምሳሌ፣ እዚህ.)

የእነዚህን ቅጦች አተገባበር ዝርዝሮችን እተወዋለሁ ምክንያቱም እነሱ ለማግኘት ቀላል ናቸው። ኦፊሴላዊ ሰነዶች, እና እንዲሁም ማረጋገጫ እና ፍቃድን ማሳየት እፈልጋለሁ, ይህም በሚቀጥለው የአንቀጹ ክፍል ውስጥ ይብራራል.

PS ከተርጓሚ

በብሎጋችን ላይ ያንብቡ፡-

ምንጭ: hab.com

አስተያየት ያክሉ