ಸೂಚನೆ. ಅನುವಾದ.: ಸೇವಾ ಜಾಲರಿಯು ಇನ್ನೂ ರಷ್ಯನ್ ಭಾಷೆಗೆ ಸ್ಥಿರವಾದ ಅನುವಾದವನ್ನು ಹೊಂದಿಲ್ಲದ ವಿದ್ಯಮಾನವಾಗಿದೆ (2 ವರ್ಷಗಳ ಹಿಂದೆ ನಾವು "ಸೇವೆಗಳಿಗಾಗಿ ಜಾಲರಿ" ಆಯ್ಕೆಯನ್ನು ನೀಡಿದ್ದೇವೆ ಮತ್ತು ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ, ಕೆಲವು ಸಹೋದ್ಯೋಗಿಗಳು "ಸೇವಾ ಜರಡಿ" ಸಂಯೋಜನೆಯನ್ನು ಸಕ್ರಿಯವಾಗಿ ಪ್ರಚಾರ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದರು) . ಈ ತಂತ್ರಜ್ಞಾನದ ಬಗ್ಗೆ ನಿರಂತರ ಚರ್ಚೆಯು ಮಾರ್ಕೆಟಿಂಗ್ ಮತ್ತು ತಾಂತ್ರಿಕ ಘಟಕಗಳು ತುಂಬಾ ನಿಕಟವಾಗಿ ಹೆಣೆದುಕೊಂಡಿರುವ ಪರಿಸ್ಥಿತಿಗೆ ಕಾರಣವಾಗಿದೆ. ಮೂಲ ಪದದ ಲೇಖಕರಲ್ಲಿ ಒಬ್ಬರಿಂದ ಈ ಅದ್ಭುತ ವಸ್ತುವು ಎಂಜಿನಿಯರ್‌ಗಳಿಗೆ ಸ್ಪಷ್ಟತೆಯನ್ನು ತರಲು ಉದ್ದೇಶಿಸಿದೆ ಮತ್ತು ಮಾತ್ರವಲ್ಲ.
ನಿಂದ ಕಾಮಿಕ್
ಪರಿಚಯ
ನೀವು ಬ್ಯಾಕೆಂಡ್ ಸಿಸ್ಟಮ್‌ಗಳ ಪ್ರದೇಶದಲ್ಲಿ ಎಲ್ಲೋ ಕೆಲಸ ಮಾಡುವ ಸಾಫ್ಟ್‌ವೇರ್ ಇಂಜಿನಿಯರ್ ಆಗಿದ್ದರೆ, “ಸೇವಾ ಜಾಲರಿ” ಎಂಬ ಪದವು ಕಳೆದ ಎರಡು ವರ್ಷಗಳಿಂದ ನಿಮ್ಮ ಮನಸ್ಸಿನಲ್ಲಿ ಈಗಾಗಲೇ ದೃಢವಾಗಿ ನೆಲೆಗೊಂಡಿದೆ. ವಿಚಿತ್ರವಾದ ಕಾಕತಾಳೀಯಕ್ಕೆ ಧನ್ಯವಾದಗಳು, ಈ ನುಡಿಗಟ್ಟು ಉದ್ಯಮವನ್ನು ಹೆಚ್ಚು ಹೆಚ್ಚು ತೆಗೆದುಕೊಳ್ಳುತ್ತಿದೆ, ಮತ್ತು ಪ್ರಚಾರ ಮತ್ತು ಸಂಬಂಧಿತ ಪ್ರಚಾರದ ಕೊಡುಗೆಗಳು ಸ್ನೋಬಾಲ್‌ನಂತೆ ಬೆಳೆಯುತ್ತಿವೆ, ಬೆಟ್ಟದ ಕೆಳಗೆ ಹಾರುತ್ತಿವೆ ಮತ್ತು ನಿಧಾನಗೊಳ್ಳುವ ಯಾವುದೇ ಲಕ್ಷಣಗಳನ್ನು ತೋರಿಸುತ್ತಿಲ್ಲ.
ಸೇವಾ ಜಾಲರಿಯು ಕ್ಲೌಡ್ ಸ್ಥಳೀಯ ಪರಿಸರ ವ್ಯವಸ್ಥೆಯ ಮರ್ಕಿ, ಒಲವಿನ ನೀರಿನಲ್ಲಿ ಜನಿಸಿತು. ದುರದೃಷ್ಟವಶಾತ್, ಇದರರ್ಥ ಅದರ ಸುತ್ತಲಿನ ಹೆಚ್ಚಿನ ವಿವಾದಗಳು "ಕಡಿಮೆ-ಕ್ಯಾಲೋರಿ ವಟಗುಟ್ಟುವಿಕೆ" ಯಿಂದ ತಾಂತ್ರಿಕ ಪದವನ್ನು ಬಳಸಲು-ಬ್ಲ್ಯಾಂಟ್ ಬುಲ್‌ಶಿಟ್‌ನವರೆಗೆ ಇರುತ್ತದೆ. ಆದರೆ ನೀವು ಎಲ್ಲಾ ಶಬ್ದವನ್ನು ಫಿಲ್ಟರ್ ಮಾಡಿದರೆ, ಸೇವಾ ಜಾಲರಿಯು ನಿಜವಾದ, ನಿರ್ದಿಷ್ಟ ಮತ್ತು ಪ್ರಮುಖ ಕಾರ್ಯವನ್ನು ಹೊಂದಿದೆ ಎಂದು ನೀವು ಕಂಡುಕೊಳ್ಳಬಹುದು.
ಈ ಪೋಸ್ಟ್‌ನಲ್ಲಿ, ನಾನು ಅದನ್ನು ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತೇನೆ: ಸೇವಾ ಮೆಶ್‌ಗೆ ಪ್ರಾಮಾಣಿಕ, ಆಳವಾದ, ಇಂಜಿನಿಯರ್-ಆಧಾರಿತ ಮಾರ್ಗದರ್ಶಿಯನ್ನು ಒದಗಿಸಿ. ನಾನು ಪ್ರಶ್ನೆಗಿಂತ ಹೆಚ್ಚಿನದನ್ನು ಉತ್ತರಿಸುತ್ತೇನೆ: "ಅದು ಏನು?", - ಆದರೂ ಕೂಡ "ಯಾಕೆ?"ಮತ್ತು "ಈಗ ಯಾಕೆ?". ಅಂತಿಮವಾಗಿ, ನಾನು (ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ) ಈ ನಿರ್ದಿಷ್ಟ ತಂತ್ರಜ್ಞಾನವು ಅಂತಹ ಅಸಾಮಾನ್ಯ ಪ್ರಚೋದನೆಯನ್ನು ಏಕೆ ಉಂಟುಮಾಡಿದೆ ಎಂಬುದನ್ನು ವಿವರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತೇನೆ, ಅದು ಸ್ವತಃ ಆಸಕ್ತಿದಾಯಕ ಕಥೆಯಾಗಿದೆ.
ನಾನು ಯಾರು?
ಎಲ್ಲರಿಗು ನಮಸ್ಖರ! ನನ್ನ ಹೆಸರು . ಸೃಷ್ಟಿಕರ್ತರಲ್ಲಿ ನಾನೂ ಒಬ್ಬ - ಮೊದಲ ಸೇವಾ ಜಾಲರಿ ಯೋಜನೆ ಮತ್ತು ಪದದ ನೋಟಕ್ಕೆ ಕಾರಣವಾಗುವ ಯೋಜನೆ ಸೇವಾ ಜಾಲರಿ ಅದರಂತೆ (ಕ್ಷಮಿಸಿ ಹುಡುಗರೇ!). (ಟಿಪ್ಪಣಿ ಅನುವಾದ.: ಅಂದಹಾಗೆ, ಈ ಪದದ ಗೋಚರಿಸುವಿಕೆಯ ಮುಂಜಾನೆ, 2,5 ವರ್ಷಗಳ ಹಿಂದೆ, ನಾವು ಈಗಾಗಲೇ ಅದೇ ಲೇಖಕರ ಆರಂಭಿಕ ವಸ್ತುಗಳನ್ನು ಅನುವಾದಿಸಿದ್ದೇವೆ "".) ನಾನೂ ಮುನ್ನಡೆಸುತ್ತೇನೆ ಲಿಂಕರ್ಡ್ ಮತ್ತು ನಂತಹ ತಂಪಾದ ಸೇವಾ ಜಾಲರಿ ವಿಷಯಗಳನ್ನು ನಿರ್ಮಿಸುವ ಪ್ರಾರಂಭವಾಗಿದೆ .
ಈ ವಿಷಯದ ಬಗ್ಗೆ ನಾನು ಬಹಳ ಪಕ್ಷಪಾತ ಮತ್ತು ವ್ಯಕ್ತಿನಿಷ್ಠ ಅಭಿಪ್ರಾಯವನ್ನು ಹೊಂದಿದ್ದೇನೆ ಎಂದು ನೀವು ಬಹುಶಃ ಊಹಿಸಬಹುದು. ಆದಾಗ್ಯೂ, ನಾನು ಪಕ್ಷಪಾತವನ್ನು ಕನಿಷ್ಠವಾಗಿ ಇರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತೇನೆ (ಒಂದು ವಿಭಾಗವನ್ನು ಹೊರತುಪಡಿಸಿ: "ಸರ್ವಿಸ್ ಮೆಶ್ ಬಗ್ಗೆ ಏಕೆ ಹೆಚ್ಚು ಚರ್ಚೆ ಇದೆ?", - ಇದರಲ್ಲಿ ನಾನು ನನ್ನ ಪೂರ್ವಕಲ್ಪಿತ ವಿಚಾರಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತೇನೆ). ಈ ಮಾರ್ಗದರ್ಶಿಯನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ವಸ್ತುನಿಷ್ಠವಾಗಿಸಲು ನಾನು ನನ್ನ ಕೈಲಾದಷ್ಟು ಮಾಡುತ್ತೇನೆ. ನಿರ್ದಿಷ್ಟ ಉದಾಹರಣೆಗಳಲ್ಲಿ, ನಾನು ಮುಖ್ಯವಾಗಿ ಲಿಂಕರ್ಡ್‌ನ ಅನುಭವವನ್ನು ಅವಲಂಬಿಸುತ್ತೇನೆ, ಇತರ ವಿಧದ ಸೇವಾ ಜಾಲರಿಗಳ ಅನುಷ್ಠಾನದಲ್ಲಿ ನನಗೆ ತಿಳಿದಿರುವ ವ್ಯತ್ಯಾಸಗಳನ್ನು (ಯಾವುದಾದರೂ ಇದ್ದರೆ) ಸೂಚಿಸುತ್ತೇನೆ.
ಸರಿ, ಇದು ಸತ್ಕಾರಗಳಿಗೆ ತೆರಳುವ ಸಮಯ.
ಸೇವಾ ಜಾಲರಿ ಎಂದರೇನು?
ಎಲ್ಲಾ ಪ್ರಚಾರದ ಹೊರತಾಗಿಯೂ, ಸೇವಾ ಜಾಲರಿಯು ರಚನಾತ್ಮಕವಾಗಿ ತುಂಬಾ ಸರಳವಾಗಿದೆ. ಇದು ಕೇವಲ "ಪಕ್ಕದ" ಸೇವೆಗಳಲ್ಲಿರುವ ಬಳಕೆದಾರರ ಸ್ಥಳ ಪ್ರಾಕ್ಸಿಗಳ ಗುಂಪಾಗಿದೆ (ನಾವು ನಂತರ "ಹತ್ತಿರ" ಕುರಿತು ಸ್ವಲ್ಪ ಮಾತನಾಡುತ್ತೇವೆ), ಜೊತೆಗೆ ನಿಯಂತ್ರಣ ಪ್ರಕ್ರಿಯೆಗಳ ಒಂದು ಸೆಟ್. ಪ್ರಾಕ್ಸಿಗಳನ್ನು ಒಟ್ಟಾಗಿ ಕರೆಯಲಾಗುತ್ತದೆ ಡೇಟಾ ಪ್ಲೇನ್, ಮತ್ತು ನಿಯಂತ್ರಣ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ ನಿಯಂತ್ರಣ ಸಮತಲ. ಡೇಟಾ ಪ್ಲೇನ್ ಸೇವೆಗಳ ನಡುವಿನ ಕರೆಗಳನ್ನು ಪ್ರತಿಬಂಧಿಸುತ್ತದೆ ಮತ್ತು ಅವರೊಂದಿಗೆ "ಬೇರೆಯೇನಾದರೂ" ಮಾಡುತ್ತದೆ; ನಿಯಂತ್ರಣ ಸಮತಲವು ಕ್ರಮವಾಗಿ, ಪ್ರಾಕ್ಸಿಯ ನಡವಳಿಕೆಯನ್ನು ಸಂಘಟಿಸುತ್ತದೆ ಮತ್ತು ನಿಮಗೆ ಪ್ರವೇಶವನ್ನು ಒದಗಿಸುತ್ತದೆ, ಅಂದರೆ. ಆಪರೇಟರ್, API ಗೆ, ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಕುಶಲತೆಯಿಂದ ಮತ್ತು ಒಟ್ಟಾರೆಯಾಗಿ ಅಳೆಯಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.
ಈ ಪ್ರಾಕ್ಸಿ ಎಂದರೇನು? ಇದು "ಲೇಯರ್ 7-ಅವೇರ್" ವರ್ಗದ TCP ಪ್ರಾಕ್ಸಿ ಆಗಿದೆ (ಅಂದರೆ OSI ಮಾದರಿಯ 7 ನೇ ಪದರವನ್ನು "ಖಾತೆಗೆ ತೆಗೆದುಕೊಳ್ಳುವುದು") HAProxy ಮತ್ತು NGINX ನಂತಹ. ನಿಮ್ಮ ಇಚ್ಛೆಯಂತೆ ನೀವು ಪ್ರಾಕ್ಸಿಯನ್ನು ಆಯ್ಕೆ ಮಾಡಬಹುದು; ಲಿಂಕರ್ಡ್ ರಸ್ಟ್ ಪ್ರಾಕ್ಸಿಯನ್ನು ಬಳಸುತ್ತಾರೆ, ಜಟಿಲವಲ್ಲದೆ ಹೆಸರಿಸಲಾಗಿದೆ . ನಾವು ಅದನ್ನು ಸೇವೆಯ ಜಾಲರಿಗಾಗಿ ನಿರ್ದಿಷ್ಟವಾಗಿ ಸಂಕಲಿಸಿದ್ದೇವೆ. ಇತರ ಮೆಶ್‌ಗಳು ಇತರ ಪ್ರಾಕ್ಸಿಗಳಿಗೆ ಆದ್ಯತೆ ನೀಡುತ್ತವೆ (ರಾಯಭಾರಿ ಸಾಮಾನ್ಯ ಆಯ್ಕೆಯಾಗಿದೆ). ಆದಾಗ್ಯೂ, ಪ್ರಾಕ್ಸಿಯನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದು ಕೇವಲ ಅನುಷ್ಠಾನದ ವಿಷಯವಾಗಿದೆ.
ಈ ಪ್ರಾಕ್ಸಿ ಸರ್ವರ್‌ಗಳು ಏನು ಮಾಡುತ್ತವೆ? ನಿಸ್ಸಂಶಯವಾಗಿ, ಅವರು ಸೇವೆಗಳಿಗೆ ಮತ್ತು ಸೇವೆಗಳಿಂದ ಕರೆಗಳನ್ನು ಪ್ರಾಕ್ಸಿ ಮಾಡುತ್ತಾರೆ (ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಹೇಳುವುದಾದರೆ, ಅವರು ಪ್ರಾಕ್ಸಿಗಳು ಮತ್ತು ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿಗಳಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಾರೆ, ಒಳಬರುವ ಮತ್ತು ಹೊರಹೋಗುವ ಕರೆಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತಾರೆ). ಮತ್ತು ಅವರು ಕರೆಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುವ ವೈಶಿಷ್ಟ್ಯದ ಸೆಟ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತಾರೆ ನಡುವೆ ಸೇವೆಗಳು. ಸೇವೆಗಳ ನಡುವಿನ ದಟ್ಟಣೆಯ ಮೇಲಿನ ಈ ಗಮನವು ಸೇವಾ ಮೆಶ್ ಪ್ರಾಕ್ಸಿಯನ್ನು API ಗೇಟ್‌ವೇಗಳು ಅಥವಾ ಪ್ರವೇಶ ಪ್ರಾಕ್ಸಿಗಳಿಂದ ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ (ಎರಡನೆಯದು ಹೊರಗಿನ ಪ್ರಪಂಚದಿಂದ ಕ್ಲಸ್ಟರ್‌ಗೆ ಬರುವ ಕರೆಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತದೆ). (ಸೂಚನೆ. ಅನುವಾದ.: ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕುಬರ್ನೆಟ್ಸ್ ಪ್ರವೇಶ ನಿಯಂತ್ರಕಗಳ ಹೋಲಿಕೆಗಾಗಿ, ಅವುಗಳಲ್ಲಿ ಹಲವು ಈಗಾಗಲೇ ಉಲ್ಲೇಖಿಸಲಾದ ರಾಯಭಾರಿಯನ್ನು ಬಳಸುತ್ತವೆ, ನೋಡಿ .)
ಆದ್ದರಿಂದ, ನಾವು ಡೇಟಾ ಪ್ಲೇನ್ ಅನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ. ನಿಯಂತ್ರಣ ಸಮತಲವು ಸರಳವಾಗಿದೆ: ಇದು ಸೇವೆಯ ಅನ್ವೇಷಣೆ, TLS ಪ್ರಮಾಣಪತ್ರ ವಿತರಣೆ, ಮೆಟ್ರಿಕ್‌ಗಳ ಒಟ್ಟುಗೂಡಿಸುವಿಕೆ, ಇತ್ಯಾದಿ ಸೇರಿದಂತೆ ಡೇಟಾ ಪ್ಲೇನ್‌ಗೆ ಕೆಲಸ ಮಾಡಲು ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಯಂತ್ರಶಾಸ್ತ್ರವನ್ನು ಒದಗಿಸುವ ಘಟಕಗಳ ಒಂದು ಗುಂಪಾಗಿದೆ. ಅದರ ನಡವಳಿಕೆ; ಪ್ರತಿಯಾಗಿ, ನಿಯಂತ್ರಣ ಸಮತಲವು API ಅನ್ನು ಒದಗಿಸುತ್ತದೆ ಅದು ಒಟ್ಟಾರೆಯಾಗಿ ಡೇಟಾ ಪ್ಲೇನ್‌ನ ನಡವಳಿಕೆಯನ್ನು ಬದಲಾಯಿಸಲು ಮತ್ತು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.
ಕೆಳಗೆ ಲಿಂಕರ್ಡ್‌ನಲ್ಲಿ ಕಂಟ್ರೋಲ್ ಪ್ಲೇನ್ ಮತ್ತು ಡೇಟಾ ಪ್ಲೇನ್‌ನ ರೇಖಾಚಿತ್ರವಿದೆ. ನೀವು ನೋಡುವಂತೆ, ನಿಯಂತ್ರಣ ಸಮತಲವು ಪ್ರಾಕ್ಸಿ ಸರ್ವರ್‌ಗಳಿಂದ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಪ್ರಮೀತಿಯಸ್ ನಿದರ್ಶನವನ್ನು ಒಳಗೊಂಡಂತೆ ಹಲವಾರು ವಿಭಿನ್ನ ಘಟಕಗಳನ್ನು ಒಳಗೊಂಡಿದೆ, ಹಾಗೆಯೇ ಇತರ ಘಟಕಗಳು destination (ಸೇವೆ ಅನ್ವೇಷಣೆ), identity (ಪ್ರಮಾಣಪತ್ರ ಪ್ರಾಧಿಕಾರ, CA) ಮತ್ತು public-api (ವೆಬ್ ಮತ್ತು CLI ಗಾಗಿ ಅಂತಿಮ ಬಿಂದುಗಳು). ಇದಕ್ಕೆ ವ್ಯತಿರಿಕ್ತವಾಗಿ, ಡೇಟಾ ಪ್ಲೇನ್ ಅಪ್ಲಿಕೇಶನ್ ನಿದರ್ಶನದ ಪಕ್ಕದಲ್ಲಿ ಸರಳವಾದ ಲಿಂಕರ್ಡ್-ಪ್ರಾಕ್ಸಿ ಆಗಿದೆ. ಇದು ಕೇವಲ ತರ್ಕ ರೇಖಾಚಿತ್ರವಾಗಿದೆ; ನೈಜ ಪ್ರಪಂಚದ ನಿಯೋಜನೆಯಲ್ಲಿ, ನೀವು ಪ್ರತಿ ಕಂಟ್ರೋಲ್ ಪ್ಲೇನ್ ಘಟಕದ ಮೂರು ಪ್ರತಿಕೃತಿಗಳನ್ನು ಮತ್ತು ಡೇಟಾ ಪ್ಲೇನ್‌ನಲ್ಲಿ ನೂರಾರು ಅಥವಾ ಸಾವಿರಾರು ಪ್ರಾಕ್ಸಿಗಳನ್ನು ಹೊಂದಿರಬಹುದು.
(ಈ ರೇಖಾಚಿತ್ರದಲ್ಲಿರುವ ನೀಲಿ ಪೆಟ್ಟಿಗೆಗಳು ಕುಬರ್ನೆಟ್ಸ್ ಪಾಡ್‌ಗಳ ಗಡಿಗಳನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತವೆ. ಲಿಂಕರ್ಡ್-ಪ್ರಾಕ್ಸಿ ಹೊಂದಿರುವ ಕಂಟೈನರ್‌ಗಳು ಅಪ್ಲಿಕೇಶನ್ ಕಂಟೈನರ್‌ಗಳಂತೆಯೇ ಅದೇ ಪಾಡ್‌ನಲ್ಲಿ ಇರುವುದನ್ನು ನೀವು ನೋಡಬಹುದು. ಈ ಯೋಜನೆಯನ್ನು ಹೀಗೆ ಕರೆಯಲಾಗುತ್ತದೆ ಸೈಡ್ಕಾರ್ ಕಂಟೇನರ್.)
ಸೇವಾ ಜಾಲರಿ ವಾಸ್ತುಶಿಲ್ಪವು ಹಲವಾರು ಪ್ರಮುಖ ಪರಿಣಾಮಗಳನ್ನು ಹೊಂದಿದೆ. ಮೊದಲನೆಯದಾಗಿ, ಸೇವೆಗಳ ನಡುವಿನ ಕರೆಗಳನ್ನು ಪ್ರತಿಬಂಧಿಸುವುದು ಪ್ರಾಕ್ಸಿಯ ಕೆಲಸವಾಗಿರುವುದರಿಂದ, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸೇವೆಗಳ ಸೆಟ್‌ಗಾಗಿ ನಿರ್ಮಿಸಿದ್ದರೆ ಮಾತ್ರ ಸೇವಾ ಜಾಲರಿಯು ಅರ್ಥಪೂರ್ಣವಾಗಿರುತ್ತದೆ. ಜಾಲರಿ ಮಾಡಬಹುದು ಏಕಶಿಲೆಗಳೊಂದಿಗೆ ಬಳಸಿ, ಆದರೆ ಇದು ಒಂದೇ ಪ್ರಾಕ್ಸಿಯ ಸಲುವಾಗಿ ಸ್ಪಷ್ಟವಾಗಿ ಅನಗತ್ಯವಾಗಿದೆ ಮತ್ತು ಅದರ ಕಾರ್ಯವು ಬೇಡಿಕೆಯಲ್ಲಿರಲು ಅಸಂಭವವಾಗಿದೆ.
ಮತ್ತೊಂದು ಪ್ರಮುಖ ಪರಿಣಾಮವೆಂದರೆ ಸೇವಾ ಜಾಲರಿಯು ಅಗತ್ಯವಿದೆ ಬೃಹತ್ ಪ್ರಾಕ್ಸಿಗಳ ಸಂಖ್ಯೆ. ವಾಸ್ತವವಾಗಿ, ಲಿಂಕರ್ಡ್ ಪ್ರತಿ ಸೇವೆಯ ಪ್ರತಿ ನಿದರ್ಶನಕ್ಕೂ ಲಿಂಕರ್ಡ್-ಪ್ರಾಕ್ಸಿಯನ್ನು ಸರಪಳಿ ಮಾಡುತ್ತದೆ (ಇತರ ಅಳವಡಿಕೆಗಳು ಪ್ರತಿ ಹೋಸ್ಟ್/ಹೋಸ್ಟ್/ವಿಎಂಗೆ ಪ್ರಾಕ್ಸಿಯನ್ನು ಸೇರಿಸುತ್ತವೆ. ಅದು ಹೇಗಾದರೂ ಸಾಕಷ್ಟು). ಪ್ರಾಕ್ಸಿಯ ಇಂತಹ ಸಕ್ರಿಯ ಬಳಕೆಯು ಹಲವಾರು ಹೆಚ್ಚುವರಿ ತೊಡಕುಗಳನ್ನು ಹೊಂದಿದೆ:
- ಡೇಟಾ ಪ್ಲೇನ್‌ನಲ್ಲಿ ಪ್ರಾಕ್ಸಿಗಳು ಇರಬೇಕು ವೇಗವಾಗಿ, ಏಕೆಂದರೆ ಪ್ರತಿ ಕರೆಗೆ ಪ್ರಾಕ್ಸಿಗೆ ಒಂದೆರಡು ಕರೆಗಳಿವೆ: ಕ್ಲೈಂಟ್ ಬದಿಯಲ್ಲಿ ಒಂದು, ಸರ್ವರ್ ಬದಿಯಲ್ಲಿ.
- ಅಲ್ಲದೆ, ಪ್ರಾಕ್ಸಿಗಳು ಇರಬೇಕು ಸಣ್ಣ и ಹಗುರವಾದ. ಪ್ರತಿಯೊಂದೂ ಮೆಮೊರಿ ಮತ್ತು CPU ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸುತ್ತದೆ, ಮತ್ತು ಈ ಬಳಕೆಯು ಅಪ್ಲಿಕೇಶನ್‌ನೊಂದಿಗೆ ರೇಖೀಯವಾಗಿ ಬೆಳೆಯುತ್ತದೆ.
- ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಪ್ರಾಕ್ಸಿಗಳನ್ನು ನಿಯೋಜಿಸಲು ಮತ್ತು ನವೀಕರಿಸಲು ನಿಮಗೆ ಯಾಂತ್ರಿಕತೆಯ ಅಗತ್ಯವಿದೆ. ಹಸ್ತಚಾಲಿತವಾಗಿ ಮಾಡುವುದು ಒಂದು ಆಯ್ಕೆಯಾಗಿಲ್ಲ.
ಸಾಮಾನ್ಯವಾಗಿ, ಸೇವಾ ಜಾಲರಿಯು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ (ಕನಿಷ್ಠ ಪಕ್ಷಿನೋಟದಿಂದ): ನೀವು ಆಂತರಿಕ, ಅಂತರ-ಸೇವಾ ದಟ್ಟಣೆಯೊಂದಿಗೆ "ಏನಾದರೂ ಮಾಡುವ" ಬಳಕೆದಾರರ ಸ್ಥಳ ಪ್ರಾಕ್ಸಿಗಳ ಗುಂಪನ್ನು ನಿಯೋಜಿಸಿ ಮತ್ತು ಅವುಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಮತ್ತು ನಿರ್ವಹಿಸಲು ನಿಯಂತ್ರಣ ಸಮತಲವನ್ನು ಬಳಸಿ.
"ಯಾಕೆ?" ಎಂಬ ಪ್ರಶ್ನೆಗೆ ಇದು ಸಮಯ.
ಸೇವಾ ಜಾಲರಿ ಯಾವುದಕ್ಕಾಗಿ?
ಸೇವಾ ಜಾಲರಿಯ ಕಲ್ಪನೆಯನ್ನು ಮೊದಲು ಎದುರಿಸಿದವರಿಗೆ, ಸ್ವಲ್ಪ ವಿಸ್ಮಯವಾಗಿರಲು ಕ್ಷಮಿಸಬಹುದಾಗಿದೆ. ಸೇವೆಯ ಜಾಲರಿ ವಿನ್ಯಾಸ ಎಂದರೆ ಅದು ಅಪ್ಲಿಕೇಶನ್ ಸುಪ್ತತೆಯನ್ನು ಹೆಚ್ಚಿಸುವುದಲ್ಲದೆ, ಅದು ಕೂಡ ಮಾಡುತ್ತದೆ ಸೇವಿಸಿ ಸಂಪನ್ಮೂಲಗಳು ಮತ್ತು ಸೇರಿಸುತ್ತಾರೆ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ಹೊಸ ಕಾರ್ಯವಿಧಾನಗಳ ಸಮೂಹ. ಮೊದಲು ನೀವು ಸೇವಾ ಜಾಲರಿಯನ್ನು ಹೊಂದಿಸಿ, ಮತ್ತು ನಂತರ ನೀವು ಹಠಾತ್ತನೆ ನೂರಾರು (ಸಾವಿರಾರು ಅಲ್ಲದಿದ್ದರೆ) ಪ್ರಾಕ್ಸಿಗಳನ್ನು ಪೂರೈಸುವ ಅಗತ್ಯವನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತೀರಿ. ಇದಕ್ಕೆ ಯಾರು ಸ್ವಯಂಸೇವಕರಾಗುತ್ತಾರೆ ಎಂಬುದು ಪ್ರಶ್ನೆ.
ಈ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರವು ಎರಡು ಭಾಗಗಳನ್ನು ಹೊಂದಿದೆ. ಮೊದಲನೆಯದಾಗಿ, ಪರಿಸರ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ನಡೆಯುತ್ತಿರುವ ಕೆಲವು ಬದಲಾವಣೆಗಳಿಂದಾಗಿ ಈ ಪ್ರಾಕ್ಸಿಗಳನ್ನು ನಿಯೋಜಿಸುವುದರೊಂದಿಗೆ ಸಂಬಂಧಿಸಿದ ವಹಿವಾಟು ವೆಚ್ಚಗಳನ್ನು ಗಣನೀಯವಾಗಿ ಕಡಿಮೆ ಮಾಡಬಹುದು (ಇದನ್ನು ನಂತರದಲ್ಲಿ ಇನ್ನಷ್ಟು).
ಎರಡನೆಯದಾಗಿ, ಅಂತಹ ಸಾಧನವು ವಾಸ್ತವವಾಗಿ ಸಿಸ್ಟಮ್ಗೆ ಹೆಚ್ಚುವರಿ ತರ್ಕವನ್ನು ಪರಿಚಯಿಸಲು ಉತ್ತಮ ಮಾರ್ಗವಾಗಿದೆ. ಮತ್ತು ಸೇವಾ ಜಾಲರಿಯನ್ನು ಬಳಸಿಕೊಂಡು ಬಹಳಷ್ಟು ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಸೇರಿಸಬಹುದಾಗಿರುವುದರಿಂದ ಮಾತ್ರವಲ್ಲದೆ ಪರಿಸರ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಮಧ್ಯಪ್ರವೇಶಿಸದೆಯೇ ಇದನ್ನು ಮಾಡಬಹುದು. ವಾಸ್ತವವಾಗಿ, ಸಂಪೂರ್ಣ ಸೇವಾ ಜಾಲರಿ ಮಾದರಿಯು ಈ ಪೋಸ್ಟುಲೇಟ್ ಅನ್ನು ಆಧರಿಸಿದೆ: ಬಹುಸೇವಾ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ, ಏನೇ ಇರಲಿ ಮಾಡುತ್ತಿದ್ದಾರೆ ವೈಯಕ್ತಿಕ ಸೇವೆಗಳು, ಸಂಚಾರ ಅವರ ನಡುವೆ ಕ್ರಿಯಾತ್ಮಕತೆಯನ್ನು ಸೇರಿಸಲು ಸೂಕ್ತ ಅಂಶವಾಗಿದೆ.
ಉದಾಹರಣೆಗೆ, ಲಿಂಕರ್ಡ್‌ನಲ್ಲಿ (ಹೆಚ್ಚಿನ ಮೆಶ್‌ಗಳಲ್ಲಿರುವಂತೆ) ಕಾರ್ಯವು ಪ್ರಾಥಮಿಕವಾಗಿ HTTP ಕರೆಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕೃತವಾಗಿದೆ, HTTP/2 ಮತ್ತು gRPC*. ಕ್ರಿಯಾತ್ಮಕತೆಯು ಸಾಕಷ್ಟು ಶ್ರೀಮಂತವಾಗಿದೆ - ಇದನ್ನು ಮೂರು ವರ್ಗಗಳಾಗಿ ವಿಂಗಡಿಸಬಹುದು:
- ಸಂಬಂಧಿತ ವೈಶಿಷ್ಟ್ಯಗಳು ವಿಶ್ವಾಸಾರ್ಹತೆ. ಮರುಪ್ರಯತ್ನ ವಿನಂತಿಗಳು, ಸಮಯ ಮೀರುವಿಕೆಗಳು, ಕ್ಯಾನರಿ ವಿಧಾನ (ಟ್ರಾಫಿಕ್ ಸ್ಪ್ಲಿಟ್/ಮರುನಿರ್ದೇಶನ) ಇತ್ಯಾದಿ.
- ಸಂಬಂಧಿತ ವೈಶಿಷ್ಟ್ಯಗಳು ಉಸ್ತುವಾರಿ. ಪ್ರತಿ ಸೇವೆ ಅಥವಾ ವೈಯಕ್ತಿಕ ಸ್ಥಳಗಳಿಗೆ ಯಶಸ್ಸಿನ ದರಗಳು, ವಿಳಂಬಗಳು ಮತ್ತು ವಿನಂತಿಯ ಸಂಪುಟಗಳ ಒಟ್ಟುಗೂಡಿಸುವಿಕೆ; ಸೇವೆಗಳ ಸ್ಥಳಶಾಸ್ತ್ರದ ನಕ್ಷೆಗಳನ್ನು ನಿರ್ಮಿಸುವುದು, ಇತ್ಯಾದಿ.
- ಸಂಬಂಧಿತ ವೈಶಿಷ್ಟ್ಯಗಳು ಭದ್ರತೆ. ಮ್ಯೂಚುಯಲ್ TLS, ಪ್ರವೇಶ ನಿಯಂತ್ರಣ, ಇತ್ಯಾದಿ.
* ಲಿಂಕರ್ಡ್‌ನ ದೃಷ್ಟಿಕೋನದಿಂದ, gRPC ಪ್ರಾಯೋಗಿಕವಾಗಿ HTTP/2 ಗಿಂತ ಭಿನ್ನವಾಗಿಲ್ಲ: ಇದು ಕೇವಲ ಪೇಲೋಡ್‌ನಲ್ಲಿ ಪ್ರೋಟೋಬಫ್ ಅನ್ನು ಬಳಸುತ್ತದೆ. ಡೆವಲಪರ್‌ನ ದೃಷ್ಟಿಕೋನದಿಂದ, ಈ ಎರಡು ವಿಷಯಗಳು ವಿಭಿನ್ನವಾಗಿವೆ.
ಈ ಹಲವು ಕಾರ್ಯವಿಧಾನಗಳು ವಿನಂತಿಯ ಮಟ್ಟದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ (ಆದ್ದರಿಂದ "L7 ಪ್ರಾಕ್ಸಿ"). ಉದಾಹರಣೆಗೆ, ಸರ್ವಿಸ್ ಫೋ ಸರ್ವಿಸ್ ಬಾರ್‌ಗೆ ಎಚ್‌ಟಿಟಿಪಿ ಕರೆ ಮಾಡಿದರೆ, ಫೂನ ಬದಿಯಲ್ಲಿರುವ ಲಿಂಕರ್ಡ್-ಪ್ರಾಕ್ಸಿ ಬುದ್ಧಿವಂತಿಕೆಯಿಂದ ಲೋಡ್-ಬ್ಯಾಲೆನ್ಸ್ ಮಾಡಬಹುದು ಮತ್ತು ಫೂದಿಂದ ಬಾರ್ ನಿದರ್ಶನಗಳನ್ನು ಗಮನಿಸಿದ ಲೇಟೆನ್ಸಿ ಆಧಾರದ ಮೇಲೆ ಮಾರ್ಗದ ಕರೆಗಳನ್ನು ಮಾಡಬಹುದು; ಅಗತ್ಯವಿದ್ದರೆ ಅದು ವಿನಂತಿಯನ್ನು ಪುನರಾವರ್ತಿಸಬಹುದು (ಮತ್ತು ಅದು ದುರ್ಬಲವಾಗಿದ್ದರೆ); ಅವರು ಪ್ರತಿಕ್ರಿಯೆ ಕೋಡ್ ಮತ್ತು ಸಮಯ ಮೀರುವಿಕೆಯನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡಬಹುದು, ಇತ್ಯಾದಿ. ಅಂತೆಯೇ, ಬಾರ್ ಬದಿಯಲ್ಲಿರುವ ಲಿಂಕರ್ಡ್-ಪ್ರಾಕ್ಸಿ ವಿನಂತಿಯನ್ನು ಅನುಮತಿಸದಿದ್ದರೆ ಅಥವಾ ವಿನಂತಿಯ ಮಿತಿಯನ್ನು ಮೀರಿದರೆ ಅದನ್ನು ತಿರಸ್ಕರಿಸಬಹುದು; ಅದರ ಭಾಗದಲ್ಲಿ ವಿಳಂಬವನ್ನು ಸರಿಪಡಿಸಬಹುದು, ಇತ್ಯಾದಿ.
ಪ್ರಾಕ್ಸಿಗಳು ಸಂಪರ್ಕ ಮಟ್ಟದಲ್ಲಿ "ಏನನ್ನಾದರೂ" ಮಾಡಬಹುದು. ಉದಾಹರಣೆಗೆ, ಫೂ ಬದಿಯಲ್ಲಿರುವ ಲಿಂಕರ್ಡ್-ಪ್ರಾಕ್ಸಿ TLS ಸಂಪರ್ಕವನ್ನು ಪ್ರಾರಂಭಿಸಬಹುದು ಮತ್ತು ಬಾರ್ ಬದಿಯಲ್ಲಿರುವ ಲಿಂಕರ್ಡ್-ಪ್ರಾಕ್ಸಿ ಅದನ್ನು ಕೊನೆಗೊಳಿಸಬಹುದು ಮತ್ತು ಎರಡೂ ಬದಿಗಳು ಪರಸ್ಪರರ TLS ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಪರಿಶೀಲಿಸಬಹುದು*. ಇದು ಸೇವೆಗಳ ನಡುವೆ ಗೂಢಲಿಪೀಕರಣವನ್ನು ಮಾತ್ರ ಒದಗಿಸುತ್ತದೆ, ಆದರೆ ಸೇವೆಗಳನ್ನು ಗುರುತಿಸಲು ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕವಾಗಿ ಸುರಕ್ಷಿತ ಮಾರ್ಗವನ್ನೂ ಸಹ ಒದಗಿಸುತ್ತದೆ: ಫೂ ಮತ್ತು ಬಾರ್ ಅವರು ತಾವು ಹೇಳುವವರೆಂದು "ಸಾಬೀತುಪಡಿಸಬಹುದು".
* "ಸ್ನೇಹಿತರ ಸ್ನೇಹಿತ" ಎಂದರೆ ಕ್ಲೈಂಟ್‌ನ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಸಹ ಪರಿಶೀಲಿಸಲಾಗಿದೆ (ಮ್ಯೂಚುಯಲ್ TLS). "ಕ್ಲಾಸಿಕ್" TLS ನಲ್ಲಿ, ಉದಾಹರಣೆಗೆ, ಬ್ರೌಸರ್ ಮತ್ತು ಸರ್ವರ್ ನಡುವೆ, ಕೇವಲ ಒಂದು ಬದಿಯ (ಸರ್ವರ್) ಪ್ರಮಾಣಪತ್ರವನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಪರಿಶೀಲಿಸಲಾಗುತ್ತದೆ.
ಅವರು ವಿನಂತಿ ಅಥವಾ ಸಂಪರ್ಕದ ಮಟ್ಟದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರಲಿ, ಎಲ್ಲಾ ಸೇವಾ ಜಾಲರಿ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಒತ್ತಿಹೇಳುವುದು ಮುಖ್ಯವಾಗಿದೆ ಕಾರ್ಯಾಚರಣೆ ಪಾತ್ರ. JSON ತುಣುಕಿಗೆ ಕ್ಷೇತ್ರಗಳನ್ನು ಸೇರಿಸುವುದು ಅಥವಾ ಪ್ರೋಟೋಬಫ್‌ಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡುವಂತಹ ಪೇಲೋಡ್‌ನ ಶಬ್ದಾರ್ಥವನ್ನು ಪರಿವರ್ತಿಸಲು Linkerd ಗೆ ಸಾಧ್ಯವಾಗುತ್ತಿಲ್ಲ. ನಾವು ESB ಮತ್ತು ಮಿಡಲ್‌ವೇರ್ ಕುರಿತು ಮಾತನಾಡುವಾಗ ಈ ಪ್ರಮುಖ ವೈಶಿಷ್ಟ್ಯದ ಕುರಿತು ನಾವು ನಂತರ ಮಾತನಾಡುತ್ತೇವೆ.
ಇದು ಸೇವಾ ಜಾಲರಿ ನೀಡುವ ವೈಶಿಷ್ಟ್ಯಗಳ ಸೆಟ್ ಆಗಿದೆ. ಪ್ರಶ್ನೆ ಉದ್ಭವಿಸುತ್ತದೆ: ಅವುಗಳನ್ನು ನೇರವಾಗಿ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಏಕೆ ಕಾರ್ಯಗತಗೊಳಿಸಬಾರದು? ಮತ್ತು ಪ್ರಾಕ್ಸಿಯೊಂದಿಗೆ ಏಕೆ ಗೊಂದಲಗೊಳ್ಳಬೇಕು?
ಸೇವಾ ಜಾಲರಿ ಏಕೆ ಒಳ್ಳೆಯದು
ಸೇವಾ ಜಾಲರಿಯ ಸಾಮರ್ಥ್ಯಗಳು ಆಕರ್ಷಕವಾಗಿದ್ದರೂ, ಅದರ ಮುಖ್ಯ ಮೌಲ್ಯವು ನಿಜವಾಗಿಯೂ ವೈಶಿಷ್ಟ್ಯಗಳಲ್ಲಿ ಇರುವುದಿಲ್ಲ. ಕೊನೆಯಲ್ಲಿ ನಾವು ಮಾಡಬಹುದು ಅವುಗಳನ್ನು ನೇರವಾಗಿ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಿ (ನಂತರ ಇದು ಸೇವಾ ಜಾಲರಿಯ ಮೂಲ ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ). ಒಂದು ವಾಕ್ಯದಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಸೇವಾ ಜಾಲರಿಯ ಮೌಲ್ಯವು ಹೀಗಿರುತ್ತದೆ: ಇದು ಆಧುನಿಕ ಸರ್ವರ್ ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ಸ್ಥಿರವಾದ, ಸ್ಟಾಕ್-ವೈಡ್, ಅಪ್ಲಿಕೇಶನ್-ಕೋಡ್-ಅಜ್ಞೇಯತಾವಾದಿ ರೀತಿಯಲ್ಲಿ ಚಲಾಯಿಸಲು ನಿರ್ಣಾಯಕ ಕಾರ್ಯವನ್ನು ಒದಗಿಸುತ್ತದೆ.
ಈ ಪ್ರಸ್ತಾಪವನ್ನು ವಿಶ್ಲೇಷಿಸೋಣ.
«ಆಧುನಿಕ ಸರ್ವರ್ ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ಚಲಾಯಿಸಲು ಕಾರ್ಯಗಳು ನಿರ್ಣಾಯಕ". ನೀವು ಸಾರ್ವಜನಿಕ ಇಂಟರ್ನೆಟ್‌ಗೆ ಸಂಪರ್ಕಗೊಂಡಿರುವ ವಹಿವಾಟು ಸರ್ವರ್ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿರ್ಮಿಸುತ್ತಿದ್ದರೆ ಅದು ಹೊರಗಿನ ಪ್ರಪಂಚದ ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಕಡಿಮೆ ಸಮಯದಲ್ಲಿ ಅವುಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ - ಉದಾಹರಣೆಗೆ, ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್, API ಸರ್ವರ್ ಮತ್ತು ಇತರ ಆಧುನಿಕ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಬಹುಪಾಲು - ಮತ್ತು ನೀವು ಅದನ್ನು ಪರಸ್ಪರ ಸಿಂಕ್ರೊನಸ್ ಆಗಿ ಸಂವಹನ ಮಾಡುವ ಸೇವೆಗಳ ಗುಂಪಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಿದರೆ ಮತ್ತು ನೀವು ನಿರಂತರವಾಗಿ ಈ ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ಅಪ್‌ಗ್ರೇಡ್ ಮಾಡುತ್ತಿದ್ದರೆ, ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಸೇರಿಸುತ್ತಿದ್ದರೆ ಮತ್ತು ಮಾರ್ಪಾಡು ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಈ ವ್ಯವಸ್ಥೆಯನ್ನು ಕೆಲಸದ ಸ್ಥಿತಿಯಲ್ಲಿ ಇರಿಸಲು ನೀವು ಒತ್ತಾಯಿಸಿದರೆ - ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಅಭಿನಂದನೆಗಳು, ನೀವು ಆಧುನಿಕ ಸರ್ವರ್ ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ರಚಿಸುತ್ತಿದ್ದೀರಿ. ಮತ್ತು ಮೇಲೆ ಪಟ್ಟಿ ಮಾಡಲಾದ ಎಲ್ಲಾ ಉತ್ತಮ ವೈಶಿಷ್ಟ್ಯಗಳು ವಾಸ್ತವವಾಗಿ ನಿಮಗೆ ನಿರ್ಣಾಯಕವಾಗಿವೆ. ಅಪ್ಲಿಕೇಶನ್ ವಿಶ್ವಾಸಾರ್ಹವಾಗಿರಬೇಕು, ಸುರಕ್ಷಿತವಾಗಿರಬೇಕು ಮತ್ತು ಅದು ಏನು ಮಾಡುತ್ತಿದೆ ಎಂಬುದನ್ನು ನೀವು ನೋಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಈ ಪ್ರಶ್ನೆಗಳನ್ನು ಸೇವಾ ಜಾಲರಿಯು ಪರಿಹರಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.
(ಸರಿ, ಈ ವಿಧಾನವು ಸರ್ವರ್ ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ನಿರ್ಮಿಸುವ ಆಧುನಿಕ ಮಾರ್ಗವಾಗಿದೆ ಎಂಬ ನನ್ನ ಕನ್ವಿಕ್ಷನ್ ಹಿಂದಿನ ಪ್ಯಾರಾಗ್ರಾಫ್‌ಗೆ ನುಸುಳಿದೆ. ಇತರರು ಏಕಶಿಲೆಗಳು, "ಪ್ರತಿಕ್ರಿಯಾತ್ಮಕ ಮೈಕ್ರೋಸರ್ವಿಸ್" ಮತ್ತು ಮೇಲಿನ ವ್ಯಾಖ್ಯಾನದ ಅಡಿಯಲ್ಲಿ ಬರದ ಇತರ ವಿಷಯಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಬಯಸುತ್ತಾರೆ. ಈ ಜನರು ಬಹುಶಃ ಅಭಿಪ್ರಾಯವನ್ನು ಹೊಂದಿರಬಹುದು ಅದು ನನ್ನಿಂದ ಭಿನ್ನವಾಗಿದೆ ಮತ್ತು ಪ್ರತಿಯಾಗಿ, ಅವರು "ತಪ್ಪು" ಎಂದು ನಾನು ನಂಬುತ್ತೇನೆ - ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ, ಸೇವಾ ಜಾಲರಿಯು ಅವರಿಗೆ ಹೆಚ್ಚು ಉಪಯುಕ್ತವಲ್ಲ).
«ಸಂಪೂರ್ಣ ಸ್ಟಾಕ್‌ಗೆ ಸಮವಸ್ತ್ರ". ಸೇವಾ ಜಾಲರಿಯಿಂದ ಒದಗಿಸಲಾದ ವೈಶಿಷ್ಟ್ಯಗಳು ಕೇವಲ ನಿರ್ಣಾಯಕವಲ್ಲ. ಅವರು ಯಾವ ಭಾಷೆಯಲ್ಲಿ ಬರೆದಿದ್ದಾರೆ, ಅವರು ಯಾವ ಚೌಕಟ್ಟನ್ನು ಬಳಸುತ್ತಾರೆ, ಯಾರು ಬರೆದಿದ್ದಾರೆ, ಹೇಗೆ ನಿಯೋಜಿಸಲಾಗಿದೆ ಮತ್ತು ಅವುಗಳ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಬಳಕೆಯ ಎಲ್ಲಾ ಇತರ ಸೂಕ್ಷ್ಮತೆಗಳನ್ನು ಲೆಕ್ಕಿಸದೆಯೇ ಅವರು ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿರುವ ಎಲ್ಲಾ ಸೇವೆಗಳಿಗೆ ಅನ್ವಯಿಸುತ್ತಾರೆ.
«ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್ ಸ್ವತಂತ್ರ". ಅಂತಿಮವಾಗಿ, ಸೇವಾ ಜಾಲರಿಯು ಸಂಪೂರ್ಣ ಸ್ಟಾಕ್‌ನಾದ್ಯಂತ ಸ್ಥಿರವಾದ ಕಾರ್ಯವನ್ನು ಒದಗಿಸುವುದಲ್ಲದೆ, ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸಂಪಾದಿಸುವ ಅಗತ್ಯವಿಲ್ಲದ ರೀತಿಯಲ್ಲಿ ಅದು ಮಾಡುತ್ತದೆ. ಕಾನ್ಫಿಗರ್, ಅಪ್‌ಡೇಟ್, ಆಪರೇಟಿಂಗ್, ನಿರ್ವಹಣೆ ಇತ್ಯಾದಿ ಕಾರ್ಯಗಳನ್ನು ಒಳಗೊಂಡಂತೆ ಸೇವಾ ಜಾಲರಿಯ ಕ್ರಿಯಾತ್ಮಕತೆಯ ಮೂಲಭೂತ ಆಧಾರವು ಸಂಪೂರ್ಣವಾಗಿ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಮಟ್ಟದಲ್ಲಿದೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ ಸ್ವತಂತ್ರವಾಗಿದೆ. ಸೇವಾ ಜಾಲರಿಯನ್ನು ಬಾಧಿಸದೆ ಅಪ್ಲಿಕೇಶನ್ ಬದಲಾಯಿಸಬಹುದು. ಪ್ರತಿಯಾಗಿ, ಯಾವುದೇ ಅಪ್ಲಿಕೇಶನ್ ಮಧ್ಯಸ್ಥಿಕೆ ಇಲ್ಲದೆ ಸೇವಾ ಜಾಲರಿಯು ಬದಲಾಗಬಹುದು.
ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಹೇಳುವುದಾದರೆ, ಸೇವಾ ಜಾಲರಿಯು ಪ್ರಮುಖ ಕಾರ್ಯವನ್ನು ಮಾತ್ರ ಒದಗಿಸುತ್ತದೆ, ಆದರೆ ಇದು ಜಾಗತಿಕ, ಏಕರೂಪ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್-ಸ್ವತಂತ್ರ ರೀತಿಯಲ್ಲಿ ಮಾಡುತ್ತದೆ. ಆದ್ದರಿಂದ, ಸೇವಾ ಜಾಲರಿಯ ಕಾರ್ಯವನ್ನು ಸೇವೆಯ ಕೋಡ್‌ನಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದರೂ (ಉದಾಹರಣೆಗೆ, ಪ್ರತಿ ಸೇವೆಯೊಂದಿಗೆ ಲೈಬ್ರರಿಯಂತೆ), ಈ ವಿಧಾನವು ಏಕರೂಪತೆ ಮತ್ತು ಸ್ವಾತಂತ್ರ್ಯವನ್ನು ಒದಗಿಸುವುದಿಲ್ಲ, ಅದು ಮೌಲ್ಯಯುತವಾಗಿದೆ ಸೇವಾ ಜಾಲರಿ.
ಮತ್ತು ನೀವು ಮಾಡಬೇಕಾಗಿರುವುದು ಪ್ರಾಕ್ಸಿಗಳ ಗುಂಪನ್ನು ಸೇರಿಸುವುದು! ನಾನು ಭರವಸೆ ನೀಡುತ್ತೇನೆ, ಶೀಘ್ರದಲ್ಲೇ ನಾವು ಈ ಪ್ರಾಕ್ಸಿಗಳನ್ನು ಸೇರಿಸುವುದರೊಂದಿಗೆ ಸಂಬಂಧಿಸಿದ ಕಾರ್ಯಾಚರಣೆಯ ವೆಚ್ಚಗಳನ್ನು ನೋಡುತ್ತೇವೆ. ಆದರೆ ಮೊದಲು, ಸ್ವಾತಂತ್ರ್ಯದ ಈ ಕಲ್ಪನೆಯನ್ನು ವಿವಿಧ ದೃಷ್ಟಿಕೋನದಿಂದ ನಿಲ್ಲಿಸಿ ನೋಡೋಣ ಜನರು.
ಸೇವಾ ಜಾಲರಿ ಯಾರಿಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ?
ತಂತ್ರಜ್ಞಾನವು ಪರಿಸರ ವ್ಯವಸ್ಥೆಯ ಪ್ರಮುಖ ಭಾಗವಾಗಬೇಕಾದರೆ ಅದು ಅನಾನುಕೂಲವಾಗಿರಬಹುದು, ಅದನ್ನು ಜನರು ಒಪ್ಪಿಕೊಳ್ಳಬೇಕು. ಹಾಗಾದರೆ ಸೇವಾ ಜಾಲರಿಯಲ್ಲಿ ಯಾರು ಆಸಕ್ತಿ ಹೊಂದಿದ್ದಾರೆ? ಇದರ ಬಳಕೆಯಿಂದ ಯಾರಿಗೆ ಲಾಭ?
ನೀವು ಆಧುನಿಕ ಸರ್ವರ್ ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದರೆ, ನಿಮ್ಮ ತಂಡವನ್ನು ಒಂದು ಗುಂಪಿನಂತೆ ನೀವು ಸ್ಥೂಲವಾಗಿ ಊಹಿಸಬಹುದು ಸೇವಾ ಮಾಲೀಕರುವ್ಯಾಪಾರ ತರ್ಕವನ್ನು ಒಟ್ಟಿಗೆ ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ಮತ್ತು ಕಾರ್ಯಗತಗೊಳಿಸುವವರು, ಮತ್ತು ವೇದಿಕೆ ಮಾಲೀಕರುಈ ಸೇವೆಗಳನ್ನು ನಡೆಸುವ ಆಂತರಿಕ ವೇದಿಕೆಯ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಿದೆ. ಸಣ್ಣ ಸಂಸ್ಥೆಗಳಲ್ಲಿ, ಇವರು ಒಂದೇ ವ್ಯಕ್ತಿಗಳಾಗಿರಬಹುದು, ಆದರೆ ಕಂಪನಿಯು ಬೆಳೆದಂತೆ, ಈ ಪಾತ್ರಗಳು ಹೆಚ್ಚು ಸ್ಪಷ್ಟವಾಗುತ್ತವೆ ಮತ್ತು ಉಪ-ಪಾತ್ರಗಳಾಗಿ ವಿಂಗಡಿಸಲ್ಪಡುತ್ತವೆ ... (ಡೆವೊಪ್ಸ್ನ ಬದಲಾಗುತ್ತಿರುವ ಸ್ವಭಾವದ ಬಗ್ಗೆ ಇಲ್ಲಿ ಹೇಳಲು ಬಹಳಷ್ಟು ಇದೆ, ಮೈಕ್ರೊ ಸರ್ವೀಸ್‌ಗಳ ಸಾಂಸ್ಥಿಕ ಪ್ರಭಾವ ಇತ್ಯಾದಿ).
ಈ ದೃಷ್ಟಿಕೋನದಿಂದ, ಸೇವಾ ಜಾಲರಿಯ ಸ್ಪಷ್ಟ ಫಲಾನುಭವಿಗಳು ವೇದಿಕೆಯ ಮಾಲೀಕರು. ಎಲ್ಲಾ ನಂತರ, ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ತಂಡದ ಅಂತಿಮ ಗುರಿಯು ಆಂತರಿಕ ವೇದಿಕೆಯನ್ನು ರಚಿಸುವುದು, ಅದರ ಮೇಲೆ ಸೇವಾ ಮಾಲೀಕರು ವ್ಯಾಪಾರ ತರ್ಕವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು ಮತ್ತು ಅದರ ಕಾರ್ಯಾಚರಣೆಯ ಕಠೋರ ವಿವರಗಳಿಂದ ಗರಿಷ್ಠ ಸ್ವಾತಂತ್ರ್ಯವನ್ನು ಖಾತರಿಪಡಿಸುವ ರೀತಿಯಲ್ಲಿ ಅದನ್ನು ಮಾಡಬಹುದು. ಸೇವಾ ಜಾಲರಿಯು ಈ ಗುರಿಯನ್ನು ಸಾಧಿಸಲು ನಿರ್ಣಾಯಕ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ನೀಡುವುದಲ್ಲದೆ, ಸೇವಾ ಮಾಲೀಕರ ಮೇಲೆ ಯಾವುದೇ ಅವಲಂಬನೆಯನ್ನು ವಿಧಿಸದ ರೀತಿಯಲ್ಲಿ ಮಾಡುತ್ತದೆ.
ಸೇವಾ ಮಾಲೀಕರು ಸಹ ಹೆಚ್ಚು ಪರೋಕ್ಷ ರೀತಿಯಲ್ಲಿ ಪ್ರಯೋಜನ ಪಡೆಯುತ್ತಾರೆ. ಸೇವೆಯ ಮಾಲೀಕರ ಗುರಿಯು ವ್ಯಾಪಾರ ಪ್ರಕ್ರಿಯೆಯ ತರ್ಕವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸಾಧ್ಯವಾದಷ್ಟು ಉತ್ಪಾದಕವಾಗಿದೆ ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಯ ಸಮಸ್ಯೆಗಳ ಬಗ್ಗೆ ಕಡಿಮೆ ಚಿಂತಿಸಬೇಕಾಗಿರುತ್ತದೆ, ಉತ್ತಮವಾಗಿದೆ. ನೀತಿಗಳು ಅಥವಾ TLS ಅನ್ನು ಜಾರಿಗೊಳಿಸುವ, ಹೇಳುವ, ಮರುಪ್ರಯತ್ನಿಸುವ ಬದಲು, ಅವರು ಕೇವಲ ವ್ಯವಹಾರದ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಬಹುದು ಮತ್ತು ವೇದಿಕೆಯು ಉಳಿದವುಗಳನ್ನು ನೋಡಿಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಭಾವಿಸುತ್ತೇವೆ. ಅವರಿಗೆ, ಇದು ದೊಡ್ಡ ಪ್ರಯೋಜನವಾಗಿದೆ.
ವೇದಿಕೆಗಳು ಮತ್ತು ಸೇವೆಗಳ ಮಾಲೀಕರ ನಡುವಿನ ಅಂತಹ ವಿಭಾಗದ ಸಾಂಸ್ಥಿಕ ಮೌಲ್ಯವನ್ನು ಅತಿಯಾಗಿ ಅಂದಾಜು ಮಾಡಲಾಗುವುದಿಲ್ಲ. ಅವಳು ಕೊಡುಗೆ ನೀಡುತ್ತಾಳೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ ಮುಖ್ಯ ಸೇವಾ ಜಾಲರಿಯ ಮೌಲ್ಯಕ್ಕೆ ಕೊಡುಗೆ.
ಮುಂಚಿನ ಲಿಂಕರ್ಡ್ ಅಭಿಮಾನಿಯೊಬ್ಬರು ಅವರು ಸೇವಾ ಜಾಲರಿಯನ್ನು ಏಕೆ ಆರಿಸಿಕೊಂಡರು ಎಂದು ನಮಗೆ ಹೇಳಿದಾಗ ನಾವು ಈ ಪಾಠವನ್ನು ಕಲಿತಿದ್ದೇವೆ: ಏಕೆಂದರೆ ಅದು ಅವರಿಗೆ "ಕನಿಷ್ಠ ಮಾತನಾಡಲು" ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿತು. ಇಲ್ಲಿ ಕೆಲವು ವಿವರಗಳಿವೆ: ಒಂದು ದೊಡ್ಡ ಕಂಪನಿಯ ವ್ಯಕ್ತಿಗಳು ತಮ್ಮ ವೇದಿಕೆಯನ್ನು ಕುಬರ್ನೆಟ್ಸ್ಗೆ ಸ್ಥಳಾಂತರಿಸಿದರು. ಅಪ್ಲಿಕೇಶನ್ ಸೂಕ್ಷ್ಮ ಮಾಹಿತಿಯೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದರಿಂದ, ಅವರು ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿನ ಎಲ್ಲಾ ಸಂವಹನಗಳನ್ನು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಲು ಬಯಸುತ್ತಾರೆ. ಆದಾಗ್ಯೂ, ನೂರಾರು ಸೇವೆಗಳು ಮತ್ತು ನೂರಾರು ಅಭಿವೃದ್ಧಿ ತಂಡಗಳ ಉಪಸ್ಥಿತಿಯಿಂದ ಪರಿಸ್ಥಿತಿಯು ಜಟಿಲವಾಗಿದೆ. ಪ್ರತಿಯೊಬ್ಬರನ್ನು ಸಂಪರ್ಕಿಸುವ ಮತ್ತು ಅವರ ಯೋಜನೆಗಳಲ್ಲಿ TLS ಗೆ ಬೆಂಬಲವನ್ನು ಸೇರಿಸಲು ಅವರಿಗೆ ಮನವರಿಕೆ ಮಾಡುವ ನಿರೀಕ್ಷೆಯು ಅವರಿಗೆ ಇಷ್ಟವಾಗಲಿಲ್ಲ. ಲಿಂಕರ್ಡ್ ಅನ್ನು ಸ್ಥಾಪಿಸುವ ಮೂಲಕ, ಅವರು ವಲಸೆ ಹೋದರು ಹೊಣೆಗಾರಿಕೆ ಡೆವಲಪರ್‌ಗಳಿಂದ (ಅವರ ದೃಷ್ಟಿಕೋನದಿಂದ ಇದು ಅನಗತ್ಯ ತೊಂದರೆಯಾಗಿದೆ) ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಿಗೆ, ಯಾರಿಗೆ ಇದು ಉನ್ನತ ಮಟ್ಟದ ಆದ್ಯತೆಯಾಗಿದೆ. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಲಿಂಕರ್ಡ್ ಅವರಿಗೆ ಸಾಂಸ್ಥಿಕ ಸಮಸ್ಯೆಯಾಗಿ ತಾಂತ್ರಿಕ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲಿಲ್ಲ.
ಸಂಕ್ಷಿಪ್ತವಾಗಿ, ಸೇವಾ ಜಾಲರಿಯು ತಾಂತ್ರಿಕ ಪರಿಹಾರವಲ್ಲ, ಆದರೆ ಸಾಮಾಜಿಕ-ತಾಂತ್ರಿಕ ಸಮಸ್ಯೆಗಳು. (ಧನ್ಯವಾದ ಈ ಪದವನ್ನು ಪರಿಚಯಿಸಲು.
ಸೇವಾ ಜಾಲರಿಯು ನನ್ನ ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆಯೇ?
ಹೌದು. ಅಂದರೆ, ಇಲ್ಲ!
ಮೇಲೆ ವಿವರಿಸಿದ ಮೂರು ವರ್ಗಗಳ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ನೋಡುವಾಗ - ವಿಶ್ವಾಸಾರ್ಹತೆ, ಭದ್ರತೆ ಮತ್ತು ವೀಕ್ಷಣೆ - ಈ ಯಾವುದೇ ಸಮಸ್ಯೆಗಳಿಗೆ ಸೇವಾ ಜಾಲರಿಯು ಸಂಪೂರ್ಣ ಪರಿಹಾರವಲ್ಲ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ. ಲಿಂಕರ್ಡ್ ಪುನರಾವರ್ತಿತ ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸಬಹುದಾದರೂ (ಅವರು ಅಸಮರ್ಥರಾಗಿದ್ದಾರೆಂದು ತಿಳಿದಿದ್ದರೆ), ಸೇವೆಯು ಅಂತಿಮವಾಗಿ ಸ್ಥಗಿತಗೊಂಡರೆ ಬಳಕೆದಾರರಿಗೆ ಏನು ಹಿಂತಿರುಗಿಸಬೇಕು ಎಂಬುದರ ಕುರಿತು ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವ ಸ್ಥಿತಿಯಲ್ಲಿಲ್ಲ - ಅಂತಹ ನಿರ್ಧಾರಗಳನ್ನು ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ ಮಾಡಬೇಕು. ಲಿಂಕರ್ಡ್ ಯಶಸ್ವಿ ವಿನಂತಿಗಳ ಅಂಕಿಅಂಶಗಳನ್ನು ಇರಿಸಬಹುದು, ಆದರೆ ಇದು ಸೇವೆಯನ್ನು ನೋಡಲು ಮತ್ತು ಅದರ ಆಂತರಿಕ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಒದಗಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ - ಅಪ್ಲಿಕೇಶನ್ ಅಂತಹ ಟೂಲ್‌ಕಿಟ್ ಅನ್ನು ಹೊಂದಿರಬೇಕು. ಮತ್ತು ಲಿಂಕರ್ಡ್ mTLS ಅನ್ನು ಹೋಸ್ಟ್ ಮಾಡುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿದ್ದರೂ, ಪೂರ್ಣ ಪ್ರಮಾಣದ ಭದ್ರತಾ ಪರಿಹಾರಗಳಿಗೆ ಹೆಚ್ಚಿನ ಅಗತ್ಯವಿರುತ್ತದೆ.
ಸೇವಾ ಮೆಶ್‌ನಿಂದ ಒದಗಿಸಲಾದ ಈ ಪ್ರದೇಶಗಳಲ್ಲಿನ ವೈಶಿಷ್ಟ್ಯಗಳ ಉಪವಿಭಾಗವು ಸಂಬಂಧಿಸಿದೆ ವೇದಿಕೆಯ ವೈಶಿಷ್ಟ್ಯಗಳು. ಇದರ ಮೂಲಕ ನಾನು ಕಾರ್ಯಗಳನ್ನು ಅರ್ಥೈಸುತ್ತೇನೆ:
- ವ್ಯವಹಾರ ತರ್ಕದಿಂದ ಸ್ವತಂತ್ರ. ಫೂ ಮತ್ತು ಬಾರ್ ನಡುವೆ ಕರೆ ಹಿಸ್ಟೋಗ್ರಾಮ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುವ ವಿಧಾನವು ಸಂಪೂರ್ಣವಾಗಿ ಸ್ವತಂತ್ರವಾಗಿದೆ ಏಕೆ ಫೂ ಕರೆಗಳು ಬಾರ್.
- ಸರಿಯಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲು ಕಷ್ಟ. ಲಿಂಕರ್ಡ್‌ನಲ್ಲಿ, ಮರುಪ್ರಯತ್ನ ಬಜೆಟ್‌ಗಳಂತಹ ಎಲ್ಲಾ ರೀತಿಯ ಅಲಂಕಾರಿಕ ಸಂಗತಿಗಳೊಂದಿಗೆ ಮರುಪ್ರಯತ್ನಗಳನ್ನು ಪ್ಯಾರಾಮೀಟರ್ ಮಾಡಲಾಗಿದೆ. (ಬಜೆಟ್‌ಗಳನ್ನು ಮರುಪ್ರಯತ್ನಿಸಿ), ಏಕೆಂದರೆ ಅಂತಹ ವಿಷಯಗಳ ಅನುಷ್ಠಾನಕ್ಕೆ ಸರಳ ಮನಸ್ಸಿನ ವಿಧಾನವು ಖಂಡಿತವಾಗಿಯೂ "ವಿನಂತಿಗಳ ಹಿಮಪಾತ" ಎಂದು ಕರೆಯಲ್ಪಡುವ ಹೊರಹೊಮ್ಮುವಿಕೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ. (ಚಂಡಮಾರುತವನ್ನು ಮರುಪ್ರಯತ್ನಿಸಿ) ಮತ್ತು ವಿತರಿಸಿದ ವ್ಯವಸ್ಥೆಗಳಿಗೆ ನಿರ್ದಿಷ್ಟವಾದ ಇತರ ಸಮಸ್ಯೆಗಳು.
- ಸ್ಥಿರವಾಗಿ ಅನ್ವಯಿಸಿದಾಗ ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿ. TLS ಕಾರ್ಯವಿಧಾನವು ಎಲ್ಲೆಡೆ ಅನ್ವಯಿಸಿದರೆ ಮಾತ್ರ ಅರ್ಥಪೂರ್ಣವಾಗಿರುತ್ತದೆ.
ಈ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಪ್ರಾಕ್ಸಿ ಲೇಯರ್‌ನಲ್ಲಿ ಅಳವಡಿಸಲಾಗಿರುವುದರಿಂದ (ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಲೇಯರ್‌ನಲ್ಲಿ ಅಲ್ಲ), ಸೇವಾ ಜಾಲರಿಯು ಅವುಗಳನ್ನು платформы, ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲ. ಹೀಗಾಗಿ, ಸೇವೆಗಳನ್ನು ಯಾವ ಭಾಷೆಯಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ, ಅವರು ಯಾವ ಚೌಕಟ್ಟನ್ನು ಬಳಸುತ್ತಾರೆ, ಯಾರು ಮತ್ತು ಏಕೆ ಬರೆದಿದ್ದಾರೆ ಎಂಬುದು ಮುಖ್ಯವಲ್ಲ. ಪ್ರಾಕ್ಸಿಗಳು ಈ ಎಲ್ಲಾ ವಿವರಗಳನ್ನು ಮೀರಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಮತ್ತು ಕಾನ್ಫಿಗರ್ ಮಾಡುವುದು, ನವೀಕರಿಸುವುದು, ನಿರ್ವಹಿಸುವುದು, ನಿರ್ವಹಿಸುವುದು ಇತ್ಯಾದಿ ಕಾರ್ಯಗಳನ್ನು ಒಳಗೊಂಡಂತೆ ಈ ಕಾರ್ಯಚಟುವಟಿಕೆಗಳ ಮೂಲಭೂತ ಆಧಾರವು ಕೇವಲ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಮಟ್ಟದಲ್ಲಿದೆ.
ಸೇವಾ ಜಾಲರಿ ಸಾಮರ್ಥ್ಯಗಳ ಉದಾಹರಣೆಗಳು
ಸಾರಾಂಶದಲ್ಲಿ, ಸೇವಾ ಜಾಲರಿಯು ವಿಶ್ವಾಸಾರ್ಹತೆ, ವೀಕ್ಷಣೆ ಅಥವಾ ಭದ್ರತೆಗೆ ಸಂಪೂರ್ಣ ಪರಿಹಾರವಲ್ಲ. ಈ ಪ್ರದೇಶಗಳ ವ್ಯಾಪ್ತಿಯು ಸೇವಾ ಮಾಲೀಕರು, Ops / SRE ತಂಡಗಳು ಮತ್ತು ಇತರ ಕಂಪನಿ ಮಧ್ಯಸ್ಥಗಾರರ ಕಡ್ಡಾಯ ಭಾಗವಹಿಸುವಿಕೆಯನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಸೇವಾ ಜಾಲರಿಯು ಈ ಪ್ರತಿಯೊಂದು ಪ್ರದೇಶಗಳಿಗೆ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಮಟ್ಟದಲ್ಲಿ "ಸ್ಲೈಸ್" ಅನ್ನು ಮಾತ್ರ ಒದಗಿಸುತ್ತದೆ.
ಸೇವೆಯ ಜಾಲರಿಯು ಇದೀಗ ಏಕೆ ಜನಪ್ರಿಯವಾಗಿದೆ?
ನೀವು ಬಹುಶಃ ಇದೀಗ ಆಶ್ಚರ್ಯ ಪಡುತ್ತಿರುವಿರಿ: ಸರಿ, ಸೇವಾ ಜಾಲರಿಯು ತುಂಬಾ ಉತ್ತಮವಾಗಿದ್ದರೆ, ಹತ್ತು ವರ್ಷಗಳ ಹಿಂದೆ ನಾವು ಲಕ್ಷಾಂತರ ಪ್ರಾಕ್ಸಿಗಳನ್ನು ಸ್ಟಾಕ್‌ನಲ್ಲಿ ನಿಯೋಜಿಸಲು ಏಕೆ ಪ್ರಾರಂಭಿಸಲಿಲ್ಲ?
ಈ ಪ್ರಶ್ನೆಗೆ ನೀರಸ ಉತ್ತರವಿದೆ: ಹತ್ತು ವರ್ಷಗಳ ಹಿಂದೆ ಎಲ್ಲರೂ ಏಕಶಿಲೆಗಳನ್ನು ನಿರ್ಮಿಸಿದರು, ಮತ್ತು ಯಾರಿಗೂ ಸೇವಾ ಜಾಲರಿ ಅಗತ್ಯವಿಲ್ಲ. ಇದು ನಿಜ, ಆದರೆ ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಈ ಉತ್ತರವು ಪಾಯಿಂಟ್ ಅನ್ನು ತಪ್ಪಿಸುತ್ತದೆ. ಹತ್ತು ವರ್ಷಗಳ ಹಿಂದೆಯೂ ಸಹ, ದೊಡ್ಡ-ಪ್ರಮಾಣದ ವ್ಯವಸ್ಥೆಗಳನ್ನು ರಚಿಸಲು ಒಂದು ಭರವಸೆಯ ಮಾರ್ಗವಾಗಿ ಮೈಕ್ರೋಸರ್ವಿಸ್ ಪರಿಕಲ್ಪನೆಯನ್ನು ವ್ಯಾಪಕವಾಗಿ ಚರ್ಚಿಸಲಾಗಿದೆ ಮತ್ತು Twitter, Facebook, Google ಮತ್ತು Netflix ನಂತಹ ಕಂಪನಿಗಳಲ್ಲಿ ಅನ್ವಯಿಸಲಾಗಿದೆ. ಸಾಮಾನ್ಯ ಗ್ರಹಿಕೆ - ಕನಿಷ್ಠ ನಾನು ಸಂಪರ್ಕದಲ್ಲಿರುವ ಉದ್ಯಮದ ಭಾಗಗಳಲ್ಲಿ - ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳು ದೊಡ್ಡ ವ್ಯವಸ್ಥೆಗಳನ್ನು ನಿರ್ಮಿಸಲು "ಸರಿಯಾದ ಮಾರ್ಗವಾಗಿದೆ", ಅದು ಕಠಿಣವಾಗಿದ್ದರೂ ಸಹ.
ಸಹಜವಾಗಿ, ಹತ್ತು ವರ್ಷಗಳ ಹಿಂದೆ ಮೈಕ್ರೊ ಸರ್ವಿಸ್‌ಗಳನ್ನು ಬಳಸಿಕೊಳ್ಳುವ ಕಂಪನಿಗಳು ಇದ್ದರೂ, ಅವರು ಸೇವಾ ಜಾಲರಿಯನ್ನು ರೂಪಿಸಲು ಸಾಧ್ಯವಿರುವಲ್ಲೆಲ್ಲಾ ಪ್ರಾಕ್ಸಿಗಳನ್ನು ಅಂಟಿಸಲಿಲ್ಲ. ಆದಾಗ್ಯೂ, ನೀವು ಹತ್ತಿರದಿಂದ ನೋಡಿದರೆ, ಅವರು ಇದೇ ರೀತಿಯದ್ದನ್ನು ಮಾಡಿದ್ದಾರೆ: ಈ ಕಂಪನಿಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವು ನೆಟ್‌ವರ್ಕಿಂಗ್‌ಗಾಗಿ ವಿಶೇಷ ಆಂತರಿಕ ಗ್ರಂಥಾಲಯದ ಬಳಕೆಯನ್ನು ಕಡ್ಡಾಯಗೊಳಿಸಿದವು (ಕೆಲವೊಮ್ಮೆ ಫ್ಯಾಟ್ ಕ್ಲೈಂಟ್ ಲೈಬ್ರರಿ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ, ಕೊಬ್ಬಿನ ಕ್ಲೈಂಟ್ ಲೈಬ್ರರಿ).
ನೆಟ್‌ಫ್ಲಿಕ್ಸ್‌ನಲ್ಲಿ ಹಿಸ್ಟರಿಕ್ಸ್, ಗೂಗಲ್ ಸ್ಟಬ್ಬಿ, ಟ್ವಿಟರ್ ಫಿನಾಗಲ್ ಲೈಬ್ರರಿಯನ್ನು ಹೊಂದಿದ್ದವು. ಉದಾಹರಣೆಗೆ, Twitter ನಲ್ಲಿನ ಪ್ರತಿಯೊಂದು ಹೊಸ ಸೇವೆಗೆ Finagle ಕಡ್ಡಾಯವಾಗಿದೆ. ಇದು ಸಂಪರ್ಕಗಳ ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್ ಸೈಡ್ ಎರಡನ್ನೂ ನಿರ್ವಹಿಸುತ್ತದೆ, ಪುನರಾವರ್ತಿತ ವಿನಂತಿಗಳು, ಬೆಂಬಲಿತ ವಿನಂತಿಯ ರೂಟಿಂಗ್, ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ಮತ್ತು ಮೀಟರಿಂಗ್ ಅನ್ನು ಅನುಮತಿಸಲಾಗಿದೆ. ಸೇವೆಯು ಏನು ಮಾಡುತ್ತಿದ್ದರೂ ಅದು ಸಂಪೂರ್ಣ ಟ್ವಿಟರ್ ಸ್ಟಾಕ್‌ನಾದ್ಯಂತ ವಿಶ್ವಾಸಾರ್ಹತೆ ಮತ್ತು ವೀಕ್ಷಣೆಯ ಸ್ಥಿರವಾದ ಪದರವನ್ನು ಒದಗಿಸಿದೆ. ಸಹಜವಾಗಿ, ಇದು JVM ಭಾಷೆಗಳಿಗೆ ಮಾತ್ರ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಸಂಪೂರ್ಣ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಬಳಸಬೇಕಾದ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಮಾದರಿಯನ್ನು ಆಧರಿಸಿದೆ. ಆದಾಗ್ಯೂ, ಅದರ ಕಾರ್ಯಚಟುವಟಿಕೆಯು ಸೇವಾ ಜಾಲರಿಯಂತೆಯೇ ಇರುತ್ತದೆ. (ವಾಸ್ತವವಾಗಿ, ಲಿಂಕರ್ಡ್‌ನ ಮೊದಲ ಆವೃತ್ತಿಯು ಪ್ರಾಕ್ಸಿ ರೂಪದಲ್ಲಿ ಸುತ್ತುವ ಫಿನಾಗಲ್ ಆಗಿತ್ತು.)
ಹೀಗಾಗಿ, ಹತ್ತು ವರ್ಷಗಳ ಹಿಂದೆ ಮೈಕ್ರೊ ಸರ್ವಿಸ್‌ಗಳು ಮಾತ್ರವಲ್ಲದೆ ವಿಶೇಷ ಪ್ರೊಟೊ-ಸರ್ವೀಸ್-ಮೆಶ್ ಲೈಬ್ರರಿಗಳೂ ಇದ್ದವು, ಅದು ಇಂದು ಸೇವಾ ಜಾಲರಿ ಪರಿಹರಿಸುವ ಅದೇ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ. ಆದರೆ, ಸೇವಾ ಜಾಲರಿಯೇ ಆಗ ಇರಲಿಲ್ಲ. ಅವಳು ಕಾಣಿಸಿಕೊಳ್ಳುವ ಮೊದಲು ಮತ್ತೊಂದು ಶಿಫ್ಟ್ ಆಗಬೇಕಿತ್ತು.
ಮತ್ತು ಇಲ್ಲಿ ಆಳವಾದ ಉತ್ತರವು ಅಡಗಿದೆ, ಕಳೆದ 10 ವರ್ಷಗಳಲ್ಲಿ ಸಂಭವಿಸಿದ ಮತ್ತೊಂದು ಬದಲಾವಣೆಯಲ್ಲಿ ಮರೆಮಾಡಲಾಗಿದೆ: ಮೈಕ್ರೋಸರ್ವಿಸ್ಗಳನ್ನು ನಿಯೋಜಿಸುವ ವೆಚ್ಚದಲ್ಲಿ ತೀವ್ರ ಕುಸಿತ ಕಂಡುಬಂದಿದೆ. ಒಂದು ದಶಕದ ಹಿಂದೆ ಮೈಕ್ರೋಸರ್ವಿಸ್ಗಳನ್ನು ಬಳಸಿದ ಮೇಲೆ ತಿಳಿಸಿದ ಕಂಪನಿಗಳು-ಟ್ವಿಟರ್, ನೆಟ್‌ಫ್ಲಿಕ್ಸ್, ಫೇಸ್‌ಬುಕ್, ಗೂಗಲ್-ಬೃಹತ್ ಪ್ರಮಾಣದ ಮತ್ತು ಬೃಹತ್ ಸಂಪನ್ಮೂಲಗಳ ಕಂಪನಿಗಳಾಗಿವೆ. ಅವರು ಕೇವಲ ಅಗತ್ಯವನ್ನು ಹೊಂದಿರಲಿಲ್ಲ, ಆದರೆ ಮೈಕ್ರೊ ಸರ್ವೀಸ್‌ಗಳ ಆಧಾರದ ಮೇಲೆ ದೊಡ್ಡ ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ನಿರ್ಮಿಸುವ, ನಿಯೋಜಿಸುವ ಮತ್ತು ನಿರ್ವಹಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಸಹ ಹೊಂದಿದ್ದರು. ಟ್ವಿಟರ್ ಎಂಜಿನಿಯರ್‌ಗಳು ಏಕಶಿಲೆಯಿಂದ ಮೈಕ್ರೋಸರ್ವೀಸ್ ವಿಧಾನಕ್ಕೆ ಚಲಿಸಲು ಮಾಡಿದ ಶಕ್ತಿ ಮತ್ತು ಶ್ರಮ ಅದ್ಭುತವಾಗಿದೆ. (ಪ್ರಾಮಾಣಿಕವಾಗಿ, ಅದು ಕೆಲಸ ಮಾಡಿದೆ.) ಈ ರೀತಿಯ ಮೂಲಸೌಕರ್ಯ ಕುಶಲತೆಯು ಆಗ ಸಣ್ಣ ಕಂಪನಿಗಳಿಗೆ ಅಸಾಧ್ಯವಾಗಿತ್ತು.
ವರ್ತಮಾನಕ್ಕೆ ಹೋಗೋಣ. ಇಂದು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳ ಅನುಪಾತವು 5:1 ಆಗಿರುವ ಸ್ಟಾರ್ಟ್‌ಅಪ್‌ಗಳಿವೆ (ಅಥವಾ ಸಹ ), ಮತ್ತು ಮೇಲಾಗಿ, ಅವರು ಅವುಗಳನ್ನು ಯಶಸ್ವಿಯಾಗಿ ನಿಭಾಯಿಸುತ್ತಾರೆ! 5 ಜನರ ಪ್ರಾರಂಭವು 50 ಮೈಕ್ರೊ ಸರ್ವಿಸ್‌ಗಳನ್ನು ಆಯಾಸವಿಲ್ಲದೆ ನಿರ್ವಹಿಸಲು ಸಾಧ್ಯವಾದರೆ, ಅವರ ಅನುಷ್ಠಾನದ ವೆಚ್ಚವನ್ನು ಏನಾದರೂ ಸ್ಪಷ್ಟವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.
ಮೊಂಜೊದಲ್ಲಿ 1500 ಸೂಕ್ಷ್ಮ ಸೇವೆಗಳು; ಪ್ರತಿ ಸಾಲು ಸಂಚಾರವನ್ನು ಅನುಮತಿಸುವ ಒಂದು ನಿಗದಿತ ನೆಟ್‌ವರ್ಕ್ ನಿಯಮವಾಗಿದೆ
ಮೈಕ್ರೊ ಸರ್ವೀಸ್‌ಗಳ ಕಾರ್ಯಾಚರಣೆಯ ವೆಚ್ಚದಲ್ಲಿ ನಾಟಕೀಯ ಕಡಿತವು ಒಂದೇ ಪ್ರಕ್ರಿಯೆಯ ಫಲಿತಾಂಶವಾಗಿದೆ: ಧಾರಕಗಳ ಜನಪ್ರಿಯತೆ ಹೆಚ್ಚುತ್ತಿದೆ и ವಾದ್ಯವೃಂದದವರು. ಸೇವಾ ಜಾಲರಿಯ ಹೊರಹೊಮ್ಮುವಿಕೆಗೆ ಏನು ಕೊಡುಗೆ ನೀಡಿದೆ ಎಂಬ ಪ್ರಶ್ನೆಗೆ ಇದು ನಿಖರವಾಗಿ ಆಳವಾದ ಉತ್ತರವಾಗಿದೆ. ಅದೇ ತಂತ್ರಜ್ಞಾನವು ಸೇವಾ ಜಾಲರಿ ಮತ್ತು ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ಎರಡನ್ನೂ ಆಕರ್ಷಕವಾಗಿಸಿದೆ: ಕುಬರ್ನೆಟ್ಸ್ ಮತ್ತು ಡಾಕರ್.
ಏಕೆ? ಸರಿ, ಡಾಕರ್ ಒಂದು ದೊಡ್ಡ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತಾನೆ - ಪ್ಯಾಕೇಜಿಂಗ್ ಸಮಸ್ಯೆ. ಕಂಟೇನರ್‌ನಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಅದರ (ನೆಟ್‌ವರ್ಕ್ ಅಲ್ಲದ) ರನ್‌ಟೈಮ್ ಅವಲಂಬನೆಗಳನ್ನು ಪ್ಯಾಕೇಜಿಂಗ್ ಮಾಡುವ ಮೂಲಕ, ಡಾಕರ್ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಫಂಗಬಲ್ ಯೂನಿಟ್ ಆಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಎಲ್ಲಿಯಾದರೂ ಹೋಸ್ಟ್ ಮಾಡಬಹುದು ಮತ್ತು ರನ್ ಮಾಡಬಹುದು. ಅದೇ ಸಮಯದಲ್ಲಿ, ಇದು ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಹೆಚ್ಚು ಸರಳಗೊಳಿಸುತ್ತದೆ. ಬಹುಭಾಷಾ ಸ್ಟ್ಯಾಕ್: ಕಂಟೇನರ್ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯ ಪರಮಾಣು ಘಟಕವಾಗಿರುವುದರಿಂದ, ಅದು JVM, ನೋಡ್, ಗೋ, ಪೈಥಾನ್ ಅಥವಾ ರೂಬಿ ಅಪ್ಲಿಕೇಶನ್ ಆಗಿರಲಿ, ನಿಯೋಜನೆ ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಯ ಉದ್ದೇಶಗಳಿಗಾಗಿ ಒಳಗೆ ಏನಿದೆ ಎಂಬುದು ಮುಖ್ಯವಲ್ಲ. ನೀವು ಅದನ್ನು ಚಲಾಯಿಸಿ ಮತ್ತು ಅಷ್ಟೆ.
ಕುಬರ್ನೆಟ್ಸ್ ಎಲ್ಲವನ್ನೂ ಮುಂದಿನ ಹಂತಕ್ಕೆ ಕೊಂಡೊಯ್ಯುತ್ತಾನೆ. ಈಗ "ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ವಸ್ತುಗಳು" ಮತ್ತು ಅವುಗಳನ್ನು ಚಲಾಯಿಸಲು ಅನೇಕ ಯಂತ್ರಗಳು ಇವೆ, ಅವುಗಳನ್ನು ಪರಸ್ಪರ ಹೊಂದಿಸುವ ಸಾಧನದ ಅವಶ್ಯಕತೆಯಿದೆ. ವಿಶಾಲ ಅರ್ಥದಲ್ಲಿ, ನೀವು ಕುಬರ್ನೆಟ್ಸ್ಗೆ ಅನೇಕ ಕಂಟೈನರ್‌ಗಳು ಮತ್ತು ಅನೇಕ ಯಂತ್ರಗಳನ್ನು ನೀಡುತ್ತೀರಿ ಮತ್ತು ಅದು ಅವುಗಳನ್ನು ಪರಸ್ಪರ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ (ಸಹಜವಾಗಿ, ಇದು ಕ್ರಿಯಾತ್ಮಕ ಮತ್ತು ನಿರಂತರವಾಗಿ ಬದಲಾಗುವ ಪ್ರಕ್ರಿಯೆ: ಹೊಸ ಕಂಟೇನರ್‌ಗಳು ಸಿಸ್ಟಮ್‌ನ ಸುತ್ತಲೂ ಚಲಿಸುತ್ತವೆ, ಯಂತ್ರಗಳು ಪ್ರಾರಂಭವಾಗುತ್ತವೆ ಮತ್ತು ನಿಲ್ಲಿಸುತ್ತವೆ, ಇತ್ಯಾದಿ. ಕುಬರ್ನೆಟ್ಸ್ ಇದನ್ನೆಲ್ಲ ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುತ್ತಾನೆ ).
ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿದ ನಂತರ, ಒಂದು ಸೇವೆಯನ್ನು ನಿಯೋಜಿಸಲು ಮತ್ತು ನಿರ್ವಹಿಸಲು ತೆಗೆದುಕೊಳ್ಳುವ ಸಮಯವು ಹತ್ತು ಸೇವೆಗಳನ್ನು ನಿಯೋಜಿಸಲು ಮತ್ತು ನಿರ್ವಹಿಸುವ ವೆಚ್ಚಕ್ಕಿಂತ ಹೆಚ್ಚು ಭಿನ್ನವಾಗಿರುವುದಿಲ್ಲ (ವಾಸ್ತವವಾಗಿ, ಇದು 100 ಸೇವೆಗಳಿಗೆ ಬಹುತೇಕ ಒಂದೇ ಆಗಿರುತ್ತದೆ). ಬಹುಭಾಷಾ ಅನುಷ್ಠಾನವನ್ನು ಪ್ರೋತ್ಸಾಹಿಸುವ ಪ್ಯಾಕೇಜಿಂಗ್ ಕಾರ್ಯವಿಧಾನವಾಗಿ ಈ ಕಂಟೇನರ್‌ಗಳಿಗೆ ಸೇರಿಸಿ ಮತ್ತು ನೀವು ಹಲವಾರು ಭಾಷೆಗಳಲ್ಲಿ ಮೈಕ್ರೊ ಸರ್ವಿಸ್‌ಗಳಾಗಿ ಅಳವಡಿಸಲಾಗಿರುವ ಹಲವಾರು ಹೊಸ ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ಹೊಂದಿರುವಿರಿ, ಸೇವಾ ಜಾಲರಿಯು ಎಷ್ಟು ಚೆನ್ನಾಗಿ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆಯೋ ಅಂತಹ ಪರಿಸರಕ್ಕೆ.
ಆದ್ದರಿಂದ, ಸೇವಾ ಜಾಲರಿಯ ಕಲ್ಪನೆಯು ಇದೀಗ ಏಕೆ ಜನಪ್ರಿಯವಾಗಿದೆ ಎಂಬ ಪ್ರಶ್ನೆಗೆ ನಾವು ಉತ್ತರಕ್ಕೆ ಬರುತ್ತೇವೆ: ಸೇವೆಗಳಿಗಾಗಿ ಕುಬರ್ನೆಟ್ಸ್ ಒದಗಿಸುವ ಏಕರೂಪತೆಯು ಸೇವಾ ಜಾಲರಿಯನ್ನು ಎದುರಿಸುತ್ತಿರುವ ಕಾರ್ಯಾಚರಣೆಯ ಕಾರ್ಯಗಳಿಗೆ ನೇರವಾಗಿ ಅನ್ವಯಿಸುತ್ತದೆ. ನೀವು ಕಂಟೈನರ್‌ಗಳಲ್ಲಿ ಪ್ರಾಕ್ಸಿಗಳನ್ನು ಪ್ಯಾಕೇಜ್ ಮಾಡಿ, ಕುಬರ್ನೆಟ್‌ಗಳಿಗೆ ಅವುಗಳನ್ನು ಎಲ್ಲಿ ಸಾಧ್ಯವೋ ಅಲ್ಲಿ ಅಂಟಿಸುವ ಕೆಲಸವನ್ನು ನೀಡಿ ಮತ್ತು ವೊಯ್ಲಾ! ಪರಿಣಾಮವಾಗಿ, ನೀವು ಸೇವಾ ಜಾಲರಿಯನ್ನು ಪಡೆಯುತ್ತೀರಿ, ಆದರೆ ಕುಬರ್ನೆಟ್ಸ್ ಅದರ ನಿಯೋಜನೆಯ ಎಲ್ಲಾ ಯಂತ್ರಶಾಸ್ತ್ರವನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ. (ಕನಿಷ್ಠ ಪಕ್ಷಿನೋಟದಿಂದ. ಸಹಜವಾಗಿ, ಈ ಪ್ರಕ್ರಿಯೆಗೆ ಹಲವು ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳಿವೆ.)
ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಹೇಳುವುದಾದರೆ: ಸೇವಾ ಜಾಲರಿಯು ಈಗ ಜನಪ್ರಿಯವಾಗಲು ಕಾರಣ ಮತ್ತು ಹತ್ತು ವರ್ಷಗಳ ಹಿಂದೆ ಅಲ್ಲ, ಕುಬರ್ನೆಟ್ಸ್ ಮತ್ತು ಡಾಕರ್ ಗಮನಾರ್ಹವಾಗಿ ಹೆಚ್ಚಾಗಲಿಲ್ಲ. ಅಗತ್ಯವಿದೆ ಅದರಲ್ಲಿ, ಬಹುಭಾಷಾ ಸೂಕ್ಷ್ಮ ಸೇವೆಗಳ ಸೆಟ್‌ಗಳಾಗಿ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಅನುಷ್ಠಾನವನ್ನು ಸರಳಗೊಳಿಸುತ್ತದೆ, ಆದರೆ ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆಯಾಗಿದೆ ವೆಚ್ಚವಾಗುತ್ತದೆ ಸೈಡ್ಕಾರ್ ಪ್ರಾಕ್ಸಿ ಪಾರ್ಕ್‌ಗಳನ್ನು ನಿಯೋಜಿಸಲು ಮತ್ತು ನಿರ್ವಹಿಸಲು ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಒದಗಿಸುವ ಮೂಲಕ ಅದರ ಕಾರ್ಯಾಚರಣೆಗಾಗಿ.
ಸೇವಾ ಜಾಲರಿಯ ಬಗ್ಗೆ ಏಕೆ ಹೆಚ್ಚು ಚರ್ಚೆ?
ತಡೆಗಟ್ಟುವಿಕೆ: ಈ ವಿಭಾಗದಲ್ಲಿ, ನಾನು ಎಲ್ಲಾ ರೀತಿಯ ಊಹೆಗಳು, ಊಹೆಗಳು, ಕಟ್ಟುಕತೆಗಳು ಮತ್ತು ಆಂತರಿಕ ಮಾಹಿತಿಯನ್ನು ಆಶ್ರಯಿಸುತ್ತೇನೆ.
"ಸೇವಾ ಜಾಲರಿ" ಗಾಗಿ ಹುಡುಕುವುದರಿಂದ ಮರುಬಳಕೆಯ, ಕಡಿಮೆ-ಕ್ಯಾಲೋರಿ ವಿಷಯ, ಬೆಸ ಯೋಜನೆಗಳು ಮತ್ತು ಪ್ರತಿಧ್ವನಿ ಚೇಂಬರ್‌ಗೆ ಯೋಗ್ಯವಾದ ಅಸ್ಪಷ್ಟತೆಯ ಕೆಲಿಡೋಸ್ಕೋಪ್ ಸಂಗ್ರಹವಾಗುತ್ತದೆ. ಯಾವುದೇ ಟ್ರೆಂಡಿ ಹೊಸ ತಂತ್ರಜ್ಞಾನವು ಇದನ್ನು ಹೊಂದಿದೆ, ಆದರೆ ಸೇವಾ ಜಾಲರಿಯ ಸಂದರ್ಭದಲ್ಲಿ, ಸಮಸ್ಯೆ ವಿಶೇಷವಾಗಿ ತೀವ್ರವಾಗಿರುತ್ತದೆ. ಏಕೆ?
ಸರಿ, ಇದು ಭಾಗಶಃ ನನ್ನ ತಪ್ಪು. ಈ ರೀತಿಯ ಅಸಂಖ್ಯಾತ ಬ್ಲಾಗ್ ಪೋಸ್ಟ್‌ಗಳು ಮತ್ತು ಲೇಖನಗಳ ಮೂಲಕ ನಾನು ಲಿಂಕರ್ಡ್ ಮತ್ತು ಸರ್ವಿಸ್ ಮೆಶ್ ಅನ್ನು ಪ್ರತಿ ಅವಕಾಶದಲ್ಲೂ ಪ್ರಚಾರ ಮಾಡಲು ನನ್ನ ಕೈಲಾದಷ್ಟು ಮಾಡಿದ್ದೇನೆ. ಆದರೆ ನಾನು ಅಷ್ಟು ಶಕ್ತಿವಂತನಲ್ಲ. ಈ ಪ್ರಶ್ನೆಗೆ ನಿಜವಾಗಿಯೂ ಉತ್ತರಿಸಲು, ನಾವು ಸಾಮಾನ್ಯ ಪರಿಸ್ಥಿತಿಯ ಬಗ್ಗೆ ಸ್ವಲ್ಪ ಮಾತನಾಡಬೇಕು. ಮತ್ತು ಒಂದು ಯೋಜನೆಯನ್ನು ಉಲ್ಲೇಖಿಸದೆ ಅದರ ಬಗ್ಗೆ ಮಾತನಾಡುವುದು ಅಸಾಧ್ಯ: Google, IBM ಮತ್ತು Lyft ಜಂಟಿಯಾಗಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ ಮುಕ್ತ ಮೂಲ ಸೇವಾ ಜಾಲರಿಯಾಗಿದೆ.
(ಆ ಮೂರು ಕಂಪನಿಗಳು ವಿಭಿನ್ನವಾದ ಪಾತ್ರಗಳನ್ನು ಹೊಂದಿವೆ: ಲಿಫ್ಟ್‌ನ ಒಳಗೊಳ್ಳುವಿಕೆಯು ಹೆಸರಿಗೆ ಮಾತ್ರ ಸೀಮಿತವಾಗಿದೆ ಎಂದು ತೋರುತ್ತದೆ; ಅವರು ಎನ್ವಾಯ್ ಅನ್ನು ಬರೆದಿದ್ದಾರೆ ಆದರೆ ಇಸ್ಟಿಯೊವನ್ನು ಬಳಸುವುದಿಲ್ಲ ಅಥವಾ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಿದ್ದಾರೆ. IBM ಇಸ್ಟಿಯೊ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಿದೆ ಮತ್ತು ಅದನ್ನು ಬಳಸುತ್ತದೆ. ಗೂಗಲ್ ಹೆಚ್ಚು ಇಸ್ಟಿಯೊ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಿದೆ, ಆದರೆ ನಾನು ಹೇಳಬಹುದಾದಷ್ಟು, ನಿಜವಾಗಿ ಅದನ್ನು ಬಳಸುವುದಿಲ್ಲ.)
ಇಸ್ಟಿಯೊ ಯೋಜನೆಯು ಎರಡು ವಿಷಯಗಳಿಗೆ ಗಮನಾರ್ಹವಾಗಿದೆ. ಮೊದಲನೆಯದಾಗಿ, ಇದು ಗೂಗಲ್, ನಿರ್ದಿಷ್ಟವಾಗಿ, ಅದರ ಪ್ರಚಾರಕ್ಕೆ ಹಾಕುವ ದೊಡ್ಡ ಮಾರ್ಕೆಟಿಂಗ್ ಪ್ರಯತ್ನವಾಗಿದೆ. ಸೇವಾ ಜಾಲರಿ ಪರಿಕಲ್ಪನೆಯ ಬಗ್ಗೆ ಪ್ರಸ್ತುತ ತಿಳಿದಿರುವ ಹೆಚ್ಚಿನ ಜನರು ಅದರ ಬಗ್ಗೆ ಮೊದಲು ಕಲಿತಿದ್ದು ಇಸ್ಟಿಯೊಗೆ ಧನ್ಯವಾದಗಳು ಎಂದು ನಾನು ಅಂದಾಜು ಮಾಡುತ್ತೇನೆ. ಎರಡನೆಯ ವೈಶಿಷ್ಟ್ಯವೆಂದರೆ ಇಸ್ಟಿಯೊವನ್ನು ಎಷ್ಟು ಕೆಟ್ಟದಾಗಿ ಸ್ವೀಕರಿಸಲಾಗಿದೆ. ಈ ವಿಷಯದಲ್ಲಿ, ನಾನು, ನಿಸ್ಸಂಶಯವಾಗಿ, ಆಸಕ್ತ ಪಕ್ಷ, ಆದರೆ ಸಾಧ್ಯವಾದಷ್ಟು ವಸ್ತುನಿಷ್ಠವಾಗಿ ಉಳಿಯಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೇನೆ, ನಾನು ಇನ್ನೂ ಸಹಾಯ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ ಆದರೆ , ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟವಾಗಿಲ್ಲ (ಆದರೂ ಅನನ್ಯವಾಗಿಲ್ಲ: systemd ಮನಸ್ಸಿಗೆ ಬರುತ್ತದೆ, ...) ಓಪನ್ ಸೋರ್ಸ್ ಯೋಜನೆಗಾಗಿ.
(ಆಚರಣೆಯಲ್ಲಿ, ಇಸ್ಟಿಯೊಗೆ ಸಂಕೀರ್ಣತೆ ಮತ್ತು UX ನೊಂದಿಗೆ ಮಾತ್ರವಲ್ಲದೆ ಕಾರ್ಯಕ್ಷಮತೆಯೊಂದಿಗೆ ಸಮಸ್ಯೆಗಳಿವೆ ಎಂದು ತೋರುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಸಮಯದಲ್ಲಿ ಮೂರನೇ ವ್ಯಕ್ತಿಯಿಂದ ನಡೆಸಲ್ಪಟ್ಟ, ತಜ್ಞರು ಲಿಂಕರ್ಡ್‌ಗಿಂತ 100 ಪಟ್ಟು ಹೆಚ್ಚು ಇಸ್ಟಿಯೊದ ಬಾಲದ ಸುಪ್ತತೆಯನ್ನು ಕಂಡುಕೊಂಡರು, ಹಾಗೆಯೇ ಸಂಪನ್ಮೂಲಗಳ ಕೊರತೆಯ ಸಂದರ್ಭಗಳು, ಲಿಂಕರ್ಡ್ ಯಶಸ್ವಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದನ್ನು ಮುಂದುವರೆಸಿದಾಗ ಮತ್ತು ಇಸ್ಟಿಯೊ ಸಂಪೂರ್ಣವಾಗಿ ಕೆಲಸ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸಿದರು.)
ಇದು ಏಕೆ ಸಂಭವಿಸಿತು ಎಂಬುದರ ಕುರಿತು ನನ್ನ ಸಿದ್ಧಾಂತಗಳನ್ನು ಬದಿಗಿಟ್ಟು, ಸೇವೆಯ ಜಾಲರಿಯ ಸುತ್ತಲಿನ ಆಫ್-ಸ್ಕೇಲ್ ಹೈಪ್ Google ನ ಒಳಗೊಳ್ಳುವಿಕೆಯಿಂದಾಗಿ ಎಂದು ನಾನು ನಂಬುತ್ತೇನೆ. ಅವುಗಳೆಂದರೆ, ಈ ಕೆಳಗಿನ ಮೂರು ಅಂಶಗಳ ಸಂಯೋಜನೆ:
- ಗೂಗಲ್‌ನಿಂದ ಇಸ್ಟಿಯೊದ ಒಬ್ಸೆಸಿವ್ ಪ್ರಚಾರ;
- ಯೋಜನೆಯ ಬಗ್ಗೆ ಸೂಕ್ತ ಅಸಮ್ಮತಿ, ವಿಮರ್ಶಾತ್ಮಕ ವರ್ತನೆ;
- ಕುಬರ್ನೆಟ್ಸ್‌ನ ಇತ್ತೀಚಿನ ಜನಪ್ರಿಯತೆ ಗಗನಕ್ಕೇರಿದೆ, ಅದರ ನೆನಪು ಇನ್ನೂ ತಾಜಾವಾಗಿದೆ.
ಒಟ್ಟಿನಲ್ಲಿ, ಈ ಅಂಶಗಳು ಒಂದು ರೀತಿಯ ಅಮಲೇರಿದ, ಅನಾಕ್ಸಿಕ್ ಪರಿಸರಕ್ಕೆ ಸೇರಿಕೊಳ್ಳುತ್ತವೆ, ಇದರಲ್ಲಿ ತರ್ಕಬದ್ಧ ತೀರ್ಪಿನ ಸಾಮರ್ಥ್ಯವು ದುರ್ಬಲಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಅದ್ಭುತವಾದ ವೈವಿಧ್ಯತೆ ಮಾತ್ರ ಉಳಿದಿದೆ. .
ಲಿಂಕರ್ಡ್ ಅವರ ದೃಷ್ಟಿಕೋನದಿಂದ, ಇದು... ನಾನು ಇದನ್ನು ಮಿಶ್ರ ಆಶೀರ್ವಾದ ಎಂದು ವಿವರಿಸುತ್ತೇನೆ. ನನ್ನ ಪ್ರಕಾರ, ಸೇವಾ ಜಾಲರಿಯು ಮುಖ್ಯವಾಹಿನಿಗೆ ಪ್ರವೇಶಿಸಿರುವುದು ಅದ್ಭುತವಾಗಿದೆ - 2016 ರಲ್ಲಿ ಲಿಂಕರ್ಡ್ ಮೊದಲು ಕಾಣಿಸಿಕೊಂಡಾಗ ಅದು ಇರಲಿಲ್ಲ ಮತ್ತು ಯೋಜನೆಯಲ್ಲಿ ಜನರ ಗಮನವನ್ನು ಸೆಳೆಯುವುದು ನಿಜವಾಗಿಯೂ ಕಷ್ಟಕರವಾಗಿತ್ತು. ಈಗ ಅಂತಹ ಸಮಸ್ಯೆ ಇಲ್ಲ! ಆದರೆ ಕೆಟ್ಟ ಸುದ್ದಿ ಏನೆಂದರೆ, ಸೇವೆಯ ಜಾಲರಿಯ ಪರಿಸ್ಥಿತಿಯು ಇಂದು ಎಷ್ಟು ಗೊಂದಲಮಯವಾಗಿದೆಯೆಂದರೆ, ಯಾವ ಯೋಜನೆಗಳು ನಿಜವಾಗಿಯೂ ಸೇವಾ ಜಾಲರಿ ವರ್ಗಕ್ಕೆ ಸೇರಿವೆ ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಅಸಾಧ್ಯವಾಗಿದೆ (ನಿರ್ದಿಷ್ಟ ಬಳಕೆಯ ಸಂದರ್ಭದಲ್ಲಿ ಯಾವುದು ಉತ್ತಮ ಎಂದು ಲೆಕ್ಕಾಚಾರ ಮಾಡೋಣ). ಇದು ನಿಸ್ಸಂಶಯವಾಗಿ ಪ್ರತಿಯೊಬ್ಬರ ಮಾರ್ಗವನ್ನು ಪಡೆಯುತ್ತದೆ (ಮತ್ತು ಖಂಡಿತವಾಗಿಯೂ ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ ಇಸ್ಟಿಯೊ ಅಥವಾ ಇನ್ನೊಂದು ಯೋಜನೆಯು ಲಿಂಕರ್ಡ್‌ಗಿಂತ ಉತ್ತಮವಾಗಿದೆ, ಏಕೆಂದರೆ ಎರಡನೆಯದು ಒಂದೇ-ಗಾತ್ರ-ಫಿಟ್ಸ್-ಎಲ್ಲಾ ಪರಿಹಾರವಲ್ಲ).
ಲಿಂಕರ್ಡ್‌ನ ಕಡೆಯಿಂದ, ಶಬ್ದವನ್ನು ನಿರ್ಲಕ್ಷಿಸುವುದು, ಸಮುದಾಯದಲ್ಲಿನ ನೈಜ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುವತ್ತ ಗಮನ ಹರಿಸುವುದು ಮತ್ತು ಪ್ರಚೋದನೆಯು ಸಾಯುವವರೆಗೆ ಕಾಯುವುದು ನಮ್ಮ ಕಾರ್ಯತಂತ್ರವಾಗಿದೆ. ಅಂತಿಮವಾಗಿ ಪ್ರಚಾರವು ಕಡಿಮೆಯಾಗುತ್ತದೆ ಮತ್ತು ನಾವು ಶಾಂತಿಯಿಂದ ಕೆಲಸ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸಬಹುದು.
ಅಲ್ಲಿಯವರೆಗೆ ನಾವೆಲ್ಲರೂ ತಾಳ್ಮೆಯಿಂದಿರಬೇಕು.
ಸಾಧಾರಣ ಸಾಫ್ಟ್‌ವೇರ್ ಇಂಜಿನಿಯರ್ ಆಗಿರುವ ನನಗೆ ಸರ್ವೀಸ್ ಮೆಶ್ ಉಪಯುಕ್ತವಾಗುತ್ತದೆಯೇ?
ಕೆಳಗಿನ ಪ್ರಶ್ನಾವಳಿ ಈ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ:
ವ್ಯಾಪಾರ ತರ್ಕದ ಅನುಷ್ಠಾನದೊಂದಿಗೆ ನೀವು ಪ್ರತ್ಯೇಕವಾಗಿ ವ್ಯವಹರಿಸುತ್ತೀರಾ? ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಸೇವಾ ಜಾಲರಿಯು ನಿಮಗೆ ಉಪಯುಕ್ತವಾಗುವುದಿಲ್ಲ. ಅಂದರೆ, ಸಹಜವಾಗಿ, ನೀವು ಅದರಲ್ಲಿ ಆಸಕ್ತಿ ಹೊಂದಿರಬಹುದು, ಆದರೆ ಆದರ್ಶಪ್ರಾಯವಾಗಿ, ಸೇವಾ ಜಾಲರಿಯು ನಿಮ್ಮ ಪರಿಸರದಲ್ಲಿ ನೇರವಾಗಿ ಏನನ್ನೂ ಪರಿಣಾಮ ಬೀರಬಾರದು. ನೀವು ಪಾವತಿಸಿದ್ದಕ್ಕಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತಿರಿ.
ಕುಬರ್ನೆಟ್ಸ್ ಬಳಸುವ ಕಂಪನಿಯಲ್ಲಿ ನೀವು ವೇದಿಕೆಯನ್ನು ನಿರ್ವಹಿಸುತ್ತೀರಾ? ಹೌದು, ಈ ಸಂದರ್ಭದಲ್ಲಿ ನಿಮಗೆ ಸೇವಾ ಜಾಲರಿ ಅಗತ್ಯವಿದೆ (ಸಹಜವಾಗಿ, ನೀವು ಏಕಶಿಲೆ ಅಥವಾ ಬ್ಯಾಚ್ ಸಂಸ್ಕರಣೆಯನ್ನು ಚಲಾಯಿಸಲು K8 ಗಳನ್ನು ಬಳಸದಿದ್ದರೆ - ಆದರೆ ನಿಮಗೆ K8 ಗಳು ಏಕೆ ಬೇಕು ಎಂದು ನಾನು ಕೇಳಲು ಬಯಸುತ್ತೇನೆ). ಹೆಚ್ಚಾಗಿ, ವಿಭಿನ್ನ ಜನರು ಬರೆದ ಅನೇಕ ಮೈಕ್ರೋಸರ್ವಿಸ್ಗಳೊಂದಿಗೆ ನೀವು ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ನಿಮ್ಮನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತೀರಿ. ಅವರೆಲ್ಲರೂ ಪರಸ್ಪರ ಸಂವಹನ ನಡೆಸುತ್ತಾರೆ ಮತ್ತು ರನ್‌ಟೈಮ್ ಅವಲಂಬನೆಗಳ ಗೋಜಲಿನೊಳಗೆ ಬಂಧಿಸಲ್ಪಟ್ಟಿದ್ದಾರೆ ಮತ್ತು ಈ ಎಲ್ಲವನ್ನು ಎದುರಿಸಲು ನೀವು ಒಂದು ಮಾರ್ಗವನ್ನು ಕಂಡುಹಿಡಿಯಬೇಕು. ಕುಬರ್ನೆಟ್ಸ್ ಬಳಕೆಯು "ನಿಮಗಾಗಿ" ಸೇವಾ ಜಾಲರಿಯನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಇದನ್ನು ಮಾಡಲು, ಅವರ ಸಾಮರ್ಥ್ಯಗಳು ಮತ್ತು ವೈಶಿಷ್ಟ್ಯಗಳೊಂದಿಗೆ ನೀವೇ ಪರಿಚಿತರಾಗಿ ಮತ್ತು ಲಭ್ಯವಿರುವ ಯಾವುದೇ ಯೋಜನೆಗಳು ನಿಮಗೆ ಸರಿಹೊಂದುತ್ತದೆಯೇ ಎಂಬ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸಿ (ಲಿಂಕರ್ಡ್ನೊಂದಿಗೆ ನಿಮ್ಮ ಸಂಶೋಧನೆಯನ್ನು ಪ್ರಾರಂಭಿಸಲು ನಾನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ).
ನೀವು ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಬಳಸದ ಆದರೆ ಮೈಕ್ರೋಸರ್ವಿಸ್ ಅನ್ನು ಬಳಸುವ ಕಂಪನಿಗಾಗಿ ವೇದಿಕೆಯನ್ನು ನಡೆಸುತ್ತಿರುವಿರಾ? ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಸೇವಾ ಜಾಲರಿಯು ನಿಮಗೆ ಉಪಯುಕ್ತವಾಗಿರುತ್ತದೆ, ಆದರೆ ಅದರ ಬಳಕೆಯು ಕ್ಷುಲ್ಲಕವಲ್ಲ. ಖಂಡಿತ ನೀವು ಮಾಡಬಹುದು ಅನುಕರಿಸುತ್ತಾರೆ ಪ್ರಾಕ್ಸಿಗಳ ಗುಂಪನ್ನು ಹೋಸ್ಟ್ ಮಾಡುವ ಮೂಲಕ ಸೇವಾ ಜಾಲರಿ, ಆದರೆ ಕುಬರ್ನೆಟ್ಸ್‌ನ ಪ್ರಮುಖ ಪ್ರಯೋಜನವೆಂದರೆ ನಿಖರವಾಗಿ ನಿಯೋಜನೆ ಮಾದರಿ: ಈ ಪ್ರಾಕ್ಸಿಗಳನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ನಿರ್ವಹಿಸಲು ಹೆಚ್ಚು ಸಮಯ, ಶ್ರಮ ಮತ್ತು ವೆಚ್ಚದ ಅಗತ್ಯವಿರುತ್ತದೆ.
ಏಕಶಿಲೆಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಕಂಪನಿಯಲ್ಲಿ ನೀವು ವೇದಿಕೆಯ ಉಸ್ತುವಾರಿ ವಹಿಸುತ್ತೀರಾ? ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನಿಮಗೆ ಬಹುಶಃ ಸೇವಾ ಜಾಲರಿ ಅಗತ್ಯವಿಲ್ಲ. ನೀವು ಏಕಶಿಲೆಗಳೊಂದಿಗೆ (ಅಥವಾ ಏಕಶಿಲೆಗಳ ಸೆಟ್‌ಗಳು) ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರೆ, ಅದು ಉತ್ತಮವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ಮತ್ತು ಅಪರೂಪವಾಗಿ ಬದಲಾಗುತ್ತಿರುವ ಪರಸ್ಪರ ಕ್ರಿಯೆಯ ಮಾದರಿಗಳನ್ನು ಹೊಂದಿದೆ, ಆಗ ಸೇವಾ ಜಾಲರಿಯು ನಿಮಗೆ ನೀಡಲು ಸ್ವಲ್ಪವೇ ಇಲ್ಲ. ಆದ್ದರಿಂದ ನೀವು ಅದನ್ನು ನಿರ್ಲಕ್ಷಿಸಬಹುದು ಮತ್ತು ಅದು ಕೆಟ್ಟ ಕನಸಿನಂತೆ ಕಣ್ಮರೆಯಾಗುತ್ತದೆ ಎಂದು ಭಾವಿಸಬಹುದು ...
ತೀರ್ಮಾನಕ್ಕೆ
ಬಹುಶಃ, ಸೇವಾ ಜಾಲರಿಯನ್ನು ಇನ್ನೂ "ವಿಶ್ವದ ಅತ್ಯಂತ ಪ್ರಚೋದಿತ ತಂತ್ರಜ್ಞಾನ" ಎಂದು ಕರೆಯಬಾರದು - ಈ ಸಂಶಯಾಸ್ಪದ ಗೌರವವು ಬಹುಶಃ ಬಿಟ್‌ಕಾಯಿನ್ ಅಥವಾ AI ಗೆ ಸೇರಿದೆ. ಬಹುಶಃ ಅವಳು ಮೊದಲ ಐದರಲ್ಲಿ ಇದ್ದಾಳೆ. ಆದರೆ ನೀವು ಶಬ್ದ ಮತ್ತು ಡಿನ್ನ ಪದರಗಳನ್ನು ಭೇದಿಸಿದರೆ, ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ರಚಿಸುವವರಿಗೆ ಸೇವಾ ಜಾಲರಿಯು ನಿಜವಾದ ಪ್ರಯೋಜನಗಳನ್ನು ತರುತ್ತದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ.
ನೀವು ಲಿಂಕರ್ಡ್ ಅನ್ನು ಪ್ರಯತ್ನಿಸಲು ನಾನು ಬಯಸುತ್ತೇನೆ - ಇದನ್ನು ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಸ್ಥಾಪಿಸುವುದು (ಅಥವಾ ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಲ್ಲಿ ಮಿನಿಕ್ಯೂಬ್ ಕೂಡ) ಮತ್ತು ನಾನು ಏನು ಮಾತನಾಡುತ್ತಿದ್ದೇನೆಂದು ನೀವೇ ನೋಡಬಹುದು.
FAQ
- ನಾನು ಸೇವಾ ಜಾಲರಿಯನ್ನು ನಿರ್ಲಕ್ಷಿಸಿದರೆ, ಅದು ಕಣ್ಮರೆಯಾಗುತ್ತದೆಯೇ?
- ನಾನು ನಿಮ್ಮನ್ನು ನಿರಾಶೆಗೊಳಿಸಬೇಕು: ಸೇವಾ ಜಾಲರಿಯು ನಮ್ಮೊಂದಿಗೆ ದೀರ್ಘಕಾಲದವರೆಗೆ ಇರುತ್ತದೆ.
— ಆದರೆ ನಾನು ಸೇವಾ ಜಾಲರಿಯನ್ನು ಬಳಸಲು ಬಯಸುವುದಿಲ್ಲ!
- ಸರಿ, ಇದು ಅಗತ್ಯವಿಲ್ಲ! ಮೇಲಿನ ನನ್ನ ಪ್ರಶ್ನಾವಳಿಯನ್ನು ನೀವು ಕನಿಷ್ಟ ಅದರ ಮೂಲಭೂತ ವಿಷಯಗಳೊಂದಿಗೆ ಪರಿಚಿತರಾಗಬೇಕೆ ಎಂದು ನೋಡಲು.
— ಇದು ಹೊಸ ಸಾಸ್‌ನೊಂದಿಗೆ ಉತ್ತಮ ಹಳೆಯ ESB/ಮಿಡಲ್‌ವೇರ್ ಅಲ್ಲವೇ?
- ಸೇವಾ ಜಾಲರಿಯು ಕಾರ್ಯಾಚರಣೆಯ ತರ್ಕದೊಂದಿಗೆ ವ್ಯವಹರಿಸುತ್ತದೆ, ಶಬ್ದಾರ್ಥವಲ್ಲ. ಎಂಟರ್‌ಪ್ರೈಸ್ ಸರ್ವಿಸ್ ಬಸ್ () ಈ ಪ್ರತ್ಯೇಕತೆಯನ್ನು ಇಟ್ಟುಕೊಳ್ಳುವುದರಿಂದ ಸೇವಾ ಜಾಲರಿಯು ಅದೇ ಅದೃಷ್ಟವನ್ನು ತಪ್ಪಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.
- API ಗೇಟ್‌ವೇಗಳಿಂದ ಸೇವಾ ಜಾಲರಿಯು ಹೇಗೆ ಭಿನ್ನವಾಗಿದೆ?
ಈ ವಿಷಯದ ಬಗ್ಗೆ ಒಂದು ಮಿಲಿಯನ್ ಲೇಖನಗಳಿವೆ. ಕೇವಲ ಗೂಗಲ್.
ರಾಯಭಾರಿಯು ಸೇವಾ ಜಾಲರಿಯೇ?
- ಇಲ್ಲ, ಎನ್ವಾಯ್ ಸೇವಾ ಜಾಲರಿ ಅಲ್ಲ, ಇದು ಪ್ರಾಕ್ಸಿ ಸರ್ವರ್ ಆಗಿದೆ. ಸೇವಾ ಜಾಲರಿಯನ್ನು ಸಂಘಟಿಸಲು ಇದನ್ನು ಬಳಸಬಹುದು (ಮತ್ತು ಹೆಚ್ಚು - ಇದು ಸಾಮಾನ್ಯ ಉದ್ದೇಶದ ಪ್ರಾಕ್ಸಿ). ಆದರೆ ಸ್ವತಃ, ಇದು ಸೇವಾ ಜಾಲರಿ ಅಲ್ಲ.
- ನೆಟ್‌ವರ್ಕ್ ಸೇವಾ ಜಾಲರಿ - ಇದು ಸೇವಾ ಜಾಲರಿಯೇ?
- ಇಲ್ಲ. ಹೆಸರಿನ ಹೊರತಾಗಿಯೂ, ಇದು ಸೇವಾ ಜಾಲರಿ ಅಲ್ಲ (ನೀವು ಮಾರ್ಕೆಟಿಂಗ್‌ನ ಅದ್ಭುತಗಳನ್ನು ಹೇಗೆ ಇಷ್ಟಪಡುತ್ತೀರಿ?).
- ಸಂದೇಶ ಸರದಿಯ ಆಧಾರದ ಮೇಲೆ ನನ್ನ ಪ್ರತಿಕ್ರಿಯಾತ್ಮಕ ಅಸಮಕಾಲಿಕ ವ್ಯವಸ್ಥೆಗೆ ಸೇವಾ ಜಾಲರಿಯು ಸಹಾಯ ಮಾಡುತ್ತದೆಯೇ?
- ಇಲ್ಲ, ಸೇವಾ ಜಾಲರಿಯು ನಿಮಗೆ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ.
- ನಾನು ಯಾವ ಸೇವಾ ಜಾಲರಿಯನ್ನು ಬಳಸಬೇಕು?
- , ದಡ್ಡ.
- ಲೇಖನ ಹೀರುತ್ತದೆ! / ಲೇಖಕ - ಸೋಪ್ ಮೇಲೆ!
— ದಯವಿಟ್ಟು ಅದರ ಲಿಂಕ್ ಅನ್ನು ನಿಮ್ಮ ಎಲ್ಲ ಸ್ನೇಹಿತರೊಂದಿಗೆ ಹಂಚಿಕೊಳ್ಳಿ ಇದರಿಂದ ಅವರು ಇದನ್ನು ಮನವರಿಕೆ ಮಾಡಿಕೊಳ್ಳಬಹುದು!
ಸ್ವೀಕೃತಿಗಳು
ಶೀರ್ಷಿಕೆಯಿಂದ ನೀವು ಊಹಿಸುವಂತೆ, ಈ ಲೇಖನವು ಜೇ ಕ್ರೆಪ್ಸ್ ಅವರ ಅದ್ಭುತ ಗ್ರಂಥದಿಂದ ಪ್ರೇರಿತವಾಗಿದೆ "". ನಾನು ಹತ್ತು ವರ್ಷಗಳ ಹಿಂದೆ ಲಿಂಕ್ಡ್ ಇನ್‌ನಲ್ಲಿ ಸಂದರ್ಶನ ಮಾಡುವಾಗ ಜೇ ಅವರನ್ನು ಭೇಟಿಯಾದೆ ಮತ್ತು ಅಂದಿನಿಂದ ಅವರು ನನಗೆ ಸ್ಫೂರ್ತಿಯಾಗಿದ್ದಾರೆ.
ನಾನು ನನ್ನನ್ನು "ಲಿಂಕರ್ಡ್ ಡೆವಲಪರ್" ಎಂದು ಕರೆಯಲು ಇಷ್ಟಪಡುತ್ತೇನೆ, ವಾಸ್ತವವೆಂದರೆ ನಾನು ಪ್ರಾಜೆಕ್ಟ್‌ನಲ್ಲಿ README.md ಫೈಲ್ ಅನ್ನು ಹೆಚ್ಚು ನಿರ್ವಹಿಸುವವನಾಗಿದ್ದೇನೆ. ಇಂದು Linkerd ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಲಾಗುತ್ತಿದೆ , , ಜನರು, ಮತ್ತು ಕೊಡುಗೆದಾರರು ಮತ್ತು ಬಳಕೆದಾರರ ಅದ್ಭುತ ಸಮುದಾಯವಿಲ್ಲದೆ ಈ ಯೋಜನೆಯು ಸಾಧ್ಯವಾಗುತ್ತಿರಲಿಲ್ಲ.
ಮತ್ತು ಅಂತಿಮವಾಗಿ, ಲಿಂಕರ್ಡ್ ಸೃಷ್ಟಿಕರ್ತರಿಗೆ ವಿಶೇಷ ಧನ್ಯವಾದಗಳು, (ಪ್ರೈಮಸ್ ಇಂಟರ್ ಪ್ಯಾರೆಸ್), ಅವರು, ಹಲವು ವರ್ಷಗಳ ಹಿಂದೆ ನನ್ನೊಂದಿಗೆ, ಸೇವಾ ಜಾಲರಿಯೊಂದಿಗೆ ಈ ಎಲ್ಲಾ ಗಡಿಬಿಡಿಯಲ್ಲಿ ತಲೆಕೆಳಗಾಗಿ ಮುಳುಗಿದರು.
ಅನುವಾದಕರಿಂದ PS
ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿಯೂ ಓದಿ:
- «";
- «";
- «";
- «";
- «».
ಮೂಲ: www.habr.com