ಅಂತರ್ಜಾಲದಲ್ಲಿ (ಸೇವಾ ಜಾಲರಿ), ಮತ್ತು ಇನ್ನೊಂದು ಇಲ್ಲಿದೆ. ಹುರ್ರೇ! ಆದರೆ ಯಾಕೆ? ನಂತರ, ಡಾಕರ್ ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್‌ನಂತಹ ಕಂಟೈನರ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳ ಆಗಮನದ ಮೊದಲು ಸೇವಾ ಜಾಲರಿಗಳು 10 ವರ್ಷಗಳ ಹಿಂದೆ ಕಾಣಿಸಿಕೊಂಡಿದ್ದರೆ ಉತ್ತಮ ಎಂದು ನನ್ನ ಅಭಿಪ್ರಾಯವನ್ನು ವ್ಯಕ್ತಪಡಿಸಲು ನಾನು ಬಯಸುತ್ತೇನೆ. ನನ್ನ ದೃಷ್ಟಿಕೋನವು ಇತರರಿಗಿಂತ ಉತ್ತಮವಾಗಿದೆ ಅಥವಾ ಕೆಟ್ಟದಾಗಿದೆ ಎಂದು ನಾನು ಹೇಳುತ್ತಿಲ್ಲ, ಆದರೆ ಸೇವಾ ಜಾಲರಿಗಳು ಸಾಕಷ್ಟು ಸಂಕೀರ್ಣವಾದ ಪ್ರಾಣಿಗಳಾಗಿರುವುದರಿಂದ, ಅವುಗಳನ್ನು ಉತ್ತಮವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಬಹು ದೃಷ್ಟಿಕೋನಗಳು ಸಹಾಯ ಮಾಡುತ್ತವೆ.
ನಾನು ಡಾಟ್‌ಕ್ಲೌಡ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇನೆ, ಇದನ್ನು ನೂರಕ್ಕೂ ಹೆಚ್ಚು ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳಲ್ಲಿ ನಿರ್ಮಿಸಲಾಗಿದೆ ಮತ್ತು ಸಾವಿರಾರು ಕಂಟೈನರೈಸ್ ಮಾಡಿದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸಲಾಗಿದೆ. ಅದನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವಲ್ಲಿ ಮತ್ತು ಪ್ರಾರಂಭಿಸುವಲ್ಲಿ ನಾವು ಎದುರಿಸಿದ ಸವಾಲುಗಳನ್ನು ನಾನು ವಿವರಿಸುತ್ತೇನೆ ಮತ್ತು ಸೇವಾ ಮೆಶ್‌ಗಳು ಹೇಗೆ ಸಹಾಯ ಮಾಡಬಹುದು (ಅಥವಾ ಸಾಧ್ಯವಾಗಲಿಲ್ಲ).
ಡಾಟ್‌ಕ್ಲೌಡ್‌ನ ಇತಿಹಾಸ
ನಾನು ಡಾಟ್‌ಕ್ಲೌಡ್‌ನ ಇತಿಹಾಸ ಮತ್ತು ಈ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಾಗಿ ಆರ್ಕಿಟೆಕ್ಚರ್ ಆಯ್ಕೆಗಳ ಬಗ್ಗೆ ಬರೆದಿದ್ದೇನೆ, ಆದರೆ ನಾನು ನೆಟ್‌ವರ್ಕ್ ಲೇಯರ್ ಬಗ್ಗೆ ಹೆಚ್ಚು ಮಾತನಾಡಿಲ್ಲ. ನೀವು ಓದಲು ಧುಮುಕುವುದಿಲ್ಲ ಬಯಸದಿದ್ದರೆ ಡಾಟ್‌ಕ್ಲೌಡ್ ಕುರಿತು, ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಸಾರಾಂಶ ಇಲ್ಲಿದೆ: ಇದು PaaS ಪ್ಲಾಟ್‌ಫಾರ್ಮ್-ಸೇವೆಯಾಗಿ ಗ್ರಾಹಕರಿಗೆ ವ್ಯಾಪಕ ಶ್ರೇಣಿಯ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು (ಜಾವಾ, ಪಿಎಚ್‌ಪಿ, ಪೈಥಾನ್...), ವ್ಯಾಪಕ ಶ್ರೇಣಿಯ ಡೇಟಾಗೆ ಬೆಂಬಲದೊಂದಿಗೆ ಚಲಾಯಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ ಸೇವೆಗಳು (MongoDB, MySQL, Redis...) ಮತ್ತು Heroku ನಂತಹ ವರ್ಕ್‌ಫ್ಲೋ: ನೀವು ನಿಮ್ಮ ಕೋಡ್ ಅನ್ನು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗೆ ಅಪ್‌ಲೋಡ್ ಮಾಡಿ, ಅದು ಕಂಟೇನರ್ ಚಿತ್ರಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತದೆ ಮತ್ತು ಅವುಗಳನ್ನು ನಿಯೋಜಿಸುತ್ತದೆ.
ಡಾಟ್‌ಕ್ಲೌಡ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗೆ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಹೇಗೆ ನಿರ್ದೇಶಿಸಲಾಗಿದೆ ಎಂದು ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ. ಇದು ವಿಶೇಷವಾಗಿ ತಂಪಾಗಿರುವ ಕಾರಣವಲ್ಲ (ಆದರೂ ವ್ಯವಸ್ಥೆಯು ಅದರ ಸಮಯಕ್ಕೆ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ!), ಆದರೆ ಪ್ರಾಥಮಿಕವಾಗಿ ಆಧುನಿಕ ಸಾಧನಗಳೊಂದಿಗೆ ಅಂತಹ ವಿನ್ಯಾಸವನ್ನು ಒಂದು ಗುಂಪಿನ ನಡುವೆ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಮಾರ್ಗ ಮಾಡಲು ಒಂದು ಮಾರ್ಗ ಬೇಕಾದರೆ ಸಾಧಾರಣ ತಂಡವು ಕಡಿಮೆ ಸಮಯದಲ್ಲಿ ಸುಲಭವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು. ಸೂಕ್ಷ್ಮ ಸೇವೆಗಳು ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಸಮೂಹ. ಈ ರೀತಿಯಾಗಿ, ನೀವು ಆಯ್ಕೆಗಳನ್ನು ಹೋಲಿಸಬಹುದು: ನೀವು ಎಲ್ಲವನ್ನೂ ನೀವೇ ಅಭಿವೃದ್ಧಿಪಡಿಸಿದರೆ ಅಥವಾ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಸೇವಾ ಜಾಲರಿಯನ್ನು ಬಳಸಿದರೆ ಏನಾಗುತ್ತದೆ. ಅದನ್ನು ನೀವೇ ತಯಾರಿಸುವುದು ಅಥವಾ ಖರೀದಿಸುವುದು ಪ್ರಮಾಣಿತ ಆಯ್ಕೆಯಾಗಿದೆ.
ಹೋಸ್ಟ್ ಮಾಡಿದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಟ್ರಾಫಿಕ್ ರೂಟಿಂಗ್
ಡಾಟ್‌ಕ್ಲೌಡ್‌ನಲ್ಲಿನ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು HTTP ಮತ್ತು TCP ಅಂತಿಮ ಬಿಂದುಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸಬಹುದು.
HTTP ಅಂತಿಮ ಬಿಂದುಗಳು ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಕ್ಲಸ್ಟರ್ ಕಾನ್ಫಿಗರೇಶನ್‌ಗೆ ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಸೇರಿಸಲಾಗಿದೆ . ಇದು ಇಂದು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಮಾಡುವಂತೆಯೇ ಇರುತ್ತದೆ ಕುಬರ್ನೆಟ್ಸ್ ಮತ್ತು ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ನಲ್ಲಿ .
ಕ್ಲೈಂಟ್‌ಗಳು ಸೂಕ್ತವಾದ ಡೊಮೇನ್‌ಗಳ ಮೂಲಕ HTTP ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳಿಗೆ ಸಂಪರ್ಕಿಸುತ್ತಾರೆ, ಡೊಮೇನ್ ಹೆಸರು ಡಾಟ್‌ಕ್ಲೌಡ್ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳಿಗೆ ಸೂಚಿಸುತ್ತದೆ. ವಿಶೇಷವೇನಿಲ್ಲ.
TCP ಅಂತಿಮ ಬಿಂದುಗಳು ಪೋರ್ಟ್ ಸಂಖ್ಯೆಯೊಂದಿಗೆ ಸಂಯೋಜಿತವಾಗಿದೆ, ನಂತರ ಅದನ್ನು ಪರಿಸರದ ಅಸ್ಥಿರಗಳ ಮೂಲಕ ಆ ಸ್ಟಾಕ್‌ನಲ್ಲಿರುವ ಎಲ್ಲಾ ಕಂಟೈನರ್‌ಗಳಿಗೆ ರವಾನಿಸಲಾಗುತ್ತದೆ.
ಗ್ರಾಹಕರು ಸೂಕ್ತವಾದ ಹೋಸ್ಟ್ ಹೆಸರು (ಗೇಟ್‌ವೇ-X.dotcloud.com ನಂತಹ) ಮತ್ತು ಪೋರ್ಟ್ ಸಂಖ್ಯೆಯನ್ನು ಬಳಸಿಕೊಂಡು TCP ಅಂತಿಮ ಬಿಂದುಗಳಿಗೆ ಸಂಪರ್ಕಿಸಬಹುದು.
ಈ ಹೋಸ್ಟ್ ಹೆಸರು "ನ್ಯಾಟ್ಸ್" ಸರ್ವರ್ ಕ್ಲಸ್ಟರ್‌ಗೆ ಪರಿಹರಿಸುತ್ತದೆ (ಇದಕ್ಕೆ ಸಂಬಂಧಿಸಿಲ್ಲ ), ಇದು ಒಳಬರುವ TCP ಸಂಪರ್ಕಗಳನ್ನು ಸರಿಯಾದ ಕಂಟೇನರ್‌ಗೆ (ಅಥವಾ, ಲೋಡ್-ಸಮತೋಲಿತ ಸೇವೆಗಳ ಸಂದರ್ಭದಲ್ಲಿ, ಸರಿಯಾದ ಕಂಟೇನರ್‌ಗಳಿಗೆ) ದಾರಿ ಮಾಡುತ್ತದೆ.
ನೀವು ಕುಬರ್ನೆಟ್ಸ್ ಬಗ್ಗೆ ಪರಿಚಿತರಾಗಿದ್ದರೆ, ಇದು ಬಹುಶಃ ನಿಮಗೆ ಸೇವೆಗಳನ್ನು ನೆನಪಿಸುತ್ತದೆ .
ಡಾಟ್‌ಕ್ಲೌಡ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ ಯಾವುದೇ ಸಮಾನ ಸೇವೆಗಳಿಲ್ಲ : ಸರಳತೆಗಾಗಿ, ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನ ಒಳಗೆ ಮತ್ತು ಹೊರಗಿನಿಂದ ಸೇವೆಗಳನ್ನು ಒಂದೇ ರೀತಿಯಲ್ಲಿ ಪ್ರವೇಶಿಸಲಾಯಿತು.
ಎಲ್ಲವನ್ನೂ ಸರಳವಾಗಿ ಆಯೋಜಿಸಲಾಗಿದೆ: HTTP ಮತ್ತು TCP ರೂಟಿಂಗ್ ನೆಟ್‌ವರ್ಕ್‌ಗಳ ಆರಂಭಿಕ ಅಳವಡಿಕೆಗಳು ಬಹುಶಃ ಪೈಥಾನ್‌ನ ಕೆಲವು ನೂರು ಸಾಲುಗಳು ಮಾತ್ರ. ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಬೆಳೆದಂತೆ ಮತ್ತು ಹೆಚ್ಚುವರಿ ಅವಶ್ಯಕತೆಗಳು ಕಾಣಿಸಿಕೊಂಡಂತೆ ಸರಳವಾದ (ನಾನು ನಿಷ್ಕಪಟವೆಂದು ಹೇಳುತ್ತೇನೆ) ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ಸಂಸ್ಕರಿಸಲಾಗುತ್ತದೆ.
ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕೋಡ್‌ನ ವ್ಯಾಪಕವಾದ ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ ಅಗತ್ಯವಿಲ್ಲ. ನಿರ್ದಿಷ್ಟವಾಗಿ, ಪರಿಸರ ಅಸ್ಥಿರಗಳ ಮೂಲಕ ಪಡೆದ ವಿಳಾಸವನ್ನು ನೇರವಾಗಿ ಬಳಸಬಹುದು.
ಆಧುನಿಕ ಸೇವಾ ಜಾಲರಿಯಿಂದ ಇದು ಹೇಗೆ ಭಿನ್ನವಾಗಿದೆ?
ಸೀಮಿತಗೊಳಿಸಲಾಗಿದೆ ಗೋಚರತೆ. TCP ರೂಟಿಂಗ್ ಮೆಶ್‌ಗಾಗಿ ನಾವು ಯಾವುದೇ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಹೊಂದಿಲ್ಲ. HTTP ರೂಟಿಂಗ್‌ಗೆ ಬಂದಾಗ, ನಂತರದ ಆವೃತ್ತಿಗಳು ದೋಷ ಸಂಕೇತಗಳು ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯಗಳೊಂದಿಗೆ ವಿವರವಾದ HTTP ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಪರಿಚಯಿಸಿದವು, ಆದರೆ ಆಧುನಿಕ ಸೇವಾ ಮೆಶ್‌ಗಳು ಇನ್ನೂ ಮುಂದೆ ಹೋಗುತ್ತವೆ, ಉದಾಹರಣೆಗೆ ಪ್ರೊಮೆಥಿಯಸ್‌ನಂತಹ ಮೆಟ್ರಿಕ್ಸ್ ಸಂಗ್ರಹ ವ್ಯವಸ್ಥೆಗಳೊಂದಿಗೆ ಏಕೀಕರಣವನ್ನು ಒದಗಿಸುತ್ತದೆ.
ಕಾರ್ಯಾಚರಣೆಯ ದೃಷ್ಟಿಕೋನದಿಂದ (ಸಮಸ್ಯೆಗಳನ್ನು ನಿವಾರಿಸಲು ಸಹಾಯ ಮಾಡಲು) ಮಾತ್ರವಲ್ಲದೆ ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡುವಾಗಲೂ ಗೋಚರತೆಯು ಮುಖ್ಯವಾಗಿದೆ. ಇದು ಸುರಕ್ಷಿತ ಬಗ್ಗೆ и .
ರೂಟಿಂಗ್ ದಕ್ಷತೆ ಸಹ ಸೀಮಿತವಾಗಿದೆ. ಡಾಟ್‌ಕ್ಲೌಡ್ ರೂಟಿಂಗ್ ಮೆಶ್‌ನಲ್ಲಿ, ಎಲ್ಲಾ ಟ್ರಾಫಿಕ್ ಮೀಸಲಾದ ರೂಟಿಂಗ್ ನೋಡ್‌ಗಳ ಕ್ಲಸ್ಟರ್ ಮೂಲಕ ಹೋಗಬೇಕಾಗಿತ್ತು. ಇದರರ್ಥ ಬಹು AZ (ಲಭ್ಯತೆಯ ವಲಯ) ಗಡಿಗಳನ್ನು ಸಂಭಾವ್ಯವಾಗಿ ದಾಟುವುದು ಮತ್ತು ಸುಪ್ತತೆಯನ್ನು ಗಣನೀಯವಾಗಿ ಹೆಚ್ಚಿಸುವುದು. ಪ್ರತಿ ಪುಟಕ್ಕೆ ನೂರಕ್ಕೂ ಹೆಚ್ಚು SQL ಪ್ರಶ್ನೆಗಳನ್ನು ಮಾಡುತ್ತಿದ್ದ ಮತ್ತು ಪ್ರತಿ ಪ್ರಶ್ನೆಗೆ SQL ಸರ್ವರ್‌ಗೆ ಹೊಸ ಸಂಪರ್ಕವನ್ನು ತೆರೆಯುವ ದೋಷನಿವಾರಣೆ ಕೋಡ್ ನನಗೆ ನೆನಪಿದೆ. ಸ್ಥಳೀಯವಾಗಿ ಚಾಲನೆಯಲ್ಲಿರುವಾಗ, ಪುಟವು ತಕ್ಷಣವೇ ಲೋಡ್ ಆಗುತ್ತದೆ, ಆದರೆ ಡಾಟ್‌ಕ್ಲೌಡ್‌ನಲ್ಲಿ ಇದು ಲೋಡ್ ಆಗಲು ಕೆಲವು ಸೆಕೆಂಡುಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಏಕೆಂದರೆ ಪ್ರತಿ TCP ಸಂಪರ್ಕ (ಮತ್ತು ನಂತರದ SQL ಪ್ರಶ್ನೆ) ಹತ್ತಾರು ಮಿಲಿಸೆಕೆಂಡುಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಈ ನಿರ್ದಿಷ್ಟ ಸಂದರ್ಭದಲ್ಲಿ, ನಿರಂತರ ಸಂಪರ್ಕಗಳು ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತವೆ.
ಅಂತಹ ಸಮಸ್ಯೆಗಳನ್ನು ನಿಭಾಯಿಸಲು ಆಧುನಿಕ ಸೇವಾ ಜಾಲರಿಗಳು ಉತ್ತಮವಾಗಿವೆ. ಮೊದಲನೆಯದಾಗಿ, ಸಂಪರ್ಕಗಳು ಮಾರ್ಗವಾಗಿದೆಯೇ ಎಂದು ಅವರು ಪರಿಶೀಲಿಸುತ್ತಾರೆ ಮೂಲದಲ್ಲಿ. ತಾರ್ಕಿಕ ಹರಿವು ಒಂದೇ ಆಗಿರುತ್ತದೆ: клиент → меш → сервис, ಆದರೆ ಈಗ ಜಾಲರಿಯು ಸ್ಥಳೀಯವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ರಿಮೋಟ್ ನೋಡ್ಗಳಲ್ಲಿ ಅಲ್ಲ, ಆದ್ದರಿಂದ ಸಂಪರ್ಕ клиент → меш ಸ್ಥಳೀಯ ಮತ್ತು ಅತಿ ವೇಗವಾಗಿದೆ (ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳ ಬದಲಿಗೆ ಮೈಕ್ರೊಸೆಕೆಂಡ್‌ಗಳು).
ಆಧುನಿಕ ಸೇವಾ ಜಾಲರಿಗಳು ಚುರುಕಾದ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ಸಹ ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತವೆ. ಬ್ಯಾಕೆಂಡ್‌ಗಳ ಆರೋಗ್ಯವನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ಮೂಲಕ, ಅವರು ವೇಗವಾದ ಬ್ಯಾಕೆಂಡ್‌ಗಳಿಗೆ ಹೆಚ್ಚಿನ ದಟ್ಟಣೆಯನ್ನು ಕಳುಹಿಸಬಹುದು, ಇದರಿಂದಾಗಿ ಒಟ್ಟಾರೆ ಕಾರ್ಯಕ್ಷಮತೆ ಸುಧಾರಿಸುತ್ತದೆ.
ಭದ್ರತೆ ಉತ್ತಮ ಕೂಡ. ಡಾಟ್‌ಕ್ಲೌಡ್ ರೂಟಿಂಗ್ ಮೆಶ್ ಸಂಪೂರ್ಣವಾಗಿ EC2 ಕ್ಲಾಸಿಕ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಟ್ರಾಫಿಕ್ ಅನ್ನು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಲಿಲ್ಲ (ಇಸಿ2 ನೆಟ್‌ವರ್ಕ್ ಟ್ರಾಫಿಕ್‌ನಲ್ಲಿ ಯಾರಾದರೂ ಸ್ನಿಫರ್ ಅನ್ನು ಹಾಕಲು ನಿರ್ವಹಿಸುತ್ತಿದ್ದರೆ, ನೀವು ಈಗಾಗಲೇ ದೊಡ್ಡ ತೊಂದರೆಯಲ್ಲಿದ್ದೀರಿ ಎಂಬ ಊಹೆಯ ಆಧಾರದ ಮೇಲೆ). ಆಧುನಿಕ ಸೇವಾ ಮೆಶ್‌ಗಳು ನಮ್ಮ ಎಲ್ಲಾ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಪಾರದರ್ಶಕವಾಗಿ ರಕ್ಷಿಸುತ್ತವೆ, ಉದಾಹರಣೆಗೆ, ಪರಸ್ಪರ TLS ದೃಢೀಕರಣ ಮತ್ತು ನಂತರದ ಎನ್‌ಕ್ರಿಪ್ಶನ್‌ನೊಂದಿಗೆ.
ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಸೇವೆಗಳಿಗೆ ಮಾರ್ಗದ ಸಂಚಾರ
ಸರಿ, ನಾವು ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ನಡುವಿನ ದಟ್ಟಣೆಯನ್ನು ಚರ್ಚಿಸಿದ್ದೇವೆ, ಆದರೆ ಡಾಟ್‌ಕ್ಲೌಡ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಬಗ್ಗೆ ಏನು?
ವೇದಿಕೆಯು ವಿವಿಧ ಕಾರ್ಯಗಳಿಗೆ ಜವಾಬ್ದಾರರಾಗಿರುವ ಸುಮಾರು ನೂರು ಮೈಕ್ರೊ ಸರ್ವೀಸ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. ಕೆಲವರು ಇತರರಿಂದ ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸಿದರು, ಮತ್ತು ಕೆಲವರು ಇತರ ಸೇವೆಗಳಿಗೆ ಸಂಪರ್ಕ ಹೊಂದಿದ ಹಿನ್ನೆಲೆ ಕೆಲಸಗಾರರು ಆದರೆ ಸಂಪರ್ಕಗಳನ್ನು ಸ್ವತಃ ಸ್ವೀಕರಿಸಲಿಲ್ಲ. ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ, ಪ್ರತಿಯೊಂದು ಸೇವೆಯು ಸಂಪರ್ಕಿಸಬೇಕಾದ ವಿಳಾಸಗಳ ಅಂತಿಮ ಬಿಂದುಗಳನ್ನು ತಿಳಿದಿರಬೇಕು.
ಅನೇಕ ಉನ್ನತ ಮಟ್ಟದ ಸೇವೆಗಳು ಮೇಲೆ ವಿವರಿಸಿದ ರೂಟಿಂಗ್ ಮೆಶ್ ಅನ್ನು ಬಳಸಬಹುದು. ವಾಸ್ತವವಾಗಿ, ಡಾಟ್‌ಕ್ಲೌಡ್‌ನ ನೂರಕ್ಕೂ ಹೆಚ್ಚು ಮೈಕ್ರೊ ಸರ್ವೀಸ್‌ಗಳನ್ನು ಡಾಟ್‌ಕ್ಲೌಡ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿಯೇ ನಿಯಮಿತ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಾಗಿ ನಿಯೋಜಿಸಲಾಗಿದೆ. ಆದರೆ ಕಡಿಮೆ ಸಂಖ್ಯೆಯ ಕೆಳಮಟ್ಟದ ಸೇವೆಗಳಿಗೆ (ವಿಶೇಷವಾಗಿ ಈ ರೂಟಿಂಗ್ ಮೆಶ್ ಅನ್ನು ಅಳವಡಿಸುವವರಿಗೆ) ಸರಳವಾದ ಏನಾದರೂ ಅಗತ್ಯವಿದೆ, ಕಡಿಮೆ ಅವಲಂಬನೆಗಳು (ಅವರು ಕೆಲಸ ಮಾಡಲು ತಮ್ಮ ಮೇಲೆ ಅವಲಂಬಿತರಾಗದ ಕಾರಣ - ಉತ್ತಮ ಹಳೆಯ ಕೋಳಿ ಮತ್ತು ಮೊಟ್ಟೆಯ ಸಮಸ್ಯೆ).
ಈ ಕೆಳಮಟ್ಟದ, ಮಿಷನ್-ನಿರ್ಣಾಯಕ ಸೇವೆಗಳನ್ನು ಕೆಲವು ಪ್ರಮುಖ ನೋಡ್ಗಳಲ್ಲಿ ನೇರವಾಗಿ ಕಂಟೇನರ್‌ಗಳನ್ನು ಚಲಾಯಿಸುವ ಮೂಲಕ ನಿಯೋಜಿಸಲಾಗಿದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಪ್ರಮಾಣಿತ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಸೇವೆಗಳನ್ನು ಬಳಸಲಾಗಿಲ್ಲ: ಲಿಂಕರ್, ಶೆಡ್ಯೂಲರ್ ಮತ್ತು ರನ್ನರ್. ನೀವು ಆಧುನಿಕ ಕಂಟೇನರ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಿಗೆ ಹೋಲಿಸಲು ಬಯಸಿದರೆ, ಇದು ನಿಯಂತ್ರಣ ಸಮತಲವನ್ನು ಚಾಲನೆ ಮಾಡುವಂತಿದೆ docker run ಕಾರ್ಯವನ್ನು ಕುಬರ್ನೆಟ್ಸ್‌ಗೆ ನಿಯೋಜಿಸುವ ಬದಲು ನೇರವಾಗಿ ನೋಡ್ಗಳಲ್ಲಿ. ಇದು ಪರಿಕಲ್ಪನೆಯಲ್ಲಿ ಸಾಕಷ್ಟು ಹೋಲುತ್ತದೆ , ಇದು ಬಳಸುತ್ತದೆ ಅಥವಾ ಸ್ವತಂತ್ರ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಬೂಟ್ ಮಾಡುವಾಗ.
ಈ ಸೇವೆಗಳನ್ನು ಸರಳ ಮತ್ತು ಕಚ್ಚಾ ರೀತಿಯಲ್ಲಿ ಬಹಿರಂಗಪಡಿಸಲಾಗಿದೆ: YAML ಫೈಲ್ ಅವರ ಹೆಸರುಗಳು ಮತ್ತು ವಿಳಾಸಗಳನ್ನು ಪಟ್ಟಿಮಾಡಿದೆ; ಮತ್ತು ಪ್ರತಿ ಕ್ಲೈಂಟ್ ನಿಯೋಜನೆಗಾಗಿ ಈ YAML ಫೈಲ್‌ನ ನಕಲನ್ನು ತೆಗೆದುಕೊಳ್ಳಬೇಕಾಗಿತ್ತು.
ಒಂದೆಡೆ, ಇದು ಅತ್ಯಂತ ವಿಶ್ವಾಸಾರ್ಹವಾಗಿದೆ ಏಕೆಂದರೆ ಇದಕ್ಕೆ ಝೂಕೀಪರ್ (ನೆನಪಿಡಿ, etcd ಅಥವಾ ಕಾನ್ಸುಲ್ ಆ ಸಮಯದಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ) ನಂತಹ ಬಾಹ್ಯ ಕೀ/ಮೌಲ್ಯದ ಅಂಗಡಿಯ ಬೆಂಬಲ ಅಗತ್ಯವಿಲ್ಲ. ಮತ್ತೊಂದೆಡೆ, ಇದು ಸೇವೆಗಳನ್ನು ಸರಿಸಲು ಕಷ್ಟಕರವಾಗಿದೆ. ಪ್ರತಿ ಬಾರಿ ನಡೆಸುವಿಕೆಯನ್ನು ಮಾಡಿದಾಗ, ಎಲ್ಲಾ ಕ್ಲೈಂಟ್‌ಗಳು ನವೀಕರಿಸಿದ YAML ಫೈಲ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾರೆ (ಮತ್ತು ಸಂಭಾವ್ಯವಾಗಿ ರೀಬೂಟ್ ಮಾಡಿ). ತುಂಬಾ ಆರಾಮದಾಯಕವಲ್ಲ!
ತರುವಾಯ, ನಾವು ಹೊಸ ಯೋಜನೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ, ಅಲ್ಲಿ ಪ್ರತಿ ಕ್ಲೈಂಟ್ ಸ್ಥಳೀಯ ಪ್ರಾಕ್ಸಿ ಸರ್ವರ್‌ಗೆ ಸಂಪರ್ಕಗೊಂಡಿದೆ. ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ ಬದಲಿಗೆ, ಇದು ಸೇವೆಯ ಪೋರ್ಟ್ ಸಂಖ್ಯೆಯನ್ನು ಮಾತ್ರ ತಿಳಿದುಕೊಳ್ಳಬೇಕು ಮತ್ತು ಅದರ ಮೂಲಕ ಸಂಪರ್ಕಿಸಬೇಕು localhost. ಸ್ಥಳೀಯ ಪ್ರಾಕ್ಸಿ ಈ ಸಂಪರ್ಕವನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ನಿಜವಾದ ಸರ್ವರ್‌ಗೆ ರವಾನಿಸುತ್ತದೆ. ಈಗ, ಬ್ಯಾಕೆಂಡ್ ಅನ್ನು ಮತ್ತೊಂದು ಯಂತ್ರ ಅಥವಾ ಸ್ಕೇಲಿಂಗ್‌ಗೆ ಚಲಿಸುವಾಗ, ಎಲ್ಲಾ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ನವೀಕರಿಸುವ ಬದಲು, ನೀವು ಈ ಎಲ್ಲಾ ಸ್ಥಳೀಯ ಪ್ರಾಕ್ಸಿಗಳನ್ನು ಮಾತ್ರ ನವೀಕರಿಸಬೇಕಾಗುತ್ತದೆ; ಮತ್ತು ರೀಬೂಟ್ ಇನ್ನು ಮುಂದೆ ಅಗತ್ಯವಿಲ್ಲ.
(TLS ಸಂಪರ್ಕಗಳಲ್ಲಿ ದಟ್ಟಣೆಯನ್ನು ಸುತ್ತುವರಿಯಲು ಮತ್ತು ಸ್ವೀಕರಿಸುವ ಬದಿಯಲ್ಲಿ ಮತ್ತೊಂದು ಪ್ರಾಕ್ಸಿ ಸರ್ವರ್ ಅನ್ನು ಇರಿಸಲು ಯೋಜಿಸಲಾಗಿದೆ, ಹಾಗೆಯೇ ಸ್ವೀಕರಿಸುವ ಸೇವೆಯ ಭಾಗವಹಿಸುವಿಕೆ ಇಲ್ಲದೆ TLS ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಪರಿಶೀಲಿಸಲು ಸಹ ಯೋಜಿಸಲಾಗಿದೆ, ಇದು ಸಂಪರ್ಕಗಳನ್ನು ಮಾತ್ರ ಸ್ವೀಕರಿಸಲು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ localhost. ಇದರ ಬಗ್ಗೆ ನಂತರ ಇನ್ನಷ್ಟು).
ಇದು ತುಂಬಾ ಹೋಲುತ್ತದೆ Airbnb ನಿಂದ, ಆದರೆ ಗಮನಾರ್ಹ ವ್ಯತ್ಯಾಸವೆಂದರೆ SmartStack ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗಿದೆ ಮತ್ತು ಉತ್ಪಾದನೆಗೆ ನಿಯೋಜಿಸಲಾಗಿದೆ, ಆದರೆ ಡಾಟ್‌ಕ್ಲೌಡ್‌ನ ಆಂತರಿಕ ರೂಟಿಂಗ್ ವ್ಯವಸ್ಥೆಯನ್ನು ಡಾಟ್‌ಕ್ಲೌಡ್ ಡಾಕರ್ ಆಗಿ ಮಾರ್ಪಡಿಸಿದಾಗ ಸ್ಥಗಿತಗೊಳಿಸಲಾಯಿತು.
ನಾನು ವೈಯಕ್ತಿಕವಾಗಿ SmartStack ಅನ್ನು Istio, Linkerd ಮತ್ತು Consul Connect ನಂತಹ ವ್ಯವಸ್ಥೆಗಳಿಗೆ ಪೂರ್ವವರ್ತಿಗಳಲ್ಲಿ ಒಂದೆಂದು ಪರಿಗಣಿಸುತ್ತೇನೆ ಏಕೆಂದರೆ ಅವೆಲ್ಲವೂ ಒಂದೇ ಮಾದರಿಯನ್ನು ಅನುಸರಿಸುತ್ತವೆ:
- ಪ್ರತಿ ನೋಡ್‌ನಲ್ಲಿ ಪ್ರಾಕ್ಸಿ ರನ್ ಮಾಡಿ.
- ಗ್ರಾಹಕರು ಪ್ರಾಕ್ಸಿಗೆ ಸಂಪರ್ಕಿಸುತ್ತಾರೆ.
- ಬ್ಯಾಕೆಂಡ್‌ಗಳು ಬದಲಾದಾಗ ನಿಯಂತ್ರಣ ಪ್ಲೇನ್ ಪ್ರಾಕ್ಸಿ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ನವೀಕರಿಸುತ್ತದೆ.
- ... ಲಾಭ!
ಸೇವಾ ಜಾಲರಿಯ ಆಧುನಿಕ ಅಳವಡಿಕೆ
ಇಂದು ನಾವು ಇದೇ ರೀತಿಯ ಗ್ರಿಡ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕಾದರೆ, ನಾವು ಇದೇ ರೀತಿಯ ತತ್ವಗಳನ್ನು ಬಳಸಬಹುದು. ಉದಾಹರಣೆಗೆ, ಸ್ಪೇಸ್‌ನಲ್ಲಿರುವ ವಿಳಾಸಗಳಿಗೆ ಸೇವಾ ಹೆಸರುಗಳನ್ನು ಮ್ಯಾಪಿಂಗ್ ಮಾಡುವ ಮೂಲಕ ಆಂತರಿಕ DNS ವಲಯವನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ 127.0.0.0/8. ನಂತರ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿನ ಪ್ರತಿ ನೋಡ್‌ನಲ್ಲಿ HAProxy ಅನ್ನು ರನ್ ಮಾಡಿ, ಪ್ರತಿ ಸೇವಾ ವಿಳಾಸದಲ್ಲಿ ಸಂಪರ್ಕಗಳನ್ನು ಸ್ವೀಕರಿಸಿ (ಆ ಸಬ್‌ನೆಟ್‌ನಲ್ಲಿ 127.0.0.0/8) ಮತ್ತು ಸರಿಯಾದ ಬ್ಯಾಕೆಂಡ್‌ಗಳಿಗೆ ಲೋಡ್ ಅನ್ನು ಮರುನಿರ್ದೇಶಿಸುವುದು/ಸಮತೋಲನ ಮಾಡುವುದು. HAProxy ಸಂರಚನೆಯನ್ನು ನಿಯಂತ್ರಿಸಬಹುದು , ಇತ್ಯಾದಿ ಅಥವಾ ಕಾನ್ಸುಲ್‌ನಲ್ಲಿ ಬ್ಯಾಕೆಂಡ್ ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಲು ನಿಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಡುತ್ತದೆ ಮತ್ತು ಅಗತ್ಯವಿದ್ದಾಗ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನವೀಕರಿಸಿದ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು HAProxy ಗೆ ತಳ್ಳುತ್ತದೆ.
ಇದು ಬಹುಮಟ್ಟಿಗೆ ಇಸ್ಟಿಯೋ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ! ಆದರೆ ಕೆಲವು ವ್ಯತ್ಯಾಸಗಳೊಂದಿಗೆ:
- ಉಪಯೋಗಗಳು HAProxy ಬದಲಿಗೆ.
- ಇತ್ಯಾದಿ ಅಥವಾ ಕಾನ್ಸುಲ್ ಬದಲಿಗೆ ಕುಬರ್ನೆಟ್ಸ್ API ಮೂಲಕ ಬ್ಯಾಕೆಂಡ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ.
- ಸೇವೆಗಳಿಗೆ 127.0.0.0/8 ಬದಲಿಗೆ ಆಂತರಿಕ ಸಬ್‌ನೆಟ್‌ನಲ್ಲಿ (ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ಐಪಿ ವಿಳಾಸಗಳು) ವಿಳಾಸಗಳನ್ನು ಹಂಚಲಾಗುತ್ತದೆ.
- ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್‌ಗಳ ನಡುವೆ ಪರಸ್ಪರ TLS ದೃಢೀಕರಣವನ್ನು ಸೇರಿಸಲು ಹೆಚ್ಚುವರಿ ಘಟಕವನ್ನು (ಸಿಟಾಡೆಲ್) ಹೊಂದಿದೆ.
- ಸರ್ಕ್ಯೂಟ್ ಬ್ರೇಕಿಂಗ್, ಡಿಸ್ಟ್ರಿಬ್ಯೂಟ್ ಟ್ರೇಸಿಂಗ್, ಕ್ಯಾನರಿ ನಿಯೋಜನೆ ಮುಂತಾದ ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ.
ಕೆಲವು ವ್ಯತ್ಯಾಸಗಳನ್ನು ತ್ವರಿತವಾಗಿ ನೋಡೋಣ.
ಪ್ರತಿನಿಧಿ ಪ್ರಾಕ್ಸಿ
ಎನ್ವಾಯ್ ಪ್ರಾಕ್ಸಿಯನ್ನು ಲಿಫ್ಟ್ ಬರೆದಿದ್ದಾರೆ [ಟ್ಯಾಕ್ಸಿ ಮಾರುಕಟ್ಟೆಯಲ್ಲಿ ಉಬರ್‌ನ ಪ್ರತಿಸ್ಪರ್ಧಿ - ಅಂದಾಜು. ಲೇನ್]. ಇದು ಇತರ ಪ್ರಾಕ್ಸಿಗಳಿಗೆ (ಉದಾ. HAProxy, Nginx, Traefik...) ಹಲವು ವಿಧಗಳಲ್ಲಿ ಹೋಲುತ್ತದೆ, ಆದರೆ ಇತರ ಪ್ರಾಕ್ಸಿಗಳ ಕೊರತೆಯಿರುವ ವೈಶಿಷ್ಟ್ಯಗಳ ಅಗತ್ಯವಿರುವುದರಿಂದ Lyft ಅವರದನ್ನು ಬರೆದರು ಮತ್ತು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಒಂದನ್ನು ವಿಸ್ತರಿಸುವ ಬದಲು ಹೊಸದನ್ನು ಮಾಡಲು ಇದು ಚುರುಕಾಗಿ ಕಾಣುತ್ತದೆ.
ರಾಯಭಾರಿಯನ್ನು ಸ್ವಂತವಾಗಿ ಬಳಸಬಹುದು. ನಾನು ಇತರ ಸೇವೆಗಳಿಗೆ ಸಂಪರ್ಕಿಸಲು ಅಗತ್ಯವಿರುವ ನಿರ್ದಿಷ್ಟ ಸೇವೆಯನ್ನು ಹೊಂದಿದ್ದರೆ, ನಾನು ಅದನ್ನು ಎನ್ವಾಯ್‌ಗೆ ಸಂಪರ್ಕಿಸಲು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು, ಮತ್ತು ಗೋಚರತೆಯಂತಹ ಹೆಚ್ಚಿನ ಹೆಚ್ಚಿನ ಹೆಚ್ಚುವರಿ ಕಾರ್ಯಗಳನ್ನು ಪಡೆಯುವಾಗ, ಇತರ ಸೇವೆಗಳ ಸ್ಥಳದೊಂದಿಗೆ ಡೈನಾಮಿಕ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು ಮತ್ತು ಮರುಸಂರಚಿಸಬಹುದು. ಕಸ್ಟಮ್ ಕ್ಲೈಂಟ್ ಲೈಬ್ರರಿಯ ಬದಲಿಗೆ ಅಥವಾ ಕೋಡ್‌ಗೆ ಕರೆ ಟ್ರೇಸ್‌ಗಳನ್ನು ಇಂಜೆಕ್ಟ್ ಮಾಡುವ ಬದಲು, ನಾವು ದಟ್ಟಣೆಯನ್ನು ಎನ್ವಾಯ್‌ಗೆ ಕಳುಹಿಸುತ್ತೇವೆ ಮತ್ತು ಅದು ನಮಗಾಗಿ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ.
ಆದರೆ ರಾಯಭಾರಿಯಾಗಿ ಕೆಲಸ ಮಾಡುವ ಸಾಮರ್ಥ್ಯವೂ ಇದೆ ಡೇಟಾ ಪ್ಲೇನ್ (ಡೇಟಾ ಪ್ಲೇನ್) ಸೇವಾ ಜಾಲರಿಗಾಗಿ. ಇದರರ್ಥ ಎನ್ವಾಯ್ ಅನ್ನು ಈಗ ಈ ಸೇವಾ ಜಾಲರಿಗಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ ನಿಯಂತ್ರಣ ವಿಮಾನ (ನಿಯಂತ್ರಣ ವಿಮಾನ).
ನಿಯಂತ್ರಣ ವಿಮಾನ
ನಿಯಂತ್ರಣ ಸಮತಲಕ್ಕಾಗಿ, ಇಸ್ಟಿಯೊ ಕುಬರ್ನೆಟ್ಸ್ API ಅನ್ನು ಅವಲಂಬಿಸಿದೆ. ಇದು confd ಅನ್ನು ಬಳಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಭಿನ್ನವಾಗಿಲ್ಲ, ಇದು ಡೇಟಾ ಸ್ಟೋರ್‌ನಲ್ಲಿ ಕೀಗಳ ಸೆಟ್ ಅನ್ನು ವೀಕ್ಷಿಸಲು etcd ಅಥವಾ ಕಾನ್ಸುಲ್ ಅನ್ನು ಅವಲಂಬಿಸಿದೆ. ಕುಬರ್ನೆಟ್ಸ್ ಸಂಪನ್ಮೂಲಗಳ ಗುಂಪನ್ನು ವೀಕ್ಷಿಸಲು ಇಸ್ಟಿಯೊ ಕುಬರ್ನೆಟ್ಸ್ API ಅನ್ನು ಬಳಸುತ್ತದೆ.
ಈ ಮತ್ತು ನಂತರ: ನಾನು ವೈಯಕ್ತಿಕವಾಗಿ ಇದನ್ನು ಉಪಯುಕ್ತವೆಂದು ಕಂಡುಕೊಂಡಿದ್ದೇನೆ ಇದು ಓದುತ್ತದೆ:
ಕುಬರ್ನೆಟ್ಸ್ API ಸರ್ವರ್ ಒಂದು "ಮೂಕ ಸರ್ವರ್" ಆಗಿದ್ದು ಅದು API ಸಂಪನ್ಮೂಲಗಳಿಗಾಗಿ ಸಂಗ್ರಹಣೆ, ಆವೃತ್ತಿ, ಊರ್ಜಿತಗೊಳಿಸುವಿಕೆ, ನವೀಕರಿಸುವಿಕೆ ಮತ್ತು ಶಬ್ದಾರ್ಥವನ್ನು ನೀಡುತ್ತದೆ.
ಇಸ್ಟಿಯೊವನ್ನು ಕುಬರ್ನೆಟ್ಸ್ ಜೊತೆ ಕೆಲಸ ಮಾಡಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ; ಮತ್ತು ನೀವು ಅದನ್ನು ಕುಬರ್ನೆಟ್ಸ್‌ನ ಹೊರಗೆ ಬಳಸಲು ಬಯಸಿದರೆ, ನಂತರ ನೀವು ಕುಬರ್ನೆಟ್ಸ್ API ಸರ್ವರ್‌ನ ನಿದರ್ಶನವನ್ನು ರನ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ (ಮತ್ತು etcd ಸಹಾಯಕ ಸೇವೆ).
ಸೇವಾ ವಿಳಾಸಗಳು
ಇಸ್ಟಿಯೊ ಕುಬರ್ನೆಟ್ಸ್ ನಿಯೋಜಿಸುವ ಕ್ಲಸ್ಟರ್‌ಐಪಿ ವಿಳಾಸಗಳನ್ನು ಅವಲಂಬಿಸಿದೆ, ಆದ್ದರಿಂದ ಇಸ್ಟಿಯೊ ಸೇವೆಗಳು ಆಂತರಿಕ ವಿಳಾಸವನ್ನು ಪಡೆಯುತ್ತವೆ (ಶ್ರೇಣಿಯಲ್ಲಿಲ್ಲ 127.0.0.0/8).
Istio ಇಲ್ಲದೆ Kubernetes ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ಸೇವೆಗಾಗಿ ClusterIP ವಿಳಾಸಕ್ಕೆ ಟ್ರಾಫಿಕ್ ಅನ್ನು kube-proxy ನಿಂದ ತಡೆಹಿಡಿಯಲಾಗುತ್ತದೆ ಮತ್ತು ಆ ಪ್ರಾಕ್ಸಿಯ ಬ್ಯಾಕೆಂಡ್‌ಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ. ನೀವು ತಾಂತ್ರಿಕ ವಿವರಗಳಲ್ಲಿ ಆಸಕ್ತಿ ಹೊಂದಿದ್ದರೆ, ClusterIP ವಿಳಾಸಕ್ಕೆ ಹೋಗುವ ಸಂಪರ್ಕಗಳ ಗಮ್ಯಸ್ಥಾನ IP ವಿಳಾಸಗಳನ್ನು ಪುನಃ ಬರೆಯಲು kube-proxy iptables ನಿಯಮಗಳನ್ನು (ಅಥವಾ IPVS ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳು, ಅದನ್ನು ಹೇಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ) ಹೊಂದಿಸುತ್ತದೆ.
ಒಮ್ಮೆ ಇಸ್ಟಿಯೊವನ್ನು ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಸ್ಥಾಪಿಸಿದರೆ, ಕಂಟೇನರ್ ಅನ್ನು ಪರಿಚಯಿಸುವ ಮೂಲಕ ನಿರ್ದಿಷ್ಟ ಗ್ರಾಹಕನಿಗೆ ಅಥವಾ ಸಂಪೂರ್ಣ ನೇಮ್‌ಸ್ಪೇಸ್‌ಗೆ ಅದನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಸಕ್ರಿಯಗೊಳಿಸುವವರೆಗೆ ಏನೂ ಬದಲಾಗುವುದಿಲ್ಲ sidecar ಕಸ್ಟಮ್ ಪಾಡ್‌ಗಳಾಗಿ. ಈ ಕಂಟೇನರ್ ರಾಯಭಾರಿಯ ನಿದರ್ಶನವನ್ನು ಸ್ಪಿನ್ ಅಪ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಇತರ ಸೇವೆಗಳಿಗೆ ಹೋಗುವ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಪ್ರತಿಬಂಧಿಸಲು ಮತ್ತು ಆ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಎನ್ವಾಯ್‌ಗೆ ಮರುನಿರ್ದೇಶಿಸಲು iptables ನಿಯಮಗಳನ್ನು ಹೊಂದಿಸುತ್ತದೆ.
ಕುಬರ್ನೆಟ್ಸ್ DNS ನೊಂದಿಗೆ ಸಂಯೋಜಿಸಿದಾಗ, ನಮ್ಮ ಕೋಡ್ ಸೇವೆಯ ಹೆಸರು ಮತ್ತು ಎಲ್ಲದರ ಮೂಲಕ "ಕೇವಲ ಕೆಲಸ ಮಾಡುತ್ತದೆ" ಎಂದು ಸಂಪರ್ಕಿಸಬಹುದು ಎಂದರ್ಥ. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ನಮ್ಮ ಕೋಡ್ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳುತ್ತದೆ http://api/v1/users/4242ನಂತರ api ಗಾಗಿ ವಿನಂತಿಯನ್ನು ಪರಿಹರಿಸಿ 10.97.105.48, iptables ನಿಯಮಗಳು 10.97.105.48 ರಿಂದ ಸಂಪರ್ಕಗಳನ್ನು ಪ್ರತಿಬಂಧಿಸುತ್ತದೆ ಮತ್ತು ಅವುಗಳನ್ನು ಸ್ಥಳೀಯ ರಾಯಭಾರಿ ಪ್ರಾಕ್ಸಿಗೆ ರವಾನಿಸುತ್ತದೆ ಮತ್ತು ಸ್ಥಳೀಯ ಪ್ರಾಕ್ಸಿ ವಿನಂತಿಯನ್ನು ನಿಜವಾದ ಬ್ಯಾಕೆಂಡ್ API ಗೆ ರವಾನಿಸುತ್ತದೆ. ಓಹ್!
ಹೆಚ್ಚುವರಿ ಅಲಂಕಾರಗಳು
MTLS (ಮ್ಯೂಚುಯಲ್ TLS) ಮೂಲಕ ಇಸ್ಟಿಯೊ ಎಂಡ್-ಟು-ಎಂಡ್ ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಮತ್ತು ದೃಢೀಕರಣವನ್ನು ಸಹ ಒದಗಿಸುತ್ತದೆ. ಎಂಬ ಘಟಕ ಸಿಟಾಡೆಲ್.
ಒಂದು ಘಟಕವೂ ಇದೆ ಮಿಕ್ಸರ್, ಯಾವ ದೂತರು ವಿನಂತಿಸಬಹುದು ಪ್ರತಿಯೊಂದರಲ್ಲೂ ಶಿರೋಲೇಖಗಳು, ಬ್ಯಾಕೆಂಡ್ ಲೋಡ್, ಇತ್ಯಾದಿಗಳಂತಹ ವಿವಿಧ ಅಂಶಗಳ ಆಧಾರದ ಮೇಲೆ ಆ ವಿನಂತಿಯ ಕುರಿತು ವಿಶೇಷ ನಿರ್ಧಾರವನ್ನು ಮಾಡಲು ವಿನಂತಿಸಿ... (ಚಿಂತಿಸಬೇಡಿ: ಮಿಕ್ಸರ್ ಚಾಲನೆಯಲ್ಲಿರಲು ಹಲವು ಮಾರ್ಗಗಳಿವೆ, ಮತ್ತು ಅದು ಕ್ರ್ಯಾಶ್ ಆಗಿದ್ದರೂ ಸಹ, ದೂತರು ಕೆಲಸ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತಾರೆ ಪ್ರಾಕ್ಸಿಯಾಗಿ ಉತ್ತಮವಾಗಿದೆ) .
ಮತ್ತು, ಸಹಜವಾಗಿ, ನಾವು ಗೋಚರತೆಯನ್ನು ಉಲ್ಲೇಖಿಸಿದ್ದೇವೆ: ವಿತರಿಸಿದ ಟ್ರೇಸಿಂಗ್ ಅನ್ನು ಒದಗಿಸುವಾಗ ದೂತರು ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತಾರೆ. ಮೈಕ್ರೊಸರ್ವಿಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನಲ್ಲಿ, ಒಂದು API ವಿನಂತಿಯು ಮೈಕ್ರೊಸರ್ವಿಸ್ A, B, C ಮತ್ತು D ಮೂಲಕ ಹಾದು ಹೋಗಬೇಕಾದರೆ, ಲಾಗಿನ್ ಆದ ಮೇಲೆ, ವಿತರಿಸಿದ ಟ್ರೇಸಿಂಗ್ ವಿನಂತಿಗೆ ಅನನ್ಯ ಗುರುತಿಸುವಿಕೆಯನ್ನು ಸೇರಿಸುತ್ತದೆ ಮತ್ತು ಈ ಎಲ್ಲಾ ಮೈಕ್ರೋಸರ್ವಿಸ್‌ಗಳಿಗೆ ಉಪ ವಿನಂತಿಗಳ ಮೂಲಕ ಈ ಗುರುತಿಸುವಿಕೆಯನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ, ಅನುಮತಿಸುತ್ತದೆ ಎಲ್ಲಾ ಸಂಬಂಧಿತ ಕರೆಗಳನ್ನು ಸೆರೆಹಿಡಿಯಲು ವಿಳಂಬಗಳು, ಇತ್ಯಾದಿ.
ಅಭಿವೃದ್ಧಿಪಡಿಸಿ ಅಥವಾ ಖರೀದಿಸಿ
ಇಸ್ಟಿಯೊ ಸಂಕೀರ್ಣವಾದ ಖ್ಯಾತಿಯನ್ನು ಹೊಂದಿದೆ. ಇದಕ್ಕೆ ವ್ಯತಿರಿಕ್ತವಾಗಿ, ಈ ಪೋಸ್ಟ್‌ನ ಆರಂಭದಲ್ಲಿ ನಾನು ವಿವರಿಸಿದ ರೂಟಿಂಗ್ ಮೆಶ್ ಅನ್ನು ನಿರ್ಮಿಸುವುದು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪರಿಕರಗಳನ್ನು ಬಳಸಿಕೊಂಡು ತುಲನಾತ್ಮಕವಾಗಿ ಸರಳವಾಗಿದೆ. ಆದ್ದರಿಂದ, ಬದಲಿಗೆ ನಿಮ್ಮ ಸ್ವಂತ ಸೇವಾ ಜಾಲರಿಯನ್ನು ರಚಿಸಲು ಅರ್ಥವಿದೆಯೇ?
ನಾವು ಸಾಧಾರಣ ಅಗತ್ಯಗಳನ್ನು ಹೊಂದಿದ್ದರೆ (ನಮಗೆ ಗೋಚರತೆ, ಸರ್ಕ್ಯೂಟ್ ಬ್ರೇಕರ್ ಮತ್ತು ಇತರ ಸೂಕ್ಷ್ಮತೆಗಳ ಅಗತ್ಯವಿಲ್ಲ), ನಂತರ ಆಲೋಚನೆಗಳು ನಮ್ಮ ಸ್ವಂತ ಸಾಧನವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಬರುತ್ತವೆ. ಆದರೆ ನಾವು ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಬಳಸಿದರೆ, ಅದರ ಅಗತ್ಯವಿರುವುದಿಲ್ಲ ಏಕೆಂದರೆ ಕುಬರ್ನೆಟ್ಸ್ ಈಗಾಗಲೇ ಸೇವೆಯ ಅನ್ವೇಷಣೆ ಮತ್ತು ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ಗಾಗಿ ಮೂಲಭೂತ ಸಾಧನಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ.
ಆದರೆ ನಾವು ಸುಧಾರಿತ ಅವಶ್ಯಕತೆಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಸೇವಾ ಜಾಲರಿಯನ್ನು "ಖರೀದಿ" ಮಾಡುವುದು ಉತ್ತಮ ಆಯ್ಕೆಯಾಗಿದೆ. (ಇದು ಯಾವಾಗಲೂ "ಖರೀದಿ" ಆಗಿರುವುದಿಲ್ಲ ಏಕೆಂದರೆ ಇಸ್ಟಿಯೊ ಓಪನ್ ಸೋರ್ಸ್ ಆಗಿದೆ, ಆದರೆ ಅದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ನಿಯೋಜಿಸಲು ಮತ್ತು ನಿರ್ವಹಿಸಲು ನಾವು ಇನ್ನೂ ಎಂಜಿನಿಯರಿಂಗ್ ಸಮಯವನ್ನು ಹೂಡಿಕೆ ಮಾಡಬೇಕಾಗಿದೆ.)
ನಾನು Istio, Linkerd ಅಥವಾ Consul Connect ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಬೇಕೇ?
ಇಲ್ಲಿಯವರೆಗೆ ನಾವು ಇಸ್ಟಿಯೊ ಬಗ್ಗೆ ಮಾತ್ರ ಮಾತನಾಡಿದ್ದೇವೆ, ಆದರೆ ಇದು ಕೇವಲ ಸೇವಾ ಜಾಲರಿಯಲ್ಲ. ಜನಪ್ರಿಯ ಪರ್ಯಾಯವೆಂದರೆ , ಮತ್ತು ಹೆಚ್ಚು ಇದೆ .
ಯಾವ ಆಯ್ಕೆ?
ಪ್ರಾಮಾಣಿಕವಾಗಿ, ನನಗೆ ಗೊತ್ತಿಲ್ಲ. ಸದ್ಯಕ್ಕೆ ನಾನು ಈ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುವಷ್ಟು ಸಮರ್ಥನೆಂದು ಪರಿಗಣಿಸುವುದಿಲ್ಲ. ಕೆಲವು ಇವೆ ಈ ಉಪಕರಣಗಳ ಹೋಲಿಕೆ ಮತ್ತು ಸಹ .
ಅಂತಹ ಸಾಧನವನ್ನು ಬಳಸುವುದು ಒಂದು ಭರವಸೆಯ ವಿಧಾನವಾಗಿದೆ . ಸೇವಾ ಮೆಶ್‌ಗಳಿಂದ ತೆರೆದುಕೊಳ್ಳುವ API ಗಳನ್ನು ಸರಳೀಕರಿಸಲು ಮತ್ತು ಏಕೀಕರಿಸಲು ಇದು ಅಮೂರ್ತ ಪದರವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ. ವಿಭಿನ್ನ ಸೇವಾ ಜಾಲರಿಗಳ ನಿರ್ದಿಷ್ಟ (ಮತ್ತು, ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ತುಲನಾತ್ಮಕವಾಗಿ ಸಂಕೀರ್ಣವಾದ) API ಗಳನ್ನು ಕಲಿಯುವ ಬದಲು, ನಾವು SuperGloo ನ ಸರಳವಾದ ರಚನೆಗಳನ್ನು ಬಳಸಬಹುದು - ಮತ್ತು ನಾವು HTTP ಇಂಟರ್‌ಫೇಸ್‌ಗಳು ಮತ್ತು ಬ್ಯಾಕೆಂಡ್‌ಗಳನ್ನು ವಿವರಿಸುವ ಮಧ್ಯಂತರ ಕಾನ್ಫಿಗರೇಶನ್ ಸ್ವರೂಪವನ್ನು ಹೊಂದಿರುವಂತೆ ಸುಲಭವಾಗಿ ಒಂದರಿಂದ ಇನ್ನೊಂದಕ್ಕೆ ಬದಲಾಯಿಸಬಹುದು. Nginx, HAProxy, Traefik, Apache... ಗಾಗಿ ನಿಜವಾದ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ರಚಿಸುವುದು.
ನಾನು Istio ಮತ್ತು SuperGloo ನೊಂದಿಗೆ ಸ್ವಲ್ಪ ತೊಡಗಿಸಿಕೊಂಡಿದ್ದೇನೆ ಮತ್ತು ಮುಂದಿನ ಲೇಖನದಲ್ಲಿ SuperGloo ಅನ್ನು ಬಳಸಿಕೊಂಡು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕ್ಲಸ್ಟರ್‌ಗೆ Istio ಅಥವಾ Linkerd ಅನ್ನು ಹೇಗೆ ಸೇರಿಸುವುದು ಮತ್ತು ಎರಡನೆಯದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸಲು ಬಯಸುತ್ತೇನೆ, ಅಂದರೆ, ನೀವು ಬದಲಾಯಿಸಲು ಅನುಮತಿಸುತ್ತದೆ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ಓವರ್‌ರೈಟ್ ಮಾಡದೆಯೇ ಒಂದು ಸೇವಾ ಜಾಲರಿ ಇನ್ನೊಂದಕ್ಕೆ.
ಮೂಲ: www.habr.com