ਨਿਊਰਲ ਨੈੱਟਵਰਕਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਦਿੱਖ ਦੇ ਮੁਲਾਂਕਣ ਲਈ ਸੇਵਾ ਢਾਂਚੇ ਦੀ ਆਮ ਸੰਖੇਪ ਜਾਣਕਾਰੀ

ਇੰਦਰਾਜ਼

ਹੈਲੋ!

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

ਆਉ ਆਰਕੀਟੈਕਚਰ ਦੀਆਂ ਲੋੜਾਂ ਬਾਰੇ ਗੱਲ ਕਰੀਏ, ਵੱਖ-ਵੱਖ ਢਾਂਚਾਗਤ ਚਿੱਤਰਾਂ ਨੂੰ ਵੇਖੀਏ, ਮੁਕੰਮਲ ਆਰਕੀਟੈਕਚਰ ਦੇ ਹਰੇਕ ਹਿੱਸੇ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰੀਏ, ਅਤੇ ਹੱਲ ਦੇ ਤਕਨੀਕੀ ਮੈਟ੍ਰਿਕਸ ਦਾ ਮੁਲਾਂਕਣ ਵੀ ਕਰੀਏ।

ਪੜ੍ਹਨ ਦਾ ਆਨੰਦ ਮਾਣੋ!

ਸਮੱਸਿਆ ਅਤੇ ਇਸ ਦੇ ਹੱਲ ਬਾਰੇ ਕੁਝ ਸ਼ਬਦ

ਮੁੱਖ ਵਿਚਾਰ ਇੱਕ ਫੋਟੋ ਦੇ ਅਧਾਰ ਤੇ ਦਸ-ਪੁਆਇੰਟ ਪੈਮਾਨੇ 'ਤੇ ਇੱਕ ਵਿਅਕਤੀ ਦੇ ਆਕਰਸ਼ਕਤਾ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨਾ ਹੈ।

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

ਹੁਣ ਅਸੀਂ ਸਿਖਰਲੇ ਪੱਧਰ 'ਤੇ ਮੁਲਾਂਕਣ ਪਾਈਪਲਾਈਨ ਰਾਹੀਂ ਜਾਵਾਂਗੇ, ਅਤੇ ਸਮੁੱਚੇ ਪ੍ਰੋਜੈਕਟ ਆਰਕੀਟੈਕਚਰ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਦੇ ਆਪਸੀ ਤਾਲਮੇਲ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਤ ਕਰਾਂਗੇ। 

ਆਕਰਸ਼ਕਤਾ ਮੁਲਾਂਕਣ ਪਾਈਪਲਾਈਨ 'ਤੇ ਕੰਮ ਕਰਦੇ ਸਮੇਂ, ਕੰਮ ਨੂੰ ਹੇਠਾਂ ਦਿੱਤੇ ਭਾਗਾਂ ਵਿੱਚ ਵਿਗਾੜ ਦਿੱਤਾ ਗਿਆ ਸੀ:

1. ਫ਼ੋਟੋਆਂ ਵਿੱਚ ਚਿਹਰੇ ਚੁਣਨਾ
2. ਹਰੇਕ ਵਿਅਕਤੀ ਦੀ ਰੇਟਿੰਗ
3. ਨਤੀਜਾ ਪੇਸ਼ ਕਰੋ

ਪਹਿਲਾਂ ਪੂਰਵ-ਸਿਖਿਅਤ ਦੀਆਂ ਤਾਕਤਾਂ ਦੁਆਰਾ ਹੱਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ MTCNN. ਦੂਜੇ ਲਈ, ਇੱਕ ਕਨਵੋਲਿਊਸ਼ਨਲ ਨਿਊਰਲ ਨੈਟਵਰਕ ਨੂੰ ਪਾਈਟੋਰਚ 'ਤੇ ਸਿਖਲਾਈ ਦਿੱਤੀ ਗਈ ਸੀ, ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ResNet34 - ਸੰਤੁਲਨ ਤੋਂ "CPU 'ਤੇ ਅਨੁਮਾਨ ਦੀ ਗੁਣਵੱਤਾ / ਗਤੀ"

ਮੁਲਾਂਕਣ ਪਾਈਪਲਾਈਨ ਦਾ ਕਾਰਜਸ਼ੀਲ ਚਿੱਤਰ

ਪ੍ਰੋਜੈਕਟ ਆਰਕੀਟੈਕਚਰ ਲੋੜਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ

ਜੀਵਨ-ਚੱਕਰ ਵਿਚ ML ਮਾਡਲ ਡਿਪਲਾਇਮੈਂਟ ਦੇ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਆਟੋਮੇਸ਼ਨ 'ਤੇ ਕੰਮ ਦੇ ਪ੍ਰੋਜੈਕਟ ਪੜਾਅ ਅਕਸਰ ਸਭ ਤੋਂ ਵੱਧ ਸਮਾਂ ਲੈਣ ਵਾਲੇ ਅਤੇ ਸਰੋਤਾਂ ਦੀ ਖਪਤ ਕਰਨ ਵਾਲੇ ਹੁੰਦੇ ਹਨ।

ਇੱਕ ML ਪ੍ਰੋਜੈਕਟ ਦਾ ਜੀਵਨ ਚੱਕਰ

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

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

ਆਰਕੀਟੈਕਚਰ

ਲੋੜਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਗਿਆ ਕਿ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਆਰਕੀਟੈਕਚਰ ਲਗਭਗ ਪੂਰੀ ਤਰ੍ਹਾਂ ਫਿੱਟ ਹੈ।

ਬੇਲੋੜੇ ਸਿਰ ਦਰਦ ਤੋਂ ਛੁਟਕਾਰਾ ਪਾਉਣ ਲਈ, ਟੈਲੀਗ੍ਰਾਮ API ਨੂੰ ਫਰੰਟਐਂਡ ਵਜੋਂ ਚੁਣਿਆ ਗਿਆ ਸੀ।

ਪਹਿਲਾਂ, ਆਉ ਤਿਆਰ ਆਰਕੀਟੈਕਚਰ ਦੇ ਢਾਂਚਾਗਤ ਚਿੱਤਰ ਨੂੰ ਵੇਖੀਏ, ਫਿਰ ਹਰੇਕ ਭਾਗ ਦੇ ਵਰਣਨ ਵੱਲ ਵਧੀਏ, ਅਤੇ ਸਫਲ ਚਿੱਤਰ ਪ੍ਰੋਸੈਸਿੰਗ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਵੀ ਰਸਮੀ ਬਣਾਓ।

ਮੁਕੰਮਲ ਆਰਕੀਟੈਕਚਰ ਦਾ ਢਾਂਚਾਗਤ ਚਿੱਤਰ

ਆਉ ਚਿੱਤਰ ਦੇ ਮੁਲਾਂਕਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਉਹਨਾਂ ਨੂੰ ਸਿੰਗਲ ਜ਼ਿੰਮੇਵਾਰੀ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹੋਏ, ਚਿੱਤਰ ਦੇ ਹਰੇਕ ਹਿੱਸੇ ਬਾਰੇ ਵਧੇਰੇ ਵਿਸਥਾਰ ਵਿੱਚ ਗੱਲ ਕਰੀਏ।

ਮਾਈਕ੍ਰੋਸਰਵਿਸ “ਅਟ੍ਰਾਈ-ਟੈਲੀਗ੍ਰਾਮ-ਬੋਟ”

ਇਹ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਟੈਲੀਗ੍ਰਾਮ API ਨਾਲ ਸਾਰੀਆਂ ਪਰਸਪਰ ਕ੍ਰਿਆਵਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ। ਇੱਥੇ 2 ਮੁੱਖ ਦ੍ਰਿਸ਼ ਹਨ: ਇੱਕ ਕਸਟਮ ਚਿੱਤਰ ਦੇ ਨਾਲ ਕੰਮ ਕਰਨਾ ਅਤੇ ਇੱਕ ਮੁਲਾਂਕਣ ਪਾਈਪਲਾਈਨ ਦੇ ਨਤੀਜੇ ਦੇ ਨਾਲ ਕੰਮ ਕਰਨਾ। ਆਉ ਆਮ ਸ਼ਬਦਾਂ ਵਿੱਚ ਦੋਵਾਂ ਦ੍ਰਿਸ਼ਾਂ ਨੂੰ ਵੇਖੀਏ।

ਇੱਕ ਚਿੱਤਰ ਦੇ ਨਾਲ ਇੱਕ ਕਸਟਮ ਸੁਨੇਹਾ ਪ੍ਰਾਪਤ ਕਰਨ ਵੇਲੇ:

1. ਫਿਲਟਰੇਸ਼ਨ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ ਹੇਠ ਲਿਖੀਆਂ ਜਾਂਚਾਂ ਸ਼ਾਮਲ ਹੁੰਦੀਆਂ ਹਨ:
   • ਅਨੁਕੂਲ ਚਿੱਤਰ ਆਕਾਰ ਦੀ ਉਪਲਬਧਤਾ
   • ਕਤਾਰ ਵਿੱਚ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਉਪਭੋਗਤਾ ਚਿੱਤਰਾਂ ਦੀ ਸੰਖਿਆ
2. ਸ਼ੁਰੂਆਤੀ ਫਿਲਟਰਿੰਗ ਪਾਸ ਕਰਦੇ ਸਮੇਂ, ਚਿੱਤਰ ਨੂੰ ਡੌਕਰ ਵਾਲੀਅਮ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ
3. ਇੱਕ ਕੰਮ "to_estimate" ਕਤਾਰ ਵਿੱਚ ਤਿਆਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ, ਹੋਰ ਚੀਜ਼ਾਂ ਦੇ ਨਾਲ, ਸਾਡੇ ਵਾਲੀਅਮ ਵਿੱਚ ਸਥਿਤ ਚਿੱਤਰ ਦਾ ਮਾਰਗ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ
4. ਜੇਕਰ ਉਪਰੋਕਤ ਕਦਮ ਸਫਲਤਾਪੂਰਵਕ ਪੂਰੇ ਹੋ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਉਪਭੋਗਤਾ ਨੂੰ ਅੰਦਾਜ਼ਨ ਚਿੱਤਰ ਪ੍ਰੋਸੈਸਿੰਗ ਸਮੇਂ ਦੇ ਨਾਲ ਇੱਕ ਸੁਨੇਹਾ ਪ੍ਰਾਪਤ ਹੋਵੇਗਾ, ਜੋ ਕਿ ਕਤਾਰ ਵਿੱਚ ਕਾਰਜਾਂ ਦੀ ਸੰਖਿਆ ਦੇ ਅਧਾਰ ਤੇ ਗਿਣਿਆ ਜਾਂਦਾ ਹੈ। ਜੇਕਰ ਕੋਈ ਗਲਤੀ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਉਪਭੋਗਤਾ ਨੂੰ ਇਸ ਬਾਰੇ ਜਾਣਕਾਰੀ ਦੇ ਨਾਲ ਇੱਕ ਸੁਨੇਹਾ ਭੇਜ ਕੇ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਸੂਚਿਤ ਕੀਤਾ ਜਾਵੇਗਾ ਕਿ ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ।

ਨਾਲ ਹੀ, ਇਹ ਮਾਈਕ੍ਰੋਸਰਵਿਸ, ਇੱਕ ਸੈਲਰੀ ਵਰਕਰ ਦੀ ਤਰ੍ਹਾਂ, "ਅਫਟਰ_ਐਸਟੀਮੇਟ" ਕਤਾਰ ਨੂੰ ਸੁਣਦੀ ਹੈ, ਜੋ ਉਹਨਾਂ ਕੰਮਾਂ ਲਈ ਹੈ ਜੋ ਮੁਲਾਂਕਣ ਪਾਈਪਲਾਈਨ ਵਿੱਚੋਂ ਲੰਘੇ ਹਨ।

ਜਦੋਂ “ਅਫਟਰ_ਐਸਟੀਮੇਟ” ਤੋਂ ਨਵਾਂ ਕੰਮ ਪ੍ਰਾਪਤ ਕਰਨਾ:

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

ਮੁਲਾਂਕਣ ਮਾਈਕ੍ਰੋਸਰਵਿਸ "ਅਟ੍ਰਾਈ-ਅਸਟਿਮੇਟਰ"

ਇਹ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਇੱਕ ਸੈਲਰੀ ਵਰਕਰ ਹੈ ਅਤੇ ਚਿੱਤਰ ਮੁਲਾਂਕਣ ਪਾਈਪਲਾਈਨ ਨਾਲ ਸਬੰਧਤ ਹਰ ਚੀਜ਼ ਨੂੰ ਸ਼ਾਮਲ ਕਰਦੀ ਹੈ। ਇੱਥੇ ਕੇਵਲ ਇੱਕ ਕਾਰਜਸ਼ੀਲ ਐਲਗੋਰਿਦਮ ਹੈ - ਆਓ ਇਸਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰੀਏ।

ਜਦੋਂ “to_estimate” ਤੋਂ ਨਵਾਂ ਕੰਮ ਪ੍ਰਾਪਤ ਕਰਨਾ:

1. ਆਉ ਮੁਲਾਂਕਣ ਪਾਈਪਲਾਈਨ ਦੁਆਰਾ ਚਿੱਤਰ ਨੂੰ ਚਲਾਉਂਦੇ ਹਾਂ:
   1. ਚਿੱਤਰ ਨੂੰ ਮੈਮੋਰੀ ਵਿੱਚ ਲੋਡ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ
   2. ਅਸੀਂ ਚਿੱਤਰ ਨੂੰ ਲੋੜੀਂਦੇ ਆਕਾਰ ਵਿੱਚ ਲਿਆਉਂਦੇ ਹਾਂ
   3. ਸਾਰੇ ਚਿਹਰੇ ਲੱਭ ਰਹੇ ਹਨ (MTCNN)
   4. ਅਸੀਂ ਸਾਰੇ ਚਿਹਰਿਆਂ ਦਾ ਮੁਲਾਂਕਣ ਕਰਦੇ ਹਾਂ (ਅਸੀਂ ਆਖਰੀ ਪੜਾਅ ਵਿੱਚ ਪਾਏ ਗਏ ਚਿਹਰਿਆਂ ਨੂੰ ਇੱਕ ਬੈਚ ਵਿੱਚ ਲਪੇਟਦੇ ਹਾਂ ਅਤੇ ResNet34 ਦਾ ਅਨੁਮਾਨ ਲਗਾਉਂਦੇ ਹਾਂ)
   5. ਅੰਤਿਮ ਚਿੱਤਰ ਨੂੰ ਰੈਂਡਰ ਕਰੋ
      1. ਆਉ ਬਾਊਂਡਿੰਗ ਬਕਸਿਆਂ ਨੂੰ ਖਿੱਚੀਏ
      2. ਰੇਟਿੰਗਾਂ ਖਿੱਚ ਰਹੀਆਂ ਹਨ
2. ਇੱਕ ਕਸਟਮ (ਅਸਲੀ) ਚਿੱਤਰ ਨੂੰ ਮਿਟਾਉਣਾ
3. ਮੁਲਾਂਕਣ ਪਾਈਪਲਾਈਨ ਤੋਂ ਆਉਟਪੁੱਟ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨਾ
4. ਅਸੀਂ ਟਾਸਕ ਨੂੰ "ਅਫਟਰ_ਐਸਟੀਮੇਟ" ਕਤਾਰ ਵਿੱਚ ਪਾਉਂਦੇ ਹਾਂ, ਜਿਸਨੂੰ ਉੱਪਰ ਚਰਚਾ ਕੀਤੀ ਗਈ "ਅਟ੍ਰਾਈ-ਟੈਲੀਗ੍ਰਾਮ-ਬੋਟ" ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਦੁਆਰਾ ਸੁਣਿਆ ਜਾਂਦਾ ਹੈ।

ਗ੍ਰੇਲੌਗ (+ mongoDB + Elasticsearch)

ਗ੍ਰੇਲੌਗ ਕੇਂਦਰੀ ਲੌਗ ਪ੍ਰਬੰਧਨ ਲਈ ਇੱਕ ਹੱਲ ਹੈ। ਇਸ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ, ਇਸਦੀ ਵਰਤੋਂ ਇਸਦੇ ਉਦੇਸ਼ ਲਈ ਕੀਤੀ ਗਈ ਸੀ।

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

ਕਿਸੇ ਅਜਿਹੇ ਵਿਅਕਤੀ ਦੇ ਰੂਪ ਵਿੱਚ ਜਿਸਨੇ ਪਹਿਲਾਂ ਸਿਰਫ ELK ਸਟੈਕ ਨਾਲ ਕੰਮ ਕੀਤਾ ਸੀ, ਮੇਰੇ ਕੋਲ ਗ੍ਰੇਲੌਗ ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ ਇੱਕ ਸਮੁੱਚਾ ਸਕਾਰਾਤਮਕ ਅਨੁਭਵ ਸੀ। ਸਿਰਫ ਇੱਕ ਚੀਜ਼ ਜੋ ਨਿਰਾਸ਼ਾਜਨਕ ਹੈ ਉਹ ਹੈ ਗ੍ਰੇਲੌਗ ਵੈੱਬ ਇੰਟਰਫੇਸ ਉੱਤੇ ਕਿਬਾਨਾ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚ ਉੱਤਮਤਾ।

ਰੈਬਿਟਮਕਿQ

ਰੈਬਿਟਮਕਿQ AMQP ਪ੍ਰੋਟੋਕੋਲ 'ਤੇ ਅਧਾਰਤ ਇੱਕ ਸੁਨੇਹਾ ਬ੍ਰੋਕਰ ਹੈ।

ਇਸ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਇਸਦੀ ਵਰਤੋਂ ਕੀਤੀ ਗਈ ਸੀ ਸਭ ਤੋਂ ਸਥਿਰ ਅਤੇ ਸਮੇਂ ਦੀ ਜਾਂਚ ਕੀਤੀ ਸੈਲਰੀ ਲਈ ਦਲਾਲ ਅਤੇ ਟਿਕਾਊ ਮੋਡ ਵਿੱਚ ਕੰਮ ਕੀਤਾ।

ਰੇਡਿਸ

ਰੇਡਿਸ ਇੱਕ NoSQL DBMS ਹੈ ਜੋ ਮੁੱਖ-ਮੁੱਲ ਡਾਟਾ ਢਾਂਚੇ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ

ਕਈ ਵਾਰ ਆਮ ਵਸਤੂਆਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜੋ ਵੱਖ-ਵੱਖ ਪਾਈਥਨ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਵਿੱਚ ਕੁਝ ਡਾਟਾ ਢਾਂਚੇ ਨੂੰ ਲਾਗੂ ਕਰਦੇ ਹਨ।

ਉਦਾਹਰਨ ਲਈ, Redis ਫਾਰਮ ਦਾ ਇੱਕ ਹੈਸ਼ਮੈਪ ਸਟੋਰ ਕਰਦਾ ਹੈ “telegram_user_id => ਕਤਾਰ ਵਿੱਚ ਸਰਗਰਮ ਕਾਰਜਾਂ ਦੀ ਸੰਖਿਆ,” ਜੋ ਤੁਹਾਨੂੰ ਇੱਕ ਉਪਭੋਗਤਾ ਦੀਆਂ ਬੇਨਤੀਆਂ ਦੀ ਸੰਖਿਆ ਨੂੰ ਇੱਕ ਨਿਸ਼ਚਿਤ ਮੁੱਲ ਤੱਕ ਸੀਮਿਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਅਤੇ, ਇਸ ਤਰ੍ਹਾਂ, DoS ਹਮਲਿਆਂ ਨੂੰ ਰੋਕਦਾ ਹੈ।

ਆਉ ਸਫਲ ਚਿੱਤਰ ਪ੍ਰੋਸੈਸਿੰਗ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਰਸਮੀ ਕਰੀਏ

1. ਉਪਭੋਗਤਾ ਟੈਲੀਗ੍ਰਾਮ ਬੋਟ ਨੂੰ ਇੱਕ ਚਿੱਤਰ ਭੇਜਦਾ ਹੈ
2. "attrai-telegram-bot" ਟੈਲੀਗ੍ਰਾਮ API ਤੋਂ ਇੱਕ ਸੁਨੇਹਾ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਪਾਰਸ ਕਰਦਾ ਹੈ
3. ਚਿੱਤਰ ਦੇ ਨਾਲ ਕੰਮ ਨੂੰ ਅਸਿੰਕ੍ਰੋਨਸ ਕਤਾਰ “to_estimate” ਵਿੱਚ ਜੋੜਿਆ ਗਿਆ ਹੈ
4. ਉਪਭੋਗਤਾ ਨੂੰ ਯੋਜਨਾਬੱਧ ਮੁਲਾਂਕਣ ਸਮੇਂ ਦੇ ਨਾਲ ਇੱਕ ਸੁਨੇਹਾ ਪ੍ਰਾਪਤ ਹੁੰਦਾ ਹੈ
5. “ਅਟ੍ਰਾਈ-ਅਨੁਮਾਨਕ” “to_estimate” ਕਤਾਰ ਤੋਂ ਇੱਕ ਕੰਮ ਲੈਂਦਾ ਹੈ, ਪਾਈਪਲਾਈਨ ਰਾਹੀਂ ਅਨੁਮਾਨਾਂ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ ਅਤੇ ਕਾਰਜ ਨੂੰ “ਅਫਟਰ_ਅਸਟਿਮੇਟ” ਕਤਾਰ ਵਿੱਚ ਪੈਦਾ ਕਰਦਾ ਹੈ।
6. "attrai-telegram-bot" "after_estimate" ਕਤਾਰ ਨੂੰ ਸੁਣਨਾ, ਉਪਭੋਗਤਾ ਨੂੰ ਨਤੀਜਾ ਭੇਜਦਾ ਹੈ

DevOps

ਅੰਤ ਵਿੱਚ, ਆਰਕੀਟੈਕਚਰ ਦੀ ਸਮੀਖਿਆ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਤੁਸੀਂ ਬਰਾਬਰ ਦੇ ਦਿਲਚਸਪ ਹਿੱਸੇ ਵੱਲ ਜਾ ਸਕਦੇ ਹੋ - DevOps

ਡੌਕਰ ਸਵਰਮ

 

ਡੌਕਰ ਸਵਰਮ  — ਇੱਕ ਕਲੱਸਟਰਿੰਗ ਸਿਸਟਮ, ਜਿਸਦੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਡੌਕਰ ਇੰਜਣ ਦੇ ਅੰਦਰ ਲਾਗੂ ਹੁੰਦੀ ਹੈ ਅਤੇ ਬਾਕਸ ਤੋਂ ਬਾਹਰ ਉਪਲਬਧ ਹੁੰਦੀ ਹੈ।

ਇੱਕ "ਸਵਾਰਮ" ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਸਾਡੇ ਕਲੱਸਟਰ ਵਿੱਚ ਸਾਰੇ ਨੋਡਾਂ ਨੂੰ 2 ਕਿਸਮਾਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾ ਸਕਦਾ ਹੈ - ਵਰਕਰ ਅਤੇ ਮੈਨੇਜਰ। ਪਹਿਲੀ ਕਿਸਮ ਦੀਆਂ ਮਸ਼ੀਨਾਂ 'ਤੇ, ਕੰਟੇਨਰਾਂ ਦੇ ਸਮੂਹ (ਸਟੈਕ) ਤਾਇਨਾਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਦੂਜੀ ਕਿਸਮ ਦੀਆਂ ਮਸ਼ੀਨਾਂ ਸਕੇਲਿੰਗ, ਸੰਤੁਲਨ ਅਤੇ ਹੋਰ ਠੰਡਾ ਫੀਚਰ. ਪ੍ਰਬੰਧਕ ਵੀ ਮੂਲ ਰੂਪ ਵਿੱਚ ਵਰਕਰ ਹੁੰਦੇ ਹਨ।

ਇੱਕ ਲੀਡਰ ਮੈਨੇਜਰ ਅਤੇ ਤਿੰਨ ਵਰਕਰਾਂ ਵਾਲਾ ਕਲੱਸਟਰ

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

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

ਡੌਕਰ ਸਟੈਕ

ਸਵੈਰਮ ਮੋਡ ਵਿੱਚ, ਉਹ ਸਟੈਕ (ਡੌਕਰ ਸੇਵਾਵਾਂ ਦੇ ਸੈੱਟ) ਨੂੰ ਤਾਇਨਾਤ ਕਰਨ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ। ਡੌਕਰ ਸਟੈਕ

ਇਹ ਡੌਕਰ-ਕੰਪੋਜ਼ ਕੌਂਫਿਗਸ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਤੈਨਾਤ ਪੈਰਾਮੀਟਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ।  

ਉਦਾਹਰਨ ਲਈ, ਇਹਨਾਂ ਪੈਰਾਮੀਟਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਹਰੇਕ ਮੁਲਾਂਕਣ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਮੌਕਿਆਂ ਲਈ ਸਰੋਤ ਸੀਮਤ ਸਨ (ਅਸੀਂ N ਮੌਕਿਆਂ ਲਈ N ਕੋਰ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਾਂ, ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਵਿੱਚ ਹੀ ਅਸੀਂ ਪਾਈਟੋਰਚ ਦੁਆਰਾ ਵਰਤੇ ਗਏ ਕੋਰਾਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਇੱਕ ਤੱਕ ਸੀਮਿਤ ਕਰਦੇ ਹਾਂ)

attrai_estimator:
  image: 'erqups/attrai_estimator:1.2'
  deploy:
    replicas: 4
    resources:
      limits:
        cpus: '4'
    restart_policy:
      condition: on-failure
      …

ਇਹ ਨੋਟ ਕਰਨਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ Redis, RabbitMQ ਅਤੇ Graylog ਰਾਜਕੀ ਸੇਵਾਵਾਂ ਹਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ "ਅਟ੍ਰਾਈ-ਅਨੁਮਾਨਕ" ਦੇ ਰੂਪ ਵਿੱਚ ਆਸਾਨੀ ਨਾਲ ਮਾਪਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ ਹੈ.

ਸਵਾਲ ਦਾ ਪੂਰਵਦਰਸ਼ਨ - ਕੁਬਰਨੇਟਸ ਕਿਉਂ ਨਹੀਂ?

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

ਬੁਨਿਆਦੀ ਢਾਂਚਾ

ਇਹ ਸਭ ਹੇਠ ਲਿਖੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨਾਲ VDS 'ਤੇ ਤੈਨਾਤ ਕੀਤਾ ਗਿਆ ਸੀ:

• CPU: 4 ਕੋਰ Intel® Xeon® Gold 5120 CPU @ 2.20GHz
• ਰੈਮ: 8 GB
• SSD: 160GB

ਸਥਾਨਕ ਲੋਡ ਟੈਸਟਿੰਗ ਤੋਂ ਬਾਅਦ, ਅਜਿਹਾ ਲਗਦਾ ਸੀ ਕਿ ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਇੱਕ ਗੰਭੀਰ ਆਮਦ ਦੇ ਨਾਲ, ਇਹ ਮਸ਼ੀਨ ਕਾਫ਼ੀ ਹੋਵੇਗੀ.

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

ਕੁਝ ਹੋਰ ਗ੍ਰਾਫਿਕਸ

ਦਿਨ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ, ਤੈਨਾਤੀ ਤੋਂ ਬਾਅਦ ਵਿਲੱਖਣ ਉਪਭੋਗਤਾਵਾਂ ਅਤੇ ਮੁਲਾਂਕਣ ਬੇਨਤੀਆਂ ਦੀ ਸੰਖਿਆ

ਮੁਲਾਂਕਣ ਪਾਈਪਲਾਈਨ ਅਨੁਮਾਨ ਸਮਾਂ ਵੰਡ

ਸਿੱਟਾ

ਸੰਖੇਪ ਕਰਨ ਲਈ, ਮੈਂ ਕਹਿ ਸਕਦਾ ਹਾਂ ਕਿ ਕੰਟੇਨਰਾਂ ਦੇ ਆਰਕੈਸਟ੍ਰੇਸ਼ਨ ਲਈ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਪਹੁੰਚ ਨੇ ਆਪਣੇ ਆਪ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਜਾਇਜ਼ ਠਹਿਰਾਇਆ - ਇੱਥੋਂ ਤੱਕ ਕਿ ਸਿਖਰ ਦੇ ਪਲਾਂ 'ਤੇ ਵੀ ਪ੍ਰੋਸੈਸਿੰਗ ਸਮੇਂ ਵਿੱਚ ਕੋਈ ਤੁਪਕੇ ਜਾਂ ਸੱਗਿੰਗ ਨਹੀਂ ਸਨ. 

ਮੈਂ ਸੋਚਦਾ ਹਾਂ ਕਿ ਛੋਟੇ ਅਤੇ ਮੱਧਮ ਆਕਾਰ ਦੇ ਪ੍ਰੋਜੈਕਟ ਜੋ ਆਪਣੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ CPU 'ਤੇ ਨਿਊਰਲ ਨੈਟਵਰਕ ਦੇ ਅਸਲ-ਸਮੇਂ ਦੇ ਅਨੁਮਾਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਇਸ ਲੇਖ ਵਿੱਚ ਦੱਸੇ ਗਏ ਅਭਿਆਸਾਂ ਨੂੰ ਸਫਲਤਾਪੂਰਵਕ ਅਪਣਾ ਸਕਦੇ ਹਨ।

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

ਤੁਸੀਂ ਟੈਲੀਗ੍ਰਾਮ - @AttraiBot 'ਤੇ ਬੋਟ ਨੂੰ ਪੋਕ ਕਰ ਸਕਦੇ ਹੋ, ਇਹ ਘੱਟੋ ਘੱਟ 2020 ਦੇ ਪਤਝੜ ਦੇ ਅੰਤ ਤੱਕ ਕੰਮ ਕਰੇਗਾ। ਮੈਨੂੰ ਤੁਹਾਨੂੰ ਯਾਦ ਦਿਵਾਉਣ ਦਿਓ ਕਿ ਕੋਈ ਵੀ ਉਪਭੋਗਤਾ ਡੇਟਾ ਸਟੋਰ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ - ਨਾ ਹੀ ਅਸਲ ਚਿੱਤਰ, ਅਤੇ ਨਾ ਹੀ ਮੁਲਾਂਕਣ ਪਾਈਪਲਾਈਨ ਦੇ ਨਤੀਜੇ - ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਤੋਂ ਬਾਅਦ ਹਰ ਚੀਜ਼ ਨੂੰ ਢਾਹ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ.

ਸਰੋਤ: www.habr.com