ಡೋಡೋ IS ಆರ್ಕಿಟೆಕ್ಚರ್ ಇತಿಹಾಸ: ದಿ ಬ್ಯಾಕ್ ಆಫೀಸ್ ಪಾತ್

ಹಬರ್ ಜಗತ್ತನ್ನು ಬದಲಾಯಿಸುತ್ತಿದೆ. ನಾವು ಈಗ ಒಂದು ವರ್ಷದಿಂದ ಬ್ಲಾಗಿಂಗ್ ಮಾಡುತ್ತಿದ್ದೇವೆ. ಸುಮಾರು ಆರು ತಿಂಗಳ ಹಿಂದೆ, ನಾವು ಖಬ್ರೊವೈಟ್ಸ್‌ನಿಂದ ಸಂಪೂರ್ಣವಾಗಿ ತಾರ್ಕಿಕ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ: “ಡೋಡೋ, ನೀವು ನಿಮ್ಮ ಸ್ವಂತ ವ್ಯವಸ್ಥೆಯನ್ನು ಹೊಂದಿದ್ದೀರಿ ಎಂದು ನೀವು ಎಲ್ಲೆಡೆ ಹೇಳುತ್ತೀರಿ. ಮತ್ತು ಈ ವ್ಯವಸ್ಥೆ ಏನು? ಮತ್ತು ಪಿಜ್ಜಾ ಸರಣಿಗೆ ಅದು ಏಕೆ ಬೇಕು?

ನಾವು ಕುಳಿತು, ಯೋಚಿಸಿದ್ದೇವೆ ಮತ್ತು ನೀವು ಸರಿ ಎಂದು ಅರಿತುಕೊಂಡೆವು. ನಮ್ಮ ಬೆರಳುಗಳ ಮೇಲೆ ಎಲ್ಲವನ್ನೂ ವಿವರಿಸಲು ನಾವು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ, ಆದರೆ ಅದು ಹರಿದ ತುಣುಕುಗಳಲ್ಲಿ ಹೊರಬರುತ್ತದೆ ಮತ್ತು ಎಲ್ಲಿಯೂ ಸಿಸ್ಟಮ್ನ ಸಂಪೂರ್ಣ ವಿವರಣೆಯಿಲ್ಲ. ಹೀಗೆ ಮಾಹಿತಿ ಸಂಗ್ರಹಿಸುವ, ಲೇಖಕರನ್ನು ಹುಡುಕುವ ಮತ್ತು ಡೋಡೋ ಐಎಸ್ ಬಗ್ಗೆ ಸರಣಿ ಲೇಖನಗಳನ್ನು ಬರೆಯುವ ಸುದೀರ್ಘ ಪ್ರಯಾಣವನ್ನು ಪ್ರಾರಂಭಿಸಲಾಯಿತು. ಹೋಗೋಣ!

ಕೃತಜ್ಞತೆಗಳು: ನಿಮ್ಮ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನಮ್ಮೊಂದಿಗೆ ಹಂಚಿಕೊಂಡಿದ್ದಕ್ಕಾಗಿ ಧನ್ಯವಾದಗಳು. ಅವರಿಗೆ ಧನ್ಯವಾದಗಳು, ನಾವು ಅಂತಿಮವಾಗಿ ಸಿಸ್ಟಮ್ ಅನ್ನು ವಿವರಿಸಿದ್ದೇವೆ, ತಾಂತ್ರಿಕ ರಾಡಾರ್ ಅನ್ನು ಸಂಗ್ರಹಿಸಿದ್ದೇವೆ ಮತ್ತು ಶೀಘ್ರದಲ್ಲೇ ನಮ್ಮ ಪ್ರಕ್ರಿಯೆಗಳ ದೊಡ್ಡ ವಿವರಣೆಯನ್ನು ಹೊರತರುತ್ತೇವೆ. ನೀನಿಲ್ಲದಿದ್ದರೆ ನಾವು ಇನ್ನೂ 5 ವರ್ಷಗಳ ಕಾಲ ಅಲ್ಲಿಯೇ ಇರುತ್ತಿದ್ದೆವು.

ಲೇಖನಗಳ ಸರಣಿ "ಡೋಡೋ ಐಎಸ್ ಎಂದರೇನು?" ಬಗ್ಗೆ ಹೇಳುತ್ತದೆ:

1. ಡೋಡೋ IS ನಲ್ಲಿ ಆರಂಭಿಕ ಏಕಶಿಲೆ (2011-2015). (ಪ್ರಗತಿಯಲ್ಲಿದೆ...)
2. ಬ್ಯಾಕ್ ಆಫೀಸ್ ಮಾರ್ಗ: ಪ್ರತ್ಯೇಕ ಬೇಸ್ ಮತ್ತು ಬಸ್. (ನೀವು ಇಲ್ಲಿದ್ದೀರಿ)
3. ಕ್ಲೈಂಟ್ ಸೈಡ್ ಪಾತ್: ಬೇಸ್ ಮೇಲೆ ಮುಂಭಾಗ (2016-2017). (ಪ್ರಗತಿಯಲ್ಲಿದೆ...)
4. ನೈಜ ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ನ ಇತಿಹಾಸ. (2018-2019). (ಪ್ರಗತಿಯಲ್ಲಿದೆ...)
5. ಏಕಶಿಲೆಯ ಗರಗಸ ಮತ್ತು ವಾಸ್ತುಶಿಲ್ಪದ ಸ್ಥಿರೀಕರಣವನ್ನು ಪೂರ್ಣಗೊಳಿಸಲಾಗಿದೆ. (ಪ್ರಗತಿಯಲ್ಲಿದೆ...)

ನೀವು ಬೇರೆ ಯಾವುದನ್ನಾದರೂ ತಿಳಿದುಕೊಳ್ಳಲು ಆಸಕ್ತಿ ಹೊಂದಿದ್ದರೆ - ಕಾಮೆಂಟ್ಗಳಲ್ಲಿ ಬರೆಯಿರಿ.

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

ಸಾಂಪ್ರದಾಯಿಕವಾಗಿ, ನಾವು ಕೆಲವು ಗುರಿಗಳನ್ನು ಸಾಧಿಸಲು ಪರಸ್ಪರ ಸಂವಹನ ನಡೆಸುವ ಘಟಕಗಳ (ತಾಂತ್ರಿಕ ಅಥವಾ ಉನ್ನತ ಮಟ್ಟದ), ವ್ಯಾಪಾರ ಮಾಡ್ಯೂಲ್‌ಗಳ ಗುಂಪಾಗಿ ಸಿಸ್ಟಮ್ ಅನ್ನು ನೋಡುತ್ತೇವೆ. ಮತ್ತು ಅಂತಹ ದೃಷ್ಟಿಕೋನವನ್ನು ವಿನ್ಯಾಸಕ್ಕಾಗಿ ಸಮರ್ಥಿಸಿದರೆ, ಅದು ವಿವರಣೆ ಮತ್ತು ತಿಳುವಳಿಕೆಗೆ ಸಾಕಷ್ಟು ಸೂಕ್ತವಲ್ಲ. ಇಲ್ಲಿ ಹಲವಾರು ಕಾರಣಗಳಿವೆ:

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

2011 ರಲ್ಲಿ, ಡೋಡೋ ಐಎಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

2020 ರ ಹೊತ್ತಿಗೆ, ಇದು ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಜಟಿಲವಾಗಿದೆ ಮತ್ತು ಈ ರೀತಿಯಾಗಿದೆ:

ಈ ವಿಕಾಸ ಹೇಗೆ ನಡೆಯಿತು? ಸಿಸ್ಟಮ್ನ ವಿವಿಧ ಭಾಗಗಳು ಏಕೆ ಬೇಕು? ಯಾವ ವಾಸ್ತುಶಿಲ್ಪದ ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ ಮತ್ತು ಏಕೆ? ಈ ಲೇಖನಗಳ ಸರಣಿಯಲ್ಲಿ ಕಂಡುಹಿಡಿಯೋಣ.

2016 ರ ಮೊದಲ ಸಮಸ್ಯೆಗಳು: ಸೇವೆಗಳು ಏಕಶಿಲೆಯನ್ನು ಏಕೆ ಬಿಡಬೇಕು

ಸೈಕಲ್‌ನಿಂದ ಮೊದಲ ಲೇಖನಗಳು ಏಕಶಿಲೆಯಿಂದ ಬೇರ್ಪಟ್ಟ ಮೊದಲ ಸೇವೆಗಳ ಬಗ್ಗೆ ಇರುತ್ತದೆ. ನಿಮ್ಮನ್ನು ಸನ್ನಿವೇಶದಲ್ಲಿ ಇರಿಸಲು, 2016 ರ ಆರಂಭದ ವೇಳೆಗೆ ನಾವು ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಯಾವ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂದು ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ, ನಾವು ಸೇವೆಗಳ ಪ್ರತ್ಯೇಕತೆಯನ್ನು ಎದುರಿಸಬೇಕಾಗಿದೆ.

ಒಂದೇ MySql ಡೇಟಾಬೇಸ್, ಇದರಲ್ಲಿ ಆ ಸಮಯದಲ್ಲಿ ಡೋಡೋ IS ನಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದ ಎಲ್ಲಾ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ತಮ್ಮ ದಾಖಲೆಗಳನ್ನು ಬರೆದವು. ಪರಿಣಾಮಗಳು ಹೀಗಿದ್ದವು:

• ಭಾರವಾದ ಹೊರೆ (85% ವಿನಂತಿಗಳೊಂದಿಗೆ ಓದುವಿಕೆಗಾಗಿ).
• ಬೇಸ್ ಬೆಳೆದಿದೆ. ಈ ಕಾರಣದಿಂದಾಗಿ, ಅದರ ವೆಚ್ಚ ಮತ್ತು ಬೆಂಬಲವು ಸಮಸ್ಯೆಯಾಯಿತು.
• ವೈಫಲ್ಯದ ಏಕೈಕ ಬಿಂದು. ಡೇಟಾಬೇಸ್‌ಗೆ ಬರೆಯುವ ಒಂದು ಅಪ್ಲಿಕೇಶನ್ ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಅದನ್ನು ಹೆಚ್ಚು ಸಕ್ರಿಯವಾಗಿ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದರೆ, ಇತರ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಅದನ್ನು ಸ್ವತಃ ಅನುಭವಿಸುತ್ತವೆ.
• ಸಂಗ್ರಹಣೆ ಮತ್ತು ಪ್ರಶ್ನೆಗಳಲ್ಲಿ ಅಸಮರ್ಥತೆ. ಸಾಮಾನ್ಯವಾಗಿ ಡೇಟಾವನ್ನು ಕೆಲವು ರಚನೆಯಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ ಅದು ಕೆಲವು ಸನ್ನಿವೇಶಗಳಿಗೆ ಅನುಕೂಲಕರವಾಗಿದೆ ಆದರೆ ಇತರರಿಗೆ ಸೂಕ್ತವಲ್ಲ. ಸೂಚ್ಯಂಕಗಳು ಕೆಲವು ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ವೇಗಗೊಳಿಸುತ್ತವೆ, ಆದರೆ ಇತರವುಗಳನ್ನು ನಿಧಾನಗೊಳಿಸಬಹುದು.
• ಕೆಲವು ಸಮಸ್ಯೆಗಳನ್ನು ತರಾತುರಿಯಲ್ಲಿ ಮಾಡಿದ ಸಂಗ್ರಹಗಳು ಮತ್ತು ಬೇಸ್‌ಗಳಿಗೆ ಓದುವ-ಪ್ರತಿಕೃತಿಗಳಿಂದ ತೆಗೆದುಹಾಕಲಾಗಿದೆ (ಇದು ಪ್ರತ್ಯೇಕ ಲೇಖನವಾಗಿರುತ್ತದೆ), ಆದರೆ ಅವರು ಸಮಯವನ್ನು ಪಡೆಯಲು ಮಾತ್ರ ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟರು ಮತ್ತು ಮೂಲಭೂತವಾಗಿ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲಿಲ್ಲ.

ಏಕಶಿಲೆಯ ಉಪಸ್ಥಿತಿಯೇ ಸಮಸ್ಯೆಯಾಗಿದೆ. ಪರಿಣಾಮಗಳು ಹೀಗಿದ್ದವು:

• ಏಕ ಮತ್ತು ಅಪರೂಪದ ಬಿಡುಗಡೆಗಳು.
• ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಜನರ ಜಂಟಿ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ತೊಂದರೆ.
• ಹೊಸ ತಂತ್ರಜ್ಞಾನಗಳು, ಹೊಸ ಚೌಕಟ್ಟುಗಳು ಮತ್ತು ಗ್ರಂಥಾಲಯಗಳನ್ನು ತರಲು ಅಸಮರ್ಥತೆ.

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

ಬ್ಯಾಕ್ ಆಫೀಸ್ ಮಾರ್ಗ: ಪ್ರತ್ಯೇಕ ಬೇಸ್ ಮತ್ತು ಬಸ್

ಅಧ್ಯಾಯ ನ್ಯಾವಿಗೇಷನ್

1. ಏಕಶಿಲೆಯ ಯೋಜನೆ 2016
2. ಏಕಶಿಲೆಯನ್ನು ಅನ್‌ಲೋಡ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತಿದೆ: ದೃಢೀಕರಣ ಮತ್ತು ಟ್ರ್ಯಾಕರ್ ಪ್ರತ್ಯೇಕತೆ
   
3. Auth ಏನು ಮಾಡುತ್ತದೆ?
4. ಲೋಡ್‌ಗಳು ಎಲ್ಲಿಂದ ಬರುತ್ತವೆ?
5. ದೃಢೀಕರಣವನ್ನು ಇಳಿಸಲಾಗುತ್ತಿದೆ
6. ಟ್ರ್ಯಾಕರ್ ಏನು ಮಾಡುತ್ತದೆ?
7. ಲೋಡ್‌ಗಳು ಎಲ್ಲಿಂದ ಬರುತ್ತವೆ?
8. ಟ್ರ್ಯಾಕರ್ ಅನ್ನು ಇಳಿಸಲಾಗುತ್ತಿದೆ

ಏಕಶಿಲೆಯ ಯೋಜನೆ 2016

Dodo IS 2016 ಏಕಶಿಲೆಯ ಮುಖ್ಯ ಬ್ಲಾಕ್‌ಗಳು ಇಲ್ಲಿವೆ ಮತ್ತು ಅವುಗಳ ಮುಖ್ಯ ಕಾರ್ಯಗಳ ಪ್ರತಿಲೇಖನವನ್ನು ಕೆಳಗೆ ನೀಡಲಾಗಿದೆ.

ಕ್ಯಾಷಿಯರ್ ವಿತರಣೆ. ಕೊರಿಯರ್‌ಗಳಿಗೆ ಲೆಕ್ಕಪತ್ರ ನಿರ್ವಹಣೆ, ಕೊರಿಯರ್‌ಗಳಿಗೆ ಆದೇಶಗಳನ್ನು ನೀಡುವುದು.
ಸಂಪರ್ಕ ಕೇಂದ್ರ. ಆಪರೇಟರ್ ಮೂಲಕ ಆದೇಶಗಳ ಸ್ವೀಕಾರ.
ಸೈಟ್. ನಮ್ಮ ವೆಬ್‌ಸೈಟ್‌ಗಳು (dodopizza.ru, dodopizza.co.uk, dodopizza.by, ಇತ್ಯಾದಿ).
ದೃ uth ೀಕರಣ. ಬ್ಯಾಕ್ ಆಫೀಸ್‌ಗಾಗಿ ದೃಢೀಕರಣ ಮತ್ತು ದೃಢೀಕರಣ ಸೇವೆ.
ಟ್ರ್ಯಾಕರ್. ಅಡುಗೆಮನೆಯಲ್ಲಿ ಟ್ರ್ಯಾಕರ್ ಅನ್ನು ಆದೇಶಿಸಿ. ಆದೇಶವನ್ನು ಸಿದ್ಧಪಡಿಸುವಾಗ ಸಿದ್ಧತೆ ಸ್ಥಿತಿಗಳನ್ನು ಗುರುತಿಸಲು ಸೇವೆ.
ರೆಸ್ಟೋರೆಂಟ್‌ನ ನಗದು ಮೇಜು. ರೆಸ್ಟೋರೆಂಟ್, ಕ್ಯಾಷಿಯರ್ ಇಂಟರ್ಫೇಸ್‌ಗಳಲ್ಲಿ ಆದೇಶಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದು.
ರಫ್ತು. ಲೆಕ್ಕಪತ್ರ ನಿರ್ವಹಣೆಗಾಗಿ 1C ಯಲ್ಲಿ ವರದಿಗಳನ್ನು ಅಪ್‌ಲೋಡ್ ಮಾಡಲಾಗುತ್ತಿದೆ.
ಅಧಿಸೂಚನೆಗಳು ಮತ್ತು ಇನ್‌ವಾಯ್ಸ್‌ಗಳು. ಅಡುಗೆಮನೆಯಲ್ಲಿ ಧ್ವನಿ ಆಜ್ಞೆಗಳು (ಉದಾಹರಣೆಗೆ, "ಹೊಸ ಪಿಜ್ಜಾ ಬಂದಿತು") + ಕೊರಿಯರ್‌ಗಳಿಗಾಗಿ ಸರಕುಪಟ್ಟಿ ಮುದ್ರಣ.
ಶಿಫ್ಟ್ ಮ್ಯಾನೇಜರ್. ಶಿಫ್ಟ್ ಮ್ಯಾನೇಜರ್ನ ಕೆಲಸಕ್ಕಾಗಿ ಇಂಟರ್ಫೇಸ್ಗಳು: ಆದೇಶಗಳ ಪಟ್ಟಿ, ಕಾರ್ಯಕ್ಷಮತೆಯ ಗ್ರಾಫ್ಗಳು, ಶಿಫ್ಟ್ಗೆ ನೌಕರರ ವರ್ಗಾವಣೆ.
ಕಚೇರಿ ವ್ಯವಸ್ಥಾಪಕ. ಫ್ರ್ಯಾಂಚೈಸಿ ಮತ್ತು ವ್ಯವಸ್ಥಾಪಕರ ಕೆಲಸಕ್ಕಾಗಿ ಇಂಟರ್ಫೇಸ್ಗಳು: ಉದ್ಯೋಗಿಗಳ ಸ್ವಾಗತ, ಪಿಜ್ಜೇರಿಯಾದ ಕೆಲಸದ ವರದಿಗಳು.
ರೆಸ್ಟೋರೆಂಟ್ ಸ್ಕೋರ್ಬೋರ್ಡ್. ಪಿಜ್ಜೇರಿಯಾಗಳಲ್ಲಿ ಟಿವಿಗಳಲ್ಲಿ ಮೆನು ಪ್ರದರ್ಶನ.
ನಿರ್ವಾಹಕ. ನಿರ್ದಿಷ್ಟ ಪಿಜ್ಜೇರಿಯಾದಲ್ಲಿನ ಸೆಟ್ಟಿಂಗ್‌ಗಳು: ಮೆನು, ಬೆಲೆಗಳು, ಲೆಕ್ಕಪತ್ರ ನಿರ್ವಹಣೆ, ಪ್ರೋಮೋ ಕೋಡ್‌ಗಳು, ಪ್ರಚಾರಗಳು, ವೆಬ್‌ಸೈಟ್ ಬ್ಯಾನರ್‌ಗಳು, ಇತ್ಯಾದಿ.
ಉದ್ಯೋಗಿಯ ವೈಯಕ್ತಿಕ ಖಾತೆ. ಉದ್ಯೋಗಿಗಳ ಕೆಲಸದ ವೇಳಾಪಟ್ಟಿಗಳು, ಉದ್ಯೋಗಿಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿ.
ಕಿಚನ್ ಪ್ರೇರಣೆ ಮಂಡಳಿ. ಅಡುಗೆಮನೆಯಲ್ಲಿ ನೇತಾಡುವ ಮತ್ತು ಪಿಜ್ಜಾ ತಯಾರಕರ ವೇಗವನ್ನು ಪ್ರದರ್ಶಿಸುವ ಪ್ರತ್ಯೇಕ ಪರದೆ.
ಸಂವಹನ. sms ಮತ್ತು ಇಮೇಲ್ ಕಳುಹಿಸಲಾಗುತ್ತಿದೆ.
ಫೈಲ್ ಸ್ಟೋರೇಜ್. ಸ್ಥಿರ ಫೈಲ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಮತ್ತು ವಿತರಿಸಲು ಸ್ವಂತ ಸೇವೆ.

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

ಏಕಶಿಲೆಯನ್ನು ಅನ್‌ಲೋಡ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತಿದೆ: ದೃಢೀಕರಣ ಮತ್ತು ಟ್ರ್ಯಾಕರ್ ಪ್ರತ್ಯೇಕತೆ

ಇತರರಿಗಿಂತ ಹೆಚ್ಚಾಗಿ ಡೇಟಾಬೇಸ್‌ನಿಂದ ರೆಕಾರ್ಡ್ ಮಾಡಿದ ಮತ್ತು ಓದುವ ಮುಖ್ಯ ಸೇವೆಗಳು:

1. ದೃಢೀಕರಣ. ಬ್ಯಾಕ್ ಆಫೀಸ್‌ಗಾಗಿ ದೃಢೀಕರಣ ಮತ್ತು ದೃಢೀಕರಣ ಸೇವೆ.
2. ಟ್ರ್ಯಾಕರ್. ಅಡುಗೆಮನೆಯಲ್ಲಿ ಟ್ರ್ಯಾಕರ್ ಅನ್ನು ಆದೇಶಿಸಿ. ಆದೇಶವನ್ನು ಸಿದ್ಧಪಡಿಸುವಾಗ ಸಿದ್ಧತೆ ಸ್ಥಿತಿಗಳನ್ನು ಗುರುತಿಸಲು ಸೇವೆ.

Auth ಏನು ಮಾಡುತ್ತದೆ?

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

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

ಲೋಡ್‌ಗಳು ಎಲ್ಲಿಂದ ಬರುತ್ತವೆ?

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

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

ದೃಢೀಕರಣವನ್ನು ಇಳಿಸಲಾಗುತ್ತಿದೆ

Auth ಪ್ರತ್ಯೇಕವಾದ ಡೊಮೇನ್ ಅನ್ನು ಹೊಂದಿದೆ, ಅಂದರೆ, ಬಳಕೆದಾರರು, ಲಾಗಿನ್‌ಗಳು ಅಥವಾ ಸಾಧನಗಳ ಕುರಿತಾದ ಡೇಟಾವು ಸೇವೆಯನ್ನು ಪ್ರವೇಶಿಸುತ್ತದೆ (ಸದ್ಯಕ್ಕೆ) ಮತ್ತು ಅಲ್ಲಿಯೇ ಇರುತ್ತದೆ. ಯಾರಿಗಾದರೂ ಅವರಿಗೆ ಅಗತ್ಯವಿದ್ದರೆ, ಅವರು ಡೇಟಾಕ್ಕಾಗಿ ಈ ಸೇವೆಗೆ ಹೋಗುತ್ತಾರೆ.

ಆಗಿತ್ತು. ಕೆಲಸದ ಮೂಲ ಯೋಜನೆ ಈ ಕೆಳಗಿನಂತಿತ್ತು:

ಅದು ಹೇಗೆ ಕೆಲಸ ಮಾಡಿದೆ ಎಂಬುದನ್ನು ನಾನು ಸ್ವಲ್ಪ ವಿವರಿಸಲು ಬಯಸುತ್ತೇನೆ:

1. ಹೊರಗಿನಿಂದ ವಿನಂತಿಯು ಬ್ಯಾಕೆಂಡ್‌ಗೆ ಬರುತ್ತದೆ (Asp.Net MVC ಇದೆ), ಅದರೊಂದಿಗೆ ಒಂದು ಸೆಶನ್ ಕುಕೀಯನ್ನು ತರುತ್ತದೆ, ಇದನ್ನು ರೆಡಿಸ್(1) ನಿಂದ ಸೆಷನ್ ಡೇಟಾವನ್ನು ಪಡೆಯಲು ಬಳಸಲಾಗುತ್ತದೆ. ಇದು ಪ್ರವೇಶಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಹೊಂದಿರುತ್ತದೆ, ಮತ್ತು ನಂತರ ನಿಯಂತ್ರಕಕ್ಕೆ ಪ್ರವೇಶವು ತೆರೆದಿರುತ್ತದೆ (3,4), ಅಥವಾ ಇಲ್ಲ.
2. ಯಾವುದೇ ಪ್ರವೇಶವಿಲ್ಲದಿದ್ದರೆ, ನೀವು ದೃಢೀಕರಣ ಕಾರ್ಯವಿಧಾನದ ಮೂಲಕ ಹೋಗಬೇಕಾಗುತ್ತದೆ. ಇಲ್ಲಿ, ಸರಳತೆಗಾಗಿ, ಇದು ಲಾಗಿನ್ ಪುಟಕ್ಕೆ ಪರಿವರ್ತನೆಯಾಗಿದ್ದರೂ, ಅದೇ ಗುಣಲಕ್ಷಣದಲ್ಲಿ ಮಾರ್ಗದ ಭಾಗವಾಗಿ ತೋರಿಸಲಾಗಿದೆ. ಸಕಾರಾತ್ಮಕ ಸನ್ನಿವೇಶದಲ್ಲಿ, ನಾವು ಸರಿಯಾಗಿ ಪೂರ್ಣಗೊಂಡ ಸೆಷನ್ ಅನ್ನು ಪಡೆಯುತ್ತೇವೆ ಮತ್ತು ಬ್ಯಾಕ್ ಆಫೀಸ್ ನಿಯಂತ್ರಕಕ್ಕೆ ಹೋಗುತ್ತೇವೆ.
3. ಡೇಟಾ ಇದ್ದರೆ, ಬಳಕೆದಾರ ನೆಲೆಯಲ್ಲಿ ಪ್ರಸ್ತುತತೆಗಾಗಿ ನೀವು ಅದನ್ನು ಪರಿಶೀಲಿಸಬೇಕು. ಅವರ ಪಾತ್ರ ಬದಲಾಗಿದೆ, ಈಗ ಅವರಿಗೆ ಪುಟದಲ್ಲಿ ಅವಕಾಶ ನೀಡಬಾರದು? ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಸೆಷನ್ (1) ಅನ್ನು ಸ್ವೀಕರಿಸಿದ ನಂತರ, ನೀವು ನೇರವಾಗಿ ಡೇಟಾಬೇಸ್‌ಗೆ ಹೋಗಬೇಕು ಮತ್ತು ದೃಢೀಕರಣ ಲಾಜಿಕ್ ಲೇಯರ್ (2) ಅನ್ನು ಬಳಸಿಕೊಂಡು ಬಳಕೆದಾರರ ಪ್ರವೇಶವನ್ನು ಪರಿಶೀಲಿಸಬೇಕು. ಮುಂದೆ, ಲಾಗಿನ್ ಪುಟಕ್ಕೆ, ಅಥವಾ ನಿಯಂತ್ರಕಕ್ಕೆ ಹೋಗಿ. ಅಂತಹ ಸರಳ ವ್ಯವಸ್ಥೆ, ಆದರೆ ಸಾಕಷ್ಟು ಪ್ರಮಾಣಿತವಲ್ಲ.
4. ಎಲ್ಲಾ ಕಾರ್ಯವಿಧಾನಗಳು ಅಂಗೀಕರಿಸಲ್ಪಟ್ಟರೆ, ನಂತರ ನಾವು ನಿಯಂತ್ರಕಗಳು ಮತ್ತು ವಿಧಾನಗಳಲ್ಲಿನ ತರ್ಕದಲ್ಲಿ ಮತ್ತಷ್ಟು ಬಿಟ್ಟುಬಿಡುತ್ತೇವೆ.

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

ಬಿಕಮ್. ಆದ್ದರಿಂದ ಅವರು ಮಾಡಿದರು:

ಈ ವಿಧಾನವು ಹಲವಾರು ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿದೆ. ಉದಾಹರಣೆಗೆ, ಪ್ರಕ್ರಿಯೆಯ ಒಳಗಿನ ವಿಧಾನವನ್ನು ಕರೆಯುವುದು http ಮೂಲಕ ಬಾಹ್ಯ ಸೇವೆಗೆ ಕರೆ ಮಾಡುವಂತೆಯೇ ಅಲ್ಲ. ಸುಪ್ತತೆ, ವಿಶ್ವಾಸಾರ್ಹತೆ, ನಿರ್ವಹಣೆ, ಕಾರ್ಯಾಚರಣೆಯ ಪಾರದರ್ಶಕತೆ ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನವಾಗಿದೆ. ಆಂಡ್ರೆ ಮೊರೆವ್ಸ್ಕಿ ತನ್ನ ವರದಿಯಲ್ಲಿ ಅಂತಹ ಸಮಸ್ಯೆಗಳ ಬಗ್ಗೆ ಹೆಚ್ಚು ವಿವರವಾಗಿ ಮಾತನಾಡಿದರು. "50 ಷೇಡ್ಸ್ ಆಫ್ ಮೈಕ್ರೋ ಸರ್ವೀಸ್".

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

ಬೇರ್ಪಡಿಕೆಗೆ ಏಕೆ ಇಷ್ಟು ಸಮಯ ಹಿಡಿಯಿತು?
ದಾರಿಯುದ್ದಕ್ಕೂ ಹಲವು ಸಮಸ್ಯೆಗಳು ನಮ್ಮನ್ನು ನಿಧಾನಗೊಳಿಸಿದವು:

1. ದೇಶ-ನಿರ್ದಿಷ್ಟ ಡೇಟಾಬೇಸ್‌ಗಳಿಂದ ಬಳಕೆದಾರರು, ಸಾಧನ ಮತ್ತು ದೃಢೀಕರಣ ಡೇಟಾವನ್ನು ಒಂದಕ್ಕೆ ಸರಿಸಲು ನಾವು ಬಯಸುತ್ತೇವೆ. ಇದನ್ನು ಮಾಡಲು, ನಾವು ಎಲ್ಲಾ ಕೋಷ್ಟಕಗಳು ಮತ್ತು ಬಳಕೆಯನ್ನು ಇಂಟ್ ಐಡೆಂಟಿಫೈಯರ್‌ನಿಂದ ಜಾಗತಿಕ UUId ಗುರುತಿಸುವಿಕೆಗೆ ಭಾಷಾಂತರಿಸಬೇಕಾಗಿತ್ತು (ಇತ್ತೀಚೆಗೆ ಈ ಕೋಡ್ ಅನ್ನು ಪುನಃ ರಚಿಸಲಾಗಿದೆ ರೋಮನ್ ಬುಕಿನ್ "Uuid - ಒಂದು ಸಣ್ಣ ರಚನೆಯ ದೊಡ್ಡ ಕಥೆ" ಮತ್ತು ಮುಕ್ತ ಮೂಲ ಯೋಜನೆ ಆದಿಮಾನವರು) ಬಳಕೆದಾರರ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವುದು (ಇದು ವೈಯಕ್ತಿಕ ಮಾಹಿತಿಯಾದ್ದರಿಂದ) ಅದರ ಮಿತಿಗಳನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ಕೆಲವು ದೇಶಗಳಿಗೆ ಅವುಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಸಂಗ್ರಹಿಸುವುದು ಅವಶ್ಯಕ. ಆದರೆ ಬಳಕೆದಾರರ ಜಾಗತಿಕ ಐಡಿ ಇರಬೇಕು.
2. ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿರುವ ಅನೇಕ ಕೋಷ್ಟಕಗಳು ಕಾರ್ಯಾಚರಣೆಯನ್ನು ನಿರ್ವಹಿಸಿದ ಬಳಕೆದಾರರ ಬಗ್ಗೆ ಆಡಿಟ್ ಮಾಹಿತಿಯನ್ನು ಹೊಂದಿವೆ. ಇದಕ್ಕೆ ಸ್ಥಿರತೆಗಾಗಿ ಹೆಚ್ಚುವರಿ ಕಾರ್ಯವಿಧಾನದ ಅಗತ್ಯವಿದೆ.
3. Api-ಸೇವೆಗಳ ರಚನೆಯ ನಂತರ, ಮತ್ತೊಂದು ವ್ಯವಸ್ಥೆಗೆ ಪರಿವರ್ತನೆಯ ದೀರ್ಘ ಮತ್ತು ಕ್ರಮೇಣ ಅವಧಿ ಇತ್ತು. ಸ್ವಿಚಿಂಗ್ ಬಳಕೆದಾರರಿಗೆ ತಡೆರಹಿತವಾಗಿರಬೇಕು ಮತ್ತು ಕೈಯಿಂದ ಕೆಲಸ ಮಾಡಬೇಕಾಗುತ್ತದೆ.

ಪಿಜ್ಜೇರಿಯಾದಲ್ಲಿ ಸಾಧನ ನೋಂದಣಿ ಯೋಜನೆ:

ದೃಢೀಕರಣ ಮತ್ತು ಸಾಧನಗಳ ಸೇವೆಯನ್ನು ಹೊರತೆಗೆದ ನಂತರ ಸಾಮಾನ್ಯ ವಾಸ್ತುಶಿಲ್ಪ:

ಹೇಳಿಕೆಯನ್ನು. 2020 ಕ್ಕೆ, ನಾವು OAuth 2.0 ದೃಢೀಕರಣ ಮಾನದಂಡವನ್ನು ಆಧರಿಸಿದ Auth ನ ಹೊಸ ಆವೃತ್ತಿಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದ್ದೇವೆ. ಈ ಮಾನದಂಡವು ಸಾಕಷ್ಟು ಸಂಕೀರ್ಣವಾಗಿದೆ, ಆದರೆ ಪಾಸ್-ಥ್ರೂ ದೃಢೀಕರಣ ಸೇವೆಯನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಇದು ಉಪಯುಕ್ತವಾಗಿದೆ. ಲೇಖನದಲ್ಲಿ "ದೃಢೀಕರಣದ ಸೂಕ್ಷ್ಮತೆಗಳು: OAuth 2.0 ತಂತ್ರಜ್ಞಾನದ ಒಂದು ಅವಲೋಕನ»ನಾವು ಅಲೆಕ್ಸಿ ಚೆರ್ನ್ಯಾವ್ ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಅನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಸರಳವಾಗಿ ಮತ್ತು ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳಲು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ ಇದರಿಂದ ನೀವು ಅದನ್ನು ಅಧ್ಯಯನ ಮಾಡಲು ಸಮಯವನ್ನು ಉಳಿಸುತ್ತೀರಿ.

ಟ್ರ್ಯಾಕರ್ ಏನು ಮಾಡುತ್ತದೆ?

ಈಗ ಲೋಡ್ ಮಾಡಲಾದ ಸೇವೆಗಳ ಎರಡನೇ ಬಗ್ಗೆ. ಟ್ರ್ಯಾಕರ್ ಎರಡು ಪಾತ್ರವನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ:

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

ಹೊಸ ಉತ್ಪನ್ನವು ಆದೇಶದಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡಾಗ (ಉದಾಹರಣೆಗೆ, ಪಿಜ್ಜಾ), ಅದು ರೋಲಿಂಗ್ ಔಟ್ ಟ್ರ್ಯಾಕರ್ ಸ್ಟೇಷನ್‌ಗೆ ಹೋಗುತ್ತದೆ. ಈ ನಿಲ್ದಾಣದಲ್ಲಿ, ಪಿಜ್ಜಾ ತಯಾರಕರೊಬ್ಬರು ಅಗತ್ಯವಿರುವ ಗಾತ್ರದ ಬನ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡು ಅದನ್ನು ಹೊರತೆಗೆಯುತ್ತಾರೆ, ನಂತರ ಅವರು ಟ್ರ್ಯಾಕರ್ ಟ್ಯಾಬ್ಲೆಟ್‌ನಲ್ಲಿ ತಮ್ಮ ಕೆಲಸವನ್ನು ಪೂರ್ಣಗೊಳಿಸಿದ್ದಾರೆ ಮತ್ತು ಸುತ್ತಿಕೊಂಡ ಹಿಟ್ಟಿನ ಬೇಸ್ ಅನ್ನು ಮುಂದಿನ ನಿಲ್ದಾಣಕ್ಕೆ ವರ್ಗಾಯಿಸುತ್ತಾರೆ - “ದೀಕ್ಷೆ”. .

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

ಟ್ರ್ಯಾಕರ್ "ರಸ್ಕಟ್ಕಾ" ನಿಲ್ದಾಣದಲ್ಲಿ ಟ್ಯಾಬ್ಲೆಟ್ನ ಪರದೆಯು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ

ಲೋಡ್‌ಗಳು ಎಲ್ಲಿಂದ ಬರುತ್ತವೆ?

ಪ್ರತಿಯೊಂದು ಪಿಜ್ಜೇರಿಯಾಗಳು ಟ್ರ್ಯಾಕರ್‌ನೊಂದಿಗೆ ಸುಮಾರು ಐದು ಮಾತ್ರೆಗಳನ್ನು ಹೊಂದಿರುತ್ತವೆ. 2016 ರಲ್ಲಿ, ನಾವು 100 ಕ್ಕೂ ಹೆಚ್ಚು ಪಿಜ್ಜೇರಿಯಾಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ (ಮತ್ತು ಈಗ 600 ಕ್ಕಿಂತ ಹೆಚ್ಚು). ಪ್ರತಿಯೊಂದು ಟ್ಯಾಬ್ಲೆಟ್‌ಗಳು ಪ್ರತಿ 10 ಸೆಕೆಂಡುಗಳಿಗೊಮ್ಮೆ ಬ್ಯಾಕೆಂಡ್‌ಗೆ ವಿನಂತಿಯನ್ನು ಮಾಡುತ್ತವೆ ಮತ್ತು ಆರ್ಡರ್ ಟೇಬಲ್ (ಕ್ಲೈಂಟ್ ಮತ್ತು ವಿಳಾಸದೊಂದಿಗೆ ಸಂಪರ್ಕ), ಆರ್ಡರ್ ಸಂಯೋಜನೆ (ಉತ್ಪನ್ನದೊಂದಿಗೆ ಸಂಪರ್ಕ ಮತ್ತು ಪ್ರಮಾಣದ ಸೂಚನೆ), ಪ್ರೇರಣೆ ಲೆಕ್ಕಪತ್ರ ಕೋಷ್ಟಕ (ದಿ ಒತ್ತುವ ಸಮಯವನ್ನು ಅದರಲ್ಲಿ ಟ್ರ್ಯಾಕ್ ಮಾಡಲಾಗುತ್ತದೆ). ಪಿಜ್ಜಾ ತಯಾರಕರು ಟ್ರ್ಯಾಕರ್‌ನಲ್ಲಿ ಉತ್ಪನ್ನದ ಮೇಲೆ ಕ್ಲಿಕ್ ಮಾಡಿದಾಗ, ಈ ಎಲ್ಲಾ ಕೋಷ್ಟಕಗಳಲ್ಲಿನ ನಮೂದುಗಳನ್ನು ನವೀಕರಿಸಲಾಗುತ್ತದೆ. ಆರ್ಡರ್ ಟೇಬಲ್ ಸಾಮಾನ್ಯವಾಗಿದೆ, ಇದು ಆದೇಶವನ್ನು ಸ್ವೀಕರಿಸುವಾಗ ಒಳಸೇರಿಸುತ್ತದೆ, ಸಿಸ್ಟಮ್‌ನ ಇತರ ಭಾಗಗಳಿಂದ ನವೀಕರಣಗಳು ಮತ್ತು ಹಲವಾರು ವಾಚನಗೋಷ್ಠಿಗಳು, ಉದಾಹರಣೆಗೆ, ಪಿಜ್ಜೇರಿಯಾದಲ್ಲಿ ನೇತಾಡುವ ಮತ್ತು ಗ್ರಾಹಕರಿಗೆ ಮುಗಿದ ಆದೇಶಗಳನ್ನು ತೋರಿಸುವ ಟಿವಿಯಲ್ಲಿ.

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

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

ಆಗಿತ್ತು. ಮೂಲ ವಾಸ್ತುಶಿಲ್ಪ ಹೀಗಿತ್ತು:

ಪ್ರತ್ಯೇಕ ಪ್ರಕ್ರಿಯೆಗಳಾಗಿ ಬೇರ್ಪಟ್ಟ ನಂತರವೂ, ಹೆಚ್ಚಿನ ಕೋಡ್ ಬೇಸ್ ವಿಭಿನ್ನ ಸೇವೆಗಳಿಗೆ ಸಾಮಾನ್ಯವಾಗಿದೆ. ನಿಯಂತ್ರಕಗಳ ಕೆಳಗೆ ಇರುವ ಎಲ್ಲವೂ ಒಂದೇ ಆಗಿದ್ದವು ಮತ್ತು ಅದೇ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ವಾಸಿಸುತ್ತಿದ್ದವು. ನಾವು ಸೇವೆಗಳ ಸಾಮಾನ್ಯ ವಿಧಾನಗಳನ್ನು ಬಳಸಿದ್ದೇವೆ, ರೆಪೊಸಿಟರಿಗಳು, ಸಾಮಾನ್ಯ ಬೇಸ್, ಇದರಲ್ಲಿ ಸಾಮಾನ್ಯ ಕೋಷ್ಟಕಗಳು ಇಡುತ್ತವೆ.

ಟ್ರ್ಯಾಕರ್ ಅನ್ನು ಇಳಿಸಲಾಗುತ್ತಿದೆ

ಟ್ರ್ಯಾಕರ್‌ನ ಮುಖ್ಯ ಸಮಸ್ಯೆಯೆಂದರೆ ಡೇಟಾವನ್ನು ವಿಭಿನ್ನ ಡೇಟಾಬೇಸ್‌ಗಳ ನಡುವೆ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಬೇಕು. ದೃಢೀಕರಣ ಸೇವೆಯ ಪ್ರತ್ಯೇಕತೆಯಿಂದ ಇದು ಅದರ ಪ್ರಮುಖ ವ್ಯತ್ಯಾಸವಾಗಿದೆ, ಆದೇಶ ಮತ್ತು ಅದರ ಸ್ಥಿತಿಯು ಬದಲಾಗಬಹುದು ಮತ್ತು ವಿಭಿನ್ನ ಸೇವೆಗಳಲ್ಲಿ ಪ್ರದರ್ಶಿಸಬೇಕು.

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

ಆದೇಶದ ಸ್ಥಿತಿಗಳನ್ನು ಬದಲಾಯಿಸುವ ಯೋಜನೆಯು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

ವಿವಿಧ ವ್ಯವಸ್ಥೆಗಳ ನಡುವೆ ಸ್ಥಿತಿಗಳು ಬದಲಾಗುತ್ತವೆ. ಮತ್ತು ಇಲ್ಲಿ ಟ್ರ್ಯಾಕರ್ ಡೇಟಾವನ್ನು ಮುಚ್ಚಿರುವ ಅಂತಿಮ ವ್ಯವಸ್ಥೆಯಾಗಿಲ್ಲ. ಅಂತಹ ಸಂದರ್ಭದಲ್ಲಿ ವಿಭಜನೆಗಾಗಿ ನಾವು ಹಲವಾರು ಸಂಭಾವ್ಯ ವಿಧಾನಗಳನ್ನು ನೋಡಿದ್ದೇವೆ:

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

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

ಆ ಹೊತ್ತಿಗೆ, ನಾವು ಈಗಾಗಲೇ RabbitMQ ಅನ್ನು ಸ್ಟಾಕ್‌ನಲ್ಲಿ ಹೊಂದಿದ್ದೇವೆ, ಆದ್ದರಿಂದ ಅದನ್ನು ಸಂದೇಶ ಬ್ರೋಕರ್ ಆಗಿ ಬಳಸಲು ಅಂತಿಮ ನಿರ್ಧಾರ. ಟ್ರ್ಯಾಕರ್ ಮೂಲಕ ರೆಸ್ಟೋರೆಂಟ್ ಕ್ಯಾಷಿಯರ್‌ನಿಂದ ಆದೇಶದ ಪರಿವರ್ತನೆಯನ್ನು ರೇಖಾಚಿತ್ರವು ತೋರಿಸುತ್ತದೆ, ಅಲ್ಲಿ ಅದು ಮ್ಯಾನೇಜರ್ ಆರ್ಡರ್ಸ್ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ಅದರ ಸ್ಥಿತಿಯನ್ನು ಮತ್ತು ಅದರ ಪ್ರದರ್ಶನವನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ಬಿಕಮ್:

ಹಂತ ಹಂತವಾಗಿ ಮಾರ್ಗವನ್ನು ಆದೇಶಿಸಿ
ಆದೇಶದ ಮಾರ್ಗವು ಆರ್ಡರ್ ಮೂಲ ಸೇವೆಗಳಲ್ಲಿ ಒಂದರಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ರೆಸ್ಟೋರೆಂಟ್‌ನ ಕ್ಯಾಷಿಯರ್ ಇಲ್ಲಿದೆ:

1. ಚೆಕ್ಔಟ್ನಲ್ಲಿ, ಆದೇಶವು ಸಂಪೂರ್ಣವಾಗಿ ಸಿದ್ಧವಾಗಿದೆ ಮತ್ತು ಅದನ್ನು ಟ್ರ್ಯಾಕರ್ಗೆ ಕಳುಹಿಸುವ ಸಮಯ. ಟ್ರ್ಯಾಕರ್ ಚಂದಾದಾರರಾಗಿರುವ ಈವೆಂಟ್ ಅನ್ನು ಎಸೆಯಲಾಗುತ್ತದೆ.
2. ಟ್ರ್ಯಾಕರ್, ಸ್ವತಃ ಆದೇಶವನ್ನು ಸ್ವೀಕರಿಸಿ, ಅದನ್ನು ತನ್ನದೇ ಆದ ಡೇಟಾಬೇಸ್‌ಗೆ ಉಳಿಸುತ್ತದೆ, ಈವೆಂಟ್ ಅನ್ನು "ಟ್ರ್ಯಾಕರ್ ಸ್ವೀಕರಿಸಿದ ಆದೇಶ" ಮಾಡಿ ಮತ್ತು ಅದನ್ನು RMQ ಗೆ ಕಳುಹಿಸುತ್ತದೆ.
3. ಪ್ರತಿ ಆರ್ಡರ್‌ಗೆ ಈವೆಂಟ್ ಬಸ್‌ಗೆ ಈಗಾಗಲೇ ಹಲವಾರು ನಿರ್ವಾಹಕರು ಚಂದಾದಾರರಾಗಿದ್ದಾರೆ. ನಮಗೆ, ಏಕಶಿಲೆಯ ಬೇಸ್ನೊಂದಿಗೆ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಮಾಡುವ ಒಂದು ಮುಖ್ಯವಾಗಿದೆ.
4. ಹ್ಯಾಂಡ್ಲರ್ ಈವೆಂಟ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾರೆ, ಅದರಲ್ಲಿ ಗಮನಾರ್ಹವಾದ ಡೇಟಾವನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತಾರೆ: ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಇದು "ಟ್ರ್ಯಾಕರ್ ಸ್ವೀಕರಿಸಿದ" ಆದೇಶದ ಸ್ಥಿತಿಯಾಗಿದೆ ಮತ್ತು ಮುಖ್ಯ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಅದರ ಆದೇಶ ಘಟಕವನ್ನು ನವೀಕರಿಸುತ್ತದೆ.

ಯಾರಿಗಾದರೂ ಏಕಶಿಲೆಯ ಟೇಬಲ್ ಆದೇಶಗಳಿಂದ ಆದೇಶ ಅಗತ್ಯವಿದ್ದರೆ, ನೀವು ಅದನ್ನು ಅಲ್ಲಿಂದ ಓದಬಹುದು. ಉದಾಹರಣೆಗೆ, ಶಿಫ್ಟ್ ಮ್ಯಾನೇಜರ್‌ನಲ್ಲಿನ ಆದೇಶಗಳ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಇದು ಅಗತ್ಯವಿದೆ:

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

ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ ಆದೇಶವನ್ನು ಕೆಲಸಕ್ಕೆ ತೆಗೆದುಕೊಂಡರೆ, ಅದರ ಸ್ಥಿತಿಯು ಮೊದಲು ಅದರ ಡೇಟಾಬೇಸ್ (ಟ್ರ್ಯಾಕರ್ ಡೇಟಾಬೇಸ್) ನಲ್ಲಿ ಬದಲಾಗುತ್ತದೆ, ಮತ್ತು ನಂತರ "ಆರ್ಡರ್ಇನ್ ಪ್ರೋಗ್ರೆಸ್" ಈವೆಂಟ್ ಅನ್ನು ತಕ್ಷಣವೇ ರಚಿಸಲಾಗುತ್ತದೆ. ಇದು RMQ ಗೆ ಸೇರುತ್ತದೆ, ಅಲ್ಲಿಂದ ಅದನ್ನು ಏಕಶಿಲೆಯ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಇತರ ಸೇವೆಗಳಿಗೆ ತಲುಪಿಸಲಾಗುತ್ತದೆ. ದಾರಿಯುದ್ದಕ್ಕೂ ವಿವಿಧ ಸಮಸ್ಯೆಗಳಿರಬಹುದು, ಅವುಗಳ ಬಗ್ಗೆ ಹೆಚ್ಚಿನ ವಿವರಗಳನ್ನು ಝೆನ್ಯಾ ಪೆಶ್ಕೋವ್ ವರದಿಯಲ್ಲಿ ಕಾಣಬಹುದು ಟ್ರ್ಯಾಕರ್‌ನಲ್ಲಿ ಅಂತಿಮ ಸ್ಥಿರತೆಯ ಅನುಷ್ಠಾನದ ವಿವರಗಳ ಬಗ್ಗೆ.

ದೃಢೀಕರಣ ಮತ್ತು ಟ್ರ್ಯಾಕರ್‌ನಲ್ಲಿನ ಬದಲಾವಣೆಗಳ ನಂತರ ಅಂತಿಮ ಆರ್ಕಿಟೆಕ್ಚರ್

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

ಅಂತಹ ವಸ್ತುಗಳ ಪ್ರಯೋಜನಗಳನ್ನು (ಅಥವಾ ಅದರ ಕೊರತೆ) ಪ್ರತಿಬಿಂಬಿಸುತ್ತಾ, ಘಟನೆಗಳ ಪೂರ್ಣ ಪ್ರಮಾಣದ ವಾರ್ಷಿಕೋತ್ಸವಗಳು, ವಿವರವಾದ ಹಿನ್ನೋಟಗಳು ಮತ್ತು ನನ್ನ ಹಿಂದಿನ ನಿರ್ಧಾರಗಳ ವಿಶ್ಲೇಷಣೆಯಿಲ್ಲದೆ ನಿರಂತರ ಅಭಿವೃದ್ಧಿ ಅಸಾಧ್ಯವೆಂದು ನಾನು ತೀರ್ಮಾನಕ್ಕೆ ಬಂದಿದ್ದೇನೆ.

ನಮ್ಮ ಮಾರ್ಗದ ಬಗ್ಗೆ ತಿಳಿದುಕೊಳ್ಳಲು ನಿಮಗೆ ಉಪಯುಕ್ತ ಮತ್ತು ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಮುಂದಿನ ಲೇಖನದಲ್ಲಿ ಡೋಡೋ ಐಎಸ್ ಸಿಸ್ಟಮ್‌ನ ಯಾವ ಭಾಗವನ್ನು ವಿವರಿಸಬೇಕು ಎಂಬ ಆಯ್ಕೆಯನ್ನು ಈಗ ನಾನು ಎದುರಿಸುತ್ತಿದ್ದೇನೆ: ಕಾಮೆಂಟ್‌ಗಳಲ್ಲಿ ಬರೆಯಿರಿ ಅಥವಾ ಮತ ಚಲಾಯಿಸಿ.

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

ಮುಂದಿನ ಲೇಖನದಲ್ಲಿ ನೀವು Dodo IS ನ ಯಾವ ಭಾಗದ ಬಗ್ಗೆ ತಿಳಿದುಕೊಳ್ಳಲು ಬಯಸುತ್ತೀರಿ?

• 24,1%ಡೋಡೋ IS ನಲ್ಲಿ ಆರಂಭಿಕ ಏಕಶಿಲೆ (2011-2015)14

• 24,1%ಮೊದಲ ಸಮಸ್ಯೆಗಳು ಮತ್ತು ಅವುಗಳ ಪರಿಹಾರಗಳು (2015-2016)14

• 20,7%ಕ್ಲೈಂಟ್-ಸೈಡ್ ಮಾರ್ಗ: ಬೇಸ್ ಮೇಲೆ ಮುಂಭಾಗ (2016-2017)12

• 36,2%ನೈಜ ಮೈಕ್ರೋ ಸರ್ವಿಸ್‌ಗಳ ಇತಿಹಾಸ (2018-2019)21

• 44,8%ಏಕಶಿಲೆಯ ಸಂಪೂರ್ಣ ಗರಗಸ ಮತ್ತು ವಾಸ್ತುಶಿಲ್ಪದ ಸ್ಥಿರೀಕರಣ26

• 29,3%ವ್ಯವಸ್ಥೆಯ ಅಭಿವೃದ್ಧಿಗೆ ಹೆಚ್ಚಿನ ಯೋಜನೆಗಳ ಬಗ್ಗೆ 17

• 19,0%ನಾನು Dodo IS11 ಬಗ್ಗೆ ಏನನ್ನೂ ತಿಳಿದುಕೊಳ್ಳಲು ಬಯಸುವುದಿಲ್ಲ

58 ಬಳಕೆದಾರರು ಮತ ಹಾಕಿದ್ದಾರೆ. 6 ಬಳಕೆದಾರರು ದೂರ ಉಳಿದಿದ್ದಾರೆ.

ಮೂಲ: www.habr.com