ಇಸ್ಟಿಯೊದಲ್ಲಿ ಟ್ರೇಸಿಂಗ್ ಮತ್ತು ಮಾನಿಟರಿಂಗ್: ಮೈಕ್ರೋಸರ್ವಿಸಸ್ ಮತ್ತು ಅನಿಶ್ಚಿತತೆಯ ತತ್ವ

ಹೈಸೆನ್‌ಬರ್ಗ್ ಅನಿಶ್ಚಿತತೆಯ ತತ್ವವು ನೀವು ಒಂದೇ ಸಮಯದಲ್ಲಿ ವಸ್ತುವಿನ ಸ್ಥಾನ ಮತ್ತು ಅದರ ವೇಗವನ್ನು ಅಳೆಯಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ಹೇಳುತ್ತದೆ. ಒಂದು ವಸ್ತುವು ಚಲಿಸುತ್ತಿದ್ದರೆ, ಅದಕ್ಕೆ ಯಾವುದೇ ಸ್ಥಳವಿಲ್ಲ. ಮತ್ತು ಸ್ಥಳವಿದ್ದರೆ, ಅದು ವೇಗವನ್ನು ಹೊಂದಿಲ್ಲ ಎಂದರ್ಥ.

Red Hat OpenShift ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ (ಮತ್ತು ಚಾಲನೆಯಲ್ಲಿರುವ ಕುಬರ್ನೆಟ್ಸ್) ಮೈಕ್ರೋಸರ್ವಿಸ್‌ಗಳಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ, ಸೂಕ್ತವಾದ ತೆರೆದ ಮೂಲ ಸಾಫ್ಟ್‌ವೇರ್‌ಗೆ ಧನ್ಯವಾದಗಳು, ಅವರು ತಮ್ಮ ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ಆರೋಗ್ಯ ಎರಡನ್ನೂ ಏಕಕಾಲದಲ್ಲಿ ವರದಿ ಮಾಡಬಹುದು. ಇದು ಸಹಜವಾಗಿ, ಹಳೆಯ ಹೈಸೆನ್‌ಬರ್ಗ್ ಅನ್ನು ನಿರಾಕರಿಸುವುದಿಲ್ಲ, ಆದರೆ ಕ್ಲೌಡ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ ಇದು ಅನಿಶ್ಚಿತತೆಯನ್ನು ನಿವಾರಿಸುತ್ತದೆ. ಎಲ್ಲವನ್ನೂ ನಿಯಂತ್ರಣದಲ್ಲಿಡಲು ಈ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು Istio ಸುಲಭಗೊಳಿಸುತ್ತದೆ.

ಪರಿಭಾಷೆಯನ್ನು ನಿರ್ಧರಿಸುವುದು

ಬೈ ಪತ್ತೆಹಚ್ಚುವಿಕೆ (ಟ್ರೇಸಿಂಗ್) ನಾವು ಸಿಸ್ಟಮ್ ಚಟುವಟಿಕೆಯ ಲಾಗಿಂಗ್ ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೇವೆ. ಇದು ಸಾಕಷ್ಟು ಸಾಮಾನ್ಯವೆಂದು ತೋರುತ್ತದೆ, ಆದರೆ ವಾಸ್ತವವಾಗಿ ಇಲ್ಲಿ ಮೂಲಭೂತ ನಿಯಮಗಳಲ್ಲಿ ಒಂದಾದ ಟ್ರೇಸ್ ಡೇಟಾವನ್ನು ಫಾರ್ಮ್ಯಾಟ್ ಮಾಡುವ ಬಗ್ಗೆ ಚಿಂತಿಸದೆ ಸೂಕ್ತವಾದ ಸಂಗ್ರಹಣೆಗೆ ಡಂಪ್ ಮಾಡುವುದು. ಮತ್ತು ಡೇಟಾವನ್ನು ಹುಡುಕುವ ಮತ್ತು ವಿಶ್ಲೇಷಿಸುವ ಎಲ್ಲಾ ಕೆಲಸವು ಗ್ರಾಹಕರ ಮೇಲಿದೆ. ಇಸ್ಟಿಯೊ ಜೇಗರ್ ಟ್ರೇಸಿಂಗ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಬಳಸುತ್ತದೆ, ಇದು ಓಪನ್ ಟ್ರೇಸಿಂಗ್ ಡೇಟಾ ಮಾದರಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ.

ಹಾದಿಗಳಲ್ಲಿ (ಕುರುಹುಗಳು, ಮತ್ತು "ಕುರುಹುಗಳು" ಎಂಬ ಪದವನ್ನು ಇಲ್ಲಿ "ಕುರುಹುಗಳು" ಎಂಬ ಅರ್ಥದಲ್ಲಿ ಬಳಸಲಾಗುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, ಬ್ಯಾಲಿಸ್ಟಿಕ್ ಪರೀಕ್ಷೆಯಲ್ಲಿ) ಅವರು ಹೇಳಿದಂತೆ ವಿನಂತಿಯ ಅಂಗೀಕಾರ ಅಥವಾ ಕೆಲಸದ ಘಟಕವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ವಿವರಿಸುವ ಡೇಟಾವನ್ನು ನಾವು ಕರೆಯುತ್ತೇವೆ, "ಇಂದ ಮತ್ತು ಕಡೆಗೆ." ಉದಾಹರಣೆಗೆ, ಬಳಕೆದಾರರು ವೆಬ್ ಪುಟದಲ್ಲಿನ ಬಟನ್ ಅನ್ನು ಕ್ಲಿಕ್ ಮಾಡಿದ ಕ್ಷಣದಿಂದ ಡೇಟಾವನ್ನು ಹಿಂತಿರುಗಿಸುವವರೆಗೆ, ಒಳಗೊಂಡಿರುವ ಎಲ್ಲಾ ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳನ್ನು ಒಳಗೊಂಡಂತೆ ನಡೆಯುವ ಎಲ್ಲವೂ. ವಿನಂತಿಯ ರೌಂಡ್ ಟ್ರಿಪ್ ಅನ್ನು ಒಂದು ಜಾಡಿನ ಸಂಪೂರ್ಣವಾಗಿ ವಿವರಿಸುತ್ತದೆ (ಅಥವಾ ಮಾದರಿಗಳು) ಎಂದು ನಾವು ಹೇಳಬಹುದು. ಜೇಗರ್ ಇಂಟರ್‌ಫೇಸ್‌ನಲ್ಲಿ, ಕುರುಹುಗಳನ್ನು ಸಮಯದ ಅಕ್ಷದ ಉದ್ದಕ್ಕೂ ಘಟಕಗಳಾಗಿ ವಿಭಜಿಸಲಾಗುತ್ತದೆ, ಸರಪಳಿಯನ್ನು ಹೇಗೆ ಪ್ರತ್ಯೇಕ ಲಿಂಕ್‌ಗಳಾಗಿ ವಿಭಜಿಸಬಹುದು. ಲಿಂಕ್‌ಗಳ ಬದಲಿಗೆ, ಮಾರ್ಗವು ಸ್ಪ್ಯಾನ್‌ಗಳು ಎಂದು ಕರೆಯಲ್ಪಡುತ್ತದೆ.

ಕಣ್ ಕೆಲಸದ ಘಟಕದ ಪ್ರಾರಂಭದಿಂದ ಅದರ ಪೂರ್ಣಗೊಳ್ಳುವವರೆಗೆ ಮಧ್ಯಂತರವಾಗಿದೆ. ಸಾದೃಶ್ಯವನ್ನು ಮುಂದುವರೆಸುತ್ತಾ, ಪ್ರತಿ ಸ್ಪ್ಯಾನ್ ಸರಪಳಿಯಲ್ಲಿ ಪ್ರತ್ಯೇಕ ಲಿಂಕ್ ಅನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ ಎಂದು ನಾವು ಹೇಳಬಹುದು. ಒಂದು ಸ್ಪ್ಯಾನ್ ಒಂದು ಅಥವಾ ಹೆಚ್ಚಿನ ಮಕ್ಕಳ ವ್ಯಾಪ್ತಿಯನ್ನು ಹೊಂದಿರಬಹುದು (ಅಥವಾ ಇಲ್ಲದಿರಬಹುದು). ಇದರ ಪರಿಣಾಮವಾಗಿ, ಅತ್ಯಂತ ಮೇಲ್ಭಾಗದ ಸ್ಪ್ಯಾನ್ (ರೂಟ್ ಸ್ಪ್ಯಾನ್) ಅದು ಸೇರಿರುವ ಜಾಡಿನ ಅದೇ ಒಟ್ಟು ಅವಧಿಯನ್ನು ಹೊಂದಿರುತ್ತದೆ.

ಮಾನಿಟರಿಂಗ್ - ಇದು ವಾಸ್ತವವಾಗಿ, ನಿಮ್ಮ ಸಿಸ್ಟಂನ ಅತ್ಯಂತ ಅವಲೋಕನವಾಗಿದೆ - ನಿಮ್ಮ ಕಣ್ಣುಗಳಿಂದ, UI ಅಥವಾ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಪರಿಕರಗಳ ಮೂಲಕ. ಮಾನಿಟರಿಂಗ್ ಟ್ರೇಸ್ ಡೇಟಾವನ್ನು ಆಧರಿಸಿದೆ. ಇಸ್ಟಿಯೊದಲ್ಲಿ, ಮಾನಿಟರಿಂಗ್ ಅನ್ನು ಪ್ರಮೀತಿಯಸ್ ಬಳಸಿ ಅಳವಡಿಸಲಾಗಿದೆ ಮತ್ತು ಸೂಕ್ತವಾದ UI ಅನ್ನು ಹೊಂದಿದೆ. ಎಚ್ಚರಿಕೆಗಳು ಮತ್ತು ಎಚ್ಚರಿಕೆ ನಿರ್ವಾಹಕರನ್ನು ಬಳಸಿಕೊಂಡು ಪ್ರಮೀತಿಯಸ್ ಸ್ವಯಂಚಾಲಿತ ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ.

ನಾವು ಗುರುತುಗಳನ್ನು ಬಿಡುತ್ತೇವೆ

ಟ್ರೇಸಿಂಗ್ ಸಾಧ್ಯವಾಗಬೇಕಾದರೆ, ಅಪ್ಲಿಕೇಶನ್ ಸ್ಪ್ಯಾನ್‌ಗಳ ಸಂಗ್ರಹವನ್ನು ರಚಿಸಬೇಕು. ನಂತರ ಅವರು ಜೇಗರ್‌ಗೆ ರಫ್ತು ಮಾಡಬೇಕಾಗಿದೆ, ಇದರಿಂದಾಗಿ ಅದು ಜಾಡಿನ ದೃಶ್ಯ ಪ್ರಾತಿನಿಧ್ಯವನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ಇತರ ವಿಷಯಗಳ ಜೊತೆಗೆ, ಈ ವ್ಯಾಪ್ತಿಯು ಕಾರ್ಯಾಚರಣೆಯ ಹೆಸರನ್ನು ಗುರುತಿಸುತ್ತದೆ, ಜೊತೆಗೆ ಅದರ ಪ್ರಾರಂಭ ಮತ್ತು ಅಂತ್ಯದ ಸಮಯದ ಮುದ್ರೆಗಳನ್ನು ಗುರುತಿಸುತ್ತದೆ. ಜೇಗರ್-ನಿರ್ದಿಷ್ಟ HTTP ವಿನಂತಿ ಹೆಡರ್‌ಗಳನ್ನು ಒಳಬರುವ ವಿನಂತಿಗಳಿಂದ ಹೊರಹೋಗುವ ವಿನಂತಿಗಳಿಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ಮೂಲಕ ಸ್ಪ್ಯಾನ್‌ಗಳ ಪ್ರಸರಣವನ್ನು ಸಾಧಿಸಲಾಗುತ್ತದೆ. ಬಳಸಿದ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಯನ್ನು ಅವಲಂಬಿಸಿ, ಇದಕ್ಕೆ ಅಪ್ಲಿಕೇಶನ್ ಮೂಲ ಕೋಡ್‌ಗೆ ಸಣ್ಣ ಬದಲಾವಣೆಗಳು ಬೇಕಾಗಬಹುದು. ಸ್ಪ್ರಿಂಗ್ ಕಾನ್ಫಿಗರೇಶನ್ ಕ್ಲಾಸ್‌ನಲ್ಲಿ ನಿಮ್ಮ ವಿನಂತಿಗೆ B3 (ಜಿಪ್‌ಕಿನ್-ಶೈಲಿಯ) ಹೆಡರ್‌ಗಳನ್ನು ಸೇರಿಸುವ ಜಾವಾದಲ್ಲಿ (ಸ್ಪ್ರಿಂಗ್ ಬೂಟ್ ಫ್ರೇಮ್‌ವರ್ಕ್ ಬಳಸಿ) ಮಾದರಿ ಕೋಡ್ ಕೆಳಗೆ ಇದೆ:

ಕೆಳಗಿನ ಹೆಡರ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ:

ನೀವು ಜಾವಾವನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ, ನೀವು ಕೋಡ್ ಅನ್ನು ಮಾತ್ರ ಬಿಡಬಹುದು ಮತ್ತು ಮಾವೆನ್ POM ಫೈಲ್‌ಗೆ ಕೆಲವು ಸಾಲುಗಳನ್ನು ಸೇರಿಸಿ ಮತ್ತು ಪರಿಸರ ವೇರಿಯಬಲ್‌ಗಳನ್ನು ಹೊಂದಿಸಬಹುದು. Jaeger Tracer Resolver ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ನಿಮ್ಮ POM.XML ಫೈಲ್‌ಗೆ ನೀವು ಸೇರಿಸಬೇಕಾದ ಸಾಲುಗಳು ಇಲ್ಲಿವೆ:

ಮತ್ತು ಅನುಗುಣವಾದ ಪರಿಸರ ವೇರಿಯಬಲ್‌ಗಳನ್ನು ಡಾಕರ್‌ಫೈಲ್‌ನಲ್ಲಿ ಹೊಂದಿಸಲಾಗಿದೆ:

ಅಷ್ಟೆ, ಈಗ ಎಲ್ಲವನ್ನೂ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ನಮ್ಮ ಮೈಕ್ರೋಸರ್ವಿಸ್ ಟ್ರೇಸ್ ಡೇಟಾವನ್ನು ಉತ್ಪಾದಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ.

ಸಾಮಾನ್ಯ ಪರಿಭಾಷೆಯಲ್ಲಿ ನೋಡೋಣ

ಇಸ್ಟಿಯೊ ಗ್ರಾಫಾನಾ ಆಧಾರಿತ ಸರಳ ನಿಯಂತ್ರಣ ಫಲಕವನ್ನು ಒಳಗೊಂಡಿದೆ. ಒಮ್ಮೆ ಎಲ್ಲವನ್ನೂ ಕಾನ್ಫಿಗರ್ ಮಾಡಿ ಮತ್ತು Red Hat OpenShift PaaS ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ ಚಾಲನೆಗೊಂಡರೆ (ನಮ್ಮ ಉದಾಹರಣೆಯಲ್ಲಿ, Red Hat OpenShift ಮತ್ತು Kubernetes ಅನ್ನು minishift ನಲ್ಲಿ ನಿಯೋಜಿಸಲಾಗಿದೆ), ಈ ಫಲಕವನ್ನು ಈ ಕೆಳಗಿನ ಆಜ್ಞೆಯೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತದೆ:

open "$(minishift openshift service grafana -u)/d/1/istio-dashboard?refresh=5⩝Id=1"

ಸಿಸ್ಟಮ್ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ತ್ವರಿತವಾಗಿ ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು ಗ್ರಾಫನಾ ಫಲಕವು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಈ ಫಲಕದ ಒಂದು ತುಣುಕನ್ನು ಕೆಳಗಿನ ಚಿತ್ರದಲ್ಲಿ ತೋರಿಸಲಾಗಿದೆ:

ಗ್ರಾಹಕರ ಮೈಕ್ರೊ ಸರ್ವಿಸ್ ಪ್ರಾಶಸ್ತ್ಯದ v1 ಮೈಕ್ರೊ ಸರ್ವೀಸ್ ಎಂದು ಕರೆಯುವುದನ್ನು ಇಲ್ಲಿ ನೀವು ನೋಡಬಹುದು, ಇದು ಶಿಫಾರಸು v1 ಮತ್ತು v2 ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ಎಂದು ಕರೆಯುತ್ತದೆ. Grafana ಫಲಕವು ಉನ್ನತ ಮಟ್ಟದ ಮೆಟ್ರಿಕ್‌ಗಳಿಗಾಗಿ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ರೋ ಬ್ಲಾಕ್ ಅನ್ನು ಹೊಂದಿದೆ, ಉದಾಹರಣೆಗೆ ಒಟ್ಟು ವಿನಂತಿಗಳ ಸಂಖ್ಯೆ (ಜಾಗತಿಕ ವಿನಂತಿಯ ಪರಿಮಾಣ), ಯಶಸ್ಸಿನ ದರಗಳು, 4xx ದೋಷಗಳು. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಪ್ರತಿ ಸೇವೆಗೆ ಗ್ರಾಫ್‌ಗಳೊಂದಿಗೆ ಸರ್ವರ್ ಮೆಶ್ ವೀಕ್ಷಣೆ ಮತ್ತು ಪ್ರತಿ ಸೇವೆಗೆ ಪ್ರತಿ ಕಂಟೇನರ್‌ನ ವಿವರವಾದ ಮಾಹಿತಿಯನ್ನು ವೀಕ್ಷಿಸಲು ಸೇವೆಗಳ ಸಾಲು ಬ್ಲಾಕ್ ಇದೆ.

ಈಗ ಆಳವಾಗಿ ಅಗೆಯೋಣ

ಸರಿಯಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ ಟ್ರೇಸಿಂಗ್‌ನೊಂದಿಗೆ, ಇಸ್ಟಿಯೊ, ಅವರು ಹೇಳಿದಂತೆ, ಬಾಕ್ಸ್‌ನ ಹೊರಗೆ ಸರಿಯಾಗಿ ಸಿಸ್ಟಮ್ ಕಾರ್ಯಕ್ಷಮತೆಯ ವಿಶ್ಲೇಷಣೆಯನ್ನು ಆಳವಾಗಿ ಅಧ್ಯಯನ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. Jaeger's UI ನಲ್ಲಿ, ನೀವು ಕುರುಹುಗಳನ್ನು ವೀಕ್ಷಿಸಬಹುದು ಮತ್ತು ಅವು ಎಷ್ಟು ದೂರ ಮತ್ತು ಆಳವಾಗಿ ಹೋಗುತ್ತವೆ ಎಂಬುದನ್ನು ನೋಡಬಹುದು, ಹಾಗೆಯೇ ಕಾರ್ಯಕ್ಷಮತೆಯ ಅಡಚಣೆಗಳನ್ನು ದೃಷ್ಟಿಗೋಚರವಾಗಿ ಸ್ಥಳೀಕರಿಸಬಹುದು. ಮಿನಿಶಿಫ್ಟ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ Red Hat OpenShift ಅನ್ನು ಬಳಸುವಾಗ, ಈ ಕೆಳಗಿನ ಆಜ್ಞೆಯೊಂದಿಗೆ Jaeger UI ಅನ್ನು ಪ್ರಾರಂಭಿಸಿ:

minishift openshift service jaeger-query --in-browser

ಈ ಪರದೆಯ ಮೇಲೆ ಪತ್ತೆಹಚ್ಚುವಿಕೆಯ ಬಗ್ಗೆ ನೀವು ಏನು ಹೇಳಬಹುದು:

• ಇದನ್ನು 7 ಸ್ಪ್ಯಾನ್‌ಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ.
• ಒಟ್ಟು ಎಕ್ಸಿಕ್ಯೂಶನ್ ಸಮಯ 6.99 ms ಆಗಿದೆ.
• ಸರಪಳಿಯಲ್ಲಿ ಕೊನೆಯದಾಗಿರುವ ಶಿಫಾರಸು ಮೈಕ್ರೊ ಸರ್ವಿಸ್, 0.69 ಎಂಎಸ್ ಕಳೆಯುತ್ತದೆ.

ಈ ಪ್ರಕಾರದ ರೇಖಾಚಿತ್ರಗಳು ಒಂದು ಕಳಪೆ ಕಾರ್ಯನಿರ್ವಹಣೆಯ ಸೇವೆಯಿಂದಾಗಿ, ಸಂಪೂರ್ಣ ಸಿಸ್ಟಮ್ನ ಕಾರ್ಯಕ್ಷಮತೆಯು ಬಳಲುತ್ತಿರುವಾಗ ಪರಿಸ್ಥಿತಿಯನ್ನು ತ್ವರಿತವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.

ಈಗ ನಾವು ಕಾರ್ಯವನ್ನು ಸಂಕೀರ್ಣಗೊಳಿಸೋಣ ಮತ್ತು ಶಿಫಾರಸಿನ ಎರಡು ನಿದರ್ಶನಗಳನ್ನು ಪ್ರಾರಂಭಿಸೋಣ: ಕಮಾಂಡ್ oc ಸ್ಕೇಲ್‌ನೊಂದಿಗೆ v2 ಮೈಕ್ರೊ ಸರ್ವಿಸ್ -ಪ್ರತಿಕೃತಿಗಳು=2 ನಿಯೋಜನೆ/ಶಿಫಾರಸು-v2. ಇದರ ನಂತರ ನಾವು ಹೊಂದಿರುವ ಪಾಡ್‌ಗಳು ಇಲ್ಲಿವೆ:

ನಾವು ಈಗ ಮತ್ತೆ ಜೇಗರ್‌ಗೆ ಬದಲಾಯಿಸಿದರೆ ಮತ್ತು ಶಿಫಾರಸು ಸೇವೆಯ ವ್ಯಾಪ್ತಿಯನ್ನು ವಿಸ್ತರಿಸಿದರೆ, ವಿನಂತಿಗಳನ್ನು ಯಾವ ಪಾಡ್‌ಗೆ ಕಳುಹಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ನಾವು ನೋಡಬಹುದು. ಹೀಗಾಗಿ, ನಿರ್ದಿಷ್ಟ ಪಾಡ್ನ ಮಟ್ಟದಲ್ಲಿ ನಾವು ಸುಲಭವಾಗಿ ಬ್ರೇಕ್ಗಳನ್ನು ಸ್ಥಳೀಕರಿಸಬಹುದು. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನೀವು ನೋಡ್_ಐಡಿ ಕ್ಷೇತ್ರವನ್ನು ನೋಡಬೇಕು:

ಎಲ್ಲವೂ ಎಲ್ಲಿ ಮತ್ತು ಹೇಗೆ ಹೋಗುತ್ತದೆ

ಈಗ ನಾವು ಪ್ರಮೀತಿಯಸ್ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಹೋಗುತ್ತೇವೆ ಮತ್ತು ಶಿಫಾರಸು ಸೇವೆಯ ಎರಡನೇ ಮತ್ತು ಮೊದಲ ಆವೃತ್ತಿಗಳ ನಡುವಿನ ವಿನಂತಿಗಳನ್ನು 2: 1 ಅನುಪಾತದಲ್ಲಿ ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಕೆಲಸ ಮಾಡುವ ಪಾಡ್‌ಗಳ ಸಂಖ್ಯೆಗೆ ಅನುಗುಣವಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ ಎಂದು ನಾವು ನಿರೀಕ್ಷಿಸುತ್ತೇವೆ. ಇದಲ್ಲದೆ, ಈ ಗ್ರಾಫ್ ಪಾಡ್‌ಗಳು ಮೇಲಕ್ಕೆ ಮತ್ತು ಕೆಳಕ್ಕೆ ಅಳೆಯುವುದರಿಂದ ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಬದಲಾಗುತ್ತದೆ, ಇದು ಕ್ಯಾನರಿ ನಿಯೋಜನೆಗೆ ವಿಶೇಷವಾಗಿ ಉಪಯುಕ್ತವಾಗಿರುತ್ತದೆ (ಮುಂದಿನ ಬಾರಿ ಈ ನಿಯೋಜನೆ ಯೋಜನೆಯನ್ನು ನಾವು ಹತ್ತಿರದಿಂದ ನೋಡುತ್ತೇವೆ).

ಇದು ಕೇವಲ ಆರಂಭವಾಗಿದೆ

ವಾಸ್ತವವಾಗಿ, ಇಂದು ನಾವು, ಅವರು ಹೇಳಿದಂತೆ, ಜೇಗರ್, ಗ್ರಾಫಾನಾ ಮತ್ತು ಪ್ರಮೀತಿಯಸ್ ಬಗ್ಗೆ ಉಪಯುಕ್ತ ಮಾಹಿತಿಯ ಸಂಪತ್ತಿನ ಮೇಲ್ಮೈಯನ್ನು ಮಾತ್ರ ಗೀಚಿದ್ದೇವೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಇದು ನಮ್ಮ ಗುರಿಯಾಗಿತ್ತು - ನಿಮ್ಮನ್ನು ಸರಿಯಾದ ದಿಕ್ಕಿನಲ್ಲಿ ತೋರಿಸುವುದು ಮತ್ತು ಇಸ್ಟಿಯೊಗೆ ಭವಿಷ್ಯವನ್ನು ತೆರೆಯುವುದು.

ಮತ್ತು ನೆನಪಿಡಿ, ಇದೆಲ್ಲವನ್ನೂ ಈಗಾಗಲೇ ಇಸ್ಟಿಯೊದಲ್ಲಿ ನಿರ್ಮಿಸಲಾಗಿದೆ. ಕೆಲವು ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಗಳನ್ನು (ಉದಾಹರಣೆಗೆ, ಜಾವಾ) ಮತ್ತು ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳನ್ನು ಬಳಸುವಾಗ (ಉದಾಹರಣೆಗೆ, ಸ್ಪ್ರಿಂಗ್ ಬೂಟ್), ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್ ಅನ್ನು ಸ್ಪರ್ಶಿಸದೆಯೇ ಇವೆಲ್ಲವನ್ನೂ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು. ಹೌದು, ನೀವು ಇತರ ಭಾಷೆಗಳನ್ನು ಬಳಸಿದರೆ ಕೋಡ್ ಅನ್ನು ಸ್ವಲ್ಪ ಮಾರ್ಪಡಿಸಬೇಕಾಗುತ್ತದೆ, ಪ್ರಾಥಮಿಕವಾಗಿ Nodejs ಅಥವಾ C# ಎಂದರ್ಥ. ಆದರೆ ಪತ್ತೆಹಚ್ಚುವಿಕೆ (ಓದಿ: "ಟ್ರೇಸಿಂಗ್") ವಿಶ್ವಾಸಾರ್ಹ ಕ್ಲೌಡ್ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ರಚಿಸಲು ಪೂರ್ವಾಪೇಕ್ಷಿತಗಳಲ್ಲಿ ಒಂದಾಗಿರುವುದರಿಂದ, ನೀವು ಇಸ್ಟಿಯೊ ಅಥವಾ ಇಲ್ಲದಿದ್ದರೂ ಕೋಡ್ ಅನ್ನು ಹೇಗಾದರೂ ಸಂಪಾದಿಸಬೇಕಾಗುತ್ತದೆ. ಹಾಗಾದರೆ ನಿಮ್ಮ ಪ್ರಯತ್ನಗಳನ್ನು ಉತ್ತಮ ಬಳಕೆಗೆ ಏಕೆ ಹಾಕಬಾರದು?

"ಎಲ್ಲಿ?" ಎಂಬ ಪ್ರಶ್ನೆಗಳಿಗೆ ಯಾವಾಗಲೂ ಉತ್ತರಿಸಲು ಕನಿಷ್ಠ ಮತ್ತು "ಎಷ್ಟು ವೇಗವಾಗಿ?" 100% ಖಚಿತತೆಯೊಂದಿಗೆ.

ಇಸ್ಟಿಯೊದಲ್ಲಿ ಚೋಸ್ ಎಂಜಿನಿಯರಿಂಗ್: ಅದು ಹೇಗೆ ಉದ್ದೇಶಿಸಲ್ಪಟ್ಟಿದೆ

ವಸ್ತುಗಳನ್ನು ಮುರಿಯುವ ಸಾಮರ್ಥ್ಯವು ಅವುಗಳನ್ನು ಮುರಿಯುವುದನ್ನು ತಡೆಯಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.

ಸಾಫ್ಟ್‌ವೇರ್ ಪರೀಕ್ಷೆ ಕಷ್ಟ ಮಾತ್ರವಲ್ಲ, ಮುಖ್ಯವೂ ಆಗಿದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಸರಿಯಾಗಿರುವುದನ್ನು ಪರೀಕ್ಷಿಸುವುದು (ಉದಾಹರಣೆಗೆ, ಒಂದು ಕಾರ್ಯವು ಸರಿಯಾದ ಫಲಿತಾಂಶವನ್ನು ನೀಡುತ್ತದೆಯೇ) ಒಂದು ವಿಷಯ, ಆದರೆ ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲದ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಪರೀಕ್ಷಿಸುವುದು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ಕಾರ್ಯವಾಗಿದೆ (ನೆಟ್‌ವರ್ಕ್ ಯಾವಾಗಲೂ ವೈಫಲ್ಯಗಳಿಲ್ಲದೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ಸಾಮಾನ್ಯವಾಗಿ ಭಾವಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಇದು ವಿತರಿಸಿದ ಲೆಕ್ಕಾಚಾರಗಳ ಬಗ್ಗೆ ಎಂಟು ತಪ್ಪುಗ್ರಹಿಕೆಗಳಲ್ಲಿ ಮೊದಲನೆಯದು). ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವಲ್ಲಿನ ತೊಂದರೆಗಳಲ್ಲಿ ಒಂದಾದ ವ್ಯವಸ್ಥೆಯಲ್ಲಿನ ವೈಫಲ್ಯಗಳನ್ನು ಹೇಗೆ ಅನುಕರಿಸುವುದು ಅಥವಾ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಅವುಗಳನ್ನು ಪರಿಚಯಿಸುವುದು, ಕರೆಯಲ್ಪಡುವ ದೋಷ ಇಂಜೆಕ್ಷನ್ ಅನ್ನು ನಿರ್ವಹಿಸುವುದು. ಅಪ್ಲಿಕೇಶನ್‌ನ ಮೂಲ ಕೋಡ್ ಅನ್ನು ಮಾರ್ಪಡಿಸುವ ಮೂಲಕ ಇದನ್ನು ಮಾಡಬಹುದು. ಆದರೆ ನಂತರ ನೀವು ಇನ್ನು ಮುಂದೆ ನಿಮ್ಮ ಮೂಲ ಕೋಡ್ ಅನ್ನು ಪರೀಕ್ಷಿಸುವುದಿಲ್ಲ, ಆದರೆ ನಿರ್ದಿಷ್ಟವಾಗಿ ವೈಫಲ್ಯಗಳನ್ನು ಅನುಕರಿಸುವ ಅದರ ಆವೃತ್ತಿ. ಪರಿಣಾಮವಾಗಿ, ನೀವು ದೋಷದ ಚುಚ್ಚುಮದ್ದಿನ ಮಾರಣಾಂತಿಕ ತೆಕ್ಕೆಗೆ ಬೀಳುವ ಮತ್ತು ಹೈಸೆನ್‌ಬಗ್‌ಗಳನ್ನು ಎದುರಿಸುವ ಅಪಾಯವಿದೆ - ನೀವು ಅವುಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಪ್ರಯತ್ನಿಸಿದಾಗ ಕಣ್ಮರೆಯಾಗುವ ವೈಫಲ್ಯಗಳು.

ಈ ಸಂಕೀರ್ಣತೆಗಳನ್ನು ಒಂದೇ ತುಣುಕಿನಲ್ಲಿ ನಿಭಾಯಿಸಲು ಇಸ್ಟಿಯೊ ನಿಮಗೆ ಹೇಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಈಗ ನಾವು ನಿಮಗೆ ತೋರಿಸುತ್ತೇವೆ.

ಎಲ್ಲವೂ ಶ್ರೇಷ್ಠವಾಗಿರುವಾಗ ಎಲ್ಲವೂ ಹೇಗಿರುತ್ತದೆ?

ಕೆಳಗಿನ ಸನ್ನಿವೇಶವನ್ನು ಪರಿಗಣಿಸಿ: ನಮ್ಮ ಶಿಫಾರಸು ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಾಗಿ ನಾವು ಎರಡು ಪಾಡ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಅದನ್ನು ನಾವು ಇಸ್ಟಿಯೊ ಟ್ಯುಟೋರಿಯಲ್‌ನಿಂದ ತೆಗೆದುಕೊಂಡಿದ್ದೇವೆ. ಒಂದು ಪಾಡ್ ಅನ್ನು v1 ಎಂದು ಲೇಬಲ್ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ಇನ್ನೊಂದನ್ನು v2 ಎಂದು ಲೇಬಲ್ ಮಾಡಲಾಗಿದೆ. ನೀವು ನೋಡುವಂತೆ, ಇಲ್ಲಿಯವರೆಗೆ ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ:

(ಅಂದಹಾಗೆ, ಬಲಭಾಗದಲ್ಲಿರುವ ಸಂಖ್ಯೆಯು ಪ್ರತಿ ಪಾಡ್‌ಗೆ ಕೇವಲ ಕರೆ ಕೌಂಟರ್ ಆಗಿದೆ)

ಆದರೆ ಅದು ನಮಗೆ ಬೇಕಾಗಿಲ್ಲ, ಸರಿ? ಸರಿ, ಮೂಲ ಕೋಡ್ ಅನ್ನು ಸ್ಪರ್ಶಿಸದೆ ಎಲ್ಲವನ್ನೂ ಮುರಿಯಲು ಪ್ರಯತ್ನಿಸೋಣ.

ಮೈಕ್ರೋ ಸರ್ವಿಸ್ ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿ ನಾವು ಅಡಚಣೆಗಳನ್ನು ವ್ಯವಸ್ಥೆಗೊಳಿಸುತ್ತೇವೆ

ಅರ್ಧದಷ್ಟು ಬಾರಿ ವಿಫಲಗೊಳ್ಳುವ (ದೋಷ) ಇಸ್ಟಿಯೊ ರೂಟಿಂಗ್ ನಿಯಮಕ್ಕಾಗಿ yaml ಫೈಲ್ ಕೆಳಗೆ ಇದೆ. ಸರ್ವರ್ 503):

ಅರ್ಧದಷ್ಟು ಪ್ರಕರಣಗಳಲ್ಲಿ 503 ದೋಷವನ್ನು ಹಿಂತಿರುಗಿಸಬೇಕು ಎಂದು ನಾವು ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳುತ್ತೇವೆ ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ಗಮನಿಸಿ.

ವೈಫಲ್ಯಗಳನ್ನು ಅನುಕರಿಸಲು ನಾವು ಈ ನಿಯಮವನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿದ ನಂತರ ಲೂಪ್‌ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಕರ್ಲ್ ಆಜ್ಞೆಯ ಸ್ಕ್ರೀನ್‌ಶಾಟ್ ಹೇಗಿರುತ್ತದೆ ಎಂಬುದು ಇಲ್ಲಿದೆ. ನೀವು ನೋಡುವಂತೆ, ಅರ್ಧದಷ್ಟು ವಿನಂತಿಗಳು ದೋಷ 503 ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತವೆ, ಯಾವ ಪಾಡ್ - v1 ಅಥವಾ v2 - ಅವುಗಳು ಇಲ್ಲಿಗೆ ಹೋಗುತ್ತವೆ:

ಸಾಮಾನ್ಯ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಪುನಃಸ್ಥಾಪಿಸಲು, ಈ ನಿಯಮವನ್ನು ಅಳಿಸಲು ಸಾಕು, ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ istioctl ಅಳಿಸಿ ರೂಟ್ರೂಲ್ ಶಿಫಾರಸು-503 -n ಟ್ಯುಟೋರಿಯಲ್ ಆಜ್ಞೆಯೊಂದಿಗೆ. ಇಲ್ಲಿ, ಟ್ಯುಟೋರಿಯಲ್ ಎನ್ನುವುದು ನಮ್ಮ Istio ಟ್ಯುಟೋರಿಯಲ್ ಅನ್ನು ನಡೆಸುವ Red Hat OpenShift ಯೋಜನೆಯ ಹೆಸರಾಗಿದೆ.

ಕೃತಕ ವಿಳಂಬಗಳನ್ನು ಪರಿಚಯಿಸಲಾಗುತ್ತಿದೆ

ನಕಲಿ 503 ದೋಷಗಳು ವೈಫಲ್ಯಕ್ಕೆ ಸಿಸ್ಟಂನ ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವವನ್ನು ಪರೀಕ್ಷಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಆದರೆ ವಿಳಂಬವನ್ನು ಊಹಿಸುವ ಮತ್ತು ನಿಭಾಯಿಸುವ ಸಾಮರ್ಥ್ಯವು ನಿಮ್ಮನ್ನು ಇನ್ನಷ್ಟು ಪ್ರಭಾವಿಸುತ್ತದೆ. ಮತ್ತು ನಿಜ ಜೀವನದಲ್ಲಿ ವಿಳಂಬಗಳು ವೈಫಲ್ಯಗಳಿಗಿಂತ ಹೆಚ್ಚಾಗಿ ಸಂಭವಿಸುತ್ತವೆ. ನಿಧಾನ ಮೈಕ್ರೊ ಸರ್ವಿಸ್ ಎಂಬುದು ಸಂಪೂರ್ಣ ವ್ಯವಸ್ಥೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವ ವಿಷವಾಗಿದೆ. Istio ನೊಂದಿಗೆ, ನಿಮ್ಮ ವಿಳಂಬ-ಸಂಬಂಧಿತ ಕೋಡ್ ಅನ್ನು ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಬದಲಾಯಿಸದೆಯೇ ನೀವು ಪರೀಕ್ಷಿಸಬಹುದು. ಮೊದಲಿಗೆ, ಕೃತಕವಾಗಿ ಪರಿಚಯಿಸಲಾದ ನೆಟ್ವರ್ಕ್ ವಿಳಂಬಗಳ ಸಂದರ್ಭದಲ್ಲಿ ಇದನ್ನು ಹೇಗೆ ಮಾಡಬೇಕೆಂದು ನಾವು ತೋರಿಸುತ್ತೇವೆ.

ಈ ರೀತಿಯಲ್ಲಿ ಪರೀಕ್ಷಿಸಿದ ನಂತರ, ನಿಮ್ಮ ಕೋಡ್ ಅನ್ನು ಟ್ವೀಕ್ ಮಾಡಲು ನಿಮಗೆ ಬೇಕಾಗಬಹುದು (ಅಥವಾ ಬಯಸಬಹುದು) ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ಗಮನಿಸಿ. ಇಲ್ಲಿ ಒಳ್ಳೆಯ ಸುದ್ದಿ ಏನೆಂದರೆ, ಈ ಸಂದರ್ಭದಲ್ಲಿ ನೀವು ಪ್ರತಿಕ್ರಿಯಾತ್ಮಕವಾಗಿರುವುದಕ್ಕಿಂತ ಪೂರ್ವಭಾವಿಯಾಗಿರುತ್ತೀರಿ. ಅಭಿವೃದ್ಧಿ ಚಕ್ರವನ್ನು ನಿಖರವಾಗಿ ಹೇಗೆ ರಚಿಸಬೇಕು: ಕೋಡಿಂಗ್-ಟೆಸ್ಟಿಂಗ್-ಫೀಡ್‌ಬ್ಯಾಕ್-ಕೋಡಿಂಗ್-ಟೆಸ್ಟಿಂಗ್...

ಈ ನಿಯಮ ಹೇಗಿದೆ... ಆದರೂ ಏನು ಗೊತ್ತಾ? ಇಸ್ಟಿಯೊ ತುಂಬಾ ಸರಳವಾಗಿದೆ ಮತ್ತು ಈ yaml ಫೈಲ್ ತುಂಬಾ ಸ್ಪಷ್ಟವಾಗಿದೆ, ಈ ಉದಾಹರಣೆಯಲ್ಲಿ ಎಲ್ಲವೂ ಸ್ವತಃ ಹೇಳುತ್ತದೆ, ಒಮ್ಮೆ ನೋಡಿ:

ಅರ್ಧ ಸಮಯ ನಾವು 7 ಸೆಕೆಂಡುಗಳ ವಿಳಂಬವನ್ನು ಅನುಭವಿಸುತ್ತೇವೆ. ಮತ್ತು ನಾವು ಮೂಲ ಕೋಡ್‌ಗೆ ಸ್ಲೀಪ್ ಕಮಾಂಡ್ ಅನ್ನು ಸೇರಿಸಿದರೆ ಇದು ಒಂದೇ ಆಗಿರುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಇಸ್ಟಿಯೊ ವಾಸ್ತವವಾಗಿ ವಿನಂತಿಯನ್ನು 7 ಸೆಕೆಂಡುಗಳಷ್ಟು ವಿಳಂಬಗೊಳಿಸುತ್ತದೆ. ಇಸ್ಟಿಯೊ ಜೇಗರ್ ಟ್ರೇಸಿಂಗ್ ಅನ್ನು ಬೆಂಬಲಿಸುವುದರಿಂದ, ಕೆಳಗಿನ ಸ್ಕ್ರೀನ್‌ಶಾಟ್‌ನಲ್ಲಿ ತೋರಿಸಿರುವಂತೆ ಜೇಗರ್ UI ನಲ್ಲಿ ಈ ವಿಳಂಬವು ಗಮನಾರ್ಹವಾಗಿದೆ. ರೇಖಾಚಿತ್ರದ ಮೇಲಿನ ಬಲ ಮೂಲೆಯಲ್ಲಿರುವ ದೀರ್ಘ ವಿನಂತಿಗೆ ಗಮನ ಕೊಡಿ - ಅದರ ಅವಧಿಯು 7.02 ಸೆಕೆಂಡುಗಳು:

ನೆಟ್‌ವರ್ಕ್ ಲೇಟೆನ್ಸಿ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ನಿಮ್ಮ ಕೋಡ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಲು ಈ ಸ್ಕ್ರಿಪ್ಟ್ ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಮತ್ತು ಈ ನಿಯಮವನ್ನು ತೆಗೆದುಹಾಕುವ ಮೂಲಕ, ನಾವು ಕೃತಕ ವಿಳಂಬವನ್ನು ತೆಗೆದುಹಾಕುತ್ತೇವೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ. ನಾವು ಪುನರಾವರ್ತಿಸುತ್ತೇವೆ, ಆದರೆ ಮತ್ತೊಮ್ಮೆ ನಾವು ಮೂಲ ಕೋಡ್ ಅನ್ನು ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಸ್ಪರ್ಶಿಸದೆಯೇ ಇದೆಲ್ಲವನ್ನೂ ಮಾಡಿದ್ದೇವೆ.

ಹಿಂದೆ ಸರಿಯಬೇಡಿ ಮತ್ತು ಬಿಟ್ಟುಕೊಡಬೇಡಿ

ಅವ್ಯವಸ್ಥೆಯ ಎಂಜಿನಿಯರಿಂಗ್‌ಗಾಗಿ ಇಸ್ಟಿಯೊದ ಮತ್ತೊಂದು ಉಪಯುಕ್ತ ವೈಶಿಷ್ಟ್ಯವೆಂದರೆ ಸೇವೆಗೆ ನಿರ್ದಿಷ್ಟ ಸಂಖ್ಯೆಯ ಬಾರಿ ಪುನರಾವರ್ತಿತ ಕರೆಗಳು. ಮೊದಲ ವಿನಂತಿಯು 503 ದೋಷದೊಂದಿಗೆ ಕೊನೆಗೊಂಡಾಗ ಪ್ರಯತ್ನಿಸುವುದನ್ನು ಮುಂದುವರಿಸುವುದು ಇಲ್ಲಿರುವ ಅಂಶವಾಗಿದೆ - ತದನಂತರ N-ಹನ್ನೊಂದನೇ ಬಾರಿ ನಾವು ಅದೃಷ್ಟಶಾಲಿಯಾಗಬಹುದು. ಬಹುಶಃ ಒಂದು ಕಾರಣಕ್ಕಾಗಿ ಅಥವಾ ಇನ್ನೊಂದು ಕಾರಣಕ್ಕಾಗಿ ಸೇವೆಯು ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ ಕಡಿಮೆಯಾಗಿದೆ. ಹೌದು, ಈ ಕಾರಣವನ್ನು ಅಗೆದು ತೊಡೆದುಹಾಕಬೇಕು. ಆದರೆ ಅದು ನಂತರ ಬರುತ್ತದೆ, ಆದರೆ ಇದೀಗ ನಾವು ಸಿಸ್ಟಮ್ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ.

ಆದ್ದರಿಂದ, ಸೇವೆಯು ಕಾಲಕಾಲಕ್ಕೆ 503 ದೋಷವನ್ನು ಎಸೆಯಲು ನಾವು ಬಯಸುತ್ತೇವೆ ಮತ್ತು ನಂತರ ಇಸ್ಟಿಯೊ ಅದನ್ನು ಮತ್ತೆ ಸಂಪರ್ಕಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಮತ್ತು ಇಲ್ಲಿ ನಮಗೆ ಕೋಡ್ ಅನ್ನು ಸ್ಪರ್ಶಿಸದೆಯೇ 503 ದೋಷವನ್ನು ಸೃಷ್ಟಿಸಲು ಒಂದು ಮಾರ್ಗ ಬೇಕು...

ನಿಲ್ಲಿಸಿ, ನಿರೀಕ್ಷಿಸಿ! ನಾವು ಅದನ್ನು ಮಾಡಿದ್ದೇವೆ.

ಈ ಫೈಲ್ ಇದನ್ನು ಮಾಡುತ್ತದೆ ಆದ್ದರಿಂದ ಶಿಫಾರಸು-v2 ಸೇವೆಯು ಅರ್ಧ ಸಮಯ 503 ದೋಷವನ್ನು ನೀಡುತ್ತದೆ:

ನಿಸ್ಸಂಶಯವಾಗಿ, ಕೆಲವು ವಿನಂತಿಗಳು ವಿಫಲಗೊಳ್ಳುತ್ತವೆ:

ಈಗ ನಾವು ಇಸ್ಟಿಯೊ ಮರುಪ್ರಯತ್ನ ಕಾರ್ಯವನ್ನು ಬಳಸೋಣ:

ಈ ರೂಟಿಂಗ್ ನಿಯಮವು ಎರಡು-ಸೆಕೆಂಡ್ ಮಧ್ಯಂತರದಲ್ಲಿ ಮೂರು ಬಾರಿ ಪುನರಾವರ್ತನೆಯಾಗುತ್ತದೆ ಮತ್ತು 503 ದೋಷಗಳನ್ನು ಕಡಿಮೆ ಮಾಡಬೇಕು (ಮತ್ತು ಆದರ್ಶಪ್ರಾಯವಾಗಿ ರೇಡಾರ್‌ನಿಂದ ತೆಗೆದುಹಾಕಬೇಕು):

ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಹೇಳುವುದಾದರೆ: ನಾವು ಇದನ್ನು ಮಾಡಿದ್ದೇವೆ ಆದ್ದರಿಂದ Istio, ಮೊದಲನೆಯದಾಗಿ, ಅರ್ಧದಷ್ಟು ವಿನಂತಿಗಳಿಗೆ 503 ದೋಷವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಮತ್ತು ಎರಡನೆಯದಾಗಿ, 503 ದೋಷ ಸಂಭವಿಸಿದಾಗ ಅದೇ ಇಸ್ಟಿಯೊ ಸೇವೆಯನ್ನು ಮರು-ಸಂಪರ್ಕಿಸಲು ಮೂರು ಪ್ರಯತ್ನಗಳನ್ನು ಮಾಡುತ್ತದೆ. ಪರಿಣಾಮವಾಗಿ, ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಹೀಗಾಗಿ, ಮರುಪ್ರಯತ್ನ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಬಳಸಿಕೊಂಡು, ನಾವು ಬಿಟ್ಟುಕೊಡುವುದಿಲ್ಲ ಮತ್ತು ಬಿಟ್ಟುಕೊಡುವುದಿಲ್ಲ ಎಂಬ ನಮ್ಮ ಭರವಸೆಯನ್ನು ನಾವು ಪೂರೈಸಿದ್ದೇವೆ.

ಮತ್ತು ಹೌದು, ನಾವು ಕೋಡ್ ಅನ್ನು ಮುಟ್ಟದೆಯೇ ಅದನ್ನು ಮತ್ತೆ ಮಾಡಿದ್ದೇವೆ. ನಮಗೆ ಬೇಕಾಗಿರುವುದು ಎರಡು ಇಸ್ಟಿಯೊ ರೂಟಿಂಗ್ ನಿಯಮಗಳು:

ಬಳಕೆದಾರರನ್ನು ಹೇಗೆ ನಿರಾಸೆಗೊಳಿಸಬಾರದು ಅಥವಾ ಏಳು ಒಂದನ್ನು ನಿರೀಕ್ಷಿಸುವುದಿಲ್ಲ

ಈಗ ನಾವು ಪರಿಸ್ಥಿತಿಯನ್ನು ಒಳಗೆ ತಿರುಗಿಸೋಣ ಮತ್ತು ನೀವು ಮಾಡಬೇಕಾದ ಏಕೈಕ ವಿಷಯವೆಂದರೆ ಹಿಮ್ಮೆಟ್ಟುವಿಕೆ ಅಥವಾ ನಿಗದಿತ ಸಮಯದವರೆಗೆ ಬಿಟ್ಟುಕೊಡದಿರುವ ಸನ್ನಿವೇಶವನ್ನು ಪರಿಗಣಿಸೋಣ. ತದನಂತರ ನೀವು ವಿನಂತಿಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಪ್ರಯತ್ನಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಬೇಕು, ಆದ್ದರಿಂದ ಎಲ್ಲರೂ ಒಂದು ನಿಧಾನ ಸೇವೆಗಾಗಿ ಕಾಯುವಂತೆ ಒತ್ತಾಯಿಸಬಾರದು. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ನಾವು ಕಳೆದುಹೋದ ಸ್ಥಾನವನ್ನು ರಕ್ಷಿಸುವುದಿಲ್ಲ, ಆದರೆ ಸೈಟ್ ಬಳಕೆದಾರರನ್ನು ನಿರಾಸೆಗೊಳಿಸದಂತೆ ಮತ್ತು ಅಜ್ಞಾನದಲ್ಲಿ ನರಳುವಂತೆ ಒತ್ತಾಯಿಸದಂತೆ ಮೀಸಲು ರೇಖೆಗೆ ಹಿಮ್ಮೆಟ್ಟುತ್ತೇವೆ.

ಇಸ್ಟಿಯೊದಲ್ಲಿ, ನೀವು ಪ್ರಶ್ನೆ ಎಕ್ಸಿಕ್ಯೂಶನ್ ಟೈಮ್‌ಔಟ್ ಅನ್ನು ಹೊಂದಿಸಬಹುದು. ಸೇವೆಯು ಈ ಅವಧಿ ಮೀರಿದರೆ, 504 ದೋಷವನ್ನು (ಗೇಟ್‌ವೇ ಟೈಮ್‌ಔಟ್) ಹಿಂತಿರುಗಿಸಲಾಗುತ್ತದೆ - ಮತ್ತೆ, ಇದನ್ನು ಇಸ್ಟಿಯೊ ಕಾನ್ಫಿಗರೇಶನ್ ಮೂಲಕ ಮಾಡಲಾಗುತ್ತದೆ. ಆದರೆ ಸೇವೆಯ ನಿಧಾನ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಅನುಕರಿಸಲು ನಾವು ಸೇವಾ ಮೂಲ ಕೋಡ್‌ಗೆ ಸ್ಲೀಪ್ ಕಮಾಂಡ್ ಅನ್ನು ಸೇರಿಸಬೇಕಾಗುತ್ತದೆ (ಮತ್ತು ನಂತರ, ಸಹಜವಾಗಿ, ಮರುನಿರ್ಮಾಣ ಮತ್ತು ಮರುಹಂಚಿಕೆಯನ್ನು ನಿರ್ವಹಿಸಿ). ಅಯ್ಯೋ, ಇದು ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ.

ಆದ್ದರಿಂದ, ನಾವು ಶಿಫಾರಸು v2 ಸೇವಾ ಕೋಡ್‌ಗೆ ಮೂರು-ಸೆಕೆಂಡ್ ನಿದ್ರೆಯನ್ನು ಸೇರಿಸಿದ್ದೇವೆ, ಅನುಗುಣವಾದ ಚಿತ್ರವನ್ನು ಮರುನಿರ್ಮಿಸಿದ್ದೇವೆ ಮತ್ತು ಕಂಟೇನರ್ ಅನ್ನು ಮರುಹೊಂದಿಸಿದ್ದೇವೆ ಮತ್ತು ಈಗ ನಾವು ಈ ಕೆಳಗಿನ ಇಸ್ಟಿಯೊ ರೂಟಿಂಗ್ ನಿಯಮವನ್ನು ಬಳಸಿಕೊಂಡು ಸಮಯ ಮೀರುವಿಕೆಯನ್ನು ಸೇರಿಸುತ್ತೇವೆ:

ಮೇಲಿನ ಸ್ಕ್ರೀನ್‌ಶಾಟ್‌ನಲ್ಲಿ ನಾವು ಒಂದು ಸೆಕೆಂಡಿನಲ್ಲಿ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ವೀಕರಿಸದಿದ್ದರೆ, ಅಂದರೆ 504 ದೋಷ ಸಂಭವಿಸುವ ಮೊದಲು ಶಿಫಾರಸು ಸೇವೆಯನ್ನು ಸಂಪರ್ಕಿಸುವ ಪ್ರಯತ್ನವನ್ನು ನಾವು ಕೈಬಿಡುತ್ತೇವೆ ಎಂದು ನೀವು ನೋಡಬಹುದು. ಈ ರೂಟಿಂಗ್ ನಿಯಮವನ್ನು ಅನ್ವಯಿಸಿದ ನಂತರ (ಮತ್ತು ಮೂರು-ಸೆಕೆಂಡ್ ನಿದ್ರೆಯನ್ನು ಸೇರಿಸುವುದು ಶಿಫಾರಸು ಸೇವಾ ಕೋಡ್‌ಗೆ :v2), ನಾವು ಇದನ್ನು ಪಡೆಯುತ್ತೇವೆ:

ನಾವು ಮತ್ತೆ ಪುನರಾವರ್ತಿಸುತ್ತೇವೆ, ಆದರೆ ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಮೂಲ ಕೋಡ್ ಅನ್ನು ಸ್ಪರ್ಶಿಸದೆಯೇ ಸಮಯ ಮೀರುವಿಕೆಯನ್ನು ಹೊಂದಿಸಬಹುದು. ಮತ್ತು ಇಲ್ಲಿ ಹೆಚ್ಚುವರಿ ಬೋನಸ್ ಏನೆಂದರೆ, ನೀವು ಈಗ ನಿಮ್ಮ ಕೋಡ್ ಅನ್ನು ಸಮಯ ಮೀರುವಿಕೆಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಲು ಮಾರ್ಪಡಿಸಬಹುದು ಮತ್ತು Istio ಬಳಸಿಕೊಂಡು ಈ ಮಾರ್ಪಾಡುಗಳನ್ನು ಸುಲಭವಾಗಿ ಪರೀಕ್ಷಿಸಬಹುದು.

ಮತ್ತು ಈಗ ಎಲ್ಲವೂ ಒಟ್ಟಿಗೆ

Istio ನೊಂದಿಗೆ ಸ್ವಲ್ಪ ಗೊಂದಲವನ್ನು ಚುಚ್ಚುವುದು ನಿಮ್ಮ ಕೋಡ್ ಮತ್ತು ಒಟ್ಟಾರೆಯಾಗಿ ನಿಮ್ಮ ಸಿಸ್ಟಮ್ನ ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಪರೀಕ್ಷಿಸಲು ಉತ್ತಮ ಮಾರ್ಗವಾಗಿದೆ. ಫಾಲ್‌ಬ್ಯಾಕ್, ಬಲ್ಕ್‌ಹೆಡ್ ಮತ್ತು ಸರ್ಕ್ಯೂಟ್ ಬ್ರೇಕರ್ ಮಾದರಿಗಳು, ಕೃತಕ ವೈಫಲ್ಯಗಳು ಮತ್ತು ವಿಳಂಬಗಳನ್ನು ರಚಿಸುವ ಕಾರ್ಯವಿಧಾನಗಳು, ಹಾಗೆಯೇ ಮರುಪ್ರಯತ್ನ ಕರೆಗಳು ಮತ್ತು ಸಮಯ ಮೀರುವಿಕೆಗಳು ದೋಷ-ಸಹಿಷ್ಣು ಕ್ಲೌಡ್ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ರಚಿಸುವಾಗ ತುಂಬಾ ಉಪಯುಕ್ತವಾಗಿರುತ್ತದೆ. Kubernetes ಮತ್ತು Red Hat OpenShift ನೊಂದಿಗೆ ಸಂಯೋಜಿಸಲ್ಪಟ್ಟ ಈ ಪರಿಕರಗಳು ಭವಿಷ್ಯವನ್ನು ಆತ್ಮವಿಶ್ವಾಸದಿಂದ ಎದುರಿಸಲು ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತವೆ.

ಮೂಲ: www.habr.com