“ನನ್ನ ಬೂಟುಗಳಲ್ಲಿ ನಡೆಯುವುದು” - ನಿರೀಕ್ಷಿಸಿ, ಅವುಗಳನ್ನು ಗುರುತಿಸಲಾಗಿದೆಯೇ?

2019 ರಿಂದ, ರಷ್ಯಾ ಕಡ್ಡಾಯ ಲೇಬಲಿಂಗ್ ಕುರಿತು ಕಾನೂನನ್ನು ಹೊಂದಿದೆ. ಕಾನೂನು ಎಲ್ಲಾ ಗುಂಪುಗಳ ಸರಕುಗಳಿಗೆ ಅನ್ವಯಿಸುವುದಿಲ್ಲ ಮತ್ತು ಉತ್ಪನ್ನ ಗುಂಪುಗಳಿಗೆ ಕಡ್ಡಾಯ ಲೇಬಲಿಂಗ್ ಜಾರಿಗೆ ಬರುವ ದಿನಾಂಕಗಳು ವಿಭಿನ್ನವಾಗಿವೆ. ತಂಬಾಕು, ಬೂಟುಗಳು ಮತ್ತು ಔಷಧಗಳು ಕಡ್ಡಾಯವಾಗಿ ಲೇಬಲಿಂಗ್‌ಗೆ ಒಳಪಟ್ಟಿರುತ್ತವೆ; ಇತರ ಉತ್ಪನ್ನಗಳನ್ನು ನಂತರ ಸೇರಿಸಲಾಗುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, ಸುಗಂಧ ದ್ರವ್ಯ, ಜವಳಿ ಮತ್ತು ಹಾಲು. ಈ ಶಾಸಕಾಂಗ ಆವಿಷ್ಕಾರವು ಹೊಸ ಐಟಿ ಪರಿಹಾರಗಳ ಅಭಿವೃದ್ಧಿಯನ್ನು ಪ್ರೇರೇಪಿಸಿತು, ಇದು ಉತ್ಪನ್ನದ ಸಂಪೂರ್ಣ ಜೀವನ ಸರಪಳಿಯನ್ನು ಉತ್ಪಾದನೆಯಿಂದ ಅಂತಿಮ ಗ್ರಾಹಕರು ಖರೀದಿಸಲು, ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಭಾಗವಹಿಸುವ ಎಲ್ಲರಿಗೂ ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗುವಂತೆ ಮಾಡುತ್ತದೆ: ರಾಜ್ಯ ಸ್ವತಃ ಮತ್ತು ಸರಕುಗಳನ್ನು ಮಾರಾಟ ಮಾಡುವ ಎಲ್ಲಾ ಸಂಸ್ಥೆಗಳು. ಕಡ್ಡಾಯ ಲೇಬಲಿಂಗ್.

X5 ನಲ್ಲಿ, ಲೇಬಲ್ ಮಾಡಲಾದ ಸರಕುಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುವ ಮತ್ತು ರಾಜ್ಯ ಮತ್ತು ಪೂರೈಕೆದಾರರೊಂದಿಗೆ ಡೇಟಾವನ್ನು ವಿನಿಮಯ ಮಾಡುವ ವ್ಯವಸ್ಥೆಯನ್ನು "ಮಾರ್ಕಸ್" ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಅದನ್ನು ಹೇಗೆ ಮತ್ತು ಯಾರು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದಾರೆ, ಅದರ ತಂತ್ರಜ್ಞಾನದ ಸ್ಟಾಕ್ ಏನು ಮತ್ತು ಏಕೆ ನಾವು ಹೆಮ್ಮೆಪಡುವ ಸಂಗತಿಯನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂಬುದನ್ನು ಕ್ರಮವಾಗಿ ಹೇಳೋಣ.

ನಿಜವಾದ ಹೈಲೋಡ್

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

ತಂಡ ಎಂ

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

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

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

ದೂರಸ್ಥ ತಂಡದ ಸಭೆ

ರಿಮೋಟ್ ಕೆಲಸದ ಸಮಯದಲ್ಲಿ ಸಭೆಗಳು

ಪರಿಹಾರದ ತಂತ್ರಜ್ಞಾನದ ಸ್ಟಾಕ್

X5 ಗಾಗಿ ಪ್ರಮಾಣಿತ ರೆಪೊಸಿಟರಿ ಮತ್ತು CI/CD ಉಪಕರಣವು GitLab ಆಗಿದೆ. ಕೋಡ್ ಸಂಗ್ರಹಣೆ, ನಿರಂತರ ಪರೀಕ್ಷೆ ಮತ್ತು ಪರೀಕ್ಷೆ ಮತ್ತು ಉತ್ಪಾದನಾ ಸರ್ವರ್‌ಗಳಿಗೆ ನಿಯೋಜನೆಗಾಗಿ ನಾವು ಇದನ್ನು ಬಳಸುತ್ತೇವೆ. ಡೆವಲಪರ್‌ನಿಂದ ಕೋಡ್‌ಗೆ ಮಾಡಿದ ಬದಲಾವಣೆಗಳನ್ನು ಕನಿಷ್ಠ 2 ಸಹೋದ್ಯೋಗಿಗಳು ಅನುಮೋದಿಸಬೇಕಾದಾಗ ನಾವು ಕೋಡ್ ವಿಮರ್ಶೆಯ ಅಭ್ಯಾಸವನ್ನು ಸಹ ಬಳಸುತ್ತೇವೆ. ಸ್ಟ್ಯಾಟಿಕ್ ಕೋಡ್ ವಿಶ್ಲೇಷಕಗಳಾದ SonarQube ಮತ್ತು JaCoCo ನಮ್ಮ ಕೋಡ್ ಅನ್ನು ಸ್ವಚ್ಛವಾಗಿಡಲು ಮತ್ತು ಅಗತ್ಯ ಮಟ್ಟದ ಯೂನಿಟ್ ಟೆಸ್ಟ್ ಕವರೇಜ್ ಅನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಕೋಡ್‌ಗೆ ಎಲ್ಲಾ ಬದಲಾವಣೆಗಳು ಈ ಚೆಕ್‌ಗಳ ಮೂಲಕ ಹೋಗಬೇಕು. ಹಸ್ತಚಾಲಿತವಾಗಿ ನಡೆಸುವ ಎಲ್ಲಾ ಪರೀಕ್ಷಾ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ತರುವಾಯ ಸ್ವಯಂಚಾಲಿತವಾಗಿರುತ್ತವೆ.

"ಮಾರ್ಕಸ್" ಮೂಲಕ ವ್ಯಾಪಾರ ಪ್ರಕ್ರಿಯೆಗಳ ಯಶಸ್ವಿ ಅನುಷ್ಠಾನಕ್ಕಾಗಿ, ನಾವು ಹಲವಾರು ತಾಂತ್ರಿಕ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಬೇಕಾಗಿದೆ, ಪ್ರತಿಯೊಂದರ ಬಗ್ಗೆ ಕ್ರಮವಾಗಿ.

ಕಾರ್ಯ 1. ಸಿಸ್ಟಮ್ನ ಸಮತಲ ಸ್ಕೇಲೆಬಿಲಿಟಿ ಅಗತ್ಯ

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

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

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

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

ಕಾರ್ಯ 2. ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಸೇವೆಗಳ ನಡುವೆ ಹೆಚ್ಚಿನ ಹೊರೆ ಮತ್ತು ಅತ್ಯಂತ ತೀವ್ರವಾದ ಡೇಟಾ ವಿನಿಮಯವನ್ನು ನಿರ್ವಹಿಸುವ ಅಗತ್ಯತೆ: ಯೋಜನೆಯ ಉಡಾವಣಾ ಹಂತದಲ್ಲಿ ಮಾತ್ರ, ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಸುಮಾರು 600 ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ನಡೆಸಲಾಗುತ್ತದೆ. ರಿಟೇಲ್ ಔಟ್‌ಲೆಟ್‌ಗಳು ನಮ್ಮ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗೆ ಸಂಪರ್ಕಗೊಳ್ಳುವುದರಿಂದ ಈ ಮೌಲ್ಯವು 5000 ops/sec ಗೆ ಹೆಚ್ಚಾಗುತ್ತದೆ ಎಂದು ನಾವು ನಿರೀಕ್ಷಿಸುತ್ತೇವೆ.

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

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

ಕಾರ್ಯ 3. ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವ ಅಗತ್ಯತೆ: ತಂಬಾಕಿಗೆ ಮಾತ್ರ ವರ್ಷಕ್ಕೆ 1 ಶತಕೋಟಿ ಲೇಬಲ್‌ಗಳು X5 ಗೆ ಬರುತ್ತವೆ. ಅವರಿಗೆ ನಿರಂತರ ಮತ್ತು ತ್ವರಿತ ಪ್ರವೇಶದ ಅಗತ್ಯವಿರುತ್ತದೆ. ಒಟ್ಟಾರೆಯಾಗಿ, ಈ ಲೇಬಲ್ ಮಾಡಿದ ಸರಕುಗಳ ಚಲನೆಯ ಇತಿಹಾಸದ ಸುಮಾರು 10 ಬಿಲಿಯನ್ ದಾಖಲೆಗಳನ್ನು ವ್ಯವಸ್ಥೆಯು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬೇಕು.

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

ಕಾರ್ಯಾಚರಣೆಗಳ ಇತಿಹಾಸದೊಂದಿಗೆ ಬಳಕೆದಾರರ ಕೆಲಸವು ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಪ್ರಮುಖ ವಿಷಯದ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು - ನಮ್ಮ ವ್ಯವಹಾರ ಪ್ರಕ್ರಿಯೆಗಳ ಕಾರ್ಯನಿರ್ವಹಣೆ, ನಾವು ಎಲ್ಲಾ ಐತಿಹಾಸಿಕ ಡೇಟಾವನ್ನು ಪ್ರತ್ಯೇಕ ಡೇಟಾಬೇಸ್ನೊಂದಿಗೆ ಪ್ರತ್ಯೇಕ ಸೇವೆಯಾಗಿ ಪ್ರತ್ಯೇಕಿಸಿದ್ದೇವೆ, ಅದು ಕಾಫ್ಕಾ ಮೂಲಕ ಮಾಹಿತಿಯನ್ನು ಪಡೆಯುತ್ತದೆ. . ಈ ರೀತಿಯಾಗಿ, ನಡೆಯುತ್ತಿರುವ ಕಾರ್ಯಾಚರಣೆಗಳಿಗಾಗಿ ಡೇಟಾವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ಸೇವೆಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರದಂತೆ ಬಳಕೆದಾರರು ಪ್ರತ್ಯೇಕ ಸೇವೆಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ.

ಕಾರ್ಯ 4: ಸರತಿ ಮರುಸಂಸ್ಕರಣೆ ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆ:

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

ಅಂತಹ ಯೋಜನೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು, ನಮಗೆ ಈ ಕೆಳಗಿನವುಗಳು ಬೇಕಾಗುತ್ತವೆ: ಈ ಪರಿಹಾರವನ್ನು ಸ್ಪ್ರಿಂಗ್‌ನೊಂದಿಗೆ ಸಂಯೋಜಿಸಲು ಮತ್ತು ಕೋಡ್ ನಕಲು ಮಾಡುವುದನ್ನು ತಪ್ಪಿಸಲು. ವೆಬ್ ಸರ್ಫಿಂಗ್ ಮಾಡುವಾಗ, ನಾವು Spring BeanPostProccessor ಅನ್ನು ಆಧರಿಸಿ ಇದೇ ರೀತಿಯ ಪರಿಹಾರವನ್ನು ನೋಡಿದ್ದೇವೆ, ಆದರೆ ಇದು ನಮಗೆ ಅನಗತ್ಯವಾಗಿ ತೊಡಕಾಗಿ ಕಾಣುತ್ತದೆ. ನಮ್ಮ ತಂಡವು ಸರಳವಾದ ಪರಿಹಾರವನ್ನು ಮಾಡಿದೆ, ಅದು ಗ್ರಾಹಕರನ್ನು ರಚಿಸಲು ಮತ್ತು ಹೆಚ್ಚುವರಿಯಾಗಿ ಗ್ರಾಹಕರನ್ನು ಮರುಪ್ರಯತ್ನಿಸಲು ಸ್ಪ್ರಿಂಗ್ ಸೈಕಲ್‌ಗೆ ಸಂಯೋಜಿಸಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ನಾವು ಸ್ಪ್ರಿಂಗ್ ತಂಡಕ್ಕೆ ನಮ್ಮ ಪರಿಹಾರದ ಮೂಲಮಾದರಿಯನ್ನು ನೀಡಿದ್ದೇವೆ, ನೀವು ಅದನ್ನು ನೋಡಬಹುದು ಇಲ್ಲಿ. ಮರುಪ್ರಯತ್ನಿಸುವ ಗ್ರಾಹಕರ ಸಂಖ್ಯೆ ಮತ್ತು ಪ್ರತಿ ಗ್ರಾಹಕರ ಪ್ರಯತ್ನಗಳ ಸಂಖ್ಯೆಯನ್ನು ನಿಯತಾಂಕಗಳ ಮೂಲಕ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ, ವ್ಯಾಪಾರ ಪ್ರಕ್ರಿಯೆಯ ಅಗತ್ಯತೆಗಳನ್ನು ಅವಲಂಬಿಸಿ, ಮತ್ತು ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡಲು, org.springframework.kafka.annotation.KafkaListener ಎಂಬ ಟಿಪ್ಪಣಿಯನ್ನು ಸೇರಿಸುವುದು ಮಾತ್ರ ಉಳಿದಿದೆ. , ಇದು ಎಲ್ಲಾ ಸ್ಪ್ರಿಂಗ್ ಡೆವಲಪರ್‌ಗಳಿಗೆ ಪರಿಚಿತವಾಗಿದೆ.

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

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

ವೇದಿಕೆಯ ಕಾರ್ಯಾಚರಣೆ

ವೇದಿಕೆಯು ಈಗಾಗಲೇ ಉತ್ಪಾದಕ ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿದೆ, ಪ್ರತಿದಿನ ನಾವು ವಿತರಣೆಗಳು ಮತ್ತು ಸಾಗಣೆಗಳನ್ನು ಕೈಗೊಳ್ಳುತ್ತೇವೆ, ಹೊಸ ವಿತರಣಾ ಕೇಂದ್ರಗಳು ಮತ್ತು ಮಳಿಗೆಗಳನ್ನು ಸಂಪರ್ಕಿಸುತ್ತೇವೆ. ಪೈಲಟ್ನ ಭಾಗವಾಗಿ, ಸಿಸ್ಟಮ್ "ತಂಬಾಕು" ಮತ್ತು "ಶೂಸ್" ಉತ್ಪನ್ನ ಗುಂಪುಗಳೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

ನಮ್ಮ ಇಡೀ ತಂಡವು ಪೈಲಟ್‌ಗಳನ್ನು ನಡೆಸುವಲ್ಲಿ ಭಾಗವಹಿಸುತ್ತದೆ, ಉದಯೋನ್ಮುಖ ಸಮಸ್ಯೆಗಳನ್ನು ವಿಶ್ಲೇಷಿಸುತ್ತದೆ ಮತ್ತು ಲಾಗ್‌ಗಳನ್ನು ಸುಧಾರಿಸುವುದರಿಂದ ಹಿಡಿದು ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಬದಲಾಯಿಸುವವರೆಗೆ ನಮ್ಮ ಉತ್ಪನ್ನವನ್ನು ಸುಧಾರಿಸಲು ಸಲಹೆಗಳನ್ನು ನೀಡುತ್ತದೆ.

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

ಈಗ ನಾವು ನಮ್ಮ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವುದನ್ನು ಮತ್ತು ಸುಧಾರಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತೇವೆ ಮತ್ತು ನಿರಂತರವಾಗಿ ಹೊಸ ಸವಾಲುಗಳನ್ನು ಎದುರಿಸುತ್ತೇವೆ. ನೀವು ಆಸಕ್ತಿ ಹೊಂದಿದ್ದರೆ, ನಾವು ಮುಂದಿನ ಲೇಖನಗಳಲ್ಲಿ ನಮ್ಮ ಪರಿಹಾರಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇವೆ.

ಮೂಲ: www.habr.com