“ਮੇਰੀਆਂ ਜੁੱਤੀਆਂ ਵਿੱਚ ਚੱਲਣਾ” - ਉਡੀਕ ਕਰੋ, ਕੀ ਉਹ ਚਿੰਨ੍ਹਿਤ ਹਨ?

2019 ਤੋਂ, ਰੂਸ ਵਿੱਚ ਲਾਜ਼ਮੀ ਲੇਬਲਿੰਗ 'ਤੇ ਇੱਕ ਕਾਨੂੰਨ ਹੈ। ਕਾਨੂੰਨ ਵਸਤਾਂ ਦੇ ਸਾਰੇ ਸਮੂਹਾਂ 'ਤੇ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਉਤਪਾਦ ਸਮੂਹਾਂ ਲਈ ਲਾਜ਼ਮੀ ਲੇਬਲਿੰਗ ਦੇ ਲਾਗੂ ਹੋਣ ਦੀ ਮਿਤੀਆਂ ਵੱਖਰੀਆਂ ਹਨ। ਤੰਬਾਕੂ, ਜੁੱਤੀਆਂ ਅਤੇ ਦਵਾਈਆਂ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਲਾਜ਼ਮੀ ਲੇਬਲਿੰਗ ਦੇ ਅਧੀਨ ਹੋਣਗੀਆਂ; ਹੋਰ ਉਤਪਾਦ ਬਾਅਦ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੇ ਜਾਣਗੇ, ਉਦਾਹਰਨ ਲਈ, ਅਤਰ, ਟੈਕਸਟਾਈਲ, ਅਤੇ ਦੁੱਧ। ਇਸ ਵਿਧਾਨਕ ਨਵੀਨਤਾ ਨੇ ਨਵੇਂ ਆਈਟੀ ਹੱਲਾਂ ਦੇ ਵਿਕਾਸ ਲਈ ਪ੍ਰੇਰਿਆ ਜੋ ਉਤਪਾਦਨ ਤੋਂ ਲੈ ਕੇ ਅੰਤਮ ਖਪਤਕਾਰ ਦੁਆਰਾ ਖਰੀਦ ਤੱਕ, ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਸਾਰੇ ਭਾਗੀਦਾਰਾਂ ਲਈ ਉਤਪਾਦ ਦੀ ਸਮੁੱਚੀ ਜੀਵਨ ਲੜੀ ਨੂੰ ਟਰੈਕ ਕਰਨਾ ਸੰਭਵ ਬਣਾਵੇਗਾ: ਦੋਵੇਂ ਰਾਜ ਖੁਦ ਅਤੇ ਸਾਰੀਆਂ ਸੰਸਥਾਵਾਂ ਜੋ ਇਸ ਨਾਲ ਚੀਜ਼ਾਂ ਵੇਚ ਰਹੀਆਂ ਹਨ। ਲਾਜ਼ਮੀ ਲੇਬਲਿੰਗ.

X5 ਵਿੱਚ, ਸਿਸਟਮ ਜੋ ਲੇਬਲ ਕੀਤੇ ਸਾਮਾਨ ਨੂੰ ਟਰੈਕ ਕਰੇਗਾ ਅਤੇ ਰਾਜ ਅਤੇ ਸਪਲਾਇਰਾਂ ਨਾਲ ਡੇਟਾ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਕਰੇਗਾ "ਮਾਰਕਸ" ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਆਓ ਤੁਹਾਨੂੰ ਕ੍ਰਮ ਵਿੱਚ ਦੱਸਦੇ ਹਾਂ ਕਿ ਇਸਨੂੰ ਕਿਵੇਂ ਅਤੇ ਕਿਸਨੇ ਵਿਕਸਿਤ ਕੀਤਾ, ਇਸਦਾ ਟੈਕਨਾਲੋਜੀ ਸਟੈਕ ਕੀ ਹੈ, ਅਤੇ ਸਾਡੇ ਕੋਲ ਮਾਣ ਕਰਨ ਵਾਲੀ ਕੋਈ ਚੀਜ਼ ਕਿਉਂ ਹੈ।

ਅਸਲ ਹਾਈਲੋਡ

"ਮਾਰਕਸ" ਬਹੁਤ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ, ਮੁੱਖ ਇੱਕ ਲੇਬਲ ਕੀਤੇ ਉਤਪਾਦਾਂ ਦੀ ਗਤੀ ਨੂੰ ਟਰੈਕ ਕਰਨ ਲਈ X5 ਸੂਚਨਾ ਪ੍ਰਣਾਲੀਆਂ ਅਤੇ ਲੇਬਲ ਕੀਤੇ ਉਤਪਾਦਾਂ (GIS MP) ਲਈ ਰਾਜ ਸੂਚਨਾ ਪ੍ਰਣਾਲੀ ਵਿਚਕਾਰ ਏਕੀਕਰਣ ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਹੈ। ਪਲੇਟਫਾਰਮ ਸਾਡੇ ਦੁਆਰਾ ਪ੍ਰਾਪਤ ਕੀਤੇ ਗਏ ਸਾਰੇ ਲੇਬਲਿੰਗ ਕੋਡ ਅਤੇ ਆਬਜੈਕਟ ਵਿੱਚ ਇਹਨਾਂ ਕੋਡਾਂ ਦੀ ਗਤੀ ਦੇ ਪੂਰੇ ਇਤਿਹਾਸ ਨੂੰ ਵੀ ਸਟੋਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਲੇਬਲ ਕੀਤੇ ਉਤਪਾਦਾਂ ਦੀ ਰੀ-ਗ੍ਰੇਡਿੰਗ ਨੂੰ ਖਤਮ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ। ਤੰਬਾਕੂ ਉਤਪਾਦਾਂ ਦੀ ਉਦਾਹਰਣ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਜੋ ਕਿ ਲੇਬਲ ਕੀਤੇ ਸਮਾਨ ਦੇ ਪਹਿਲੇ ਸਮੂਹਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੇ ਗਏ ਸਨ, ਸਿਗਰੇਟ ਦੇ ਸਿਰਫ਼ ਇੱਕ ਟਰੱਕ ਵਿੱਚ ਲਗਭਗ 600 ਪੈਕ ਹੁੰਦੇ ਹਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਦਾ ਆਪਣਾ ਵਿਲੱਖਣ ਕੋਡ ਹੁੰਦਾ ਹੈ। ਅਤੇ ਸਾਡੇ ਸਿਸਟਮ ਦਾ ਕੰਮ ਵੇਅਰਹਾਊਸਾਂ ਅਤੇ ਸਟੋਰਾਂ ਦੇ ਵਿਚਕਾਰ ਅਜਿਹੇ ਹਰੇਕ ਪੈਕ ਦੀ ਗਤੀਵਿਧੀ ਦੀ ਕਾਨੂੰਨੀਤਾ ਨੂੰ ਟਰੈਕ ਕਰਨਾ ਅਤੇ ਪ੍ਰਮਾਣਿਤ ਕਰਨਾ ਹੈ, ਅਤੇ ਅੰਤ ਵਿੱਚ ਅੰਤਮ ਖਰੀਦਦਾਰ ਨੂੰ ਉਹਨਾਂ ਦੀ ਵਿਕਰੀ ਦੀ ਸਵੀਕਾਰਤਾ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨਾ ਹੈ। ਅਤੇ ਅਸੀਂ ਪ੍ਰਤੀ ਘੰਟਾ ਲਗਭਗ 000 ਨਕਦ ਲੈਣ-ਦੇਣ ਰਿਕਾਰਡ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਸਾਨੂੰ ਇਹ ਵੀ ਰਿਕਾਰਡ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ ਕਿ ਅਜਿਹਾ ਹਰੇਕ ਪੈਕ ਸਟੋਰ ਵਿੱਚ ਕਿਵੇਂ ਆਇਆ। ਇਸ ਤਰ੍ਹਾਂ, ਵਸਤੂਆਂ ਦੇ ਵਿਚਕਾਰ ਸਾਰੀਆਂ ਗਤੀਆਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ, ਅਸੀਂ ਪ੍ਰਤੀ ਸਾਲ ਅਰਬਾਂ ਰਿਕਾਰਡਾਂ ਦੀ ਉਮੀਦ ਕਰ ਰਹੇ ਹਾਂ।

ਟੀਮ ਐਮ

ਇਸ ਤੱਥ ਦੇ ਬਾਵਜੂਦ ਕਿ ਮਾਰਕਸ ਨੂੰ X5 ਦੇ ਅੰਦਰ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ, ਇਹ ਇੱਕ ਉਤਪਾਦ ਪਹੁੰਚ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਲਾਗੂ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ. ਟੀਮ ਸਕਰਮ ਅਨੁਸਾਰ ਕੰਮ ਕਰਦੀ ਹੈ। ਪ੍ਰੋਜੈਕਟ ਪਿਛਲੀ ਗਰਮੀਆਂ ਵਿੱਚ ਸ਼ੁਰੂ ਹੋਇਆ ਸੀ, ਪਰ ਪਹਿਲੇ ਨਤੀਜੇ ਅਕਤੂਬਰ ਵਿੱਚ ਹੀ ਆਏ ਸਨ - ਸਾਡੀ ਆਪਣੀ ਟੀਮ ਪੂਰੀ ਤਰ੍ਹਾਂ ਇਕੱਠੀ ਕੀਤੀ ਗਈ ਸੀ, ਸਿਸਟਮ ਆਰਕੀਟੈਕਚਰ ਵਿਕਸਿਤ ਕੀਤਾ ਗਿਆ ਸੀ ਅਤੇ ਸਾਜ਼ੋ-ਸਾਮਾਨ ਖਰੀਦਿਆ ਗਿਆ ਸੀ. ਹੁਣ ਟੀਮ ਵਿੱਚ 16 ਲੋਕ ਹਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਛੇ ਬੈਕਐਂਡ ਅਤੇ ਫਰੰਟਐਂਡ ਵਿਕਾਸ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਤਿੰਨ ਸਿਸਟਮ ਵਿਸ਼ਲੇਸ਼ਣ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ। ਛੇ ਹੋਰ ਲੋਕ ਮੈਨੂਅਲ, ਲੋਡ, ਆਟੋਮੇਟਿਡ ਟੈਸਟਿੰਗ, ਅਤੇ ਉਤਪਾਦ ਰੱਖ-ਰਖਾਅ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਸਾਡੇ ਕੋਲ ਇੱਕ SRE ਮਾਹਰ ਹੈ।

ਸਾਡੀ ਟੀਮ ਵਿੱਚ ਸਿਰਫ਼ ਡਿਵੈਲਪਰ ਹੀ ਕੋਡ ਨਹੀਂ ਲਿਖਦੇ; ਲਗਭਗ ਸਾਰੇ ਲੋਕ ਜਾਣਦੇ ਹਨ ਕਿ ਆਟੋਟੈਸਟ, ਲੋਡ ਸਕ੍ਰਿਪਟਾਂ ਅਤੇ ਆਟੋਮੇਸ਼ਨ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰੋਗਰਾਮ ਕਰਨਾ ਅਤੇ ਲਿਖਣਾ ਹੈ। ਅਸੀਂ ਇਸ ਵੱਲ ਵਿਸ਼ੇਸ਼ ਧਿਆਨ ਦਿੰਦੇ ਹਾਂ, ਕਿਉਂਕਿ ਉਤਪਾਦ ਸਹਾਇਤਾ ਲਈ ਉੱਚ ਪੱਧਰੀ ਸਵੈਚਾਲਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਅਸੀਂ ਹਮੇਸ਼ਾ ਉਹਨਾਂ ਸਹਿਕਰਮੀਆਂ ਨੂੰ ਸਲਾਹ ਦੇਣ ਅਤੇ ਉਹਨਾਂ ਦੀ ਮਦਦ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ ਜਿਹਨਾਂ ਨੇ ਪਹਿਲਾਂ ਪ੍ਰੋਗਰਾਮ ਨਹੀਂ ਕੀਤਾ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਕੰਮ ਕਰਨ ਲਈ ਕੁਝ ਛੋਟੇ ਕੰਮ ਦਿੰਦੇ ਹਾਂ।

ਕੋਰੋਨਵਾਇਰਸ ਮਹਾਂਮਾਰੀ ਦੇ ਕਾਰਨ, ਅਸੀਂ ਪੂਰੀ ਟੀਮ ਨੂੰ ਰਿਮੋਟ ਕੰਮ ਵਿੱਚ ਤਬਦੀਲ ਕਰ ਦਿੱਤਾ; ਵਿਕਾਸ ਪ੍ਰਬੰਧਨ ਲਈ ਸਾਰੇ ਸਾਧਨਾਂ ਦੀ ਉਪਲਬਧਤਾ, ਜੀਰਾ ਅਤੇ ਗਿਟਲੈਬ ਵਿੱਚ ਬਣੇ ਵਰਕਫਲੋ ਨੇ ਇਸ ਪੜਾਅ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਪਾਰ ਕਰਨਾ ਸੰਭਵ ਬਣਾਇਆ। ਰਿਮੋਟ ਤੌਰ 'ਤੇ ਬਿਤਾਏ ਗਏ ਮਹੀਨਿਆਂ ਨੇ ਦਿਖਾਇਆ ਕਿ ਨਤੀਜੇ ਵਜੋਂ ਟੀਮ ਦੀ ਉਤਪਾਦਕਤਾ ਨੂੰ ਨੁਕਸਾਨ ਨਹੀਂ ਹੋਇਆ; ਬਹੁਤ ਸਾਰੇ ਲੋਕਾਂ ਲਈ, ਕੰਮ 'ਤੇ ਆਰਾਮ ਵਧਿਆ ਹੈ, ਸਿਰਫ ਲਾਈਵ ਸੰਚਾਰ ਸੀ.

ਰਿਮੋਟ ਟੀਮ ਮੀਟਿੰਗ

ਰਿਮੋਟ ਕੰਮ ਦੌਰਾਨ ਮੀਟਿੰਗਾਂ

ਹੱਲ ਦਾ ਤਕਨਾਲੋਜੀ ਸਟੈਕ

X5 ਲਈ ਸਟੈਂਡਰਡ ਰਿਪੋਜ਼ਟਰੀ ਅਤੇ CI/CD ਟੂਲ GitLab ਹੈ। ਅਸੀਂ ਇਸਨੂੰ ਕੋਡ ਸਟੋਰੇਜ, ਨਿਰੰਤਰ ਟੈਸਟਿੰਗ, ਅਤੇ ਟੈਸਟ ਅਤੇ ਉਤਪਾਦਨ ਸਰਵਰਾਂ ਲਈ ਤੈਨਾਤੀ ਲਈ ਵਰਤਦੇ ਹਾਂ। ਅਸੀਂ ਕੋਡ ਸਮੀਖਿਆ ਦੇ ਅਭਿਆਸ ਦੀ ਵੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ, ਜਦੋਂ ਘੱਟੋ-ਘੱਟ 2 ਸਹਿਕਰਮੀਆਂ ਨੂੰ ਡਿਵੈਲਪਰ ਦੁਆਰਾ ਕੋਡ ਵਿੱਚ ਕੀਤੀਆਂ ਤਬਦੀਲੀਆਂ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਸਟੈਟਿਕ ਕੋਡ ਐਨਾਲਾਈਜ਼ਰ SonarQube ਅਤੇ JaCoCo ਸਾਡੇ ਕੋਡ ਨੂੰ ਸਾਫ਼ ਰੱਖਣ ਅਤੇ ਯੂਨਿਟ ਟੈਸਟ ਕਵਰੇਜ ਦੇ ਲੋੜੀਂਦੇ ਪੱਧਰ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਵਿੱਚ ਸਾਡੀ ਮਦਦ ਕਰਦੇ ਹਨ। ਕੋਡ ਵਿੱਚ ਸਾਰੀਆਂ ਤਬਦੀਲੀਆਂ ਇਹਨਾਂ ਜਾਂਚਾਂ ਵਿੱਚੋਂ ਲੰਘਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਸਾਰੀਆਂ ਟੈਸਟ ਸਕ੍ਰਿਪਟਾਂ ਜੋ ਹੱਥੀਂ ਚਲਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਬਾਅਦ ਵਿੱਚ ਸਵੈਚਲਿਤ ਹੁੰਦੀਆਂ ਹਨ।

"ਮਾਰਕਸ" ਦੁਆਰਾ ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਸਫਲਤਾਪੂਰਵਕ ਲਾਗੂ ਕਰਨ ਲਈ, ਸਾਨੂੰ ਕਈ ਤਕਨੀਕੀ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨਾ ਪਿਆ, ਹਰ ਇੱਕ ਕ੍ਰਮ ਵਿੱਚ.

ਟਾਸਕ 1. ਸਿਸਟਮ ਦੀ ਹਰੀਜੱਟਲ ਸਕੇਲੇਬਿਲਟੀ ਦੀ ਲੋੜ

ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ, ਅਸੀਂ ਆਰਕੀਟੈਕਚਰ ਲਈ ਇੱਕ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਪਹੁੰਚ ਨੂੰ ਚੁਣਿਆ ਹੈ। ਇਸ ਦੇ ਨਾਲ ਹੀ ਸੇਵਾਵਾਂ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਦੇ ਖੇਤਰਾਂ ਨੂੰ ਸਮਝਣਾ ਬਹੁਤ ਜ਼ਰੂਰੀ ਸੀ। ਅਸੀਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ, ਉਹਨਾਂ ਨੂੰ ਵਪਾਰਕ ਕਾਰਜਾਂ ਵਿੱਚ ਵੰਡਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ। ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਵੇਅਰਹਾਊਸ ਵਿੱਚ ਸਵੀਕ੍ਰਿਤੀ ਇੱਕ ਬਹੁਤ ਹੀ ਅਕਸਰ ਨਹੀਂ ਹੈ, ਪਰ ਬਹੁਤ ਵੱਡੇ ਪੈਮਾਨੇ ਦੀ ਕਾਰਵਾਈ ਹੈ, ਜਿਸ ਦੌਰਾਨ ਸਵੀਕਾਰ ਕੀਤੇ ਜਾ ਰਹੇ ਮਾਲ ਦੀਆਂ ਇਕਾਈਆਂ ਬਾਰੇ ਰਾਜ ਰੈਗੂਲੇਟਰ ਤੋਂ ਤੁਰੰਤ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰਨੀ ਜ਼ਰੂਰੀ ਹੈ, ਜਿਸਦੀ ਗਿਣਤੀ ਇੱਕ ਡਿਲਿਵਰੀ ਵਿੱਚ 600000 ਤੱਕ ਪਹੁੰਚ ਜਾਂਦੀ ਹੈ. , ਇਸ ਉਤਪਾਦ ਨੂੰ ਵੇਅਰਹਾਊਸ ਵਿੱਚ ਸਵੀਕਾਰ ਕਰਨ ਦੀ ਮਨਜ਼ੂਰੀ ਦੀ ਜਾਂਚ ਕਰੋ ਅਤੇ ਵੇਅਰਹਾਊਸ ਆਟੋਮੇਸ਼ਨ ਸਿਸਟਮ ਲਈ ਸਾਰੀ ਲੋੜੀਂਦੀ ਜਾਣਕਾਰੀ ਵਾਪਸ ਕਰੋ। ਪਰ ਵੇਅਰਹਾਊਸਾਂ ਤੋਂ ਸ਼ਿਪਮੈਂਟ ਦੀ ਬਹੁਤ ਜ਼ਿਆਦਾ ਤੀਬਰਤਾ ਹੁੰਦੀ ਹੈ, ਪਰ ਉਸੇ ਸਮੇਂ ਡੇਟਾ ਦੀ ਛੋਟੀ ਜਿਹੀ ਮਾਤਰਾ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ.

ਅਸੀਂ ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ ਨੂੰ ਰਾਜ ਰਹਿਤ ਆਧਾਰ 'ਤੇ ਲਾਗੂ ਕਰਦੇ ਹਾਂ ਅਤੇ ਅੰਦਰੂਨੀ ਕਾਰਵਾਈਆਂ ਨੂੰ ਕਦਮਾਂ ਵਿੱਚ ਵੰਡਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਵੀ ਕਰਦੇ ਹਾਂ, ਜਿਸਨੂੰ ਅਸੀਂ ਕਾਫਕਾ ਸਵੈ-ਵਿਸ਼ੇ ਕਹਿੰਦੇ ਹਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ। ਇਹ ਉਦੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇੱਕ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਆਪਣੇ ਆਪ ਨੂੰ ਇੱਕ ਸੁਨੇਹਾ ਭੇਜਦਾ ਹੈ, ਜੋ ਤੁਹਾਨੂੰ ਵਧੇਰੇ ਸਰੋਤ-ਸੰਬੰਧੀ ਕਾਰਜਾਂ 'ਤੇ ਲੋਡ ਨੂੰ ਸੰਤੁਲਿਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਅਤੇ ਉਤਪਾਦ ਰੱਖ-ਰਖਾਅ ਨੂੰ ਸੌਖਾ ਬਣਾਉਂਦਾ ਹੈ, ਪਰ ਬਾਅਦ ਵਿੱਚ ਇਸ 'ਤੇ ਹੋਰ।

ਅਸੀਂ ਵੱਖ-ਵੱਖ ਸੇਵਾਵਾਂ ਵਿੱਚ ਬਾਹਰੀ ਪ੍ਰਣਾਲੀਆਂ ਨਾਲ ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਲਈ ਮਾਡਿਊਲਾਂ ਨੂੰ ਵੱਖ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ। ਇਸ ਨਾਲ ਬਾਹਰੀ ਪ੍ਰਣਾਲੀਆਂ ਦੇ ਅਕਸਰ ਬਦਲਦੇ API ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨਾ ਸੰਭਵ ਹੋ ਗਿਆ ਹੈ, ਜਿਸ ਨਾਲ ਵਪਾਰਕ ਕਾਰਜਸ਼ੀਲਤਾ ਵਾਲੀਆਂ ਸੇਵਾਵਾਂ 'ਤੇ ਅਸਲ ਵਿੱਚ ਕੋਈ ਪ੍ਰਭਾਵ ਨਹੀਂ ਪੈਂਦਾ।

ਸਾਰੀਆਂ ਮਾਈਕ੍ਰੋਸੇਵਾਵਾਂ ਨੂੰ ਇੱਕ ਓਪਨਸ਼ਿਫਟ ਕਲੱਸਟਰ ਵਿੱਚ ਤੈਨਾਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜੋ ਹਰੇਕ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਨੂੰ ਸਕੇਲਿੰਗ ਕਰਨ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ ਅਤੇ ਸਾਨੂੰ ਤੀਜੀ-ਧਿਰ ਦੇ ਸੇਵਾ ਖੋਜ ਟੂਲਸ ਦੀ ਵਰਤੋਂ ਨਾ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।

ਟਾਸਕ 2. ਪਲੇਟਫਾਰਮ ਸੇਵਾਵਾਂ ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਉੱਚ ਲੋਡ ਅਤੇ ਬਹੁਤ ਤੀਬਰ ਡੇਟਾ ਐਕਸਚੇਂਜ ਨੂੰ ਬਣਾਈ ਰੱਖਣ ਦੀ ਜ਼ਰੂਰਤ: ਇਕੱਲੇ ਪ੍ਰੋਜੈਕਟ ਲਾਂਚ ਪੜਾਅ ਦੌਰਾਨ, ਪ੍ਰਤੀ ਸਕਿੰਟ ਲਗਭਗ 600 ਓਪਰੇਸ਼ਨ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਅਸੀਂ ਉਮੀਦ ਕਰਦੇ ਹਾਂ ਕਿ ਇਹ ਮੁੱਲ 5000 ਓਪਸ/ਸੈਕੰਡ ਤੱਕ ਵਧ ਜਾਵੇਗਾ ਕਿਉਂਕਿ ਰਿਟੇਲ ਆਊਟਲੇਟ ਸਾਡੇ ਪਲੇਟਫਾਰਮ ਨਾਲ ਜੁੜਦੇ ਹਨ।

ਇਹ ਸਮੱਸਿਆ ਇੱਕ ਕਾਫਕਾ ਕਲੱਸਟਰ ਨੂੰ ਤੈਨਾਤ ਕਰਕੇ ਅਤੇ ਪਲੇਟਫਾਰਮ ਦੇ ਮਾਈਕ੍ਰੋਸਰਵਿਸਜ਼ ਵਿਚਕਾਰ ਸਮਕਾਲੀ ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਨੂੰ ਲਗਭਗ ਪੂਰੀ ਤਰ੍ਹਾਂ ਛੱਡ ਕੇ ਹੱਲ ਕੀਤਾ ਗਿਆ ਸੀ। ਇਸ ਲਈ ਸਿਸਟਮ ਲੋੜਾਂ ਦੇ ਬਹੁਤ ਧਿਆਨ ਨਾਲ ਵਿਸ਼ਲੇਸ਼ਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਕਿਉਂਕਿ ਸਾਰੇ ਓਪਰੇਸ਼ਨ ਅਸਿੰਕ੍ਰੋਨਸ ਨਹੀਂ ਹੋ ਸਕਦੇ ਹਨ। ਇਸ ਦੇ ਨਾਲ ਹੀ, ਅਸੀਂ ਨਾ ਸਿਰਫ਼ ਬ੍ਰੋਕਰ ਰਾਹੀਂ ਇਵੈਂਟਾਂ ਨੂੰ ਪ੍ਰਸਾਰਿਤ ਕਰਦੇ ਹਾਂ, ਸਗੋਂ ਸੰਦੇਸ਼ ਵਿੱਚ ਸਾਰੀਆਂ ਲੋੜੀਂਦੀ ਵਪਾਰਕ ਜਾਣਕਾਰੀ ਵੀ ਪ੍ਰਸਾਰਿਤ ਕਰਦੇ ਹਾਂ। ਇਸ ਤਰ੍ਹਾਂ, ਸੰਦੇਸ਼ ਦਾ ਆਕਾਰ ਕਈ ਸੌ ਕਿਲੋਬਾਈਟ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ। ਕਾਫਕਾ ਵਿੱਚ ਸੁਨੇਹਾ ਆਕਾਰ ਸੀਮਾ ਸਾਨੂੰ ਸੁਨੇਹੇ ਦੇ ਆਕਾਰ ਦਾ ਸਹੀ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਦੀ ਮੰਗ ਕਰਦੀ ਹੈ, ਅਤੇ ਜੇਕਰ ਲੋੜ ਹੋਵੇ, ਤਾਂ ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਵੰਡਦੇ ਹਾਂ, ਪਰ ਇਹ ਵੰਡ ਵਪਾਰਕ ਕਾਰਜਾਂ ਨਾਲ ਸੰਬੰਧਿਤ, ਤਰਕਪੂਰਨ ਹੈ।
ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ ਕਾਰ ਵਿੱਚ ਆਉਣ ਵਾਲੇ ਸਮਾਨ ਨੂੰ ਡੱਬਿਆਂ ਵਿੱਚ ਵੰਡਦੇ ਹਾਂ। ਸਮਕਾਲੀ ਓਪਰੇਸ਼ਨਾਂ ਲਈ, ਵੱਖਰੀਆਂ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਨਿਰਧਾਰਤ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਲੋਡ ਟੈਸਟਿੰਗ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਕਾਫਕਾ ਦੀ ਵਰਤੋਂ ਨਾਲ ਸਾਨੂੰ ਇੱਕ ਹੋਰ ਚੁਣੌਤੀ ਪੇਸ਼ ਕੀਤੀ ਗਈ - ਕਾਫਕਾ ਏਕੀਕਰਣ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ ਸਾਡੀ ਸੇਵਾ ਦੇ ਸੰਚਾਲਨ ਦੀ ਜਾਂਚ ਕਰਨਾ ਸਾਡੇ ਸਾਰੇ ਯੂਨਿਟ ਟੈਸਟਾਂ ਨੂੰ ਅਸਿੰਕ੍ਰੋਨਸ ਬਣਾਉਂਦਾ ਹੈ। ਅਸੀਂ ਏਮਬੈਡਡ ਕਾਫਕਾ ਬ੍ਰੋਕਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਆਪਣੇ ਖੁਦ ਦੇ ਉਪਯੋਗਤਾ ਤਰੀਕਿਆਂ ਨੂੰ ਲਿਖ ਕੇ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕੀਤਾ ਹੈ। ਇਹ ਵਿਅਕਤੀਗਤ ਤਰੀਕਿਆਂ ਲਈ ਯੂਨਿਟ ਟੈਸਟ ਲਿਖਣ ਦੀ ਜ਼ਰੂਰਤ ਨੂੰ ਖਤਮ ਨਹੀਂ ਕਰਦਾ ਹੈ, ਪਰ ਅਸੀਂ ਕਾਫਕਾ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਗੁੰਝਲਦਾਰ ਕੇਸਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੇ ਹਾਂ।

ਟਰੇਸਿੰਗ ਲੌਗਸ 'ਤੇ ਬਹੁਤ ਧਿਆਨ ਦਿੱਤਾ ਗਿਆ ਸੀ ਤਾਂ ਜੋ ਸੇਵਾਵਾਂ ਦੇ ਸੰਚਾਲਨ ਦੌਰਾਨ ਜਾਂ ਕਾਫਕਾ ਬੈਚ ਦੇ ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ ਅਪਵਾਦ ਹੋਣ 'ਤੇ ਉਹਨਾਂ ਦੀ ਟਰੇਸਆਈਡੀ ਗੁੰਮ ਨਾ ਹੋਵੇ। ਅਤੇ ਜੇਕਰ ਪਹਿਲੇ ਦੇ ਨਾਲ ਕੋਈ ਖਾਸ ਸਮੱਸਿਆਵਾਂ ਨਹੀਂ ਸਨ, ਤਾਂ ਦੂਜੇ ਮਾਮਲੇ ਵਿੱਚ ਸਾਨੂੰ ਉਹਨਾਂ ਸਾਰੇ TraceIds ਨੂੰ ਲੌਗ ਕਰਨ ਲਈ ਮਜ਼ਬੂਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜੋ ਬੈਚ ਦੇ ਨਾਲ ਆਇਆ ਸੀ ਅਤੇ ਟਰੇਸਿੰਗ ਜਾਰੀ ਰੱਖਣ ਲਈ ਇੱਕ ਦੀ ਚੋਣ ਕਰੋ। ਫਿਰ, ਅਸਲੀ TraceId ਦੁਆਰਾ ਖੋਜ ਕਰਨ 'ਤੇ, ਉਪਭੋਗਤਾ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਪਤਾ ਲੱਗ ਜਾਵੇਗਾ ਕਿ ਕਿਸ ਨਾਲ ਟਰੇਸਿੰਗ ਜਾਰੀ ਹੈ।

ਟਾਸਕ 3. ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਡੇਟਾ ਸਟੋਰ ਕਰਨ ਦੀ ਲੋੜ: ਇਕੱਲੇ ਤੰਬਾਕੂ ਲਈ ਪ੍ਰਤੀ ਸਾਲ 1 ਬਿਲੀਅਨ ਤੋਂ ਵੱਧ ਲੇਬਲ X5 'ਤੇ ਆਉਂਦੇ ਹਨ। ਉਹਨਾਂ ਨੂੰ ਨਿਰੰਤਰ ਅਤੇ ਤੇਜ਼ ਪਹੁੰਚ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਕੁੱਲ ਮਿਲਾ ਕੇ, ਸਿਸਟਮ ਨੂੰ ਇਹਨਾਂ ਲੇਬਲ ਕੀਤੇ ਸਮਾਨ ਦੇ ਅੰਦੋਲਨ ਦੇ ਇਤਿਹਾਸ ਦੇ ਲਗਭਗ 10 ਬਿਲੀਅਨ ਰਿਕਾਰਡਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।

ਤੀਜੀ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ, NoSQL ਡੇਟਾਬੇਸ MongoDB ਨੂੰ ਚੁਣਿਆ ਗਿਆ ਸੀ। ਅਸੀਂ 5 ਨੋਡਾਂ ਦਾ ਇੱਕ ਸ਼ਾਰਡ ਬਣਾਇਆ ਹੈ ਅਤੇ ਹਰੇਕ ਨੋਡ ਵਿੱਚ 3 ਸਰਵਰਾਂ ਦਾ ਪ੍ਰਤੀਰੂਪ ਸੈੱਟ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਸਿਸਟਮ ਨੂੰ ਖਿਤਿਜੀ ਤੌਰ 'ਤੇ ਸਕੇਲ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਕਲੱਸਟਰ ਵਿੱਚ ਨਵੇਂ ਸਰਵਰਾਂ ਨੂੰ ਜੋੜਦਾ ਹੈ, ਅਤੇ ਇਸਦੀ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ। ਇੱਥੇ ਸਾਨੂੰ ਇੱਕ ਹੋਰ ਸਮੱਸਿਆ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ - ਮੋਂਗੋ ਕਲੱਸਟਰ ਵਿੱਚ ਲੈਣ-ਦੇਣ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣਾ, ਹਰੀਜੋਂਟਲੀ ਸਕੇਲੇਬਲ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਦੀ ਵਰਤੋਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ। ਉਦਾਹਰਨ ਲਈ, ਸਾਡੇ ਸਿਸਟਮ ਦੇ ਕਾਰਜਾਂ ਵਿੱਚੋਂ ਇੱਕ ਸਮਾਨ ਲੇਬਲਿੰਗ ਕੋਡਾਂ ਵਾਲੇ ਉਤਪਾਦਾਂ ਨੂੰ ਮੁੜ-ਵੇਚਣ ਦੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਦੀ ਪਛਾਣ ਕਰਨਾ ਹੈ। ਇੱਥੇ, ਓਵਰਲੇਜ਼ ਗਲਤ ਸਕੈਨ ਜਾਂ ਕੈਸ਼ੀਅਰਾਂ ਦੁਆਰਾ ਗਲਤ ਕਾਰਵਾਈਆਂ ਨਾਲ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ। ਅਸੀਂ ਪਾਇਆ ਹੈ ਕਿ ਅਜਿਹੇ ਡੁਪਲੀਕੇਟ ਇੱਕ ਕਾਫਕਾ ਬੈਚ ਦੇ ਅੰਦਰ, ਅਤੇ ਦੋ ਬੈਚਾਂ ਵਿੱਚ ਸਮਾਨਾਂਤਰ ਪ੍ਰਕਿਰਿਆ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ। ਇਸ ਤਰ੍ਹਾਂ, ਡੇਟਾਬੇਸ ਦੀ ਪੁੱਛਗਿੱਛ ਕਰਕੇ ਡੁਪਲੀਕੇਟ ਦੀ ਜਾਂਚ ਕਰਨ ਨਾਲ ਕੁਝ ਨਹੀਂ ਮਿਲਿਆ. ਹਰੇਕ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਲਈ, ਅਸੀਂ ਇਸ ਸੇਵਾ ਦੇ ਵਪਾਰਕ ਤਰਕ ਦੇ ਆਧਾਰ 'ਤੇ ਸਮੱਸਿਆ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਹੱਲ ਕੀਤਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਜਾਂਚਾਂ ਲਈ, ਅਸੀਂ ਬੈਚ ਦੇ ਅੰਦਰ ਇੱਕ ਜਾਂਚ ਅਤੇ ਸੰਮਿਲਿਤ ਕਰਨ ਵੇਲੇ ਡੁਪਲੀਕੇਟ ਦੀ ਦਿੱਖ ਲਈ ਵੱਖਰੀ ਪ੍ਰਕਿਰਿਆ ਸ਼ਾਮਲ ਕੀਤੀ ਹੈ।

ਇਹ ਸੁਨਿਸ਼ਚਿਤ ਕਰਨ ਲਈ ਕਿ ਓਪਰੇਸ਼ਨਾਂ ਦੇ ਇਤਿਹਾਸ ਦੇ ਨਾਲ ਉਪਭੋਗਤਾਵਾਂ ਦਾ ਕੰਮ ਕਿਸੇ ਵੀ ਤਰੀਕੇ ਨਾਲ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਚੀਜ਼ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰਦਾ - ਸਾਡੀਆਂ ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਕੰਮਕਾਜ, ਅਸੀਂ ਸਾਰੇ ਇਤਿਹਾਸਕ ਡੇਟਾ ਨੂੰ ਇੱਕ ਵੱਖਰੇ ਡੇਟਾਬੇਸ ਦੇ ਨਾਲ ਇੱਕ ਵੱਖਰੀ ਸੇਵਾ ਵਿੱਚ ਵੱਖ ਕੀਤਾ ਹੈ, ਜੋ ਕਾਫਕਾ ਦੁਆਰਾ ਵੀ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ. . ਇਸ ਤਰ੍ਹਾਂ, ਵਰਤੋਂਕਾਰ ਚੱਲ ਰਹੇ ਓਪਰੇਸ਼ਨਾਂ ਲਈ ਡੇਟਾ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਵਾਲੀਆਂ ਸੇਵਾਵਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤੇ ਬਿਨਾਂ ਇੱਕ ਅਲੱਗ ਸੇਵਾ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ।

ਟਾਸਕ 4: ਕਤਾਰ ਰੀਪ੍ਰੋਸੈਸਿੰਗ ਅਤੇ ਨਿਗਰਾਨੀ:

ਵਿਤਰਿਤ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ, ਡਾਟਾਬੇਸ, ਕਤਾਰਾਂ ਅਤੇ ਬਾਹਰੀ ਡੇਟਾ ਸਰੋਤਾਂ ਦੀ ਉਪਲਬਧਤਾ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਅਤੇ ਗਲਤੀਆਂ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਪੈਦਾ ਹੁੰਦੀਆਂ ਹਨ। ਮਾਰਕਸ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਅਜਿਹੀਆਂ ਗਲਤੀਆਂ ਦਾ ਸਰੋਤ ਬਾਹਰੀ ਪ੍ਰਣਾਲੀਆਂ ਨਾਲ ਏਕੀਕਰਣ ਹੈ। ਅਜਿਹਾ ਹੱਲ ਲੱਭਣਾ ਜ਼ਰੂਰੀ ਸੀ ਜੋ ਕੁਝ ਨਿਰਧਾਰਤ ਸਮਾਂ ਸਮਾਪਤੀ ਦੇ ਨਾਲ ਗਲਤ ਜਵਾਬਾਂ ਲਈ ਵਾਰ-ਵਾਰ ਬੇਨਤੀਆਂ ਦੀ ਆਗਿਆ ਦੇਵੇ, ਪਰ ਉਸੇ ਸਮੇਂ ਮੁੱਖ ਕਤਾਰ ਵਿੱਚ ਸਫਲ ਬੇਨਤੀਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਬੰਦ ਨਾ ਕਰੇ। ਇਸ ਉਦੇਸ਼ ਲਈ, ਅਖੌਤੀ "ਵਿਸ਼ਾ ਅਧਾਰਤ ਮੁੜ ਕੋਸ਼ਿਸ਼" ਸੰਕਲਪ ਨੂੰ ਚੁਣਿਆ ਗਿਆ ਸੀ। ਹਰੇਕ ਮੁੱਖ ਵਿਸ਼ੇ ਲਈ, ਇੱਕ ਜਾਂ ਇੱਕ ਤੋਂ ਵੱਧ ਮੁੜ-ਕੋਸ਼ਿਸ਼ ਕਰਨ ਵਾਲੇ ਵਿਸ਼ੇ ਬਣਾਏ ਜਾਂਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਗਲਤ ਸੰਦੇਸ਼ ਭੇਜੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਉਸੇ ਸਮੇਂ ਮੁੱਖ ਵਿਸ਼ੇ ਤੋਂ ਸੁਨੇਹਿਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਦੇਰੀ ਨੂੰ ਖਤਮ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇੰਟਰਐਕਸ਼ਨ ਸਕੀਮ -

ਅਜਿਹੀ ਸਕੀਮ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ, ਸਾਨੂੰ ਹੇਠ ਲਿਖਿਆਂ ਦੀ ਲੋੜ ਸੀ: ਬਸੰਤ ਨਾਲ ਇਸ ਹੱਲ ਨੂੰ ਜੋੜਨ ਅਤੇ ਕੋਡ ਡੁਪਲੀਕੇਸ਼ਨ ਤੋਂ ਬਚਣ ਲਈ। ਵੈੱਬ 'ਤੇ ਸਰਫਿੰਗ ਕਰਦੇ ਸਮੇਂ, ਅਸੀਂ Spring BeanPostProccessor 'ਤੇ ਆਧਾਰਿਤ ਇੱਕ ਸਮਾਨ ਹੱਲ ਲੱਭਿਆ, ਪਰ ਇਹ ਸਾਡੇ ਲਈ ਬੇਲੋੜਾ ਬੋਝਲ ਜਾਪਦਾ ਸੀ। ਸਾਡੀ ਟੀਮ ਨੇ ਇੱਕ ਸਰਲ ਹੱਲ ਤਿਆਰ ਕੀਤਾ ਹੈ ਜੋ ਸਾਨੂੰ ਖਪਤਕਾਰ ਬਣਾਉਣ ਲਈ ਬਸੰਤ ਚੱਕਰ ਵਿੱਚ ਏਕੀਕ੍ਰਿਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਅਤੇ ਇਸ ਤੋਂ ਇਲਾਵਾ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਵਾਲੇ ਖਪਤਕਾਰਾਂ ਨੂੰ ਜੋੜਦਾ ਹੈ। ਅਸੀਂ ਬਸੰਤ ਟੀਮ ਨੂੰ ਸਾਡੇ ਹੱਲ ਦਾ ਇੱਕ ਪ੍ਰੋਟੋਟਾਈਪ ਪੇਸ਼ ਕੀਤਾ, ਤੁਸੀਂ ਇਸਨੂੰ ਦੇਖ ਸਕਦੇ ਹੋ ਇੱਥੇ. ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਵਾਲੇ ਖਪਤਕਾਰਾਂ ਦੀ ਸੰਖਿਆ ਅਤੇ ਹਰੇਕ ਖਪਤਕਾਰ ਲਈ ਕੋਸ਼ਿਸ਼ਾਂ ਦੀ ਸੰਖਿਆ ਨੂੰ ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆ ਦੀਆਂ ਲੋੜਾਂ ਦੇ ਅਧਾਰ ਤੇ, ਪੈਰਾਮੀਟਰਾਂ ਦੁਆਰਾ ਸੰਰਚਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਸਭ ਕੁਝ ਕੰਮ ਕਰਨ ਲਈ, ਜੋ ਕੁਝ ਬਚਦਾ ਹੈ ਉਹ ਐਨੋਟੇਸ਼ਨ org.springframework.kafka.annotation.KafkaListener ਨੂੰ ਜੋੜਨਾ ਹੈ। , ਜੋ ਸਾਰੇ ਸਪਰਿੰਗ ਡਿਵੈਲਪਰਾਂ ਲਈ ਜਾਣੂ ਹੈ।

ਜੇਕਰ ਸਾਰੇ ਪੁਨਰ-ਕੋਸ਼ਿਸ਼ ਦੇ ਬਾਅਦ ਸੁਨੇਹੇ 'ਤੇ ਕਾਰਵਾਈ ਨਹੀਂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਤਾਂ ਇਹ Spring DeadLetterPublishingRecoverer ਦੀ ਵਰਤੋਂ ਕਰਕੇ DLT (ਡੈੱਡ ਲੈਟਰ ਵਿਸ਼ਾ) 'ਤੇ ਜਾਂਦਾ ਹੈ। ਸਮਰਥਨ ਦੀ ਬੇਨਤੀ 'ਤੇ, ਅਸੀਂ ਇਸ ਕਾਰਜਕੁਸ਼ਲਤਾ ਦਾ ਵਿਸਤਾਰ ਕੀਤਾ ਹੈ ਅਤੇ ਇੱਕ ਵੱਖਰੀ ਸੇਵਾ ਬਣਾਈ ਹੈ ਜੋ ਤੁਹਾਨੂੰ DLT, ਸਟੈਕਟਰੇਸ, ਟਰੇਸਆਈਡੀ ਅਤੇ ਉਹਨਾਂ ਬਾਰੇ ਹੋਰ ਉਪਯੋਗੀ ਜਾਣਕਾਰੀ ਵਿੱਚ ਸ਼ਾਮਲ ਸੁਨੇਹਿਆਂ ਨੂੰ ਦੇਖਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਸਾਰੇ ਡੀਐਲਟੀ ਵਿਸ਼ਿਆਂ ਵਿੱਚ ਨਿਗਰਾਨੀ ਅਤੇ ਚੇਤਾਵਨੀਆਂ ਸ਼ਾਮਲ ਕੀਤੀਆਂ ਗਈਆਂ ਸਨ, ਅਤੇ ਹੁਣ, ਅਸਲ ਵਿੱਚ, ਇੱਕ ਡੀਐਲਟੀ ਵਿਸ਼ੇ ਵਿੱਚ ਇੱਕ ਸੰਦੇਸ਼ ਦੀ ਦਿੱਖ ਇੱਕ ਨੁਕਸ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਹੱਲ ਕਰਨ ਦਾ ਇੱਕ ਕਾਰਨ ਹੈ। ਇਹ ਬਹੁਤ ਸੁਵਿਧਾਜਨਕ ਹੈ - ਵਿਸ਼ੇ ਦੇ ਨਾਮ ਦੁਆਰਾ, ਅਸੀਂ ਤੁਰੰਤ ਸਮਝ ਜਾਂਦੇ ਹਾਂ ਕਿ ਪ੍ਰਕਿਰਿਆ ਦੇ ਕਿਹੜੇ ਪੜਾਅ 'ਤੇ ਸਮੱਸਿਆ ਪੈਦਾ ਹੋਈ, ਜੋ ਇਸਦੇ ਮੂਲ ਕਾਰਨ ਦੀ ਖੋਜ ਨੂੰ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਤੇਜ਼ ਕਰਦਾ ਹੈ।

ਸਭ ਤੋਂ ਹਾਲ ਹੀ ਵਿੱਚ, ਅਸੀਂ ਇੱਕ ਇੰਟਰਫੇਸ ਲਾਗੂ ਕੀਤਾ ਹੈ ਜੋ ਸਾਨੂੰ ਉਹਨਾਂ ਦੇ ਕਾਰਨਾਂ (ਉਦਾਹਰਨ ਲਈ, ਬਾਹਰੀ ਸਿਸਟਮ ਦੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਬਹਾਲ ਕਰਨ) ਅਤੇ, ਬੇਸ਼ਕ, ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ ਅਨੁਸਾਰੀ ਨੁਕਸ ਨੂੰ ਸਥਾਪਿਤ ਕਰਨ ਤੋਂ ਬਾਅਦ ਸਾਡੇ ਸਮਰਥਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸੁਨੇਹਿਆਂ ਨੂੰ ਦੁਬਾਰਾ ਭੇਜਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਸਾਡੇ ਸਵੈ-ਵਿਸ਼ੇ ਕੰਮ ਆਉਂਦੇ ਹਨ: ਇੱਕ ਲੰਬੀ ਪ੍ਰੋਸੈਸਿੰਗ ਚੇਨ ਨੂੰ ਮੁੜ ਚਾਲੂ ਨਾ ਕਰਨ ਲਈ, ਤੁਸੀਂ ਇਸਨੂੰ ਲੋੜੀਂਦੇ ਪੜਾਅ ਤੋਂ ਮੁੜ ਚਾਲੂ ਕਰ ਸਕਦੇ ਹੋ।

ਪਲੇਟਫਾਰਮ ਓਪਰੇਸ਼ਨ

ਪਲੇਟਫਾਰਮ ਪਹਿਲਾਂ ਹੀ ਉਤਪਾਦਕ ਕਾਰਜ ਵਿੱਚ ਹੈ, ਹਰ ਰੋਜ਼ ਅਸੀਂ ਡਿਲੀਵਰੀ ਅਤੇ ਸ਼ਿਪਮੈਂਟ ਕਰਦੇ ਹਾਂ, ਨਵੇਂ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਸੈਂਟਰਾਂ ਅਤੇ ਸਟੋਰਾਂ ਨੂੰ ਜੋੜਦੇ ਹਾਂ। ਪਾਇਲਟ ਦੇ ਹਿੱਸੇ ਵਜੋਂ, ਸਿਸਟਮ "ਤੰਬਾਕੂ" ਅਤੇ "ਸ਼ੂਜ਼" ਉਤਪਾਦ ਸਮੂਹਾਂ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ।

ਸਾਡੀ ਪੂਰੀ ਟੀਮ ਪਾਇਲਟਾਂ ਦੇ ਸੰਚਾਲਨ ਵਿੱਚ ਹਿੱਸਾ ਲੈਂਦੀ ਹੈ, ਉੱਭਰ ਰਹੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦੀ ਹੈ ਅਤੇ ਲੌਗਸ ਨੂੰ ਸੁਧਾਰਨ ਤੋਂ ਲੈ ਕੇ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਬਦਲਣ ਤੱਕ, ਸਾਡੇ ਉਤਪਾਦ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਲਈ ਸੁਝਾਅ ਦਿੰਦੀ ਹੈ।

ਸਾਡੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਨਾ ਦੁਹਰਾਉਣ ਲਈ, ਪਾਇਲਟ ਦੌਰਾਨ ਪਾਏ ਗਏ ਸਾਰੇ ਕੇਸ ਸਵੈਚਲਿਤ ਟੈਸਟਾਂ ਵਿੱਚ ਪ੍ਰਤੀਬਿੰਬਿਤ ਹੁੰਦੇ ਹਨ। ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਆਟੋਟੈਸਟ ਅਤੇ ਯੂਨਿਟ ਟੈਸਟਾਂ ਦੀ ਮੌਜੂਦਗੀ ਤੁਹਾਨੂੰ ਰਿਗਰੈਸ਼ਨ ਟੈਸਟਿੰਗ ਕਰਨ ਅਤੇ ਕੁਝ ਘੰਟਿਆਂ ਵਿੱਚ ਸ਼ਾਬਦਿਕ ਤੌਰ 'ਤੇ ਇੱਕ ਹੌਟਫਿਕਸ ਸਥਾਪਤ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ।

ਹੁਣ ਅਸੀਂ ਆਪਣੇ ਪਲੇਟਫਾਰਮ ਦਾ ਵਿਕਾਸ ਅਤੇ ਸੁਧਾਰ ਕਰਨਾ ਜਾਰੀ ਰੱਖਦੇ ਹਾਂ, ਅਤੇ ਲਗਾਤਾਰ ਨਵੀਆਂ ਚੁਣੌਤੀਆਂ ਦਾ ਸਾਹਮਣਾ ਕਰਦੇ ਹਾਂ। ਜੇ ਤੁਸੀਂ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਅਸੀਂ ਅਗਲੇ ਲੇਖਾਂ ਵਿੱਚ ਸਾਡੇ ਹੱਲਾਂ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ.

ਸਰੋਤ: www.habr.com