ਸੇਵਾ ਜਾਲ ਦੀ ਵਰਤੋਂ ਦੇ ਦ੍ਰਿਸ਼

ਨੋਟ ਕਰੋ। ਅਨੁਵਾਦ: ਇਸ ਲੇਖ ਦਾ ਲੇਖਕ (ਲੂਕ ​​ਪਰਕਿਨਜ਼) ਸੀਐਨਸੀਐਫ ਸੰਸਥਾ ਵਿੱਚ ਇੱਕ ਡਿਵੈਲਪਰ ਐਡਵੋਕੇਟ ਹੈ, ਜੋ ਕਿ ਲਿੰਕਰਡ, ਐਸਐਮਆਈ (ਸਰਵਿਸ ਮੇਸ਼ ਇੰਟਰਫੇਸ) ਅਤੇ ਕੁਮਾ (ਜਿਵੇਂ ਕਿ ਓਪਨ ਸੋਰਸ ਪ੍ਰੋਜੈਕਟਾਂ ਦਾ ਘਰ ਹੈ, ਕੀ ਤੁਸੀਂ ਇਹ ਵੀ ਸੋਚਿਆ ਹੈ ਕਿ Istio ਕਿਉਂ ਹੈ? ਇਸ ਸੂਚੀ ਵਿੱਚ ਨਹੀਂ? .) ਇੱਕ ਵਾਰ ਫਿਰ DevOps ਕਮਿਊਨਿਟੀ ਨੂੰ "ਸੇਵਾ ਜਾਲ" ਨਾਮਕ ਟਰੈਡੀ ਹਾਈਪ ਦੀ ਬਿਹਤਰ ਸਮਝ ਲਿਆਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੈ, ਉਹ 16 ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਸੂਚੀ ਦਿੰਦਾ ਹੈ ਜੋ ਅਜਿਹੇ ਹੱਲ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ।

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

* ਨੋਟ ਅਨੁਵਾਦ: ਇੱਥੇ ਅਤੇ ਅੱਗੇ ਲੇਖ ਵਿੱਚ ਬਿਲਕੁਲ ਇਸ ਅਨੁਵਾਦ ("ਸੇਵਾ ਜਾਲ") ਦੀ ਵਰਤੋਂ ਅਜੇ ਵੀ ਨਵੀਂ ਮਿਆਦ ਸੇਵਾ ਜਾਲ ਲਈ ਕੀਤੀ ਜਾਵੇਗੀ।

ਪਰ ਪਹਿਲਾਂ ਮੈਂ ਕੁਝ ਟਿੱਪਣੀਆਂ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ:

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

ਛੋਟੀ ਸੂਚੀ:

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

1. ਸੇਵਾ ਖੋਜ

TL; DR: ਸਧਾਰਨ ਨਾਮ ਵਰਤ ਕੇ ਨੈੱਟਵਰਕ 'ਤੇ ਹੋਰ ਸੇਵਾਵਾਂ ਨਾਲ ਜੁੜੋ।

ਸੇਵਾਵਾਂ ਨੂੰ ਢੁਕਵੇਂ ਨਾਮਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਦੂਜੇ ਨੂੰ ਆਪਣੇ ਆਪ "ਲੱਭਣ" ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ - ਉਦਾਹਰਨ ਲਈ, service.api.production, pets/staging ਜ cassandra. ਕਲਾਉਡ ਵਾਤਾਵਰਣ ਲਚਕੀਲੇ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਇੱਕ ਇੱਕਲਾ ਨਾਮ ਸੇਵਾ ਦੀਆਂ ਬਹੁਤ ਸਾਰੀਆਂ ਉਦਾਹਰਣਾਂ ਨੂੰ ਲੁਕਾ ਸਕਦਾ ਹੈ। ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਅਜਿਹੀ ਸਥਿਤੀ ਵਿੱਚ ਸਾਰੇ IP ਐਡਰੈੱਸ ਨੂੰ ਹਾਰਡਕੋਡ ਕਰਨਾ ਸਰੀਰਕ ਤੌਰ 'ਤੇ ਅਸੰਭਵ ਹੈ।

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

ਹਰੇਕ ਸੇਵਾ ਜਾਲ ਸੇਵਾ ਖੋਜ ਵਿਧੀ ਨੂੰ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਲਾਗੂ ਕਰਦੀ ਹੈ। ਇਸ ਸਮੇਂ, ਸਭ ਤੋਂ ਆਮ ਤਰੀਕਾ ਹੈ ਬਾਹਰੀ ਪ੍ਰਕਿਰਿਆਵਾਂ ਜਿਵੇਂ ਕਿ Kubernetes DNS ਨੂੰ ਸੌਂਪਣਾ। ਅਤੀਤ ਵਿੱਚ ਟਵਿੱਟਰ 'ਤੇ ਅਸੀਂ ਇਸ ਉਦੇਸ਼ ਲਈ ਇੱਕ ਨਾਮਕਰਨ ਪ੍ਰਣਾਲੀ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਸੀ ਫਿਨਾਗਲ. ਇਸ ਤੋਂ ਇਲਾਵਾ, ਸੇਵਾ ਜਾਲ ਤਕਨਾਲੋਜੀ ਕਸਟਮ ਨਾਮਕਰਨ ਵਿਧੀਆਂ ਨੂੰ ਉਭਰਨਾ ਸੰਭਵ ਬਣਾਉਂਦੀ ਹੈ (ਹਾਲਾਂਕਿ ਮੈਂ ਅਜੇ ਤੱਕ ਅਜਿਹੀ ਕਾਰਜਸ਼ੀਲਤਾ ਦੇ ਨਾਲ ਕੋਈ ਐਸਐਮ ਲਾਗੂ ਨਹੀਂ ਦੇਖਿਆ ਹੈ)।

2. ਐਨਕ੍ਰਿਪਸ਼ਨ

TL;DR: ਸੇਵਾਵਾਂ ਦੇ ਵਿਚਕਾਰ ਅਣਏਨਕ੍ਰਿਪਟਡ ਟ੍ਰੈਫਿਕ ਤੋਂ ਛੁਟਕਾਰਾ ਪਾਓ ਅਤੇ ਇਸ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸਵੈਚਲਿਤ ਅਤੇ ਸਕੇਲੇਬਲ ਬਣਾਓ।

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

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

3. ਪ੍ਰਮਾਣੀਕਰਨ ਅਤੇ ਅਧਿਕਾਰ

TL; DR: ਇਹ ਸਥਾਪਿਤ ਕਰੋ ਕਿ ਬੇਨਤੀਕਰਤਾ ਕੌਣ ਹੈ ਅਤੇ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਕਿ ਬੇਨਤੀ ਸੇਵਾ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹਨਾਂ ਨੂੰ ਕੀ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਹੈ।

ਸੇਵਾਵਾਂ ਅਕਸਰ ਜਾਣਨਾ ਚਾਹੁੰਦੀਆਂ ਹਨ ਕੌਣ ਬੇਨਤੀ (ਪ੍ਰਮਾਣਿਕਤਾ) ਕਰਦਾ ਹੈ, ਅਤੇ ਇਸ ਜਾਣਕਾਰੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ, ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਹੈ, ਜੋ ਕਿ ਇੱਕ ਦਿੱਤੀ ਹਸਤੀ ਨੂੰ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਹੈ (ਅਧਿਕਾਰਤ). ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਸਰਵਣ "ਕੌਣ" ਛੁਪਾ ਸਕਦਾ ਹੈ:

1. ਹੋਰ ਸੇਵਾਵਾਂ। ਇਸਨੂੰ "ਪ੍ਰਮਾਣਿਕਤਾ" ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਸਾਥੀ" ਉਦਾਹਰਨ ਲਈ, ਸੇਵਾ web ਸੇਵਾ ਤੱਕ ਪਹੁੰਚ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ db. ਸਰਵਿਸ ਮੇਸ਼ ਆਮ ਤੌਰ 'ਤੇ mTLS ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਅਜਿਹੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਦੇ ਹਨ: ਇਸ ਕੇਸ ਵਿੱਚ ਸਰਟੀਫਿਕੇਟ ਜ਼ਰੂਰੀ ਪਛਾਣਕਰਤਾ ਵਜੋਂ ਕੰਮ ਕਰਦੇ ਹਨ।
2. ਕੁਝ ਮਨੁੱਖੀ ਉਪਭੋਗਤਾ। ਇਸਨੂੰ "ਪ੍ਰਮਾਣਿਕਤਾ" ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਬੇਨਤੀ" ਉਦਾਹਰਨ ਲਈ, ਉਪਭੋਗਤਾ haxor69 ਇੱਕ ਨਵਾਂ ਲੈਂਪ ਖਰੀਦਣਾ ਚਾਹੁੰਦਾ ਹੈ। ਸਰਵਿਸ ਮੇਸ਼ ਵੱਖ-ਵੱਖ ਵਿਧੀਆਂ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ, ਉਦਾਹਰਨ ਲਈ JSON ਵੈੱਬ ਟੋਕਨ.

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

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

4. ਲੋਡ ਸੰਤੁਲਨ

TL; DR: ਇੱਕ ਖਾਸ ਪੈਟਰਨ ਦੇ ਅਨੁਸਾਰ ਸੇਵਾ ਦੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਲੋਡ ਨੂੰ ਵੰਡੋ।

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

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

5. ਸਰਕਟ ਤੋੜਨਾ

TL;DR: ਸਮੱਸਿਆ ਵਾਲੀ ਸੇਵਾ ਲਈ ਆਵਾਜਾਈ ਨੂੰ ਰੋਕੋ ਅਤੇ ਸਭ ਤੋਂ ਮਾੜੇ ਹਾਲਾਤਾਂ ਵਿੱਚ ਨੁਕਸਾਨ ਨੂੰ ਕੰਟਰੋਲ ਕਰੋ।

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

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

ਤੁਸੀਂ ਸ਼ਾਇਦ ਸਰਕਟ ਤੋੜਨ ਦੀ ਦੁਰਵਰਤੋਂ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਪਰ ਇਹ ਜਾਣ ਕੇ ਚੰਗਾ ਲੱਗਿਆ ਕਿ ਐਮਰਜੈਂਸੀ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਤੁਹਾਡੇ ਕੋਲ ਬੈਕਅੱਪ ਯੋਜਨਾ ਹੈ।

6. ਆਟੋਸਕੇਲਿੰਗ

TL;DR: ਨਿਸ਼ਚਿਤ ਮਾਪਦੰਡ ਦੇ ਆਧਾਰ 'ਤੇ ਸੇਵਾ ਦੇ ਮਾਮਲਿਆਂ ਦੀ ਗਿਣਤੀ ਵਧਾਓ ਜਾਂ ਘਟਾਓ।

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

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

7. ਕੈਨਰੀ ਤੈਨਾਤੀਆਂ

TL;DR: ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਇੱਕ ਉਪ ਸਮੂਹ 'ਤੇ ਨਵੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਜਾਂ ਸੇਵਾ ਸੰਸਕਰਣਾਂ ਦੀ ਜਾਂਚ ਕਰੋ।

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

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

8. ਨੀਲੀ-ਹਰੇ ਤੈਨਾਤੀਆਂ

TL;DR: ਇੱਕ ਵਧੀਆ ਨਵੀਂ ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ ਰੋਲ ਆਊਟ ਕਰੋ, ਪਰ ਤੁਰੰਤ ਸਭ ਕੁਝ ਵਾਪਸ ਲੈਣ ਲਈ ਤਿਆਰ ਰਹੋ।

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

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

ਨੋਟ ਕਰੋ। ਅਨੁਵਾਦ: ਤੁਸੀਂ ਕੁਬਰਨੇਟਸ (ਉਲੇਖ ਕੀਤੇ ਕੈਨਰੀ, ਨੀਲੇ/ਹਰੇ ਅਤੇ ਹੋਰਾਂ ਸਮੇਤ) ਵਿੱਚ ਵੱਖ-ਵੱਖ ਤੈਨਾਤੀ ਰਣਨੀਤੀਆਂ ਬਾਰੇ ਹੋਰ ਪੜ੍ਹ ਸਕਦੇ ਹੋ। ਇਸ ਲੇਖ.

9. ਸਿਹਤ ਜਾਂਚ

TL;DR: ਇਸ ਗੱਲ ਦਾ ਧਿਆਨ ਰੱਖੋ ਕਿ ਕਿਹੜੀਆਂ ਸੇਵਾ ਉਦਾਹਰਨਾਂ ਕਾਰਜਸ਼ੀਲ ਹਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਜਵਾਬ ਦਿਓ ਜੋ ਹੁਣ ਕਾਰਜਸ਼ੀਲ ਨਹੀਂ ਹਨ।

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

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

10. ਲੋਡ ਸ਼ੈਡਿੰਗ

TL;DR: ਵਰਤੋਂ ਵਿੱਚ ਅਸਥਾਈ ਵਾਧੇ ਦੇ ਜਵਾਬ ਵਿੱਚ ਆਵਾਜਾਈ ਨੂੰ ਰੀਡਾਇਰੈਕਟ ਕਰੋ।

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

11. ਟ੍ਰੈਫਿਕ ਸਮਾਨਤਾ/ਮਿਰਰਿੰਗ

TL; DR: ਇੱਕ ਵਾਰ ਵਿੱਚ ਕਈ ਥਾਵਾਂ 'ਤੇ ਇੱਕ ਬੇਨਤੀ ਭੇਜੋ।

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

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

12. ਇਨਸੂਲੇਸ਼ਨ

TL;DR: ਆਪਣੇ ਸੇਵਾ ਜਾਲ ਨੂੰ ਮਿੰਨੀ-ਨੈੱਟਵਰਕ ਵਿੱਚ ਤੋੜੋ।

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

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

13. ਦਰ ਸੀਮਤ ਕਰਨ, ਮੁੜ ਕੋਸ਼ਿਸ਼ਾਂ ਅਤੇ ਸਮਾਂ ਸਮਾਪਤ ਕਰਨ ਦੀ ਬੇਨਤੀ ਕਰੋ

TL; DR: ਤੁਹਾਨੂੰ ਹੁਣ ਆਪਣੇ ਕੋਡਬੇਸ ਵਿੱਚ ਨਿਟੀ-ਗਰੀਟੀ ਬੇਨਤੀ ਪ੍ਰਬੰਧਨ ਕਾਰਜਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ।

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

ਇਹਨਾਂ ਕਾਰਜਾਂ ਨੂੰ ਇੱਕ ਸੇਵਾ ਜਾਲ ਵਿੱਚ ਔਫਲੋਡ ਕਰਨ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਸੇਵਾ ਵਿਕਾਸਕਰਤਾਵਾਂ ਨੂੰ ਉਹਨਾਂ ਬਾਰੇ ਸੋਚਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੋਵੇਗੀ, ਸਗੋਂ ਇਹ ਵੀ ਕਿ ਉਹਨਾਂ ਨੂੰ ਵਧੇਰੇ ਗਲੋਬਲ ਤਰੀਕੇ ਨਾਲ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਜੇ ਸੇਵਾਵਾਂ ਦੀ ਇੱਕ ਗੁੰਝਲਦਾਰ ਲੜੀ ਵਰਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਕਹੋ A -> B -> C -> D -> E, ਬੇਨਤੀ ਦੇ ਪੂਰੇ ਜੀਵਨ ਚੱਕਰ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇਕਰ ਕੰਮ ਸੇਵਾ C ਵਿੱਚ ਸਮਾਂ ਸਮਾਪਤੀ ਨੂੰ ਵਧਾਉਣਾ ਹੈ, ਤਾਂ ਇਹ ਸਭ ਕੁਝ ਇੱਕੋ ਵਾਰ ਕਰਨਾ ਹੈ, ਨਾ ਕਿ ਹਿੱਸਿਆਂ ਵਿੱਚ: ਸੇਵਾ ਕੋਡ ਨੂੰ ਅੱਪਡੇਟ ਕਰਕੇ ਅਤੇ ਪੁੱਲ ਬੇਨਤੀ ਸਵੀਕਾਰ ਹੋਣ ਤੱਕ ਉਡੀਕ ਕਰਕੇ ਅਤੇ CI ਸਿਸਟਮ ਅੱਪਡੇਟ ਕੀਤੀ ਸੇਵਾ ਨੂੰ ਤੈਨਾਤ ਕਰਦਾ ਹੈ।

14. ਟੈਲੀਮੈਟਰੀ

TL;DR: ਸੇਵਾਵਾਂ ਤੋਂ ਸਾਰੀ ਲੋੜੀਂਦੀ (ਅਤੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਹੀਂ) ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਕਰੋ।

ਟੈਲੀਮੈਟਰੀ ਇੱਕ ਆਮ ਸ਼ਬਦ ਹੈ ਜਿਸ ਵਿੱਚ ਮੈਟ੍ਰਿਕਸ, ਵਿਤਰਿਤ ਟਰੇਸਿੰਗ ਅਤੇ ਲੌਗ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ। ਸਰਵਿਸ ਮੇਸ਼ ਸਾਰੇ ਤਿੰਨ ਕਿਸਮ ਦੇ ਡੇਟਾ ਨੂੰ ਇਕੱਤਰ ਕਰਨ ਅਤੇ ਪ੍ਰੋਸੈਸ ਕਰਨ ਲਈ ਵਿਧੀ ਪੇਸ਼ ਕਰਦੇ ਹਨ। ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਚੀਜ਼ਾਂ ਥੋੜੀਆਂ ਧੁੰਦਲੀਆਂ ਹੋ ਜਾਂਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਸੰਭਵ ਵਿਕਲਪਾਂ ਦੀ ਗਿਣਤੀ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੈ। ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਲਈ ਉੱਥੇ ਹੈ Prometheus ਅਤੇ ਹੋਰ ਸਾਧਨ ਜੋ ਲੌਗ ਇਕੱਠੇ ਕਰਨ ਲਈ ਵਰਤੇ ਜਾ ਸਕਦੇ ਹਨ ਰਵਾਨਗੀ, ਲੋਕੀ, ਵੈਕਟਰ et al. (ਉਦਾਹਰਨ ਲਈ ਸਾਡੇ ਨਾਲ ਕਲਿਕਹਾਊਸ ਲਾਗ ਹਾਊਸ K8s ਲਈ - ਲਗਭਗ. ਅਨੁਵਾਦ।), ਵਿਤਰਿਤ ਟਰੇਸਿੰਗ ਲਈ ਹੈ ਜਗੇਰ ਇਤਆਦਿ. ਹਰੇਕ ਸੇਵਾ ਜਾਲ ਕੁਝ ਸਾਧਨਾਂ ਦਾ ਸਮਰਥਨ ਕਰ ਸਕਦਾ ਹੈ ਨਾ ਕਿ ਹੋਰਾਂ ਦਾ। ਇਹ ਦੇਖਣਾ ਦਿਲਚਸਪ ਹੋਵੇਗਾ ਕਿ ਕੀ ਪ੍ਰੋਜੈਕਟ ਕਰ ਸਕਦਾ ਹੈ ਟੈਲੀਮੈਟਰੀ ਖੋਲ੍ਹੋ ਕੁਝ ਕਨਵਰਜੈਂਸ ਪ੍ਰਦਾਨ ਕਰੋ।

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

• CLI ਵਿੱਚ ਕਿਸੇ ਖਾਸ ਸੇਵਾ ਤੋਂ ਟੇਲ ਲੌਗਸ;
• ਸਰਵਿਸ ਮੈਸ਼ ਡੈਸ਼ਬੋਰਡ ਤੋਂ ਬੇਨਤੀਆਂ ਦੀ ਮਾਤਰਾ ਦੀ ਨਿਗਰਾਨੀ ਕਰੋ;
• ਵੰਡੇ ਹੋਏ ਟਰੇਸ ਇਕੱਠੇ ਕਰੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਜੈਗਰ ਵਰਗੇ ਸਿਸਟਮ ਵਿੱਚ ਅੱਗੇ ਭੇਜੋ।

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

15. ਆਡਿਟ

TL; DR: ਜਿਹੜੇ ਲੋਕ ਇਤਿਹਾਸ ਦੇ ਸਬਕ ਭੁੱਲ ਜਾਂਦੇ ਹਨ, ਉਹ ਉਨ੍ਹਾਂ ਨੂੰ ਦੁਹਰਾਉਣ ਲਈ ਬਰਬਾਦ ਹੁੰਦੇ ਹਨ।

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

ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਆਡਿਟਿੰਗ ਟੈਲੀਮੈਟਰੀ ਨਾਲ ਬਹੁਤ ਨੇੜਿਓਂ ਸਬੰਧਤ ਹੈ। ਫਰਕ ਇਹ ਹੈ ਕਿ ਟੈਲੀਮੈਟਰੀ ਆਮ ਤੌਰ 'ਤੇ ਉਤਪਾਦਕਤਾ ਅਤੇ ਤਕਨੀਕੀ ਤੰਦਰੁਸਤੀ ਵਰਗੀਆਂ ਚੀਜ਼ਾਂ ਨਾਲ ਜੁੜੀ ਹੁੰਦੀ ਹੈ, ਜਦੋਂ ਕਿ ਆਡਿਟਿੰਗ ਕਾਨੂੰਨੀ ਅਤੇ ਹੋਰ ਮੁੱਦਿਆਂ ਨਾਲ ਸਬੰਧਤ ਹੋ ਸਕਦੀ ਹੈ ਜੋ ਸਖਤੀ ਨਾਲ ਤਕਨੀਕੀ ਖੇਤਰ ਤੋਂ ਬਾਹਰ ਜਾਂਦੇ ਹਨ (ਉਦਾਹਰਣ ਵਜੋਂ, GDPR - ਡੇਟਾ ਸੁਰੱਖਿਆ 'ਤੇ EU ਜਨਰਲ ਰੈਗੂਲੇਸ਼ਨ) ਦੀ ਪਾਲਣਾ।

16. ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ

TL;DR: ਲੌਂਗ ਲਾਈਵ React.js - ਸ਼ਾਨਦਾਰ ਇੰਟਰਫੇਸ ਦਾ ਇੱਕ ਅਮੁੱਕ ਸਰੋਤ।

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

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

ਸੂਚੀ ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਸਨ

ਮੈਂ ਅਸਲ ਵਿੱਚ ਸੂਚੀ ਵਿੱਚ ਕੁਝ ਹੋਰ ਵਰਤੋਂ ਦੇ ਕੇਸਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਦਾ ਇਰਾਦਾ ਰੱਖਦਾ ਸੀ, ਪਰ ਫਿਰ ਨਾ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ। ਮੇਰੇ ਫੈਸਲੇ ਦੇ ਕਾਰਨਾਂ ਦੇ ਨਾਲ ਉਹ ਇੱਥੇ ਹਨ:

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

ਸਿੱਟਾ

ਹੁਣ ਲਈ ਇਹ ਸਭ ਕੁਝ ਹੈ! ਦੁਬਾਰਾ ਫਿਰ, ਇਹ ਸੂਚੀ ਬਹੁਤ ਮਨਮਾਨੀ ਹੈ ਅਤੇ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਅਧੂਰੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ ਕਿ ਮੈਂ ਕੁਝ ਗੁਆ ਲਿਆ ਹੈ ਜਾਂ ਕੁਝ ਗਲਤ ਹੋ ਗਿਆ ਹੈ, ਤਾਂ ਕਿਰਪਾ ਕਰਕੇ ਮੇਰੇ ਨਾਲ ਟਵਿੱਟਰ 'ਤੇ ਸੰਪਰਕ ਕਰੋ (@luckerkins). ਕਿਰਪਾ ਕਰਕੇ ਸ਼ਿਸ਼ਟਾਚਾਰ ਦੇ ਨਿਯਮਾਂ ਦਾ ਆਦਰ ਕਰੋ।

ਅਨੁਵਾਦਕ ਤੋਂ ਪੀ.ਐਸ

ਲੇਖ ਦਾ ਸਿਰਲੇਖ ਚਿੱਤਰ ਲੇਖ ਦੇ ਇੱਕ ਚਿੱਤਰ 'ਤੇ ਅਧਾਰਤ ਹੈ "ਸਰਵਿਸ ਮੈਸ਼ ਕੀ ਹੈ (ਅਤੇ ਇਸਨੂੰ ਕਦੋਂ ਵਰਤਣਾ ਹੈ)?"(ਗ੍ਰੇਗਰੀ ਮੈਕਕਿਨਨ ਦੁਆਰਾ) ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਕਿਵੇਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਤੋਂ ਕੁਝ ਕਾਰਜਕੁਸ਼ਲਤਾ (ਹਰੇ ਰੰਗ ਵਿੱਚ) ਇੱਕ ਸੇਵਾ ਜਾਲ ਵਿੱਚ ਚਲੀ ਗਈ ਹੈ ਜੋ ਉਹਨਾਂ (ਨੀਲੇ ਵਿੱਚ) ਵਿਚਕਾਰ ਆਪਸੀ ਕੁਨੈਕਸ਼ਨ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ।

ਸਾਡੇ ਬਲੌਗ 'ਤੇ ਵੀ ਪੜ੍ਹੋ:

• «ਸੇਵਾ ਜਾਲ: ਹਰ ਸਾਫਟਵੇਅਰ ਇੰਜੀਨੀਅਰ ਨੂੰ ਸਭ ਤੋਂ ਗਰਮ ਤਕਨਾਲੋਜੀ ਬਾਰੇ ਕੀ ਜਾਣਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ";
• «ਇੱਕ ਸੇਵਾ ਜਾਲ ਕੀ ਹੈ ਅਤੇ ਮੈਨੂੰ [ਮਾਈਕ੍ਰੋਸਰਵਿਸਿਜ਼ ਦੇ ਨਾਲ ਕਲਾਉਡ ਐਪਲੀਕੇਸ਼ਨ ਲਈ] ਇਸਦੀ ਕਿਉਂ ਲੋੜ ਹੈ?";
• «ਇਸਟੀਓ ਦੇ ਨਾਲ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ 'ਤੇ ਵਾਪਸ ਜਾਓ। ਭਾਗ 1".

ਸਰੋਤ: www.habr.com