ಏಕಶಿಲೆಯಿಂದ ಸೂಕ್ಷ್ಮ ಸೇವೆಗಳಿಗೆ ಪರಿವರ್ತನೆ: ಇತಿಹಾಸ ಮತ್ತು ಅಭ್ಯಾಸ

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

ಯೋಜನೆಯು ತನ್ನ ಇತಿಹಾಸವನ್ನು ಬಹಳ ಹಿಂದೆಯೇ, 2000 ರ ಆರಂಭದಲ್ಲಿ ಪ್ರಾರಂಭಿಸಿತು. ಮೊದಲ ಆವೃತ್ತಿಗಳನ್ನು ವಿಷುಯಲ್ ಬೇಸಿಕ್ 6 ರಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ. ಕಾಲಾನಂತರದಲ್ಲಿ, ಈ ಭಾಷೆಯಲ್ಲಿ ಅಭಿವೃದ್ಧಿಯನ್ನು ಬೆಂಬಲಿಸಲು ಕಷ್ಟವಾಗುತ್ತದೆ ಎಂದು ಸ್ಪಷ್ಟವಾಯಿತು, ಏಕೆಂದರೆ IDE ಮತ್ತು ಭಾಷೆ ಸ್ವತಃ ಕಳಪೆಯಾಗಿ ಅಭಿವೃದ್ಧಿಗೊಂಡಿದೆ. 2000 ರ ದಶಕದ ಕೊನೆಯಲ್ಲಿ, ಹೆಚ್ಚು ಭರವಸೆಯ C# ಗೆ ಬದಲಾಯಿಸಲು ನಿರ್ಧರಿಸಲಾಯಿತು. ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಹಳೆಯ ಪರಿಷ್ಕರಣೆಯೊಂದಿಗೆ ಸಮಾನಾಂತರವಾಗಿ ಬರೆಯಲಾಗಿದೆ, ಕ್ರಮೇಣ ಹೆಚ್ಚು ಹೆಚ್ಚು ಕೋಡ್ ಅನ್ನು .NET ನಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ. C# ನಲ್ಲಿ ಬ್ಯಾಕೆಂಡ್ ಆರಂಭದಲ್ಲಿ ಸೇವಾ ವಾಸ್ತುಶಿಲ್ಪದ ಮೇಲೆ ಕೇಂದ್ರೀಕೃತವಾಗಿತ್ತು, ಆದರೆ ಅಭಿವೃದ್ಧಿಯ ಸಮಯದಲ್ಲಿ, ತರ್ಕದೊಂದಿಗೆ ಸಾಮಾನ್ಯ ಗ್ರಂಥಾಲಯಗಳನ್ನು ಬಳಸಲಾಯಿತು ಮತ್ತು ಸೇವೆಗಳನ್ನು ಒಂದೇ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಪ್ರಾರಂಭಿಸಲಾಯಿತು. ಫಲಿತಾಂಶವು ನಾವು "ಸೇವಾ ಏಕಶಿಲೆ" ಎಂದು ಕರೆಯುವ ಅಪ್ಲಿಕೇಶನ್ ಆಗಿದೆ.

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

ನಾವು 2015 ರ ಸುಮಾರಿಗೆ ವಿಭಜನೆಯ ಕೆಲಸವನ್ನು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ನಾವು ಇನ್ನೂ ಆದರ್ಶ ಸ್ಥಿತಿಯನ್ನು ತಲುಪಿಲ್ಲ - ಇನ್ನೂ ದೊಡ್ಡ ಯೋಜನೆಯ ಭಾಗಗಳಿವೆ, ಅದನ್ನು ಏಕಶಿಲೆಗಳು ಎಂದು ಕರೆಯಲಾಗುವುದಿಲ್ಲ, ಆದರೆ ಅವು ಮೈಕ್ರೋಸರ್ವಿಸ್‌ಗಳಂತೆ ಕಾಣುವುದಿಲ್ಲ. ಅದೇನೇ ಇದ್ದರೂ, ಪ್ರಗತಿ ಗಮನಾರ್ಹವಾಗಿದೆ.
ನಾನು ಅದರ ಬಗ್ಗೆ ಲೇಖನದಲ್ಲಿ ಮಾತನಾಡುತ್ತೇನೆ.

ಪರಿವಿಡಿ

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

ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪರಿಹಾರದ ವಾಸ್ತುಶಿಲ್ಪ ಮತ್ತು ಸಮಸ್ಯೆಗಳು

ಆರಂಭದಲ್ಲಿ, ವಾಸ್ತುಶಿಲ್ಪವು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ: UI ಒಂದು ಪ್ರತ್ಯೇಕ ಅಪ್ಲಿಕೇಶನ್ ಆಗಿದೆ, ಏಕಶಿಲೆಯ ಭಾಗವನ್ನು ವಿಷುಯಲ್ ಬೇಸಿಕ್ 6 ರಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ, .NET ಅಪ್ಲಿಕೇಶನ್ ಸಾಕಷ್ಟು ದೊಡ್ಡ ಡೇಟಾಬೇಸ್ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಸಂಬಂಧಿತ ಸೇವೆಗಳ ಒಂದು ಗುಂಪಾಗಿದೆ.

ಹಿಂದಿನ ಪರಿಹಾರದ ಅನಾನುಕೂಲಗಳು

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

ಸುಧಾರಣೆಗಳ ಸಾಲು
ಈ ನ್ಯೂನತೆಯು ಸಾಂಸ್ಥಿಕವಾಗಿದೆ. ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನೇಕ ಗ್ರಾಹಕರನ್ನು ಹೊಂದಿದೆ, ಮತ್ತು ಅವರೆಲ್ಲರೂ ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಅದನ್ನು ಸುಧಾರಿಸಲು ಬಯಸುತ್ತಾರೆ. ಹಿಂದೆ, ಇದನ್ನು ಸಮಾನಾಂತರವಾಗಿ ಮಾಡುವುದು ಅಸಾಧ್ಯವಾಗಿತ್ತು, ಮತ್ತು ಎಲ್ಲಾ ಗ್ರಾಹಕರು ಸಾಲಿನಲ್ಲಿ ನಿಂತರು. ಈ ಪ್ರಕ್ರಿಯೆಯು ವ್ಯವಹಾರಗಳಿಗೆ ನಕಾರಾತ್ಮಕವಾಗಿತ್ತು ಏಕೆಂದರೆ ಅವರು ತಮ್ಮ ಕಾರ್ಯವು ಮೌಲ್ಯಯುತವಾಗಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸಬೇಕಾಗಿತ್ತು. ಮತ್ತು ಅಭಿವೃದ್ಧಿ ತಂಡವು ಈ ಸರದಿಯನ್ನು ಸಂಘಟಿಸುವ ಸಮಯವನ್ನು ಕಳೆದರು. ಇದು ಸಾಕಷ್ಟು ಸಮಯ ಮತ್ತು ಶ್ರಮವನ್ನು ತೆಗೆದುಕೊಂಡಿತು, ಮತ್ತು ಉತ್ಪನ್ನವು ಅಂತಿಮವಾಗಿ ಅವರು ಇಷ್ಟಪಟ್ಟಷ್ಟು ತ್ವರಿತವಾಗಿ ಬದಲಾಯಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ.

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

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

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

ಸೂಕ್ಷ್ಮ ಸೇವೆಗಳಿಂದ ನಿರೀಕ್ಷೆಗಳು

ಸಿದ್ಧವಾದಾಗ ಘಟಕಗಳ ಸಂಚಿಕೆ. ದ್ರಾವಣವನ್ನು ಕೊಳೆಯುವ ಮೂಲಕ ಮತ್ತು ವಿಭಿನ್ನ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಬೇರ್ಪಡಿಸುವ ಮೂಲಕ ಸಿದ್ಧವಾದಾಗ ಘಟಕಗಳ ವಿತರಣೆ.

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

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

ನಿಯೋಜನೆ ನಮ್ಯತೆ. ನಾವು ಸೇವೆಗಳನ್ನು ನಮಗೆ ಅಗತ್ಯವಿರುವ ರೀತಿಯಲ್ಲಿ ಸಂಯೋಜಿಸಲು ಬಯಸುತ್ತೇವೆಯೇ ಹೊರತು ಕೋಡ್ ಅದನ್ನು ಒತ್ತಾಯಿಸುವ ರೀತಿಯಲ್ಲಿ ಅಲ್ಲ.

ಹೊಸ ತಂತ್ರಜ್ಞಾನಗಳ ಬಳಕೆ. ಇದು ಯಾವುದೇ ಪ್ರೋಗ್ರಾಮರ್ಗೆ ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ.

ಪರಿವರ್ತನೆಯ ಸಮಸ್ಯೆಗಳು

ಸಹಜವಾಗಿ, ಏಕಶಿಲೆಯನ್ನು ಸೂಕ್ಷ್ಮ ಸೇವೆಗಳಾಗಿ ಮುರಿಯುವುದು ಸುಲಭವಾಗಿದ್ದರೆ, ಸಮ್ಮೇಳನಗಳಲ್ಲಿ ಅದರ ಬಗ್ಗೆ ಮಾತನಾಡಲು ಮತ್ತು ಲೇಖನಗಳನ್ನು ಬರೆಯಲು ಅಗತ್ಯವಿಲ್ಲ. ಈ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಹಲವು ಮೋಸಗಳಿವೆ; ನಮಗೆ ಅಡ್ಡಿಯಾದ ಮುಖ್ಯವಾದವುಗಳನ್ನು ನಾನು ವಿವರಿಸುತ್ತೇನೆ.

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

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

ಮೂರನೇ ಸಮಸ್ಯೆ - ಅಗತ್ಯ ಮೂಲಸೌಕರ್ಯಗಳ ಕೊರತೆ. ವಾಸ್ತವವಾಗಿ, ನಾವು ಮೂಲ ಕೋಡ್ ಅನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಸರ್ವರ್‌ಗಳಿಗೆ ನಕಲಿಸುತ್ತಿದ್ದೇವೆ.

ಏಕಶಿಲೆಯಿಂದ ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗೆ ಹೇಗೆ ಚಲಿಸುವುದು

ಸೂಕ್ಷ್ಮ ಸೇವೆಗಳನ್ನು ಒದಗಿಸುವುದು

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

ಸೂಕ್ಷ್ಮ ಸೇವೆಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು ನಾವು ಯಾವ ವಿಧಾನಗಳನ್ನು ಬಳಸುತ್ತೇವೆ?

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

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

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

namespace RBA.Services.Accounts.Host
{
   internal class Program
   {
      private static void Main(string[] args)
      {
        HostRunner<Accounts>.Run("RBA.Services.Accounts.Host");

       }
    }
}

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

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

ಮೈಕ್ರೋಸರ್ವಿಸ್ ಅನ್ನು ನಿಯೋಜಿಸಲು ಮೂರನೇ ಮಾರ್ಗನಾವು ಬಳಸುವ ಒಂದು ನಮಗೆ ಸ್ವಲ್ಪ ನಿರ್ದಿಷ್ಟವಾಗಿದೆ. ಇದು UI ಲೇಯರ್‌ನಿಂದ ವ್ಯಾಪಾರ ತರ್ಕವನ್ನು ತೆಗೆದುಹಾಕುವುದು. ನಮ್ಮ ಮುಖ್ಯ UI ಅಪ್ಲಿಕೇಶನ್ ಡೆಸ್ಕ್‌ಟಾಪ್ ಆಗಿದೆ; ಇದು ಬ್ಯಾಕೆಂಡ್‌ನಂತೆ C# ನಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ. ಡೆವಲಪರ್‌ಗಳು ನಿಯತಕಾಲಿಕವಾಗಿ ತಪ್ಪುಗಳನ್ನು ಮಾಡಿದ್ದಾರೆ ಮತ್ತು ಬ್ಯಾಕೆಂಡ್‌ನಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದ ಮತ್ತು ಮರುಬಳಕೆ ಮಾಡಬೇಕಾದ ತರ್ಕದ ಭಾಗಗಳನ್ನು UI ಗೆ ವರ್ಗಾಯಿಸಿದರು.

UI ಭಾಗದ ಕೋಡ್‌ನಿಂದ ನೀವು ನಿಜವಾದ ಉದಾಹರಣೆಯನ್ನು ನೋಡಿದರೆ, ಈ ಪರಿಹಾರದ ಹೆಚ್ಚಿನವು ನೈಜ ವ್ಯವಹಾರ ತರ್ಕವನ್ನು ಒಳಗೊಂಡಿರುವುದನ್ನು ನೀವು ನೋಡಬಹುದು, ಅದು UI ಫಾರ್ಮ್ ಅನ್ನು ನಿರ್ಮಿಸಲು ಮಾತ್ರವಲ್ಲದೆ ಇತರ ಪ್ರಕ್ರಿಯೆಗಳಲ್ಲಿ ಉಪಯುಕ್ತವಾಗಿದೆ.

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

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

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

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

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

ವಿತರಿಸಿದ ವಹಿವಾಟುಗಳ ಅಗತ್ಯವಿರುವ ಕೋಡ್ ಅನ್ನು ನಾವು ತಪ್ಪಿಸುವುದಿಲ್ಲ ಎಂದು ನಾವು ದೃಢವಾಗಿ ನಿರ್ಧರಿಸಿದ್ದೇವೆ. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಈ ನಿಯಮವನ್ನು ಅನುಸರಿಸಲು ಇದು ತುಂಬಾ ಸುಲಭವಾಗಿದೆ. ಕಟ್ಟುನಿಟ್ಟಾದ ವಿತರಿಸಿದ ವಹಿವಾಟುಗಳು ನಿಜವಾಗಿಯೂ ಅಗತ್ಯವಿರುವ ಸಂದರ್ಭಗಳನ್ನು ನಾವು ಇನ್ನೂ ಎದುರಿಸಿಲ್ಲ - ಮಾಡ್ಯೂಲ್ಗಳ ನಡುವಿನ ಅಂತಿಮ ಸ್ಥಿರತೆ ಸಾಕಷ್ಟು ಸಾಕಾಗುತ್ತದೆ.

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

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

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

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

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

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

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

ಡೇಟಾಬೇಸ್ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು

ಡೇಟಾಬೇಸ್ ಅನ್ನು ಮೂಲ ಕೋಡ್‌ಗಿಂತ ಕೆಟ್ಟದಾಗಿ ವಿಂಗಡಿಸಬಹುದು, ಏಕೆಂದರೆ ಇದು ಪ್ರಸ್ತುತ ಸ್ಕೀಮಾವನ್ನು ಮಾತ್ರವಲ್ಲದೆ ಸಂಗ್ರಹವಾದ ಐತಿಹಾಸಿಕ ಡೇಟಾವನ್ನು ಸಹ ಒಳಗೊಂಡಿದೆ.

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

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

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

ಡೇಟಾಬೇಸ್ ವಿಭಜನೆಯ ಎರಡು ಜಾಗತಿಕ ವಿಧಾನಗಳನ್ನು ನಾವು ಬಳಸಿದ್ದೇವೆ: ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕೋಷ್ಟಕಗಳ ವಿಭಜನೆ ಮತ್ತು ಸಂಸ್ಕರಣೆಯೊಂದಿಗೆ ವಿಭಜನೆ.

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

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

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

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

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

ನಂತರ ನಾವು ಈ ಸಂಪರ್ಕವನ್ನು ತೆಗೆದುಹಾಕುತ್ತೇವೆ, ಅಂದರೆ, ಬೇರ್ಪಡಿಸಿದ ಕೋಷ್ಟಕಗಳಿಂದ ಏಕಶಿಲೆಯ ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ ಡೇಟಾವನ್ನು ಓದುವುದನ್ನು ಸಹ API ಗೆ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ.

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

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

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

ಈ ಯೋಜನೆಯು ಕಾರ್ಯನಿರ್ವಹಿಸಲು, ನಮಗೆ ಪರಿವರ್ತನೆಯ ಅವಧಿಯ ಅಗತ್ಯವಿರುತ್ತದೆ.

ನಂತರ ಎರಡು ಸಂಭವನೀಯ ವಿಧಾನಗಳಿವೆ.

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

ಎರಡನೆಯದು: ನಾವು ಕೆಲವು ವ್ಯಾಪಾರ ಮಾನದಂಡಗಳ ಪ್ರಕಾರ ಡೇಟಾವನ್ನು ವಿಭಜಿಸುತ್ತೇವೆ. ಉದಾಹರಣೆಗೆ, ಹಳೆಯ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾದ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ನಾವು 5 ಉತ್ಪನ್ನಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ನಾವು ಹೊಸ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಹೊಸ ವ್ಯಾಪಾರ ಕಾರ್ಯದಲ್ಲಿ ಆರನೆಯದನ್ನು ಇರಿಸುತ್ತೇವೆ. ಆದರೆ ನಮಗೆ API ಗೇಟ್‌ವೇ ಅಗತ್ಯವಿರುತ್ತದೆ ಅದು ಈ ಡೇಟಾವನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಕ್ಲೈಂಟ್ ಅನ್ನು ಎಲ್ಲಿ ಮತ್ತು ಏನನ್ನು ಪಡೆಯಬೇಕೆಂದು ತೋರಿಸುತ್ತದೆ.

ಎರಡೂ ವಿಧಾನಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ, ಪರಿಸ್ಥಿತಿಯನ್ನು ಅವಲಂಬಿಸಿ ಆಯ್ಕೆಮಾಡಿ.

ಎಲ್ಲವೂ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ನಮಗೆ ಖಚಿತವಾದ ನಂತರ, ಹಳೆಯ ಡೇಟಾಬೇಸ್ ರಚನೆಗಳೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಏಕಶಿಲೆಯ ಭಾಗವನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬಹುದು.

ಹಳೆಯ ಡೇಟಾ ರಚನೆಗಳನ್ನು ತೆಗೆದುಹಾಕುವುದು ಕೊನೆಯ ಹಂತವಾಗಿದೆ.

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

ಮೂಲ ಕೋಡ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲಾಗುತ್ತಿದೆ

ನಾವು ಏಕಶಿಲೆಯ ಯೋಜನೆಯನ್ನು ವಿಶ್ಲೇಷಿಸಲು ಪ್ರಾರಂಭಿಸಿದಾಗ ಮೂಲ ಕೋಡ್ ರೇಖಾಚಿತ್ರವು ಹೇಗೆ ಕಾಣುತ್ತದೆ.

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

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

ಕೆಲವು ಸಾಮಾನ್ಯ ವಸ್ತುಗಳು ವಾಸ್ತವವಾಗಿ ಈ ಪದರಕ್ಕೆ ಸೇರಿಲ್ಲದಿದ್ದರೂ, ಮೂಲಸೌಕರ್ಯ ಗ್ರಂಥಾಲಯಗಳಾಗಿದ್ದಾಗ ಕೆಲವೊಮ್ಮೆ ಪರಿಸ್ಥಿತಿ ಉದ್ಭವಿಸುತ್ತದೆ. ಮರುಹೆಸರಿಸುವ ಮೂಲಕ ಇದನ್ನು ಪರಿಹರಿಸಲಾಗಿದೆ.

ಅತಿ ದೊಡ್ಡ ಕಾಳಜಿಯೆಂದರೆ ಸೀಮಿತ ಸಂದರ್ಭಗಳು. ಒಂದು ಸಾಮಾನ್ಯ ಅಸೆಂಬ್ಲಿಯಲ್ಲಿ 3-4 ಸಂದರ್ಭಗಳನ್ನು ಬೆರೆಸಲಾಗಿದೆ ಮತ್ತು ಅದೇ ವ್ಯವಹಾರ ಕಾರ್ಯಗಳಲ್ಲಿ ಪರಸ್ಪರ ಬಳಸಲಾಗಿದೆ. ಇದನ್ನು ಎಲ್ಲಿ ವಿಂಗಡಿಸಬಹುದು ಮತ್ತು ಯಾವ ಗಡಿಗಳಲ್ಲಿ ಮತ್ತು ಈ ವಿಭಾಗವನ್ನು ಮೂಲ ಕೋಡ್ ಅಸೆಂಬ್ಲಿಗಳಾಗಿ ಮ್ಯಾಪಿಂಗ್ ಮಾಡುವ ಮೂಲಕ ಮುಂದೆ ಏನು ಮಾಡಬೇಕು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಅಗತ್ಯವಾಗಿತ್ತು.

ಕೋಡ್ ವಿಭಜನೆ ಪ್ರಕ್ರಿಯೆಗಾಗಿ ನಾವು ಹಲವಾರು ನಿಯಮಗಳನ್ನು ರೂಪಿಸಿದ್ದೇವೆ.

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

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

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

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

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

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

ಮೂಲಸೌಕರ್ಯ ಸಮಸ್ಯೆಗಳು

ಮೈಕ್ರೊ ಸರ್ವಿಸ್‌ಗಳಿಗೆ ತೆರಳುವ ಹೆಚ್ಚಿನ ತೊಂದರೆಗಳು ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ಸಂಬಂಧಿಸಿವೆ. ನಿಮಗೆ ಸ್ವಯಂಚಾಲಿತ ನಿಯೋಜನೆಯ ಅಗತ್ಯವಿದೆ, ಮೂಲಸೌಕರ್ಯವನ್ನು ಚಲಾಯಿಸಲು ನಿಮಗೆ ಹೊಸ ಗ್ರಂಥಾಲಯಗಳ ಅಗತ್ಯವಿದೆ.

ಪರಿಸರದಲ್ಲಿ ಹಸ್ತಚಾಲಿತ ಸ್ಥಾಪನೆ

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

ನಾವು ಮೂಲ ಕೋಡ್ ಸಂಗ್ರಹಣೆಗಾಗಿ ಅಟ್ಲಾಸಿಯನ್, ಬಿಟ್‌ಬಕೆಟ್ ಮತ್ತು ಕಟ್ಟಡಕ್ಕಾಗಿ ಬಿದಿರನ್ನು ಬಳಸುತ್ತೇವೆ. ನಾವು ಕೇಕ್‌ನಲ್ಲಿ ಬಿಲ್ಡ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಬರೆಯಲು ಇಷ್ಟಪಡುತ್ತೇವೆ ಏಕೆಂದರೆ ಅದು C# ನಂತೆಯೇ ಇರುತ್ತದೆ. ರೆಡಿಮೇಡ್ ಪ್ಯಾಕೇಜುಗಳು ಆರ್ಟಿಫ್ಯಾಕ್ಟರಿಗೆ ಬರುತ್ತವೆ ಮತ್ತು ಅನ್ಸಿಬಲ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪರೀಕ್ಷಾ ಸರ್ವರ್‌ಗಳಿಗೆ ಸಿಗುತ್ತದೆ, ನಂತರ ಅವುಗಳನ್ನು ತಕ್ಷಣವೇ ಪರೀಕ್ಷಿಸಬಹುದು.

ಪ್ರತ್ಯೇಕ ಲಾಗಿಂಗ್

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

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

ಸಂಬಂಧಿತ ಸೇವೆಗಳನ್ನು ಪರೀಕ್ಷಿಸುವುದು ಮತ್ತು ಡೀಬಗ್ ಮಾಡುವುದು

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

ಸೇವೆಗಳ ಉತ್ಪಾದನಾ ಆವೃತ್ತಿಗಳನ್ನು ಮಾತ್ರ ಚಲಾಯಿಸುವ ಸರ್ವರ್‌ಗಳಿವೆ. ಘಟನೆಗಳ ಸಂದರ್ಭದಲ್ಲಿ, ನಿಯೋಜನೆಯ ಮೊದಲು ವಿತರಣೆಯನ್ನು ಪರಿಶೀಲಿಸಲು ಮತ್ತು ಆಂತರಿಕ ತರಬೇತಿಗಾಗಿ ಈ ಸರ್ವರ್‌ಗಳು ಅಗತ್ಯವಿದೆ.

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

ಹೆಚ್ಚುವರಿಯಾಗಿ, ಲೋಡ್ ಪರೀಕ್ಷೆಯ ಅಗತ್ಯವು ಹೆಚ್ಚಾಗಿದೆ; ಹಿಂದೆ ಇದನ್ನು ಅಪರೂಪದ ಸಂದರ್ಭಗಳಲ್ಲಿ ಮಾತ್ರ ನಡೆಸಲಾಗುತ್ತಿತ್ತು. ನಾವು ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸಲು JMeter ಅನ್ನು ಬಳಸುತ್ತೇವೆ, ಅವುಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು InfluxDB ಮತ್ತು ಪ್ರಕ್ರಿಯೆ ಗ್ರಾಫ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಲು Grafana ಅನ್ನು ಬಳಸುತ್ತೇವೆ.

ನಾವೇನು ​​ಸಾಧಿಸಿದ್ದೇವೆ?

ಮೊದಲನೆಯದಾಗಿ, ನಾವು "ಬಿಡುಗಡೆ" ಎಂಬ ಪರಿಕಲ್ಪನೆಯನ್ನು ತೊಡೆದುಹಾಕಿದ್ದೇವೆ. ಈ ಕೊಲೊಸಸ್ ಅನ್ನು ಉತ್ಪಾದನಾ ಪರಿಸರದಲ್ಲಿ ನಿಯೋಜಿಸಿದಾಗ ಎರಡು ತಿಂಗಳ ದೈತ್ಯಾಕಾರದ ಬಿಡುಗಡೆಗಳು ಕಳೆದುಹೋಗಿವೆ, ವ್ಯಾಪಾರ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ತಾತ್ಕಾಲಿಕವಾಗಿ ಅಡ್ಡಿಪಡಿಸುತ್ತದೆ. ಈಗ ನಾವು ಪ್ರತಿ 1,5 ದಿನಗಳಿಗೊಮ್ಮೆ ಸರಾಸರಿಯಾಗಿ ಸೇವೆಗಳನ್ನು ನಿಯೋಜಿಸುತ್ತೇವೆ, ಅನುಮೋದನೆಯ ನಂತರ ಅವು ಕಾರ್ಯಾಚರಣೆಗೆ ಹೋಗುವುದರಿಂದ ಅವುಗಳನ್ನು ಗುಂಪು ಮಾಡುತ್ತೇವೆ.

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

ನಾವು ನಿಯೋಜನೆ ಮಾದರಿಯನ್ನು ನಿಯಂತ್ರಿಸಬಹುದು. ಅಗತ್ಯವಿದ್ದರೆ, ಉಳಿದ ಪರಿಹಾರದಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಸೇವೆಗಳ ಗುಂಪುಗಳನ್ನು ನೀವು ಆಯ್ಕೆ ಮಾಡಬಹುದು.

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

ಸಾರಾಂಶ

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

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

  PS ಹೆಚ್ಚು ಭಾವನಾತ್ಮಕ ಕಥೆ (ಮತ್ತು ವೈಯಕ್ತಿಕವಾಗಿ ನಿಮಗಾಗಿ) - ಪ್ರಕಾರ ಲಿಂಕ್.
  ವರದಿಯ ಪೂರ್ಣ ಆವೃತ್ತಿ ಇಲ್ಲಿದೆ.

ಮೂಲ: www.habr.com