ಸರ್ವಿಸ್ ಮೆಶ್ ಮೈಕ್ರೊ ಸರ್ವೀಸ್‌ಗಳನ್ನು ಸಂಯೋಜಿಸಲು ಮತ್ತು ಕ್ಲೌಡ್ ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ವಲಸೆ ಹೋಗಲು ಪ್ರಸಿದ್ಧವಾದ ವಾಸ್ತುಶಿಲ್ಪದ ಮಾದರಿಯಾಗಿದೆ. ಇಂದು ಕ್ಲೌಡ್-ಕಂಟೇನರ್ ಜಗತ್ತಿನಲ್ಲಿ ಅದು ಇಲ್ಲದೆ ಮಾಡುವುದು ತುಂಬಾ ಕಷ್ಟ. ಹಲವಾರು ತೆರೆದ ಮೂಲ ಸೇವಾ ಜಾಲರಿ ಅಳವಡಿಕೆಗಳು ಮಾರುಕಟ್ಟೆಯಲ್ಲಿ ಈಗಾಗಲೇ ಲಭ್ಯವಿವೆ, ಆದರೆ ಅವುಗಳ ಕಾರ್ಯಶೀಲತೆ, ವಿಶ್ವಾಸಾರ್ಹತೆ ಮತ್ತು ಭದ್ರತೆ ಯಾವಾಗಲೂ ಸಾಕಾಗುವುದಿಲ್ಲ, ವಿಶೇಷವಾಗಿ ದೇಶಾದ್ಯಂತದ ದೊಡ್ಡ ಹಣಕಾಸು ಕಂಪನಿಗಳ ಅವಶ್ಯಕತೆಗಳಿಗೆ ಬಂದಾಗ. ಅದಕ್ಕಾಗಿಯೇ ನಾವು Sbertech ನಲ್ಲಿ ಸೇವೆ ಮೆಶ್ ಅನ್ನು ಕಸ್ಟಮೈಸ್ ಮಾಡಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ ಮತ್ತು ಸೇವಾ ಮೆಶ್ ಬಗ್ಗೆ ಏನು ತಂಪಾಗಿದೆ, ಯಾವುದು ತುಂಬಾ ತಂಪಾಗಿಲ್ಲ ಮತ್ತು ಅದರ ಬಗ್ಗೆ ನಾವು ಏನು ಮಾಡಲಿದ್ದೇವೆ ಎಂಬುದರ ಕುರಿತು ಮಾತನಾಡಲು ಬಯಸುತ್ತೇವೆ.
ಕ್ಲೌಡ್ ತಂತ್ರಜ್ಞಾನಗಳ ಜನಪ್ರಿಯತೆಯೊಂದಿಗೆ ಸೇವಾ ಮೆಶ್ ಮಾದರಿಯ ಜನಪ್ರಿಯತೆಯು ಬೆಳೆಯುತ್ತಿದೆ. ಇದು ವಿವಿಧ ನೆಟ್ವರ್ಕ್ ಸೇವೆಗಳ ನಡುವಿನ ಪರಸ್ಪರ ಕ್ರಿಯೆಯನ್ನು ಸರಳಗೊಳಿಸುವ ಮೀಸಲಾದ ಮೂಲಸೌಕರ್ಯ ಪದರವಾಗಿದೆ. ಆಧುನಿಕ ಕ್ಲೌಡ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ನೂರಾರು ಅಥವಾ ಸಾವಿರಾರು ಸೇವೆಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ, ಪ್ರತಿಯೊಂದೂ ಸಾವಿರಾರು ಪ್ರತಿಗಳನ್ನು ಹೊಂದಬಹುದು.
ಈ ಸೇವೆಗಳ ನಡುವಿನ ಸಂವಹನ ಮತ್ತು ನಿರ್ವಹಣೆಯು ಸೇವಾ ಮೆಶ್‌ನ ಪ್ರಮುಖ ಕಾರ್ಯವಾಗಿದೆ. ವಾಸ್ತವವಾಗಿ, ಇದು ಅನೇಕ ಪ್ರಾಕ್ಸಿಗಳ ನೆಟ್ವರ್ಕ್ ಮಾದರಿಯಾಗಿದೆ, ಕೇಂದ್ರೀಯವಾಗಿ ನಿರ್ವಹಿಸಲ್ಪಡುತ್ತದೆ ಮತ್ತು ಬಹಳ ಉಪಯುಕ್ತ ಕಾರ್ಯಗಳ ಗುಂಪನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ.
ಪ್ರಾಕ್ಸಿ ಮಟ್ಟದಲ್ಲಿ (ಡೇಟಾ ಪ್ಲೇನ್):
- ರೂಟಿಂಗ್ ಮತ್ತು ಟ್ರಾಫಿಕ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ನೀತಿಗಳನ್ನು ನಿಯೋಜಿಸುವುದು ಮತ್ತು ವಿತರಿಸುವುದು
- ಕೀಗಳು, ಪ್ರಮಾಣಪತ್ರಗಳು, ಟೋಕನ್ಗಳ ವಿತರಣೆ
- ಟೆಲಿಮೆಟ್ರಿಯ ಸಂಗ್ರಹ, ಮಾನಿಟರಿಂಗ್ ಮೆಟ್ರಿಕ್‌ಗಳ ಉತ್ಪಾದನೆ
- ಭದ್ರತೆ ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆ ಮೂಲಸೌಕರ್ಯದೊಂದಿಗೆ ಏಕೀಕರಣ
ನಿಯಂತ್ರಣ ಸಮತಲ ಮಟ್ಟದಲ್ಲಿ:
- ರೂಟಿಂಗ್ ಮತ್ತು ಟ್ರಾಫಿಕ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ನೀತಿಗಳನ್ನು ಅನ್ವಯಿಸುವುದು
- ಮರುಪ್ರಯತ್ನಗಳು ಮತ್ತು ಸಮಯ ಮೀರುವಿಕೆಗಳನ್ನು ನಿರ್ವಹಿಸುವುದು, "ಡೆಡ್" ನೋಡ್‌ಗಳನ್ನು ಪತ್ತೆಹಚ್ಚುವುದು (ಸರ್ಕ್ಯೂಟ್ ಬ್ರೇಕಿಂಗ್), ಇಂಜೆಕ್ಷನ್ ದೋಷಗಳನ್ನು ನಿರ್ವಹಿಸುವುದು ಮತ್ತು ಇತರ ಕಾರ್ಯವಿಧಾನಗಳ ಮೂಲಕ ಸೇವಾ ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವವನ್ನು ಖಾತ್ರಿಪಡಿಸುವುದು
- ಕರೆ ಪ್ರಮಾಣೀಕರಣ/ಅಧಿಕಾರ
- ಡ್ರಾಪಿಂಗ್ ಮೆಟ್ರಿಕ್ಸ್ (ವೀಕ್ಷಣೆ)
ಈ ತಂತ್ರಜ್ಞಾನದ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಆಸಕ್ತಿ ಹೊಂದಿರುವ ಬಳಕೆದಾರರ ವ್ಯಾಪ್ತಿಯು ತುಂಬಾ ವಿಸ್ತಾರವಾಗಿದೆ - ಸಣ್ಣ ಪ್ರಾರಂಭದಿಂದ ದೊಡ್ಡ ಇಂಟರ್ನೆಟ್ ನಿಗಮಗಳಿಗೆ, ಉದಾಹರಣೆಗೆ, ಪೇಪಾಲ್.
ಕಾರ್ಪೊರೇಟ್ ವಲಯದಲ್ಲಿ ಸೇವಾ ಮೆಶ್ ಏಕೆ ಬೇಕು?
ಸೇವಾ ಮೆಶ್ ಅನ್ನು ಬಳಸುವುದರಿಂದ ಅನೇಕ ಸ್ಪಷ್ಟ ಪ್ರಯೋಜನಗಳಿವೆ. ಮೊದಲನೆಯದಾಗಿ, ಡೆವಲಪರ್‌ಗಳಿಗೆ ಇದು ಸರಳವಾಗಿ ಅನುಕೂಲಕರವಾಗಿದೆ: ಕೋಡ್ ಬರೆಯಲು ತಂತ್ರಜ್ಞಾನ ವೇದಿಕೆ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಇದು ಸಾರಿಗೆ ಪದರವು ಅಪ್ಲಿಕೇಶನ್ ತರ್ಕದಿಂದ ಸಂಪೂರ್ಣವಾಗಿ ಪ್ರತ್ಯೇಕಿಸಲ್ಪಟ್ಟಿದೆ ಎಂಬ ಕಾರಣದಿಂದಾಗಿ ಕ್ಲೌಡ್ ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ಏಕೀಕರಣವನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಸರಳಗೊಳಿಸುತ್ತದೆ.
ಇದಲ್ಲದೆ, ಸೇವೆ ಮೆಶ್ ಪೂರೈಕೆದಾರರು ಮತ್ತು ಗ್ರಾಹಕರ ನಡುವಿನ ಸಂಬಂಧವನ್ನು ಸರಳಗೊಳಿಸುತ್ತದೆ. ಇಂದು, ವಿಶೇಷ ಏಕೀಕರಣ ಮಧ್ಯವರ್ತಿ ಮತ್ತು ಮಧ್ಯವರ್ತಿ - ಎಂಟರ್‌ಪ್ರೈಸ್ ಸರ್ವಿಸ್ ಬಸ್ ಅನ್ನು ಒಳಗೊಳ್ಳದೆ, ಎಪಿಐ ಪೂರೈಕೆದಾರರು ಮತ್ತು ಗ್ರಾಹಕರು ತಮ್ಮದೇ ಆದ ಇಂಟರ್‌ಫೇಸ್‌ಗಳು ಮತ್ತು ಒಪ್ಪಂದಗಳನ್ನು ಒಪ್ಪಿಕೊಳ್ಳುವುದು ತುಂಬಾ ಸುಲಭ. ಈ ವಿಧಾನವು ಎರಡು ಸೂಚಕಗಳನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. ಹೊಸ ಕಾರ್ಯವನ್ನು ಮಾರುಕಟ್ಟೆಗೆ ತರುವ ವೇಗ (ಸಮಯದಿಂದ ಮಾರುಕಟ್ಟೆಗೆ) ಹೆಚ್ಚಾಗುತ್ತದೆ, ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ ಪರಿಹಾರದ ವೆಚ್ಚವು ಹೆಚ್ಚಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಏಕೀಕರಣವನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ಮಾಡಬೇಕಾಗಿದೆ. ವ್ಯಾಪಾರ ಕಾರ್ಯನಿರ್ವಹಣೆಯ ಅಭಿವೃದ್ಧಿ ತಂಡಗಳಿಂದ ಸೇವಾ ಮೆಶ್ ಬಳಕೆಯು ಇಲ್ಲಿ ಸಮತೋಲನವನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಪರಿಣಾಮವಾಗಿ, API ಪೂರೈಕೆದಾರರು ತಮ್ಮ ಸೇವೆಯ ಅಪ್ಲಿಕೇಶನ್ ಘಟಕದ ಮೇಲೆ ಪ್ರತ್ಯೇಕವಾಗಿ ಗಮನಹರಿಸಬಹುದು ಮತ್ತು ಅದನ್ನು ಸೇವಾ ಮೆಶ್‌ನಲ್ಲಿ ಸರಳವಾಗಿ ಪ್ರಕಟಿಸಬಹುದು - API ತಕ್ಷಣವೇ ಎಲ್ಲಾ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಲಭ್ಯವಾಗುತ್ತದೆ ಮತ್ತು ಏಕೀಕರಣದ ಗುಣಮಟ್ಟವು ಉತ್ಪಾದನೆಗೆ ಸಿದ್ಧವಾಗುತ್ತದೆ ಮತ್ತು ಒಂದೇ ಅಗತ್ಯವಿರುವುದಿಲ್ಲ ಹೆಚ್ಚುವರಿ ಕೋಡ್ ಸಾಲು.
ಮುಂದಿನ ಅನುಕೂಲವೆಂದರೆ ಅದು ಡೆವಲಪರ್, ಸರ್ವಿಸ್ ಮೆಶ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು, ವ್ಯಾಪಾರದ ಕಾರ್ಯನಿರ್ವಹಣೆಯ ಮೇಲೆ ಮಾತ್ರ ಕೇಂದ್ರೀಕರಿಸುತ್ತಾರೆ - ಅದರ ಸೇವೆಯ ತಾಂತ್ರಿಕ ಅಂಶಕ್ಕಿಂತ ಉತ್ಪನ್ನದ ಮೇಲೆ. ಉದಾಹರಣೆಗೆ, ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಸೇವೆಯನ್ನು ಕರೆಯುವ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ, ಸಂಪರ್ಕ ವೈಫಲ್ಯವು ಎಲ್ಲೋ ಸಂಭವಿಸಬಹುದು ಎಂಬ ಅಂಶವನ್ನು ನೀವು ಇನ್ನು ಮುಂದೆ ಯೋಚಿಸಬೇಕಾಗಿಲ್ಲ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಸೇವೆಯ ಮೆಶ್ ಅದೇ ಸೇವೆಯ ನಕಲುಗಳ ನಡುವೆ ದಟ್ಟಣೆಯನ್ನು ಸಮತೋಲನಗೊಳಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ: ಒಂದು ನಕಲು "ಸಾಯಿದರೆ", ಸಿಸ್ಟಮ್ ಎಲ್ಲಾ ದಟ್ಟಣೆಯನ್ನು ಉಳಿದ ಲೈವ್ ಪ್ರತಿಗಳಿಗೆ ಬದಲಾಯಿಸುತ್ತದೆ.
ಸೇವೆ ಮೆಶ್ - ವಿತರಿಸಿದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ರಚಿಸಲು ಇದು ಉತ್ತಮ ಆಧಾರವಾಗಿದೆ, ಇದು ತನ್ನ ಸೇವೆಗಳಿಗೆ ಆಂತರಿಕವಾಗಿ ಮತ್ತು ಬಾಹ್ಯವಾಗಿ ಕರೆಗಳನ್ನು ಒದಗಿಸುವ ವಿವರಗಳನ್ನು ಕ್ಲೈಂಟ್‌ನಿಂದ ಮರೆಮಾಡುತ್ತದೆ. ಸರ್ವಿಸ್ ಮೆಶ್ ಅನ್ನು ಬಳಸುವ ಎಲ್ಲಾ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ ಮತ್ತು ಪರಸ್ಪರ ಸಾರಿಗೆ ಮಟ್ಟದಲ್ಲಿ ಪ್ರತ್ಯೇಕವಾಗಿರುತ್ತವೆ: ಅವುಗಳ ನಡುವೆ ಯಾವುದೇ ಸಂವಹನವಿಲ್ಲ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಡೆವಲಪರ್ ತನ್ನ ಸೇವೆಗಳ ಮೇಲೆ ಸಂಪೂರ್ಣ ನಿಯಂತ್ರಣವನ್ನು ಪಡೆಯುತ್ತಾನೆ.
ಎಂಬುದನ್ನು ಗಮನಿಸಬೇಕು ಸೇವಾ ಜಾಲರಿ ಪರಿಸರದಲ್ಲಿ ವಿತರಿಸಿದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನವೀಕರಿಸುವುದು ಸುಲಭವಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಒಂದು ನೀಲಿ/ಹಸಿರು ನಿಯೋಜನೆ, ಇದರಲ್ಲಿ ಅನುಸ್ಥಾಪನೆಗೆ ಎರಡು ಅಪ್ಲಿಕೇಶನ್ ಪರಿಸರಗಳು ಲಭ್ಯವಿವೆ, ಅದರಲ್ಲಿ ಒಂದನ್ನು ನವೀಕರಿಸಲಾಗಿಲ್ಲ ಮತ್ತು ಸ್ಟ್ಯಾಂಡ್‌ಬೈ ಮೋಡ್‌ನಲ್ಲಿದೆ. ವಿಫಲವಾದ ಬಿಡುಗಡೆಯ ಸಂದರ್ಭದಲ್ಲಿ ಹಿಂದಿನ ಆವೃತ್ತಿಗೆ ಹಿಂತಿರುಗುವುದು ವಿಶೇಷ ರೂಟರ್ ಮೂಲಕ ನಡೆಸಲ್ಪಡುತ್ತದೆ, ಅದರ ಪಾತ್ರವನ್ನು ಸೇವೆ ಮೆಶ್ ಚೆನ್ನಾಗಿ ನಿಭಾಯಿಸುತ್ತದೆ. ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಪರೀಕ್ಷಿಸಲು, ನೀವು ಬಳಸಬಹುದು ಕ್ಯಾನರಿ ಬಿಡುಗಡೆ — ಕ್ಲೈಂಟ್‌ಗಳ ಪೈಲಟ್ ಗುಂಪಿನಿಂದ 10% ಟ್ರಾಫಿಕ್ ಅಥವಾ ವಿನಂತಿಗಳನ್ನು ಮಾತ್ರ ಹೊಸ ಆವೃತ್ತಿಗೆ ಬದಲಿಸಿ. ಮುಖ್ಯ ಸಂಚಾರವು ಹಳೆಯ ಆವೃತ್ತಿಗೆ ಹೋಗುತ್ತದೆ, ಏನೂ ಒಡೆಯುವುದಿಲ್ಲ.
ಸಹ ಸೇವೆ ಮೆಶ್ ನಮಗೆ ನೈಜ-ಸಮಯದ SLA ನಿಯಂತ್ರಣವನ್ನು ನೀಡುತ್ತದೆ. ಕ್ಲೈಂಟ್‌ಗಳಲ್ಲಿ ಒಬ್ಬರು ಅದಕ್ಕೆ ನಿಯೋಜಿಸಲಾದ ಕೋಟಾವನ್ನು ಮೀರಿದಾಗ ವಿತರಿಸಿದ ಪ್ರಾಕ್ಸಿ ಸಿಸ್ಟಮ್ ಸೇವೆಯನ್ನು ವಿಫಲಗೊಳಿಸಲು ಅನುಮತಿಸುವುದಿಲ್ಲ. API ಥ್ರೋಪುಟ್ ಸೀಮಿತವಾಗಿದ್ದರೆ, ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ವಹಿವಾಟುಗಳೊಂದಿಗೆ ಅದನ್ನು ಮುಳುಗಿಸಲು ಯಾರಿಗೂ ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ: ಸೇವೆಯ ಮೆಶ್ ಸೇವೆಯ ಮುಂದೆ ನಿಂತಿದೆ ಮತ್ತು ಅನಗತ್ಯ ಸಂಚಾರವನ್ನು ಅನುಮತಿಸುವುದಿಲ್ಲ. ಇದು ಏಕೀಕರಣ ಪದರದಲ್ಲಿ ಸರಳವಾಗಿ ಹೋರಾಡುತ್ತದೆ ಮತ್ತು ಸೇವೆಗಳು ಅದನ್ನು ಗಮನಿಸದೆ ಕೆಲಸ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತವೆ.
ಕಂಪನಿಯು ಏಕೀಕರಣ ಪರಿಹಾರಗಳ ಅಭಿವೃದ್ಧಿಗೆ ವೆಚ್ಚವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಬಯಸಿದರೆ, ಸೇವಾ ಮೆಶ್ ಸಹ ಸಹಾಯ ಮಾಡುತ್ತದೆ: ನೀವು ವಾಣಿಜ್ಯ ಉತ್ಪನ್ನಗಳಿಂದ ಅದರ ತೆರೆದ ಮೂಲ ಆವೃತ್ತಿಗೆ ಬದಲಾಯಿಸಬಹುದು. ನಮ್ಮ ಎಂಟರ್‌ಪ್ರೈಸ್ ಸೇವಾ ಮೆಶ್ ಸೇವಾ ಮೆಶ್‌ನ ಓಪನ್ ಸೋರ್ಸ್ ಆವೃತ್ತಿಯನ್ನು ಆಧರಿಸಿದೆ.
ಇನ್ನೊಂದು ಅನುಕೂಲ - ಏಕೀಕರಣ ಸೇವೆಗಳ ಏಕ ಪೂರ್ಣ ಪ್ರಮಾಣದ ಲಭ್ಯತೆ. ಎಲ್ಲಾ ಏಕೀಕರಣವನ್ನು ಈ ಮಿಡಲ್‌ವೇರ್ ಮೂಲಕ ನಿರ್ಮಿಸಲಾಗಿದೆಯಾದ್ದರಿಂದ, ಕಂಪನಿಯ ವ್ಯಾಪಾರ ಕೇಂದ್ರವನ್ನು ರೂಪಿಸುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ನಡುವಿನ ಎಲ್ಲಾ ಏಕೀಕರಣ ಟ್ರಾಫಿಕ್ ಮತ್ತು ಸಂಪರ್ಕಗಳನ್ನು ನಾವು ನಿರ್ವಹಿಸಬಹುದು. ಇದು ತುಂಬಾ ಆರಾಮದಾಯಕವಾಗಿದೆ.
ಮತ್ತು ಅಂತಿಮವಾಗಿ ಸೇವಾ ಮೆಶ್ ಕಂಪನಿಯನ್ನು ಡೈನಾಮಿಕ್ ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ಸರಿಸಲು ಪ್ರೋತ್ಸಾಹಿಸುತ್ತದೆ. ಈಗ ಹಲವರು ಕಂಟೈನರೈಸೇಶನ್ ಕಡೆಗೆ ನೋಡುತ್ತಿದ್ದಾರೆ. ಏಕಶಿಲೆಯನ್ನು ಸೂಕ್ಷ್ಮ ಸೇವೆಗಳಾಗಿ ಕತ್ತರಿಸುವುದು, ಇದೆಲ್ಲವನ್ನೂ ಸುಂದರವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸುವುದು - ವಿಷಯವು ಹೆಚ್ಚುತ್ತಿದೆ. ಆದರೆ ನೀವು ಅನೇಕ ವರ್ಷಗಳಿಂದ ಉತ್ಪಾದನೆಯಲ್ಲಿರುವ ವ್ಯವಸ್ಥೆಯನ್ನು ಹೊಸ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗೆ ವರ್ಗಾಯಿಸಲು ಪ್ರಯತ್ನಿಸಿದಾಗ, ನೀವು ತಕ್ಷಣವೇ ಹಲವಾರು ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸುತ್ತೀರಿ: ಎಲ್ಲವನ್ನೂ ಕಂಟೇನರ್‌ಗಳಿಗೆ ತಳ್ಳುವುದು ಮತ್ತು ಅದನ್ನು ವೇದಿಕೆಯಲ್ಲಿ ನಿಯೋಜಿಸುವುದು ಸುಲಭವಲ್ಲ. ಮತ್ತು ಈ ವಿತರಿಸಿದ ಘಟಕಗಳ ಅನುಷ್ಠಾನ, ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಮತ್ತು ಪರಸ್ಪರ ಕ್ರಿಯೆಯು ಮತ್ತೊಂದು ಸಂಕೀರ್ಣ ವಿಷಯವಾಗಿದೆ. ಅವರು ಪರಸ್ಪರ ಹೇಗೆ ಸಂವಹನ ನಡೆಸುತ್ತಾರೆ? ಕ್ಯಾಸ್ಕೇಡಿಂಗ್ ವೈಫಲ್ಯಗಳು ಇರುತ್ತವೆಯೇ? ಸೇವೆ ಮೆಶ್ ಈ ಕೆಲವು ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ ಮತ್ತು ಹಳೆಯ ವಾಸ್ತುಶಿಲ್ಪದಿಂದ ಹೊಸದಕ್ಕೆ ವಲಸೆಯನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತದೆ ಏಕೆಂದರೆ ನೀವು ನೆಟ್ವರ್ಕ್ ವಿನಿಮಯ ತರ್ಕವನ್ನು ಮರೆತುಬಿಡಬಹುದು.
ನಿಮಗೆ ಸೇವಾ ಮೆಶ್ ಗ್ರಾಹಕೀಕರಣ ಏಕೆ ಬೇಕು?
ನಮ್ಮ ಕಂಪನಿಯಲ್ಲಿ, ನೂರಾರು ಸಿಸ್ಟಮ್‌ಗಳು ಮತ್ತು ಮಾಡ್ಯೂಲ್‌ಗಳು ಸಹಬಾಳ್ವೆ ನಡೆಸುತ್ತವೆ ಮತ್ತು ರನ್‌ಟೈಮ್ ತುಂಬಾ ಲೋಡ್ ಆಗಿದೆ. ಆದ್ದರಿಂದ ಒಂದು ವ್ಯವಸ್ಥೆಯು ಇನ್ನೊಂದನ್ನು ಕರೆಯುವ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ವೀಕರಿಸುವ ಸರಳ ಮಾದರಿಯು ಸಾಕಾಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಉತ್ಪಾದನೆಯಲ್ಲಿ ನಾವು ಹೆಚ್ಚಿನದನ್ನು ಬಯಸುತ್ತೇವೆ. ಎಂಟರ್‌ಪ್ರೈಸ್ ಸೇವಾ ಜಾಲರಿಯಿಂದ ನಿಮಗೆ ಇನ್ನೇನು ಬೇಕು?
ಈವೆಂಟ್ ಪ್ರಕ್ರಿಯೆ ಸೇವೆ
ನಾವು ನೈಜ-ಸಮಯದ ಈವೆಂಟ್ ಸಂಸ್ಕರಣೆಯನ್ನು ಮಾಡಬೇಕಾಗಿದೆ ಎಂದು ಊಹಿಸೋಣ - ಕ್ಲೈಂಟ್‌ನ ಕ್ರಿಯೆಗಳನ್ನು ನೈಜ ಸಮಯದಲ್ಲಿ ವಿಶ್ಲೇಷಿಸುವ ವ್ಯವಸ್ಥೆ ಮತ್ತು ತಕ್ಷಣವೇ ಅವನಿಗೆ ಸಂಬಂಧಿತ ಕೊಡುಗೆಯನ್ನು ನೀಡಬಹುದು. ಇದೇ ರೀತಿಯ ಕಾರ್ಯವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು, ಬಳಸಿ ಈವೆಂಟ್-ಡ್ರೈವ್ ಆರ್ಕಿಟೆಕ್ಚರ್ (EDA) ಎಂದು ಕರೆಯಲ್ಪಡುವ ವಾಸ್ತುಶಿಲ್ಪದ ಮಾದರಿ. ಪ್ರಸ್ತುತ ಯಾವುದೇ ಸೇವಾ ಮೆಶ್‌ಗಳು ಸ್ಥಳೀಯವಾಗಿ ಅಂತಹ ಮಾದರಿಗಳನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ, ಆದರೆ ಇದು ಬಹಳ ಮುಖ್ಯವಾಗಿದೆ, ವಿಶೇಷವಾಗಿ ಬ್ಯಾಂಕ್‌ಗೆ!
ರಿಮೋಟ್ ಪ್ರೊಸೀಜರ್ ಕಾಲ್ (RPC) ಅನ್ನು ಸರ್ವಿಸ್ ಮೆಶ್‌ನ ಎಲ್ಲಾ ಆವೃತ್ತಿಗಳು ಬೆಂಬಲಿಸುತ್ತವೆ ಎಂಬುದು ವಿಚಿತ್ರವಾಗಿದೆ, ಆದರೆ ಅವು EDA ಯೊಂದಿಗೆ ಸ್ನೇಹಪರವಾಗಿಲ್ಲ. ಏಕೆಂದರೆ ಸರ್ವಿಸ್ ಮೆಶ್ ಒಂದು ರೀತಿಯ ಆಧುನಿಕ ವಿತರಣಾ ಏಕೀಕರಣವಾಗಿದೆ, ಮತ್ತು EDA ಎನ್ನುವುದು ಗ್ರಾಹಕರ ಅನುಭವದ ವಿಷಯದಲ್ಲಿ ಅನನ್ಯವಾದ ಕೆಲಸಗಳನ್ನು ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ಅತ್ಯಂತ ಸೂಕ್ತವಾದ ವಾಸ್ತುಶಿಲ್ಪದ ಮಾದರಿಯಾಗಿದೆ.
ನಮ್ಮ ಎಂಟರ್‌ಪ್ರೈಸ್ ಸೇವಾ ಮೆಶ್ ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಬೇಕು. ಹೆಚ್ಚುವರಿಯಾಗಿ, ವಿವಿಧ ಫಿಲ್ಟರ್‌ಗಳು ಮತ್ತು ಟೆಂಪ್ಲೆಟ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಖಾತರಿಪಡಿಸಿದ ವಿತರಣೆ, ಸ್ಟ್ರೀಮಿಂಗ್ ಮತ್ತು ಸಂಕೀರ್ಣ ಈವೆಂಟ್ ಪ್ರಕ್ರಿಯೆಯ ಅನುಷ್ಠಾನವನ್ನು ನಾವು ಅದರಲ್ಲಿ ನೋಡಲು ಬಯಸುತ್ತೇವೆ.
ಫೈಲ್ ವರ್ಗಾವಣೆ ಸೇವೆ
EDA ಜೊತೆಗೆ, ಫೈಲ್ಗಳನ್ನು ವರ್ಗಾಯಿಸಲು ಸಾಧ್ಯವಾಗುವುದು ಒಳ್ಳೆಯದು: ಎಂಟರ್‌ಪ್ರೈಸ್ ಪ್ರಮಾಣದಲ್ಲಿ, ಆಗಾಗ್ಗೆ ಫೈಲ್ ಏಕೀಕರಣ ಮಾತ್ರ ಸಾಧ್ಯ. ನಿರ್ದಿಷ್ಟವಾಗಿ, ETL (ಎಕ್ಸ್ಟ್ರಾಕ್ಟ್, ಟ್ರಾನ್ಸ್ಫಾರ್ಮ್, ಲೋಡ್) ವಾಸ್ತುಶಿಲ್ಪದ ಮಾದರಿಯನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. ಅದರಲ್ಲಿ, ನಿಯಮದಂತೆ, ಪ್ರತಿಯೊಬ್ಬರೂ ಫೈಲ್ಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ: ದೊಡ್ಡ ಡೇಟಾವನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ಇದು ಪ್ರತ್ಯೇಕ ವಿನಂತಿಗಳನ್ನು ತಳ್ಳಲು ಅಪ್ರಾಯೋಗಿಕವಾಗಿದೆ. ಎಂಟರ್‌ಪ್ರೈಸ್ ಸರ್ವಿಸ್ ಮೆಶ್‌ನಲ್ಲಿ ಫೈಲ್ ವರ್ಗಾವಣೆಗಳನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಬೆಂಬಲಿಸುವ ಸಾಮರ್ಥ್ಯವು ನಿಮ್ಮ ವ್ಯಾಪಾರಕ್ಕೆ ಅಗತ್ಯವಿರುವ ನಮ್ಯತೆಯನ್ನು ನೀಡುತ್ತದೆ.
ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಸೇವೆ
ದೊಡ್ಡ ಸಂಸ್ಥೆಗಳು ಯಾವಾಗಲೂ ವಿಭಿನ್ನ ಉತ್ಪನ್ನಗಳನ್ನು ತಯಾರಿಸುವ ವಿಭಿನ್ನ ತಂಡಗಳನ್ನು ಹೊಂದಿರುತ್ತವೆ. ಉದಾಹರಣೆಗೆ, ಬ್ಯಾಂಕಿನಲ್ಲಿ, ಕೆಲವು ತಂಡಗಳು ಠೇವಣಿಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತವೆ, ಆದರೆ ಇತರರು ಸಾಲದ ಉತ್ಪನ್ನಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಅಂತಹ ಪ್ರಕರಣಗಳು ಸಾಕಷ್ಟು ಇವೆ. ಇವರು ವಿಭಿನ್ನ ಜನರು, ತಮ್ಮ ಉತ್ಪನ್ನಗಳನ್ನು ತಯಾರಿಸುವ ವಿಭಿನ್ನ ತಂಡಗಳು, ತಮ್ಮ API ಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಾರೆ ಮತ್ತು ಅವುಗಳನ್ನು ಇತರರಿಗೆ ಒದಗಿಸುತ್ತಾರೆ. ಮತ್ತು ಆಗಾಗ್ಗೆ ಈ ಸೇವೆಗಳನ್ನು ರಚಿಸುವ ಅವಶ್ಯಕತೆಯಿದೆ, ಜೊತೆಗೆ API ಗಳ ಗುಂಪನ್ನು ಅನುಕ್ರಮವಾಗಿ ಕರೆಯಲು ಸಂಕೀರ್ಣ ತರ್ಕವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿ. ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು, ಈ ಎಲ್ಲಾ ಸಂಯೋಜಿತ ತರ್ಕವನ್ನು ಸರಳಗೊಳಿಸುವ ಏಕೀಕರಣ ಪದರದಲ್ಲಿ ನಿಮಗೆ ಪರಿಹಾರದ ಅಗತ್ಯವಿದೆ (ಹಲವಾರು API ಗಳನ್ನು ಕರೆಯುವುದು, ವಿನಂತಿಯ ಮಾರ್ಗವನ್ನು ವಿವರಿಸುವುದು, ಇತ್ಯಾದಿ.). ಇದು ಎಂಟರ್‌ಪ್ರೈಸ್ ಸರ್ವಿಸ್ ಮೆಶ್‌ನಲ್ಲಿ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಸೇವೆಯಾಗಿದೆ.
AI ಮತ್ತು ML
ಮೈಕ್ರೊ ಸರ್ವೀಸ್‌ಗಳು ಒಂದೇ ಏಕೀಕರಣ ಪದರದ ಮೂಲಕ ಸಂವಹನ ನಡೆಸಿದಾಗ, ಸೇವಾ ಮೆಶ್ ಸ್ವಾಭಾವಿಕವಾಗಿ ಪ್ರತಿ ಸೇವೆಯ ಕರೆಗಳ ಬಗ್ಗೆ ಎಲ್ಲವನ್ನೂ ತಿಳಿದಿರುತ್ತದೆ. ನಾವು ಟೆಲಿಮೆಟ್ರಿಯನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ: ಯಾರು ಯಾರನ್ನು, ಯಾವಾಗ, ಎಷ್ಟು ಸಮಯದವರೆಗೆ, ಎಷ್ಟು ಬಾರಿ ಕರೆದರು, ಇತ್ಯಾದಿ. ನೂರಾರು ಸಾವಿರ ಈ ಸೇವೆಗಳು ಮತ್ತು ಶತಕೋಟಿ ಕರೆಗಳು ಇದ್ದಾಗ, ಇದೆಲ್ಲವೂ ಸಂಗ್ರಹಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ದೊಡ್ಡ ಡೇಟಾವನ್ನು ರೂಪಿಸುತ್ತದೆ. ಈ ಡೇಟಾವನ್ನು AI, ಯಂತ್ರ ಕಲಿಕೆ ಇತ್ಯಾದಿಗಳನ್ನು ಬಳಸಿಕೊಂಡು ವಿಶ್ಲೇಷಿಸಬಹುದು ಮತ್ತು ನಂತರ ವಿಶ್ಲೇಷಣೆಯ ಫಲಿತಾಂಶಗಳ ಆಧಾರದ ಮೇಲೆ ಕೆಲವು ಉಪಯುಕ್ತ ವಿಷಯಗಳನ್ನು ಮಾಡಬಹುದು. ಈ ಎಲ್ಲಾ ನೆಟ್ವರ್ಕ್ ಟ್ರಾಫಿಕ್ ಮತ್ತು ಆರ್ಟಿಫಿಶಿಯಲ್ ಇಂಟೆಲಿಜೆನ್ಸ್‌ಗೆ ಸರ್ವಿಸ್ ಮೆಶ್‌ನಲ್ಲಿ ಸಂಯೋಜಿಸಲಾದ ಅಪ್ಲಿಕೇಶನ್ ಕರೆಗಳ ನಿಯಂತ್ರಣವನ್ನು ಕನಿಷ್ಠ ಭಾಗಶಃ ಹಸ್ತಾಂತರಿಸುವುದು ಸೂಕ್ತವಾಗಿರುತ್ತದೆ.
API ಗೇಟ್‌ವೇ ಸೇವೆ
ವಿಶಿಷ್ಟವಾಗಿ, ಸೇವಾ ಮೆಶ್ ಪ್ರಾಕ್ಸಿಗಳು ಮತ್ತು ಸೇವೆಗಳನ್ನು ಹೊಂದಿದ್ದು ಅದು ವಿಶ್ವಾಸಾರ್ಹ ಪರಿಧಿಯೊಳಗೆ ಪರಸ್ಪರ ಮಾತನಾಡುತ್ತದೆ. ಆದರೆ ಬಾಹ್ಯ ಕೌಂಟರ್ಪಾರ್ಟಿಗಳೂ ಇವೆ. ಈ ಗುಂಪಿನ ಗ್ರಾಹಕರಿಗೆ ಒಡ್ಡಿಕೊಳ್ಳುವ API ಗಳ ಅವಶ್ಯಕತೆಗಳು ಹೆಚ್ಚು ತೀವ್ರವಾಗಿರುತ್ತವೆ. ನಾವು ಈ ಕೆಲಸವನ್ನು ಎರಡು ಮುಖ್ಯ ಭಾಗಗಳಾಗಿ ವಿಂಗಡಿಸುತ್ತೇವೆ.
- ಭದ್ರತೆ. ddos ಗೆ ಸಂಬಂಧಿಸಿದ ಸಮಸ್ಯೆಗಳು, ಪ್ರೋಟೋಕಾಲ್‌ಗಳ ದುರ್ಬಲತೆ, ಅಪ್ಲಿಕೇಶನ್‌ಗಳು, ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳು ಇತ್ಯಾದಿ.
- ಸ್ಕೇಲ್. ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಸೇವೆ ಸಲ್ಲಿಸಬೇಕಾದ APIಗಳ ಸಂಖ್ಯೆಯು ಸಾವಿರಾರು ಅಥವಾ ನೂರಾರು ಸಾವಿರದಷ್ಟಿದ್ದಾಗ, ಈ API ಗಳ ಸೆಟ್‌ಗೆ ಕೆಲವು ರೀತಿಯ ನಿರ್ವಹಣಾ ಸಾಧನದ ಅವಶ್ಯಕತೆಯಿದೆ. ನೀವು ನಿರಂತರವಾಗಿ API ಅನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕಾಗುತ್ತದೆ: ಅವರು ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದಾರೆಯೇ ಅಥವಾ ಇಲ್ಲವೇ, ಅವರ ಸ್ಥಿತಿ ಏನು, ಯಾವ ಸಂಚಾರ ಹರಿಯುತ್ತಿದೆ, ಯಾವ ಅಂಕಿಅಂಶಗಳು, ಇತ್ಯಾದಿ. API ಗೇಟ್‌ವೇ ಸಂಪೂರ್ಣ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಿರ್ವಹಿಸುವ ಮತ್ತು ಸುರಕ್ಷಿತವಾಗಿಸುವಾಗ ಈ ಕಾರ್ಯವನ್ನು ನಿರ್ವಹಿಸಬೇಕು. ಈ ಘಟಕಕ್ಕೆ ಧನ್ಯವಾದಗಳು, ಎಂಟರ್‌ಪ್ರೈಸ್ ಸರ್ವಿಸ್ ಮೆಶ್ ಆಂತರಿಕ ಮತ್ತು ಬಾಹ್ಯ API ಗಳನ್ನು ಸುಲಭವಾಗಿ ಪ್ರಕಟಿಸಲು ಕಲಿಯುತ್ತದೆ.
ನಿರ್ದಿಷ್ಟ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು ಮತ್ತು ಡೇಟಾ ಫಾರ್ಮ್ಯಾಟ್‌ಗಳಿಗೆ ಬೆಂಬಲ ಸೇವೆ (AS ಗೇಟ್‌ವೇ)
ಪ್ರಸ್ತುತ, ಹೆಚ್ಚಿನ ಸೇವಾ ಮೆಶ್ ಪರಿಹಾರಗಳು ಸ್ಥಳೀಯವಾಗಿ HTTP ಮತ್ತು HTTP2 ಟ್ರಾಫಿಕ್‌ನೊಂದಿಗೆ ಅಥವಾ TCP/IP ಮಟ್ಟದಲ್ಲಿ ಕಡಿಮೆ ಮೋಡ್‌ನಲ್ಲಿ ಮಾತ್ರ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಎಂಟರ್‌ಪ್ರೈಸ್ ಸರ್ವಿಸ್ ಮೆಶ್ ಹಲವು ನಿರ್ದಿಷ್ಟ ಡೇಟಾ ವರ್ಗಾವಣೆ ಪ್ರೋಟೋಕಾಲ್‌ಗಳೊಂದಿಗೆ ಹೊರಹೊಮ್ಮುತ್ತಿದೆ. ಕೆಲವು ವ್ಯವಸ್ಥೆಗಳು ಸಂದೇಶ ದಲ್ಲಾಳಿಗಳನ್ನು ಬಳಸಬಹುದು, ಇತರವು ಡೇಟಾಬೇಸ್ ಮಟ್ಟದಲ್ಲಿ ಸಂಯೋಜಿಸಲ್ಪಟ್ಟಿವೆ. ಕಂಪನಿಯು SAP ಹೊಂದಿದ್ದರೆ, ಅದು ತನ್ನದೇ ಆದ ಏಕೀಕರಣ ವ್ಯವಸ್ಥೆಯನ್ನು ಸಹ ಬಳಸಬಹುದು. ಇದಲ್ಲದೆ, ಇದೆಲ್ಲವೂ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ವ್ಯವಹಾರದ ಪ್ರಮುಖ ಭಾಗವಾಗಿದೆ.
ನೀವು ಕೇವಲ ಹೇಳಲು ಸಾಧ್ಯವಿಲ್ಲ: "ಪರಂಪರೆಯನ್ನು ತ್ಯಜಿಸೋಣ ಮತ್ತು ಸೇವಾ ಮೆಶ್ ಅನ್ನು ಬಳಸಬಹುದಾದ ಹೊಸ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ಮಾಡೋಣ." ಎಲ್ಲಾ ಹಳೆಯ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ಹೊಸದರೊಂದಿಗೆ ಸಂಪರ್ಕಿಸಲು (ಮೈಕ್ರೋ ಸರ್ವಿಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನಲ್ಲಿ), ಸರ್ವಿಸ್ ಮೆಶ್ ಅನ್ನು ಬಳಸಬಹುದಾದ ವ್ಯವಸ್ಥೆಗಳಿಗೆ ಕೆಲವು ರೀತಿಯ ಅಡಾಪ್ಟರ್, ಮಧ್ಯವರ್ತಿ, ಗೇಟ್‌ವೇ ಅಗತ್ಯವಿರುತ್ತದೆ. ಒಪ್ಪುತ್ತೇನೆ, ಅದು ಸೇವೆಯ ಜೊತೆಗೆ ಪೆಟ್ಟಿಗೆಯಲ್ಲಿ ಬಂದರೆ ಚೆನ್ನಾಗಿರುತ್ತದೆ. AC ಗೇಟ್‌ವೇ ಯಾವುದೇ ಏಕೀಕರಣ ಆಯ್ಕೆಯನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ. ಕೇವಲ ಊಹಿಸಿ, ನೀವು ಎಂಟರ್‌ಪ್ರೈಸ್ ಸರ್ವಿಸ್ ಮೆಶ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿ ಮತ್ತು ನಿಮಗೆ ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಪ್ರೋಟೋಕಾಲ್‌ಗಳೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಲು ಇದು ಸಿದ್ಧವಾಗಿದೆ. ಈ ವಿಧಾನವು ನಮಗೆ ಬಹಳ ಮುಖ್ಯವಾಗಿದೆ.
ಸೇವಾ ಮೆಶ್ (ಎಂಟರ್‌ಪ್ರೈಸ್ ಸರ್ವಿಸ್ ಮೆಶ್) ನ ಕಾರ್ಪೊರೇಟ್ ಆವೃತ್ತಿಯನ್ನು ನಾವು ಸ್ಥೂಲವಾಗಿ ಹೇಗೆ ಊಹಿಸುತ್ತೇವೆ. ವಿವರಿಸಿದ ಗ್ರಾಹಕೀಕರಣವು ಏಕೀಕರಣ ವೇದಿಕೆಯ ಸಿದ್ಧ-ಸಿದ್ಧ ಮುಕ್ತ-ಮೂಲ ಆವೃತ್ತಿಗಳನ್ನು ಬಳಸಲು ಪ್ರಯತ್ನಿಸುವಾಗ ಉಂಟಾಗುವ ಹೆಚ್ಚಿನ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ. ಕೇವಲ ಒಂದೆರಡು ವರ್ಷಗಳ ಹಿಂದೆ ಪರಿಚಯಿಸಲಾಯಿತು, ಸೇವಾ ಮೆಶ್ ವಾಸ್ತುಶಿಲ್ಪವು ವಿಕಸನಗೊಳ್ಳುತ್ತಲೇ ಇದೆ ಮತ್ತು ಅದರ ಅಭಿವೃದ್ಧಿಗೆ ಕೊಡುಗೆ ನೀಡಲು ನಾವು ಉತ್ಸುಕರಾಗಿದ್ದೇವೆ. ನಮ್ಮ ಅನುಭವವು ನಿಮಗೆ ಉಪಯುಕ್ತವಾಗಿದೆ ಎಂದು ನಾವು ಭಾವಿಸುತ್ತೇವೆ.
ಮೂಲ: www.habr.com