ವಿತರಿಸಿದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಬಿಲ್ಡಿಂಗ್ ಬ್ಲಾಕ್‌ಗಳು. ಮೊದಲ ವಿಧಾನ

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

• ವಿನಂತಿ-ಪ್ರತಿಕ್ರಿಯೆ
• ವಿನಂತಿ-ಚಂಕ್ಡ್ ಪ್ರತಿಕ್ರಿಯೆ
• ವಿನಂತಿಯೊಂದಿಗೆ ಪ್ರತಿಕ್ರಿಯೆ
• ಪ್ರಕಟಿಸಿ-ಚಂದಾದಾರರಾಗಿ
• ತಲೆಕೆಳಗಾದ ಪ್ರಕಟಿಸಿ-ಚಂದಾದಾರರಾಗಿ
• ಕಾರ್ಯ ವಿತರಣೆ

SOA, MSA ಮತ್ತು ಸಂದೇಶ ಕಳುಹಿಸುವಿಕೆ

SOA, MSA ಗಳು ಸಿಸ್ಟಮ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳಾಗಿದ್ದು, ಅವು ಕಟ್ಟಡ ವ್ಯವಸ್ಥೆಗಳ ನಿಯಮಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತವೆ, ಆದರೆ ಸಂದೇಶ ಕಳುಹಿಸುವಿಕೆಯು ಅವುಗಳ ಅನುಷ್ಠಾನಕ್ಕೆ ಪ್ರಾಚೀನತೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ.

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

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

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

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

ಸಿಸ್ಟಮ್ ಘಟಕಗಳು ನೇರವಾಗಿ ಅಥವಾ ಬ್ರೋಕರ್ ಮೂಲಕ ಸಂವಹನ ನಡೆಸುತ್ತವೆ. ಸಂದೇಶದ ದೃಷ್ಟಿಕೋನದಿಂದ, ಪ್ರತಿ ಸೇವೆಯು ಹಲವಾರು ಜೀವನ ಹಂತಗಳನ್ನು ಹೊಂದಿದೆ:

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

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

ವಿನಿಮಯ

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

ಸಂದೇಶ ವಿನಿಮಯ ಮಾದರಿಗಳು (MEPs)

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

ವಿನಂತಿ-ಪ್ರತಿಕ್ರಿಯೆ ಅಥವಾ RPC

ನಾವು ಇನ್ನೊಂದು ಪ್ರಕ್ರಿಯೆಯಿಂದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ವೀಕರಿಸಬೇಕಾದಾಗ RPC ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. ಈ ಪ್ರಕ್ರಿಯೆಯು ಒಂದೇ ನೋಡ್‌ನಲ್ಲಿ ಚಾಲನೆಯಾಗುತ್ತಿರಬಹುದು ಅಥವಾ ಬೇರೆ ಖಂಡದಲ್ಲಿರಬಹುದು. ಸಂದೇಶ ಕಳುಹಿಸುವಿಕೆಯ ಮೂಲಕ ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್ ನಡುವಿನ ಪರಸ್ಪರ ಕ್ರಿಯೆಯ ರೇಖಾಚಿತ್ರವನ್ನು ಕೆಳಗೆ ನೀಡಲಾಗಿದೆ.

ಸಂದೇಶ ಕಳುಹಿಸುವಿಕೆಯು ಸಂಪೂರ್ಣವಾಗಿ ಅಸಮಕಾಲಿಕವಾಗಿರುವುದರಿಂದ, ಕ್ಲೈಂಟ್‌ಗೆ ವಿನಿಮಯವನ್ನು 2 ಹಂತಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ:

1. ವಿನಂತಿಯನ್ನು ಸಲ್ಲಿಸಿ

   messaging:request(Exchange, ResponseMatchingTag, RequestDefinition, HandlerProcess).

   ವಿನಿಮಯ - ವಿನಿಮಯ ಕೇಂದ್ರದ ಅನನ್ಯ ಹೆಸರು
   ResponseMatchingTag ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಸ್ಥಳೀಯ ಲೇಬಲ್. ಉದಾಹರಣೆಗೆ, ವಿವಿಧ ಬಳಕೆದಾರರಿಗೆ ಸೇರಿದ ಹಲವಾರು ಒಂದೇ ರೀತಿಯ ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸುವ ಸಂದರ್ಭದಲ್ಲಿ.
   ವಿನಂತಿ ವ್ಯಾಖ್ಯಾನ - ವಿನಂತಿ ದೇಹ
   ಹ್ಯಾಂಡ್ಲರ್ ಪ್ರಕ್ರಿಯೆ - ಹ್ಯಾಂಡ್ಲರ್‌ನ PID. ಈ ಪ್ರಕ್ರಿಯೆಯು ಸರ್ವರ್‌ನಿಂದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ.

2. ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುತ್ತಿದೆ

   handle_info(#'$msg'{exchange = EXCHANGE, tag = ResponseMatchingTag,message = ResponsePayload}, State)

   ಪ್ರತಿಕ್ರಿಯೆ ಪೇಲೋಡ್ - ಸರ್ವರ್ ಪ್ರತಿಕ್ರಿಯೆ.

ಸರ್ವರ್ಗಾಗಿ, ಪ್ರಕ್ರಿಯೆಯು 2 ಹಂತಗಳನ್ನು ಸಹ ಒಳಗೊಂಡಿದೆ:

1. ವಿನಿಮಯ ಬಿಂದುವನ್ನು ಪ್ರಾರಂಭಿಸುವುದು
2. ಸ್ವೀಕರಿಸಿದ ವಿನಂತಿಗಳ ಪ್ರಕ್ರಿಯೆ

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

ಸರ್ವರ್ ಕೋಡ್

api.hrl ನಲ್ಲಿ ಸೇವೆ API ಅನ್ನು ವ್ಯಾಖ್ಯಾನಿಸೋಣ:

%% =====================================================
%%  entities
%% =====================================================
-record(time, {
  unixtime :: non_neg_integer(),
  datetime :: binary()
}).

-record(time_error, {
  code :: non_neg_integer(),
  error :: term()
}).

%% =====================================================
%%  methods
%% =====================================================
-record(time_req, {
  opts :: term()
}).
-record(time_resp, {
  result :: #time{} | #time_error{}
}).

time_controller.erl ನಲ್ಲಿ ಸೇವಾ ನಿಯಂತ್ರಕವನ್ನು ವ್ಯಾಖ್ಯಾನಿಸೋಣ

%% В примере показан только значимый код. Вставив его в шаблон gen_server можно получить рабочий сервис.

%% инициализация gen_server
init(Args) ->
  %% подключение к точке обмена
  messaging:monitor_exchange(req_resp, ?EXCHANGE, default, self())
  {ok, #{}}.

%% обработка события потери связи с точкой обмена. Это же событие приходит, если точка обмена еще не запустилась.
handle_info(#exchange_die{exchange = ?EXCHANGE}, State) ->
  erlang:send(self(), monitor_exchange),
  {noreply, State};

%% обработка API
handle_info(#time_req{opts = _Opts}, State) ->
  messaging:response_once(Client, #time_resp{
result = #time{ unixtime = time_utils:unixtime(now()), datetime = time_utils:iso8601_fmt(now())}
  });
  {noreply, State};

%% завершение работы gen_server
terminate(_Reason, _State) ->
  messaging:demonitor_exchange(req_resp, ?EXCHANGE, default, self()),
  ok.

ಗ್ರಾಹಕ ಕೋಡ್

ಸೇವೆಗೆ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಲು, ನೀವು ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ಎಲ್ಲಿಯಾದರೂ ಸಂದೇಶ ಕಳುಹಿಸುವ ವಿನಂತಿ API ಗೆ ಕರೆ ಮಾಡಬಹುದು:

case messaging:request(?EXCHANGE, tag, #time_req{opts = #{}}, self()) of
    ok -> ok;
    _ -> %% repeat or fail logic
end

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

handle_info(#'$msg'{exchange = ?EXCHANGE, tag = tag, message = #time_resp{result = #time{unixtime = Utime}}}, State) ->
  ?debugVal(Utime),
  {noreply, State};

handle_info(#'$msg'{exchange = ?EXCHANGE, tag = tag, message = #time_resp{result = #time_error{code = ErrorCode}}}, State) ->
  ?debugVal({error, ErrorCode}),
  {noreply, State};

ವಿನಂತಿ-ಚಂಕ್ಡ್ ಪ್ರತಿಕ್ರಿಯೆ

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

ಅಂತಹ ಪ್ರಕರಣಗಳ ಒಂದೆರಡು ಉದಾಹರಣೆಗಳನ್ನು ನಾನು ನಿಮಗೆ ನೀಡುತ್ತೇನೆ:

• ಘಟಕಗಳು ಫೈಲ್‌ಗಳಂತಹ ಬೈನರಿ ಡೇಟಾವನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳುತ್ತವೆ. ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸಣ್ಣ ಭಾಗಗಳಾಗಿ ವಿಭಜಿಸುವುದು ಯಾವುದೇ ಗಾತ್ರದ ಫೈಲ್‌ಗಳೊಂದಿಗೆ ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಕೆಲಸ ಮಾಡಲು ಮತ್ತು ಮೆಮೊರಿ ಓವರ್‌ಫ್ಲೋಗಳನ್ನು ತಪ್ಪಿಸಲು ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ.
• ಪಟ್ಟಿಗಳು. ಉದಾಹರಣೆಗೆ, ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿನ ಬೃಹತ್ ಕೋಷ್ಟಕದಿಂದ ನಾವು ಎಲ್ಲಾ ದಾಖಲೆಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಬೇಕಾಗುತ್ತದೆ ಮತ್ತು ಅವುಗಳನ್ನು ಮತ್ತೊಂದು ಘಟಕಕ್ಕೆ ವರ್ಗಾಯಿಸಬೇಕು.

ನಾನು ಈ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಲೊಕೊಮೊಟಿವ್ ಎಂದು ಕರೆಯುತ್ತೇನೆ. ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ, 1024 MB ಯ 1 ಸಂದೇಶಗಳು 1 GB ಯ ಒಂದು ಸಂದೇಶಕ್ಕಿಂತ ಉತ್ತಮವಾಗಿದೆ.

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

ವಿನಂತಿಯೊಂದಿಗೆ ಪ್ರತಿಕ್ರಿಯೆ

ಸಂವಾದ ವ್ಯವಸ್ಥೆಗಳನ್ನು ನಿರ್ಮಿಸಲು ಇದು RPC ಮಾದರಿಯ ಅಪರೂಪದ ಮಾರ್ಪಾಡು.

ಪ್ರಕಟಿಸಿ-ಚಂದಾದಾರರಾಗಿ (ಡೇಟಾ ವಿತರಣಾ ವೃಕ್ಷ)

ಈವೆಂಟ್-ಚಾಲಿತ ವ್ಯವಸ್ಥೆಗಳು ಡೇಟಾ ಸಿದ್ಧವಾದ ತಕ್ಷಣ ಅವುಗಳನ್ನು ಗ್ರಾಹಕರಿಗೆ ತಲುಪಿಸುತ್ತವೆ. ಹೀಗಾಗಿ, ವ್ಯವಸ್ಥೆಗಳು ಪುಲ್ ಅಥವಾ ಪೋಲ್ ಮಾದರಿಗಿಂತ ಪುಶ್ ಮಾದರಿಗೆ ಹೆಚ್ಚು ಒಳಗಾಗುತ್ತವೆ. ನಿರಂತರವಾಗಿ ವಿನಂತಿಸುವ ಮೂಲಕ ಮತ್ತು ಡೇಟಾಕ್ಕಾಗಿ ಕಾಯುವ ಮೂಲಕ ಸಂಪನ್ಮೂಲಗಳನ್ನು ವ್ಯರ್ಥ ಮಾಡುವುದನ್ನು ತಪ್ಪಿಸಲು ಈ ವೈಶಿಷ್ಟ್ಯವು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.
ನಿರ್ದಿಷ್ಟ ವಿಷಯಕ್ಕೆ ಚಂದಾದಾರರಾಗಿರುವ ಗ್ರಾಹಕರಿಗೆ ಸಂದೇಶವನ್ನು ವಿತರಿಸುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಅಂಕಿ ತೋರಿಸುತ್ತದೆ.

ಈ ಮಾದರಿಯನ್ನು ಬಳಸುವ ಕ್ಲಾಸಿಕ್ ಉದಾಹರಣೆಗಳೆಂದರೆ ರಾಜ್ಯದ ವಿತರಣೆ: ಕಂಪ್ಯೂಟರ್ ಆಟಗಳಲ್ಲಿ ಆಟದ ಪ್ರಪಂಚ, ವಿನಿಮಯದ ಮಾರುಕಟ್ಟೆ ಡೇಟಾ, ಡೇಟಾ ಫೀಡ್‌ಗಳಲ್ಲಿ ಉಪಯುಕ್ತ ಮಾಹಿತಿ.

ಚಂದಾದಾರರ ಕೋಡ್ ಅನ್ನು ನೋಡೋಣ:

init(_Args) ->
  %% подписываемся на обменник, ключ = key
  messaging:subscribe(?SUBSCRIPTION, key, tag, self()),
  {ok, #{}}.

handle_info(#exchange_die{exchange = ?SUBSCRIPTION}, State) ->
  %% если точка обмена недоступна, то пытаемся переподключиться
  messaging:subscribe(?SUBSCRIPTION, key, tag, self()),
  {noreply, State};

%% обрабатываем пришедшие сообщения
handle_info(#'$msg'{exchange = ?SUBSCRIPTION, message = Msg}, State) ->
  ?debugVal(Msg),
  {noreply, State};

%% при остановке потребителя - отключаемся от точки обмена
terminate(_Reason, _State) ->
  messaging:unsubscribe(?SUBSCRIPTION, key, tag, self()),
  ok.

ಯಾವುದೇ ಅನುಕೂಲಕರ ಸ್ಥಳದಲ್ಲಿ ಸಂದೇಶವನ್ನು ಪ್ರಕಟಿಸಲು ಮೂಲವು ಕಾರ್ಯವನ್ನು ಕರೆಯಬಹುದು:

messaging:publish_message(Exchange, Key, Message).

ವಿನಿಮಯ - ವಿನಿಮಯ ಬಿಂದುವಿನ ಹೆಸರು,
ಕೀ - ರೂಟಿಂಗ್ ಕೀ
ಸಂದೇಶ - ಪೇಲೋಡ್

ತಲೆಕೆಳಗಾದ ಪ್ರಕಟಿಸಿ-ಚಂದಾದಾರರಾಗಿ

ಪಬ್-ಸಬ್ ಅನ್ನು ವಿಸ್ತರಿಸುವ ಮೂಲಕ, ನೀವು ಲಾಗಿಂಗ್ ಮಾಡಲು ಅನುಕೂಲಕರವಾದ ಮಾದರಿಯನ್ನು ಪಡೆಯಬಹುದು. ಮೂಲಗಳು ಮತ್ತು ಗ್ರಾಹಕರ ಸೆಟ್ ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನವಾಗಿರಬಹುದು. ಚಿತ್ರವು ಒಬ್ಬ ಗ್ರಾಹಕ ಮತ್ತು ಬಹು ಮೂಲಗಳೊಂದಿಗೆ ಒಂದು ಪ್ರಕರಣವನ್ನು ತೋರಿಸುತ್ತದೆ.

ಕಾರ್ಯ ವಿತರಣಾ ಮಾದರಿ

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

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

ಸಂದೇಶ ಕಳುಹಿಸುವಿಕೆಯು ಸರತಿ ಸಾಲುಗಳು ಮತ್ತು ಪ್ರಕ್ರಿಯೆಯ ಆದ್ಯತೆಯನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಪ್ರೊಸೆಸರ್‌ಗಳು ಕಾರ್ಯಗಳನ್ನು ಅವರು ಬಂದಂತೆ ಸ್ವೀಕರಿಸುತ್ತಾರೆ. ಕಾರ್ಯವು ಯಶಸ್ವಿಯಾಗಿ ಪೂರ್ಣಗೊಳ್ಳಬಹುದು ಅಥವಾ ವಿಫಲವಾಗಬಹುದು:

• messaging:ack(Tack) - ಸಂದೇಶವನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದರೆ ಕರೆಯಲಾಗುತ್ತದೆ
• messaging:nack(Tack) - ಎಲ್ಲಾ ತುರ್ತು ಸಂದರ್ಭಗಳಲ್ಲಿ ಕರೆಯಲಾಗುತ್ತದೆ. ಕಾರ್ಯವನ್ನು ಹಿಂತಿರುಗಿಸಿದ ನಂತರ, ಸಂದೇಶ ಕಳುಹಿಸುವಿಕೆಯು ಅದನ್ನು ಮತ್ತೊಂದು ಹ್ಯಾಂಡ್ಲರ್‌ಗೆ ರವಾನಿಸುತ್ತದೆ.

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

ಪ್ರಾಥಮಿಕ ಸಾರಾಂಶ

ವಿತರಣಾ ವ್ಯವಸ್ಥೆಗಳ ಮೂಲ ಬಿಲ್ಡಿಂಗ್ ಬ್ಲಾಕ್ಸ್ ಅನ್ನು ನಾವು ಆವರಿಸಿದ್ದೇವೆ ಮತ್ತು ಎರ್ಲಾಂಗ್/ಎಲಿಕ್ಸಿರ್‌ನಲ್ಲಿ ಅವುಗಳ ಬಳಕೆಯ ಬಗ್ಗೆ ಮೂಲಭೂತ ತಿಳುವಳಿಕೆಯನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ.

ಮೂಲ ಮಾದರಿಗಳನ್ನು ಸಂಯೋಜಿಸುವ ಮೂಲಕ, ಉದಯೋನ್ಮುಖ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ನೀವು ಸಂಕೀರ್ಣ ಮಾದರಿಗಳನ್ನು ರಚಿಸಬಹುದು.

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

ಎರಡನೇ ಭಾಗದ ಅಂತ್ಯ.

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

ಮೂಲ: www.habr.com