ಹಲೋ, ಹಬ್ರ್. ಹೊಸ ಕೋರ್ಸ್ ಸ್ಟ್ರೀಮ್‌ಗಾಗಿ ದಾಖಲಾತಿಯು ಇದೀಗ OTUS ನಲ್ಲಿ ತೆರೆದಿರುತ್ತದೆ . ಕೋರ್ಸ್ ಪ್ರಾರಂಭವಾಗುವ ಮುನ್ನಾದಿನದಂದು, ನನ್ನ ಮೂಲ ಲೇಖನವನ್ನು ನಿಮ್ಮೊಂದಿಗೆ ಹಂಚಿಕೊಳ್ಳಲು ನಾನು ಬಯಸುತ್ತೇನೆ.
ಪರಿಚಯ
ಮಾಹಿತಿ ವ್ಯವಸ್ಥೆಯನ್ನು ನಿರ್ಮಿಸುವಾಗ ವಾಸ್ತುಶಿಲ್ಪದ ಶೈಲಿಯ ಆಯ್ಕೆಯು ಮೂಲಭೂತ ತಾಂತ್ರಿಕ ನಿರ್ಧಾರಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ಈ ಲೇಖನಗಳ ಸರಣಿಯಲ್ಲಿ, ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಹೆಚ್ಚು ಜನಪ್ರಿಯವಾದ ವಾಸ್ತುಶಿಲ್ಪದ ಶೈಲಿಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಲು ನಾನು ಪ್ರಸ್ತಾಪಿಸುತ್ತೇನೆ ಮತ್ತು ಯಾವ ವಾಸ್ತುಶಿಲ್ಪದ ಶೈಲಿಯು ಯಾವಾಗ ಹೆಚ್ಚು ಯೋಗ್ಯವಾಗಿದೆ ಎಂಬ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ. ಪ್ರಸ್ತುತಿಯ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ, ಏಕಶಿಲೆಯಿಂದ ಮೈಕ್ರೊ ಸರ್ವೀಸ್‌ಗೆ ವಾಸ್ತುಶಿಲ್ಪದ ಶೈಲಿಗಳ ಅಭಿವೃದ್ಧಿಯನ್ನು ವಿವರಿಸುವ ತಾರ್ಕಿಕ ಸರಪಳಿಯನ್ನು ಸೆಳೆಯಲು ನಾನು ಪ್ರಯತ್ನಿಸುತ್ತೇನೆ.
ಇತಿಹಾಸದ ಸ್ವಲ್ಪ
ನೀವು ಡೆವಲಪರ್‌ಗಳನ್ನು ಕೇಳಲು ಪ್ರಯತ್ನಿಸಿದರೆ: "ನಮಗೆ ಮೈಕ್ರೊ ಸರ್ವೀಸ್‌ಗಳು ಏಕೆ ಬೇಕು?", ನೀವು ವಿವಿಧ ಉತ್ತರಗಳನ್ನು ಪಡೆಯುತ್ತೀರಿ. ಮೈಕ್ರೊ ಸರ್ವಿಸ್‌ಗಳು ಸ್ಕೇಲೆಬಿಲಿಟಿಯನ್ನು ಸುಧಾರಿಸುತ್ತದೆ, ಕೋಡ್ ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸುಲಭಗೊಳಿಸುತ್ತದೆ, ದೋಷ ಸಹಿಷ್ಣುತೆಯನ್ನು ಸುಧಾರಿಸುತ್ತದೆ ಮತ್ತು "ನಿಮ್ಮ ಕೋಡ್ ಅನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸಲು" ಅವರು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತಾರೆ ಎಂದು ನೀವು ಕೇಳುತ್ತೀರಿ. ಸೂಕ್ಷ್ಮ ಸೇವೆಗಳ ಹೊರಹೊಮ್ಮುವಿಕೆಯ ಹಿಂದಿನ ಉದ್ದೇಶವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಇತಿಹಾಸವನ್ನು ನೋಡೋಣ.
ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಹೇಳುವುದಾದರೆ, ನಮ್ಮ ಪ್ರಸ್ತುತ ತಿಳುವಳಿಕೆಯಲ್ಲಿ ಮೈಕ್ರೊ ಸರ್ವೀಸ್‌ಗಳು ಈ ಕೆಳಗಿನಂತೆ ಹುಟ್ಟಿಕೊಂಡಿವೆ: 2011 ರಲ್ಲಿ, ಜೇಮ್ಸ್ ಲೂಯಿಸ್, ವಿವಿಧ ಕಂಪನಿಗಳ ಕೆಲಸವನ್ನು ವಿಶ್ಲೇಷಿಸುತ್ತಾ, ಹೊಸ “ಮೈಕ್ರೋ-ಅಪ್ಲಿಕೇಶನ್” ಮಾದರಿಯ ಹೊರಹೊಮ್ಮುವಿಕೆಯತ್ತ ಗಮನ ಸೆಳೆದರು, ಇದು ನಿಯೋಜನೆಯನ್ನು ವೇಗಗೊಳಿಸುವ ದೃಷ್ಟಿಯಿಂದ SOA ಅನ್ನು ಉತ್ತಮಗೊಳಿಸಿತು. ಸೇವೆಗಳು. ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ, 2012 ರಲ್ಲಿ, ಆರ್ಕಿಟೆಕ್ಚರ್ ಶೃಂಗಸಭೆಯಲ್ಲಿ, ಮಾದರಿಯನ್ನು ಮೈಕ್ರೋ ಸರ್ವಿಸ್ ಎಂದು ಮರುನಾಮಕರಣ ಮಾಡಲಾಯಿತು. ಹೀಗಾಗಿ, ಸೂಕ್ಷ್ಮ ಸೇವೆಗಳನ್ನು ಪರಿಚಯಿಸುವ ಆರಂಭಿಕ ಗುರಿಯು ಕುಖ್ಯಾತರನ್ನು ಸುಧಾರಿಸುವುದಾಗಿತ್ತು ಮಾರುಕಟ್ಟೆಗೆ ಸಮಯ.
2015 ರಲ್ಲಿ ಮೈಕ್ರೊ ಸರ್ವೀಸಸ್ ಪ್ರಚೋದನೆಯ ಅಲೆಯಲ್ಲಿತ್ತು. ಕೆಲವು ಅಧ್ಯಯನಗಳ ಪ್ರಕಾರ, ಸೂಕ್ಷ್ಮ ಸೇವೆಗಳ ವಿಷಯದ ಕುರಿತು ವರದಿಯಿಲ್ಲದೆ ಒಂದು ಸಮ್ಮೇಳನವೂ ಪೂರ್ಣಗೊಂಡಿಲ್ಲ. ಇದಲ್ಲದೆ, ಕೆಲವು ಸಮ್ಮೇಳನಗಳು ಮೈಕ್ರೊ ಸರ್ವಿಸ್‌ಗಳಿಗೆ ಪ್ರತ್ಯೇಕವಾಗಿ ಮೀಸಲಾಗಿವೆ. ಇತ್ತೀಚಿನ ದಿನಗಳಲ್ಲಿ, ಅನೇಕ ಯೋಜನೆಗಳು ಈ ವಾಸ್ತುಶಿಲ್ಪದ ಶೈಲಿಯನ್ನು ಬಳಸುವುದನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತವೆ ಮತ್ತು ಯೋಜನೆಯು ಟನ್ಗಳಷ್ಟು ಪರಂಪರೆಯ ಕೋಡ್ ಅನ್ನು ಹೊಂದಿದ್ದರೆ, ನಂತರ ಮೈಕ್ರೋಸರ್ವಿಸ್ಗೆ ವಲಸೆಯನ್ನು ಬಹುಶಃ ಸಕ್ರಿಯವಾಗಿ ಕೈಗೊಳ್ಳಲಾಗುತ್ತದೆ.
ಮೇಲಿನ ಎಲ್ಲಾ ಹೊರತಾಗಿಯೂ, ಸಾಕಷ್ಟು ಕಡಿಮೆ ಸಂಖ್ಯೆಯ ಅಭಿವರ್ಧಕರು ಇನ್ನೂ "ಮೈಕ್ರೋ ಸರ್ವಿಸ್" ಪರಿಕಲ್ಪನೆಯನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಬಹುದು. ಆದರೆ ನಾವು ಈ ಬಗ್ಗೆ ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ ಮಾತನಾಡುತ್ತೇವೆ ...
ಏಕಶಿಲೆ
ಮೈಕ್ರೊ ಸರ್ವಿಸ್‌ಗಳಿಗೆ ವ್ಯತಿರಿಕ್ತವಾಗಿರುವ ವಾಸ್ತುಶಿಲ್ಪದ ಶೈಲಿಯು ಏಕಶಿಲೆಯಾಗಿದೆ (ಅಥವಾ ಆಲ್-ಇನ್-ಒನ್). ಏಕಶಿಲೆ ಏನೆಂದು ಹೇಳಲು ಬಹುಶಃ ಅರ್ಥವಿಲ್ಲ, ಆದ್ದರಿಂದ ನಾನು ಈ ವಾಸ್ತುಶಿಲ್ಪ ಶೈಲಿಯ ಅನಾನುಕೂಲಗಳನ್ನು ತಕ್ಷಣವೇ ಪಟ್ಟಿ ಮಾಡುತ್ತೇನೆ, ಇದು ವಾಸ್ತುಶಿಲ್ಪದ ಶೈಲಿಗಳ ಮತ್ತಷ್ಟು ಅಭಿವೃದ್ಧಿಯನ್ನು ಪ್ರಾರಂಭಿಸಿತು: ಗಾತ್ರ, ಸಂಪರ್ಕ, ನಿಯೋಜನೆ, ಸ್ಕೇಲೆಬಿಲಿಟಿ, ವಿಶ್ವಾಸಾರ್ಹತೆ ಮತ್ತು ಬಿಗಿತ. ಕೆಳಗೆ ನಾನು ಪ್ರತಿಯೊಂದು ನ್ಯೂನತೆಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಗಣಿಸಲು ಪ್ರಸ್ತಾಪಿಸುತ್ತೇನೆ.
ಗಾತ್ರ
ಏಕಶಿಲೆಯು ತುಂಬಾ ದೊಡ್ಡದಾಗಿದೆ. ಮತ್ತು ಇದು ಸಾಮಾನ್ಯವಾಗಿ ದೊಡ್ಡ ಡೇಟಾಬೇಸ್‌ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತದೆ. ಒಬ್ಬ ಡೆವಲಪರ್‌ಗೆ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಅಪ್ಲಿಕೇಶನ್ ತುಂಬಾ ದೊಡ್ಡದಾಗಿದೆ. ಈ ಕೋಡ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು ಸಾಕಷ್ಟು ಸಮಯವನ್ನು ಕಳೆದವರು ಮಾತ್ರ ಏಕಶಿಲೆಯೊಂದಿಗೆ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದು, ಆದರೆ ಆರಂಭಿಕರು ಏಕಶಿಲೆಯನ್ನು ಕಂಡುಹಿಡಿಯಲು ಸಾಕಷ್ಟು ಸಮಯವನ್ನು ಕಳೆಯುತ್ತಾರೆ ಮತ್ತು ಅವರು ಅದನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತಾರೆ ಎಂಬುದಕ್ಕೆ ಯಾವುದೇ ಗ್ಯಾರಂಟಿ ಇಲ್ಲ. ಸಾಮಾನ್ಯವಾಗಿ, ಏಕಶಿಲೆಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ, ಏಕಶಿಲೆಯನ್ನು ಹೆಚ್ಚು ಅಥವಾ ಕಡಿಮೆ ಚೆನ್ನಾಗಿ ತಿಳಿದಿರುವ ಮತ್ತು ಒಂದೂವರೆ ವರ್ಷದೊಳಗೆ ಇತರ ಹೊಸ ಅಭಿವರ್ಧಕರ ಕೈಗಳನ್ನು ಹೊಡೆಯುವ ಕೆಲವು "ಷರತ್ತುಬದ್ಧ" ಹಿರಿಯರು ಯಾವಾಗಲೂ ಇರುತ್ತಾರೆ. ಸ್ವಾಭಾವಿಕವಾಗಿ, ಅಂತಹ ಷರತ್ತುಬದ್ಧ ಹಿರಿಯ ವೈಫಲ್ಯದ ಏಕೈಕ ಹಂತವಾಗಿದೆ, ಮತ್ತು ಅವನ ನಿರ್ಗಮನವು ಏಕಶಿಲೆಯ ಸಾವಿಗೆ ಕಾರಣವಾಗಬಹುದು.
ಸಂಪರ್ಕ
ಏಕಶಿಲೆಯು "ಮಣ್ಣಿನ ದೊಡ್ಡ ಚೆಂಡು", ಇದರಲ್ಲಿ ಬದಲಾವಣೆಗಳು ಅನಿರೀಕ್ಷಿತ ಪರಿಣಾಮಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು. ಒಂದು ಸ್ಥಳದಲ್ಲಿ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡುವ ಮೂಲಕ, ನೀವು ಇನ್ನೊಂದರಲ್ಲಿ ಏಕಶಿಲೆಯನ್ನು ಹಾನಿಗೊಳಿಸಬಹುದು (ಅದೇ "ನೀವು ನಿಮ್ಮ ಕಿವಿಯನ್ನು ಗೀಚಿದ್ದೀರಿ, *@ ಬಿದ್ದವು"). ಏಕಶಿಲೆಯಲ್ಲಿನ ಘಟಕಗಳು ಬಹಳ ಸಂಕೀರ್ಣ ಮತ್ತು ಮುಖ್ಯವಾಗಿ, ಸ್ಪಷ್ಟವಲ್ಲದ ಸಂಬಂಧಗಳನ್ನು ಹೊಂದಿವೆ ಎಂಬ ಅಂಶದಿಂದಾಗಿ ಇದು ಸಂಭವಿಸುತ್ತದೆ.
ನಿಯೋಜನೆ
ಏಕಶಿಲೆಯನ್ನು ನಿಯೋಜಿಸುವುದು, ಅದರ ಘಟಕಗಳ ನಡುವಿನ ಸಂಕೀರ್ಣ ಸಂಬಂಧಗಳ ಕಾರಣದಿಂದಾಗಿ, ತನ್ನದೇ ಆದ ಆಚರಣೆಯೊಂದಿಗೆ ದೀರ್ಘ ಪ್ರಕ್ರಿಯೆಯಾಗಿದೆ. ಅಂತಹ ಆಚರಣೆಯನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಸಂಪೂರ್ಣವಾಗಿ ಪ್ರಮಾಣೀಕರಿಸಲಾಗುವುದಿಲ್ಲ ಮತ್ತು "ಮೌಖಿಕವಾಗಿ" ರವಾನಿಸಲಾಗುತ್ತದೆ.
ಸ್ಕೇಲೆಬಿಲಿಟಿ
ಏಕಶಿಲೆಯ ಮಾಡ್ಯೂಲ್‌ಗಳು ಸಂಘರ್ಷದ ಸಂಪನ್ಮೂಲ ಅಗತ್ಯಗಳನ್ನು ಹೊಂದಿರಬಹುದು, ಹಾರ್ಡ್‌ವೇರ್ ವಿಷಯದಲ್ಲಿ ರಾಜಿ ಮಾಡಿಕೊಳ್ಳುವ ಅಗತ್ಯವಿದೆ. ನೀವು A ಮತ್ತು B ಸೇವೆಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಏಕಶಿಲೆಯನ್ನು ಹೊಂದಿರುವಿರಿ ಎಂದು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ಸೇವೆ A ಹಾರ್ಡ್ ಡ್ರೈವ್‌ನ ಗಾತ್ರದ ಮೇಲೆ ಬೇಡಿಕೆಯಿದೆ ಮತ್ತು ಸೇವೆ B RAM ನಲ್ಲಿ ಬೇಡಿಕೆಯಿದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಏಕಶಿಲೆಯನ್ನು ಸ್ಥಾಪಿಸಿದ ಯಂತ್ರವು ಎರಡೂ ಸೇವೆಗಳ ಅವಶ್ಯಕತೆಗಳನ್ನು ಬೆಂಬಲಿಸಬೇಕು ಅಥವಾ ನೀವು ಸೇವೆಗಳಲ್ಲಿ ಒಂದನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ, ಕೃತಕವಾಗಿ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬೇಕಾಗುತ್ತದೆ.
ಮತ್ತೊಂದು ಉದಾಹರಣೆ (ಹೆಚ್ಚು ಶ್ರೇಷ್ಠ): ಸೇವೆ B ಗಿಂತ ಸೇವೆಯು ಹೆಚ್ಚು ಜನಪ್ರಿಯವಾಗಿದೆ, ಆದ್ದರಿಂದ ನೀವು 100 ಸೇವೆಗಳು A ಮತ್ತು 10 ಸೇವೆಗಳು B ಇರಬೇಕೆಂದು ಬಯಸುತ್ತೀರಿ. ಮತ್ತೆ, ಎರಡು ಆಯ್ಕೆಗಳು: ಒಂದೋ ನಾವು 100 ಪೂರ್ಣ ಪ್ರಮಾಣದ ಏಕಶಿಲೆಗಳನ್ನು ನಿಯೋಜಿಸುತ್ತೇವೆ, ಅಥವಾ ಕೆಲವು ನಂತರ ಸೇವೆಗಳು B ಅನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬೇಕಾಗುತ್ತದೆ.
ವಿಶ್ವಾಸಾರ್ಹತೆ
ಎಲ್ಲಾ ಸೇವೆಗಳು ಒಟ್ಟಿಗೆ ನೆಲೆಗೊಂಡಿರುವುದರಿಂದ, ಏಕಶಿಲೆಯು ಬಿದ್ದರೆ, ನಂತರ ಎಲ್ಲಾ ಸೇವೆಗಳು ಒಂದೇ ಬಾರಿಗೆ ಬೀಳುತ್ತವೆ. ವಾಸ್ತವವಾಗಿ, ಇದು ತುಂಬಾ ಕೆಟ್ಟದ್ದಲ್ಲದಿರಬಹುದು, ಕನಿಷ್ಠ ವಿತರಣಾ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಯಾವುದೇ ಭಾಗಶಃ ವಿಫಲತೆಗಳು ಇರುವುದಿಲ್ಲ, ಆದರೆ ಮತ್ತೊಂದೆಡೆ, 0.001% ಬಳಕೆದಾರರು ಬಳಸುವ ಕಾರ್ಯಚಟುವಟಿಕೆಯಲ್ಲಿನ ದೋಷದಿಂದಾಗಿ, ನೀವು ಎಲ್ಲಾ ಬಳಕೆದಾರರನ್ನು ಕಳೆದುಕೊಳ್ಳಬಹುದು ನಿಮ್ಮ ವ್ಯವಸ್ಥೆಯ.
ಜಡತ್ವ
ಏಕಶಿಲೆಯ ಗಾತ್ರದಿಂದಾಗಿ, ಹೊಸ ತಂತ್ರಜ್ಞಾನಗಳಿಗೆ ಬದಲಾಯಿಸುವುದು ಕಷ್ಟ. ಪರಿಣಾಮವಾಗಿ, ಅದೇ ಹಿರಿಯರನ್ನು ಉಳಿಸಿಕೊಳ್ಳುವುದು ಪ್ರತ್ಯೇಕ ಕಾರ್ಯವಾಗಿದೆ. ಯೋಜನೆಯ ಪ್ರಾರಂಭದಲ್ಲಿ ಆಯ್ಕೆಮಾಡಿದ ತಂತ್ರಜ್ಞಾನದ ಸ್ಟಾಕ್ ಉತ್ಪನ್ನದ ಅಭಿವೃದ್ಧಿಗೆ ಅಡ್ಡಿಯಾಗುವ ಬ್ಲಾಕ್ ಆಗಬಹುದು.
ತೀರ್ಮಾನಕ್ಕೆ
ಮುಂದಿನ ಬಾರಿ ನಾವು ಘಟಕಗಳು ಮತ್ತು SOA ಗೆ ಚಲಿಸುವ ಮೂಲಕ ಈ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಜನರು ಹೇಗೆ ಪ್ರಯತ್ನಿಸಿದ್ದಾರೆ ಎಂಬುದರ ಕುರಿತು ನಾವು ಮಾತನಾಡುತ್ತೇವೆ.
ಮತ್ತಷ್ಟು ಓದು:
ಮೂಲ: www.habr.com