ಕೊನೆಯಲ್ಲಿ ನಾವು ಇಸ್ಟಿಯೊ ಸರ್ವಿಸ್ ಮೆಶ್ನ ಮೂಲ ಘಟಕಗಳನ್ನು ನೋಡಿದ್ದೇವೆ, ಸಿಸ್ಟಮ್ನೊಂದಿಗೆ ಪರಿಚಯ ಮಾಡಿಕೊಂಡಿದ್ದೇವೆ ಮತ್ತು ಇಸ್ಟಿಯೊ ಜೊತೆ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುವಾಗ ಸಾಮಾನ್ಯವಾಗಿ ಉದ್ಭವಿಸುವ ಮುಖ್ಯ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸಿದ್ದೇವೆ. ಈ ಭಾಗದಲ್ಲಿ, ನೆಟ್ವರ್ಕ್ ಮೂಲಕ ಟ್ರೇಸಿಂಗ್ ಮಾಹಿತಿಯ ಸಂಗ್ರಹವನ್ನು ಹೇಗೆ ಸಂಘಟಿಸುವುದು ಎಂದು ನಾವು ನೋಡೋಣ.
ಅನೇಕ ಡೆವಲಪರ್ಗಳು ಮತ್ತು ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು ಸರ್ವಿಸ್ ಮೆಶ್ ಎಂಬ ಪದಗಳನ್ನು ಕೇಳಿದಾಗ ಮೊದಲು ಮನಸ್ಸಿಗೆ ಬರುವುದು ಟ್ರೇಸಿಂಗ್. ವಾಸ್ತವವಾಗಿ, ನಾವು ಪ್ರತಿ ನೆಟ್ವರ್ಕ್ ನೋಡ್ಗೆ ವಿಶೇಷ ಪ್ರಾಕ್ಸಿ ಸರ್ವರ್ ಅನ್ನು ಸೇರಿಸುತ್ತೇವೆ, ಅದರ ಮೂಲಕ ಎಲ್ಲಾ TCP ಟ್ರಾಫಿಕ್ ಹಾದುಹೋಗುತ್ತದೆ. ಈಗ ನೀವು ನೆಟ್ವರ್ಕ್ನಲ್ಲಿರುವ ಎಲ್ಲಾ ನೆಟ್ವರ್ಕ್ ಸಂವಹನಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಸುಲಭವಾಗಿ ಕಳುಹಿಸಬಹುದು ಎಂದು ತೋರುತ್ತದೆ. ದುರದೃಷ್ಟವಶಾತ್, ವಾಸ್ತವದಲ್ಲಿ, ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕಾದ ಹಲವು ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳಿವೆ. ಅವುಗಳನ್ನು ನೋಡೋಣ.
ಮೊದಲ ತಪ್ಪು ಕಲ್ಪನೆ: ಪಾದಯಾತ್ರೆಗಳ ಕುರಿತು ನಾವು ಆನ್ಲೈನ್ನಲ್ಲಿ ಉಚಿತವಾಗಿ ಡೇಟಾವನ್ನು ಪಡೆಯಬಹುದು.
ವಾಸ್ತವವಾಗಿ, ತುಲನಾತ್ಮಕವಾಗಿ ಉಚಿತವಾಗಿ ನಾವು ನಮ್ಮ ವ್ಯವಸ್ಥೆಯ ನೋಡ್ಗಳನ್ನು ಬಾಣಗಳಿಂದ ಮತ್ತು ಸೇವೆಗಳ ನಡುವೆ ಹಾದುಹೋಗುವ ಡೇಟಾದ ದರದಿಂದ ಮಾತ್ರ ಸಂಪರ್ಕಿಸಬಹುದು (ವಾಸ್ತವವಾಗಿ, ಪ್ರತಿ ಯೂನಿಟ್ ಸಮಯಕ್ಕೆ ಬೈಟ್ಗಳ ಸಂಖ್ಯೆ ಮಾತ್ರ). ಆದಾಗ್ಯೂ, ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ, ನಮ್ಮ ಸೇವೆಗಳು HTTP, gRPC, Redis, ಮತ್ತು ಮುಂತಾದ ಕೆಲವು ಅಪ್ಲಿಕೇಶನ್-ಮಟ್ಟದ ಪ್ರೋಟೋಕಾಲ್ ಮೂಲಕ ಸಂವಹನ ನಡೆಸುತ್ತವೆ. ಮತ್ತು, ಸಹಜವಾಗಿ, ಈ ಪ್ರೋಟೋಕಾಲ್ಗಳಿಗೆ ನಿರ್ದಿಷ್ಟವಾಗಿ ಟ್ರೇಸಿಂಗ್ ಮಾಹಿತಿಯನ್ನು ನೋಡಲು ನಾವು ಬಯಸುತ್ತೇವೆ, ಡೇಟಾದ ದರವಲ್ಲ, ವಿನಂತಿಗಳ ದರವನ್ನು ನಾವು ನೋಡಲು ಬಯಸುತ್ತೇವೆ. ನಮ್ಮ ಪ್ರೋಟೋಕಾಲ್ಗಾಗಿ ವಿನಂತಿಗಳ ವಿಳಂಬವನ್ನು ನಾವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಬಯಸುತ್ತೇವೆ. ಅಂತಿಮವಾಗಿ, ನಮ್ಮ ವ್ಯವಸ್ಥೆಯನ್ನು ಪ್ರವೇಶಿಸುವುದರಿಂದ ಬಳಕೆದಾರರಿಂದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ವೀಕರಿಸುವವರೆಗೆ ವಿನಂತಿಯು ತೆಗೆದುಕೊಳ್ಳುವ ಪೂರ್ಣ ಮಾರ್ಗವನ್ನು ನಾವು ನೋಡಲು ಬಯಸುತ್ತೇವೆ. ಈ ಕಾರ್ಯವನ್ನು ಪರಿಹರಿಸುವುದು ಅಷ್ಟು ಸುಲಭವಲ್ಲ.
ಮೊದಲಿಗೆ, ಇಸ್ಟಿಯೊದಲ್ಲಿ ವಾಸ್ತುಶಿಲ್ಪದ ದೃಷ್ಟಿಕೋನದಿಂದ ಟ್ರೇಸಿಂಗ್ ಸ್ಪ್ಯಾನ್ಗಳನ್ನು ಕಳುಹಿಸುವುದು ಹೇಗೆ ಕಾಣುತ್ತದೆ ಎಂದು ನೋಡೋಣ. ಮೊದಲ ಭಾಗದಿಂದ ನಮಗೆ ನೆನಪಿರುವಂತೆ, ಇಸ್ಟಿಯೊ ಟೆಲಿಮೆಟ್ರಿಯನ್ನು ಸಂಗ್ರಹಿಸಲು ಪ್ರತ್ಯೇಕ ಘಟಕವನ್ನು ಹೊಂದಿದೆ, ಇದನ್ನು ಮಿಕ್ಸರ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಪ್ರಸ್ತುತ ಆವೃತ್ತಿ 1.0.* ರಲ್ಲಿ, ಕಳುಹಿಸುವಿಕೆಯನ್ನು ಪ್ರಾಕ್ಸಿ ಸರ್ವರ್ಗಳಿಂದ ನೇರವಾಗಿ ಮಾಡಲಾಗುತ್ತದೆ, ಅಂದರೆ, ಎನ್ವಾಯ್ ಪ್ರಾಕ್ಸಿಯಿಂದ. ಎನ್ವಾಯ್ ಪ್ರಾಕ್ಸಿ ಜಿಪ್ಕಿನ್ ಪ್ರೋಟೋಕಾಲ್ ಮೂಲಕ ಟ್ರೇಸಿಂಗ್ ಸ್ಪ್ಯಾನ್ಗಳನ್ನು ಬಾಕ್ಸ್ನ ಹೊರಗೆ ಕಳುಹಿಸುವುದನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ. ಇತರ ಪ್ರೋಟೋಕಾಲ್ಗಳನ್ನು ಸಂಪರ್ಕಿಸಬಹುದು, ಆದರೆ ಪ್ಲಗಿನ್ ಮೂಲಕ ಮಾತ್ರ. ಇಸ್ಟಿಯೊದೊಂದಿಗೆ, ನಾವು ತಕ್ಷಣವೇ ಬಿಲ್ಟ್ ಮತ್ತು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾದ ಎನ್ವಾಯ್ ಪ್ರಾಕ್ಸಿಯನ್ನು ಪಡೆಯುತ್ತೇವೆ, ಅದು ಜಿಪ್ಕಿನ್ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಮಾತ್ರ ಬೆಂಬಲಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ನಾವು ಜೇಗರ್ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬಳಸಲು ಮತ್ತು ಯುಡಿಪಿ ಮೂಲಕ ಟ್ರೇಸಿಂಗ್ ಸ್ಪ್ಯಾನ್ಗಳನ್ನು ಕಳುಹಿಸಲು ಬಯಸಿದರೆ, ನಾವು ನಮ್ಮದೇ ಆದ ಇಸ್ಟಿಯೊ-ಪ್ರಾಕ್ಸಿ ಚಿತ್ರವನ್ನು ನಿರ್ಮಿಸಬೇಕಾಗುತ್ತದೆ. ಇಸ್ಟಿಯೊ-ಪ್ರಾಕ್ಸಿಗಾಗಿ ಕಸ್ಟಮ್ ಪ್ಲಗಿನ್ಗಳಿಗೆ ಬೆಂಬಲವಿದೆ, ಆದರೆ ಅದು ಇನ್ನೂ ಆಲ್ಫಾ ಆವೃತ್ತಿಯಲ್ಲಿದೆ. ಆದ್ದರಿಂದ, ನಾವು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಕಸ್ಟಮ್ ಸೆಟ್ಟಿಂಗ್ಗಳಿಲ್ಲದೆ ಮಾಡಲು ಬಯಸಿದರೆ, ಟ್ರೇಸಿಂಗ್ ಸ್ಪ್ಯಾನ್ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಮತ್ತು ಸ್ವೀಕರಿಸಲು ಬಳಸುವ ತಂತ್ರಜ್ಞಾನಗಳ ವ್ಯಾಪ್ತಿಯು ಕಡಿಮೆಯಾಗುತ್ತದೆ. ಮುಖ್ಯ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ, ವಾಸ್ತವವಾಗಿ, ನೀವು ಈಗ ಜಿಪ್ಕಿನ್ ಅನ್ನು ಅಥವಾ ಜೇಗರ್ ಅನ್ನು ಬಳಸಬಹುದು, ಆದರೆ ಎಲ್ಲವನ್ನೂ ಜಿಪ್ಕಿನ್-ಹೊಂದಾಣಿಕೆಯ ಪ್ರೋಟೋಕಾಲ್ ಮೂಲಕ ಅಲ್ಲಿಗೆ ಕಳುಹಿಸಬಹುದು (ಇದು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ). ಜಿಪ್ಕಿನ್ ಪ್ರೋಟೋಕಾಲ್ ಸ್ವತಃ ಎಲ್ಲಾ ಟ್ರೇಸಿಂಗ್ ಮಾಹಿತಿಯನ್ನು HTTP ಪ್ರೋಟೋಕಾಲ್ ಮೂಲಕ ಸಂಗ್ರಾಹಕರಿಗೆ ಕಳುಹಿಸುವುದನ್ನು ಊಹಿಸುತ್ತದೆ, ಇದು ಸಾಕಷ್ಟು ದುಬಾರಿಯಾಗಿದೆ.
ನಾನು ಈಗಾಗಲೇ ಹೇಳಿದಂತೆ, ನಾವು ಅಪ್ಲಿಕೇಶನ್-ಮಟ್ಟದ ಪ್ರೋಟೋಕಾಲ್ಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಬಯಸುತ್ತೇವೆ. ಇದರರ್ಥ ಪ್ರತಿ ಸೇವೆಯ ಪಕ್ಕದಲ್ಲಿರುವ ಪ್ರಾಕ್ಸಿ ಸರ್ವರ್ಗಳು ಪ್ರಸ್ತುತ ಯಾವ ರೀತಿಯ ಸಂವಹನ ನಡೆಯುತ್ತಿದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ಇಸ್ಟಿಯೊ ಎಲ್ಲಾ ಪೋರ್ಟ್ಗಳಿಗೆ ಸರಳ TCP ಪ್ರಕಾರವನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತದೆ, ಅಂದರೆ ಯಾವುದೇ ಟ್ರೇಸ್ಗಳನ್ನು ಕಳುಹಿಸಲಾಗುವುದಿಲ್ಲ. ಟ್ರೇಸ್ಗಳನ್ನು ಕಳುಹಿಸಲು, ನೀವು ಮೊದಲು, ಮುಖ್ಯ ಮೆಶ್ ಕಾನ್ಫಿಗರೇಶನ್ನಲ್ಲಿ ಈ ಆಯ್ಕೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಬೇಕು ಮತ್ತು, ಮುಖ್ಯವಾಗಿ, ಸೇವೆಯಲ್ಲಿ ಬಳಸಲಾಗುವ ಪ್ರೋಟೋಕಾಲ್ಗೆ ಅನುಗುಣವಾಗಿ ಕುಬರ್ನೆಟ್ಸ್ ಸೇವಾ ಘಟಕಗಳಲ್ಲಿನ ಎಲ್ಲಾ ಪೋರ್ಟ್ಗಳನ್ನು ಹೆಸರಿಸಬೇಕು. ಅಂದರೆ, ಉದಾಹರಣೆಗೆ, ಈ ರೀತಿ:
apiVersion: v1
kind: Service
metadata:
name: nginx
spec:
ports:
- port: 80
targetPort: 80
name: http
selector:
app: nginxನೀವು http-magic ನಂತಹ ಸಂಯುಕ್ತ ಹೆಸರುಗಳನ್ನು ಸಹ ಬಳಸಬಹುದು (Istio http ಅನ್ನು ನೋಡುತ್ತದೆ ಮತ್ತು ಆ ಪೋರ್ಟ್ ಅನ್ನು http ಎಂಡ್ಪಾಯಿಂಟ್ ಆಗಿ ಗುರುತಿಸುತ್ತದೆ). ಸ್ವರೂಪ: proto-extra.
ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ನಿರ್ಧರಿಸಲು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಕಾನ್ಫಿಗರೇಶನ್ಗಳನ್ನು ಪ್ಯಾಚ್ ಮಾಡದಿರಲು, ನೀವು ಕೊಳಕು ಪರಿಹಾರವನ್ನು ಬಳಸಬಹುದು: ಪೈಲಟ್ ಘಟಕವು ಕೇವಲ ಇರುವ ಕ್ಷಣದಲ್ಲಿ ಅದನ್ನು ಪ್ಯಾಚ್ ಮಾಡಿ. ಕೊನೆಯಲ್ಲಿ, ಸಹಜವಾಗಿ, ಈ ತರ್ಕವನ್ನು ಪ್ರಮಾಣಿತ ಒಂದಕ್ಕೆ ಬದಲಾಯಿಸುವುದು ಮತ್ತು ಎಲ್ಲಾ ಪೋರ್ಟ್ಗಳಿಗೆ ಹೆಸರಿಸುವ ಸಂಪ್ರದಾಯಕ್ಕೆ ಬದಲಾಯಿಸುವುದು ಅಗತ್ಯವಾಗಿರುತ್ತದೆ.
ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಸರಿಯಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆಯೇ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ನೀವು ರಾಯಭಾರಿ ಪ್ರಾಕ್ಸಿ ಹೊಂದಿರುವ ಯಾವುದೇ ಸೈಡ್ಕಾರ್ ಕಂಟೇನರ್ಗಳಿಗೆ ಹೋಗಿ /config_dump ಸ್ಥಳದೊಂದಿಗೆ ರಾಯಭಾರಿ ಇಂಟರ್ಫೇಸ್ನ ನಿರ್ವಾಹಕ ಪೋರ್ಟ್ಗೆ ವಿನಂತಿಯನ್ನು ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಪರಿಣಾಮವಾಗಿ ಸಂರಚನೆಯಲ್ಲಿ, ನೀವು ಬಯಸಿದ ಸೇವೆಗಾಗಿ ಕಾರ್ಯಾಚರಣೆ ಕ್ಷೇತ್ರವನ್ನು ನೋಡಬೇಕು. ವಿನಂತಿಯನ್ನು ಎಲ್ಲಿ ಮಾಡಲಾಗಿದೆ ಎಂಬುದರ ಗುರುತಿಸುವಿಕೆಯಾಗಿ ಇದನ್ನು ಇಸ್ಟಿಯೊದಲ್ಲಿ ಬಳಸಲಾಗುತ್ತದೆ. ಇಸ್ಟಿಯೊದಲ್ಲಿ ಈ ಪ್ಯಾರಾಮೀಟರ್ನ ಮೌಲ್ಯವನ್ನು ಕಸ್ಟಮೈಸ್ ಮಾಡಲು (ನಂತರ ನಾವು ಅದನ್ನು ನಮ್ಮ ಟ್ರೇಸಿಂಗ್ ಸಿಸ್ಟಮ್ನಲ್ಲಿ ನೋಡುತ್ತೇವೆ), ಸೈಡ್ಕಾರ್ ಕಂಟೇನರ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುವ ಹಂತದಲ್ಲಿ ನೀವು ಸರ್ವಿಸ್ಕ್ಲಸ್ಟರ್ ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಬೇಕಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಕುಬರ್ನೆಟ್ಗಳ ಕೆಳಮುಖ API ನಿಂದ ಪಡೆದ ವೇರಿಯೇಬಲ್ಗಳಿಂದ ಇದನ್ನು ಈ ರೀತಿ ಲೆಕ್ಕಹಾಕಬಹುದು:
--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')
ರಾಯಭಾರಿಯಲ್ಲಿ ಟ್ರೇಸಿಂಗ್ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಒಂದು ಉತ್ತಮ ಉದಾಹರಣೆ .
ಟ್ರೇಸಿಂಗ್ ಸ್ಪ್ಯಾನ್ಗಳನ್ನು ಕಳುಹಿಸಲು ಎಂಡ್ಪಾಯಿಂಟ್ ಅನ್ನು ಸಹ ರಾಯಭಾರಿ ಪ್ರಾಕ್ಸಿ ಲಾಂಚ್ ಫ್ಲ್ಯಾಗ್ಗಳಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಬೇಕು, ಉದಾಹರಣೆಗೆ: --zipkinAddress tracing-collector.tracing:9411
ಎರಡನೇ ತಪ್ಪು ಕಲ್ಪನೆ: ವ್ಯವಸ್ಥೆಯ ಮೂಲಕ ಹಾದುಹೋಗುವ ವಿನಂತಿಗಳ ಸಂಪೂರ್ಣ ಕುರುಹುಗಳನ್ನು ನಾವು ಅಗ್ಗವಾಗಿ ಪೆಟ್ಟಿಗೆಯ ಹೊರಗೆ ಪಡೆಯಬಹುದು.
ದುರದೃಷ್ಟವಶಾತ್, ಇದು ಹಾಗಲ್ಲ. ಅನುಷ್ಠಾನದ ಸಂಕೀರ್ಣತೆಯು ನೀವು ಈಗಾಗಲೇ ಸೇವೆಗಳ ಸಂವಹನವನ್ನು ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸಿದ್ದೀರಿ ಎಂಬುದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ. ಅದು ಏಕೆ?
ವಿಷಯವೆಂದರೆ istio-proxy ಸೇವೆಗೆ ಒಳಬರುವ ವಿನಂತಿಗಳ ಪತ್ರವ್ಯವಹಾರವನ್ನು ಅದೇ ಸೇವೆಯಿಂದ ಹೊರಹೋಗುವ ವಿನಂತಿಗಳೊಂದಿಗೆ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗಬೇಕಾದರೆ, ಎಲ್ಲಾ ದಟ್ಟಣೆಯನ್ನು ಸರಳವಾಗಿ ಪ್ರತಿಬಂಧಿಸುವುದು ಸಾಕಾಗುವುದಿಲ್ಲ. ಕೆಲವು ರೀತಿಯ ಸಂಪರ್ಕ ಗುರುತಿಸುವಿಕೆಯನ್ನು ಹೊಂದಿರುವುದು ಅವಶ್ಯಕ. HTTP ರಾಯಭಾರಿ ಪ್ರಾಕ್ಸಿ ವಿಶೇಷ ಹೆಡರ್ಗಳನ್ನು ಬಳಸುತ್ತದೆ, ಅದರ ಮೂಲಕ ಸೇವೆಗೆ ಯಾವ ವಿನಂತಿಯು ಇತರ ಸೇವೆಗಳಿಗೆ ನಿರ್ದಿಷ್ಟ ವಿನಂತಿಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ರಾಯಭಾರಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ. ಅಂತಹ ಹೆಡರ್ಗಳ ಪಟ್ಟಿ:
- x- ವಿನಂತಿ-ಐಡಿ,
- x-b3-ಟ್ರೇಸಿಡ್,
- x-b3-ಸ್ಪ್ಯಾನಿಡ್,
- x-b3-ಪೇರೆಂಟ್ಸ್ಪ್ಯಾನಿಡ್,
- x-b3- ಮಾದರಿ,
- x-b3-ಧ್ವಜಗಳು,
- x-ot-span-ಸಂದರ್ಭ.
ನೀವು ಒಂದೇ ಬಿಂದುವನ್ನು ಹೊಂದಿದ್ದರೆ, ಉದಾಹರಣೆಗೆ, ಒಂದು ಮೂಲ ಕ್ಲೈಂಟ್, ಅಲ್ಲಿ ನೀವು ಅಂತಹ ತರ್ಕವನ್ನು ಸೇರಿಸಬಹುದು, ಆಗ ಎಲ್ಲವೂ ಸರಿಯಾಗಿದೆ, ಎಲ್ಲಾ ಕ್ಲೈಂಟ್ಗಳಲ್ಲಿ ಈ ಲೈಬ್ರರಿಯನ್ನು ನವೀಕರಿಸಲು ನೀವು ಕಾಯಬೇಕಾಗಿದೆ. ಆದರೆ ನೀವು ಬಹಳ ವೈವಿಧ್ಯಮಯ ವ್ಯವಸ್ಥೆಯನ್ನು ಹೊಂದಿದ್ದರೆ ಮತ್ತು ನೆಟ್ವರ್ಕ್ ಮೂಲಕ ಸೇವೆಗಳಿಂದ ಸೇವೆಗಳಿಗೆ ಸಾಗುವಲ್ಲಿ ಯಾವುದೇ ಏಕೀಕರಣವಿಲ್ಲದಿದ್ದರೆ, ಇದು ಹೆಚ್ಚಾಗಿ ದೊಡ್ಡ ಸಮಸ್ಯೆಯಾಗಿರುತ್ತದೆ. ಅಂತಹ ತರ್ಕವನ್ನು ಸೇರಿಸದೆಯೇ, ಎಲ್ಲಾ ಟ್ರೇಸಿಂಗ್ ಮಾಹಿತಿಯು ಕೇವಲ "ಏಕ-ಹಂತ"ವಾಗಿರುತ್ತದೆ. ಅಂದರೆ, ನಾವು ಎಲ್ಲಾ ಅಂತರ ಸೇವಾ ಸಂವಹನಗಳನ್ನು ಪಡೆಯುತ್ತೇವೆ, ಆದರೆ ಅವುಗಳನ್ನು ನೆಟ್ವರ್ಕ್ ಮೂಲಕ ಹಾದುಹೋಗುವ ಒಂದೇ ಸರಪಳಿಗಳಲ್ಲಿ ಅಂಟಿಸಲಾಗುವುದಿಲ್ಲ.
ತೀರ್ಮಾನಕ್ಕೆ
ನೆಟ್ವರ್ಕ್ ಮೂಲಕ ಟ್ರೇಸಿಂಗ್ ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಲು ಇಸ್ಟಿಯೊ ಅನುಕೂಲಕರ ಸಾಧನವನ್ನು ಒದಗಿಸುತ್ತದೆ, ಆದರೆ ಅನುಷ್ಠಾನಕ್ಕಾಗಿ ನೀವು ನಿಮ್ಮ ವ್ಯವಸ್ಥೆಯನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳಬೇಕು ಮತ್ತು ಇಸ್ಟಿಯೊ ಅನುಷ್ಠಾನದ ನಿಶ್ಚಿತಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ಪರಿಣಾಮವಾಗಿ, ಎರಡು ಪ್ರಮುಖ ಅಂಶಗಳನ್ನು ಪರಿಹರಿಸಬೇಕಾಗಿದೆ: ಅಪ್ಲಿಕೇಶನ್-ಮಟ್ಟದ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುವುದು (ಇದನ್ನು ರಾಯಭಾರಿ ಪ್ರಾಕ್ಸಿ ಬೆಂಬಲಿಸಬೇಕು) ಮತ್ತು ಸೇವೆಯಿಂದ ವಿನಂತಿಗಳಿಂದ ಸೇವೆಗೆ ವಿನಂತಿಗಳ ಸಂಬಂಧದ ಬಗ್ಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ಮಾಹಿತಿಯನ್ನು ಹೊಂದಿಸುವುದು (HTTP ಪ್ರೋಟೋಕಾಲ್ನ ಸಂದರ್ಭದಲ್ಲಿ ಹೆಡರ್ಗಳನ್ನು ಬಳಸಿ). ಈ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಿದಾಗ, ಅನೇಕ ವಿಭಿನ್ನ ಭಾಷೆಗಳು ಮತ್ತು ಚೌಕಟ್ಟುಗಳಲ್ಲಿ ಬರೆಯಲಾದ ಅತ್ಯಂತ ವೈವಿಧ್ಯಮಯ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿಯೂ ಸಹ ನೆಟ್ವರ್ಕ್ನಿಂದ ಮಾಹಿತಿಯನ್ನು ಪಾರದರ್ಶಕವಾಗಿ ಸಂಗ್ರಹಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ಪ್ರಬಲ ಸಾಧನವನ್ನು ನಾವು ಪಡೆಯುತ್ತೇವೆ.
ಸರ್ವಿಸ್ ಮೆಶ್ ಬಗ್ಗೆ ಮುಂದಿನ ಲೇಖನದಲ್ಲಿ, ನಾವು ಇಸ್ಟಿಯೊದ ದೊಡ್ಡ ಸಮಸ್ಯೆಗಳಲ್ಲಿ ಒಂದನ್ನು ನೋಡುತ್ತೇವೆ - ಪ್ರತಿ ಸೈಡ್ಕಾರ್ ಪ್ರಾಕ್ಸಿ ಕಂಟೇನರ್ನ ದೊಡ್ಡ ಮೆಮೊರಿ ಬಳಕೆ - ಮತ್ತು ಅದನ್ನು ಹೇಗೆ ಎದುರಿಸುವುದು ಎಂಬುದನ್ನು ಚರ್ಚಿಸುತ್ತೇವೆ.
ಮೂಲ: www.habr.com
