ਸੇਵਾ ਜਾਲ: ਹਰ ਸਾਫਟਵੇਅਰ ਇੰਜੀਨੀਅਰ ਨੂੰ ਸਭ ਤੋਂ ਗਰਮ ਤਕਨਾਲੋਜੀ ਬਾਰੇ ਕੀ ਜਾਣਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ

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

ਤੋਂ ਕਾਮਿਕ ਸੇਬੇਸਟਿਅਨ ਕੈਸੇਰੇਸ

ਜਾਣ ਪਛਾਣ

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

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

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

ਮੈ ਕੌਨ ਹਾ?

ਸਾਰਿਆਂ ਨੂੰ ਸਤਿ ਸ਼੍ਰੀ ਅਕਾਲ! ਮੇਰਾ ਨਾਮ ਹੈ ਵਿਲੀਅਮ ਮੋਰਗਨ. ਮੈਂ ਸਿਰਜਣਹਾਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹਾਂ ਲਿੰਕਰਡ - ਸਭ ਤੋਂ ਪਹਿਲਾ ਸੇਵਾ ਜਾਲ ਪ੍ਰੋਜੈਕਟ ਅਤੇ ਉਹ ਪ੍ਰੋਜੈਕਟ ਜੋ ਮਿਆਦ ਦੀ ਦਿੱਖ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ ਸੇਵਾ ਜਾਲ ਜਿਵੇਂ ਕਿ (ਮਾਫ ਕਰਨਾ ਦੋਸਤੋ!) (ਨੋਟ ਅਨੁਵਾਦ।: ਵੈਸੇ, ਇਸ ਸ਼ਬਦ ਦੀ ਦਿੱਖ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ, 2,5 ਸਾਲ ਪਹਿਲਾਂ, ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਉਸੇ ਲੇਖਕ ਦੀ ਸ਼ੁਰੂਆਤੀ ਸਮੱਗਰੀ ਦਾ ਅਨੁਵਾਦ ਕਰ ਚੁੱਕੇ ਹਾਂ ਜਿਸਨੂੰ "ਇੱਕ ਸੇਵਾ ਜਾਲ ਕੀ ਹੈ ਅਤੇ ਮੈਨੂੰ [ਮਾਈਕ੍ਰੋਸਰਵਿਸਿਜ਼ ਦੇ ਨਾਲ ਕਲਾਉਡ ਐਪਲੀਕੇਸ਼ਨ ਲਈ] ਇਸਦੀ ਕਿਉਂ ਲੋੜ ਹੈ?"।) ਮੈਂ ਵੀ ਅਗਵਾਈ ਕਰਦਾ ਹਾਂ ਬੁਆਏਂਟ ਇੱਕ ਸਟਾਰਟਅਪ ਹੈ ਜੋ ਲਿੰਕਰਡ ਅਤੇ ਵਰਗੀਆਂ ਵਧੀਆ ਸਰਵਿਸ ਮੇਸ਼ ਚੀਜ਼ਾਂ ਬਣਾਉਂਦਾ ਹੈ ਡਾਈਵ.

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

ਠੀਕ ਹੈ, ਇਹ ਸਲੂਕ 'ਤੇ ਜਾਣ ਦਾ ਸਮਾਂ ਹੈ.

ਸੇਵਾ ਜਾਲ ਕੀ ਹੈ?

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

ਇਹ ਪ੍ਰੌਕਸੀ ਕੀ ਹੈ? ਇਹ "ਲੇਅਰ 7-ਜਾਗਰੂਕ" ਸ਼੍ਰੇਣੀ ਦੀ ਇੱਕ TCP ਪ੍ਰੌਕਸੀ ਹੈ (ਜਿਵੇਂ ਕਿ OSI ਮਾਡਲ ਦੀ 7ਵੀਂ ਪਰਤ ਨੂੰ "ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ") ਜਿਵੇਂ HAProxy ਅਤੇ NGINX। ਤੁਸੀਂ ਆਪਣੀ ਪਸੰਦ ਅਨੁਸਾਰ ਇੱਕ ਪ੍ਰੌਕਸੀ ਚੁਣ ਸਕਦੇ ਹੋ; ਲਿੰਕਰਡ ਇੱਕ ਜੰਗਾਲ ਪ੍ਰੌਕਸੀ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਜਿਸਦਾ ਨਾਮ ਦਿੱਤਾ ਗਿਆ ਹੈ ਲਿੰਕਰਡ-ਪ੍ਰਾਕਸੀ. ਅਸੀਂ ਇਸਨੂੰ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਸੇਵਾ ਜਾਲ ਲਈ ਕੰਪਾਇਲ ਕੀਤਾ ਹੈ. ਹੋਰ ਜਾਲ ਹੋਰ ਪ੍ਰੌਕਸੀਜ਼ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੇ ਹਨ (ਦੂਤ ਇੱਕ ਆਮ ਚੋਣ ਹੈ)। ਹਾਲਾਂਕਿ, ਇੱਕ ਪ੍ਰੌਕਸੀ ਚੁਣਨਾ ਸਿਰਫ ਲਾਗੂ ਕਰਨ ਦਾ ਮਾਮਲਾ ਹੈ।

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

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

ਹੇਠਾਂ ਲਿੰਕਰਡ ਵਿੱਚ ਕੰਟਰੋਲ ਪਲੇਨ ਅਤੇ ਡੇਟਾ ਪਲੇਨ ਦਾ ਇੱਕ ਚਿੱਤਰ ਹੈ। ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ, ਕੰਟਰੋਲ ਪਲੇਨ ਵਿੱਚ ਕਈ ਵੱਖ-ਵੱਖ ਭਾਗ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ, ਜਿਸ ਵਿੱਚ ਇੱਕ ਪ੍ਰੋਮੀਥੀਅਸ ਉਦਾਹਰਣ ਵੀ ਸ਼ਾਮਲ ਹੈ ਜੋ ਪ੍ਰੌਕਸੀ ਸਰਵਰਾਂ ਤੋਂ ਮੈਟ੍ਰਿਕਸ ਇਕੱਠਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਨਾਲ ਹੀ ਹੋਰ ਭਾਗ ਜਿਵੇਂ ਕਿ destination (ਸੇਵਾ ਖੋਜ), identity (ਸਰਟੀਫਿਕੇਟ ਅਥਾਰਟੀ, CA) ਅਤੇ public-api (ਵੈੱਬ ਅਤੇ CLI ਲਈ ਅੰਤਮ ਬਿੰਦੂ)। ਇਸਦੇ ਉਲਟ, ਡੇਟਾ ਪਲੇਨ ਐਪਲੀਕੇਸ਼ਨ ਉਦਾਹਰਨ ਦੇ ਅੱਗੇ ਇੱਕ ਸਧਾਰਨ ਲਿੰਕਰਡ-ਪ੍ਰਾਕਸੀ ਹੈ। ਇਹ ਕੇਵਲ ਇੱਕ ਤਰਕ ਚਿੱਤਰ ਹੈ; ਇੱਕ ਅਸਲ ਸੰਸਾਰ ਤੈਨਾਤੀ ਵਿੱਚ, ਤੁਹਾਡੇ ਕੋਲ ਹਰੇਕ ਕੰਟਰੋਲ ਪਲੇਨ ਕੰਪੋਨੈਂਟ ਦੀਆਂ ਤਿੰਨ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਅਤੇ ਡੇਟਾ ਪਲੇਨ ਵਿੱਚ ਸੈਂਕੜੇ ਜਾਂ ਹਜ਼ਾਰਾਂ ਪ੍ਰੌਕਸੀ ਹੋ ਸਕਦੇ ਹਨ।

(ਇਸ ਡਾਇਗ੍ਰਾਮ ਵਿੱਚ ਨੀਲੇ ਬਕਸੇ ਕੁਬਰਨੇਟਸ ਪੌਡਸ ਦੀਆਂ ਬਾਰਡਰਾਂ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ। ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਲਿੰਕਰਡ-ਪ੍ਰੌਕਸੀ ਵਾਲੇ ਕੰਟੇਨਰ ਉਸੇ ਪੋਡ ਵਿੱਚ ਹਨ ਜਿਵੇਂ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਕੰਟੇਨਰਾਂ ਵਿੱਚ। ਇਸ ਸਕੀਮ ਨੂੰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਸਾਈਡਕਾਰ ਕੰਟੇਨਰ.)

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

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

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

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

ਇਹ ਸਵਾਲ ਦਾ ਸਮਾਂ ਹੈ "ਕਿਉਂ?"

ਸੇਵਾ ਜਾਲ ਕਿਸ ਲਈ ਹੈ?

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

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

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

ਉਦਾਹਰਨ ਲਈ, ਲਿੰਕਰਡ ਵਿੱਚ (ਜਿਵੇਂ ਕਿ ਜ਼ਿਆਦਾਤਰ ਮੇਸ਼ਾਂ ਵਿੱਚ) ਕਾਰਜਕੁਸ਼ਲਤਾ ਮੁੱਖ ਤੌਰ 'ਤੇ HTTP/2 ਅਤੇ gRPC* ਸਮੇਤ HTTP ਕਾਲਾਂ 'ਤੇ ਕੇਂਦਰਿਤ ਹੈ। ਕਾਰਜਕੁਸ਼ਲਤਾ ਕਾਫ਼ੀ ਅਮੀਰ ਹੈ - ਇਸ ਨੂੰ ਤਿੰਨ ਵਰਗਾਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾ ਸਕਦਾ ਹੈ:

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

* ਲਿੰਕਰਡ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, gRPC ਅਮਲੀ ਤੌਰ 'ਤੇ HTTP/2 ਤੋਂ ਵੱਖਰਾ ਨਹੀਂ ਹੈ: ਇਹ ਪੇਲੋਡ ਵਿੱਚ ਪ੍ਰੋਟੋਬੁਫ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਡਿਵੈਲਪਰ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਇਹ ਦੋ ਚੀਜ਼ਾਂ, ਬੇਸ਼ਕ, ਵੱਖਰੀਆਂ ਹਨ.

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

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

* "ਇੱਕ ਦੋਸਤ ਦਾ ਦੋਸਤ" ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਗਾਹਕ ਦਾ ਸਰਟੀਫਿਕੇਟ ਵੀ ਪ੍ਰਮਾਣਿਤ ਹੈ (ਆਪਸੀ TLS)। "ਕਲਾਸਿਕ" TLS ਵਿੱਚ, ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਬ੍ਰਾਊਜ਼ਰ ਅਤੇ ਇੱਕ ਸਰਵਰ ਦੇ ਵਿਚਕਾਰ, ਸਿਰਫ਼ ਇੱਕ ਪਾਸੇ (ਸਰਵਰ) ਦਾ ਸਰਟੀਫਿਕੇਟ ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰਮਾਣਿਤ ਹੁੰਦਾ ਹੈ।

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

ਇਹ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦਾ ਸਮੂਹ ਹੈ ਜੋ ਸੇਵਾ ਜਾਲ ਪੇਸ਼ ਕਰਦਾ ਹੈ। ਸਵਾਲ ਪੈਦਾ ਹੁੰਦਾ ਹੈ: ਕਿਉਂ ਨਾ ਉਹਨਾਂ ਨੂੰ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਅਰਜ਼ੀ ਵਿੱਚ ਲਾਗੂ ਕੀਤਾ ਜਾਵੇ? ਅਤੇ ਪਰਾਕਸੀ ਨਾਲ ਕਿਉਂ ਗੜਬੜ?

ਇੱਕ ਸੇਵਾ ਜਾਲ ਇੱਕ ਚੰਗਾ ਵਿਚਾਰ ਕਿਉਂ ਹੈ

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

ਆਓ ਇਸ ਪ੍ਰਸਤਾਵ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰੀਏ।

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

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

«ਪੂਰੇ ਸਟੈਕ ਲਈ ਯੂਨੀਫਾਰਮ". ਸੇਵਾ ਜਾਲ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਸਿਰਫ਼ ਨਾਜ਼ੁਕ ਨਹੀਂ ਹਨ. ਉਹ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ 'ਤੇ ਲਾਗੂ ਹੁੰਦੇ ਹਨ, ਚਾਹੇ ਉਹ ਕਿਹੜੀ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖੇ ਗਏ ਹਨ, ਉਹ ਕਿਹੜੇ ਢਾਂਚੇ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਕਿਸ ਨੇ ਲਿਖਿਆ, ਉਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਤਾਇਨਾਤ ਕੀਤਾ ਗਿਆ ਸੀ, ਅਤੇ ਉਹਨਾਂ ਦੇ ਵਿਕਾਸ ਅਤੇ ਵਰਤੋਂ ਦੀਆਂ ਹੋਰ ਸਾਰੀਆਂ ਸੂਖਮਤਾਵਾਂ।

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

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

ਅਤੇ ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਪ੍ਰੌਕਸੀਜ਼ ਦਾ ਇੱਕ ਸਮੂਹ ਸ਼ਾਮਲ ਕਰਨ ਦੀ ਲੋੜ ਹੈ! ਮੈਂ ਵਾਅਦਾ ਕਰਦਾ ਹਾਂ, ਬਹੁਤ ਜਲਦੀ ਅਸੀਂ ਇਹਨਾਂ ਪ੍ਰੌਕਸੀਆਂ ਨੂੰ ਜੋੜਨ ਨਾਲ ਜੁੜੇ ਸੰਚਾਲਨ ਖਰਚਿਆਂ ਨੂੰ ਦੇਖਾਂਗੇ। ਪਰ ਪਹਿਲਾਂ, ਆਓ ਰੁਕੀਏ ਅਤੇ ਆਜ਼ਾਦੀ ਦੇ ਇਸ ਵਿਚਾਰ ਨੂੰ ਵੱਖ-ਵੱਖ ਨਜ਼ਰੀਏ ਤੋਂ ਵੇਖੀਏ ਲੋਕ.

ਸੇਵਾ ਜਾਲ ਕਿਸ ਦੀ ਮਦਦ ਕਰਦਾ ਹੈ?

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

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

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

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

ਪਲੇਟਫਾਰਮਾਂ ਅਤੇ ਸੇਵਾਵਾਂ ਦੇ ਮਾਲਕਾਂ ਵਿਚਕਾਰ ਅਜਿਹੀ ਵੰਡ ਦੇ ਸੰਗਠਨਾਤਮਕ ਮੁੱਲ ਨੂੰ ਜ਼ਿਆਦਾ ਅੰਦਾਜ਼ਾ ਨਹੀਂ ਲਗਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਮੈਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਉਹ ਯੋਗਦਾਨ ਪਾਉਂਦੀ ਹੈ ਮੁੱਖ ਸੇਵਾ ਜਾਲ ਦੇ ਮੁੱਲ ਵਿੱਚ ਯੋਗਦਾਨ.

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

ਸੰਖੇਪ ਵਿੱਚ, ਸੇਵਾ ਜਾਲ, ਨਾ ਕਿ, ਇੱਕ ਤਕਨੀਕੀ ਹੱਲ ਹੈ, ਪਰ ਸਮਾਜਿਕ-ਤਕਨੀਕੀ ਸਮੱਸਿਆਵਾਂ। (ਤੁਹਾਡਾ ਧੰਨਵਾਦ ਸਿੰਡੀ ਸ਼੍ਰੀਧਰਨ ਇਸ ਸ਼ਬਦ ਨੂੰ ਪੇਸ਼ ਕਰਨ ਲਈ।

ਕੀ ਸੇਵਾ ਜਾਲ ਮੇਰੀਆਂ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰੇਗੀ?

ਹਾਂ। ਮੇਰਾ ਮਤਲਬ ਹੈ, ਨਹੀਂ!

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

ਸੇਵਾ ਜਾਲ ਦੁਆਰਾ ਪੇਸ਼ ਕੀਤੇ ਗਏ ਇਹਨਾਂ ਖੇਤਰਾਂ ਵਿੱਚ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦਾ ਇੱਕ ਉਪ ਸਮੂਹ ਸੰਬੰਧਿਤ ਹੈ ਪਲੇਟਫਾਰਮ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ. ਇਸ ਤੋਂ ਮੇਰਾ ਮਤਲਬ ਫੰਕਸ਼ਨ ਹੈ ਜੋ:

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

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

ਸੇਵਾ ਜਾਲ ਸਮਰੱਥਾ ਦੀਆਂ ਉਦਾਹਰਨਾਂ

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

ਸੇਵਾ ਜਾਲ ਇਸ ਸਮੇਂ ਪ੍ਰਸਿੱਧ ਕਿਉਂ ਹੋ ਗਿਆ ਹੈ?

ਤੁਸੀਂ ਸ਼ਾਇਦ ਹੁਣੇ ਹੈਰਾਨ ਹੋ ਰਹੇ ਹੋ: ਠੀਕ ਹੈ, ਜੇਕਰ ਸੇਵਾ ਜਾਲ ਇੰਨਾ ਵਧੀਆ ਹੈ, ਤਾਂ ਅਸੀਂ ਦਸ ਸਾਲ ਪਹਿਲਾਂ ਸਟੈਕ 'ਤੇ ਲੱਖਾਂ ਪ੍ਰੌਕਸੀਜ਼ ਨੂੰ ਤਾਇਨਾਤ ਕਰਨਾ ਕਿਉਂ ਨਹੀਂ ਸ਼ੁਰੂ ਕੀਤਾ?

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

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

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

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

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

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

ਮੋਨਜ਼ੋ ਵਿੱਚ 1500 ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼; ਹਰੇਕ ਲਾਈਨ ਇੱਕ ਨਿਰਧਾਰਤ ਨੈਟਵਰਕ ਨਿਯਮ ਹੈ ਜੋ ਆਵਾਜਾਈ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ

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

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

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

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

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

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

ਸੇਵਾ ਜਾਲ ਬਾਰੇ ਇੰਨੀ ਚਰਚਾ ਕਿਉਂ ਹੈ?

ਰੋਕਥਾਮ: ਇਸ ਭਾਗ ਵਿੱਚ, ਮੈਂ ਹਰ ਤਰ੍ਹਾਂ ਦੀਆਂ ਧਾਰਨਾਵਾਂ, ਅਨੁਮਾਨਾਂ, ਮਨਘੜਤ ਅਤੇ ਅੰਦਰੂਨੀ ਜਾਣਕਾਰੀ ਦਾ ਸਹਾਰਾ ਲੈਂਦਾ ਹਾਂ।

"ਸੇਵਾ ਜਾਲ" ਦੀ ਖੋਜ ਕਰਨ ਨਾਲ ਰੀਸਾਈਕਲ ਕੀਤੀ, ਘੱਟ-ਕੈਲੋਰੀ ਸਮੱਗਰੀ, ਅਜੀਬ ਪ੍ਰੋਜੈਕਟਾਂ, ਅਤੇ ਇੱਕ ਈਕੋ ਚੈਂਬਰ ਦੇ ਯੋਗ ਵਿਗਾੜ ਦਾ ਇੱਕ ਕੈਲੀਡੋਸਕੋਪ ਬਣ ਜਾਵੇਗਾ। ਕਿਸੇ ਵੀ ਟਰੈਡੀ ਨਵੀਂ ਤਕਨਾਲੋਜੀ ਵਿੱਚ ਇਹ ਹੈ, ਪਰ ਸੇਵਾ ਜਾਲ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਸਮੱਸਿਆ ਖਾਸ ਤੌਰ 'ਤੇ ਗੰਭੀਰ ਹੈ. ਕਿਉਂ?

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

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

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

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

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

1. ਗੂਗਲ ਦੁਆਰਾ Istio ਦਾ ਜਨੂੰਨੀ ਪ੍ਰਚਾਰ;
2. ਪ੍ਰੋਜੈਕਟ ਪ੍ਰਤੀ ਉਚਿਤ ਅਸਵੀਕਾਰ, ਆਲੋਚਨਾਤਮਕ ਰਵੱਈਆ;
3. ਕੁਬਰਨੇਟਸ ਦੀ ਤਾਜ਼ਾ ਅਸਮਾਨ ਛੂੰਹਦੀ ਪ੍ਰਸਿੱਧੀ, ਜਿਸਦੀ ਯਾਦ ਅਜੇ ਵੀ ਤਾਜ਼ਾ ਹੈ।

ਇਕੱਠੇ, ਇਹ ਕਾਰਕ ਇੱਕ ਕਿਸਮ ਦੇ ਨਸ਼ੀਲੇ, ਅਨੋਕਸਿਕ ਵਾਤਾਵਰਣ ਵਿੱਚ ਇਕੱਠੇ ਹੋ ਜਾਂਦੇ ਹਨ ਜਿਸ ਵਿੱਚ ਤਰਕਸ਼ੀਲ ਨਿਰਣੇ ਦੀ ਸਮਰੱਥਾ ਘੱਟ ਜਾਂਦੀ ਹੈ, ਸਿਰਫ ਇੱਕ ਅਜੀਬ ਕਿਸਮ ਨੂੰ ਛੱਡ ਕੇ ਟਿਊਲਿਪ ਮਨਿਆ.

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

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

ਉਦੋਂ ਤੱਕ, ਸਾਨੂੰ ਸਾਰਿਆਂ ਨੂੰ ਸਬਰ ਰੱਖਣਾ ਪਵੇਗਾ।

ਕੀ ਸੇਵਾ ਜਾਲ ਮੇਰੇ ਲਈ ਉਪਯੋਗੀ ਹੋਵੇਗੀ, ਇੱਕ ਮਾਮੂਲੀ ਸਾਫਟਵੇਅਰ ਇੰਜੀਨੀਅਰ?

ਹੇਠਾਂ ਦਿੱਤੀ ਪ੍ਰਸ਼ਨਾਵਲੀ ਇਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣ ਵਿੱਚ ਮਦਦ ਕਰੇਗੀ:

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

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

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

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

ਸਿੱਟਾ

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

ਮੈਂ ਚਾਹੁੰਦਾ ਹਾਂ ਕਿ ਤੁਸੀਂ ਲਿੰਕਰਡ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ - ਇਸਨੂੰ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਵਿੱਚ ਸਥਾਪਤ ਕਰਨਾ (ਜਾਂ ਇੱਕ ਲੈਪਟਾਪ 'ਤੇ ਵੀ ਮਿਨੀਕਿਊਬ) ਲਗਭਗ 60 ਸਕਿੰਟ ਲੱਗਦਾ ਹੈਅਤੇ ਤੁਸੀਂ ਖੁਦ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਮੈਂ ਕਿਸ ਬਾਰੇ ਗੱਲ ਕਰ ਰਿਹਾ ਹਾਂ।

ਸਵਾਲ

- ਜੇ ਮੈਂ ਸੇਵਾ ਜਾਲ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦਾ ਹਾਂ, ਤਾਂ ਕੀ ਇਹ ਅਲੋਪ ਹੋ ਜਾਵੇਗਾ?
- ਮੈਨੂੰ ਤੁਹਾਨੂੰ ਨਿਰਾਸ਼ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ: ਸੇਵਾ ਜਾਲ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਸਾਡੇ ਨਾਲ ਹੈ.

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

- ਕੀ ਇਹ ਇੱਕ ਨਵੀਂ ਚਟਣੀ ਦੇ ਨਾਲ ਚੰਗਾ ਪੁਰਾਣਾ ESB/ਮਿਡਲਵੇਅਰ ਨਹੀਂ ਹੈ?
- ਸੇਵਾ ਜਾਲ ਸੰਚਾਲਨ ਤਰਕ ਨਾਲ ਨਜਿੱਠਦਾ ਹੈ, ਅਰਥਵਾਦੀ ਨਹੀਂ। ਇਹ ਮੁੱਖ ਨੁਕਸਾਨ ਸੀ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਸਰਵਿਸ ਬੱਸ (ਈਐਸਬੀ). ਇਸ ਵਿਛੋੜੇ ਨੂੰ ਰੱਖਣ ਨਾਲ ਸੇਵਾ ਜਾਲ ਨੂੰ ਉਸੇ ਕਿਸਮਤ ਤੋਂ ਬਚਣ ਵਿੱਚ ਮਦਦ ਮਿਲਦੀ ਹੈ।

- ਇੱਕ ਸੇਵਾ ਜਾਲ API ਗੇਟਵੇ ਤੋਂ ਕਿਵੇਂ ਵੱਖਰਾ ਹੈ?
ਇਸ ਵਿਸ਼ੇ 'ਤੇ ਇਕ ਮਿਲੀਅਨ ਲੇਖ ਹਨ। ਬਸ ਗੂਗਲ.

ਕੀ ਰਾਜਦੂਤ ਇੱਕ ਸੇਵਾ ਜਾਲ ਹੈ?
- ਨਹੀਂ, ਦੂਤ ਕੋਈ ਸੇਵਾ ਜਾਲ ਨਹੀਂ ਹੈ, ਇਹ ਇੱਕ ਪ੍ਰੌਕਸੀ ਸਰਵਰ ਹੈ। ਇਸਦੀ ਵਰਤੋਂ ਸੇਵਾ ਜਾਲ ਨੂੰ ਸੰਗਠਿਤ ਕਰਨ ਲਈ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ (ਅਤੇ ਹੋਰ ਬਹੁਤ ਕੁਝ - ਇਹ ਇੱਕ ਆਮ ਉਦੇਸ਼ ਪ੍ਰੌਕਸੀ ਹੈ)। ਪਰ ਆਪਣੇ ਆਪ ਵਿੱਚ, ਇਹ ਇੱਕ ਸੇਵਾ ਜਾਲ ਨਹੀਂ ਹੈ.

- ਨੈੱਟਵਰਕ ਸੇਵਾ ਜਾਲ - ਕੀ ਇਹ ਇੱਕ ਸੇਵਾ ਜਾਲ ਹੈ?
- ਨਹੀਂ। ਨਾਮ ਦੇ ਬਾਵਜੂਦ, ਇਹ ਇੱਕ ਸੇਵਾ ਜਾਲ ਨਹੀਂ ਹੈ (ਤੁਸੀਂ ਮਾਰਕੀਟਿੰਗ ਦੇ ਅਜੂਬਿਆਂ ਨੂੰ ਕਿਵੇਂ ਪਸੰਦ ਕਰਦੇ ਹੋ?).

- ਕੀ ਸੇਵਾ ਜਾਲ ਸੁਨੇਹਾ ਕਤਾਰ ਦੇ ਅਧਾਰ ਤੇ ਮੇਰੇ ਪ੍ਰਤੀਕਿਰਿਆਸ਼ੀਲ ਅਸਿੰਕ੍ਰੋਨਸ ਸਿਸਟਮ ਵਿੱਚ ਮਦਦ ਕਰੇਗਾ?
- ਨਹੀਂ, ਸੇਵਾ ਜਾਲ ਤੁਹਾਡੀ ਮਦਦ ਨਹੀਂ ਕਰੇਗਾ।

- ਮੈਨੂੰ ਕਿਹੜਾ ਸੇਵਾ ਜਾਲ ਵਰਤਣਾ ਚਾਹੀਦਾ ਹੈ?
- ਲਿੰਕਰਡ, ਕੋਈ ਦਿਮਾਗੀ ਨਹੀਂ।

- ਲੇਖ ਬੇਕਾਰ! / ਲੇਖਕ - ਸਾਬਣ 'ਤੇ!
- ਕਿਰਪਾ ਕਰਕੇ ਇਸ ਦਾ ਲਿੰਕ ਆਪਣੇ ਸਾਰੇ ਦੋਸਤਾਂ ਨਾਲ ਸਾਂਝਾ ਕਰੋ ਤਾਂ ਜੋ ਉਹ ਇਸ ਬਾਰੇ ਯਕੀਨ ਕਰ ਸਕਣ!

ਪ੍ਰਵਾਨਗੀ

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

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

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

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

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

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

ਸਰੋਤ: www.habr.com