🥇Istio ಜೊತೆಗೆ ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗೆ ಹಿಂತಿರುಗಿ. ಭಾಗ 2

ಸೂಚನೆ. ಅನುವಾದ.: ಮೊದಲ ಭಾಗ ಈ ಸರಣಿಯು ಇಸ್ಟಿಯೊ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಪರಿಚಯಿಸಲು ಮತ್ತು ಅವುಗಳನ್ನು ಕ್ರಿಯೆಯಲ್ಲಿ ಪ್ರದರ್ಶಿಸಲು ಸಮರ್ಪಿಸಲಾಗಿದೆ. ಈಗ ನಾವು ಈ ಸೇವಾ ಜಾಲರಿಯ ಸಂರಚನೆ ಮತ್ತು ಬಳಕೆಯ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾದ ಅಂಶಗಳ ಬಗ್ಗೆ ಮತ್ತು ನಿರ್ದಿಷ್ಟವಾಗಿ, ಉತ್ತಮವಾಗಿ ಟ್ಯೂನ್ ಮಾಡಿದ ರೂಟಿಂಗ್ ಮತ್ತು ನೆಟ್‌ವರ್ಕ್ ಟ್ರಾಫಿಕ್ ನಿರ್ವಹಣೆಯ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇವೆ.

ಲೇಖನವು ರೆಪೊಸಿಟರಿಯಿಂದ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು (ಕುಬರ್ನೆಟ್ಸ್ ಮತ್ತು ಇಸ್ಟಿಯೊಗಾಗಿ ಮ್ಯಾನಿಫೆಸ್ಟ್‌ಗಳು) ಬಳಸುತ್ತದೆ ಎಂದು ನಾವು ನಿಮಗೆ ನೆನಪಿಸುತ್ತೇವೆ istio-ಮಾಸ್ಟರಿ.

ಸಂಚಾರ ನಿರ್ವಹಣೆ

Istio ನೊಂದಿಗೆ, ಒದಗಿಸಲು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಹೊಸ ಸಾಮರ್ಥ್ಯಗಳು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ:

ಡೈನಾಮಿಕ್ ವಿನಂತಿ ರೂಟಿಂಗ್: ಕ್ಯಾನರಿ ರೋಲ್‌ಔಟ್‌ಗಳು, ಎ/ಬಿ ಪರೀಕ್ಷೆ;
ಹೊರೆ ಸಮತೋಲನೆ: ಸರಳ ಮತ್ತು ಸ್ಥಿರ, ಹ್ಯಾಶ್‌ಗಳ ಆಧಾರದ ಮೇಲೆ;
ಬೀಳುವ ನಂತರ ಚೇತರಿಕೆ: ಕಾಲಾವಧಿಗಳು, ಮರುಪ್ರಯತ್ನಗಳು, ಸರ್ಕ್ಯೂಟ್ ಬ್ರೇಕರ್ಗಳು;
ದೋಷಗಳನ್ನು ಸೇರಿಸುವುದು: ವಿಳಂಬಗಳು, ಕೈಬಿಡಲಾದ ವಿನಂತಿಗಳು, ಇತ್ಯಾದಿ.

ಲೇಖನವು ಮುಂದುವರಿದಂತೆ, ಆಯ್ದ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಉದಾಹರಣೆಯಾಗಿ ಬಳಸಿಕೊಂಡು ಈ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ವಿವರಿಸಲಾಗುವುದು ಮತ್ತು ಹೊಸ ಪರಿಕಲ್ಪನೆಗಳನ್ನು ದಾರಿಯುದ್ದಕ್ಕೂ ಪರಿಚಯಿಸಲಾಗುತ್ತದೆ. ಅಂತಹ ಮೊದಲ ಪರಿಕಲ್ಪನೆಯು ಇರುತ್ತದೆ 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

ಹಸಿರು ಆವೃತ್ತಿಯ ನಿಯೋಜನೆ ಮ್ಯಾನಿಫೆಸ್ಟ್ ಎರಡು ಸ್ಥಳಗಳಲ್ಲಿ ಭಿನ್ನವಾಗಿದೆ:

ಚಿತ್ರವು ವಿಭಿನ್ನ ಟ್ಯಾಗ್ ಅನ್ನು ಆಧರಿಸಿದೆ - istio-green,
ಪಾಡ್‌ಗಳಿಗೆ ಲೇಬಲ್ ಇದೆ 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 ಬಳಸಿ ಅಳವಡಿಸಲಾಗಿದೆ.

ಗಮ್ಯಸ್ಥಾನದ ನಿಯಮಗಳು

ನಂತರ ವರ್ಚುವಲ್ ಸೇವೆ ಬಯಸಿದ ಸೇವೆಗೆ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಲಾಗಿದೆ, ಈ ಸೇವೆಯ ನಿದರ್ಶನಗಳಿಗಾಗಿ ಉದ್ದೇಶಿಸಲಾದ ಟ್ರಾಫಿಕ್‌ಗೆ ಅನ್ವಯಿಸುವ ನೀತಿಗಳನ್ನು ನಾವು DestinationRules ಬಳಸಿ ವ್ಯಾಖ್ಯಾನಿಸಬಹುದು:

ಇಸ್ಟಿಯೊ ಸಂಪನ್ಮೂಲಗಳೊಂದಿಗೆ ಸಂಚಾರ ನಿರ್ವಹಣೆ

ಹೇಳಿಕೆಯನ್ನು: ನೆಟ್‌ವರ್ಕ್ ಟ್ರಾಫಿಕ್‌ನಲ್ಲಿ ಇಸ್ಟಿಯೊ ಸಂಪನ್ಮೂಲಗಳ ಪ್ರಭಾವವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸುಲಭವಾದ ರೀತಿಯಲ್ಲಿ ಇಲ್ಲಿ ಪ್ರಸ್ತುತಪಡಿಸಲಾಗಿದೆ. ನಿಖರವಾಗಿ ಹೇಳಬೇಕೆಂದರೆ, ಸಿಆರ್‌ಡಿಯಲ್ಲಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾದ ಪ್ರವೇಶ ಗೇಟ್‌ವೇಯಲ್ಲಿರುವ ರಾಯಭಾರಿಯಿಂದ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಲು ಯಾವ ನಿದರ್ಶನವನ್ನು ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ.

ಗಮ್ಯಸ್ಥಾನ ನಿಯಮಗಳೊಂದಿಗೆ, ಸ್ಥಿರವಾದ ಹ್ಯಾಶ್‌ಗಳನ್ನು ಬಳಸಲು ನಾವು ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು ಮತ್ತು ಅದೇ ಸೇವೆಯ ನಿದರ್ಶನವು ಅದೇ ಬಳಕೆದಾರರಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬಹುದು. ಕೆಳಗಿನ ಸಂರಚನೆಯು ಇದನ್ನು ಸಾಧಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ (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 ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ಕ್ಷೇತ್ರದಲ್ಲಿ ಹೆಚ್ಚಿನ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಹೊಂದಿದೆ - ವಿವರಗಳಿಗಾಗಿ ಪರಿಶೀಲಿಸಿ ಅಧಿಕೃತ ದಸ್ತಾವೇಜನ್ನು.

ವರ್ಚುವಲ್ ಸೇವೆಯನ್ನು ಮತ್ತಷ್ಟು ಅಧ್ಯಯನ ಮಾಡುವ ಮೊದಲು, ಈ ಕೆಳಗಿನ ಆಜ್ಞೆಗಳನ್ನು ಚಲಾಯಿಸುವ ಮೂಲಕ ಅಪ್ಲಿಕೇಶನ್‌ನ "ಹಸಿರು ಆವೃತ್ತಿ" ಮತ್ತು ಅನುಗುಣವಾದ ಸಂಚಾರ ನಿರ್ದೇಶನ ನಿಯಮವನ್ನು ಅಳಿಸೋಣ:

$ 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-subsets-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

ಅತಿಥೆಯ (host) ಮಾರ್ಗವು ಸೇವೆಯ ಕಡೆಗೆ ಹೋದಾಗ ಈ ನಿಯಮವು ಪ್ರಕರಣಗಳಿಗೆ ಮಾತ್ರ ಅನ್ವಯಿಸುತ್ತದೆ ಎಂದು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ sa-logic;
ಶೀರ್ಷಿಕೆಗಳು (name) ಉಪವಿಭಾಗಗಳ ನಿದರ್ಶನಗಳಿಗೆ ರೂಟಿಂಗ್ ಮಾಡುವಾಗ ಉಪವಿಭಾಗಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ;
ಲೇಬಲ್ (label) ಉಪವಿಭಾಗದ ಭಾಗವಾಗಲು ನಿದರ್ಶನಗಳು ಹೊಂದಿಕೆಯಾಗಬೇಕಾದ ಕೀ-ಮೌಲ್ಯದ ಜೋಡಿಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ.

ಕೆಳಗಿನ ಆಜ್ಞೆಯೊಂದಿಗೆ ಸಂರಚನೆಯನ್ನು ಅನ್ವಯಿಸಿ:

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

ಈಗ ಉಪವಿಭಾಗಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ, ನಾವು ಮುಂದುವರಿಯಬಹುದು ಮತ್ತು ಸಾ-ಲಾಜಿಕ್‌ಗೆ ವಿನಂತಿಗಳಿಗೆ ನಿಯಮಗಳನ್ನು ಅನ್ವಯಿಸಲು ವರ್ಚುವಲ್ ಸೇವೆಯನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು:

ಉಪವಿಭಾಗಕ್ಕೆ ರೂಟ್ ಮಾಡಲಾಗಿದೆ v1,
ಉಪವಿಭಾಗಕ್ಕೆ ಪ್ರತಿಬಿಂಬಿಸಲಾಗಿದೆ 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, ಇದು ಸೈಡ್‌ಕಾರ್ ಎನ್ವಾಯ್ ಮೂಲಕ ಹೋಗುತ್ತದೆ, ಇದು - ವರ್ಚುವಲ್ ಸರ್ವಿಸ್ ಮೂಲಕ - ವಿನಂತಿಯನ್ನು 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

ವರ್ಚುವಲ್ ಸೇವೆಗಳು ಕ್ಯಾನರಿ ರೋಲ್‌ಔಟ್‌ಗಳನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತವೆ: ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ಸಮಸ್ಯೆಗಳ ಸಂಭಾವ್ಯ ಪರಿಣಾಮವನ್ನು ಬಳಕೆದಾರರ ಆಧಾರದ 20% ಗೆ ಸಂಕುಚಿತಗೊಳಿಸಿದ್ದೇವೆ. ಅದ್ಭುತ! ಈಗ, ಪ್ರತಿಯೊಂದು ಸಂದರ್ಭದಲ್ಲೂ ನಮ್ಮ ಕೋಡ್ ಬಗ್ಗೆ ನಮಗೆ ಖಚಿತತೆ ಇಲ್ಲದಿರುವಾಗ (ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ - ಯಾವಾಗಲೂ...), ನಾವು ಮಿರರಿಂಗ್ ಮತ್ತು ಕ್ಯಾನರಿ ರೋಲ್‌ಔಟ್‌ಗಳನ್ನು ಬಳಸಬಹುದು.

ಸಮಯಾವಧಿಗಳು ಮತ್ತು ಮರುಪ್ರಯತ್ನಗಳು

ಆದರೆ ದೋಷಗಳು ಯಾವಾಗಲೂ ಕೋಡ್‌ನಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುವುದಿಲ್ಲ. "ನಿಂದ ಪಟ್ಟಿಯಲ್ಲಿ8 ಡಿಸ್ಟ್ರಿಬ್ಯೂಟೆಡ್ ಕಂಪ್ಯೂಟಿಂಗ್ ಬಗ್ಗೆ ತಪ್ಪು ಕಲ್ಪನೆಗಳು"ಮೊದಲ ಸ್ಥಾನದಲ್ಲಿ "ನೆಟ್‌ವರ್ಕ್ ವಿಶ್ವಾಸಾರ್ಹವಾಗಿದೆ" ಎಂಬ ತಪ್ಪಾದ ನಂಬಿಕೆಯಾಗಿದೆ. ವಾಸ್ತವದಲ್ಲಿ ನೆಟ್ವರ್ಕ್ ಕೇವಲ ವಿಶ್ವಾಸಾರ್ಹ, ಮತ್ತು ಈ ಕಾರಣಕ್ಕಾಗಿ ನಮಗೆ ಸಮಯ ಮೀರುವ ಅಗತ್ಯವಿದೆ (ಕಾಲಾವಧಿಗಳು) ಮತ್ತು ಮರುಪ್ರಯತ್ನಿಸುತ್ತದೆ (ಮರುಪ್ರಯತ್ನ).

ಪ್ರದರ್ಶನಕ್ಕಾಗಿ ನಾವು ಅದೇ ಸಮಸ್ಯೆಯ ಆವೃತ್ತಿಯನ್ನು ಬಳಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತೇವೆ sa-logic (buggy), ಮತ್ತು ನಾವು ಯಾದೃಚ್ಛಿಕ ವೈಫಲ್ಯಗಳೊಂದಿಗೆ ನೆಟ್ವರ್ಕ್ನ ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಅನುಕರಿಸುತ್ತೇವೆ.

ದೋಷಗಳೊಂದಿಗಿನ ನಮ್ಮ ಸೇವೆಯು ಪ್ರತಿಕ್ರಿಯಿಸಲು ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುವ 1/3 ಅವಕಾಶವನ್ನು ಹೊಂದಿರಲಿ, ಆಂತರಿಕ ಸರ್ವರ್ ದೋಷದೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುವ 1/3 ಅವಕಾಶ ಮತ್ತು ಪುಟವನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಹಿಂತಿರುಗಿಸುವ 1/3 ಅವಕಾಶ.

ಅಂತಹ ಸಮಸ್ಯೆಗಳ ಪ್ರಭಾವವನ್ನು ತಗ್ಗಿಸಲು ಮತ್ತು ಬಳಕೆದಾರರ ಜೀವನವನ್ನು ಉತ್ತಮಗೊಳಿಸಲು, ನಾವು:

ಸೇವೆಯು ಪ್ರತಿಕ್ರಿಯಿಸಲು 8 ಸೆಕೆಂಡುಗಳಿಗಿಂತ ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಂಡರೆ ಸಮಯ ಮೀರುವಿಕೆಯನ್ನು ಸೇರಿಸಿ,
ವಿನಂತಿಯು ವಿಫಲವಾದಲ್ಲಿ ಮರುಪ್ರಯತ್ನಿಸಿ.

ಅನುಷ್ಠಾನಕ್ಕಾಗಿ, ನಾವು ಈ ಕೆಳಗಿನ ಸಂಪನ್ಮೂಲ ವ್ಯಾಖ್ಯಾನವನ್ನು ಬಳಸುತ್ತೇವೆ (sa-logic-retries-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

ವಿನಂತಿಯ ಅವಧಿಯನ್ನು 8 ಸೆಕೆಂಡುಗಳಿಗೆ ಹೊಂದಿಸಲಾಗಿದೆ;
ವಿನಂತಿಗಳನ್ನು 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 ಯಿಂದಲ್ಲದಿದ್ದರೂ ಸಹ). (ಗಮನಿಸಿ: ಮಾದರಿಯ ಹೆಚ್ಚು ವಿವರವಾದ ವಿವರಣೆಯನ್ನು ಕಾಣಬಹುದು, ಉದಾಹರಣೆಗೆ, ಇಲ್ಲಿ.)

ಈ ಮಾದರಿಗಳ ಅನುಷ್ಠಾನದ ವಿವರಗಳನ್ನು ನಾನು ಬಿಟ್ಟುಬಿಡುತ್ತೇನೆ ಏಕೆಂದರೆ ಅವುಗಳು ಹುಡುಕಲು ಸುಲಭವಾಗಿದೆ ಅಧಿಕೃತ ದಸ್ತಾವೇಜನ್ನು, ಮತ್ತು ನಾನು ನಿಜವಾಗಿಯೂ ದೃಢೀಕರಣ ಮತ್ತು ಅಧಿಕಾರವನ್ನು ತೋರಿಸಲು ಬಯಸುತ್ತೇನೆ, ಅದನ್ನು ಲೇಖನದ ಮುಂದಿನ ಭಾಗದಲ್ಲಿ ಚರ್ಚಿಸಲಾಗುವುದು.

ಅನುವಾದಕರಿಂದ PS

ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿಯೂ ಓದಿ:

"ಇಸ್ಟಿಯೊ ಜೊತೆಗೆ ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗೆ ಹಿಂತಿರುಗಿ": ಭಾಗ 1 (ಮುಖ್ಯ ವೈಶಿಷ್ಟ್ಯಗಳ ಪರಿಚಯ), ಭಾಗ 3 (ದೃಢೀಕರಣ ಮತ್ತು ಅಧಿಕಾರ);
«ವಾಹಕ - ಕುಬರ್ನೆಟ್ಸ್‌ಗಾಗಿ ಹಗುರವಾದ ಸೇವಾ ಜಾಲರಿ";
«ಸೇವಾ ಜಾಲರಿ ಎಂದರೇನು ಮತ್ತು ನನಗೆ ಅದು ಏಕೆ ಬೇಕು [ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ನೊಂದಿಗೆ ಕ್ಲೌಡ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಾಗಿ]?».

ಮೂಲ: www.habr.com

ಇಸ್ಟಿಯೊ ಜೊತೆಗೆ ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗೆ ಹಿಂತಿರುಗಿ. ಭಾಗ 2