ಡೋಡೋ IS ವಾಸ್ತುಶಿಲ್ಪದ ಇತಿಹಾಸ: ಆರಂಭಿಕ ಏಕಶಿಲೆ

ಅಥವಾ ಏಕಶಿಲೆಯೊಂದಿಗೆ ಪ್ರತಿ ಅತೃಪ್ತ ಕಂಪನಿಯು ತನ್ನದೇ ಆದ ರೀತಿಯಲ್ಲಿ ಅತೃಪ್ತಿ ಹೊಂದಿದೆ.

ಡೋಡೋ ಪಿಜ್ಜಾ ವ್ಯವಹಾರದಂತೆ - 2011 ರಲ್ಲಿ ಡೋಡೋ ಐಎಸ್ ವ್ಯವಸ್ಥೆಯ ಅಭಿವೃದ್ಧಿಯು ತಕ್ಷಣವೇ ಪ್ರಾರಂಭವಾಯಿತು. ಇದು ವ್ಯವಹಾರ ಪ್ರಕ್ರಿಯೆಗಳ ಸಂಪೂರ್ಣ ಮತ್ತು ಸಂಪೂರ್ಣ ಡಿಜಿಟಲೀಕರಣದ ಕಲ್ಪನೆಯನ್ನು ಆಧರಿಸಿದೆ, ಮತ್ತು ತಮ್ಮದೇ ಆದ ಮೇಲೆ, ಇದು 2011 ರಲ್ಲಿ ಅನೇಕ ಪ್ರಶ್ನೆಗಳನ್ನು ಮತ್ತು ಸಂದೇಹಗಳನ್ನು ಹುಟ್ಟುಹಾಕಿತು. ಆದರೆ ಈಗ 9 ವರ್ಷಗಳಿಂದ ನಾವು ಈ ಮಾರ್ಗವನ್ನು ಅನುಸರಿಸುತ್ತಿದ್ದೇವೆ - ನಮ್ಮದೇ ಆದ ಅಭಿವೃದ್ಧಿಯೊಂದಿಗೆ, ಇದು ಏಕಶಿಲೆಯಿಂದ ಪ್ರಾರಂಭವಾಯಿತು.

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

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

1. ಡೋಡೋ IS ನಲ್ಲಿ ಆರಂಭಿಕ ಏಕಶಿಲೆ (2011-2015). (ನೀವು ಇಲ್ಲಿದ್ದೀರಿ)

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

3. ಕ್ಲೈಂಟ್ ಸೈಡ್ ಪಾತ್: ಬೇಸ್ ಮೇಲೆ ಮುಂಭಾಗ (2016-2017). (ಪ್ರಗತಿಯಲ್ಲಿದೆ...)

4. ನೈಜ ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ನ ಇತಿಹಾಸ. (2018-2019). (ಪ್ರಗತಿಯಲ್ಲಿದೆ...)

5. ಏಕಶಿಲೆಯ ಗರಗಸ ಮತ್ತು ವಾಸ್ತುಶಿಲ್ಪದ ಸ್ಥಿರೀಕರಣವನ್ನು ಪೂರ್ಣಗೊಳಿಸಲಾಗಿದೆ. (ಪ್ರಗತಿಯಲ್ಲಿದೆ...)

ಮೂಲ ವಾಸ್ತುಶಿಲ್ಪ

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

ಆರ್ಕಿಟೆಕ್ಚರ್‌ನಲ್ಲಿನ ಮೊದಲ ಮಾಡ್ಯೂಲ್ ಆದೇಶ ಸ್ವೀಕಾರವಾಗಿದೆ. ವ್ಯವಹಾರ ಪ್ರಕ್ರಿಯೆಯು ಹೀಗಿತ್ತು:

• ಗ್ರಾಹಕರು ಪಿಜ್ಜೇರಿಯಾವನ್ನು ಕರೆಯುತ್ತಾರೆ;

• ಮ್ಯಾನೇಜರ್ ಫೋನ್ ಎತ್ತಿಕೊಳ್ಳುತ್ತಾನೆ;

• ಫೋನ್ ಮೂಲಕ ಆದೇಶಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ;

• ಅದೇ ಸಮಯದಲ್ಲಿ, ಇದು ಆರ್ಡರ್ ಸ್ವೀಕಾರ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಅದನ್ನು ತುಂಬುತ್ತದೆ: ಕ್ಲೈಂಟ್ ಬಗ್ಗೆ ಮಾಹಿತಿ, ಆರ್ಡರ್ ವಿವರಗಳ ಡೇಟಾ ಮತ್ತು ವಿತರಣಾ ವಿಳಾಸವನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಲಾಗುತ್ತದೆ. 

ಮಾಹಿತಿ ವ್ಯವಸ್ಥೆಯ ಇಂಟರ್ಫೇಸ್ ಈ ರೀತಿ ಕಾಣುತ್ತದೆ...

ಅಕ್ಟೋಬರ್ 2011 ರಿಂದ ಮೊದಲ ಆವೃತ್ತಿ:

2012ರ ಜನವರಿಯಲ್ಲಿ ಸ್ವಲ್ಪ ಸುಧಾರಿಸಿದೆ

ಮಾಹಿತಿ ವ್ಯವಸ್ಥೆ ಡೋಡೋ ಪಿಜ್ಜಾ ಡೆಲಿವರಿ ಪಿಜ್ಜಾ ರೆಸ್ಟೋರೆಂಟ್

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

ಅವರ ಮೊದಲ ನಿರ್ಧಾರವು ತಂತ್ರಜ್ಞಾನದ ರಾಶಿಯ ಭವಿಷ್ಯದ ಭವಿಷ್ಯವನ್ನು ನಿರ್ಧರಿಸಿತು:

• ASP.NET MVC, C# ಭಾಷೆಯಲ್ಲಿ ಬ್ಯಾಕೆಂಡ್. ಡೆವಲಪರ್‌ಗಳು ಡಾಟ್‌ನೆಟ್ಟರ್‌ಗಳು; ಈ ಸ್ಟಾಕ್ ಅವರಿಗೆ ಪರಿಚಿತ ಮತ್ತು ಆಹ್ಲಾದಕರವಾಗಿತ್ತು.

• ಬೂಟ್‌ಸ್ಟ್ರ್ಯಾಪ್ ಮತ್ತು JQuery ನಲ್ಲಿ ಮುಂಭಾಗ: ಕಸ್ಟಮ್ ಶೈಲಿಗಳು ಮತ್ತು ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳ ಆಧಾರದ ಮೇಲೆ ಬಳಕೆದಾರ ಇಂಟರ್ಫೇಸ್‌ಗಳು. 

• MySQL ಡೇಟಾಬೇಸ್: ಯಾವುದೇ ಪರವಾನಗಿ ವೆಚ್ಚಗಳಿಲ್ಲ, ಬಳಸಲು ಸುಲಭ.

• ವಿಂಡೋಸ್ ಸರ್ವರ್‌ನಲ್ಲಿ ಸರ್ವರ್‌ಗಳು, ಏಕೆಂದರೆ .NET ಆಗ ವಿಂಡೋಸ್‌ನಲ್ಲಿ ಮಾತ್ರ ಇರಬಹುದಾಗಿತ್ತು (ನಾವು ಮೊನೊವನ್ನು ಚರ್ಚಿಸುವುದಿಲ್ಲ).

ಭೌತಿಕವಾಗಿ, ಇದೆಲ್ಲವನ್ನೂ "ಹೋಸ್ಟರ್ ಡೆಸ್ಕ್" ನಲ್ಲಿ ವ್ಯಕ್ತಪಡಿಸಲಾಗಿದೆ. 

ಆರ್ಡರ್ ಸ್ವೀಕಾರ ಅರ್ಜಿಯ ಆರ್ಕಿಟೆಕ್ಚರ್

ಆ ಸಮಯದಲ್ಲಿ, ಎಲ್ಲರೂ ಈಗಾಗಲೇ ಮೈಕ್ರೋಸರ್ವಿಸ್ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದರು, ಮತ್ತು SOA ಅನ್ನು ಸುಮಾರು 5 ವರ್ಷಗಳವರೆಗೆ ದೊಡ್ಡ ಯೋಜನೆಗಳಲ್ಲಿ ಬಳಸಲಾಗುತ್ತಿತ್ತು, ಉದಾಹರಣೆಗೆ, WCF ಅನ್ನು 2006 ರಲ್ಲಿ ಬಿಡುಗಡೆ ಮಾಡಲಾಯಿತು. ಆದರೆ ನಂತರ ಅವರು ವಿಶ್ವಾಸಾರ್ಹ ಮತ್ತು ಸಾಬೀತಾದ ಪರಿಹಾರವನ್ನು ಆಯ್ಕೆ ಮಾಡಿದರು.

ಇಲ್ಲಿದೆ.

Asp.Net MVC ರೇಜರ್ ಆಗಿದೆ, ಇದು ಫಾರ್ಮ್‌ನಿಂದ ಅಥವಾ ಕ್ಲೈಂಟ್‌ನಿಂದ ಕೋರಿಕೆಯ ಮೇರೆಗೆ ಸರ್ವರ್‌ನಲ್ಲಿ ರೆಂಡರಿಂಗ್‌ನೊಂದಿಗೆ HTML ಪುಟವನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ, CSS ಮತ್ತು JS ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ಈಗಾಗಲೇ ಮಾಹಿತಿಯನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತವೆ ಮತ್ತು ಅಗತ್ಯವಿದ್ದರೆ, JQuery ಮೂಲಕ AJAX ವಿನಂತಿಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತವೆ.

ಸರ್ವರ್‌ನಲ್ಲಿನ ವಿನಂತಿಗಳು *ನಿಯಂತ್ರಕ ವರ್ಗಗಳಿಗೆ ಸೇರುತ್ತವೆ, ಅಲ್ಲಿ ವಿಧಾನವು ಅಂತಿಮ HTML ಪುಟವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಉತ್ಪಾದಿಸುತ್ತದೆ. ನಿಯಂತ್ರಕರು *ಸೇವೆಗಳು ಎಂಬ ತರ್ಕದ ಪದರಕ್ಕೆ ವಿನಂತಿಗಳನ್ನು ಮಾಡುತ್ತಾರೆ. ಪ್ರತಿಯೊಂದು ಸೇವೆಗಳು ವ್ಯವಹಾರದ ಕೆಲವು ಅಂಶಗಳಿಗೆ ಅನುಗುಣವಾಗಿರುತ್ತವೆ:

• ಉದಾಹರಣೆಗೆ, ಡಿಪಾರ್ಟ್ಮೆಂಟ್ ಸ್ಟ್ರಕ್ಚರ್ ಸರ್ವೀಸ್ ಪಿಜ್ಜೇರಿಯಾಗಳು ಮತ್ತು ಇಲಾಖೆಗಳ ಮಾಹಿತಿಯನ್ನು ಒದಗಿಸಿದೆ. ವಿಭಾಗವು ಒಬ್ಬ ಫ್ರಾಂಚೈಸಿಯಿಂದ ನಿರ್ವಹಿಸಲ್ಪಡುವ ಪಿಜ್ಜೇರಿಯಾಗಳ ಗುಂಪಾಗಿದೆ.

• ರಿಸೀವಿಂಗ್ ಆರ್ಡರ್ಸ್ ಸರ್ವೀಸ್ ಆರ್ಡರ್‌ನ ವಿಷಯಗಳನ್ನು ಸ್ವೀಕರಿಸಿದೆ ಮತ್ತು ಲೆಕ್ಕಾಚಾರ ಮಾಡಿದೆ.

• ಮತ್ತು SmsService SMS ಕಳುಹಿಸಲು API ಸೇವೆಗಳಿಗೆ ಕರೆ ಮಾಡುವ ಮೂಲಕ SMS ಕಳುಹಿಸಲಾಗಿದೆ.

ಸೇವೆಗಳು ಡೇಟಾಬೇಸ್‌ನಿಂದ ಡೇಟಾವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತವೆ ಮತ್ತು ವ್ಯಾಪಾರ ತರ್ಕವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತವೆ. ಪ್ರತಿಯೊಂದು ಸೇವೆಯು ಸೂಕ್ತವಾದ ಹೆಸರಿನೊಂದಿಗೆ ಒಂದು ಅಥವಾ ಹೆಚ್ಚಿನ *ರೆಪೊಸಿಟರಿಗಳನ್ನು ಹೊಂದಿತ್ತು. ಅವು ಈಗಾಗಲೇ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಸಂಗ್ರಹವಾಗಿರುವ ಕಾರ್ಯವಿಧಾನಗಳಿಗೆ ಪ್ರಶ್ನೆಗಳನ್ನು ಮತ್ತು ಮ್ಯಾಪರ್‌ಗಳ ಪದರವನ್ನು ಒಳಗೊಂಡಿವೆ. ಸ್ಟೋರೇಜ್‌ಗಳಲ್ಲಿ, ವಿಶೇಷವಾಗಿ ವರದಿ ಮಾಡುವ ಡೇಟಾವನ್ನು ಉತ್ಪಾದಿಸುವ ವ್ಯಾಪಾರದ ತರ್ಕವಿದೆ. ORM ಅನ್ನು ಬಳಸಲಾಗಿಲ್ಲ, ಪ್ರತಿಯೊಬ್ಬರೂ ಕೈಯಿಂದ ಬರೆಯುವ sql ಅನ್ನು ಅವಲಂಬಿಸಿದ್ದಾರೆ. 

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

ಇದೆಲ್ಲವನ್ನೂ ಈ ಮಾದರಿಯಿಂದ ಪ್ರತಿನಿಧಿಸಬಹುದು:

ಆರ್ಡರ್ ರೀತಿಯಲ್ಲಿ

ಅಂತಹ ಆದೇಶವನ್ನು ರಚಿಸಲು ಸರಳೀಕೃತ ಆರಂಭಿಕ ಮಾರ್ಗವನ್ನು ಪರಿಗಣಿಸೋಣ.

ಆರಂಭದಲ್ಲಿ ಸೈಟ್ ಸ್ಥಿರವಾಗಿತ್ತು. ಅದರ ಮೇಲೆ ಬೆಲೆಗಳು ಇದ್ದವು, ಮತ್ತು ಮೇಲ್ಭಾಗದಲ್ಲಿ ಫೋನ್ ಸಂಖ್ಯೆ ಮತ್ತು "ನಿಮಗೆ ಪಿಜ್ಜಾ ಬೇಕಾದರೆ, ಸಂಖ್ಯೆಗೆ ಕರೆ ಮಾಡಿ ಮತ್ತು ಆರ್ಡರ್ ಮಾಡಿ" ಎಂಬ ಶಾಸನವಿತ್ತು. ಆದೇಶಿಸಲು, ನಾವು ಸರಳ ಹರಿವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕಾಗಿದೆ: 

• ಕ್ಲೈಂಟ್ ಬೆಲೆಗಳೊಂದಿಗೆ ಸ್ಥಿರ ವೆಬ್‌ಸೈಟ್‌ಗೆ ಹೋಗುತ್ತದೆ, ಉತ್ಪನ್ನಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ವೆಬ್‌ಸೈಟ್‌ನಲ್ಲಿ ಪಟ್ಟಿ ಮಾಡಲಾದ ಸಂಖ್ಯೆಗೆ ಕರೆ ಮಾಡುತ್ತದೆ.

• ಗ್ರಾಹಕರು ಅವರು ಆರ್ಡರ್‌ಗೆ ಸೇರಿಸಲು ಬಯಸುವ ಉತ್ಪನ್ನಗಳನ್ನು ಹೆಸರಿಸುತ್ತಾರೆ.

• ಅವನ ವಿಳಾಸ ಮತ್ತು ಹೆಸರನ್ನು ನೀಡುತ್ತದೆ.

• ಆಪರೇಟರ್ ಆದೇಶವನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾರೆ.

• ಸ್ವೀಕರಿಸಿದ ಆದೇಶಗಳ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಆದೇಶವನ್ನು ಪ್ರದರ್ಶಿಸಲಾಗುತ್ತದೆ.

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

ಕ್ಲೈಂಟ್ ಉತ್ಪನ್ನವನ್ನು ಹೆಸರಿಸುತ್ತಾನೆ, ಆಪರೇಟರ್ ಕ್ಲಿಕ್ ಮಾಡುತ್ತಾನೆ + ಉತ್ಪನ್ನದ ಪಕ್ಕದಲ್ಲಿ, ಮತ್ತು ವಿನಂತಿಯನ್ನು ಸರ್ವರ್‌ಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ. ಉತ್ಪನ್ನದ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಡೇಟಾಬೇಸ್‌ನಿಂದ ಹೊರತೆಗೆಯಲಾಗುತ್ತದೆ ಮತ್ತು ಉತ್ಪನ್ನದ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಕಾರ್ಟ್‌ಗೆ ಸೇರಿಸಲಾಗುತ್ತದೆ.

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

ಮುಂದೆ, ಕ್ಲೈಂಟ್ನ ವಿಳಾಸ ಮತ್ತು ಹೆಸರನ್ನು ನಮೂದಿಸಿ. 

ನೀವು "ಆದೇಶವನ್ನು ರಚಿಸಿ" ಕ್ಲಿಕ್ ಮಾಡಿದಾಗ:

• ನಾವು ವಿನಂತಿಯನ್ನು OrderController.SaveOrder() ಗೆ ಕಳುಹಿಸುತ್ತೇವೆ.

• ನಾವು ಅಧಿವೇಶನದಿಂದ ಕಾರ್ಟ್ ಅನ್ನು ಪಡೆಯುತ್ತೇವೆ, ನಮಗೆ ಅಗತ್ಯವಿರುವ ಪ್ರಮಾಣದಲ್ಲಿ ಉತ್ಪನ್ನಗಳಿವೆ.

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

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

• ಆರ್ಡರ್ ಡಿಸ್ಪ್ಲೇ ಇಂಟರ್ಫೇಸ್ ಹೋಗುತ್ತದೆ ಮತ್ತು ಇತ್ತೀಚಿನ ಆದೇಶಗಳನ್ನು ಹೊರತೆಗೆಯುತ್ತದೆ ಮತ್ತು ಅವುಗಳನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತದೆ.

ಹೊಸ ಮಾಡ್ಯೂಲ್‌ಗಳು

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

ಮಾಡ್ಯೂಲ್ ಎನ್ನುವುದು ಕೆಲವು ಸಾಮಾನ್ಯ ವ್ಯವಹಾರ ಗುರಿಯಿಂದ ಒಂದಾಗಿರುವ ಕಾರ್ಯಗಳ ಒಂದು ಗುಂಪಾಗಿದೆ. ಇದಲ್ಲದೆ, ಅವರು ಭೌತಿಕವಾಗಿ ಅದೇ ಅಪ್ಲಿಕೇಶನ್ನಲ್ಲಿ ನೆಲೆಗೊಂಡಿದ್ದಾರೆ.

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

ತಾಂತ್ರಿಕವಾಗಿ, ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಪ್ರದೇಶವಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ (ಈ ಕಲ್ಪನೆಯು ಸಹ ಉಳಿದಿದೆ asp.net ಕೋರ್) ಮುಂಭಾಗ, ಮಾದರಿಗಳು ಮತ್ತು ತಮ್ಮದೇ ಆದ ನಿಯಂತ್ರಕ ವರ್ಗಗಳಿಗೆ ಪ್ರತ್ಯೇಕ ಫೈಲ್‌ಗಳು ಇದ್ದವು. ಪರಿಣಾಮವಾಗಿ, ವ್ಯವಸ್ಥೆಯು ಅಂತಹ...

...ಇದಕ್ಕಾಗಿ:

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

• ಸೈಟ್ - ಮೊದಲ ಆವೃತ್ತಿ ವೆಬ್ಸೈಟ್ dodopizza.ru.

• ರಫ್ತು: 1C ಗಾಗಿ Dodo IS ನಿಂದ ವರದಿಗಳನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಲಾಗುತ್ತಿದೆ. 

• ವೈಯಕ್ತಿಕ - ಉದ್ಯೋಗಿಯ ವೈಯಕ್ತಿಕ ಖಾತೆ. ಇದನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗಿದೆ ಮತ್ತು ತನ್ನದೇ ಆದ ಪ್ರವೇಶ ಬಿಂದು ಮತ್ತು ಪ್ರತ್ಯೇಕ ವಿನ್ಯಾಸವನ್ನು ಹೊಂದಿದೆ.

• fs - ಸ್ಥಿರ ಹೋಸ್ಟಿಂಗ್ ಯೋಜನೆ. ನಂತರ ನಾವು ಅದರಿಂದ ದೂರ ಸರಿದಿದ್ದೇವೆ, ಎಲ್ಲಾ ಸ್ಥಿರ ವಿಷಯವನ್ನು Akamai CDN ಗೆ ಸರಿಸಿದ್ದೇವೆ. 

ಉಳಿದ ಬ್ಲಾಕ್‌ಗಳು ಬ್ಯಾಕ್ ಆಫೀಸ್ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿವೆ. 

ಹೆಸರುಗಳ ವಿವರಣೆ:

• ಕ್ಯಾಷಿಯರ್ - ರೆಸ್ಟೋರೆಂಟ್ ನಗದು ರಿಜಿಸ್ಟರ್.

• ಶಿಫ್ಟ್ ಮ್ಯಾನೇಜರ್ - "ಶಿಫ್ಟ್ ಮ್ಯಾನೇಜರ್" ಪಾತ್ರಕ್ಕಾಗಿ ಇಂಟರ್ಫೇಸ್‌ಗಳು: ಪಿಜ್ಜೇರಿಯಾ ಮಾರಾಟದ ಕಾರ್ಯಾಚರಣೆಯ ಅಂಕಿಅಂಶಗಳು, ಉತ್ಪನ್ನಗಳನ್ನು ಸ್ಟಾಪ್ ಪಟ್ಟಿಯಲ್ಲಿ ಇರಿಸುವ ಸಾಮರ್ಥ್ಯ, ಆದೇಶವನ್ನು ಬದಲಾಯಿಸಿ.

• ಆಫೀಸ್ ಮ್ಯಾನೇಜರ್ - "ಪಿಜ್ಜೇರಿಯಾ ಮ್ಯಾನೇಜರ್" ಮತ್ತು "ಫ್ರಾಂಚೈಸಿ" ಪಾತ್ರಗಳಿಗಾಗಿ ಇಂಟರ್ಫೇಸ್. ಇಲ್ಲಿ ನೀವು ಪಿಜ್ಜೇರಿಯಾವನ್ನು ಹೊಂದಿಸಲು ಕಾರ್ಯಗಳನ್ನು ಕಾಣಬಹುದು, ಅದರ ಬೋನಸ್ ಪ್ರಚಾರಗಳು, ಉದ್ಯೋಗಿಗಳೊಂದಿಗೆ ಸ್ವೀಕರಿಸುವುದು ಮತ್ತು ಕೆಲಸ ಮಾಡುವುದು ಮತ್ತು ವರದಿಗಳು.

• ಪಬ್ಲಿಕ್‌ಸ್ಕ್ರೀನ್‌ಗಳು - ಪಿಜ್ಜೇರಿಯಾಗಳಲ್ಲಿ ನೇತಾಡುವ ಟಿವಿಗಳು ಮತ್ತು ಟ್ಯಾಬ್ಲೆಟ್‌ಗಳಿಗಾಗಿ ಇಂಟರ್‌ಫೇಸ್‌ಗಳು. ಟಿವಿಗಳು ವಿತರಣೆಯ ನಂತರ ಮೆನು, ಜಾಹೀರಾತು ಮಾಹಿತಿ ಮತ್ತು ಆರ್ಡರ್ ಸ್ಥಿತಿಯನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತವೆ. 

ಅವರು ಸಾಮಾನ್ಯ ಸೇವಾ ಪದರ, Dodo.Core ಡೊಮೇನ್ ವರ್ಗಗಳ ಸಾಮಾನ್ಯ ಬ್ಲಾಕ್ ಮತ್ತು ಸಾಮಾನ್ಯ ನೆಲೆಯನ್ನು ಬಳಸಿದರು. ಕೆಲವೊಮ್ಮೆ ಅವರು ಇನ್ನೂ ಪರಸ್ಪರ ಮಾರ್ಗಗಳ ಮೂಲಕ ಕಾರಣವಾಗಬಹುದು. ಹೆಚ್ಚುವರಿಯಾಗಿ, dodopizza.ru ಅಥವಾ personal.dodopizza.ru ನಂತಹ ವೈಯಕ್ತಿಕ ಸೈಟ್‌ಗಳು ಸಹ ಸಾಮಾನ್ಯ ಸೇವೆಗಳನ್ನು ಪ್ರವೇಶಿಸುತ್ತವೆ.

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

ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಮಾಡ್ಯೂಲ್‌ಗಳ ಪ್ರಮಾಣವನ್ನು ಉತ್ತಮವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ಅಭಿವೃದ್ಧಿ ಯೋಜನೆಗಳೊಂದಿಗೆ 2012 ರ ರೇಖಾಚಿತ್ರ ಇಲ್ಲಿದೆ:

2015 ರ ಹೊತ್ತಿಗೆ, ಎಲ್ಲವೂ ಟ್ರ್ಯಾಕ್‌ನಲ್ಲಿತ್ತು ಮತ್ತು ಇನ್ನೂ ಹೆಚ್ಚಿನವು ಉತ್ಪಾದನೆಯಲ್ಲಿತ್ತು.

• ಆದೇಶ ಸ್ವೀಕಾರವು ಸಂಪರ್ಕ ಕೇಂದ್ರದ ಪ್ರತ್ಯೇಕ ಬ್ಲಾಕ್ ಆಗಿ ಬೆಳೆದಿದೆ, ಅಲ್ಲಿ ಆದೇಶವನ್ನು ಆಪರೇಟರ್ ಸ್ವೀಕರಿಸುತ್ತಾರೆ.

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

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

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

ಸಮಾನಾಂತರವಾಗಿ, 2012 ರಿಂದ 2015 ರವರೆಗೆ, 10 ಕ್ಕೂ ಹೆಚ್ಚು ಡೆವಲಪರ್‌ಗಳು ಕಾಣಿಸಿಕೊಂಡರು, 35 ಪಿಜ್ಜೇರಿಯಾಗಳನ್ನು ತೆರೆಯಲಾಯಿತು, ವ್ಯವಸ್ಥೆಯನ್ನು ರೊಮೇನಿಯಾಕ್ಕೆ ನಿಯೋಜಿಸಲಾಯಿತು ಮತ್ತು ಯುಎಸ್‌ಎಯಲ್ಲಿ ಪಾಯಿಂಟ್‌ಗಳನ್ನು ತೆರೆಯಲು ಸಿದ್ಧಪಡಿಸಲಾಯಿತು. ಡೆವಲಪರ್‌ಗಳು ಇನ್ನು ಮುಂದೆ ಎಲ್ಲಾ ಕಾರ್ಯಗಳಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಿಲ್ಲ, ಆದರೆ ತಂಡಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ. ಪ್ರತಿಯೊಂದು ವ್ಯವಸ್ಥೆಯು ತನ್ನದೇ ಆದ ಭಾಗದಲ್ಲಿ ಪರಿಣತಿಯನ್ನು ಹೊಂದಿದೆ. 

ತೊಂದರೆಗಳು

ವಾಸ್ತುಶಿಲ್ಪದ ಕಾರಣ ಸೇರಿದಂತೆ (ಆದರೆ ಮಾತ್ರವಲ್ಲ).

ತಳದಲ್ಲಿ ಅವ್ಯವಸ್ಥೆ

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

ಆದರೆ 4 ವರ್ಷಗಳ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ, ಡೇಟಾಬೇಸ್ ಸುಮಾರು 600 ಕೋಷ್ಟಕಗಳು, 1500 ಸಂಗ್ರಹಿಸಲಾದ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಒಳಗೊಂಡಿದೆ, ಅವುಗಳಲ್ಲಿ ಹಲವು ತರ್ಕವನ್ನು ಸಹ ಹೊಂದಿವೆ. ದುರದೃಷ್ಟವಶಾತ್, MySQL ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ ಸಂಗ್ರಹಿಸಲಾದ ಕಾರ್ಯವಿಧಾನಗಳು ಹೆಚ್ಚಿನ ಪ್ರಯೋಜನವನ್ನು ಒದಗಿಸುವುದಿಲ್ಲ. ಡೇಟಾಬೇಸ್‌ನಿಂದ ಅವುಗಳನ್ನು ಸಂಗ್ರಹಿಸಲಾಗಿಲ್ಲ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ತರ್ಕವನ್ನು ಸಂಗ್ರಹಿಸುವುದು ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಡೀಬಗ್ ಮಾಡುವಿಕೆಯನ್ನು ಸಂಕೀರ್ಣಗೊಳಿಸುತ್ತದೆ. ಕೋಡ್ ಅನ್ನು ಮರುಬಳಕೆ ಮಾಡುವುದು ಸಹ ಕಷ್ಟ.

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

ಕೋಷ್ಟಕಗಳಲ್ಲಿನ ಡೇಟಾ ಯಾವಾಗಲೂ ಹೆಚ್ಚು ಸೂಕ್ತವಾದ ರೂಪದಲ್ಲಿರುವುದಿಲ್ಲ. ಎಲ್ಲೋ ಡಿನಾರ್ಮಲೈಸೇಶನ್ ಮಾಡುವುದು ಅಗತ್ಯವಾಗಿತ್ತು. ನಿಯಮಿತವಾಗಿ ಸ್ವೀಕರಿಸಿದ ಕೆಲವು ಡೇಟಾವು XML ರಚನೆಯ ರೂಪದಲ್ಲಿ ಒಂದು ಕಾಲಮ್‌ನಲ್ಲಿದೆ, ಇದು ಮರಣದಂಡನೆಯ ಸಮಯವನ್ನು ಹೆಚ್ಚಿಸಿತು, ದೀರ್ಘವಾದ ಪ್ರಶ್ನೆಗಳು ಮತ್ತು ಸಂಕೀರ್ಣ ಅಭಿವೃದ್ಧಿ.

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

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

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

ಸಂಹಿತೆಯಲ್ಲಿ ಒಗ್ಗಟ್ಟು ಮತ್ತು ಗೊಂದಲ

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

ಸೇವೆಗಳು (ಒಂದು ಏಕಶಿಲೆಯ ದೊಡ್ಡ ಯೋಜನೆಯೊಳಗಿನ ತರಗತಿಗಳು) ತಮ್ಮ ಡೇಟಾವನ್ನು ಉತ್ಕೃಷ್ಟಗೊಳಿಸಲು ಪರಸ್ಪರ ಕರೆ ಮಾಡಬಹುದು.

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

ತರ್ಕವು ನಿಯಂತ್ರಕಗಳಲ್ಲಿ ಅಥವಾ ಸೇವಾ ತರಗತಿಗಳಲ್ಲಿದೆ. 

ಇವುಗಳು ಸಣ್ಣ ಸಮಸ್ಯೆಗಳಂತೆ ತೋರುತ್ತದೆ, ಆದರೆ ಅವು ಅಭಿವೃದ್ಧಿಯನ್ನು ಬಹಳವಾಗಿ ನಿಧಾನಗೊಳಿಸಿದವು ಮತ್ತು ಗುಣಮಟ್ಟವನ್ನು ಕಡಿಮೆಗೊಳಿಸಿದವು, ಅಸ್ಥಿರತೆ ಮತ್ತು ದೋಷಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತವೆ. 

ದೊಡ್ಡ ಅಭಿವೃದ್ಧಿಯ ಸಂಕೀರ್ಣತೆ

ಅಭಿವೃದ್ಧಿಯಲ್ಲಿಯೇ ತೊಂದರೆಗಳು ಉದ್ಭವಿಸಿದವು. ಸಿಸ್ಟಮ್ನ ವಿಭಿನ್ನ ಬ್ಲಾಕ್ಗಳನ್ನು ಮತ್ತು ಸಮಾನಾಂತರವಾಗಿ ರಚಿಸುವುದು ಅಗತ್ಯವಾಗಿತ್ತು. ಪ್ರತಿಯೊಂದು ಘಟಕದ ಅಗತ್ಯಗಳನ್ನು ಒಂದೇ ಕೋಡ್‌ಗೆ ಹೊಂದಿಸುವುದು ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಯಿತು. ಎಲ್ಲಾ ಘಟಕಗಳನ್ನು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಒಪ್ಪಿಕೊಳ್ಳುವುದು ಮತ್ತು ದಯವಿಟ್ಟು ಮೆಚ್ಚಿಸುವುದು ಸುಲಭವಲ್ಲ. ಇದಕ್ಕೆ ತಂತ್ರಜ್ಞಾನದಲ್ಲಿನ ಮಿತಿಗಳನ್ನು ಸೇರಿಸಲಾಗಿದೆ, ವಿಶೇಷವಾಗಿ ಬೇಸ್ ಮತ್ತು ಮುಂಭಾಗಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತೆ. ಉನ್ನತ ಮಟ್ಟದ ಚೌಕಟ್ಟುಗಳ ಪರವಾಗಿ, ವಿಶೇಷವಾಗಿ ಕ್ಲೈಂಟ್ ಸೇವೆಗಳ (ವೆಬ್‌ಸೈಟ್) ಪರವಾಗಿ JQuery ಅನ್ನು ತ್ಯಜಿಸುವುದು ಅಗತ್ಯವಾಗಿತ್ತು.

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

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

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

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

ಬ್ಲಾಗ್ ಪವರ್ ಆಫ್ ಮೈಂಡ್ ರೆಸ್ಟೋರೆಂಟ್‌ಗಳಲ್ಲಿ ನಗದು ರೆಜಿಸ್ಟರ್‌ಗಳನ್ನು ಹೇಗೆ ಹಾಕುತ್ತದೆ

ಪಿಜ್ಜೇರಿಯಾ ನೆಟ್ವರ್ಕ್ (ಮತ್ತು ಲೋಡ್) ಬೆಳವಣಿಗೆಯು ಅದೇ ವೇಗದಲ್ಲಿ ಮುಂದುವರಿದರೆ, ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ ಹನಿಗಳು ಸಿಸ್ಟಮ್ ಚೇತರಿಸಿಕೊಳ್ಳುವುದಿಲ್ಲ. ಕೆಳಗಿನ ಕಥೆಯು 2015 ರ ಹೊತ್ತಿಗೆ ನಾವು ಎದುರಿಸಲು ಪ್ರಾರಂಭಿಸಿದ ಸಮಸ್ಯೆಗಳನ್ನು ಚೆನ್ನಾಗಿ ವಿವರಿಸುತ್ತದೆ. 

ಬ್ಲಾಗ್ ನಲ್ಲಿ "ಮನಸ್ಸಿನ ಶಕ್ತಿ"ಇಡೀ ನೆಟ್‌ವರ್ಕ್‌ಗಾಗಿ ವರ್ಷದ ಆದಾಯದ ಡೇಟಾವನ್ನು ತೋರಿಸುವ ವಿಜೆಟ್ ಇತ್ತು. ಈ ಡೇಟಾವನ್ನು ಒದಗಿಸುವ ಸಾರ್ವಜನಿಕ ಡೋಡೋ API ಅನ್ನು ವಿಜೆಟ್ ಪ್ರವೇಶಿಸಿದೆ. ಈ ಅಂಕಿಅಂಶಗಳು ಈಗ ಲಭ್ಯವಿವೆ http://dodopizzastory.com/. ವಿಜೆಟ್ ಅನ್ನು ಪ್ರತಿ ಪುಟದಲ್ಲಿ ತೋರಿಸಲಾಗಿದೆ ಮತ್ತು ಪ್ರತಿ 20 ಸೆಕೆಂಡುಗಳಿಗೊಮ್ಮೆ ಟೈಮರ್‌ನಲ್ಲಿ ವಿನಂತಿಗಳನ್ನು ಮಾಡಲಾಗಿದೆ. ವಿನಂತಿಯು api.dodopizza.ru ಗೆ ಹೋಗಿ ಕೇಳಿದೆ:

• ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಪಿಜ್ಜೇರಿಯಾಗಳ ಸಂಖ್ಯೆ;

• ವರ್ಷದ ಆರಂಭದಿಂದ ಒಟ್ಟು ನೆಟ್ವರ್ಕ್ ಆದಾಯ;

• ಇಂದಿನ ಆದಾಯ.

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

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

ರೇಖಾಚಿತ್ರವು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

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

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

ಇದೊಂದೇ ಕಥೆಯಲ್ಲ. 2015 ರ ಶರತ್ಕಾಲದಲ್ಲಿ, ಪ್ರತಿ ಶುಕ್ರವಾರ ಸಿಸ್ಟಂನಲ್ಲಿನ ಹೊರೆ ನಿರ್ಣಾಯಕವಾಗಿತ್ತು. ಹಲವಾರು ಬಾರಿ ನಾವು ಸಾರ್ವಜನಿಕ API ಅನ್ನು ಆಫ್ ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ಒಮ್ಮೆ ನಾವು ಸೈಟ್ ಅನ್ನು ಆಫ್ ಮಾಡಬೇಕಾಗಿತ್ತು ಏಕೆಂದರೆ ಏನೂ ಸಹಾಯ ಮಾಡಲಿಲ್ಲ. ಭಾರೀ ಹೊರೆಗಳ ಅಡಿಯಲ್ಲಿ ಸ್ಥಗಿತಗೊಳಿಸುವ ಆದೇಶದೊಂದಿಗೆ ಸೇವೆಗಳ ಪಟ್ಟಿ ಕೂಡ ಇತ್ತು.

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

ತ್ವರಿತ ವ್ಯಾಪಾರ ಬೆಳವಣಿಗೆ

ಅದನ್ನು "ಈಗಿನಿಂದಲೇ ಚೆನ್ನಾಗಿ ಮಾಡಲು" ಏಕೆ ಸಾಧ್ಯವಾಗಲಿಲ್ಲ? ಈ ಕೆಳಗಿನ ಗ್ರಾಫ್‌ಗಳನ್ನು ನೋಡಿ.

2014-2015ರಲ್ಲಿ ರೊಮೇನಿಯಾದಲ್ಲಿ ಉದ್ಘಾಟನೆ ನಡೆದಿತ್ತು ಮತ್ತು USA ಯಲ್ಲಿ ಉದ್ಘಾಟನೆಯನ್ನು ಸಿದ್ಧಪಡಿಸಲಾಗುತ್ತಿದೆ.

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

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

ಸಹಾಯ ಮಾಡಿದ ತ್ವರಿತ ಪರಿಹಾರಗಳು

ಸಮಸ್ಯೆಗಳಿಗೆ ಪರಿಹಾರದ ಅಗತ್ಯವಿದೆ. ಸಾಂಪ್ರದಾಯಿಕವಾಗಿ, ಪರಿಹಾರಗಳನ್ನು 2 ಗುಂಪುಗಳಾಗಿ ವಿಂಗಡಿಸಬಹುದು:

• ವೇಗವಾದವುಗಳು ಬೆಂಕಿಯನ್ನು ನಂದಿಸುತ್ತವೆ ಮತ್ತು ನಮಗೆ ಸುರಕ್ಷತೆಯ ಸಣ್ಣ ಅಂಚುಗಳನ್ನು ನೀಡುತ್ತವೆ ಮತ್ತು ನಮಗೆ ಬದಲಾಯಿಸಲು ಸಮಯವನ್ನು ಖರೀದಿಸುತ್ತವೆ.

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

ತ್ವರಿತ ಬದಲಾವಣೆಗಳ ಒಣ ಪಟ್ಟಿ:

ಬೇಸ್ ಮಾಸ್ಟರ್ ಅನ್ನು ಸ್ಕೇಲ್ ಮಾಡಿ

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

2014 ರಿಂದ, ನಾವು ಅಜೂರ್‌ಗೆ ತೆರಳಿದ್ದೇವೆ; ನಾವು ಈ ವಿಷಯದ ಬಗ್ಗೆ ಲೇಖನದಲ್ಲಿ ಬರೆದಿದ್ದೇವೆ "ಮೈಕ್ರೋಸಾಫ್ಟ್ ಅಜುರೆ ಕ್ಲೌಡ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಡೋಡೋ ಪಿಜ್ಜಾ ಹೇಗೆ ಪಿಜ್ಜಾವನ್ನು ನೀಡುತ್ತದೆ" ಆದರೆ ಸರ್ವರ್ ಹೆಚ್ಚಳದ ಸರಣಿಯ ನಂತರ, ಬೇಸ್ನ ವೆಚ್ಚವು ಮಿತಿಯನ್ನು ತಲುಪಿತು. 

ಓದಲು ಡೇಟಾಬೇಸ್ ಪ್ರತಿಕೃತಿಗಳು

ನಾವು ಬೇಸ್ಗಾಗಿ ಎರಡು ಪ್ರತಿಕೃತಿಗಳನ್ನು ಮಾಡಿದ್ದೇವೆ:

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

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

ಕೋಡ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಗಳು

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

ಬ್ಯಾಕೆಂಡ್‌ಗಾಗಿ ಬಹು ಸರ್ವರ್‌ಗಳು

ಹೆಚ್ಚಿದ ಲೋಡ್‌ಗಳನ್ನು ತಡೆದುಕೊಳ್ಳಲು ಅಪ್ಲಿಕೇಶನ್‌ನ ಬ್ಯಾಕೆಂಡ್ ಅನ್ನು ಸಹ ಅಳೆಯಬೇಕಾಗಿತ್ತು. ಒಂದು IIS ಸರ್ವರ್‌ನಿಂದ ಕ್ಲಸ್ಟರ್ ಮಾಡಲು ಇದು ಅಗತ್ಯವಾಗಿತ್ತು. ನಾವು ತೆರಳಿದೆವು ಅಪ್ಲಿಕೇಶನ್ ಅಧಿವೇಶನ RedisCache ನಲ್ಲಿನ ಮೆಮೊರಿಯಿಂದ, ಇದು ರೌಂಡ್ ರಾಬಿನ್‌ನೊಂದಿಗೆ ಸರಳ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ನ ಹಿಂದೆ ಹಲವಾರು ಸರ್ವರ್‌ಗಳನ್ನು ರಚಿಸಲು ಸಾಧ್ಯವಾಗಿಸಿತು. ಮೊದಲಿಗೆ, ಸಂಗ್ರಹಗಳಿಗಾಗಿ ಅದೇ ರೆಡಿಸ್ ಅನ್ನು ಬಳಸಲಾಗುತ್ತಿತ್ತು, ನಂತರ ಅವುಗಳನ್ನು ಹಲವಾರು ಭಾಗಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ. 

ಪರಿಣಾಮವಾಗಿ, ವಾಸ್ತುಶಿಲ್ಪವು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಯಿತು ...

...ಆದರೆ ಸ್ವಲ್ಪ ಟೆನ್ಶನ್ ಶಮನವಾಯಿತು.

ತದನಂತರ ಲೋಡ್ ಮಾಡಲಾದ ಘಟಕಗಳನ್ನು ಮತ್ತೆ ಮಾಡುವುದು ಅಗತ್ಯವಾಗಿತ್ತು, ಅದನ್ನು ನಾವು ತೆಗೆದುಕೊಂಡಿದ್ದೇವೆ. ಇದರ ಬಗ್ಗೆ ಮುಂದಿನ ಭಾಗದಲ್ಲಿ ಮಾತನಾಡುತ್ತೇವೆ.

ಮೂಲ: www.habr.com