🥇ಕ್ಲೌಡ್ ಸೇವೆಯ ರಚನೆಯ ಇತಿಹಾಸ, ಸೈಬರ್‌ಪಂಕ್‌ನೊಂದಿಗೆ ಸುವಾಸನೆ

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

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

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

ಬೆಕ್ಕಿಗೆ ಸ್ವಾಗತ.

ಪ್ರಯಾಣದ ಪ್ರಾರಂಭ

ಕೆಲವು ಸಮಯದ ಹಿಂದೆ, ನಮ್ಮ ಕ್ಲೈಂಟ್‌ಗಳಿಗಾಗಿ ಕ್ಲೌಡ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುವ ಕಾರ್ಯವನ್ನು ನಮ್ಮ ತಂಡಕ್ಕೆ ನೀಡಲಾಯಿತು. ಸೇವೆಯ ಸಾಫ್ಟ್‌ವೇರ್ ಭಾಗವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ತಂತ್ರಜ್ಞಾನಗಳನ್ನು ಆಯ್ಕೆಮಾಡುವಲ್ಲಿ ನಾವು ನಿರ್ವಹಣೆ ಬೆಂಬಲ, ಸಂಪನ್ಮೂಲಗಳು, ಹಾರ್ಡ್‌ವೇರ್ ಸ್ಟಾಕ್ ಮತ್ತು ಸ್ವಾತಂತ್ರ್ಯವನ್ನು ಹೊಂದಿದ್ದೇವೆ.

ಹಲವಾರು ಅವಶ್ಯಕತೆಗಳೂ ಇದ್ದವು:

ಸೇವೆಗೆ ಅನುಕೂಲಕರ ವೈಯಕ್ತಿಕ ಖಾತೆಯ ಅಗತ್ಯವಿದೆ;
ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅನ್ನು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಬಿಲ್ಲಿಂಗ್ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಸಂಯೋಜಿಸಬೇಕು;
ಸಾಫ್ಟ್‌ವೇರ್ ಮತ್ತು ಹಾರ್ಡ್‌ವೇರ್: ಓಪನ್‌ಸ್ಟ್ಯಾಕ್ + ಟಂಗ್‌ಸ್ಟನ್ ಫ್ಯಾಬ್ರಿಕ್ (ಓಪನ್ ಕಾಂಟ್ರಾಲ್), ನಮ್ಮ ಎಂಜಿನಿಯರ್‌ಗಳು ಚೆನ್ನಾಗಿ "ಅಡುಗೆ" ಮಾಡಲು ಕಲಿತಿದ್ದಾರೆ.

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

ಪೈಥಾನ್ + ಫ್ಲಾಸ್ಕ್ + ಸ್ವಾಗ್ಗರ್ + SQLalchemy - ಸಂಪೂರ್ಣ ಗುಣಮಟ್ಟದ ಪೈಥಾನ್ ಸೆಟ್;
ಮುಂಭಾಗಕ್ಕಾಗಿ Vue.js;
AMQP ಮೂಲಕ Celery ಅನ್ನು ಬಳಸಿಕೊಂಡು ಘಟಕಗಳು ಮತ್ತು ಸೇವೆಗಳ ನಡುವಿನ ಪರಸ್ಪರ ಕ್ರಿಯೆಯನ್ನು ಮಾಡಲು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ.

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

ಆದ್ದರಿಂದ, ನಮ್ಮ ಪರಿಚಯವನ್ನು ಪ್ರಾರಂಭಿಸೋಣ.

ಸೈಲೆಂಟ್ ಬಿಲ್ - ಬಿಲ್ಲಿಂಗ್

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

ಬಿಲ್ಲಿಂಗ್ ನಾವು ಸ್ನೇಹಿತರನ್ನು ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿದ ಮೊದಲ ವ್ಯವಸ್ಥೆಯಾಗಿದೆ. ಮತ್ತು ಸೇವೆಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವಾಗ ನಾವು ಎದುರಿಸಿದ ಮೊದಲ ತೊಂದರೆ.

ಉದಾಹರಣೆಗೆ, ರಚಿಸಿದಾಗ ಅಥವಾ ಅಳಿಸಿದಾಗ, ಕಾರ್ಯವು ಆಂತರಿಕ ಬಿಲ್ಲಿಂಗ್ ಕ್ಯೂಗೆ ಹೋಗುತ್ತದೆ. ಹೀಗಾಗಿ, ಸೇವೆಗಳೊಂದಿಗೆ ಅಸಮಕಾಲಿಕ ಕೆಲಸದ ವ್ಯವಸ್ಥೆಯನ್ನು ಅಳವಡಿಸಲಾಗಿದೆ. ನಮ್ಮ ಸೇವಾ ಪ್ರಕಾರಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು, ನಾವು ಈ ಸರತಿ ಸಾಲಿನಲ್ಲಿ ನಮ್ಮ ಕಾರ್ಯಗಳನ್ನು "ಹಾಕುವ" ಅಗತ್ಯವಿದೆ. ಮತ್ತು ಇಲ್ಲಿ ನಾವು ಸಮಸ್ಯೆಗೆ ಸಿಲುಕಿದ್ದೇವೆ: ದಾಖಲೆಗಳ ಕೊರತೆ.

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

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

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

ಇನ್ನೊಂದು ಸಮಸ್ಯೆ ಮೌನ.

ಕೆಲವು API ವಿನಂತಿಗಳಿಗೆ ಬಿಲ್ಲಿ ಮೌನವಾಗಿ "ಸರಿ" ಎಂದು ಉತ್ತರಿಸುತ್ತಾರೆ. ಉದಾಹರಣೆಗೆ, ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ ನಾವು ಭರವಸೆ ನೀಡಿದ ಪಾವತಿಗಳ ಪಾವತಿಗಳನ್ನು ಮಾಡಿದಾಗ ಇದು ಹೀಗಿತ್ತು (ನಂತರದಲ್ಲಿ ಇನ್ನಷ್ಟು). ವಿನಂತಿಗಳನ್ನು ಸರಿಯಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗಿದೆ ಮತ್ತು ನಾವು ಯಾವುದೇ ದೋಷಗಳನ್ನು ನೋಡಲಿಲ್ಲ.

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

ಸಾಮಾನ್ಯವಾಗಿ, ದಸ್ತಾವೇಜನ್ನು ಮತ್ತು ಸಣ್ಣ API ನ್ಯೂನತೆಗಳ ಅಂತರಗಳ ಹೊರತಾಗಿಯೂ, ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿ ಹೋಯಿತು. ಲಾಗ್‌ಗಳನ್ನು ಹೇಗೆ ರಚಿಸಲಾಗಿದೆ ಮತ್ತು ಏನನ್ನು ನೋಡಬೇಕು ಎಂಬುದನ್ನು ನೀವು ಅರ್ಥಮಾಡಿಕೊಂಡರೆ ಭಾರವಾದ ಹೊರೆಯಲ್ಲಿಯೂ ಸಹ ಓದಬಹುದು. ಡೇಟಾಬೇಸ್‌ನ ರಚನೆಯು ಅಲಂಕೃತವಾಗಿದೆ, ಆದರೆ ಸಾಕಷ್ಟು ತಾರ್ಕಿಕವಾಗಿದೆ ಮತ್ತು ಕೆಲವು ರೀತಿಯಲ್ಲಿ ಆಕರ್ಷಕವಾಗಿದೆ.

ಆದ್ದರಿಂದ, ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಹೇಳುವುದಾದರೆ, ಪರಸ್ಪರ ಕ್ರಿಯೆಯ ಹಂತದಲ್ಲಿ ನಾವು ಎದುರಿಸಿದ ಮುಖ್ಯ ಸಮಸ್ಯೆಗಳು ನಿರ್ದಿಷ್ಟ ವ್ಯವಸ್ಥೆಯ ಅನುಷ್ಠಾನದ ವೈಶಿಷ್ಟ್ಯಗಳಿಗೆ ಸಂಬಂಧಿಸಿವೆ:

ದಾಖಲೆರಹಿತ "ವೈಶಿಷ್ಟ್ಯಗಳು" ನಮಗೆ ಒಂದು ರೀತಿಯಲ್ಲಿ ಅಥವಾ ಇನ್ನೊಂದು ರೀತಿಯಲ್ಲಿ ಪರಿಣಾಮ ಬೀರುತ್ತವೆ;
ಮುಚ್ಚಿದ ಮೂಲ (ಬಿಲ್ಲಿಂಗ್ ಅನ್ನು C ++ ನಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ), ಪರಿಣಾಮವಾಗಿ - "ಪ್ರಯೋಗ ಮತ್ತು ದೋಷ" ಹೊರತುಪಡಿಸಿ ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಸಮಸ್ಯೆ 1 ಅನ್ನು ಪರಿಹರಿಸಲು ಅಸಾಧ್ಯ.

ಅದೃಷ್ಟವಶಾತ್, ಉತ್ಪನ್ನವು ಸಾಕಷ್ಟು ವ್ಯಾಪಕವಾದ API ಅನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ನಾವು ಕೆಳಗಿನ ಉಪವ್ಯವಸ್ಥೆಗಳನ್ನು ನಮ್ಮ ವೈಯಕ್ತಿಕ ಖಾತೆಗೆ ಸಂಯೋಜಿಸಿದ್ದೇವೆ:

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

ಟಂಗ್ಸ್ಟನ್ ಕ್ಷೇತ್ರಗಳ ಮೂಲಕ ನಡೆಯುವುದು - ಟಂಗ್ಸ್ಟನ್ ಫ್ಯಾಬ್ರಿಕ್

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

ಇದು ನಾವು ಸ್ನೇಹಿತರನ್ನು ಮಾಡಿಕೊಳ್ಳಬೇಕಾದ ಎರಡನೇ ಸಿಸ್ಟಮ್‌ನ ಡೊಮೇನ್ ಆಗಿದೆ - ಟಂಗ್‌ಸ್ಟನ್ ಫ್ಯಾಬ್ರಿಕ್ (ಟಿಎಫ್), ಹಿಂದೆ ಓಪನ್‌ಕಾಂಟ್ರೈಲ್. ನೆಟ್ವರ್ಕ್ ಉಪಕರಣಗಳನ್ನು ನಿರ್ವಹಿಸುವುದು ಇದರ ಕಾರ್ಯವಾಗಿದೆ, ಬಳಕೆದಾರರಾಗಿ ನಮಗೆ ಸಾಫ್ಟ್ವೇರ್ ಅಮೂರ್ತತೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ. TF - SDN, ನೆಟ್ವರ್ಕ್ ಉಪಕರಣಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಸಂಕೀರ್ಣ ತರ್ಕವನ್ನು ಆವರಿಸುತ್ತದೆ. ತಂತ್ರಜ್ಞಾನದ ಬಗ್ಗೆ ಉತ್ತಮ ಲೇಖನವಿದೆ, ಉದಾಹರಣೆಗೆ, ಇಲ್ಲಿ.

ಸಿಸ್ಟಮ್ ಅನ್ನು ನ್ಯೂಟ್ರಾನ್ ಪ್ಲಗಿನ್ ಮೂಲಕ ಓಪನ್ ಸ್ಟಾಕ್ (ಕೆಳಗೆ ಚರ್ಚಿಸಲಾಗಿದೆ) ನೊಂದಿಗೆ ಸಂಯೋಜಿಸಲಾಗಿದೆ.

OpenStack ಸೇವೆಗಳ ಪರಸ್ಪರ ಕ್ರಿಯೆ.

ಕಾರ್ಯಾಚರಣೆ ವಿಭಾಗದ ವ್ಯಕ್ತಿಗಳು ನಮಗೆ ಈ ವ್ಯವಸ್ಥೆಯನ್ನು ಪರಿಚಯಿಸಿದರು. ನಮ್ಮ ಸೇವೆಗಳ ನೆಟ್‌ವರ್ಕ್ ಸ್ಟಾಕ್ ಅನ್ನು ನಿರ್ವಹಿಸಲು ನಾವು ಸಿಸ್ಟಂನ API ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ಇದು ನಮಗೆ ಇನ್ನೂ ಯಾವುದೇ ಗಂಭೀರ ಸಮಸ್ಯೆಗಳು ಅಥವಾ ಅನಾನುಕೂಲತೆಗಳನ್ನು ಉಂಟುಮಾಡಿಲ್ಲ (OE ನಿಂದ ಹುಡುಗರಿಗೆ ನಾನು ಮಾತನಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ), ಆದರೆ ಪರಸ್ಪರ ಕ್ರಿಯೆಯಲ್ಲಿ ಕೆಲವು ವಿಚಿತ್ರತೆಗಳಿವೆ.

ಮೊದಲನೆಯದು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ: SSH ಮೂಲಕ ಸಂಪರ್ಕಿಸುವಾಗ ನಿದರ್ಶನ ಕನ್ಸೋಲ್‌ಗೆ ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಡೇಟಾವನ್ನು ಔಟ್‌ಪುಟ್ ಮಾಡುವ ಅಗತ್ಯವಿರುವ ಆಜ್ಞೆಗಳು ಸಂಪರ್ಕವನ್ನು ಸರಳವಾಗಿ "ಹ್ಯಾಂಗ್ ಅಪ್" ಮಾಡುತ್ತವೆ, ಆದರೆ VNC ಮೂಲಕ ಎಲ್ಲವೂ ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ.

ಸಮಸ್ಯೆಯ ಬಗ್ಗೆ ತಿಳಿದಿಲ್ಲದವರಿಗೆ, ಇದು ತುಂಬಾ ತಮಾಷೆಯಾಗಿ ಕಾಣುತ್ತದೆ: ls / ರೂಟ್ ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, ಮೇಲ್ಭಾಗವು ಸಂಪೂರ್ಣವಾಗಿ "ಫ್ರೀಜ್" ಆಗುತ್ತದೆ. ಅದೃಷ್ಟವಶಾತ್, ನಾವು ಮೊದಲು ಇದೇ ರೀತಿಯ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸಿದ್ದೇವೆ. ಕಂಪ್ಯೂಟ್ ನೋಡ್‌ಗಳಿಂದ ರೂಟರ್‌ಗಳಿಗೆ ಮಾರ್ಗದಲ್ಲಿ MTU ಅನ್ನು ಟ್ಯೂನ್ ಮಾಡುವ ಮೂಲಕ ನಿರ್ಧರಿಸಲಾಯಿತು. ಅಂದಹಾಗೆ, ಇದು TF ಸಮಸ್ಯೆ ಅಲ್ಲ.

ಮುಂದಿನ ಸಮಸ್ಯೆ ಕೇವಲ ಮೂಲೆಯಲ್ಲಿತ್ತು. ಒಂದು "ಸುಂದರ" ಕ್ಷಣದಲ್ಲಿ, ರೂಟಿಂಗ್ನ ಮ್ಯಾಜಿಕ್ ಕಣ್ಮರೆಯಾಯಿತು, ಅದರಂತೆಯೇ. TF ಸಾಧನದಲ್ಲಿ ರೂಟಿಂಗ್ ನಿರ್ವಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದೆ.

ನಾವು ನಿರ್ವಾಹಕರ ಮಟ್ಟದಿಂದ ಓಪನ್‌ಸ್ಟಾಕ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ಅದರ ನಂತರ ಅಗತ್ಯವಿರುವ ಬಳಕೆದಾರರ ಮಟ್ಟಕ್ಕೆ ತೆರಳಿದ್ದೇವೆ. SDN ಕ್ರಿಯೆಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಬಳಕೆದಾರರ ವ್ಯಾಪ್ತಿಯನ್ನು "ಹೈಜಾಕ್" ಮಾಡಲು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಸತ್ಯವೆಂದರೆ ಅದೇ ನಿರ್ವಾಹಕ ಖಾತೆಯನ್ನು TF ಮತ್ತು OpenStack ಅನ್ನು ಸಂಪರ್ಕಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ. ಬಳಕೆದಾರರಿಗೆ ಬದಲಾಯಿಸುವ ಹಂತದಲ್ಲಿ, "ಮ್ಯಾಜಿಕ್" ಕಣ್ಮರೆಯಾಯಿತು. ಸಿಸ್ಟಮ್ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಪ್ರತ್ಯೇಕ ಖಾತೆಯನ್ನು ರಚಿಸಲು ನಿರ್ಧರಿಸಲಾಯಿತು. ಏಕೀಕರಣ ಕಾರ್ಯವನ್ನು ಮುರಿಯದೆ ಕೆಲಸ ಮಾಡಲು ಇದು ನಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿತು.

ಸಿಲಿಕಾನ್ ಲೈಫ್ಫಾರ್ಮ್ಸ್ - ಓಪನ್ ಸ್ಟಾಕ್

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

OpenStack ನಮ್ಮ ವೇದಿಕೆಯ ತಿರುಳು.

OpenStack ಹಲವಾರು ಉಪವ್ಯವಸ್ಥೆಗಳನ್ನು ಹೊಂದಿದೆ, ಅದರಲ್ಲಿ ನಾವು ಪ್ರಸ್ತುತ Nova, Glance ಮತ್ತು Cinder ಅನ್ನು ಹೆಚ್ಚು ಸಕ್ರಿಯವಾಗಿ ಬಳಸುತ್ತೇವೆ. ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ತನ್ನದೇ ಆದ API ಅನ್ನು ಹೊಂದಿದೆ. ಕಂಪ್ಯೂಟ್ ಸಂಪನ್ಮೂಲಗಳು ಮತ್ತು ನಿದರ್ಶನಗಳ ರಚನೆಗೆ ನೋವಾ ಕಾರಣವಾಗಿದೆ, ಸಂಪುಟಗಳು ಮತ್ತು ಅವುಗಳ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಸಿಂಡರ್ ಜವಾಬ್ದಾರನಾಗಿರುತ್ತಾನೆ, ಗ್ಲಾನ್ಸ್ ಎನ್ನುವುದು ಓಎಸ್ ಟೆಂಪ್ಲೇಟ್‌ಗಳು ಮತ್ತು ಅವುಗಳ ಮೇಲೆ ಮೆಟೈನ್‌ಫಾರ್ಮೇಶನ್ ಅನ್ನು ನಿರ್ವಹಿಸುವ ಇಮೇಜ್ ಸೇವೆಯಾಗಿದೆ.

ಪ್ರತಿಯೊಂದು ಸೇವೆಯು ಕಂಟೇನರ್‌ನಲ್ಲಿ ಚಲಿಸುತ್ತದೆ ಮತ್ತು ಸಂದೇಶ ಬ್ರೋಕರ್ "ಬಿಳಿ ಮೊಲ" - RabbitMQ.

ಈ ವ್ಯವಸ್ಥೆಯು ನಮಗೆ ಅತ್ಯಂತ ಅನಿರೀಕ್ಷಿತ ತೊಂದರೆಯನ್ನು ನೀಡಿತು.

ಮತ್ತು ನಾವು ಸರ್ವರ್‌ಗೆ ಹೆಚ್ಚುವರಿ ಪರಿಮಾಣವನ್ನು ಸಂಪರ್ಕಿಸಲು ಪ್ರಯತ್ನಿಸಿದಾಗ ಮೊದಲ ಸಮಸ್ಯೆ ಬರಲು ಹೆಚ್ಚು ಸಮಯ ಇರಲಿಲ್ಲ. Cinder API ಈ ಕಾರ್ಯವನ್ನು ನಿರ್ವಹಿಸಲು ನಿರಾಕರಿಸಿತು. ಹೆಚ್ಚು ನಿಖರವಾಗಿ, ನೀವು OpenStack ಅನ್ನು ನಂಬಿದರೆ, ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸಲಾಗಿದೆ, ಆದರೆ ವರ್ಚುವಲ್ ಸರ್ವರ್ ಒಳಗೆ ಯಾವುದೇ ಡಿಸ್ಕ್ ಸಾಧನವಿಲ್ಲ.

ನಾವು ಒಂದು ಮಾರ್ಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ ಮತ್ತು Nova API ನಿಂದ ಅದೇ ಕ್ರಮವನ್ನು ವಿನಂತಿಸಿದ್ದೇವೆ. ಫಲಿತಾಂಶವೆಂದರೆ ಸಾಧನವು ಸರಿಯಾಗಿ ಸಂಪರ್ಕಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಸರ್ವರ್‌ನಲ್ಲಿ ಪ್ರವೇಶಿಸಬಹುದು. ಬ್ಲಾಕ್-ಸ್ಟೋರೇಜ್ ಸಿಂಡರ್ಗೆ ಪ್ರತಿಕ್ರಿಯಿಸದಿದ್ದಾಗ ಸಮಸ್ಯೆ ಸಂಭವಿಸುತ್ತದೆ ಎಂದು ತೋರುತ್ತದೆ.

ಡಿಸ್ಕ್ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ ಮತ್ತೊಂದು ತೊಂದರೆ ನಮಗೆ ಕಾಯುತ್ತಿದೆ. ಸಿಸ್ಟಂ ಪರಿಮಾಣವನ್ನು ಸರ್ವರ್‌ನಿಂದ ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸಲಾಗಲಿಲ್ಲ.

ಮತ್ತೆ, OpenStack ಸ್ವತಃ ಸಂಪರ್ಕವನ್ನು ನಾಶಪಡಿಸಿದೆ ಎಂದು "ಪ್ರಮಾಣ" ಮಾಡುತ್ತದೆ ಮತ್ತು ಈಗ ನೀವು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಮಾಣದೊಂದಿಗೆ ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡಬಹುದು. ಆದರೆ API ನಿರ್ದಿಷ್ಟವಾಗಿ ಡಿಸ್ಕ್ನಲ್ಲಿ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಮಾಡಲು ಬಯಸುವುದಿಲ್ಲ.

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

OpenStack ತನ್ನದೇ ಆದ ಪರಸ್ಪರ ಕ್ರಿಯೆಯ ತರ್ಕ ಮತ್ತು ಅಲಂಕೃತ API ಅನ್ನು ಹೊಂದಿರುವ ಸಂಕೀರ್ಣವಾದ ವ್ಯವಸ್ಥೆಯಾಗಿದೆ. ಸಾಕಷ್ಟು ವಿವರವಾದ ದಾಖಲಾತಿಯಿಂದ ನಮಗೆ ಸಹಾಯವಾಗುತ್ತದೆ ಮತ್ತು ಸಹಜವಾಗಿ, ಪ್ರಯೋಗ ಮತ್ತು ದೋಷ (ಅದು ಇಲ್ಲದೆ ನಾವು ಎಲ್ಲಿದ್ದೇವೆ).

ಟೆಸ್ಟ್ ರನ್

ಕಳೆದ ವರ್ಷ ಡಿಸೆಂಬರ್‌ನಲ್ಲಿ ಪರೀಕ್ಷಾರ್ಥ ಉಡಾವಣೆ ನಡೆಸಿದ್ದೆವು. ತಾಂತ್ರಿಕ ಕಡೆಯಿಂದ ಮತ್ತು UX ಕಡೆಯಿಂದ ನಮ್ಮ ಯೋಜನೆಯನ್ನು ಯುದ್ಧ ಕ್ರಮದಲ್ಲಿ ಪರೀಕ್ಷಿಸುವುದು ಮುಖ್ಯ ಕಾರ್ಯವಾಗಿತ್ತು. ಪ್ರೇಕ್ಷಕರನ್ನು ಆಯ್ದವಾಗಿ ಆಹ್ವಾನಿಸಲಾಯಿತು ಮತ್ತು ಪರೀಕ್ಷೆಯನ್ನು ಮುಚ್ಚಲಾಯಿತು. ಆದಾಗ್ಯೂ, ನಮ್ಮ ವೆಬ್‌ಸೈಟ್‌ನಲ್ಲಿ ಪರೀಕ್ಷೆಗೆ ಪ್ರವೇಶವನ್ನು ವಿನಂತಿಸುವ ಆಯ್ಕೆಯನ್ನು ಸಹ ನಾವು ಬಿಟ್ಟಿದ್ದೇವೆ.

ಪರೀಕ್ಷೆಯು ಸಹಜವಾಗಿ, ಅದರ ಮೋಜಿನ ಕ್ಷಣಗಳಿಲ್ಲದೆ ಇರಲಿಲ್ಲ, ಏಕೆಂದರೆ ನಮ್ಮ ಸಾಹಸಗಳು ಇಲ್ಲಿಯೇ ಪ್ರಾರಂಭವಾಗಿವೆ.

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

ಮತ್ತೊಂದು ಕುತೂಹಲವು ನಿಮ್ಮ ವೈಯಕ್ತಿಕ ಖಾತೆಯಲ್ಲಿ "ಪಾಸ್ವರ್ಡ್ ಬದಲಿಸಿ" ಬಟನ್ನ ಕಾರ್ಯಚಟುವಟಿಕೆಗೆ ಸಂಬಂಧಿಸಿದೆ.

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

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

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

ಮುಂದುವರೆಯಲು

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

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

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

ನಾವು ಇತ್ತೀಚೆಗೆ ಸೇವೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ.
ನಮ್ಮಲ್ಲಿ ನೀವು ಎಲ್ಲಾ ವಿವರಗಳನ್ನು ಕಂಡುಹಿಡಿಯಬಹುದು ಸೈಟ್.

CLO ಅಭಿವೃದ್ಧಿ ತಂಡ

ಉಪಯುಕ್ತ ಕೊಂಡಿಗಳು

ಓಪನ್ ಸ್ಟ್ಯಾಕ್

ಟಂಗ್ಸ್ಟನ್ ಫ್ಯಾಬ್ರಿಕ್

ಮೂಲ: www.habr.com

ಕ್ಲೌಡ್ ಸೇವೆಯ ರಚನೆಯ ಇತಿಹಾಸ, ಸೈಬರ್‌ಪಂಕ್‌ನೊಂದಿಗೆ ಸುವಾಸನೆ