🥇ಸೇವಾ ಜಾಲರಿ ಬಳಕೆಯ ಪ್ರಕರಣಗಳು

ಸೂಚನೆ. ಅನುವಾದ.: ಈ ಲೇಖನದ ಲೇಖಕರು (ಲುಕ್ ಪರ್ಕಿನ್ಸ್) CNCF ನಲ್ಲಿ ಡೆವಲಪರ್ ವಕೀಲರಾಗಿದ್ದು, ಲಿಂಕಾರ್ಡ್, SMI (ಸರ್ವಿಸ್ ಮೆಶ್ ಇಂಟರ್ಫೇಸ್) ಮತ್ತು ಕುಮಾ ಮುಂತಾದ ಓಪನ್ ಸೋರ್ಸ್ ಯೋಜನೆಗಳಿಗೆ ನೆಲೆಯಾಗಿದೆ (ಅಂದಹಾಗೆ, ಇಸ್ಟಿಯೊ ಈ ಪಟ್ಟಿಯಲ್ಲಿ ಏಕೆ ಇಲ್ಲ ಎಂದು ನೀವು ಯೋಚಿಸಿದ್ದೀರಾ?..). "ಸರ್ವಿಸ್ ಮೆಶ್" ಎಂಬ ಟ್ರೆಂಡಿ ಹೈಪ್ ಅನ್ನು ಡೆವೊಪ್ಸ್ ಸಮುದಾಯಕ್ಕೆ ಚೆನ್ನಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ಮತ್ತೊಂದು ಪ್ರಯತ್ನದಲ್ಲಿ, ಅಂತಹ ಪರಿಹಾರಗಳು ಒದಗಿಸುವ 16 ವಿಶಿಷ್ಟ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಅವರು ಪಟ್ಟಿ ಮಾಡುತ್ತಾರೆ.

ಇಂದು ಸೇವಾ ಜಾಲರಿ ― ಸಾಫ್ಟ್‌ವೇರ್ ಎಂಜಿನಿಯರಿಂಗ್‌ನಲ್ಲಿ ಅತ್ಯಂತ ಜನಪ್ರಿಯ ವಿಷಯಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ (ಮತ್ತು ಸರಿಯಾಗಿಯೇ ಇದೆ!). ಇದು ನಂಬಲಾಗದಷ್ಟು ಭರವಸೆಯ ತಂತ್ರಜ್ಞಾನ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ ಮತ್ತು ಅದನ್ನು ವ್ಯಾಪಕವಾಗಿ ಅಳವಡಿಸಿಕೊಳ್ಳುವುದನ್ನು ನೋಡುವ ಕನಸು ನನಗಿದೆ (ಅದು ಅರ್ಥಪೂರ್ಣವಾದಾಗ, ಸಹಜವಾಗಿ). ಆದಾಗ್ಯೂ, ಹೆಚ್ಚಿನ ಜನರಿಗೆ ಇದು ಇನ್ನೂ ಅದರ ಬಗ್ಗೆ ನಿಗೂಢತೆಯ ಪ್ರಭಾವಲಯವನ್ನು ಹೊಂದಿದೆ. ನನಗೆ ಅವನನ್ನು ಚೆನ್ನಾಗಿ ಗೊತ್ತು. ಅದರೊಂದಿಗೆ, ಅದರ ಅನುಕೂಲಗಳನ್ನು ಮತ್ತು ಅದು ನಿಖರವಾಗಿ ಏನು (ನಿಮ್ಮ ವಿನಮ್ರ ಸೇವಕ ಸೇರಿದಂತೆ) ರೂಪಿಸಲು ಕಷ್ಟವಾಗುತ್ತದೆ. ಈ ಲೇಖನದಲ್ಲಿ, ನಾನು ವಿವಿಧವನ್ನು ಪಟ್ಟಿ ಮಾಡುವ ಮೂಲಕ ಪರಿಸ್ಥಿತಿಯನ್ನು ಸರಿಪಡಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತೇನೆ. ಬಳಕೆಯ ಸನ್ನಿವೇಶಗಳು "ಸೇವಾ ಗ್ರಿಡ್‌ಗಳು"*.

* ಅನುವಾದಕರ ಟಿಪ್ಪಣಿ: ಇಲ್ಲಿಂದ ಈ ಲೇಖನದಲ್ಲಿ, ಈ ಅನುವಾದ ("ಸೇವಾ ಜಾಲರಿ") ಇನ್ನೂ ಹೊಸ ಪದ ಸೇವಾ ಜಾಲರಿಗೆ ಬಳಸಲ್ಪಡುತ್ತದೆ.

ಆದರೆ ಮೊದಲು ನಾನು ಕೆಲವು ಕಾಮೆಂಟ್‌ಗಳನ್ನು ಮಾಡಲು ಬಯಸುತ್ತೇನೆ:

ನನ್ನ ಸ್ವಂತ ಶಿಕ್ಷಣಕ್ಕಾಗಿ ಕೈಗೊಂಡ ಯೋಜನೆಗಳ ಹೊರಗೆ ನಾನು ಎಂದಿಗೂ ಸೇವಾ ಜಾಲಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಿಲ್ಲ ಅಥವಾ ಬಳಸಿಲ್ಲ. ಮತ್ತೊಂದೆಡೆ, ನಾನು 2015 ರಲ್ಲಿ ಟ್ವಿಟರ್‌ನ ಆಂತರಿಕ ಸೇವಾ ಜಾಲಕ್ಕಾಗಿ ಒಂದು ಟನ್ ದಾಖಲಾತಿಯನ್ನು ಬರೆದಿದ್ದೇನೆ (ಆಗ ಅದನ್ನು "ಸೇವಾ ಜಾಲ" ಎಂದು ಕೂಡ ಕರೆಯಲಾಗುತ್ತಿರಲಿಲ್ಲ) ಮತ್ತು ಸೈಟ್ ಮತ್ತು ದಸ್ತಾವೇಜನ್ನುಗೆ ಕೊಡುಗೆ ನೀಡಿದ್ದೇನೆ. ಲಿಂಕರ್ಡ್, ಆದ್ದರಿಂದ ಅದು ಏನನ್ನಾದರೂ ಅರ್ಥೈಸುತ್ತದೆ.
ನನ್ನ ಪಟ್ಟಿ ತಾತ್ಕಾಲಿಕ ಮತ್ತು ಅಪೂರ್ಣ. ನನಗೆ ತಿಳಿದಿಲ್ಲದ ಬಳಕೆಯ ಸಂದರ್ಭಗಳು ಇರುವ ಸಾಧ್ಯತೆಯಿದೆ, ಮತ್ತು ತಂತ್ರಜ್ಞಾನವು ವಿಕಸನಗೊಂಡು ಹೆಚ್ಚು ಜನಪ್ರಿಯವಾಗುತ್ತಿದ್ದಂತೆ ಕಾಲಾನಂತರದಲ್ಲಿ ಹೊಸವುಗಳು ಹೊರಹೊಮ್ಮುವ ಸಾಧ್ಯತೆಯಿದೆ.
ಅದೇ ಸಮಯದಲ್ಲಿ, ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪ್ರತಿಯೊಂದು ಸೇವಾ ಜಾಲರಿ ಅನುಷ್ಠಾನವು ಪಟ್ಟಿ ಮಾಡಲಾದ ಎಲ್ಲಾ ಬಳಕೆಯ ಸಂದರ್ಭಗಳನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ “ಸೇವಾ ಜಾಲರಿ ಮಾಡಬಹುದು…” ನಂತಹ ನನ್ನ ಹೇಳಿಕೆಗಳನ್ನು “ಕೆಲವು, ಮತ್ತು ಬಹುಶಃ ಎಲ್ಲಾ, ಜನಪ್ರಿಯ ಸೇವಾ ಜಾಲರಿ ಅನುಷ್ಠಾನಗಳು ಮಾಡಬಹುದು…” ಎಂದು ಓದಬೇಕು.
ಉದಾಹರಣೆಗಳ ಕ್ರಮವು ಅಪ್ರಸ್ತುತವಾಗುತ್ತದೆ.

ಕಿರು ಪಟ್ಟಿ:

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

1. ಸೇವಾ ಅನ್ವೇಷಣೆ

TL;DR: ಸರಳ ಹೆಸರುಗಳನ್ನು ಬಳಸಿಕೊಂಡು ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿರುವ ಇತರ ಸೇವೆಗಳಿಗೆ ಸಂಪರ್ಕಪಡಿಸಿ.

ಸೇವೆಗಳು ಸೂಕ್ತ ಹೆಸರುಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಪರಸ್ಪರ ಸ್ವಯಂಚಾಲಿತವಾಗಿ "ಹುಡುಕಲು" ಸಾಧ್ಯವಾಗುತ್ತದೆ, ಉದಾಹರಣೆಗೆ service.api.production, pets/staging ಅಥವಾ cassandra. ಮೋಡದ ಪರಿಸರಗಳು ಅವುಗಳ ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವದಿಂದ ನಿರೂಪಿಸಲ್ಪಟ್ಟಿವೆ, ಮತ್ತು ಒಂದು ಹೆಸರು ಬಹು ಸೇವಾ ನಿದರ್ಶನಗಳನ್ನು ಮರೆಮಾಡಬಹುದು. ಅಂತಹ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ಎಲ್ಲಾ IP ವಿಳಾಸಗಳನ್ನು ಹಾರ್ಡ್‌ಕೋಡ್ ಮಾಡುವುದು ಭೌತಿಕವಾಗಿ ಅಸಾಧ್ಯ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ.

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

ಪ್ರತಿಯೊಂದು ಸೇವಾ ಜಾಲವು ಸೇವಾ ಅನ್ವೇಷಣೆಯನ್ನು ವಿಭಿನ್ನವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ. ಪ್ರಸ್ತುತ, ಕುಬರ್ನೆಟ್ಸ್ DNS ನಂತಹ ಬಾಹ್ಯ ಪ್ರಕ್ರಿಯೆಗಳಿಗೆ ನಿಯೋಜಿಸುವುದು ಸಾಮಾನ್ಯ ಮಾರ್ಗವಾಗಿದೆ. ಹಿಂದೆ, ಟ್ವಿಟರ್‌ನಲ್ಲಿ, ನಾವು ಈ ಉದ್ದೇಶಕ್ಕಾಗಿ ಹೆಸರಿನ ವ್ಯವಸ್ಥೆಯನ್ನು ಬಳಸುತ್ತಿದ್ದೆವು. ಫಿಂಗಲ್ಇದರ ಜೊತೆಗೆ, ಸೇವಾ ಜಾಲರಿ ತಂತ್ರಜ್ಞಾನವು ಕಸ್ಟಮ್ ಹೆಸರಿಸುವ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ರಚಿಸಲು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ (ಆದಾಗ್ಯೂ ನಾನು ಅಂತಹ ಕಾರ್ಯವನ್ನು ಹೊಂದಿರುವ ಯಾವುದೇ SM ಅನುಷ್ಠಾನವನ್ನು ಇನ್ನೂ ಎದುರಿಸಿಲ್ಲ).

2. ಗೂಢಲಿಪೀಕರಣ

TL;DR: ಸೇವೆಗಳ ನಡುವಿನ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡದ ದಟ್ಟಣೆಯನ್ನು ತೊಡೆದುಹಾಕಿ ಮತ್ತು ಈ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತ ಮತ್ತು ಸ್ಕೇಲೆಬಲ್ ಆಗಿ ಮಾಡಿ.

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

ಖಂಡಿತ, mTLS ಸೇವಾ ಜಾಲರಿಗಾಗಿ ಐಚ್ಛಿಕ. ಪ್ರತಿಯೊಂದು ಸೇವೆಯು ತನ್ನದೇ ಆದ TLS ಅನ್ನು ನೋಡಿಕೊಳ್ಳಬಹುದು, ಆದರೆ ಇದರರ್ಥ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಉತ್ಪಾದಿಸಲು, ಅವುಗಳನ್ನು ಸೇವಾ ಹೋಸ್ಟ್‌ಗಳಲ್ಲಿ ವಿತರಿಸಲು, ಫೈಲ್‌ಗಳಿಂದ ಈ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಲೋಡ್ ಮಾಡುವ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಕೋಡ್ ಅನ್ನು ಸೇರಿಸಲು ಒಂದು ಮಾರ್ಗವನ್ನು ಕಂಡುಕೊಳ್ಳುವುದು. ಓಹ್, ಮತ್ತು ಈ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ನಿಯಮಿತ ಮಧ್ಯಂತರಗಳಲ್ಲಿ ನವೀಕರಿಸಲು ಮರೆಯಬೇಡಿ. ಸೇವೆ ಮೆಶ್‌ಗಳು mTLS ಅನ್ನು ವ್ಯವಸ್ಥೆಗಳೊಂದಿಗೆ ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುತ್ತವೆ ಸ್ಪಿಫ್, ಇದು ಪ್ರತಿಯಾಗಿ, ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ನೀಡುವ ಮತ್ತು ತಿರುಗಿಸುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುತ್ತದೆ.

3. ದೃಢೀಕರಣ ಮತ್ತು ದೃಢೀಕರಣ

TL;DR: ವಿನಂತಿಯನ್ನು ಯಾರು ಪ್ರಾರಂಭಿಸುತ್ತಿದ್ದಾರೆ ಎಂಬುದನ್ನು ಸ್ಥಾಪಿಸಿ ಮತ್ತು ವಿನಂತಿಯು ಸೇವೆಯನ್ನು ತಲುಪುವ ಮೊದಲು ಅವರಿಗೆ ಏನು ಮಾಡಲು ಅನುಮತಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ.

ಸೇವೆಗಳು ಹೆಚ್ಚಾಗಿ ತಿಳಿದುಕೊಳ್ಳಲು ಬಯಸುತ್ತವೆ, ಯಾರು ವಿನಂತಿಯನ್ನು (ದೃಢೀಕರಣ) ಮಾಡುತ್ತದೆ ಮತ್ತು ಈ ಮಾಹಿತಿಯನ್ನು ಬಳಸಿಕೊಂಡು ನಿರ್ಧರಿಸುತ್ತದೆ ಆ ಈ ವಿಷಯಕ್ಕೆ (ಅಧಿಕಾರ) ಮಾಡಲು ಅವಕಾಶವಿದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, "ಯಾರು" ಎಂಬ ಸರ್ವನಾಮವು ಮರೆಮಾಡಬಹುದು:

ಇತರ ಸೇವೆಗಳು. ಇದನ್ನು "ದೃಢೀಕರಣ" ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ ಪೀರ್'ಎ"ಉದಾಹರಣೆಗೆ, ಸೇವೆ web ಸೇವೆಯನ್ನು ಪ್ರವೇಶಿಸಲು ಬಯಸುತ್ತಾರೆ dbಸೇವಾ ಜಾಲರಿಗಳು ಸಾಮಾನ್ಯವಾಗಿ mTLS ಬಳಸಿ ಇಂತಹ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತವೆ: ಈ ಸಂದರ್ಭದಲ್ಲಿ ಪ್ರಮಾಣಪತ್ರಗಳು ಅಗತ್ಯ ಗುರುತಿಸುವಿಕೆಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ.
ಕೆಲವು ಮಾನವ ಬಳಕೆದಾರರು. ಇದನ್ನು "ದೃಢೀಕರಣ" ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ ವಿನಂತಿಗಳು"ಉದಾಹರಣೆಗೆ, ಬಳಕೆದಾರ haxor69 ಹೊಸ ದೀಪವನ್ನು ಖರೀದಿಸಲು ಬಯಸುತ್ತಾರೆ. ಸೇವಾ ಗ್ರಿಡ್‌ಗಳು ವಿವಿಧ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಒದಗಿಸುತ್ತವೆ, ಉದಾಹರಣೆಗೆ JSON ವೆಬ್ ಟೋಕನ್ಗಳು.
ನಮ್ಮಲ್ಲಿ ಹಲವರು ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್‌ನಲ್ಲಿ ಇದನ್ನು ಮಾಡಿದ್ದೇವೆ. ಒಂದು ವಿನಂತಿ ಬರುತ್ತದೆ, ನಾವು ಒಂದು ಟೇಬಲ್ ಅನ್ನು ನೋಡುತ್ತೇವೆ. users, ಬಳಕೆದಾರರನ್ನು ಹುಡುಕಿ ಮತ್ತು ಪಾಸ್‌ವರ್ಡ್ ಅನ್ನು ಹೋಲಿಕೆ ಮಾಡಿ, ನಂತರ ಕಾಲಮ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿ permissions ಇತ್ಯಾದಿ. ಸೇವಾ ಜಾಲರಿಯ ಸಂದರ್ಭದಲ್ಲಿ, ವಿನಂತಿಯು ಸೇವೆಯನ್ನು ತಲುಪುವ ಮೊದಲೇ ಇದು ಸಂಭವಿಸುತ್ತದೆ.

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

4. ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್

TL;DR: ನಿರ್ದಿಷ್ಟ ಮಾದರಿಯ ಪ್ರಕಾರ ಸೇವಾ ನಿದರ್ಶನಗಳಲ್ಲಿ ಲೋಡ್ ಅನ್ನು ವಿತರಿಸಿ.

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

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

5. ಸರ್ಕ್ಯೂಟ್ ಬ್ರೇಕಿಂಗ್

TL;DR: ಸಮಸ್ಯಾತ್ಮಕ ಸೇವೆಗೆ ಸಂಚಾರವನ್ನು ನಿಲ್ಲಿಸಿ ಮತ್ತು ಕೆಟ್ಟ ಸಂದರ್ಭಗಳಲ್ಲಿ ಹಾನಿಯನ್ನು ನಿಯಂತ್ರಿಸಿ.

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

ಸೇವಾ ಗ್ರಿಡ್‌ಗಳು ನಿಮಗೆ ನಿರ್ಧರಿಸಲು ಮಾತ್ರ ಅನುಮತಿಸುವುದಿಲ್ಲ, ಯಾವಾಗ ಸ್ಥಗಿತಗೊಳಿಸುವಿಕೆಯು ನಂತರ ಬರುತ್ತದೆ ಮತ್ತು ಆ ಅನುಸರಿಸುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, "when" ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ನಿಯತಾಂಕಗಳ ಯಾವುದೇ ಸಂಯೋಜನೆಯನ್ನು ಒಳಗೊಂಡಿರಬಹುದು: ಒಂದು ನಿರ್ದಿಷ್ಟ ಅವಧಿಗೆ ಒಟ್ಟು ವಿನಂತಿಗಳ ಸಂಖ್ಯೆ, ಸಮಾನಾಂತರ ಸಂಪರ್ಕಗಳ ಸಂಖ್ಯೆ, ಬಾಕಿ ಇರುವ ವಿನಂತಿಗಳು, ಸಕ್ರಿಯ ಮರುಪ್ರಯತ್ನಗಳು, ಇತ್ಯಾದಿ.

ನೀವು ಸರ್ಕ್ಯೂಟ್ ಬ್ರೇಕಿಂಗ್ ಅನ್ನು ಅತಿಯಾಗಿ ಬಳಸಲು ಬಯಸದಿರಬಹುದು, ಆದರೆ ತುರ್ತು ಸಂದರ್ಭಗಳಲ್ಲಿ ನಿಮ್ಮ ಬಳಿ ಬ್ಯಾಕಪ್ ಯೋಜನೆ ಇದೆ ಎಂದು ತಿಳಿದುಕೊಳ್ಳುವುದು ಒಳ್ಳೆಯದು.

6. ಆಟೋಸ್ಕೇಲಿಂಗ್

TL;DR: ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಮಾನದಂಡಗಳ ಆಧಾರದ ಮೇಲೆ ಸೇವಾ ನಿದರ್ಶನಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸಿ ಅಥವಾ ಕಡಿಮೆ ಮಾಡಿ.

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

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

7. ಕ್ಯಾನರಿ ನಿಯೋಜನೆಗಳು

TL;DR: ಬಳಕೆದಾರರ ಉಪವಿಭಾಗದಲ್ಲಿ ಸೇವೆಯ ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳು ಅಥವಾ ಆವೃತ್ತಿಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ.

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

ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಯಾವ ಆವೃತ್ತಿಯನ್ನು ಯಾರು ನೋಡುತ್ತಾರೆ ಎಂಬುದಕ್ಕೆ ಮಾನದಂಡಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಲು ಮತ್ತು ಅದಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಟ್ರಾಫಿಕ್ ಅನ್ನು ರೂಟ್ ಮಾಡಲು ಸೇವಾ ಮೆಶ್‌ಗಳು ನಿಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಡುತ್ತವೆ. ಸೇವೆಗಳಿಗೆ ಏನೂ ಬದಲಾಗುವುದಿಲ್ಲ. ಸೇವೆಯ ಆವೃತ್ತಿ 1.0 ಎಲ್ಲಾ ವಿನಂತಿಗಳು ಅದನ್ನು ನೋಡಬೇಕಾದ ಬಳಕೆದಾರರಿಂದ ಬರುತ್ತಿವೆ ಎಂದು ಊಹಿಸುತ್ತದೆ ಮತ್ತು ಆವೃತ್ತಿ 1.1 ಅದರ ಬಳಕೆದಾರರಿಗೆ ಅದೇ ರೀತಿ ಊಹಿಸುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಹಳೆಯ ಮತ್ತು ಹೊಸ ಆವೃತ್ತಿಗಳ ನಡುವಿನ ಟ್ರಾಫಿಕ್‌ನ ಶೇಕಡಾವಾರು ಪ್ರಮಾಣವನ್ನು ನೀವು ಬದಲಾಯಿಸಬಹುದು, ಅದು ಸ್ಥಿರವಾಗಿದ್ದರೆ ಮತ್ತು ನಿಮ್ಮ "ಗಿನಿಯಿಲಿಗಳು" ಚಾಲನೆ ನೀಡಿದರೆ ಹೆಚ್ಚುತ್ತಿರುವ ಸಂಖ್ಯೆಯ ಬಳಕೆದಾರರನ್ನು ಹೊಸದಕ್ಕೆ ಮರುನಿರ್ದೇಶಿಸಬಹುದು.

8. ನೀಲಿ-ಹಸಿರು ನಿಯೋಜನೆಗಳು

TL;DR: ಒಂದು ಹೊಸ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಹೊರತರೋಣ, ಆದರೆ ಅದನ್ನು ತಕ್ಷಣವೇ ಹಿಂತಿರುಗಿಸಲು ಸಿದ್ಧರಾಗಿರಿ.

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

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

ಸೂಚನೆ. ಅನುವಾದ.: ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿನ ವಿವಿಧ ನಿಯೋಜನಾ ತಂತ್ರಗಳ ಕುರಿತು (ಉಲ್ಲೇಖಿಸಲಾದ ಕ್ಯಾನರಿ, ನೀಲಿ/ಹಸಿರು ಮತ್ತು ಇತರವುಗಳನ್ನು ಒಳಗೊಂಡಂತೆ) ನೀವು ಇನ್ನಷ್ಟು ಓದಬಹುದು ಈ ಲೇಖನ.

9. ಆರೋಗ್ಯ ತಪಾಸಣೆ

TL;DR: ಯಾವ ಸೇವಾ ನಿದರ್ಶನಗಳು ಆರೋಗ್ಯಕರವಾಗಿವೆ ಎಂಬುದನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ ಮತ್ತು ಇನ್ನು ಮುಂದೆ ಆರೋಗ್ಯಕರವಾಗಿಲ್ಲದವುಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಿ.

ಆರೋಗ್ಯ ತಪಾಸಣೆ (ಆರೋಗ್ಯ ತಪಾಸಣೆ) ಸೇವಾ ನಿದರ್ಶನಗಳು ಟ್ರಾಫಿಕ್ ಅನ್ನು ಸ್ವೀಕರಿಸಲು ಮತ್ತು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಸಿದ್ಧವಾಗಿವೆಯೇ ಎಂದು ನಿರ್ಧರಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, HTTP ಸೇವೆಗಳ ಸಂದರ್ಭದಲ್ಲಿ, ಆರೋಗ್ಯ ಪರಿಶೀಲನೆಯು ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗೆ GET ವಿನಂತಿಯಂತೆ ಕಾಣಿಸಬಹುದು /healthಉತ್ತರ 200 OK ಅಂದರೆ ನಿದರ್ಶನವು ಆರೋಗ್ಯಕರವಾಗಿದೆ, ಬೇರೆ ಯಾವುದಾದರೂ - ಅದು ಸಂಚಾರವನ್ನು ಸ್ವೀಕರಿಸಲು ಸಿದ್ಧವಾಗಿಲ್ಲ ಎಂದರ್ಥ. ಸೇವಾ ಮೆಶ್‌ಗಳು ಆರೋಗ್ಯವನ್ನು ಪರಿಶೀಲಿಸುವ ವಿಧಾನ ಮತ್ತು ಈ ಪರಿಶೀಲನೆಯನ್ನು ನಿರ್ವಹಿಸುವ ಆವರ್ತನ ಎರಡನ್ನೂ ನಿರ್ದಿಷ್ಟಪಡಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ನಂತರ ಈ ಮಾಹಿತಿಯನ್ನು ಇತರ ಉದ್ದೇಶಗಳಿಗಾಗಿ ಬಳಸಬಹುದು - ಉದಾಹರಣೆಗೆ, ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ಮತ್ತು ಸರ್ಕ್ಯೂಟ್ ಬ್ರೇಕಿಂಗ್‌ಗಾಗಿ.

ಹೀಗಾಗಿ, ಆರೋಗ್ಯ ತಪಾಸಣೆಗಳು ಸ್ವತಂತ್ರ ಬಳಕೆಯ ಸಂದರ್ಭವಲ್ಲ, ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ ಇತರ ಗುರಿಗಳನ್ನು ಸಾಧಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ. ಅಲ್ಲದೆ, ಆರೋಗ್ಯ ತಪಾಸಣೆಗಳ ಫಲಿತಾಂಶಗಳನ್ನು ಅವಲಂಬಿಸಿ, ಬಾಹ್ಯ (ಇತರ ಸೇವಾ ಮೆಶ್ ಗುರಿಗಳಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ) ಕ್ರಮಗಳು ಅಗತ್ಯವಾಗಬಹುದು: ಉದಾಹರಣೆಗೆ, ಸ್ಥಿತಿ ಪುಟವನ್ನು ನವೀಕರಿಸುವುದು, GitHub ನಲ್ಲಿ ಸಮಸ್ಯೆಯನ್ನು ರಚಿಸುವುದು ಅಥವಾ JIRA ಟಿಕೆಟ್ ಅನ್ನು ಭರ್ತಿ ಮಾಡುವುದು. ಮತ್ತು ಸೇವಾ ಮೆಶ್ ಇದೆಲ್ಲವನ್ನೂ ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ಅನುಕೂಲಕರ ಕಾರ್ಯವಿಧಾನವನ್ನು ನೀಡುತ್ತದೆ.

10. ಲೋಡ್ ಶೆಡ್ಡಿಂಗ್

TL;DR: ಬಳಕೆಯಲ್ಲಿ ತಾತ್ಕಾಲಿಕ ಏರಿಕೆಗೆ ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ ಸಂಚಾರವನ್ನು ಮರುಮಾರ್ಗಗೊಳಿಸಿ.

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

11. ಸಂಚಾರದ ಸಮಾನಾಂತರೀಕರಣ/ಪ್ರತಿಬಿಂಬೀಕರಣ

TL;DR: ಒಂದೇ ವಿನಂತಿಯನ್ನು ಹಲವಾರು ಸ್ಥಳಗಳಿಗೆ ಏಕಕಾಲದಲ್ಲಿ ಕಳುಹಿಸಿ.

ಕೆಲವೊಮ್ಮೆ ಹಲವಾರು ಸೇವೆಗಳಿಗೆ ಒಂದೇ ಬಾರಿಗೆ ವಿನಂತಿಯನ್ನು (ಅಥವಾ ಕೆಲವು ವಿನಂತಿಗಳನ್ನು) ಕಳುಹಿಸುವ ಅವಶ್ಯಕತೆಯಿದೆ. ಒಂದು ವಿಶಿಷ್ಟ ಉದಾಹರಣೆಯೆಂದರೆ ಉತ್ಪಾದನಾ ದಟ್ಟಣೆಯ ಭಾಗವನ್ನು ಸ್ಟೇಜಿಂಗ್ ಸೇವೆಗೆ ಕಳುಹಿಸುವುದು. ಮುಖ್ಯ ಉತ್ಪಾದನಾ ವೆಬ್ ಸರ್ವರ್ ಡೌನ್‌ಸ್ಟ್ರೀಮ್ ಸೇವೆಗೆ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುತ್ತದೆ. products.production ಮತ್ತು ಅದಕ್ಕೆ ಮಾತ್ರ. ಮತ್ತು ಸೇವಾ ಜಾಲವು ಈ ವಿನಂತಿಯನ್ನು ಬುದ್ಧಿವಂತಿಕೆಯಿಂದ ನಕಲಿಸಿ ಕಳುಹಿಸುತ್ತದೆ products.staging, ಇದು ವೆಬ್ ಸರ್ವರ್‌ಗೆ ತಿಳಿದಿರುವುದಿಲ್ಲ.

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

12. ನಿರೋಧನ

TL;DR: ನಿಮ್ಮ ಸೇವಾ ಜಾಲವನ್ನು ಮಿನಿ-ನೆಟ್‌ವರ್ಕ್‌ಗಳಾಗಿ ವಿಭಜಿಸಿ.

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

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

13. ವಿನಂತಿ ದರ ಮಿತಿ, ಮರುಪ್ರಯತ್ನಗಳು ಮತ್ತು ಸಮಯ ಮೀರುವಿಕೆಗಳು

TL;DR: ನಿಮ್ಮ ಕೋಡ್‌ಬೇಸ್‌ನಲ್ಲಿ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುವ ವಿನಂತಿ ನಿರ್ವಹಣಾ ಕಾರ್ಯಗಳನ್ನು ಇನ್ನು ಮುಂದೆ ಸೇರಿಸುವ ಅಗತ್ಯವಿಲ್ಲ.

ಈ ಎಲ್ಲಾ ವಿಷಯಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಬಳಕೆಯ ಸಂದರ್ಭಗಳೆಂದು ಪರಿಗಣಿಸಬಹುದು, ಆದರೆ ಅವುಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಹೊಂದಿರುವ ಒಂದು ವಿಷಯದ ಕಾರಣದಿಂದಾಗಿ ನಾನು ಅವುಗಳನ್ನು ಒಟ್ಟಿಗೆ ಗುಂಪು ಮಾಡಲು ನಿರ್ಧರಿಸಿದೆ: ಅವು ಸಾಮಾನ್ಯವಾಗಿ ಅಪ್ಲಿಕೇಶನ್ ಲೈಬ್ರರಿಗಳಿಂದ ನಿರ್ವಹಿಸಲ್ಪಡುವ ವಿನಂತಿಯ ಜೀವನಚಕ್ರ ನಿರ್ವಹಣಾ ಕಾರ್ಯಗಳನ್ನು ಆಫ್‌ಲೋಡ್ ಮಾಡುತ್ತವೆ. ನೀವು ರೂಬಿ ಆನ್ ರೈಲ್ಸ್ ವೆಬ್ ಸರ್ವರ್ ಅನ್ನು ನಿರ್ಮಿಸುತ್ತಿದ್ದರೆ (ಸೇವಾ ಜಾಲರಿಯೊಂದಿಗೆ ಸಂಯೋಜಿಸಲಾಗಿಲ್ಲ) ಅದು ಬ್ಯಾಕೆಂಡ್ ಸೇವೆಗಳಿಗೆ ವಿನಂತಿಗಳನ್ನು ಮಾಡುತ್ತದೆ gRPC, N ವಿನಂತಿಗಳು ವಿಫಲವಾದರೆ ಏನು ಮಾಡಬೇಕೆಂದು ಅಪ್ಲಿಕೇಶನ್ ಸ್ವತಃ ನಿರ್ಧರಿಸಬೇಕಾಗುತ್ತದೆ. ಈ ಸೇವೆಗಳು ಎಷ್ಟು ಟ್ರಾಫಿಕ್ ಅನ್ನು ನಿಭಾಯಿಸಬಲ್ಲವು ಎಂಬುದನ್ನು ಸಹ ಅದು ಲೆಕ್ಕಾಚಾರ ಮಾಡಬೇಕಾಗುತ್ತದೆ ಮತ್ತು ವಿಶೇಷ ಲೈಬ್ರರಿಯನ್ನು ಬಳಸಿಕೊಂಡು ಈ ನಿಯತಾಂಕಗಳನ್ನು ಹಾರ್ಡ್‌ಕೋಡ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಜೊತೆಗೆ, ಅಪ್ಲಿಕೇಶನ್ ಯಾವಾಗ ಬಿಟ್ಟುಕೊಡಬೇಕು ಮತ್ತು ವಿನಂತಿಯನ್ನು ಕೆಟ್ಟದಾಗಿ ಬಿಡಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಬೇಕಾಗುತ್ತದೆ (ಸಮಯ ಮೀರುವ ಮೂಲಕ). ಮತ್ತು ಮೇಲಿನ ಯಾವುದೇ ನಿಯತಾಂಕಗಳನ್ನು ಬದಲಾಯಿಸಲು, ವೆಬ್ ಸರ್ವರ್ ಅನ್ನು ನಿಲ್ಲಿಸಬೇಕು, ಮರುಸಂರಚಿಸಬೇಕು ಮತ್ತು ಮರುಪ್ರಾರಂಭಿಸಬೇಕು.

ಈ ಕಾರ್ಯಗಳನ್ನು ಸೇವಾ ಜಾಲಕ್ಕೆ ನಿಯೋಜಿಸುವುದು ಎಂದರೆ ಸೇವಾ ಅಭಿವರ್ಧಕರು ಅವುಗಳ ಬಗ್ಗೆ ಯೋಚಿಸಬೇಕಾಗಿಲ್ಲ, ಜೊತೆಗೆ ಅವುಗಳನ್ನು ಹೆಚ್ಚು ಜಾಗತಿಕ ರೀತಿಯಲ್ಲಿ ಪರಿಗಣಿಸಬಹುದು. ನೀವು A –> B –> C –> D –> E ಎಂದು ಹೇಳುವಂತಹ ಸಂಕೀರ್ಣ ಸೇವೆಗಳ ಸರಪಣಿಯನ್ನು ಹೊಂದಿದ್ದರೆ, ನೀವು ವಿನಂತಿಯ ಸಂಪೂರ್ಣ ಜೀವನಚಕ್ರವನ್ನು ಪರಿಗಣಿಸಬೇಕಾಗುತ್ತದೆ. ನೀವು ಸೇವೆ C ಯಲ್ಲಿ ಸಮಯ ಮೀರುವಿಕೆಯನ್ನು ವಿಸ್ತರಿಸಬೇಕಾದರೆ, ಅದನ್ನು ತುಂಡು ತುಂಡಾಗಿ ಮಾಡುವ ಬದಲು ಒಂದೇ ಬಾರಿಗೆ ಮಾಡುವುದು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ: ಸೇವಾ ಕೋಡ್ ಅನ್ನು ನವೀಕರಿಸುವುದು ಮತ್ತು ಪುಲ್ ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸಲು ಮತ್ತು CI ವ್ಯವಸ್ಥೆಯು ನವೀಕರಿಸಿದ ಸೇವೆಯನ್ನು ನಿಯೋಜಿಸಲು ಕಾಯುವುದು.

14. ಟೆಲಿಮೆಟ್ರಿ

TL;DR: ಸೇವೆಗಳಿಂದ ಎಲ್ಲಾ ಅಗತ್ಯ (ಮತ್ತು ಸಾಕಷ್ಟು ಅಗತ್ಯವಿಲ್ಲದ) ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಿ.

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

ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಸೇವಾ ಜಾಲರಿ ತಂತ್ರಜ್ಞಾನದ ಪ್ರಯೋಜನವೆಂದರೆ, ಸೈಡ್‌ಕಾರ್ ಕಂಟೇನರ್‌ಗಳು ತಾತ್ವಿಕವಾಗಿ, ಮೇಲಿನ ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ತಮ್ಮ ಸೇವೆಗಳಿಂದ ಸಂಗ್ರಹಿಸಬಹುದು. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ನೀವು ಒಂದೇ ಟೆಲಿಮೆಟ್ರಿ ಸಂಗ್ರಹಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ನಿಮ್ಮ ವಿಲೇವಾರಿಯಲ್ಲಿ ಪಡೆಯುತ್ತೀರಿ, ಮತ್ತು ಸೇವಾ ಜಾಲರಿಯು ಈ ಎಲ್ಲಾ ಮಾಹಿತಿಯನ್ನು ವಿವಿಧ ರೀತಿಯಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬಹುದು. ಉದಾಹರಣೆಗೆ:

CLI ನಲ್ಲಿ ಒಂದು ನಿರ್ದಿಷ್ಟ ಸೇವೆಯಿಂದ ಟೈಲ್ ಲಾಗ್‌ಗಳು;
ಸೇವಾ ಮೆಶ್ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನಿಂದ ವಿನಂತಿಯ ಪರಿಮಾಣವನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಿ;
ವಿತರಿಸಿದ ಕುರುಹುಗಳನ್ನು ಸಂಗ್ರಹಿಸಿ ಜೇಗರ್ ನಂತಹ ವ್ಯವಸ್ಥೆಗೆ ರವಾನಿಸಿ.

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

15. ಲೆಕ್ಕಪರಿಶೋಧನೆ

TL;DR: ಇತಿಹಾಸದ ಪಾಠಗಳನ್ನು ಮರೆತವರು ಅವುಗಳನ್ನು ಪುನರಾವರ್ತಿಸಲು ವಿಧಿವಶರಾಗುತ್ತಾರೆ.

ಆಡಿಟಿಂಗ್ ಎನ್ನುವುದು ವ್ಯವಸ್ಥೆಯಲ್ಲಿನ ಪ್ರಮುಖ ಘಟನೆಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ಕಲೆ. ಸೇವಾ ಜಾಲದ ಸಂದರ್ಭದಲ್ಲಿ, ನಿರ್ದಿಷ್ಟ ಸೇವೆಗಳ ನಿರ್ದಿಷ್ಟ ಅಂತಿಮ ಬಿಂದುಗಳಿಗೆ ಯಾರು ವಿನಂತಿಗಳನ್ನು ಮಾಡಿದ್ದಾರೆ ಅಥವಾ ಕಳೆದ ತಿಂಗಳಲ್ಲಿ ಎಷ್ಟು ಬಾರಿ ನಿರ್ದಿಷ್ಟ ಭದ್ರತೆಗೆ ಸಂಬಂಧಿಸಿದ ಘಟನೆ ಸಂಭವಿಸಿದೆ ಎಂಬುದನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುವುದು ಇದರ ಅರ್ಥವಾಗಿರಬಹುದು.

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

16. ದೃಶ್ಯೀಕರಣ

TL;DR: ವಿಚಿತ್ರ ಇಂಟರ್ಫೇಸ್‌ಗಳ ಕಾರಂಜಿಯಾದ React.js ದೀರ್ಘಕಾಲ ಬದುಕಲಿ.

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

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

ಪಟ್ಟಿಯಲ್ಲಿ ಸೇರಿಸಲಾಗಿಲ್ಲ

ನಾನು ಮೊದಲು ಪಟ್ಟಿಯಲ್ಲಿ ಇನ್ನೂ ಕೆಲವು ಬಳಕೆಯ ಸಂದರ್ಭಗಳನ್ನು ಸೇರಿಸಲು ಉದ್ದೇಶಿಸಿದ್ದೆ, ಆದರೆ ನಂತರ ಸೇರಿಸದಿರಲು ನಿರ್ಧರಿಸಿದೆ. ನನ್ನ ನಿರ್ಧಾರಕ್ಕೆ ಕಾರಣಗಳೊಂದಿಗೆ ಅವು ಇಲ್ಲಿವೆ:

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

ತೀರ್ಮಾನಕ್ಕೆ

ಈಗ ಇಷ್ಟೇ! ಮತ್ತೊಮ್ಮೆ, ಈ ಪಟ್ಟಿ ತುಂಬಾ ಷರತ್ತುಬದ್ಧವಾಗಿದೆ ಮತ್ತು ಹೆಚ್ಚಾಗಿ ಅಪೂರ್ಣವಾಗಿದೆ. ನಾನು ಏನನ್ನಾದರೂ ತಪ್ಪಿಸಿಕೊಂಡಿದ್ದೇನೆ ಅಥವಾ ತಪ್ಪು ಮಾಡಿದ್ದೇನೆ ಎಂದು ನೀವು ಭಾವಿಸಿದರೆ, ಟ್ವಿಟರ್‌ನಲ್ಲಿ ನನ್ನನ್ನು ಸಂಪರ್ಕಿಸಿ (@ಲುಪರ್ಕಿನ್ಸ್). ದಯವಿಟ್ಟು ಸಭ್ಯತೆಯ ನಿಯಮಗಳನ್ನು ಪಾಲಿಸಿ.

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

ಲೇಖನದ ಮುಖ್ಯ ವಿವರಣೆಯು "" ಲೇಖನದ ಚಿತ್ರವನ್ನು ಆಧರಿಸಿದೆ.ಸರ್ವಿಸ್ ಮೆಶ್ ಎಂದರೇನು (ಮತ್ತು ಯಾವಾಗ ಬಳಸಬೇಕು)?" (ಗ್ರೆಗೊರಿ ಮ್ಯಾಕಿನ್ನನ್ ಅವರಿಂದ) ಇದು ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಂದ (ಹಸಿರು ಬಣ್ಣದಲ್ಲಿ) ಕೆಲವು ಕಾರ್ಯಗಳು ಅವುಗಳ ನಡುವೆ ಸಂಪರ್ಕಗಳನ್ನು ಒದಗಿಸುವ ಸೇವಾ ಜಾಲರಿಗೆ (ನೀಲಿ ಬಣ್ಣದಲ್ಲಿ) ಹೇಗೆ ವಲಸೆ ಹೋಗಿವೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ.

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

ಮೂಲ: www.habr.com