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

(ಮತ್ತು ಈ ಲೇಖನದ ಕೊನೆಯಲ್ಲಿ, ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ತಜ್ಞ ಕ್ರಿಸ್ ರಿಚರ್ಡ್‌ಸನ್‌ರಿಂದ ಮೂರು ದಿನಗಳ ಸೆಮಿನಾರ್‌ಗೆ ಹಾಜರಾಗುವ ಅವಕಾಶದ ಬಗ್ಗೆ ನಾನು ಮಾತನಾಡುತ್ತೇನೆ).

ನಾವು ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗೆ ಹೇಗೆ ಬಂದೆವು

Avito ವಿಶ್ವದ ಅತಿದೊಡ್ಡ ವರ್ಗೀಕೃತ ಸೈಟ್‌ಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ; ದಿನಕ್ಕೆ 15 ಮಿಲಿಯನ್‌ಗಿಂತಲೂ ಹೆಚ್ಚು ಹೊಸ ಜಾಹೀರಾತುಗಳನ್ನು ಪ್ರಕಟಿಸಲಾಗುತ್ತದೆ. ನಮ್ಮ ಬ್ಯಾಕೆಂಡ್ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 20 ಸಾವಿರಕ್ಕೂ ಹೆಚ್ಚು ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ. ನಾವು ಪ್ರಸ್ತುತ ನೂರಾರು ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ.

ನಾವು ಈಗ ಹಲವಾರು ವರ್ಷಗಳಿಂದ ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ನಿರ್ಮಿಸುತ್ತಿದ್ದೇವೆ. ಹೇಗೆ ನಿಖರವಾಗಿ - ನಮ್ಮ ಸಹೋದ್ಯೋಗಿಗಳು ವಿವರವಾಗಿ ಹೇಳಿದರು RIT++ 2017 ರಲ್ಲಿ ನಮ್ಮ ವಿಭಾಗದಲ್ಲಿ. CodeFest 2017 ನಲ್ಲಿ (ನೋಡಿ. видео), ಸೆರ್ಗೆಯ್ ಓರ್ಲೋವ್ ಮತ್ತು ಮಿಖಾಯಿಲ್ ಪ್ರೊಕೊಪ್ಚುಕ್ ನಮಗೆ ಸೂಕ್ಷ್ಮ ಸೇವೆಗಳಿಗೆ ಏಕೆ ಪರಿವರ್ತನೆ ಬೇಕು ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ ಇಲ್ಲಿ ಯಾವ ಪಾತ್ರವನ್ನು ವಹಿಸಿದರು ಎಂಬುದನ್ನು ವಿವರವಾಗಿ ವಿವರಿಸಿದರು. ಸರಿ, ಈಗ ನಾವು ಅಂತಹ ವಾಸ್ತುಶಿಲ್ಪದಲ್ಲಿ ಅಂತರ್ಗತವಾಗಿರುವ ಸ್ಕೇಲಿಂಗ್ ವೆಚ್ಚವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಎಲ್ಲವನ್ನೂ ಮಾಡುತ್ತಿದ್ದೇವೆ.

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

ಈಗ PaaS CLI ಯುಟಿಲಿಟಿಯಲ್ಲಿ, ಒಂದು ಆಜ್ಞೆಯೊಂದಿಗೆ ಹೊಸ ಸೇವೆಯನ್ನು ರಚಿಸಲಾಗಿದೆ ಮತ್ತು ಹೊಸ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಇನ್ನೆರಡು ಸೇರಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಹಂತಕ್ಕೆ ನಿಯೋಜಿಸಲಾಗುತ್ತದೆ.

"ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ವಿಘಟನೆಯ" ಯುಗವನ್ನು ಹೇಗೆ ಜಯಿಸುವುದು

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

ಹೆಚ್ಚುವರಿಯಾಗಿ, ಮೈಕ್ರೊ ಸರ್ವಿಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಪರಿಣಾಮಕಾರಿಯಾಗಿರಲು, ಹಲವು ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಸ್ಥಾಪಿಸುವ ಅಗತ್ಯವಿದೆ, ಅವುಗಳೆಂದರೆ:

• ಲಾಗಿಂಗ್;
• ವಿನಂತಿಯನ್ನು ಪತ್ತೆಹಚ್ಚುವಿಕೆ (ಜೇಗರ್);
• ದೋಷ ಒಟ್ಟುಗೂಡಿಸುವಿಕೆ (ಸೆಂಟ್ರಿ);
• ಸ್ಥಿತಿಗಳು, ಸಂದೇಶಗಳು, ಕುಬರ್ನೆಟ್ಸ್‌ನಿಂದ ಈವೆಂಟ್‌ಗಳು (ಈವೆಂಟ್ ಸ್ಟ್ರೀಮ್ ಪ್ರೊಸೆಸಿಂಗ್);
• ಓಟದ ಮಿತಿ / ಸರ್ಕ್ಯೂಟ್ ಬ್ರೇಕರ್ (ನೀವು ಹೈಸ್ಟ್ರಿಕ್ಸ್ ಅನ್ನು ಬಳಸಬಹುದು);
• ಸೇವಾ ಸಂಪರ್ಕದ ನಿಯಂತ್ರಣ (ನಾವು Netramesh ಅನ್ನು ಬಳಸುತ್ತೇವೆ);
• ಮೇಲ್ವಿಚಾರಣೆ (ಗ್ರಾಫನಾ);
• ಅಸೆಂಬ್ಲಿ (ಟೀಮ್‌ಸಿಟಿ);
• ಸಂವಹನ ಮತ್ತು ಅಧಿಸೂಚನೆ (ಸ್ಲಾಕ್, ಇಮೇಲ್);
• ಕಾರ್ಯ ಟ್ರ್ಯಾಕಿಂಗ್; (ಜಿರಾ)
• ದಸ್ತಾವೇಜನ್ನು ಸಿದ್ಧಪಡಿಸುವುದು.

ವ್ಯವಸ್ಥೆಯು ಅದರ ಸಮಗ್ರತೆಯನ್ನು ಕಳೆದುಕೊಳ್ಳುವುದಿಲ್ಲ ಮತ್ತು ಅದು ಮಾಪಕವಾಗುವಂತೆ ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಉಳಿಯುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ನಾವು Avito ನಲ್ಲಿ ಮೈಕ್ರೊ ಸರ್ವೀಸ್‌ಗಳ ಸಂಘಟನೆಯನ್ನು ಮರುಚಿಂತಿಸಿದ್ದೇವೆ.

ನಾವು ಸೂಕ್ಷ್ಮ ಸೇವೆಗಳನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತೇವೆ

ಹಲವಾರು Avito ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳಲ್ಲಿ ಏಕೀಕೃತ "ಪಕ್ಷದ ನೀತಿ"ಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಈ ಕೆಳಗಿನವು ಸಹಾಯ ಮಾಡುತ್ತದೆ:

• ಮೂಲಸೌಕರ್ಯವನ್ನು ಪದರಗಳಾಗಿ ವಿಭಜಿಸುವುದು;
• ಸೇವೆಯಾಗಿ ವೇದಿಕೆ (PaaS) ಪರಿಕಲ್ಪನೆ;
• ಮೈಕ್ರೊ ಸರ್ವೀಸ್‌ನೊಂದಿಗೆ ನಡೆಯುವ ಎಲ್ಲವನ್ನೂ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದು.

ಮೂಲಸೌಕರ್ಯ ಅಮೂರ್ತ ಪದರಗಳು ಮೂರು ಪದರಗಳನ್ನು ಒಳಗೊಂಡಿವೆ. ಮೇಲಿನಿಂದ ಕೆಳಕ್ಕೆ ಹೋಗೋಣ.

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

ಎಲ್ಲಾ ಪದರಗಳನ್ನು PaaS ನಿಂದ ಸಂಯೋಜಿಸಲಾಗಿದೆ. ಮತ್ತು ಈ ವೇದಿಕೆಯು ಪ್ರತಿಯಾಗಿ ಮೂರು ಭಾಗಗಳನ್ನು ಒಳಗೊಂಡಿದೆ.

I. ಜನರೇಟರ್‌ಗಳು, CLI ಯುಟಿಲಿಟಿ ಮೂಲಕ ನಿಯಂತ್ರಿಸಲಾಗುತ್ತದೆ. ಮೈಕ್ರೋಸರ್ವಿಸ್ ಅನ್ನು ಸರಿಯಾದ ರೀತಿಯಲ್ಲಿ ಮತ್ತು ಕನಿಷ್ಠ ಪ್ರಯತ್ನದಿಂದ ರಚಿಸಲು ಡೆವಲಪರ್‌ಗೆ ಸಹಾಯ ಮಾಡುವವಳು ಅವಳು.

II. ಏಕೀಕೃತ ಸಂಗ್ರಾಹಕ ಸಾಮಾನ್ಯ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ಮೂಲಕ ಎಲ್ಲಾ ಪರಿಕರಗಳ ನಿಯಂತ್ರಣದೊಂದಿಗೆ.

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

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

ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಮೈಕ್ರೋ ಸರ್ವಿಸ್ ಡೆವಲಪ್‌ಮೆಂಟ್ ಪೈಪ್‌ಲೈನ್ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ?

ಸಾಮಾನ್ಯವಾಗಿ, ಮೈಕ್ರೊ ಸರ್ವೀಸ್ ಸೃಷ್ಟಿ ಸರಪಳಿಯು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

CLI-ಪುಶ್ → ನಿರಂತರ ಏಕೀಕರಣ → ಬೇಕ್ → ನಿಯೋಜಿಸಿ → ಕೃತಕ ಪರೀಕ್ಷೆಗಳು → ಕ್ಯಾನರಿ ಪರೀಕ್ಷೆಗಳು → ಸ್ಕ್ವೀಜ್ ಪರೀಕ್ಷೆ → ಉತ್ಪಾದನೆ → ನಿರ್ವಹಣೆ.

ಈ ಕ್ರಮದಲ್ಲಿ ನಿಖರವಾಗಿ ಅದರ ಮೂಲಕ ಹೋಗೋಣ.

CLI-ಪುಶ್

• ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ಅನ್ನು ರಚಿಸುವುದು.
ಮೈಕ್ರೊ ಸರ್ವೀಸ್‌ಗಳನ್ನು ಹೇಗೆ ಮಾಡಬೇಕೆಂದು ಪ್ರತಿಯೊಬ್ಬ ಡೆವಲಪರ್‌ಗೆ ಕಲಿಸಲು ನಾವು ಬಹಳ ಸಮಯದಿಂದ ಹೆಣಗಾಡಿದ್ದೇವೆ. ಇದು ಸಂಗಮದಲ್ಲಿ ವಿವರವಾದ ಸೂಚನೆಗಳನ್ನು ಬರೆಯುವುದನ್ನು ಒಳಗೊಂಡಿತ್ತು. ಆದರೆ ಯೋಜನೆಗಳು ಬದಲಾಗಿವೆ ಮತ್ತು ಪೂರಕವಾಗಿವೆ. ಇದರ ಫಲಿತಾಂಶವೆಂದರೆ ಪ್ರಯಾಣದ ಆರಂಭದಲ್ಲಿ ಅಡಚಣೆಯು ಕಾಣಿಸಿಕೊಂಡಿತು: ಮೈಕ್ರೊ ಸರ್ವಿಸ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸಲು ಇದು ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಂಡಿತು ಮತ್ತು ಅವುಗಳ ರಚನೆಯ ಸಮಯದಲ್ಲಿ ಇನ್ನೂ ಸಮಸ್ಯೆಗಳು ಉದ್ಭವಿಸುತ್ತವೆ.

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

- ಟೆಂಪ್ಲೇಟ್ ಪ್ರಕಾರ ಸೇವೆಯನ್ನು ರಚಿಸುತ್ತದೆ - ಹಂತ ಹಂತವಾಗಿ, "ಮಾಂತ್ರಿಕ" ಮೋಡ್ನಲ್ಲಿ. ನಾವು Avito ಬ್ಯಾಕೆಂಡ್‌ನಲ್ಲಿ ಮುಖ್ಯ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಗಳಿಗೆ ಟೆಂಪ್ಲೇಟ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ: PHP, Golang ಮತ್ತು Python.

- ಒಂದು ಸಮಯದಲ್ಲಿ ಒಂದು ಆಜ್ಞೆಯು ನಿರ್ದಿಷ್ಟ ಗಣಕದಲ್ಲಿ ಸ್ಥಳೀಯ ಅಭಿವೃದ್ಧಿಗಾಗಿ ಪರಿಸರವನ್ನು ನಿಯೋಜಿಸುತ್ತದೆ - ಮಿನಿಕ್ಯೂಬ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ, ಹೆಲ್ಮ್ ಚಾರ್ಟ್‌ಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ರಚಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಸ್ಥಳೀಯ ಕುಬರ್ನೆಟ್‌ಗಳಲ್ಲಿ ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತದೆ.

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

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

- ಸ್ವಯಂ ಪರೀಕ್ಷೆಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ. ಖಾಲಿ ರೂಪದಲ್ಲಿ, ಆದರೆ ಬಳಕೆಗೆ ಸಾಕಷ್ಟು ಸೂಕ್ತವಾಗಿದೆ.

• ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ನಿಯೋಜನೆ.

ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ಅನ್ನು ನಿಯೋಜಿಸುವುದು ನಮಗೆ ಸ್ವಲ್ಪ ಕೆಲಸವಾಗಿತ್ತು. ಕೆಳಗಿನವುಗಳು ಬೇಕಾಗಿದ್ದವು:

I. ಡಾಕರ್‌ಫೈಲ್.

II. ಸಂರಚನೆ.
III. ಹೆಲ್ಮ್ ಚಾರ್ಟ್, ಇದು ಸ್ವತಃ ತೊಡಕಿನ ಮತ್ತು ಒಳಗೊಂಡಿದೆ:

- ಚಾರ್ಟ್ಗಳು ಸ್ವತಃ;
- ಟೆಂಪ್ಲೇಟ್ಗಳು;
- ವಿಭಿನ್ನ ಪರಿಸರಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡು ನಿರ್ದಿಷ್ಟ ಮೌಲ್ಯಗಳು.

ಕುಬರ್ನೆಟ್ಸ್ ಮ್ಯಾನಿಫೆಸ್ಟ್‌ಗಳನ್ನು ಪುನಃ ಕೆಲಸ ಮಾಡುವುದರಿಂದ ನಾವು ನೋವನ್ನು ತೆಗೆದುಕೊಂಡಿದ್ದೇವೆ ಆದ್ದರಿಂದ ಅವುಗಳು ಈಗ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಉತ್ಪತ್ತಿಯಾಗುತ್ತವೆ. ಆದರೆ ಮುಖ್ಯವಾಗಿ, ಅವರು ನಿಯೋಜನೆಯನ್ನು ಮಿತಿಗೆ ಸರಳಗೊಳಿಸಿದರು. ಇಂದಿನಿಂದ ನಾವು ಡಾಕರ್‌ಫೈಲ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಡೆವಲಪರ್ ಸಂಪೂರ್ಣ ಸಂರಚನೆಯನ್ನು ಒಂದೇ ಚಿಕ್ಕ app.toml ಫೈಲ್‌ನಲ್ಲಿ ಬರೆಯುತ್ತಾರೆ.

ಹೌದು, ಮತ್ತು app.toml ನಲ್ಲಿಯೇ ಒಂದು ನಿಮಿಷ ಮಾಡಲು ಏನೂ ಇಲ್ಲ. ಸೇವೆಯ ಎಲ್ಲಿ ಮತ್ತು ಎಷ್ಟು ನಕಲುಗಳನ್ನು ಸಂಗ್ರಹಿಸಬೇಕೆಂದು ನಾವು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತೇವೆ (ದೇವ್ ಸರ್ವರ್‌ನಲ್ಲಿ, ಸ್ಟೇಜಿಂಗ್‌ನಲ್ಲಿ, ಉತ್ಪಾದನೆಯಲ್ಲಿ), ಮತ್ತು ಅದರ ಅವಲಂಬನೆಗಳನ್ನು ಸೂಚಿಸುತ್ತೇವೆ. [ಎಂಜಿನ್] ಬ್ಲಾಕ್‌ನಲ್ಲಿ ಸಾಲಿನ ಗಾತ್ರ = "ಸಣ್ಣ" ಅನ್ನು ಗಮನಿಸಿ. ಇದು ಕುಬರ್ನೆಟ್ಸ್ ಮೂಲಕ ಸೇವೆಗೆ ನಿಯೋಜಿಸಲಾಗುವ ಮಿತಿಯಾಗಿದೆ.

ನಂತರ, ಸಂರಚನೆಯ ಆಧಾರದ ಮೇಲೆ, ಎಲ್ಲಾ ಅಗತ್ಯ ಹೆಲ್ಮ್ ಚಾರ್ಟ್‌ಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ರಚಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಡೇಟಾಬೇಸ್‌ಗಳಿಗೆ ಸಂಪರ್ಕಗಳನ್ನು ರಚಿಸಲಾಗುತ್ತದೆ.

• ಮೂಲ ಮೌಲ್ಯೀಕರಣ. ಅಂತಹ ತಪಾಸಣೆಗಳು ಸಹ ಸ್ವಯಂಚಾಲಿತವಾಗಿರುತ್ತವೆ.
ಟ್ರ್ಯಾಕ್ ಮಾಡಬೇಕಾಗಿದೆ:
- ಡಾಕರ್‌ಫೈಲ್ ಇದೆಯೇ;
— app.toml ಇದೆಯೇ;
- ದಾಖಲಾತಿ ಲಭ್ಯವಿದೆಯೇ?
- ಅವಲಂಬನೆ ಕ್ರಮದಲ್ಲಿದೆಯೇ?
- ಎಚ್ಚರಿಕೆ ನಿಯಮಗಳನ್ನು ಹೊಂದಿಸಲಾಗಿದೆಯೇ.
ಕೊನೆಯ ಹಂತಕ್ಕೆ: ಯಾವ ಉತ್ಪನ್ನದ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕೆಂದು ಸೇವೆಯ ಮಾಲೀಕರು ಸ್ವತಃ ನಿರ್ಧರಿಸುತ್ತಾರೆ.

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

I. ಸೇವೆಯ ಸಂಕ್ಷಿಪ್ತ ವಿವರಣೆ. ಅದು ಏನು ಮಾಡುತ್ತದೆ ಮತ್ತು ಅದು ಏಕೆ ಬೇಕು ಎಂಬುದರ ಕುರಿತು ಅಕ್ಷರಶಃ ಕೆಲವು ವಾಕ್ಯಗಳು.

II. ಆರ್ಕಿಟೆಕ್ಚರ್ ರೇಖಾಚಿತ್ರ ಲಿಂಕ್. ತ್ವರಿತ ನೋಟದಿಂದ ಅದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಬಹಳ ಮುಖ್ಯ, ಉದಾಹರಣೆಗೆ, ನೀವು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳಲು Redis ಅನ್ನು ಬಳಸುತ್ತಿದ್ದೀರಾ ಅಥವಾ ನಿರಂತರ ಮೋಡ್‌ನಲ್ಲಿ ಮುಖ್ಯ ಡೇಟಾ ಸ್ಟೋರ್ ಆಗಿ ಬಳಸುತ್ತಿದ್ದೀರಾ. ಸದ್ಯಕ್ಕೆ Avito ನಲ್ಲಿ ಇದು ಸಂಗಮಕ್ಕೆ ಲಿಂಕ್ ಆಗಿದೆ.

III. ರನ್ಬುಕ್. ಸೇವೆಯನ್ನು ಪ್ರಾರಂಭಿಸಲು ಮತ್ತು ಅದನ್ನು ನಿರ್ವಹಿಸುವ ಜಟಿಲತೆಗಳ ಕುರಿತು ಕಿರು ಮಾರ್ಗದರ್ಶಿ.

IV. FAQ, ಸೇವೆಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ ನಿಮ್ಮ ಸಹೋದ್ಯೋಗಿಗಳು ಎದುರಿಸಬಹುದಾದ ಸಮಸ್ಯೆಗಳನ್ನು ನಿರೀಕ್ಷಿಸುವುದು ಒಳ್ಳೆಯದು.

V. API ಗಾಗಿ ಅಂತಿಮ ಬಿಂದುಗಳ ವಿವರಣೆ. ಇದ್ದಕ್ಕಿದ್ದಂತೆ ನೀವು ಗಮ್ಯಸ್ಥಾನಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸದಿದ್ದರೆ, ನಿಮ್ಮ ಮೈಕ್ರೋಸರ್ವಿಸ್‌ಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ಸಹೋದ್ಯೋಗಿಗಳು ಅದನ್ನು ಪಾವತಿಸುತ್ತಾರೆ. ಈಗ ನಾವು ಸ್ವಾಗರ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ ಮತ್ತು ಇದಕ್ಕಾಗಿ ಸಂಕ್ಷಿಪ್ತ ಎಂಬ ನಮ್ಮ ಪರಿಹಾರವನ್ನು ಬಳಸುತ್ತೇವೆ.

VI ಲೇಬಲ್‌ಗಳು. ಅಥವಾ ಸೇವೆಯು ಕಂಪನಿಯ ಯಾವ ಉತ್ಪನ್ನ, ಕ್ರಿಯಾತ್ಮಕತೆ ಅಥವಾ ರಚನಾತ್ಮಕ ವಿಭಾಗವನ್ನು ತೋರಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸುವ ಗುರುತುಗಳು. ಒಂದು ವಾರದ ಹಿಂದೆ ನಿಮ್ಮ ಸಹೋದ್ಯೋಗಿಗಳು ಅದೇ ವ್ಯಾಪಾರ ಘಟಕಕ್ಕಾಗಿ ಹೊರತಂದಿರುವ ಕಾರ್ಯವನ್ನು ನೀವು ಕಡಿತಗೊಳಿಸುತ್ತಿರುವಿರಾ ಎಂಬುದನ್ನು ತ್ವರಿತವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಅವರು ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತಾರೆ.

VII. ಸೇವೆಯ ಮಾಲೀಕರು ಅಥವಾ ಮಾಲೀಕರು. ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಇದು — ಅಥವಾ ಅವುಗಳನ್ನು — ಸ್ವಯಂಚಾಲಿತವಾಗಿ PaaS ಬಳಸಿಕೊಂಡು ನಿರ್ಧರಿಸಬಹುದು, ಆದರೆ ಸುರಕ್ಷಿತ ಬದಿಯಲ್ಲಿರಲು, ಡೆವಲಪರ್ ಅವುಗಳನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ನಿರ್ದಿಷ್ಟಪಡಿಸುವ ಅಗತ್ಯವಿದೆ.

ಅಂತಿಮವಾಗಿ, ಕೋಡ್ ವಿಮರ್ಶೆಯಂತೆಯೇ ದಸ್ತಾವೇಜನ್ನು ಪರಿಶೀಲಿಸುವುದು ಉತ್ತಮ ಅಭ್ಯಾಸವಾಗಿದೆ.

ನಿರಂತರ ಇಂಟಿಗ್ರೇಷನ್

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

ತಯಾರಿಸಲು

ಮುಂದಿನ ಹಂತವು ನಿಯೋಜನೆಯ ಮೊದಲು ಪ್ಯಾಕೇಜಿಂಗ್ ಸೇವೆಗಳು.

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

ಎಕ್ಸಿಕ್ಯೂಶನ್ ಸಮಯ, ಕಡಿಮೆ ಉತ್ತಮ. ಗರಿಷ್ಠ: 643ms, ಕನಿಷ್ಠ: 42ms. ಫೋಟೋ ಕ್ಲಿಕ್ ಮಾಡಬಹುದಾಗಿದೆ.

ಶಸ್ತ್ರಚಿಕಿತ್ಸೆಗೆ ಸಮಯ, ಕಡಿಮೆ ಉತ್ತಮ. ಗರಿಷ್ಠ: 14091 ns, ಕನಿಷ್ಠ: 151 ns. ಫೋಟೋ ಕ್ಲಿಕ್ ಮಾಡಬಹುದಾಗಿದೆ.

ಅಸೆಂಬ್ಲಿ ತಯಾರಿ ಹಂತದಲ್ಲಿ, ನೀವು ಈ ವೇರಿಯಬಲ್ ಅನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಹೊಂದಿಸಬಹುದು ಅಥವಾ ನೀವು ಲೈಬ್ರರಿಯನ್ನು ಬಳಸಬಹುದು automaxprocs Uber ನ ಹುಡುಗರಿಂದ.

ನಿಯೋಜಿಸಿ

• ಸಂಪ್ರದಾಯಗಳನ್ನು ಪರಿಶೀಲಿಸಲಾಗುತ್ತಿದೆ. ನಿಮ್ಮ ಉದ್ದೇಶಿತ ಪರಿಸರಕ್ಕೆ ನೀವು ಸೇವಾ ಅಸೆಂಬ್ಲಿಗಳನ್ನು ತಲುಪಿಸಲು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು, ನೀವು ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಪರಿಶೀಲಿಸಬೇಕು:
- API ಅಂತಿಮ ಬಿಂದುಗಳು.
- ಸ್ಕೀಮಾದೊಂದಿಗೆ API ಅಂತ್ಯಬಿಂದುಗಳ ಪ್ರತಿಕ್ರಿಯೆಗಳ ಅನುಸರಣೆ.
- ಲಾಗ್ ಫಾರ್ಮ್ಯಾಟ್.
— ಸೇವೆಗೆ ವಿನಂತಿಗಳಿಗಾಗಿ ಹೆಡರ್‌ಗಳನ್ನು ಹೊಂದಿಸುವುದು (ಪ್ರಸ್ತುತ ಇದನ್ನು netramesh ನಿಂದ ಮಾಡಲಾಗುತ್ತದೆ)
- ಈವೆಂಟ್ ಬಸ್‌ಗೆ ಸಂದೇಶಗಳನ್ನು ಕಳುಹಿಸುವಾಗ ಮಾಲೀಕರ ಟೋಕನ್ ಅನ್ನು ಹೊಂದಿಸುವುದು. ಬಸ್‌ನಾದ್ಯಂತ ಸೇವೆಗಳ ಸಂಪರ್ಕವನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ಇದು ಅಗತ್ಯವಿದೆ. ಸೇವೆಗಳ ಸಂಪರ್ಕವನ್ನು ಹೆಚ್ಚಿಸದ (ಇದು ಒಳ್ಳೆಯದು) ಮತ್ತು ಸೇವೆಗಳ ಸಂಪರ್ಕವನ್ನು ಬಲಪಡಿಸುವ ವ್ಯವಹಾರ ಡೇಟಾ (ಇದು ತುಂಬಾ ಕೆಟ್ಟದು!) ಎರಡನ್ನೂ ನೀವು ಬಸ್‌ಗೆ ಐಡೆಮ್ಪೋಟೆಂಟ್ ಡೇಟಾವನ್ನು ಕಳುಹಿಸಬಹುದು. ಮತ್ತು ಈ ಸಂಪರ್ಕವು ಸಮಸ್ಯೆಯಾದಾಗ, ಬಸ್ ಅನ್ನು ಯಾರು ಬರೆಯುತ್ತಾರೆ ಮತ್ತು ಓದುತ್ತಾರೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಸೇವೆಗಳನ್ನು ಸರಿಯಾಗಿ ಪ್ರತ್ಯೇಕಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.

Avito ನಲ್ಲಿ ಇನ್ನೂ ಹೆಚ್ಚಿನ ಸಮಾವೇಶಗಳಿಲ್ಲ, ಆದರೆ ಅವರ ಪೂಲ್ ವಿಸ್ತರಿಸುತ್ತಿದೆ. ಅಂತಹ ಒಪ್ಪಂದಗಳು ತಂಡವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಮತ್ತು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಒಂದು ರೂಪದಲ್ಲಿ ಲಭ್ಯವಿವೆ, ಮೈಕ್ರೋಸರ್ವಿಸ್ಗಳ ನಡುವೆ ಸ್ಥಿರತೆಯನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳುವುದು ಸುಲಭವಾಗಿದೆ.

ಸಂಶ್ಲೇಷಿತ ಪರೀಕ್ಷೆಗಳು

• ಮುಚ್ಚಿದ ಲೂಪ್ ಪರೀಕ್ಷೆ. ಇದಕ್ಕಾಗಿ ನಾವು ಈಗ ಮುಕ್ತ ಮೂಲವನ್ನು ಬಳಸುತ್ತಿದ್ದೇವೆ Hoverfly.io. ಮೊದಲಿಗೆ, ಇದು ಸೇವೆಯಲ್ಲಿ ನಿಜವಾದ ಲೋಡ್ ಅನ್ನು ದಾಖಲಿಸುತ್ತದೆ, ನಂತರ - ಕೇವಲ ಮುಚ್ಚಿದ ಲೂಪ್ನಲ್ಲಿ - ಅದನ್ನು ಅನುಕರಿಸುತ್ತದೆ.

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

ಲೋಡ್ ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ, ಸಂಪನ್ಮೂಲ ಬಳಕೆ ನಿಗದಿತ ಮಿತಿಗಳನ್ನು ಪೂರೈಸುತ್ತದೆಯೇ ಎಂದು ನಾವು ಪರಿಶೀಲಿಸುತ್ತೇವೆ. ಮತ್ತು ನಾವು ಪ್ರಾಥಮಿಕವಾಗಿ ವಿಪರೀತಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತೇವೆ.

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

ಬಿ) ನಾವು RPS ಪ್ರಕಾರ ಕಟ್ಆಫ್ ಅನ್ನು ನೋಡುತ್ತೇವೆ.
ಇಲ್ಲಿ ನಾವು ಪ್ರಸ್ತುತ ಆವೃತ್ತಿ ಮತ್ತು ಹಿಂದಿನ ಆವೃತ್ತಿ ಮತ್ತು ಒಟ್ಟು ಪ್ರಮಾಣದ ನಡುವಿನ ವ್ಯತ್ಯಾಸವನ್ನು ನೋಡುತ್ತೇವೆ. ಉದಾಹರಣೆಗೆ, ಸೇವೆಯು 100 rps ಅನ್ನು ಉತ್ಪಾದಿಸಿದರೆ, ಅದು ಕಳಪೆಯಾಗಿ ಬರೆಯಲ್ಪಟ್ಟಿದೆ, ಅಥವಾ ಇದು ಅದರ ನಿರ್ದಿಷ್ಟತೆಯಾಗಿದೆ, ಆದರೆ ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ, ಸೇವೆಯನ್ನು ಬಹಳ ಹತ್ತಿರದಿಂದ ನೋಡಲು ಇದು ಒಂದು ಕಾರಣವಾಗಿದೆ.
ಇದಕ್ಕೆ ವ್ಯತಿರಿಕ್ತವಾಗಿ, ಹಲವಾರು RPS ಇದ್ದರೆ, ಬಹುಶಃ ಕೆಲವು ರೀತಿಯ ದೋಷವಿರಬಹುದು ಮತ್ತು ಕೆಲವು ಅಂತಿಮ ಬಿಂದುಗಳು ಪೇಲೋಡ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿವೆ, ಆದರೆ ಇನ್ನೊಂದನ್ನು ಸರಳವಾಗಿ ಪ್ರಚೋದಿಸಲಾಗುತ್ತದೆ return true;

ಕ್ಯಾನರಿ ಪರೀಕ್ಷೆಗಳು

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

ಸ್ಕ್ವೀಜ್ ಪರೀಕ್ಷೆ

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

ಉತ್ಪಾದನೆ

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

ಪರಿಣಾಮವಾಗಿ, ಸ್ಕೇಲಿಂಗ್ ಮಾಡುವಾಗ ನಾವು ವಿಶ್ಲೇಷಿಸುತ್ತೇವೆ:
- CPU ಮತ್ತು RAM ಸೂಚಕಗಳು,
- ಸರದಿಯಲ್ಲಿರುವ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆ,
- ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯ,
- ಸಂಗ್ರಹವಾದ ಐತಿಹಾಸಿಕ ಮಾಹಿತಿಯ ಆಧಾರದ ಮೇಲೆ ಮುನ್ಸೂಚನೆ.

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

ಸೇವೆ

ಮೈಕ್ರೊ ಸರ್ವಿಸ್ ಅನ್ನು ಕಾರ್ಯಾಚರಣೆಗೆ ಒಳಪಡಿಸಿದ ನಂತರ, ನಾವು ಅದಕ್ಕೆ ಪ್ರಚೋದಕಗಳನ್ನು ಲಗತ್ತಿಸಬಹುದು.

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

ಕೆಲವು ಪ್ರಚೋದಕಗಳು ಕಾರ್ಯಾಚರಣೆಯ ಸ್ಥಿರತೆಗೆ ಜವಾಬ್ದಾರರಾಗಿರುತ್ತಾರೆ, ಕೆಲವು - ಸಿಸ್ಟಮ್ ನಿರ್ವಹಣೆಯ ಕಾರ್ಯವಾಗಿ - ಉದಾಹರಣೆಗೆ, ಕೆಲವು ಸೇವೆಯನ್ನು ದೀರ್ಘಕಾಲದವರೆಗೆ ನಿಯೋಜಿಸಲಾಗಿಲ್ಲ ಮತ್ತು ಅದರ ಮೂಲ ಚಿತ್ರವು ಭದ್ರತಾ ತಪಾಸಣೆಗಳನ್ನು ರವಾನಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದೆ.

ಡ್ಯಾಶ್‌ಬೋರ್ಡ್

ಸಂಕ್ಷಿಪ್ತವಾಗಿ, ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ನಮ್ಮ ಸಂಪೂರ್ಣ PaaS ನ ನಿಯಂತ್ರಣ ಫಲಕವಾಗಿದೆ.

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

ಒಟ್ಟು

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

ನಾನು ಹೈಲೋಡ್++ 2018 ಗಾಗಿ ಈ ವಿಷಯದ ಕುರಿತು ವರದಿಯನ್ನು ನೀಡಿದ್ದೇನೆ, ನೀವು ಅದನ್ನು ವೀಕ್ಷಿಸಬಹುದು видео и ಪ್ರಸ್ತುತಿ.

ಕೊನೆಯವರೆಗೂ ಓದುವವರಿಗೆ ಬೋನಸ್ ಟ್ರ್ಯಾಕ್

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

ತರಬೇತಿಯು ಮಾಸ್ಕೋದಲ್ಲಿ ಆಗಸ್ಟ್ 5 ರಿಂದ 7 ರವರೆಗೆ ನಡೆಯುತ್ತದೆ. ಇವು ಸಂಪೂರ್ಣವಾಗಿ ಆಕ್ರಮಿಸಲ್ಪಡುವ ಕೆಲಸದ ದಿನಗಳಾಗಿವೆ. ಊಟ ಮತ್ತು ತರಬೇತಿ ನಮ್ಮ ಕಛೇರಿಯಲ್ಲಿ ಇರುತ್ತದೆ, ಮತ್ತು ಆಯ್ಕೆಯಾದ ಭಾಗವಹಿಸುವವರು ಪ್ರಯಾಣ ಮತ್ತು ವಸತಿಗಾಗಿ ಸ್ವತಃ ಪಾವತಿಸುತ್ತಾರೆ.

ನೀವು ಭಾಗವಹಿಸಲು ಅರ್ಜಿ ಸಲ್ಲಿಸಬಹುದು ಈ ಗೂಗಲ್ ರೂಪದಲ್ಲಿ. ನಿಮ್ಮಿಂದ - ನೀವು ತರಬೇತಿಗೆ ಏಕೆ ಹಾಜರಾಗಬೇಕು ಎಂಬ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರ ಮತ್ತು ನಿಮ್ಮನ್ನು ಹೇಗೆ ಸಂಪರ್ಕಿಸಬೇಕು ಎಂಬುದರ ಕುರಿತು ಮಾಹಿತಿ. ಇಂಗ್ಲಿಷ್ನಲ್ಲಿ ಉತ್ತರಿಸಿ, ಏಕೆಂದರೆ ಕ್ರಿಸ್ ಸ್ವತಃ ತರಬೇತಿಗೆ ಹಾಜರಾಗುವ ಪಾಲ್ಗೊಳ್ಳುವವರನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತಾರೆ.
ಈ ಪೋಸ್ಟ್‌ಗೆ ಅಪ್‌ಡೇಟ್‌ನಲ್ಲಿ ಮತ್ತು ಡೆವಲಪರ್‌ಗಳಿಗಾಗಿ Avito ಸಾಮಾಜಿಕ ನೆಟ್‌ವರ್ಕ್‌ಗಳಲ್ಲಿ ತರಬೇತಿ ಭಾಗವಹಿಸುವವರ ಹೆಸರನ್ನು ನಾವು ಪ್ರಕಟಿಸುತ್ತೇವೆ (AvitoTech in ಫೇಸ್ಬುಕ್, Вконтакте, ಟ್ವಿಟರ್) ಜುಲೈ 19 ರ ನಂತರ ಇಲ್ಲ.

ಮೂಲ: www.habr.com