ਸਤ ਸ੍ਰੀ ਅਕਾਲ! ਮੇਰਾ ਨਾਮ ਵਡਿਮ ਮੈਡੀਸਨ ਹੈ, ਮੈਂ ਅਵੀਟੋ ਸਿਸਟਮ ਪਲੇਟਫਾਰਮ ਦੇ ਵਿਕਾਸ ਦੀ ਅਗਵਾਈ ਕਰਦਾ ਹਾਂ. ਇਹ ਇੱਕ ਤੋਂ ਵੱਧ ਵਾਰ ਕਿਹਾ ਗਿਆ ਹੈ ਕਿ ਕਿਵੇਂ ਅਸੀਂ ਕੰਪਨੀ ਵਿੱਚ ਇੱਕ ਮੋਨੋਲੀਥਿਕ ਆਰਕੀਟੈਕਚਰ ਤੋਂ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਵੱਲ ਵਧ ਰਹੇ ਹਾਂ। ਇਹ ਸਾਂਝਾ ਕਰਨ ਦਾ ਸਮਾਂ ਹੈ ਕਿ ਅਸੀਂ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਦਾ ਵੱਧ ਤੋਂ ਵੱਧ ਲਾਹਾ ਲੈਣ ਅਤੇ ਆਪਣੇ ਆਪ ਨੂੰ ਉਹਨਾਂ ਵਿੱਚ ਗੁਆਚਣ ਤੋਂ ਬਚਾਉਣ ਲਈ ਆਪਣੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨੂੰ ਕਿਵੇਂ ਬਦਲਿਆ ਹੈ। PaaS ਇੱਥੇ ਸਾਡੀ ਕਿਵੇਂ ਮਦਦ ਕਰਦਾ ਹੈ, ਅਸੀਂ ਕਿਵੇਂ ਤੈਨਾਤੀ ਨੂੰ ਸਰਲ ਬਣਾਇਆ ਅਤੇ ਇੱਕ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਦੀ ਰਚਨਾ ਨੂੰ ਇੱਕ ਕਲਿੱਕ ਵਿੱਚ ਘਟਾ ਦਿੱਤਾ - ਪੜ੍ਹੋ। ਜੋ ਵੀ ਮੈਂ ਹੇਠਾਂ ਲਿਖਦਾ ਹਾਂ ਉਹ ਅਵੀਟੋ ਵਿੱਚ ਪੂਰੀ ਤਰ੍ਹਾਂ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦਾ, ਇਸ ਵਿੱਚੋਂ ਕੁਝ ਇਹ ਹੈ ਕਿ ਅਸੀਂ ਆਪਣੇ ਪਲੇਟਫਾਰਮ ਨੂੰ ਕਿਵੇਂ ਵਿਕਸਿਤ ਕਰਦੇ ਹਾਂ।

(ਅਤੇ ਇਸ ਲੇਖ ਦੇ ਅੰਤ ਵਿੱਚ, ਮੈਂ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਆਰਕੀਟੈਕਚਰ ਮਾਹਰ ਕ੍ਰਿਸ ਰਿਚਰਡਸਨ ਦੇ ਤਿੰਨ ਦਿਨਾਂ ਸੈਮੀਨਾਰ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣ ਦੇ ਮੌਕੇ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗਾ)।

ਅਸੀਂ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ 'ਤੇ ਕਿਵੇਂ ਆਏ

ਅਵੀਟੋ ਦੁਨੀਆ ਦੀ ਸਭ ਤੋਂ ਵੱਡੀ ਸ਼੍ਰੇਣੀਬੱਧ ਸਾਈਟਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ; ਇਸ 'ਤੇ ਪ੍ਰਤੀ ਦਿਨ 15 ਮਿਲੀਅਨ ਤੋਂ ਵੱਧ ਨਵੇਂ ਇਸ਼ਤਿਹਾਰ ਪ੍ਰਕਾਸ਼ਿਤ ਹੁੰਦੇ ਹਨ। ਸਾਡਾ ਬੈਕਐਂਡ ਪ੍ਰਤੀ ਸਕਿੰਟ 20 ਹਜ਼ਾਰ ਤੋਂ ਵੱਧ ਬੇਨਤੀਆਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ। ਸਾਡੇ ਕੋਲ ਇਸ ਸਮੇਂ ਕਈ ਸੌ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਹਨ।

ਅਸੀਂ ਕਈ ਸਾਲਾਂ ਤੋਂ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਆਰਕੀਟੈਕਚਰ ਬਣਾ ਰਹੇ ਹਾਂ। ਬਿਲਕੁਲ ਕਿਵੇਂ - ਵਿਸਥਾਰ ਵਿੱਚ ਸਾਡੇ ਸਹਿਯੋਗੀ ਨੂੰ ਦੱਸਿਆ RIT++ 2017 'ਤੇ ਸਾਡੇ ਸੈਕਸ਼ਨ 'ਤੇ। CodeFest 2017 'ਤੇ (ਦੇਖੋ। видео), ਸੇਰਗੇਈ ਓਰਲੋਵ ਅਤੇ ਮਿਖਾਇਲ ਪ੍ਰੋਕੋਪਚੁਕ ਨੇ ਵਿਸਥਾਰ ਵਿੱਚ ਦੱਸਿਆ ਕਿ ਸਾਨੂੰ ਮਾਈਕ੍ਰੋਸਰਵਿਸਿਜ਼ ਵਿੱਚ ਤਬਦੀਲੀ ਦੀ ਲੋੜ ਕਿਉਂ ਪਈ ਅਤੇ ਇੱਥੇ ਕੁਬਰਨੇਟਸ ਨੇ ਕੀ ਭੂਮਿਕਾ ਨਿਭਾਈ। ਖੈਰ, ਹੁਣ ਅਸੀਂ ਸਕੇਲਿੰਗ ਲਾਗਤਾਂ ਨੂੰ ਘੱਟ ਕਰਨ ਲਈ ਸਭ ਕੁਝ ਕਰ ਰਹੇ ਹਾਂ ਜੋ ਅਜਿਹੇ ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ।

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

ਹੁਣ PaaS CLI ਉਪਯੋਗਤਾ ਵਿੱਚ, ਇੱਕ ਕਮਾਂਡ ਨਾਲ ਇੱਕ ਨਵੀਂ ਸੇਵਾ ਬਣਾਈ ਗਈ ਹੈ, ਅਤੇ ਇੱਕ ਨਵਾਂ ਡਾਟਾਬੇਸ ਦੋ ਹੋਰਾਂ ਨਾਲ ਜੋੜਿਆ ਗਿਆ ਹੈ ਅਤੇ ਸਟੇਜ 'ਤੇ ਤਾਇਨਾਤ ਕੀਤਾ ਗਿਆ ਹੈ।

"ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਫ੍ਰੈਗਮੈਂਟੇਸ਼ਨ" ਦੇ ਯੁੱਗ ਨੂੰ ਕਿਵੇਂ ਦੂਰ ਕਰਨਾ ਹੈ

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

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਬਣਾਉਣ ਲਈ, ਬਹੁਤ ਸਾਰੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਸਥਾਪਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਅਰਥਾਤ:

• ਲਾਗਿੰਗ;
• ਬੇਨਤੀ ਟਰੇਸਿੰਗ (ਜੇਗਰ);
• ਗਲਤੀ ਇਕੱਤਰੀਕਰਨ (ਸੈਂਟਰੀ);
• ਕੁਬਰਨੇਟਸ (ਇਵੈਂਟ ਸਟ੍ਰੀਮ ਪ੍ਰੋਸੈਸਿੰਗ) ਤੋਂ ਸਥਿਤੀਆਂ, ਸੰਦੇਸ਼, ਇਵੈਂਟਸ;
• ਰੇਸ ਸੀਮਾ / ਸਰਕਟ ਬਰੇਕਰ (ਤੁਸੀਂ Hystrix ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ);
• ਸੇਵਾ ਕਨੈਕਟੀਵਿਟੀ ਦਾ ਨਿਯੰਤਰਣ (ਅਸੀਂ ਨੇਤਰਮੇਸ਼ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ);
• ਨਿਗਰਾਨੀ (ਗਰਾਫਾਨਾ);
• ਅਸੈਂਬਲੀ (ਟੀਮ ਸਿਟੀ);
• ਸੰਚਾਰ ਅਤੇ ਸੂਚਨਾ (ਸਲੈਕ, ਈਮੇਲ);
• ਟਾਸਕ ਟਰੈਕਿੰਗ; (ਜੀਰਾ)
• ਦਸਤਾਵੇਜ਼ਾਂ ਦੀ ਤਿਆਰੀ।

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

ਅਸੀਂ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਦਾ ਪ੍ਰਬੰਧਨ ਕਿਵੇਂ ਕਰਦੇ ਹਾਂ

ਬਹੁਤ ਸਾਰੀਆਂ ਅਵੀਟੋ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ਾਂ ਵਿੱਚ ਇੱਕ ਏਕੀਕ੍ਰਿਤ "ਪਾਰਟੀ ਨੀਤੀ" ਨੂੰ ਲਾਗੂ ਕਰਨ ਵਿੱਚ ਹੇਠਾਂ ਦਿੱਤੀ ਮਦਦ:

• ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨੂੰ ਪਰਤਾਂ ਵਿੱਚ ਵੰਡਣਾ;
• ਇੱਕ ਸੇਵਾ (PaaS) ਸੰਕਲਪ ਵਜੋਂ ਪਲੇਟਫਾਰਮ;
• ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਨਾਲ ਵਾਪਰਨ ਵਾਲੀ ਹਰ ਚੀਜ਼ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨਾ।

ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਐਬਸਟਰੈਕਸ਼ਨ ਲੇਅਰਾਂ ਵਿੱਚ ਤਿੰਨ ਪਰਤਾਂ ਸ਼ਾਮਲ ਹੁੰਦੀਆਂ ਹਨ। ਚਲੋ ਉੱਪਰ ਤੋਂ ਹੇਠਾਂ ਵੱਲ ਚੱਲੀਏ.

A. ਸਿਖਰ - ਸੇਵਾ ਜਾਲ। ਪਹਿਲਾਂ ਅਸੀਂ Istio ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ, ਪਰ ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਇਹ ਬਹੁਤ ਸਾਰੇ ਸਰੋਤਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਜੋ ਕਿ ਸਾਡੇ ਵਾਲੀਅਮ ਲਈ ਬਹੁਤ ਮਹਿੰਗਾ ਹੈ। ਇਸ ਲਈ, ਆਰਕੀਟੈਕਚਰ ਟੀਮ ਦੇ ਸੀਨੀਅਰ ਇੰਜੀਨੀਅਰ ਅਲੈਗਜ਼ੈਂਡਰ ਲੁਕਯਾਨਚੇਨਕੋ ਨੇ ਆਪਣਾ ਹੱਲ ਵਿਕਸਿਤ ਕੀਤਾ - ਨੇਤਰਮੇਸ਼ (ਓਪਨ ਸੋਰਸ ਵਿੱਚ ਉਪਲਬਧ), ਜਿਸਨੂੰ ਅਸੀਂ ਵਰਤਮਾਨ ਵਿੱਚ ਉਤਪਾਦਨ ਵਿੱਚ ਵਰਤਦੇ ਹਾਂ ਅਤੇ ਜੋ Istio ਨਾਲੋਂ ਕਈ ਗੁਣਾ ਘੱਟ ਸਰੋਤਾਂ ਦੀ ਖਪਤ ਕਰਦਾ ਹੈ (ਪਰ ਉਹ ਸਭ ਕੁਝ ਨਹੀਂ ਕਰਦਾ ਜਿਸਦਾ Istio ਮਾਣ ਕਰ ਸਕਦਾ ਹੈ)।
ਬੀ ਮੀਡੀਅਮ - ਕੁਬਰਨੇਟਸ। ਅਸੀਂ ਇਸ 'ਤੇ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਤਾਇਨਾਤ ਅਤੇ ਸੰਚਾਲਿਤ ਕਰਦੇ ਹਾਂ।
C. ਥੱਲੇ - ਬੇਅਰ ਧਾਤ। ਅਸੀਂ ਬੱਦਲਾਂ ਜਾਂ ਓਪਨਸਟੈਕ ਵਰਗੀਆਂ ਚੀਜ਼ਾਂ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੇ ਹਾਂ, ਪਰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੇਅਰ ਮੈਟਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਾਂ।

ਸਾਰੀਆਂ ਪਰਤਾਂ PaaS ਦੁਆਰਾ ਜੋੜੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਅਤੇ ਇਹ ਪਲੇਟਫਾਰਮ, ਬਦਲੇ ਵਿੱਚ, ਤਿੰਨ ਭਾਗਾਂ ਦੇ ਸ਼ਾਮਲ ਹਨ.

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

II. ਸੰਯੁਕਤ ਕੁਲੈਕਟਰ ਇੱਕ ਸਾਂਝੇ ਡੈਸ਼ਬੋਰਡ ਦੁਆਰਾ ਸਾਰੇ ਸਾਧਨਾਂ ਦੇ ਨਿਯੰਤਰਣ ਦੇ ਨਾਲ.

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

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

ਇੱਕ ਮਿਆਰੀ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਡਿਵੈਲਪਮੈਂਟ ਪਾਈਪਲਾਈਨ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ?

ਆਮ ਤੌਰ 'ਤੇ, ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਬਣਾਉਣ ਦੀ ਲੜੀ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ:

CLI-ਪੁਸ਼ → ਨਿਰੰਤਰ ਏਕੀਕਰਣ → ਬੇਕ → ਤੈਨਾਤ → ਨਕਲੀ ਟੈਸਟ → ਕੈਨਰੀ ਟੈਸਟ → ਸਕਿਊਜ਼ ਟੈਸਟਿੰਗ → ਉਤਪਾਦਨ → ਰੱਖ-ਰਖਾਅ।

ਆਓ ਇਸ ਕ੍ਰਮ ਵਿੱਚ ਬਿਲਕੁਲ ਇਸ ਵਿੱਚੋਂ ਲੰਘੀਏ।

CLI- ਧੱਕਾ

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

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

— ਇੱਕ ਟੈਂਪਲੇਟ ਦੇ ਅਨੁਸਾਰ ਇੱਕ ਸੇਵਾ ਬਣਾਉਂਦਾ ਹੈ — ਕਦਮ ਦਰ ਕਦਮ, “ਵਿਜ਼ਾਰਡ” ਮੋਡ ਵਿੱਚ। ਸਾਡੇ ਕੋਲ ਅਵੀਟੋ ਬੈਕਐਂਡ ਵਿੱਚ ਮੁੱਖ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾਵਾਂ ਲਈ ਟੈਂਪਲੇਟ ਹਨ: PHP, ਗੋਲੰਗ ਅਤੇ ਪਾਈਥਨ।

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

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

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

- ਆਟੋਟੈਸਟ ਤਿਆਰ ਕਰਦਾ ਹੈ। ਖਾਲੀ ਦੇ ਰੂਪ ਵਿੱਚ, ਪਰ ਵਰਤੋਂ ਲਈ ਕਾਫ਼ੀ ਢੁਕਵਾਂ ਹੈ.

• ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਤੈਨਾਤੀ.

ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਨੂੰ ਤੈਨਾਤ ਕਰਨਾ ਸਾਡੇ ਲਈ ਥੋੜ੍ਹਾ ਜਿਹਾ ਕੰਮ ਹੁੰਦਾ ਸੀ। ਹੇਠ ਲਿਖੇ ਲੋੜੀਂਦੇ ਸਨ:

I. ਡੌਕਰਫਾਈਲ।

II. ਸੰਰਚਨਾ.
III. ਹੈਲਮ ਚਾਰਟ, ਜੋ ਕਿ ਆਪਣੇ ਆਪ ਵਿੱਚ ਬੋਝਲ ਹੈ ਅਤੇ ਇਸ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:

- ਚਾਰਟ ਆਪਣੇ ਆਪ;
- ਟੈਂਪਲੇਟਸ;
- ਵੱਖ-ਵੱਖ ਵਾਤਾਵਰਣਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ ਖਾਸ ਮੁੱਲ।

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

ਹਾਂ, ਅਤੇ app.toml ਵਿੱਚ ਆਪਣੇ ਆਪ ਵਿੱਚ ਇੱਕ ਮਿੰਟ ਲਈ ਕਰਨ ਲਈ ਕੁਝ ਨਹੀਂ ਹੈ। ਅਸੀਂ ਨਿਰਧਾਰਿਤ ਕਰਦੇ ਹਾਂ ਕਿ ਸੇਵਾ ਦੀਆਂ ਕਿੱਥੇ ਅਤੇ ਕਿੰਨੀਆਂ ਕਾਪੀਆਂ ਇਕੱਠੀਆਂ ਕਰਨੀਆਂ ਹਨ (ਦੇਵ ਸਰਵਰ 'ਤੇ, ਸਟੇਜਿੰਗ 'ਤੇ, ਉਤਪਾਦਨ ਵਿੱਚ), ਅਤੇ ਇਸਦੀ ਨਿਰਭਰਤਾ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਾਂ। [ਇੰਜਣ] ਬਲਾਕ ਵਿੱਚ ਲਾਈਨ ਦੇ ਆਕਾਰ = "ਛੋਟੇ" ਵੱਲ ਧਿਆਨ ਦਿਓ। ਇਹ ਉਹ ਸੀਮਾ ਹੈ ਜੋ ਕੁਬਰਨੇਟਸ ਦੁਆਰਾ ਸੇਵਾ ਲਈ ਨਿਰਧਾਰਤ ਕੀਤੀ ਜਾਵੇਗੀ।

ਫਿਰ, ਸੰਰਚਨਾ ਦੇ ਅਧਾਰ ਤੇ, ਸਾਰੇ ਲੋੜੀਂਦੇ ਹੈਲਮ ਚਾਰਟ ਆਪਣੇ ਆਪ ਤਿਆਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਡੇਟਾਬੇਸ ਨਾਲ ਕਨੈਕਸ਼ਨ ਬਣਾਏ ਜਾਂਦੇ ਹਨ।

• ਬੁਨਿਆਦੀ ਪ੍ਰਮਾਣਿਕਤਾ। ਅਜਿਹੇ ਚੈਕ ਵੀ ਸਵੈਚਾਲਿਤ ਹੁੰਦੇ ਹਨ।
ਟਰੈਕ ਕਰਨ ਦੀ ਲੋੜ ਹੈ:
- ਕੀ ਇੱਥੇ ਕੋਈ ਡੌਕਰਫਾਈਲ ਹੈ;
- ਕੀ ਇੱਥੇ app.toml ਹੈ;
- ਕੀ ਕੋਈ ਦਸਤਾਵੇਜ਼ ਉਪਲਬਧ ਹਨ?
- ਕੀ ਨਿਰਭਰਤਾ ਕ੍ਰਮ ਵਿੱਚ ਹੈ?
- ਕੀ ਚੇਤਾਵਨੀ ਨਿਯਮ ਸੈੱਟ ਕੀਤੇ ਗਏ ਹਨ।
ਆਖਰੀ ਬਿੰਦੂ ਤੱਕ: ਸੇਵਾ ਦਾ ਮਾਲਕ ਖੁਦ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਉਤਪਾਦ ਮੈਟ੍ਰਿਕਸ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨੀ ਹੈ.

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

I. ਸੇਵਾ ਦਾ ਸੰਖੇਪ ਵੇਰਵਾ. ਇਹ ਕੀ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸਦੀ ਲੋੜ ਕਿਉਂ ਹੈ ਇਸ ਬਾਰੇ ਸ਼ਾਬਦਿਕ ਤੌਰ 'ਤੇ ਕੁਝ ਵਾਕ।

II. ਆਰਕੀਟੈਕਚਰ ਚਿੱਤਰ ਲਿੰਕ. ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਇਸ 'ਤੇ ਇੱਕ ਤੇਜ਼ ਨਜ਼ਰ ਨਾਲ ਇਹ ਸਮਝਣਾ ਆਸਾਨ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਕੀ ਤੁਸੀਂ ਕੈਚਿੰਗ ਲਈ Redis ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ ਜਾਂ ਪਰਸਿਸਟੈਂਟ ਮੋਡ ਵਿੱਚ ਮੁੱਖ ਡਾਟਾ ਸਟੋਰ ਦੇ ਤੌਰ 'ਤੇ। ਅਵੀਟੋ ਵਿੱਚ ਹੁਣ ਲਈ ਇਹ ਸੰਗਮ ਦੀ ਇੱਕ ਲਿੰਕ ਹੈ.

III. ਰਨਬੁੱਕ. ਸੇਵਾ ਸ਼ੁਰੂ ਕਰਨ ਅਤੇ ਇਸ ਨੂੰ ਸੰਭਾਲਣ ਦੀਆਂ ਪੇਚੀਦਗੀਆਂ ਬਾਰੇ ਇੱਕ ਛੋਟੀ ਗਾਈਡ।

IV. FAQ, ਜਿੱਥੇ ਸੇਵਾ ਦੇ ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ ਤੁਹਾਡੇ ਸਹਿਕਰਮੀਆਂ ਨੂੰ ਆਉਣ ਵਾਲੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣਾ ਚੰਗਾ ਹੋਵੇਗਾ।

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

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

VII. ਸੇਵਾ ਦੇ ਮਾਲਕ ਜਾਂ ਮਾਲਕ. ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਇਹ — ਜਾਂ ਉਹਨਾਂ — ਨੂੰ PaaS ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਵੈਚਲਿਤ ਤੌਰ 'ਤੇ ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਸੁਰੱਖਿਅਤ ਪਾਸੇ ਰਹਿਣ ਲਈ, ਸਾਨੂੰ ਡਿਵੈਲਪਰ ਨੂੰ ਉਹਨਾਂ ਨੂੰ ਹੱਥੀਂ ਨਿਰਧਾਰਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਅੰਤ ਵਿੱਚ, ਕੋਡ ਸਮੀਖਿਆ ਦੇ ਸਮਾਨ ਦਸਤਾਵੇਜ਼ਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰਨਾ ਇੱਕ ਚੰਗਾ ਅਭਿਆਸ ਹੈ।

ਲਗਾਤਾਰ ਏਕਤਾ

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

ਪਕਾਉਣਾ

ਅਗਲਾ ਪੜਾਅ ਤਾਇਨਾਤੀ ਤੋਂ ਪਹਿਲਾਂ ਪੈਕੇਜਿੰਗ ਸੇਵਾਵਾਂ ਹੈ।

• ਐਪਲੀਕੇਸ਼ਨ ਬਣਾਉਣਾ। ਕਲਾਸਿਕਸ ਦੇ ਅਨੁਸਾਰ - ਇੱਕ ਡੌਕਰ ਚਿੱਤਰ ਵਿੱਚ.
• ਸੇਵਾ ਆਪਣੇ ਆਪ ਅਤੇ ਸੰਬੰਧਿਤ ਸਰੋਤਾਂ ਲਈ ਹੈਲਮ ਚਾਰਟ ਤਿਆਰ ਕਰਨਾ। ਡਾਟਾਬੇਸ ਅਤੇ ਕੈਸ਼ ਲਈ ਵੀ ਸ਼ਾਮਲ ਹੈ. ਉਹ app.toml ਸੰਰਚਨਾ ਦੇ ਅਨੁਸਾਰ ਆਪਣੇ ਆਪ ਬਣਾਏ ਜਾਂਦੇ ਹਨ ਜੋ CLI-ਪੁਸ਼ ਪੜਾਅ 'ਤੇ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਸੀ।
• ਪੋਰਟ ਖੋਲ੍ਹਣ ਲਈ ਪ੍ਰਬੰਧਕਾਂ ਲਈ ਟਿਕਟਾਂ ਬਣਾਉਣਾ (ਜਦੋਂ ਲੋੜ ਹੋਵੇ)।
• ਯੂਨਿਟ ਟੈਸਟਾਂ ਨੂੰ ਚਲਾਉਣਾ ਅਤੇ ਕੋਡ ਕਵਰੇਜ ਦੀ ਗਣਨਾ ਕਰਨਾ. ਜੇਕਰ ਕੋਡ ਕਵਰੇਜ ਨਿਰਧਾਰਤ ਥ੍ਰੈਸ਼ਹੋਲਡ ਤੋਂ ਹੇਠਾਂ ਹੈ, ਤਾਂ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਸੇਵਾ ਅੱਗੇ ਨਹੀਂ ਜਾਵੇਗੀ - ਤੈਨਾਤੀ ਲਈ। ਜੇਕਰ ਇਹ ਸਵੀਕਾਰਯੋਗ ਹੋਣ ਦੀ ਕਗਾਰ 'ਤੇ ਹੈ, ਤਾਂ ਸੇਵਾ ਨੂੰ ਇੱਕ "ਨਿਰਾਸ਼ਾਜਨਕ" ਗੁਣਾਂਕ ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਾਵੇਗਾ: ਫਿਰ, ਜੇਕਰ ਸਮੇਂ ਦੇ ਨਾਲ ਸੂਚਕ ਵਿੱਚ ਕੋਈ ਸੁਧਾਰ ਨਹੀਂ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਡਿਵੈਲਪਰ ਨੂੰ ਇੱਕ ਸੂਚਨਾ ਪ੍ਰਾਪਤ ਹੋਵੇਗੀ ਕਿ ਟੈਸਟਾਂ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਕੋਈ ਤਰੱਕੀ ਨਹੀਂ ਹੈ ( ਅਤੇ ਇਸ ਬਾਰੇ ਕੁਝ ਕਰਨ ਦੀ ਲੋੜ ਹੈ)।
• ਮੈਮੋਰੀ ਅਤੇ CPU ਸੀਮਾਵਾਂ ਲਈ ਲੇਖਾ-ਜੋਖਾ. ਅਸੀਂ ਮੁੱਖ ਤੌਰ 'ਤੇ ਗੋਲੰਗ ਵਿੱਚ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਲਿਖਦੇ ਹਾਂ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਚਲਾਉਂਦੇ ਹਾਂ। ਇਸ ਲਈ ਗੋਲੰਗ ਭਾਸ਼ਾ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਨਾਲ ਜੁੜੀ ਇੱਕ ਸੂਖਮਤਾ: ਮੂਲ ਰੂਪ ਵਿੱਚ, ਸ਼ੁਰੂ ਕਰਨ ਵੇਲੇ, ਮਸ਼ੀਨ ਦੇ ਸਾਰੇ ਕੋਰ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਜੇਕਰ ਤੁਸੀਂ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ GOMAXPROCS ਵੇਰੀਏਬਲ ਨੂੰ ਸੈੱਟ ਨਹੀਂ ਕਰਦੇ ਹੋ, ਅਤੇ ਜਦੋਂ ਇੱਕੋ ਮਸ਼ੀਨ 'ਤੇ ਅਜਿਹੀਆਂ ਕਈ ਸੇਵਾਵਾਂ ਲਾਂਚ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਤਾਂ ਉਹ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਸਰੋਤਾਂ ਲਈ ਮੁਕਾਬਲਾ ਕਰਨ ਲਈ, ਇੱਕ ਦੂਜੇ ਨਾਲ ਦਖਲਅੰਦਾਜ਼ੀ ਕਰਨਾ. ਹੇਠਾਂ ਦਿੱਤੇ ਗ੍ਰਾਫ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਜੇਕਰ ਤੁਸੀਂ ਬਿਨਾਂ ਕਿਸੇ ਵਿਵਾਦ ਦੇ ਅਤੇ ਸਰੋਤ ਮੋਡ ਦੀ ਦੌੜ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ ਚਲਾਉਂਦੇ ਹੋ ਤਾਂ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸਮਾਂ ਕਿਵੇਂ ਬਦਲਦਾ ਹੈ। (ਗ੍ਰਾਫ਼ ਦੇ ਸਰੋਤ ਹਨ ਇੱਥੇ).

ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਟਾਈਮ, ਘੱਟ ਬਿਹਤਰ ਹੈ. ਅਧਿਕਤਮ: 643ms, ਘੱਟੋ-ਘੱਟ: 42ms। ਫੋਟੋ ਕਲਿੱਕ ਕਰਨ ਯੋਗ ਹੈ।

ਸਰਜਰੀ ਲਈ ਸਮਾਂ, ਘੱਟ ਬਿਹਤਰ ਹੈ. ਵੱਧ ਤੋਂ ਵੱਧ: 14091 ਐਨਐਸ, ਘੱਟੋ ਘੱਟ: 151 ਐਨਐਸ। ਫੋਟੋ ਕਲਿੱਕ ਕਰਨ ਯੋਗ ਹੈ।

ਅਸੈਂਬਲੀ ਦੀ ਤਿਆਰੀ ਦੇ ਪੜਾਅ 'ਤੇ, ਤੁਸੀਂ ਇਸ ਵੇਰੀਏਬਲ ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਸੈੱਟ ਕਰ ਸਕਦੇ ਹੋ ਜਾਂ ਤੁਸੀਂ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ automaxprocs ਉਬੇਰ ਦੇ ਮੁੰਡਿਆਂ ਤੋਂ।

ਤੈਨਾਤ

• ਸੰਮੇਲਨਾਂ ਦੀ ਜਾਂਚ ਕਰਨਾ। ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਤੁਸੀਂ ਸੇਵਾ ਅਸੈਂਬਲੀਆਂ ਨੂੰ ਆਪਣੇ ਨਿਯਤ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ ਪ੍ਰਦਾਨ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰੋ, ਤੁਹਾਨੂੰ ਹੇਠ ਲਿਖਿਆਂ ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਲੋੜ ਹੈ:
- API ਅੰਤ ਬਿੰਦੂ।
- ਸਕੀਮਾ ਦੇ ਨਾਲ API ਅੰਤਮ ਬਿੰਦੂ ਜਵਾਬਾਂ ਦੀ ਪਾਲਣਾ।
- ਲੌਗ ਫਾਰਮੈਟ।
- ਸੇਵਾ ਲਈ ਬੇਨਤੀਆਂ ਲਈ ਸਿਰਲੇਖ ਸੈੱਟ ਕਰਨਾ (ਵਰਤਮਾਨ ਵਿੱਚ ਇਹ ਨੇਤਰਮੇਸ਼ ਦੁਆਰਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ)
- ਇਵੈਂਟ ਬੱਸ ਨੂੰ ਸੁਨੇਹੇ ਭੇਜਣ ਵੇਲੇ ਮਾਲਕ ਟੋਕਨ ਸੈੱਟ ਕਰਨਾ। ਬੱਸ ਵਿੱਚ ਸੇਵਾਵਾਂ ਦੀ ਕਨੈਕਟੀਵਿਟੀ ਨੂੰ ਟਰੈਕ ਕਰਨ ਲਈ ਇਹ ਲੋੜੀਂਦਾ ਹੈ। ਤੁਸੀਂ ਬੱਸ ਨੂੰ ਦੋਨੋ ਇਮਪੋਟੈਂਟ ਡੇਟਾ ਭੇਜ ਸਕਦੇ ਹੋ, ਜੋ ਸੇਵਾਵਾਂ ਦੀ ਕਨੈਕਟੀਵਿਟੀ ਨੂੰ ਨਹੀਂ ਵਧਾਉਂਦਾ (ਜੋ ਕਿ ਚੰਗਾ ਹੈ), ਅਤੇ ਵਪਾਰਕ ਡੇਟਾ ਜੋ ਸੇਵਾਵਾਂ ਦੀ ਕਨੈਕਟੀਵਿਟੀ ਨੂੰ ਮਜ਼ਬੂਤ ​​ਕਰਦਾ ਹੈ (ਜੋ ਕਿ ਬਹੁਤ ਮਾੜਾ ਹੈ!)। ਅਤੇ ਇਸ ਬਿੰਦੂ 'ਤੇ ਜਦੋਂ ਇਹ ਕਨੈਕਟੀਵਿਟੀ ਇੱਕ ਮੁੱਦਾ ਬਣ ਜਾਂਦੀ ਹੈ, ਇਹ ਸਮਝਣਾ ਕਿ ਬੱਸ ਕੌਣ ਲਿਖਦਾ ਅਤੇ ਪੜ੍ਹਦਾ ਹੈ, ਸੇਵਾਵਾਂ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਵੱਖ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।

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

ਸਿੰਥੈਟਿਕ ਟੈਸਟ

• ਬੰਦ ਲੂਪ ਟੈਸਟਿੰਗ। ਇਸਦੇ ਲਈ ਅਸੀਂ ਹੁਣ ਓਪਨ ਸੋਰਸ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹਾਂ Hoverfly.io. ਪਹਿਲਾਂ, ਇਹ ਸੇਵਾ 'ਤੇ ਅਸਲ ਲੋਡ ਨੂੰ ਰਿਕਾਰਡ ਕਰਦਾ ਹੈ, ਫਿਰ - ਸਿਰਫ ਇੱਕ ਬੰਦ ਲੂਪ ਵਿੱਚ - ਇਹ ਇਸਦੀ ਨਕਲ ਕਰਦਾ ਹੈ।

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

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

a) ਅਸੀਂ ਕੁੱਲ ਲੋਡ ਨੂੰ ਦੇਖਦੇ ਹਾਂ।
- ਬਹੁਤ ਛੋਟਾ - ਜ਼ਿਆਦਾਤਰ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਕੁਝ ਕੰਮ ਨਹੀਂ ਕਰਦਾ ਜੇ ਲੋਡ ਅਚਾਨਕ ਕਈ ਵਾਰ ਘੱਟ ਜਾਂਦਾ ਹੈ.
- ਬਹੁਤ ਵੱਡਾ - ਅਨੁਕੂਲਤਾ ਦੀ ਲੋੜ ਹੈ।

b) ਅਸੀਂ RPS ਦੇ ਅਨੁਸਾਰ ਕੱਟਆਫ ਨੂੰ ਦੇਖਦੇ ਹਾਂ।
ਇੱਥੇ ਅਸੀਂ ਮੌਜੂਦਾ ਸੰਸਕਰਣ ਅਤੇ ਪਿਛਲੇ ਸੰਸਕਰਣ ਅਤੇ ਕੁੱਲ ਮਾਤਰਾ ਵਿੱਚ ਅੰਤਰ ਦੇਖਦੇ ਹਾਂ। ਉਦਾਹਰਨ ਲਈ, ਜੇ ਕੋਈ ਸੇਵਾ 100 ਆਰਪੀਐਸ ਪੈਦਾ ਕਰਦੀ ਹੈ, ਤਾਂ ਇਹ ਜਾਂ ਤਾਂ ਮਾੜੀ ਲਿਖੀ ਗਈ ਹੈ, ਜਾਂ ਇਹ ਇਸਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ, ਪਰ ਕਿਸੇ ਵੀ ਸਥਿਤੀ ਵਿੱਚ, ਇਹ ਸੇਵਾ ਨੂੰ ਬਹੁਤ ਧਿਆਨ ਨਾਲ ਦੇਖਣ ਦਾ ਇੱਕ ਕਾਰਨ ਹੈ.
ਜੇ, ਇਸਦੇ ਉਲਟ, ਬਹੁਤ ਸਾਰੇ ਆਰਪੀਐਸ ਹਨ, ਤਾਂ ਸ਼ਾਇਦ ਕੁਝ ਕਿਸਮ ਦਾ ਬੱਗ ਹੈ ਅਤੇ ਕੁਝ ਅੰਤਮ ਬਿੰਦੂਆਂ ਨੇ ਪੇਲੋਡ ਨੂੰ ਚਲਾਉਣਾ ਬੰਦ ਕਰ ਦਿੱਤਾ ਹੈ, ਪਰ ਕੁਝ ਹੋਰ ਇੱਕ ਨੂੰ ਸਿਰਫ਼ ਚਾਲੂ ਕੀਤਾ ਗਿਆ ਹੈ return true;

ਕੈਨਰੀ ਟੈਸਟ

ਸਿੰਥੈਟਿਕ ਟੈਸਟ ਪਾਸ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਥੋੜ੍ਹੇ ਜਿਹੇ ਉਪਭੋਗਤਾਵਾਂ 'ਤੇ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਾਂ। ਅਸੀਂ ਧਿਆਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੇ ਹਾਂ, ਸੇਵਾ ਦੇ ਉਦੇਸ਼ ਵਾਲੇ ਦਰਸ਼ਕਾਂ ਦੇ ਇੱਕ ਛੋਟੇ ਹਿੱਸੇ ਨਾਲ - 0,1% ਤੋਂ ਘੱਟ। ਇਸ ਪੜਾਅ 'ਤੇ, ਇਹ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਸਹੀ ਤਕਨੀਕੀ ਅਤੇ ਉਤਪਾਦ ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਨਿਗਰਾਨੀ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ ਹੈ ਤਾਂ ਜੋ ਉਹ ਜਿੰਨੀ ਜਲਦੀ ਹੋ ਸਕੇ ਸੇਵਾ ਵਿੱਚ ਸਮੱਸਿਆ ਨੂੰ ਦਰਸਾਉਣ। ਕੈਨਰੀ ਟੈਸਟ ਲਈ ਘੱਟੋ-ਘੱਟ ਸਮਾਂ 5 ਮਿੰਟ ਹੈ, ਮੁੱਖ ਸਮਾਂ 2 ਘੰਟੇ ਹੈ। ਗੁੰਝਲਦਾਰ ਸੇਵਾਵਾਂ ਲਈ, ਅਸੀਂ ਹੱਥੀਂ ਸਮਾਂ ਸੈੱਟ ਕਰਦੇ ਹਾਂ।
ਆਉ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰੀਏ:
- ਭਾਸ਼ਾ-ਵਿਸ਼ੇਸ਼ ਮੈਟ੍ਰਿਕਸ, ਖਾਸ ਤੌਰ 'ਤੇ, php-fpm ਵਰਕਰ;
- ਸੰਤਰੀ ਵਿੱਚ ਗਲਤੀਆਂ;
- ਜਵਾਬ ਸਥਿਤੀਆਂ;
- ਜਵਾਬ ਸਮਾਂ, ਸਹੀ ਅਤੇ ਔਸਤ;
- ਲੇਟੈਂਸੀ;
- ਅਪਵਾਦ, ਸੰਸਾਧਿਤ ਅਤੇ ਅਣ-ਪ੍ਰਬੰਧਿਤ;
- ਉਤਪਾਦ ਮੈਟ੍ਰਿਕਸ.

ਸਕਿਊਜ਼ ਟੈਸਟਿੰਗ

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

ਉਤਪਾਦਨ

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

ਨਤੀਜੇ ਵਜੋਂ, ਸਕੇਲਿੰਗ ਕਰਦੇ ਸਮੇਂ ਅਸੀਂ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦੇ ਹਾਂ:
- CPU ਅਤੇ RAM ਸੂਚਕ,
- ਕਤਾਰ ਵਿੱਚ ਬੇਨਤੀਆਂ ਦੀ ਗਿਣਤੀ,
- ਜਵਾਬ ਸਮਾਂ,
- ਇਕੱਠੇ ਕੀਤੇ ਇਤਿਹਾਸਕ ਡੇਟਾ ਦੇ ਅਧਾਰ ਤੇ ਪੂਰਵ ਅਨੁਮਾਨ।

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

ਸੇਵਾ

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

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

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

ਡੈਸ਼ਬੋਰਡ

ਸੰਖੇਪ ਵਿੱਚ, ਡੈਸ਼ਬੋਰਡ ਸਾਡੇ ਪੂਰੇ PaaS ਦਾ ਕੰਟਰੋਲ ਪੈਨਲ ਹੈ।

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

ਕੁੱਲ

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

ਮੈਂ ਹਾਈਲੋਡ++ 2018 ਲਈ ਇਸ ਵਿਸ਼ੇ 'ਤੇ ਇੱਕ ਰਿਪੋਰਟ ਦਿੱਤੀ ਹੈ, ਤੁਸੀਂ ਇਸਨੂੰ ਦੇਖ ਸਕਦੇ ਹੋ видео и ਪੇਸ਼ਕਾਰੀ.

ਉਹਨਾਂ ਲਈ ਬੋਨਸ ਟਰੈਕ ਜੋ ਅੰਤ ਤੱਕ ਪੜ੍ਹਦੇ ਹਨ

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

ਇਹ ਸਿਖਲਾਈ ਮਾਸਕੋ ਵਿੱਚ 5 ਤੋਂ 7 ਅਗਸਤ ਤੱਕ ਹੋਵੇਗੀ। ਇਹ ਕੰਮ ਦੇ ਦਿਨ ਹਨ ਜੋ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵਿਅਸਤ ਹੋ ਜਾਣਗੇ। ਦੁਪਹਿਰ ਦਾ ਖਾਣਾ ਅਤੇ ਸਿਖਲਾਈ ਸਾਡੇ ਦਫ਼ਤਰ ਵਿੱਚ ਹੋਵੇਗੀ, ਅਤੇ ਚੁਣਿਆ ਗਿਆ ਭਾਗੀਦਾਰ ਯਾਤਰਾ ਅਤੇ ਰਿਹਾਇਸ਼ ਲਈ ਖੁਦ ਭੁਗਤਾਨ ਕਰੇਗਾ।

ਤੁਸੀਂ ਭਾਗੀਦਾਰੀ ਲਈ ਅਰਜ਼ੀ ਦੇ ਸਕਦੇ ਹੋ ਇਸ ਗੂਗਲ ਫਾਰਮ ਵਿੱਚ. ਤੁਹਾਡੇ ਵੱਲੋਂ - ਇਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਕਿ ਤੁਹਾਨੂੰ ਸਿਖਲਾਈ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ ਅਤੇ ਤੁਹਾਡੇ ਨਾਲ ਸੰਪਰਕ ਕਰਨ ਬਾਰੇ ਜਾਣਕਾਰੀ। ਅੰਗਰੇਜ਼ੀ ਵਿੱਚ ਜਵਾਬ ਦਿਓ, ਕਿਉਂਕਿ ਕ੍ਰਿਸ ਭਾਗੀਦਾਰ ਦੀ ਚੋਣ ਕਰੇਗਾ ਜੋ ਖੁਦ ਸਿਖਲਾਈ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਵੇਗਾ।
ਅਸੀਂ ਇਸ ਪੋਸਟ ਦੇ ਇੱਕ ਅਪਡੇਟ ਵਿੱਚ ਅਤੇ ਡਿਵੈਲਪਰਾਂ ਲਈ ਅਵੀਟੋ (AvitoTech in) ਸੋਸ਼ਲ ਨੈਟਵਰਕਸ ਵਿੱਚ ਸਿਖਲਾਈ ਭਾਗੀਦਾਰ ਦੇ ਨਾਮ ਦੀ ਘੋਸ਼ਣਾ ਕਰਾਂਗੇ ਫੇਸਬੁੱਕ, Ð'конÑ,Ð ° кÑ,Ðμ, ਟਵਿੱਟਰ) 19 ਜੁਲਾਈ ਤੋਂ ਬਾਅਦ ਨਹੀਂ।

ਸਰੋਤ: www.habr.com