ಹೇ ಹಬ್ರ್! ನಾನು ನಿಮ್ಮ ಗಮನಕ್ಕೆ ಲೇಖನದ ಅನುವಾದವನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುತ್ತೇನೆ "ಸರ್ವಿಸ್ ಮೆಶ್ ಡೇಟಾ ಪ್ಲೇನ್ ವರ್ಸಸ್ ಕಂಟ್ರೋಲ್ ಪ್ಲೇನ್" ಲೇಖಕ ಮ್ಯಾಟ್ ಕ್ಲೈನ್.

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

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

ಜುಲೈನಲ್ಲಿ ನಾನು ಬರೆದ ಟ್ವೀಟ್‌ಗಳ ಕೆಳಗಿನ ಸರಣಿಯಿಂದ ಪರಿಸ್ಥಿತಿಯನ್ನು ಅತ್ಯುತ್ತಮವಾಗಿ ಸಂಕ್ಷೇಪಿಸಲಾಗಿದೆ:

ಸೇವಾ ಜಾಲರಿಯ ಗೊಂದಲ #1: Linkerd ~ = Nginx ~ = Haproxy ~ = ರಾಯಭಾರಿ. ಅವರೇನೂ ಇಸ್ತಿಯೋಗೆ ಸರಿಸಾಟಿಯಲ್ಲ. ಇಸ್ಟಿಯೊ ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನವಾಗಿದೆ. 1 /

ಮೊದಲನೆಯದು ಸರಳವಾಗಿ ಡೇಟಾ ಪ್ಲೇನ್‌ಗಳು. ಸ್ವತಃ ಅವರು ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ. ಅವರು ಇನ್ನೂ ಯಾವುದೋ ಮನಸ್ಥಿತಿಯಲ್ಲಿರಬೇಕು. 2/

ಭಾಗಗಳನ್ನು ಒಟ್ಟಿಗೆ ಜೋಡಿಸುವ ನಿಯಂತ್ರಣ ಸಮತಲಕ್ಕೆ ಇಸ್ಟಿಯೊ ಒಂದು ಉದಾಹರಣೆಯಾಗಿದೆ. ಇದು ಇನ್ನೊಂದು ಪದರ. / ಅಂತ್ಯ

ಹಿಂದಿನ ಟ್ವೀಟ್‌ಗಳು ಹಲವಾರು ವಿಭಿನ್ನ ಯೋಜನೆಗಳನ್ನು (ಲಿಂಕರ್ಡ್, NGINX, HAProxy, Envoy, ಮತ್ತು Istio) ಉಲ್ಲೇಖಿಸುತ್ತವೆ, ಆದರೆ ಹೆಚ್ಚು ಮುಖ್ಯವಾಗಿ ಡೇಟಾ ಪ್ಲೇನ್, ಸರ್ವಿಸ್ ಮೆಶ್ ಮತ್ತು ಕಂಟ್ರೋಲ್ ಪ್ಲೇನ್‌ನ ಸಾಮಾನ್ಯ ಪರಿಕಲ್ಪನೆಗಳನ್ನು ಪರಿಚಯಿಸುತ್ತವೆ. ಈ ಪೋಸ್ಟ್‌ನಲ್ಲಿ, ನಾನು ಒಂದು ಹೆಜ್ಜೆ ಹಿಂದಕ್ಕೆ ತೆಗೆದುಕೊಳ್ಳುತ್ತೇನೆ ಮತ್ತು "ಡೇಟಾ ಪ್ಲೇನ್" ಮತ್ತು "ನಿಯಂತ್ರಣ ಪ್ಲೇನ್" ಪದಗಳಿಂದ ನಾನು ಏನು ಅರ್ಥೈಸುತ್ತೇನೆ ಎಂಬುದರ ಕುರಿತು ಹೆಚ್ಚಿನ ಮಟ್ಟದಲ್ಲಿ ಮಾತನಾಡುತ್ತೇನೆ ಮತ್ತು ನಂತರ ಟ್ವೀಟ್‌ಗಳಲ್ಲಿ ಉಲ್ಲೇಖಿಸಲಾದ ಯೋಜನೆಗಳಿಗೆ ನಿಯಮಗಳು ಹೇಗೆ ಅನ್ವಯಿಸುತ್ತವೆ ಎಂಬುದರ ಕುರಿತು ಮಾತನಾಡುತ್ತೇನೆ.

ನಿಜವಾಗಿಯೂ ಸೇವಾ ಜಾಲರಿ ಎಂದರೇನು?

ಚಿತ್ರ 1: ಸೇವಾ ಜಾಲರಿ ಅವಲೋಕನ

ಚಿತ್ರ 1 ಸೇವಾ ಜಾಲರಿಯ ಪರಿಕಲ್ಪನೆಯನ್ನು ಅದರ ಮೂಲಭೂತ ಮಟ್ಟದಲ್ಲಿ ವಿವರಿಸುತ್ತದೆ. ನಾಲ್ಕು ಸೇವಾ ಸಮೂಹಗಳಿವೆ (AD). ಪ್ರತಿಯೊಂದು ಸೇವಾ ನಿದರ್ಶನವು ಸ್ಥಳೀಯ ಪ್ರಾಕ್ಸಿ ಸರ್ವರ್‌ನೊಂದಿಗೆ ಸಂಯೋಜಿತವಾಗಿದೆ. ಒಂದೇ ಅಪ್ಲಿಕೇಶನ್ ನಿದರ್ಶನದಿಂದ ಎಲ್ಲಾ ನೆಟ್‌ವರ್ಕ್ ಟ್ರಾಫಿಕ್ (HTTP, REST, gRPC, Redis, ಇತ್ಯಾದಿ) ಸ್ಥಳೀಯ ಪ್ರಾಕ್ಸಿ ಮೂಲಕ ಸೂಕ್ತವಾದ ಬಾಹ್ಯ ಸೇವಾ ಕ್ಲಸ್ಟರ್‌ಗಳಿಗೆ ರವಾನಿಸಲಾಗುತ್ತದೆ. ಈ ರೀತಿಯಾಗಿ, ಅಪ್ಲಿಕೇಶನ್ ನಿದರ್ಶನವು ಒಟ್ಟಾರೆಯಾಗಿ ನೆಟ್‌ವರ್ಕ್ ಬಗ್ಗೆ ತಿಳಿದಿರುವುದಿಲ್ಲ ಮತ್ತು ಅದರ ಸ್ಥಳೀಯ ಪ್ರಾಕ್ಸಿಯ ಬಗ್ಗೆ ಮಾತ್ರ ತಿಳಿದಿರುತ್ತದೆ. ಪರಿಣಾಮವಾಗಿ, ವಿತರಿಸಿದ ಸಿಸ್ಟಮ್ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಸೇವೆಯಿಂದ ತೆಗೆದುಹಾಕಲಾಗಿದೆ.

ಡೇಟಾ ಪ್ಲೇನ್

ಸೇವಾ ಜಾಲರಿಯಲ್ಲಿ, ಅಪ್ಲಿಕೇಶನ್‌ಗಾಗಿ ಸ್ಥಳೀಯವಾಗಿ ಇರುವ ಪ್ರಾಕ್ಸಿ ಸರ್ವರ್ ಈ ಕೆಳಗಿನ ಕಾರ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ:

• ಸೇವೆಯ ಅನ್ವೇಷಣೆ. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಯಾವ ಸೇವೆಗಳು/ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಲಭ್ಯವಿವೆ?
• ಆರೋಗ್ಯ ತಪಾಸಣೆ. ಸೇವೆಯ ಅನ್ವೇಷಣೆಯಿಂದ ಹಿಂತಿರುಗಿಸಲಾದ ಸೇವಾ ನಿದರ್ಶನಗಳು ಆರೋಗ್ಯಕರವಾಗಿವೆಯೇ ಮತ್ತು ನೆಟ್‌ವರ್ಕ್ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಸ್ವೀಕರಿಸಲು ಸಿದ್ಧವಾಗಿದೆಯೇ? ಇದು ಸಕ್ರಿಯ (ಉದಾ ಪ್ರತಿಕ್ರಿಯೆ/ಆರೋಗ್ಯ ತಪಾಸಣೆ) ಮತ್ತು ನಿಷ್ಕ್ರಿಯ (ಉದಾಹರಣೆಗೆ 3 ಸತತ 5xx ದೋಷಗಳನ್ನು ಅನಾರೋಗ್ಯಕರ ಸೇವಾ ಸ್ಥಿತಿಯ ಸೂಚನೆಯಾಗಿ ಬಳಸುವುದು) ಆರೋಗ್ಯ ತಪಾಸಣೆಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ.
• ರೂಟಿಂಗ್. REST ಸೇವೆಯಿಂದ "/foo" ಗೆ ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸುವಾಗ, ವಿನಂತಿಯನ್ನು ಯಾವ ಸೇವಾ ಕ್ಲಸ್ಟರ್‌ಗೆ ಕಳುಹಿಸಬೇಕು?
• ಹೊರೆ ಸಮತೋಲನೆ. ರೂಟಿಂಗ್ ಸಮಯದಲ್ಲಿ ಸೇವಾ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಿದ ನಂತರ, ವಿನಂತಿಯನ್ನು ಯಾವ ಸೇವಾ ನಿದರ್ಶನಕ್ಕೆ ಕಳುಹಿಸಬೇಕು? ಯಾವ ಕಾಲಾವಧಿಯೊಂದಿಗೆ? ಯಾವ ಸರ್ಕ್ಯೂಟ್ ಬ್ರೇಕಿಂಗ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳೊಂದಿಗೆ? ವಿನಂತಿಯು ವಿಫಲವಾದರೆ, ಅದನ್ನು ಮರುಪ್ರಯತ್ನಿಸಬೇಕೇ?
• ದೃಢೀಕರಣ ಮತ್ತು ದೃಢೀಕರಣ. ಒಳಬರುವ ವಿನಂತಿಗಳಿಗಾಗಿ, ಕರೆ ಮಾಡುವ ಸೇವೆಯನ್ನು mTLS ಅಥವಾ ಇತರ ಕಾರ್ಯವಿಧಾನವನ್ನು ಬಳಸಿಕೊಂಡು ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕವಾಗಿ ಗುರುತಿಸಬಹುದೇ/ಅಧಿಕೃತಗೊಳಿಸಬಹುದೇ? ಅದನ್ನು ಗುರುತಿಸಿದರೆ/ಅಧಿಕೃತವಾಗಿದ್ದರೆ, ಸೇವೆಯಲ್ಲಿ ವಿನಂತಿಸಿದ ಕಾರ್ಯಾಚರಣೆಯನ್ನು (ಎಂಡ್‌ಪಾಯಿಂಟ್) ಕರೆ ಮಾಡಲು ಅನುಮತಿಸಲಾಗಿದೆಯೇ ಅಥವಾ ದೃಢೀಕರಿಸದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಹಿಂತಿರುಗಿಸಬೇಕೇ?
• ಗಮನಿಸುವಿಕೆ. ಪ್ರತಿ ವಿನಂತಿಗೆ ವಿವರವಾದ ಅಂಕಿಅಂಶಗಳು, ಲಾಗ್‌ಗಳು/ಲಾಗ್‌ಗಳು ಮತ್ತು ವಿತರಿಸಿದ ಟ್ರೇಸ್ ಡೇಟಾವನ್ನು ರಚಿಸಬೇಕು ಇದರಿಂದ ನಿರ್ವಾಹಕರು ವಿತರಿಸಿದ ಟ್ರಾಫಿಕ್ ಹರಿವು ಮತ್ತು ಡೀಬಗ್ ಮಾಡುವ ಸಮಸ್ಯೆಗಳನ್ನು ಅವರು ಉದ್ಭವಿಸಿದಾಗ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬಹುದು.

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

ನಿಯಂತ್ರಣ ವಿಮಾನ

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

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

ಅನೇಕ ತಂತ್ರಜ್ಞರು ಡೇಟಾ ಪ್ಲೇನ್ ಮತ್ತು ಕಂಟ್ರೋಲ್ ಪ್ಲೇನ್‌ನ ಪ್ರತ್ಯೇಕ ಪರಿಕಲ್ಪನೆಗಳನ್ನು ಗೊಂದಲಕ್ಕೀಡುಮಾಡಲು ಕಾರಣವೆಂದರೆ ಹೆಚ್ಚಿನ ಜನರಿಗೆ ಡೇಟಾ ಪ್ಲೇನ್ ಪರಿಚಿತವಾಗಿರುವಾಗ ನಿಯಂತ್ರಣ ಪ್ಲೇನ್ ವಿದೇಶಿ/ಅರ್ಥವಾಗುವುದಿಲ್ಲ. ನಾವು ದೀರ್ಘಕಾಲದವರೆಗೆ ಭೌತಿಕ ನೆಟ್ವರ್ಕ್ ರೂಟರ್ಗಳು ಮತ್ತು ಸ್ವಿಚ್ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೇವೆ. ಪ್ಯಾಕೆಟ್‌ಗಳು/ವಿನಂತಿಗಳು A ಯಿಂದ ಪಾಯಿಂಟ್ B ಗೆ ಹೋಗಬೇಕು ಮತ್ತು ಇದನ್ನು ಮಾಡಲು ನಾವು ಹಾರ್ಡ್‌ವೇರ್ ಮತ್ತು ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ಬಳಸಬಹುದು ಎಂದು ನಾವು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇವೆ. ಹೊಸ ಪೀಳಿಗೆಯ ಸಾಫ್ಟ್‌ವೇರ್ ಪ್ರಾಕ್ಸಿಗಳು ನಾವು ದೀರ್ಘಕಾಲದಿಂದ ಬಳಸುತ್ತಿರುವ ಪರಿಕರಗಳ ಅಲಂಕಾರಿಕ ಆವೃತ್ತಿಗಳಾಗಿವೆ.

ಚಿತ್ರ 2: ಮಾನವ ನಿಯಂತ್ರಣ ಸಮತಲ

ಆದಾಗ್ಯೂ, ನಾವು ದೀರ್ಘಕಾಲದವರೆಗೆ ನಿಯಂತ್ರಣ ವಿಮಾನಗಳನ್ನು ಬಳಸುತ್ತಿದ್ದೇವೆ, ಆದಾಗ್ಯೂ ಹೆಚ್ಚಿನ ನೆಟ್‌ವರ್ಕ್ ಆಪರೇಟರ್‌ಗಳು ಸಿಸ್ಟಮ್‌ನ ಈ ಭಾಗವನ್ನು ಯಾವುದೇ ತಂತ್ರಜ್ಞಾನದ ಘಟಕದೊಂದಿಗೆ ಸಂಯೋಜಿಸದಿರಬಹುದು. ಕಾರಣ ಸರಳವಾಗಿದೆ:
ಇಂದು ಬಳಕೆಯಲ್ಲಿರುವ ಹೆಚ್ಚಿನ ನಿಯಂತ್ರಣ ವಿಮಾನಗಳು... ನಾವು.

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

ಚಿತ್ರ 3: ಸುಧಾರಿತ ಸೇವಾ ಜಾಲರಿ ನಿಯಂತ್ರಣ ವಿಮಾನ

ಮೇಲೆ ಫಿಗರ್ 3 ಸೇವಾ ಜಾಲರಿಯ "ವಿಸ್ತೃತ" ನಿಯಂತ್ರಣ ಸಮತಲವನ್ನು ತೋರಿಸುತ್ತದೆ. ಇದು ಈ ಕೆಳಗಿನ ಭಾಗಗಳನ್ನು ಒಳಗೊಂಡಿದೆ:

• ಮನುಷ್ಯ: ಇಡೀ ವ್ಯವಸ್ಥೆಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ಉನ್ನತ ಮಟ್ಟದ ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವ ವ್ಯಕ್ತಿ (ಆಶಾದಾಯಕವಾಗಿ ಕಡಿಮೆ ಕೋಪ) ಇನ್ನೂ ಇದ್ದಾರೆ.
• ಕಂಟ್ರೋಲ್ ಪ್ಲೇನ್ UI: ಒಬ್ಬ ವ್ಯಕ್ತಿಯು ಸಿಸ್ಟಮ್ ಅನ್ನು ನಿಯಂತ್ರಿಸಲು ಕೆಲವು ರೀತಿಯ ಬಳಕೆದಾರ ಇಂಟರ್ಫೇಸ್ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತಾನೆ. ಇದು ವೆಬ್ ಪೋರ್ಟಲ್, ಕಮಾಂಡ್ ಲೈನ್ ಅಪ್ಲಿಕೇಶನ್ (CLI) ಅಥವಾ ಕೆಲವು ಇತರ ಇಂಟರ್ಫೇಸ್ ಆಗಿರಬಹುದು. ಬಳಕೆದಾರ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು, ನಿರ್ವಾಹಕರು ಜಾಗತಿಕ ಸಿಸ್ಟಮ್ ಕಾನ್ಫಿಗರೇಶನ್ ನಿಯತಾಂಕಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ಹೊಂದಿರುತ್ತಾರೆ:
  • ನಿಯೋಜನೆ ನಿಯಂತ್ರಣ, ನೀಲಿ/ಹಸಿರು ಮತ್ತು/ಅಥವಾ ಕ್ರಮೇಣ ಸಂಚಾರ ಪರಿವರ್ತನೆ
  • ದೃಢೀಕರಣ ಮತ್ತು ದೃಢೀಕರಣ ಆಯ್ಕೆಗಳು
  • ರೂಟಿಂಗ್ ಟೇಬಲ್ ವಿಶೇಷಣಗಳು, ಉದಾಹರಣೆಗೆ ಅಪ್ಲಿಕೇಶನ್ A "/foo" ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ವಿನಂತಿಸಿದಾಗ ಏನಾಗುತ್ತದೆ
  • ಸಮಯ ಮೀರುವಿಕೆಗಳು, ಮರುಪ್ರಯತ್ನಗಳು, ಸರ್ಕ್ಯೂಟ್ ಬ್ರೇಕಿಂಗ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಇತ್ಯಾದಿಗಳಂತಹ ಬ್ಯಾಲೆನ್ಸರ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಲೋಡ್ ಮಾಡಿ.
• ಕೆಲಸದ ಹೊರೆ ವೇಳಾಪಟ್ಟಿ: ಕುಬರ್ನೆಟ್ಸ್ ಅಥವಾ ನೊಮಾಡ್‌ನಂತಹ ಕೆಲವು ರೀತಿಯ ವೇಳಾಪಟ್ಟಿ/ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ವ್ಯವಸ್ಥೆಯ ಮೂಲಕ ಸೇವೆಗಳನ್ನು ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ನಡೆಸಲಾಗುತ್ತದೆ. ಅದರ ಸ್ಥಳೀಯ ಪ್ರಾಕ್ಸಿ ಜೊತೆಗೆ ಸೇವೆಯನ್ನು ಲೋಡ್ ಮಾಡಲು ಶೆಡ್ಯೂಲರ್ ಜವಾಬ್ದಾರನಾಗಿರುತ್ತಾನೆ.
• ಸೇವೆಯ ಅನ್ವೇಷಣೆ. ಶೆಡ್ಯೂಲರ್ ಸೇವೆಯ ನಿದರ್ಶನಗಳನ್ನು ಪ್ರಾರಂಭಿಸಿದಾಗ ಮತ್ತು ನಿಲ್ಲಿಸಿದಾಗ, ಅದು ಆರೋಗ್ಯ ಸ್ಥಿತಿಯನ್ನು ಸೇವಾ ಪತ್ತೆ ವ್ಯವಸ್ಥೆಗೆ ವರದಿ ಮಾಡುತ್ತದೆ.
• ಸೈಡ್‌ಕಾರ್ ಪ್ರಾಕ್ಸಿ ಕಾನ್ಫಿಗರೇಶನ್ APIಗಳು : ಸ್ಥಳೀಯ ಪ್ರಾಕ್ಸಿಗಳು ಆಪರೇಟರ್ ಹಸ್ತಕ್ಷೇಪವಿಲ್ಲದೆ ಅಂತಿಮವಾಗಿ ಸ್ಥಿರವಾದ ಮಾದರಿಯನ್ನು ಬಳಸಿಕೊಂಡು ವಿವಿಧ ಸಿಸ್ಟಮ್ ಘಟಕಗಳಿಂದ ಸ್ಥಿತಿಯನ್ನು ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಹೊರತೆಗೆಯುತ್ತವೆ. ಪ್ರಸ್ತುತ ಚಾಲನೆಯಲ್ಲಿರುವ ಎಲ್ಲಾ ಸೇವಾ ನಿದರ್ಶನಗಳು ಮತ್ತು ಸ್ಥಳೀಯ ಪ್ರಾಕ್ಸಿ ಸರ್ವರ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಸಂಪೂರ್ಣ ವ್ಯವಸ್ಥೆಯು ಅಂತಿಮವಾಗಿ ಒಂದು ಪರಿಸರ ವ್ಯವಸ್ಥೆಯಾಗಿ ಒಮ್ಮುಖವಾಗುತ್ತದೆ. ಪ್ರಾಯೋಗಿಕವಾಗಿ ಇದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಎನ್ವಾಯ್‌ನ ಸಾರ್ವತ್ರಿಕ ಡೇಟಾ ಪ್ಲೇನ್ API ಒಂದು ಉದಾಹರಣೆಯಾಗಿದೆ.

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

ಡೇಟಾ ಪ್ಲೇನ್ ಮತ್ತು ಕಂಟ್ರೋಲ್ ಪ್ಲೇನ್. ಡೇಟಾ ಪ್ಲೇನ್ ವರ್ಸಸ್ ಕಂಟ್ರೋಲ್ ಪ್ಲೇನ್ ಸಾರಾಂಶ

• ಸೇವೆ ಮೆಶ್ ಡೇಟಾ ಪ್ಲೇನ್: ವ್ಯವಸ್ಥೆಯಲ್ಲಿನ ಪ್ರತಿ ಪ್ಯಾಕೆಟ್/ವಿನಂತಿಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್/ಸೇವೆ ಅನ್ವೇಷಣೆ, ಆರೋಗ್ಯ ತಪಾಸಣೆ, ರೂಟಿಂಗ್, ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್, ದೃಢೀಕರಣ/ಅಧಿಕಾರ ಮತ್ತು ವೀಕ್ಷಣೆಗೆ ಜವಾಬ್ದಾರರು.
• ಸೇವಾ ಜಾಲರಿ ನಿಯಂತ್ರಣ ವಿಮಾನ: ಸೇವಾ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಎಲ್ಲಾ ಡೇಟಾ ಪ್ಲೇನ್‌ಗಳಿಗೆ ನೀತಿ ಮತ್ತು ಸಂರಚನೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ. ಸಿಸ್ಟಂನಲ್ಲಿ ಯಾವುದೇ ಪ್ಯಾಕೇಜುಗಳು/ವಿನಂತಿಗಳನ್ನು ಮುಟ್ಟುವುದಿಲ್ಲ. ನಿಯಂತ್ರಣ ಸಮತಲವು ಎಲ್ಲಾ ಡೇಟಾ ಪ್ಲೇನ್‌ಗಳನ್ನು ವಿತರಿಸಿದ ವ್ಯವಸ್ಥೆಯಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.

ಪ್ರಸ್ತುತ ಯೋಜನೆಯ ಭೂದೃಶ್ಯ

ಮೇಲಿನ ವಿವರಣೆಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಂಡ ನಂತರ, ಸೇವಾ ಜಾಲರಿ ಯೋಜನೆಯ ಪ್ರಸ್ತುತ ಸ್ಥಿತಿಯನ್ನು ನೋಡೋಣ.

• ಡೇಟಾ ವಿಮಾನಗಳು: ಲಿಂಕರ್ಡ್, NGINX, HAProxy, Envoy, Traefik
• ನಿಯಂತ್ರಣ ವಿಮಾನಗಳು: ಇಸ್ಟಿಯೊ, ನೆಲ್ಸನ್, ಸ್ಮಾರ್ಟ್‌ಸ್ಟಾಕ್

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

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

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

ನೆಲ್ಸನ್ ಮತ್ತು ಸ್ಮಾರ್ಟ್‌ಸ್ಟ್ಯಾಕ್ ನಿಯಂತ್ರಣ ಸಮತಲ ಮತ್ತು ಡೇಟಾ ಪ್ಲೇನ್‌ನ ಪ್ರತ್ಯೇಕತೆಯನ್ನು ವಿವರಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ನೆಲ್ಸನ್ ಎನ್ವಾಯ್ ಅನ್ನು ಅದರ ಪ್ರಾಕ್ಸಿಯಾಗಿ ಬಳಸುತ್ತಾರೆ ಮತ್ತು ಹ್ಯಾಶಿಕಾರ್ಪ್ ಸ್ಟಾಕ್ ಅನ್ನು ಆಧರಿಸಿ ಸೇವಾ ಜಾಲರಿಗಾಗಿ ವಿಶ್ವಾಸಾರ್ಹ ನಿಯಂತ್ರಣ ವಿಮಾನವನ್ನು ನಿರ್ಮಿಸುತ್ತಾರೆ, ಅಂದರೆ. ಅಲೆಮಾರಿ, ಇತ್ಯಾದಿ. SmartStack ಬಹುಶಃ ಸೇವೆಯ ಮೆಶ್‌ಗಳ ಹೊಸ ಅಲೆಯ ಮೊದಲನೆಯದು. SmartStack HAProxy ಅಥವಾ NGINX ಸುತ್ತಲೂ ನಿಯಂತ್ರಣ ಸಮತಲವನ್ನು ನಿರ್ಮಿಸುತ್ತದೆ, ಡೇಟಾ ಪ್ಲೇನ್‌ನಿಂದ ಸೇವಾ ಜಾಲರಿಯಿಂದ ನಿಯಂತ್ರಣ ಸಮತಲವನ್ನು ಬೇರ್ಪಡಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತದೆ.

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

ಪ್ರಮುಖ ಟೇಕ್ಅವೇಗಳು

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

ಮೂಲ: www.habr.com