ಸೆಪ್ಟೆಂಬರ್ 19 ಮಾಸ್ಕೋದಲ್ಲಿ ಮೊದಲ ವಿಷಯಾಧಾರಿತ ಸಭೆ HUG (ಹೈಲೋಡ್++ ಯೂಸರ್ ಗ್ರೂಪ್), ಇದನ್ನು ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗೆ ಸಮರ್ಪಿಸಲಾಗಿದೆ. ಪ್ರಸ್ತುತಿಯು "ಆಪರೇಟಿಂಗ್ ಮೈಕ್ರೋಸರ್ವೀಸಸ್: ಸೈಜ್ ಮ್ಯಾಟರ್ಸ್, ನೀವು ಕುಬರ್ನೆಟ್ಸ್ ಹೊಂದಿದ್ದರೂ ಸಹ," ಇದರಲ್ಲಿ ನಾವು ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನೊಂದಿಗೆ ಆಪರೇಟಿಂಗ್ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳಲ್ಲಿ ಫ್ಲಾಂಟ್‌ನ ವ್ಯಾಪಕ ಅನುಭವವನ್ನು ಹಂಚಿಕೊಂಡಿದ್ದೇವೆ. ಮೊದಲನೆಯದಾಗಿ, ತಮ್ಮ ಪ್ರಸ್ತುತ ಅಥವಾ ಭವಿಷ್ಯದ ಯೋಜನೆಯಲ್ಲಿ ಈ ವಿಧಾನವನ್ನು ಬಳಸುವ ಬಗ್ಗೆ ಯೋಚಿಸುತ್ತಿರುವ ಎಲ್ಲಾ ಡೆವಲಪರ್‌ಗಳಿಗೆ ಇದು ಉಪಯುಕ್ತವಾಗಿರುತ್ತದೆ.
ಪರಿಚಯಿಸುವ (50 ನಿಮಿಷಗಳು, ಲೇಖನಕ್ಕಿಂತ ಹೆಚ್ಚು ತಿಳಿವಳಿಕೆ), ಹಾಗೆಯೇ ಪಠ್ಯ ರೂಪದಲ್ಲಿ ಅದರಿಂದ ಮುಖ್ಯ ಸಾರ.
NB: ಈ ಪೋಸ್ಟ್‌ನ ಕೊನೆಯಲ್ಲಿ ವೀಡಿಯೊ ಮತ್ತು ಪ್ರಸ್ತುತಿ ಸಹ ಲಭ್ಯವಿದೆ.
ಪರಿಚಯ
ಸಾಮಾನ್ಯವಾಗಿ ಒಳ್ಳೆಯ ಕಥೆಗೆ ಆರಂಭ, ಮುಖ್ಯ ಕಥಾವಸ್ತು ಮತ್ತು ರೆಸಲ್ಯೂಶನ್ ಇರುತ್ತದೆ. ಈ ವರದಿಯು ಮುನ್ನುಡಿಯಂತಿದೆ ಮತ್ತು ಅದರಲ್ಲಿ ದುರಂತವಾಗಿದೆ. ಇದು ಮೈಕ್ರೊ ಸರ್ವೀಸ್‌ನ ಹೊರಗಿನವರ ನೋಟವನ್ನು ಒದಗಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಗಮನಿಸುವುದು ಮುಖ್ಯವಾಗಿದೆ. ಶೋಷಣೆ.
ನಾನು ಈ ಗ್ರಾಫ್‌ನೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸುತ್ತೇನೆ, ಅದರ ಲೇಖಕ (2015 ರಲ್ಲಿ) ಮಾರ್ಟಿನ್ ಫೌಲರ್:
ಒಂದು ನಿರ್ದಿಷ್ಟ ಮೌಲ್ಯವನ್ನು ತಲುಪುವ ಏಕಶಿಲೆಯ ಅಪ್ಲಿಕೇಶನ್‌ನ ಸಂದರ್ಭದಲ್ಲಿ, ಉತ್ಪಾದಕತೆಯು ಹೇಗೆ ಕುಸಿಯಲು ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಇದು ತೋರಿಸುತ್ತದೆ. ಸೂಕ್ಷ್ಮ ಸೇವೆಗಳು ವಿಭಿನ್ನವಾಗಿವೆ, ಅವುಗಳೊಂದಿಗಿನ ಆರಂಭಿಕ ಉತ್ಪಾದಕತೆ ಕಡಿಮೆಯಾಗಿದೆ, ಆದರೆ ಸಂಕೀರ್ಣತೆ ಹೆಚ್ಚಾದಂತೆ, ದಕ್ಷತೆಯ ಅವನತಿಯು ಅವರಿಗೆ ಅಷ್ಟೊಂದು ಗಮನಿಸುವುದಿಲ್ಲ.
ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಬಳಸುವ ಸಂದರ್ಭದಲ್ಲಿ ನಾನು ಈ ಗ್ರಾಫ್‌ಗೆ ಸೇರಿಸುತ್ತೇನೆ:
ಮೈಕ್ರೋಸರ್ವಿಸ್‌ನೊಂದಿಗೆ ಅಪ್ಲಿಕೇಶನ್ ಏಕೆ ಉತ್ತಮವಾಗಿದೆ? ಏಕೆಂದರೆ ಅಂತಹ ವಾಸ್ತುಶಿಲ್ಪವು ವಾಸ್ತುಶಿಲ್ಪಕ್ಕೆ ಗಂಭೀರವಾದ ಅವಶ್ಯಕತೆಗಳನ್ನು ಮುಂದಿಡುತ್ತದೆ, ಇದು ಕುಬರ್ನೆಟ್ಸ್ನ ಸಾಮರ್ಥ್ಯಗಳಿಂದ ಸಂಪೂರ್ಣವಾಗಿ ಆವರಿಸಲ್ಪಟ್ಟಿದೆ. ಮತ್ತೊಂದೆಡೆ, ಈ ಕೆಲವು ಕಾರ್ಯಚಟುವಟಿಕೆಗಳು ಏಕಶಿಲೆಗೆ ಉಪಯುಕ್ತವಾಗುತ್ತವೆ, ವಿಶೇಷವಾಗಿ ಇಂದು ವಿಶಿಷ್ಟವಾದ ಏಕಶಿಲೆಯು ನಿಖರವಾಗಿ ಏಕಶಿಲೆಯಾಗಿಲ್ಲ (ವಿವರಗಳು ನಂತರದ ವರದಿಯಲ್ಲಿವೆ).
ನೀವು ನೋಡುವಂತೆ, ಅಂತಿಮ ಗ್ರಾಫ್ (ಎರಡೂ ಏಕಶಿಲೆಯ ಮತ್ತು ಮೈಕ್ರೋಸರ್ವಿಸ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಕುಬರ್ನೆಟ್ಸ್‌ನೊಂದಿಗೆ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿರುವಾಗ) ಮೂಲಕ್ಕಿಂತ ಹೆಚ್ಚು ಭಿನ್ನವಾಗಿರುವುದಿಲ್ಲ. ಮುಂದೆ ನಾವು ಕುಬರ್ನೆಟ್ಸ್ ಬಳಸಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇವೆ.
ಉಪಯುಕ್ತ ಮತ್ತು ಹಾನಿಕಾರಕ ಸೂಕ್ಷ್ಮ ಸೇವೆಗಳು
ಮತ್ತು ಮುಖ್ಯ ಆಲೋಚನೆ ಇಲ್ಲಿದೆ:
ಏನದು ಸಾಮಾನ್ಯ ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್? ಇದು ನಿಮಗೆ ನಿಜವಾದ ಪ್ರಯೋಜನಗಳನ್ನು ತರಬೇಕು, ನಿಮ್ಮ ಕೆಲಸದ ದಕ್ಷತೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ. ನಾವು ಗ್ರಾಫ್‌ಗೆ ಹಿಂತಿರುಗಿದರೆ, ಅದು ಇಲ್ಲಿದೆ:
ನೀವು ಅವಳನ್ನು ಕರೆದರೆ ಉಪಯುಕ್ತ, ನಂತರ ಗ್ರಾಫ್ನ ಇನ್ನೊಂದು ಬದಿಯಲ್ಲಿ ಇರುತ್ತದೆ ಹಾನಿಕಾರಕ ಸೂಕ್ಷ್ಮ ಸೇವೆಗಳು (ಕೆಲಸದಲ್ಲಿ ಮಧ್ಯಪ್ರವೇಶಿಸುತ್ತದೆ):
"ಮುಖ್ಯ ಕಲ್ಪನೆ" ಗೆ ಹಿಂತಿರುಗುವುದು: ನನ್ನ ಅನುಭವವನ್ನು ನಾನು ನಂಬಬೇಕೇ? ಈ ವರ್ಷದ ಆರಂಭದಿಂದ ನಾನು ನೋಡುತ್ತಿದ್ದೇನೆ 85 ಯೋಜನೆಗಳು. ಅವರೆಲ್ಲರೂ ಮೈಕ್ರೊ ಸರ್ವೀಸ್‌ಗಳಾಗಿರಲಿಲ್ಲ (ಅವುಗಳಲ್ಲಿ ಮೂರನೇ ಒಂದು ಭಾಗದಿಂದ ಅರ್ಧದಷ್ಟು ಅಂತಹ ವಾಸ್ತುಶಿಲ್ಪವನ್ನು ಹೊಂದಿದ್ದವು), ಆದರೆ ಇದು ಇನ್ನೂ ದೊಡ್ಡ ಸಂಖ್ಯೆಯಾಗಿದೆ. ನಾವು (ಫ್ಲಾಂಟ್ ಕಂಪನಿ) ಹೊರಗುತ್ತಿಗೆದಾರರಾಗಿ ಸಣ್ಣ ಕಂಪನಿಗಳಲ್ಲಿ (5 ಡೆವಲಪರ್‌ಗಳೊಂದಿಗೆ) ಮತ್ತು ದೊಡ್ಡ ಕಂಪನಿಗಳಲ್ಲಿ (~ 500 ಡೆವಲಪರ್‌ಗಳು) ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ ವಿವಿಧ ರೀತಿಯ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನೋಡಲು ನಿರ್ವಹಿಸುತ್ತೇವೆ. ಒಂದು ಹೆಚ್ಚುವರಿ ಪ್ರಯೋಜನವೆಂದರೆ ಈ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ವರ್ಷಗಳಲ್ಲಿ ಲೈವ್ ಮತ್ತು ವಿಕಸನಗೊಳ್ಳುವುದನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ.
ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ಏಕೆ?
ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ನ ಪ್ರಯೋಜನಗಳ ಬಗ್ಗೆ ಪ್ರಶ್ನೆಗೆ ಇದೆ ಈಗಾಗಲೇ ಉಲ್ಲೇಖಿಸಲಾದ ಮಾರ್ಟಿನ್ ಫೌಲರ್ ಅವರಿಂದ:
- ಮಾಡ್ಯುಲಾರಿಟಿಯ ಸ್ಪಷ್ಟ ಗಡಿಗಳು;
- ಸ್ವತಂತ್ರ ನಿಯೋಜನೆ;
- ತಂತ್ರಜ್ಞಾನಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಸ್ವಾತಂತ್ರ್ಯ.
ನಾನು ಸಾಫ್ಟ್‌ವೇರ್ ಆರ್ಕಿಟೆಕ್ಟ್‌ಗಳು ಮತ್ತು ಡೆವಲಪರ್‌ಗಳೊಂದಿಗೆ ಸಾಕಷ್ಟು ಮಾತನಾಡಿದ್ದೇನೆ ಮತ್ತು ಅವರಿಗೆ ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳು ಏಕೆ ಬೇಕು ಎಂದು ಕೇಳಿದೆ. ಮತ್ತು ನಾನು ಅವರ ನಿರೀಕ್ಷೆಗಳ ಪಟ್ಟಿಯನ್ನು ಮಾಡಿದ್ದೇನೆ. ಏನಾಯಿತು ಎಂಬುದು ಇಲ್ಲಿದೆ:
ನಾವು "ಸಂವೇದನೆಗಳಲ್ಲಿ" ಕೆಲವು ಅಂಶಗಳನ್ನು ವಿವರಿಸಿದರೆ:
- ಮಾಡ್ಯೂಲ್‌ಗಳ ಸ್ಪಷ್ಟ ಗಡಿಗಳು: ಇಲ್ಲಿ ನಾವು ಭಯಾನಕ ಏಕಶಿಲೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಈಗ ಎಲ್ಲವನ್ನೂ ಜಿಟ್ ರೆಪೊಸಿಟರಿಗಳಲ್ಲಿ ಅಂದವಾಗಿ ಜೋಡಿಸಲಾಗುತ್ತದೆ, ಇದರಲ್ಲಿ ಎಲ್ಲವೂ “ಕಪಾಟಿನಲ್ಲಿ” ಇದೆ, ಬೆಚ್ಚಗಿನ ಮತ್ತು ಮೃದುವಾದವು ಮಿಶ್ರಣವಾಗುವುದಿಲ್ಲ;
- ನಿಯೋಜನೆಯ ಸ್ವಾತಂತ್ರ್ಯ: ನಾವು ಸ್ವತಂತ್ರವಾಗಿ ಸೇವೆಗಳನ್ನು ಹೊರತರಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ ಇದರಿಂದ ಅಭಿವೃದ್ಧಿಯು ವೇಗವಾಗಿ ಹೋಗುತ್ತದೆ (ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಸಮಾನಾಂತರವಾಗಿ ಪ್ರಕಟಿಸಿ);
- ಅಭಿವೃದ್ಧಿ ಸ್ವಾತಂತ್ರ್ಯ: ನಾವು ಈ ಮೈಕ್ರೊ ಸರ್ವಿಸ್ ಅನ್ನು ಒಂದು ತಂಡ/ಡೆವಲಪರ್‌ಗೆ ನೀಡಬಹುದು ಮತ್ತು ಅದನ್ನು ಇನ್ನೊಂದಕ್ಕೆ ನೀಡಬಹುದು, ಇದಕ್ಕೆ ಧನ್ಯವಾದಗಳು ನಾವು ವೇಗವಾಗಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಬಹುದು;
- боಹೆಚ್ಚಿನ ವಿಶ್ವಾಸಾರ್ಹತೆ: ಭಾಗಶಃ ಅವನತಿ ಸಂಭವಿಸಿದಲ್ಲಿ (20 ರಲ್ಲಿ ಒಂದು ಮೈಕ್ರೊ ಸರ್ವಿಸ್ ಬೀಳುತ್ತದೆ), ನಂತರ ಕೇವಲ ಒಂದು ಬಟನ್ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ ಮತ್ತು ಒಟ್ಟಾರೆಯಾಗಿ ಸಿಸ್ಟಮ್ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ.
ವಿಶಿಷ್ಟ (ಹಾನಿಕಾರಕ) ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್
ರಿಯಾಲಿಟಿ ಏಕೆ ನಾವು ನಿರೀಕ್ಷಿಸುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ವಿವರಿಸಲು, ನಾನು ಪ್ರಸ್ತುತಪಡಿಸುತ್ತೇನೆ ಸಾಮೂಹಿಕ ಹಲವಾರು ವಿಭಿನ್ನ ಯೋಜನೆಗಳ ಅನುಭವದ ಆಧಾರದ ಮೇಲೆ ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನ ಚಿತ್ರ.
ಅಮೆಜಾನ್ ಅಥವಾ ಕನಿಷ್ಠ OZON ನೊಂದಿಗೆ ಸ್ಪರ್ಧಿಸಲಿರುವ ಅಮೂರ್ತ ಆನ್‌ಲೈನ್ ಸ್ಟೋರ್ ಒಂದು ಉದಾಹರಣೆಯಾಗಿದೆ. ಇದರ ಮೈಕ್ರೊ ಸರ್ವಿಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:
ಕಾರಣಗಳ ಸಂಯೋಜನೆಗಾಗಿ, ಈ ಮೈಕ್ರೋಸರ್ವಿಸ್‌ಗಳನ್ನು ವಿವಿಧ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ:
ಪ್ರತಿಯೊಂದು ಮೈಕ್ರೊ ಸರ್ವೀಸ್ ಸ್ವಾಯತ್ತತೆಯನ್ನು ಹೊಂದಿರಬೇಕಾಗಿರುವುದರಿಂದ, ಅವುಗಳಲ್ಲಿ ಹಲವು ತಮ್ಮದೇ ಆದ ಡೇಟಾಬೇಸ್ ಮತ್ತು ಸಂಗ್ರಹದ ಅಗತ್ಯವಿರುತ್ತದೆ. ಅಂತಿಮ ವಾಸ್ತುಶಿಲ್ಪವು ಈ ಕೆಳಗಿನಂತಿರುತ್ತದೆ:
ಅದರ ಪರಿಣಾಮಗಳೇನು?
ಫೌಲರ್ ಕೂಡ ಇದನ್ನು ಹೊಂದಿದ್ದಾನೆ - ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳನ್ನು ಬಳಸುವುದಕ್ಕಾಗಿ "ಪಾವತಿ" ಬಗ್ಗೆ:
ಮತ್ತು ನಮ್ಮ ನಿರೀಕ್ಷೆಗಳನ್ನು ಪೂರೈಸಲಾಗಿದೆಯೇ ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ.
ಮಾಡ್ಯೂಲ್‌ಗಳ ಗಡಿಗಳನ್ನು ತೆರವುಗೊಳಿಸಿ...
ಆದರೆ ನಾವು ನಿಜವಾಗಿ ಎಷ್ಟು ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳನ್ನು ಸರಿಪಡಿಸಬೇಕಾಗಿದೆ?ಬದಲಾವಣೆಯನ್ನು ಹೊರತರಲು? ವಿತರಿಸಿದ ಟ್ರೇಸರ್ ಇಲ್ಲದೆ ಎಲ್ಲವೂ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಾವು ಲೆಕ್ಕಾಚಾರ ಮಾಡಬಹುದೇ (ಎಲ್ಲಾ ನಂತರ, ಯಾವುದೇ ವಿನಂತಿಯನ್ನು ಮೈಕ್ರೋಸರ್ವಿಸ್‌ಗಳ ಅರ್ಧದಷ್ಟು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುತ್ತದೆ)?
ಒಂದು ಮಾದರಿ ಇದೆ "", ಮತ್ತು ಇಲ್ಲಿ ಅದು ಕೊಳಕು ವಿತರಿಸಿದ ಉಂಡೆಯಾಗಿ ಹೊರಹೊಮ್ಮಿತು. ಇದನ್ನು ಖಚಿತಪಡಿಸಲು, ವಿನಂತಿಗಳು ಹೇಗೆ ಹೋಗುತ್ತವೆ ಎಂಬುದರ ಅಂದಾಜು ವಿವರಣೆ ಇಲ್ಲಿದೆ:
ನಿಯೋಜನೆ ಸ್ವಾತಂತ್ರ್ಯ...
ತಾಂತ್ರಿಕವಾಗಿ, ಇದನ್ನು ಸಾಧಿಸಲಾಗಿದೆ: ನಾವು ಪ್ರತಿ ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಹೊರತರಬಹುದು. ಆದರೆ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಅದು ಯಾವಾಗಲೂ ಹೊರಹೊಮ್ಮುತ್ತದೆ ಎಂದು ನೀವು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕು ಅನೇಕ ಸೂಕ್ಷ್ಮ ಸೇವೆಗಳು, ಮತ್ತು ನಾವು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕಾಗಿದೆ ಅವರ ರೋಲ್‌ಔಟ್‌ನ ಕ್ರಮ. ಉತ್ತಮ ರೀತಿಯಲ್ಲಿ, ನಾವು ಬಿಡುಗಡೆಯನ್ನು ಸರಿಯಾದ ಕ್ರಮದಲ್ಲಿ ಹೊರತರುತ್ತಿದ್ದೇವೆಯೇ ಎಂದು ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರತ್ಯೇಕ ಸರ್ಕ್ಯೂಟ್‌ನಲ್ಲಿ ಪರೀಕ್ಷಿಸಬೇಕಾಗಿದೆ.
ತಂತ್ರಜ್ಞಾನವನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಸ್ವಾತಂತ್ರ್ಯ...
ಅವಳು. ಸ್ವಾತಂತ್ರ್ಯವು ಸಾಮಾನ್ಯವಾಗಿ ಕಾನೂನುಬಾಹಿರತೆಯ ಗಡಿಯಾಗಿದೆ ಎಂಬುದನ್ನು ನೆನಪಿಡಿ. ಅವರೊಂದಿಗೆ "ಆಡಲು" ತಂತ್ರಜ್ಞಾನಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡದಿರುವುದು ಇಲ್ಲಿ ಬಹಳ ಮುಖ್ಯವಾಗಿದೆ.
ಅಭಿವೃದ್ಧಿಯ ಸ್ವಾತಂತ್ರ್ಯ...
ಸಂಪೂರ್ಣ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ (ಹಲವು ಘಟಕಗಳೊಂದಿಗೆ) ಪರೀಕ್ಷಾ ಲೂಪ್ ಅನ್ನು ಹೇಗೆ ಮಾಡುವುದು? ಆದರೆ ನೀವು ಅದನ್ನು ಇನ್ನೂ ನವೀಕರಿಸಬೇಕಾಗಿದೆ. ಇದೆಲ್ಲವೂ ಎಂಬ ಅಂಶಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ ಪರೀಕ್ಷಾ ಸರ್ಕ್ಯೂಟ್ಗಳ ನಿಜವಾದ ಸಂಖ್ಯೆ, ನಾವು ತಾತ್ವಿಕವಾಗಿ ಹೊಂದಿರಬಹುದು, ಕನಿಷ್ಠ ಎಂದು ತಿರುಗುತ್ತದೆ.
ಈ ಎಲ್ಲವನ್ನು ಸ್ಥಳೀಯವಾಗಿ ನಿಯೋಜಿಸುವುದು ಹೇಗೆ?.. ಆಗಾಗ್ಗೆ ಡೆವಲಪರ್ ತನ್ನ ಕೆಲಸವನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ಮಾಡುತ್ತಾನೆ, ಆದರೆ "ಯಾದೃಚ್ಛಿಕವಾಗಿ" ಎಂದು ತಿರುಗುತ್ತದೆ, ಏಕೆಂದರೆ ಸರ್ಕ್ಯೂಟ್ ಪರೀಕ್ಷೆಗೆ ಮುಕ್ತವಾಗುವವರೆಗೆ ಕಾಯಲು ಒತ್ತಾಯಿಸಲಾಗುತ್ತದೆ.
ಪ್ರತ್ಯೇಕ ಸ್ಕೇಲಿಂಗ್...
ಹೌದು, ಆದರೆ ಬಳಸಿದ DBMS ಪ್ರದೇಶದಲ್ಲಿ ಇದು ಸೀಮಿತವಾಗಿದೆ. ನೀಡಿರುವ ಆರ್ಕಿಟೆಕ್ಚರ್ ಉದಾಹರಣೆಯಲ್ಲಿ, ಕಸ್ಸಂದ್ರವು ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ, ಆದರೆ MySQL ಮತ್ತು PostgreSQL.
Боಹೆಚ್ಚಿನ ವಿಶ್ವಾಸಾರ್ಹತೆ...
ವಾಸ್ತವದಲ್ಲಿ ಒಂದು ಮೈಕ್ರೊ ಸರ್ವೀಸ್‌ನ ವೈಫಲ್ಯವು ಇಡೀ ಸಿಸ್ಟಮ್‌ನ ಸರಿಯಾದ ಕಾರ್ಯನಿರ್ವಹಣೆಯನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಮುರಿಯುತ್ತದೆ, ಆದರೆ ಹೊಸ ಸಮಸ್ಯೆಯೂ ಇದೆ: ಪ್ರತಿ ಮೈಕ್ರೋ ಸರ್ವಿಸ್ ದೋಷ-ಸಹಿಷ್ಣು ಮಾಡುವುದು ತುಂಬಾ ಕಷ್ಟ. ಮೈಕ್ರೊ ಸರ್ವಿಸ್‌ಗಳು ವಿಭಿನ್ನ ತಂತ್ರಜ್ಞಾನಗಳನ್ನು (ಮೆಮ್‌ಕ್ಯಾಶ್, ರೆಡಿಸ್, ಇತ್ಯಾದಿ) ಬಳಸುವುದರಿಂದ, ಪ್ರತಿಯೊಂದಕ್ಕೂ ನೀವು ಎಲ್ಲವನ್ನೂ ಯೋಚಿಸಬೇಕು ಮತ್ತು ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕು, ಅದು ಸಹಜವಾಗಿ ಸಾಧ್ಯ, ಆದರೆ ದೊಡ್ಡ ಸಂಪನ್ಮೂಲಗಳ ಅಗತ್ಯವಿರುತ್ತದೆ.
ಲೋಡ್ ಅಳತೆ...
ಇದು ನಿಜವಾಗಿಯೂ ಒಳ್ಳೆಯದು.
ಮೈಕ್ರೊ ಸರ್ವೀಸ್‌ನ "ಲಘುತೆ"...
ನಮ್ಮಲ್ಲಿ ದೊಡ್ಡದು ಮಾತ್ರವಲ್ಲ ನೆಟ್ವರ್ಕ್ ಓವರ್ಹೆಡ್ (DNS ಗಾಗಿ ವಿನಂತಿಗಳು ಗುಣಿಸುತ್ತಿವೆ, ಇತ್ಯಾದಿ), ಆದರೆ ನಾವು ಪ್ರಾರಂಭಿಸಿದ ಅನೇಕ ಉಪಪ್ರಶ್ನೆಗಳ ಕಾರಣದಿಂದಾಗಿ ಡೇಟಾವನ್ನು ಪುನರಾವರ್ತಿಸಿ (ಸ್ಟೋರ್ ಕ್ಯಾಷ್), ಇದು ಗಮನಾರ್ಹ ಪ್ರಮಾಣದ ಸಂಗ್ರಹಣೆಗೆ ಕಾರಣವಾಯಿತು.
ಮತ್ತು ನಮ್ಮ ನಿರೀಕ್ಷೆಗಳನ್ನು ಪೂರೈಸಿದ ಫಲಿತಾಂಶ ಇಲ್ಲಿದೆ:
ಆದರೆ ಅಷ್ಟೆ ಅಲ್ಲ!
ಏಕೆಂದರೆ:
- ಹೆಚ್ಚಾಗಿ ನಮಗೆ ಸಂದೇಶ ಬಸ್ ಅಗತ್ಯವಿರುತ್ತದೆ.
- ಸರಿಯಾದ ಸಮಯದಲ್ಲಿ ಸ್ಥಿರವಾದ ಬ್ಯಾಕಪ್ ಅನ್ನು ಹೇಗೆ ಮಾಡುವುದು? ಒಂದೇ ಒಂದು ನೈಜ ಇದಕ್ಕಾಗಿ ಸಂಚಾರವನ್ನು ಆಫ್ ಮಾಡುವುದು ಆಯ್ಕೆಯಾಗಿದೆ. ಆದರೆ ಉತ್ಪಾದನೆಯಲ್ಲಿ ಇದನ್ನು ಹೇಗೆ ಮಾಡುವುದು?
- ನಾವು ಹಲವಾರು ಪ್ರದೇಶಗಳನ್ನು ಬೆಂಬಲಿಸುವ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದರೆ, ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದರಲ್ಲೂ ಸುಸ್ಥಿರತೆಯನ್ನು ಸಂಘಟಿಸುವುದು ಬಹಳ ಕಾರ್ಮಿಕ-ತೀವ್ರ ಕಾರ್ಯವಾಗಿದೆ.
- ಕೇಂದ್ರೀಕೃತ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡುವ ಸಮಸ್ಯೆ ಉದ್ಭವಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ನಾವು PHP ಆವೃತ್ತಿಯನ್ನು ನವೀಕರಿಸಬೇಕಾದರೆ, ನಾವು ಪ್ರತಿ ರೆಪೊಸಿಟರಿಗೆ ಬದ್ಧರಾಗಬೇಕಾಗುತ್ತದೆ (ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಡಜನ್ಗಟ್ಟಲೆ ಇವೆ).
- ಕಾರ್ಯಾಚರಣೆಯ ಸಂಕೀರ್ಣತೆಯ ಬೆಳವಣಿಗೆಯು ಆಫ್‌ಹ್ಯಾಂಡ್, ಘಾತೀಯವಾಗಿದೆ.
ಇದನ್ನೆಲ್ಲ ಏನು ಮಾಡಬೇಕು?
ಏಕಶಿಲೆಯ ಅಪ್ಲಿಕೇಶನ್ನೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿ. ಫೌಲರ್ ಅವರ ಅನುಭವ ಬಹುತೇಕ ಎಲ್ಲಾ ಯಶಸ್ವಿ ಮೈಕ್ರೋಸರ್ವೀಸ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಏಕಶಿಲೆಯಾಗಿ ಪ್ರಾರಂಭವಾದವು ಅದು ತುಂಬಾ ದೊಡ್ಡದಾಗಿದೆ ಮತ್ತು ನಂತರ ಮುರಿದುಹೋಯಿತು. ಅದೇ ಸಮಯದಲ್ಲಿ, ಬಹುಪಾಲು ಎಲ್ಲಾ ವ್ಯವಸ್ಥೆಗಳು ಮೈಕ್ರೋ ಸರ್ವಿಸ್‌ಗಳಾಗಿ ನಿರ್ಮಿಸಲಾದ ಮೊದಲಿನಿಂದಲೂ ಬೇಗ ಅಥವಾ ನಂತರ ಗಂಭೀರ ಸಮಸ್ಯೆಗಳನ್ನು ಅನುಭವಿಸಿದವು.
ಮತ್ತೊಂದು ಅಮೂಲ್ಯವಾದ ಚಿಂತನೆಯೆಂದರೆ, ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಹೊಂದಿರುವ ಯೋಜನೆಯು ಯಶಸ್ವಿಯಾಗಬೇಕಾದರೆ, ನೀವು ಚೆನ್ನಾಗಿ ತಿಳಿದಿರಬೇಕು ಮತ್ತು ವಿಷಯದ ಪ್ರದೇಶ, ಮತ್ತು ಮೈಕ್ರೊ ಸರ್ವೀಸಸ್ ಅನ್ನು ಹೇಗೆ ಮಾಡುವುದು. ಮತ್ತು ವಿಷಯದ ಪ್ರದೇಶವನ್ನು ಕಲಿಯಲು ಉತ್ತಮ ಮಾರ್ಗವೆಂದರೆ ಏಕಶಿಲೆ ಮಾಡುವುದು.
ಆದರೆ ನಾವು ಈಗಾಗಲೇ ಈ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿದ್ದರೆ ಏನು?
ಯಾವುದೇ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವ ಮೊದಲ ಹೆಜ್ಜೆಯೆಂದರೆ ಅದನ್ನು ಒಪ್ಪಿಕೊಳ್ಳುವುದು ಮತ್ತು ಅದು ಸಮಸ್ಯೆ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು, ನಾವು ಇನ್ನು ಮುಂದೆ ಅನುಭವಿಸಲು ಬಯಸುವುದಿಲ್ಲ.
ಮಿತಿಮೀರಿ ಬೆಳೆದ ಏಕಶಿಲೆಯ ಸಂದರ್ಭದಲ್ಲಿ (ಅದಕ್ಕಾಗಿ ಹೆಚ್ಚುವರಿ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಖರೀದಿಸುವ ಅವಕಾಶವನ್ನು ನಾವು ಕಳೆದುಕೊಂಡಾಗ), ನಾವು ಅದನ್ನು ಕತ್ತರಿಸಿದರೆ, ಈ ಸಂದರ್ಭದಲ್ಲಿ ವಿರುದ್ಧವಾದ ಕಥೆಯು ಹೊರಹೊಮ್ಮುತ್ತದೆ: ಅತಿಯಾದ ಮೈಕ್ರೊಸರ್ವಿಸ್ಗಳು ಇನ್ನು ಮುಂದೆ ಸಹಾಯ ಮಾಡದಿದ್ದಾಗ, ಆದರೆ ಅಡ್ಡಿಯುಂಟುಮಾಡುತ್ತದೆ - ಹೆಚ್ಚುವರಿ ಕತ್ತರಿಸಿ ಮತ್ತು ಹಿಗ್ಗಿಸಿ!
ಉದಾಹರಣೆಗೆ, ಮೇಲೆ ಚರ್ಚಿಸಿದ ಸಾಮೂಹಿಕ ಚಿತ್ರಕ್ಕಾಗಿ...
ಅತ್ಯಂತ ಪ್ರಶ್ನಾರ್ಹ ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳನ್ನು ತೊಡೆದುಹಾಕಿ:
ಮುಂಭಾಗದ ಉತ್ಪಾದನೆಗೆ ಜವಾಬ್ದಾರರಾಗಿರುವ ಎಲ್ಲಾ ಸೂಕ್ಷ್ಮ ಸೇವೆಗಳನ್ನು ಸಂಯೋಜಿಸಿ:
... ಒಂದು ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ಆಗಿ, ಒಂದರಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ (ಆಧುನಿಕ ಮತ್ತು ಸಾಮಾನ್ಯ, ನೀವೇ ಯೋಚಿಸಿದಂತೆ) ಭಾಷೆ/ಫ್ರೇಮ್‌ವರ್ಕ್:
ಇದು ಒಂದು ORM (ಒಂದು DBMS) ಮತ್ತು ಮೊದಲು ಒಂದೆರಡು ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ:
... ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ ನೀವು ಹೆಚ್ಚಿನದನ್ನು ಅಲ್ಲಿಗೆ ವರ್ಗಾಯಿಸಬಹುದು, ಈ ಕೆಳಗಿನ ಫಲಿತಾಂಶವನ್ನು ಪಡೆಯಬಹುದು:
ಇದಲ್ಲದೆ, ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ನಾವು ಈ ಎಲ್ಲವನ್ನು ಪ್ರತ್ಯೇಕ ನಿದರ್ಶನಗಳಲ್ಲಿ ನಡೆಸುತ್ತೇವೆ, ಅಂದರೆ ನಾವು ಇನ್ನೂ ಲೋಡ್ ಅನ್ನು ಅಳೆಯಬಹುದು ಮತ್ತು ಅವುಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಅಳೆಯಬಹುದು.
ಸಾರಾಂಶಿಸು
ದೊಡ್ಡ ಚಿತ್ರವನ್ನು ನೋಡಿ. ಆಗಾಗ್ಗೆ, ಮೈಕ್ರೊ ಸರ್ವಿಸ್‌ಗಳೊಂದಿಗಿನ ಈ ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳು ಉದ್ಭವಿಸುತ್ತವೆ ಏಕೆಂದರೆ ಯಾರಾದರೂ ತಮ್ಮ ಕೆಲಸವನ್ನು ತೆಗೆದುಕೊಂಡರು, ಆದರೆ “ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ನೊಂದಿಗೆ ಆಡಲು” ಬಯಸಿದ್ದರು.
"ಮೈಕ್ರೋಸರ್ವಿಸಸ್" ಪದದಲ್ಲಿ "ಮೈಕ್ರೋ" ಭಾಗವು ಅನಗತ್ಯವಾಗಿದೆ.. ಅವು ಬೃಹತ್ ಏಕಶಿಲೆಗಿಂತ ಚಿಕ್ಕದಾಗಿರುವುದರಿಂದ ಮಾತ್ರ "ಸೂಕ್ಷ್ಮ". ಆದರೆ ಅವುಗಳನ್ನು ಸಣ್ಣ ವಿಷಯ ಎಂದು ಭಾವಿಸಬೇಡಿ.
ಮತ್ತು ಅಂತಿಮ ಚಿಂತನೆಗಾಗಿ, ಮೂಲ ಚಾರ್ಟ್‌ಗೆ ಹಿಂತಿರುಗೋಣ:
ಅದರ ಮೇಲೆ ಬರೆದ ಟಿಪ್ಪಣಿ (ಮೇಲಿನಿಂದ ಬಲ) ಎಂಬ ಅಂಶಕ್ಕೆ ಕುದಿಯುತ್ತದೆ ನಿಮ್ಮ ಯೋಜನೆಯನ್ನು ಮಾಡುವ ತಂಡದ ಕೌಶಲ್ಯಗಳು ಯಾವಾಗಲೂ ಪ್ರಾಥಮಿಕವಾಗಿರುತ್ತವೆ — ಮೈಕ್ರೊ ಸರ್ವೀಸ್ ಮತ್ತು ಏಕಶಿಲೆಯ ನಡುವೆ ನಿಮ್ಮ ಆಯ್ಕೆಯಲ್ಲಿ ಅವರು ಪ್ರಮುಖ ಪಾತ್ರ ವಹಿಸುತ್ತಾರೆ. ತಂಡವು ಸಾಕಷ್ಟು ಕೌಶಲ್ಯಗಳನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ, ಆದರೆ ಅದು ಮೈಕ್ರೋಸರ್ವಿಸ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದರೆ, ಕಥೆಯು ಖಂಡಿತವಾಗಿಯೂ ಮಾರಕವಾಗಿರುತ್ತದೆ.
ವೀಡಿಯೊಗಳು ಮತ್ತು ಸ್ಲೈಡ್‌ಗಳು
ಭಾಷಣದಿಂದ ವೀಡಿಯೊ (~ 50 ನಿಮಿಷಗಳು; ದುರದೃಷ್ಟವಶಾತ್, ಇದು ಸಂದರ್ಶಕರ ಹಲವಾರು ಭಾವನೆಗಳನ್ನು ತಿಳಿಸುವುದಿಲ್ಲ, ಇದು ವರದಿಯ ಮನಸ್ಥಿತಿಯನ್ನು ಹೆಚ್ಚಾಗಿ ನಿರ್ಧರಿಸುತ್ತದೆ, ಆದರೆ ಅದು ಹೀಗಿದೆ):
ವರದಿಯ ಮಂಡನೆ:
ಪಿಎಸ್
ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿನ ಇತರ ವರದಿಗಳು:
- «» (ಡಿಮಿಟ್ರಿ ಸ್ಟೋಲಿಯಾರೋವ್; ಮೇ 28, 2018 ರೂಟ್‌ಕಾನ್ಫ್‌ನಲ್ಲಿ);
- «» (ಡಿಮಿಟ್ರಿ ಸ್ಟೋಲಿಯಾರೋವ್; ನವೆಂಬರ್ 7, 2017 ಹೈಲೋಡ್++ ನಲ್ಲಿ);
- «» (ಡಿಮಿಟ್ರಿ ಸ್ಟೋಲಿಯಾರೋವ್; ಜೂನ್ 6, 2017 ರೂಟ್‌ಕಾನ್ಫ್‌ನಲ್ಲಿ);
- «» (ಡಿಮಿಟ್ರಿ ಸ್ಟೋಲಿಯಾರೋವ್; ನವೆಂಬರ್ 8, 2016 ಹೈಲೋಡ್++ ನಲ್ಲಿ);
- «» (ಡಿಮಿಟ್ರಿ ಸ್ಟೋಲಿಯಾರೋವ್; ಮೇ 31, 2016 ರೂಟ್‌ಕಾನ್ಫ್‌ನಲ್ಲಿ).
ನೀವು ಈ ಕೆಳಗಿನ ಪ್ರಕಟಣೆಗಳಲ್ಲಿ ಆಸಕ್ತಿ ಹೊಂದಿರಬಹುದು:
- «";
- «";
- «».
ಮೂಲ: www.habr.com