ನಾವು ಏಕಶಿಲೆಯ ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ ಮೈಕ್ರೋಸರ್ವೀಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗೆ ಚಲಿಸುವಾಗ, ನಾವು ಹೊಸ ಸವಾಲುಗಳನ್ನು ಎದುರಿಸುತ್ತೇವೆ.

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

ಅಂತಹ ಸಮಸ್ಯೆಗಳನ್ನು ನಿಭಾಯಿಸಲು ಸಹಾಯ ಮಾಡುವ ಸಾಧನಕ್ಕಾಗಿ ನಾನು ಬಹಳ ಸಮಯದಿಂದ ಹುಡುಕುತ್ತಿದ್ದೇನೆ (ನಾನು ಇದರ ಬಗ್ಗೆ ಹ್ಯಾಬ್ರೆಯಲ್ಲಿ ಬರೆದಿದ್ದೇನೆ: 1, 2), ಆದರೆ ಕೊನೆಯಲ್ಲಿ ನಾನು ನನ್ನ ಸ್ವಂತ ಮುಕ್ತ ಮೂಲ ಪರಿಹಾರವನ್ನು ಮಾಡಿದೆ. ಈ ಲೇಖನದಲ್ಲಿ ನಾನು ಸೇವೆಯ ಮೆಶ್ ವಿಧಾನದ ಪ್ರಯೋಜನಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇನೆ ಮತ್ತು ಅದರ ಅನುಷ್ಠಾನಕ್ಕಾಗಿ ಹೊಸ ಸಾಧನವನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತೇನೆ.

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

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

ಸೇವಾ ಜಾಲರಿ ವಿಧಾನ

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

ಪರಿಹಾರಗಳು

ಈ ವಿಧಾನದ ಹಲವಾರು ಅನುಷ್ಠಾನಗಳು ಈಗಾಗಲೇ ಇವೆ: ಇಸ್ಟಿಯೊ и ಲಿಂಕರ್ಡ್2. ಅವರು ಬಾಕ್ಸ್ ಹೊರಗೆ ಬಹಳಷ್ಟು ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಒದಗಿಸುತ್ತಾರೆ. ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ, ಸಂಪನ್ಮೂಲಗಳ ಮೇಲೆ ದೊಡ್ಡ ಓವರ್ಹೆಡ್ ಬರುತ್ತದೆ. ಇದಲ್ಲದೆ, ಅಂತಹ ವ್ಯವಸ್ಥೆಯು ಕಾರ್ಯನಿರ್ವಹಿಸುವ ದೊಡ್ಡ ಕ್ಲಸ್ಟರ್, ಹೊಸ ಮೂಲಸೌಕರ್ಯವನ್ನು ನಿರ್ವಹಿಸಲು ಹೆಚ್ಚಿನ ಸಂಪನ್ಮೂಲಗಳ ಅಗತ್ಯವಿರುತ್ತದೆ. Avito ನಲ್ಲಿ, ನಾವು ಸಾವಿರಾರು ಸೇವಾ ನಿದರ್ಶನಗಳನ್ನು ಹೊಂದಿರುವ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತೇವೆ (ಮತ್ತು ಅವುಗಳ ಸಂಖ್ಯೆಯು ವೇಗವಾಗಿ ಬೆಳೆಯುತ್ತಲೇ ಇದೆ). ಅದರ ಪ್ರಸ್ತುತ ಅನುಷ್ಠಾನದಲ್ಲಿ, ಇಸ್ಟಿಯೊ ಪ್ರತಿ ಸೇವಾ ನಿದರ್ಶನಕ್ಕೆ ~300Mb RAM ಅನ್ನು ಬಳಸುತ್ತದೆ. ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಸಾಧ್ಯತೆಗಳ ಕಾರಣದಿಂದಾಗಿ, ಪಾರದರ್ಶಕ ಸಮತೋಲನವು ಸೇವೆಗಳ ಒಟ್ಟಾರೆ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯವನ್ನು (10ms ವರೆಗೆ) ಪರಿಣಾಮ ಬೀರುತ್ತದೆ.

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

ಪರಿಣಾಮವಾಗಿ, ನಾವು ನಮ್ಮ ನಿರ್ಧಾರಕ್ಕೆ ಬಂದಿದ್ದೇವೆ:  ನೇತ್ರಮೇಶ್.

ನೇತ್ರಮೇಶ್

ನೇತ್ರಮೇಶ್ ವ್ಯವಸ್ಥೆಯಲ್ಲಿನ ಸೇವೆಗಳ ಸಂಖ್ಯೆಯನ್ನು ಲೆಕ್ಕಿಸದೆಯೇ, ಅನಂತವಾಗಿ ಅಳೆಯುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿರುವ ಹಗುರವಾದ ಸೇವಾ ಜಾಲರಿ ಪರಿಹಾರವಾಗಿದೆ.

ಹೊಸ ಪರಿಹಾರದ ಮುಖ್ಯ ಗುರಿಗಳು ಕಡಿಮೆ ಸಂಪನ್ಮೂಲ ಓವರ್ಹೆಡ್ ಮತ್ತು ಹೆಚ್ಚಿನ ಕಾರ್ಯಕ್ಷಮತೆ. ಮುಖ್ಯ ವೈಶಿಷ್ಟ್ಯಗಳಲ್ಲಿ, ನಮ್ಮ ಜೇಗರ್ ಸಿಸ್ಟಮ್‌ಗೆ ಟ್ರೇಸಿಂಗ್ ಸ್ಪ್ಯಾನ್‌ಗಳನ್ನು ಪಾರದರ್ಶಕವಾಗಿ ಕಳುಹಿಸಲು ನಾವು ತಕ್ಷಣ ಬಯಸುತ್ತೇವೆ.

ಇಂದು, ಹೆಚ್ಚಿನ ಕ್ಲೌಡ್ ಪರಿಹಾರಗಳನ್ನು ಗೋಲಾಂಗ್‌ನಲ್ಲಿ ಅಳವಡಿಸಲಾಗಿದೆ. ಮತ್ತು, ಸಹಜವಾಗಿ, ಇದಕ್ಕೆ ಕಾರಣಗಳಿವೆ. I/O ನೊಂದಿಗೆ ಅಸಮಕಾಲಿಕವಾಗಿ ಕೆಲಸ ಮಾಡುವ ನೆಟ್‌ವರ್ಕ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಗೋಲಾಂಗ್‌ನಲ್ಲಿ ಬರೆಯುವುದು ಮತ್ತು ಅಗತ್ಯವಿರುವಂತೆ ಕೋರ್‌ಗಳಾದ್ಯಂತ ಸ್ಕೇಲ್ ಮಾಡುವುದು ಅನುಕೂಲಕರ ಮತ್ತು ತುಂಬಾ ಸರಳವಾಗಿದೆ. ಮತ್ತು, ಬಹಳ ಮುಖ್ಯವಾದದ್ದು, ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಕಾರ್ಯಕ್ಷಮತೆ ಸಾಕು. ಅದಕ್ಕೇ ನಾವೂ ಗೋಲಾಂಗ್ ಆಯ್ಕೆ ಮಾಡಿಕೊಂಡೆವು.

ಉತ್ಪಾದಕತೆ

ಗರಿಷ್ಠ ಉತ್ಪಾದಕತೆಯನ್ನು ಸಾಧಿಸಲು ನಾವು ನಮ್ಮ ಪ್ರಯತ್ನಗಳನ್ನು ಕೇಂದ್ರೀಕರಿಸಿದ್ದೇವೆ. ಸೇವೆಯ ಪ್ರತಿ ನಿದರ್ಶನದ ಪಕ್ಕದಲ್ಲಿ ನಿಯೋಜಿಸಲಾದ ಪರಿಹಾರಕ್ಕಾಗಿ, RAM ಮತ್ತು CPU ಸಮಯದ ಒಂದು ಸಣ್ಣ ಬಳಕೆಯ ಅಗತ್ಯವಿದೆ. ಮತ್ತು, ಸಹಜವಾಗಿ, ಪ್ರತಿಕ್ರಿಯೆ ವಿಳಂಬವೂ ಚಿಕ್ಕದಾಗಿರಬೇಕು.

ನಾವು ಯಾವ ಫಲಿತಾಂಶಗಳನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ ಎಂದು ನೋಡೋಣ.

ರಾಮ್

Netramesh ಟ್ರಾಫಿಕ್ ಇಲ್ಲದೆ ~10Mb ಮತ್ತು ಪ್ರತಿ ನಿದರ್ಶನಕ್ಕೆ 50 RPS ವರೆಗಿನ ಲೋಡ್‌ನೊಂದಿಗೆ ಗರಿಷ್ಠ 10000Mb ಅನ್ನು ಬಳಸುತ್ತದೆ.

Istio ರಾಯಭಾರಿ ಪ್ರಾಕ್ಸಿ ಯಾವಾಗಲೂ ಸಾವಿರಾರು ನಿದರ್ಶನಗಳೊಂದಿಗೆ ನಮ್ಮ ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ ~300Mb ಅನ್ನು ಬಳಸುತ್ತದೆ. ಇದು ಸಂಪೂರ್ಣ ಕ್ಲಸ್ಟರ್‌ಗೆ ಅಳೆಯಲು ಅನುಮತಿಸುವುದಿಲ್ಲ.

Netramesh ನೊಂದಿಗೆ ನಾವು ಮೆಮೊರಿ ಬಳಕೆಯಲ್ಲಿ ~10x ಕಡಿತವನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ.

ಸಿಪಿಯು

CPU ಬಳಕೆಯು ಲೋಡ್ ಅಡಿಯಲ್ಲಿ ತುಲನಾತ್ಮಕವಾಗಿ ಸಮಾನವಾಗಿರುತ್ತದೆ. ಇದು ಸೈಡ್‌ಕಾರ್‌ಗೆ ಪ್ರತಿ ಯುನಿಟ್ ಸಮಯದ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. ಗರಿಷ್ಠ ಮಟ್ಟದಲ್ಲಿ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 3000 ವಿನಂತಿಗಳಲ್ಲಿ ಮೌಲ್ಯಗಳು:

ಇನ್ನೂ ಒಂದು ಪ್ರಮುಖ ಅಂಶವಿದೆ: Netramesh - ನಿಯಂತ್ರಣ ಸಮತಲವಿಲ್ಲದೆ ಮತ್ತು ಲೋಡ್ ಇಲ್ಲದೆ ಪರಿಹಾರವು CPU ಸಮಯವನ್ನು ಬಳಸುವುದಿಲ್ಲ. ಇಸ್ಟಿಯೊ ಜೊತೆಗೆ, ಸೈಡ್‌ಕಾರ್‌ಗಳು ಯಾವಾಗಲೂ ಸೇವಾ ಅಂತಿಮ ಬಿಂದುಗಳನ್ನು ನವೀಕರಿಸುತ್ತವೆ. ಪರಿಣಾಮವಾಗಿ, ನಾವು ಈ ಚಿತ್ರವನ್ನು ಲೋಡ್ ಇಲ್ಲದೆ ನೋಡಬಹುದು:

ಸೇವೆಗಳ ನಡುವಿನ ಸಂವಹನಕ್ಕಾಗಿ ನಾವು HTTP/1 ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ರಾಯಭಾರಿ ಮೂಲಕ ಪ್ರಾಕ್ಸಿ ಮಾಡುವಾಗ ಇಸ್ಟಿಯೊಗೆ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯದ ಹೆಚ್ಚಳವು 5-10ms ವರೆಗೆ ಇತ್ತು, ಇದು ಮಿಲಿಸೆಕೆಂಡ್‌ನಲ್ಲಿ ಪ್ರತಿಕ್ರಿಯಿಸಲು ಸಿದ್ಧವಾಗಿರುವ ಸೇವೆಗಳಿಗೆ ಸಾಕಷ್ಟು ಆಗಿದೆ. Netramesh ಜೊತೆ ಈ ಸಮಯ 0.5-2ms ಕಡಿಮೆಯಾಗಿದೆ.

ಸ್ಕೇಲೆಬಿಲಿಟಿ

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

ಸೇವೆಯ ಅನ್ವೇಷಣೆ

Netramesh ಸೇವೆಯ ಅನ್ವೇಷಣೆಗಾಗಿ ಯಾವುದೇ ಹೆಚ್ಚುವರಿ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಸೇರಿಸುವುದಿಲ್ಲ. ನೇತ್ರಾ ಸೈಡ್‌ಕಾರ್ ಮೂಲಕ ಎಲ್ಲಾ ಟ್ರಾಫಿಕ್ ಪಾರದರ್ಶಕವಾಗಿ ಪ್ರಾಕ್ಸಿಯಾಗಿದೆ.

Netramesh HTTP/1 ಅಪ್ಲಿಕೇಶನ್ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ. ಅದನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಲು, ಪೋರ್ಟ್‌ಗಳ ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದಾದ ಪಟ್ಟಿಯನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. ವಿಶಿಷ್ಟವಾಗಿ, ಸಿಸ್ಟಮ್ ಹಲವಾರು ಪೋರ್ಟ್‌ಗಳನ್ನು ಹೊಂದಿದೆ, ಅದರ ಮೂಲಕ HTTP ಸಂವಹನ ಸಂಭವಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಸೇವೆಗಳು ಮತ್ತು ಬಾಹ್ಯ ವಿನಂತಿಗಳ ನಡುವಿನ ಪರಸ್ಪರ ಕ್ರಿಯೆಗಾಗಿ ನಾವು 80, 8890, 8080 ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಪರಿಸರ ವೇರಿಯಬಲ್ ಬಳಸಿ ಅವುಗಳನ್ನು ಹೊಂದಿಸಬಹುದು NETRA_HTTP_PORTS.

ನೀವು ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಆಗಿ ಬಳಸಿದರೆ ಮತ್ತು ಸೇವೆಗಳ ನಡುವಿನ ಅಂತರ-ಕ್ಲಸ್ಟರ್ ಸಂವಹನಕ್ಕಾಗಿ ಅದರ ಸೇವಾ ಘಟಕದ ಕಾರ್ಯವಿಧಾನವನ್ನು ಬಳಸಿದರೆ, ಕಾರ್ಯವಿಧಾನವು ಒಂದೇ ಆಗಿರುತ್ತದೆ. ಮೊದಲಿಗೆ, ಮೈಕ್ರೋ ಸರ್ವಿಸ್ kube-dns ಅನ್ನು ಬಳಸಿಕೊಂಡು ಸೇವಾ IP ವಿಳಾಸವನ್ನು ಪಡೆಯುತ್ತದೆ ಮತ್ತು ಅದಕ್ಕೆ ಹೊಸ ಸಂಪರ್ಕವನ್ನು ತೆರೆಯುತ್ತದೆ. ಈ ಸಂಪರ್ಕವನ್ನು ಮೊದಲು ಸ್ಥಳೀಯ ನೇತ್ರಾ-ಸೈಡ್‌ಕಾರ್‌ನೊಂದಿಗೆ ಸ್ಥಾಪಿಸಲಾಗಿದೆ ಮತ್ತು ಎಲ್ಲಾ TCP ಪ್ಯಾಕೆಟ್‌ಗಳು ಆರಂಭದಲ್ಲಿ ನೇತ್ರವನ್ನು ತಲುಪುತ್ತವೆ. ಮುಂದೆ, ನೇತ್ರಾ-ಸೈಡ್‌ಕಾರ್ ಮೂಲ ಗಮ್ಯಸ್ಥಾನದೊಂದಿಗೆ ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ. ನೋಡ್‌ನಲ್ಲಿನ ಪಾಡ್ ಐಪಿಯಲ್ಲಿನ NAT ನೇತ್ರಾ ಇಲ್ಲದಂತೆಯೇ ಇರುತ್ತದೆ.

ವಿತರಿಸಿದ ಟ್ರೇಸಿಂಗ್ ಮತ್ತು ಸಂದರ್ಭ ಫಾರ್ವರ್ಡ್

HTTP ಸಂವಹನಗಳ ಕುರಿತು ಟ್ರೇಸಿಂಗ್ ಸ್ಪ್ಯಾನ್‌ಗಳನ್ನು ಕಳುಹಿಸಲು ಅಗತ್ಯವಿರುವ ಕಾರ್ಯವನ್ನು Netramesh ಒದಗಿಸುತ್ತದೆ. Netra-sidecar HTTP ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಪಾರ್ಸ್ ಮಾಡುತ್ತದೆ, ವಿನಂತಿಯ ವಿಳಂಬವನ್ನು ಅಳೆಯುತ್ತದೆ ಮತ್ತು HTTP ಹೆಡರ್‌ಗಳಿಂದ ಅಗತ್ಯ ಮಾಹಿತಿಯನ್ನು ಹೊರತೆಗೆಯುತ್ತದೆ. ಅಂತಿಮವಾಗಿ, ನಾವು ಒಂದೇ ಜೇಗರ್ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಎಲ್ಲಾ ಕುರುಹುಗಳನ್ನು ಪಡೆಯುತ್ತೇವೆ. ಸೂಕ್ಷ್ಮ-ಧಾನ್ಯದ ಸಂರಚನೆಗಾಗಿ, ನೀವು ಅಧಿಕೃತ ಗ್ರಂಥಾಲಯದಿಂದ ಒದಗಿಸಲಾದ ಪರಿಸರ ಅಸ್ಥಿರಗಳನ್ನು ಸಹ ಬಳಸಬಹುದು ಜೇಗರ್ ಗೋ ಲೈಬ್ರರಿ.

ಆದರೆ ಒಂದು ಸಮಸ್ಯೆ ಇದೆ. ಸೇವೆಗಳು ವಿಶೇಷ ಉಬರ್ ಹೆಡರ್ ಅನ್ನು ರಚಿಸುವವರೆಗೆ ಮತ್ತು ಕಳುಹಿಸುವವರೆಗೆ, ನಾವು ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಸಂಪರ್ಕಿತ ಟ್ರೇಸಿಂಗ್ ಸ್ಪ್ಯಾನ್‌ಗಳನ್ನು ನೋಡುವುದಿಲ್ಲ. ಮತ್ತು ಸಮಸ್ಯೆಗಳ ಕಾರಣವನ್ನು ನಾವು ತ್ವರಿತವಾಗಿ ಕಂಡುಹಿಡಿಯಬೇಕು. ಇಲ್ಲಿಯೂ ನೇತ್ರಮೇಶ್ ಪರಿಹಾರ ಕಂಡುಕೊಂಡಿದ್ದಾರೆ. ಪ್ರಾಕ್ಸಿಗಳು HTTP ಹೆಡರ್‌ಗಳನ್ನು ಓದುತ್ತವೆ ಮತ್ತು ಅವುಗಳು uber ಟ್ರೇಸ್ ಐಡಿಯನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ, ಒಂದನ್ನು ರಚಿಸಿ. ನೇತ್ರಮೇಶ್ ಒಳಬರುವ ಮತ್ತು ಹೊರಹೋಗುವ ವಿನಂತಿಗಳ ಮಾಹಿತಿಯನ್ನು ಸೈಡ್‌ಕಾರ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸುತ್ತದೆ ಮತ್ತು ಅಗತ್ಯ ಹೊರಹೋಗುವ ವಿನಂತಿಯ ಹೆಡರ್‌ಗಳೊಂದಿಗೆ ಅವುಗಳನ್ನು ಪುಷ್ಟೀಕರಿಸುವ ಮೂಲಕ ಅವುಗಳನ್ನು ಹೊಂದಿಸುತ್ತದೆ. ಸೇವೆಗಳಲ್ಲಿ ನೀವು ಮಾಡಬೇಕಾಗಿರುವುದು ಕೇವಲ ಒಂದು ಹೆಡರ್ ಅನ್ನು ಕಳುಹಿಸುವುದು X-Request-Id, ಇದು ಪರಿಸರ ವೇರಿಯಬಲ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು NETRA_HTTP_REQUEST_ID_HEADER_NAME. Netramesh ನಲ್ಲಿ ಸಂದರ್ಭದ ಗಾತ್ರವನ್ನು ನಿಯಂತ್ರಿಸಲು, ನೀವು ಈ ಕೆಳಗಿನ ಪರಿಸರ ವೇರಿಯಬಲ್‌ಗಳನ್ನು ಹೊಂದಿಸಬಹುದು: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (ಸಂದರ್ಭವನ್ನು ಸಂಗ್ರಹಿಸುವ ಸಮಯ) ಮತ್ತು NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (ಸಂದರ್ಭ ಶುದ್ಧೀಕರಣದ ಆವರ್ತನ).

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

ವಿನಂತಿಯ ಮೂಲವನ್ನು ನಿರ್ಧರಿಸುವುದು

ವಿನಂತಿಯು ಎಲ್ಲಿಂದ ಬಂದಿದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಲು, ಮೂಲದೊಂದಿಗೆ ಹೆಡರ್ ಅನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸೇರಿಸುವ ಕಾರ್ಯವನ್ನು ನೀವು ಬಳಸಬಹುದು. ಪರಿಸರ ವೇರಿಯಬಲ್ ಅನ್ನು ಬಳಸುವುದು NETRA_HTTP_X_SOURCE_HEADER_NAME ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸ್ಥಾಪಿಸಲಾಗುವ ಹೆಡರ್ ಹೆಸರನ್ನು ನೀವು ನಿರ್ದಿಷ್ಟಪಡಿಸಬಹುದು. ಬಳಸಿಕೊಂಡು NETRA_HTTP_X_SOURCE_VALUE ಎಲ್ಲಾ ಹೊರಹೋಗುವ ವಿನಂತಿಗಳಿಗೆ X-ಮೂಲ ಹೆಡರ್ ಅನ್ನು ಹೊಂದಿಸುವ ಮೌಲ್ಯವನ್ನು ನೀವು ಹೊಂದಿಸಬಹುದು.

ಈ ಉಪಯುಕ್ತ ಹೆಡರ್ನ ವಿತರಣೆಯನ್ನು ನೆಟ್ವರ್ಕ್ನಾದ್ಯಂತ ಏಕರೂಪವಾಗಿ ವಿತರಿಸಲು ಇದು ಅನುಮತಿಸುತ್ತದೆ. ನಂತರ ನೀವು ಅದನ್ನು ಸೇವೆಗಳಲ್ಲಿ ಬಳಸಬಹುದು ಮತ್ತು ಅದನ್ನು ಲಾಗ್‌ಗಳು ಮತ್ತು ಮೆಟ್ರಿಕ್‌ಗಳಿಗೆ ಸೇರಿಸಬಹುದು.

ಟ್ರಾಫಿಕ್ ರೂಟಿಂಗ್ ಮತ್ತು ನೇತ್ರಮೇಶ್ ಇಂಟರ್ನಲ್‌ಗಳು

ನೇತ್ರಮೆಶ್ ಎರಡು ಮುಖ್ಯ ಘಟಕಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. ಮೊದಲನೆಯದು, ನೇಟ್ರಾ-ಇನಿಟ್, ಟ್ರಾಫಿಕ್ ಅನ್ನು ಪ್ರತಿಬಂಧಿಸಲು ನೆಟ್‌ವರ್ಕ್ ನಿಯಮಗಳನ್ನು ಹೊಂದಿಸುತ್ತದೆ. ಅವನು ಬಳಸುತ್ತಾನೆ iptables ಮರುನಿರ್ದೇಶನ ನಿಯಮಗಳು ನೇತ್ರಮೇಶ್‌ನ ಎರಡನೇ ಮುಖ್ಯ ಅಂಶವಾಗಿರುವ ಸೈಡ್‌ಕಾರ್‌ನಲ್ಲಿನ ಟ್ರಾಫಿಕ್‌ನ ಎಲ್ಲಾ ಅಥವಾ ಭಾಗವನ್ನು ಪ್ರತಿಬಂಧಿಸಲು. ಒಳಬರುವ ಮತ್ತು ಹೊರಹೋಗುವ TCP ಸೆಷನ್‌ಗಳಿಗೆ ಯಾವ ಪೋರ್ಟ್‌ಗಳನ್ನು ತಡೆಹಿಡಿಯಬೇಕು ಎಂಬುದನ್ನು ನೀವು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.

ಉಪಕರಣವು ಆಸಕ್ತಿದಾಯಕ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಸಹ ಹೊಂದಿದೆ - ಸಂಭವನೀಯ ರೂಟಿಂಗ್. ನೀವು ಟ್ರೇಸಿಂಗ್ ಸ್ಪ್ಯಾನ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಪ್ರತ್ಯೇಕವಾಗಿ Netramesh ಅನ್ನು ಬಳಸಿದರೆ, ನಂತರ ಉತ್ಪಾದನಾ ಪರಿಸರದಲ್ಲಿ ನೀವು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಉಳಿಸಬಹುದು ಮತ್ತು ವೇರಿಯೇಬಲ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಸಂಭವನೀಯ ರೂಟಿಂಗ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಬಹುದು. NETRA_INBOUND_PROBABILITY и NETRA_OUTBOUND_PROBABILITY (0 ರಿಂದ 1 ರವರೆಗೆ). ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯವು 1 ಆಗಿದೆ (ಎಲ್ಲಾ ದಟ್ಟಣೆಯನ್ನು ತಡೆಹಿಡಿಯಲಾಗಿದೆ).

ಯಶಸ್ವಿ ಪ್ರತಿಬಂಧದ ನಂತರ, ನೇತ್ರಾ ಸೈಡ್‌ಕಾರ್ ಹೊಸ ಸಂಪರ್ಕವನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಬಳಸುತ್ತದೆ SO_ORIGINAL_DST ಮೂಲ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಪಡೆಯಲು ಸಾಕೆಟ್ ಆಯ್ಕೆ. ನೇತ್ರಾ ನಂತರ ಮೂಲ IP ವಿಳಾಸಕ್ಕೆ ಹೊಸ ಸಂಪರ್ಕವನ್ನು ತೆರೆಯುತ್ತದೆ ಮತ್ತು ಪಕ್ಷಗಳ ನಡುವೆ ದ್ವಿಮುಖ TCP ಸಂವಹನವನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ, ಹಾದುಹೋಗುವ ಎಲ್ಲಾ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಆಲಿಸುತ್ತದೆ. ಪೋರ್ಟ್ ಅನ್ನು HTTP ಎಂದು ವ್ಯಾಖ್ಯಾನಿಸಿದರೆ, ನೇತ್ರಾ ಅದನ್ನು ಪಾರ್ಸ್ ಮಾಡಲು ಮತ್ತು ಪತ್ತೆಹಚ್ಚಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ. HTTP ಪಾರ್ಸಿಂಗ್ ವಿಫಲವಾದರೆ, ನೇತ್ರಾ TCP ಗೆ ಹಿಂತಿರುಗುತ್ತದೆ ಮತ್ತು ಬೈಟ್‌ಗಳನ್ನು ಪಾರದರ್ಶಕವಾಗಿ ಪ್ರಾಕ್ಸಿ ಮಾಡುತ್ತದೆ.

ಅವಲಂಬನೆ ಗ್ರಾಫ್ ಅನ್ನು ನಿರ್ಮಿಸುವುದು

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

ಟ್ರೇಸಿಂಗ್ ಸ್ಪ್ಯಾನ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ನೀವು Elasticsearch ಅನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ, ನೀವು ಬಳಸಬಹುದು ಸರಳ ಗೋಲಾಂಗ್ ಉಪಯುಕ್ತತೆ, ಇದು ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟದ ವೈಶಿಷ್ಟ್ಯಗಳು ಮತ್ತು ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಬಳಸಿಕೊಂಡು ನಿಮಿಷಗಳಲ್ಲಿ ಅದೇ ಗ್ರಾಫ್ ಅನ್ನು ನಿರ್ಮಿಸುತ್ತದೆ.

Netramesh ಅನ್ನು ಹೇಗೆ ಬಳಸುವುದು

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

ಈ ಸಮಯದಲ್ಲಿ, ಸೇವೆಗಳಿಗೆ ಸೈಡ್‌ಕಾರ್‌ಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಅಳವಡಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ನೇತ್ರಾ ಹೊಂದಿಲ್ಲ, ಆದರೆ ಅನುಷ್ಠಾನಕ್ಕೆ ಯೋಜನೆಗಳಿವೆ.

ನೇತ್ರಮೇಶನ ಭವಿಷ್ಯ

ಮುಖ್ಯ ಗುರಿ ನೇತ್ರಮೇಶ್ ಕನಿಷ್ಠ ಸಂಪನ್ಮೂಲ ವೆಚ್ಚಗಳು ಮತ್ತು ಹೆಚ್ಚಿನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸಾಧಿಸುವುದು, ವೀಕ್ಷಣೆ ಮತ್ತು ಅಂತರ-ಸೇವಾ ಸಂವಹನದ ನಿಯಂತ್ರಣಕ್ಕಾಗಿ ಮೂಲಭೂತ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಒದಗಿಸುವುದು.

ಭವಿಷ್ಯದಲ್ಲಿ, HTTP ಜೊತೆಗೆ ಇತರೆ ಅಪ್ಲಿಕೇಶನ್ ಲೇಯರ್ ಪ್ರೋಟೋಕಾಲ್‌ಗಳನ್ನು Netramesh ಬೆಂಬಲಿಸುತ್ತದೆ. L7 ರೂಟಿಂಗ್ ಸದ್ಯದಲ್ಲಿಯೇ ಲಭ್ಯವಾಗಲಿದೆ.

ನೀವು ಇದೇ ರೀತಿಯ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸಿದರೆ Netramesh ಅನ್ನು ಬಳಸಿ ಮತ್ತು ಪ್ರಶ್ನೆಗಳು ಮತ್ತು ಸಲಹೆಗಳೊಂದಿಗೆ ನಮಗೆ ಬರೆಯಿರಿ.

ಮೂಲ: www.habr.com