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

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

dotcloud ਇਤਿਹਾਸ

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

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

ਹੋਸਟ ਕੀਤੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਟ੍ਰੈਫਿਕ ਰੂਟਿੰਗ

DotCloud 'ਤੇ ਐਪਲੀਕੇਸ਼ਨ HTTP ਅਤੇ TCP ਅੰਤਮ ਬਿੰਦੂਆਂ ਦਾ ਪਰਦਾਫਾਸ਼ ਕਰ ਸਕਦੀਆਂ ਹਨ।

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

ਗ੍ਰਾਹਕ ਢੁਕਵੇਂ ਡੋਮੇਨਾਂ ਰਾਹੀਂ HTTP ਅੰਤਮ ਬਿੰਦੂਆਂ ਨਾਲ ਜੁੜਦੇ ਹਨ, ਜੋ ਕਿ dotCloud ਲੋਡ ਬੈਲੇਂਸਰਾਂ ਨੂੰ ਡੋਮੇਨ ਨਾਮ ਪੁਆਇੰਟ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ। ਕੁਝ ਖਾਸ ਨਹੀਂ.

TCP ਅੰਤ ਬਿੰਦੂ ਇੱਕ ਪੋਰਟ ਨੰਬਰ ਨਾਲ ਜੁੜਿਆ ਹੋਇਆ ਹੈ, ਜੋ ਫਿਰ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ ਦੁਆਰਾ ਉਸ ਸਟੈਕ ਵਿੱਚ ਸਾਰੇ ਕੰਟੇਨਰਾਂ ਨੂੰ ਪਾਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਗ੍ਰਾਹਕ ਢੁਕਵੇਂ ਹੋਸਟਨਾਮ (ਗੇਟਵੇ-X.dotcloud.com ਵਰਗਾ ਕੋਈ ਚੀਜ਼) ਅਤੇ ਪੋਰਟ ਨੰਬਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ TCP ਅੰਤਮ ਬਿੰਦੂਆਂ ਨਾਲ ਜੁੜ ਸਕਦੇ ਹਨ।

ਇਹ ਹੋਸਟ-ਨਾਂ "ਨੈਟਸ" ਸਰਵਰ ਕਲੱਸਟਰ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ (ਨਾਲ ਸਬੰਧਤ ਨਹੀਂ NATS) ਜੋ ਆਉਣ ਵਾਲੇ TCP ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਸਹੀ ਕੰਟੇਨਰ (ਜਾਂ, ਲੋਡ-ਸੰਤੁਲਿਤ ਸੇਵਾਵਾਂ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਸਹੀ ਕੰਟੇਨਰਾਂ ਵਿੱਚ) ਰੂਟ ਕਰੇਗਾ।

ਜੇ ਤੁਸੀਂ ਕੁਬਰਨੇਟਸ ਤੋਂ ਜਾਣੂ ਹੋ, ਤਾਂ ਇਹ ਸੰਭਵ ਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ ਸੇਵਾਵਾਂ ਦੀ ਯਾਦ ਦਿਵਾਏਗਾ ਨੋਡਪੋਰਟ.

DotCloud ਪਲੇਟਫਾਰਮ 'ਤੇ ਕੋਈ ਸੇਵਾ ਬਰਾਬਰ ਨਹੀਂ ਸੀ ClusterIP: ਸਰਲਤਾ ਲਈ, ਸੇਵਾਵਾਂ ਤੱਕ ਪਹੁੰਚ ਪਲੇਟਫਾਰਮ ਦੇ ਅੰਦਰੋਂ ਅਤੇ ਬਾਹਰੋਂ ਉਸੇ ਤਰ੍ਹਾਂ ਹੋਈ।

ਹਰ ਚੀਜ਼ ਨੂੰ ਕਾਫ਼ੀ ਸਰਲ ਢੰਗ ਨਾਲ ਸੰਗਠਿਤ ਕੀਤਾ ਗਿਆ ਸੀ: HTTP ਅਤੇ TCP ਰੂਟਿੰਗ ਨੈੱਟਵਰਕਾਂ ਦੇ ਮੂਲ ਸਥਾਪਨ ਸ਼ਾਇਦ ਪਾਈਥਨ ਦੀਆਂ ਕੁਝ ਸੌ ਲਾਈਨਾਂ ਸਨ। ਸਧਾਰਨ (ਮੈਂ ਕਹਾਂਗਾ, ਭੋਲੇ) ਐਲਗੋਰਿਦਮ ਜੋ ਪਲੇਟਫਾਰਮ ਦੇ ਵਾਧੇ ਅਤੇ ਵਾਧੂ ਲੋੜਾਂ ਦੇ ਉਭਾਰ ਨਾਲ ਸੁਧਾਰੇ ਗਏ ਹਨ.

ਮੌਜੂਦਾ ਕੋਡ ਦੀ ਵਿਆਪਕ ਰੀਫੈਕਟਰਿੰਗ ਦੀ ਲੋੜ ਨਹੀਂ ਸੀ। ਵਿਸ਼ੇਸ਼ ਰੂਪ ਤੋਂ, 12 ਫੈਕਟਰ ਐਪਸ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ ਦੁਆਰਾ ਪ੍ਰਾਪਤ ਕੀਤੇ ਪਤੇ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦਾ ਹੈ।

ਇਹ ਆਧੁਨਿਕ ਸੇਵਾ ਜਾਲ ਤੋਂ ਕਿਵੇਂ ਵੱਖਰਾ ਹੈ?

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

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

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

ਅਜਿਹੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨਾਲ ਨਜਿੱਠਣ ਲਈ ਆਧੁਨਿਕ ਸੇਵਾ ਜਾਲ ਬਿਹਤਰ ਹਨ। ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਉਹ ਜਾਂਚ ਕਰਦੇ ਹਨ ਕਿ ਕੁਨੈਕਸ਼ਨ ਰੂਟ ਕੀਤੇ ਗਏ ਹਨ ਸਰੋਤ ਵਿੱਚ. ਲਾਜ਼ੀਕਲ ਪ੍ਰਵਾਹ ਇੱਕੋ ਜਿਹਾ ਹੈ: клиент → меш → сервис, ਪਰ ਹੁਣ ਜਾਲ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ ਨਾ ਕਿ ਰਿਮੋਟ ਨੋਡਾਂ 'ਤੇ, ਇਸਲਈ ਕੁਨੈਕਸ਼ਨ клиент → меш ਸਥਾਨਕ ਅਤੇ ਬਹੁਤ ਤੇਜ਼ ਹੈ (ਮਿਲੀਸਕਿੰਟ ਦੀ ਬਜਾਏ ਮਾਈਕ੍ਰੋਸਕਿੰਟ)।

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

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

ਪਲੇਟਫਾਰਮ ਸੇਵਾਵਾਂ ਲਈ ਟ੍ਰੈਫਿਕ ਰੂਟਿੰਗ

ਠੀਕ ਹੈ, ਅਸੀਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੇ ਵਿਚਕਾਰ ਟ੍ਰੈਫਿਕ ਬਾਰੇ ਚਰਚਾ ਕੀਤੀ ਹੈ, ਪਰ dotCloud ਪਲੇਟਫਾਰਮ ਬਾਰੇ ਕੀ?

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

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

ਇਹ ਨੀਵੇਂ-ਪੱਧਰੀ, ਜ਼ਰੂਰੀ ਸੇਵਾਵਾਂ ਨੂੰ ਕੁਝ ਮੁੱਖ ਨੋਡਾਂ 'ਤੇ ਸਿੱਧੇ ਕੰਟੇਨਰ ਚਲਾ ਕੇ ਤਾਇਨਾਤ ਕੀਤਾ ਗਿਆ ਸੀ। ਉਸੇ ਸਮੇਂ, ਸਟੈਂਡਰਡ ਪਲੇਟਫਾਰਮ ਸੇਵਾਵਾਂ ਸ਼ਾਮਲ ਨਹੀਂ ਸਨ: ਲਿੰਕਰ, ਸ਼ਡਿਊਲਰ ਅਤੇ ਰਨਰ। ਜੇਕਰ ਤੁਸੀਂ ਆਧੁਨਿਕ ਕੰਟੇਨਰ ਪਲੇਟਫਾਰਮਾਂ ਨਾਲ ਤੁਲਨਾ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇਹ ਇੱਕ ਕੰਟਰੋਲ ਪਲੇਨ ਲਾਂਚ ਕਰਨ ਵਰਗਾ ਹੈ docker run ਕੁਬਰਨੇਟਸ ਨੂੰ ਕੰਮ ਸੌਂਪਣ ਦੀ ਬਜਾਏ ਸਿੱਧੇ ਨੋਡਾਂ 'ਤੇ। ਇਹ ਸੰਕਲਪ ਵਿੱਚ ਪਰੈਟੀ ਸਮਾਨ ਹੈ ਸਥਿਰ ਮੋਡੀਊਲ (ਪੋਡ), ਜੋ ਵਰਤਦਾ ਹੈ kubeadm ਜ bootkube ਇੱਕ ਸਟੈਂਡਅਲੋਨ ਕਲੱਸਟਰ ਨੂੰ ਬੂਟ ਕਰਨ ਵੇਲੇ।

ਇਹਨਾਂ ਸੇਵਾਵਾਂ ਨੂੰ ਇੱਕ ਸਧਾਰਨ ਅਤੇ ਕੱਚੇ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰਗਟ ਕੀਤਾ ਗਿਆ ਸੀ: ਇੱਕ YAML ਫਾਈਲ ਵਿੱਚ ਉਹਨਾਂ ਦੇ ਨਾਮ ਅਤੇ ਪਤੇ ਸੂਚੀਬੱਧ ਕੀਤੇ ਗਏ ਸਨ; ਅਤੇ ਹਰੇਕ ਕਲਾਇੰਟ ਨੂੰ ਤੈਨਾਤੀ ਲਈ ਇਸ YAML ਫਾਈਲ ਦੀ ਇੱਕ ਕਾਪੀ ਲੈਣੀ ਪੈਂਦੀ ਸੀ।

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

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

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

ਇਹ ਬਹੁਤ ਸਮਾਨ ਹੈ ਸਮਾਰਟਸਟੈਕ Airbnb ਤੋਂ, ਪਰ ਮਹੱਤਵਪੂਰਨ ਅੰਤਰ ਇਹ ਹੈ ਕਿ SmartStack ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਉਤਪਾਦਨ ਲਈ ਤੈਨਾਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਜਦੋਂ ਕਿ dotCloud ਦੇ ਅੰਦਰੂਨੀ ਰੂਟਿੰਗ ਸਿਸਟਮ ਨੂੰ ਬਾਕਸ ਕੀਤਾ ਗਿਆ ਸੀ ਜਦੋਂ dotCloud Docker ਵਿੱਚ ਬਦਲ ਗਿਆ ਸੀ।

ਮੈਂ ਨਿੱਜੀ ਤੌਰ 'ਤੇ ਸਮਾਰਟਸਟੈਕ ਨੂੰ ਇਸਟੀਓ, ਲਿੰਕਰਡ ਅਤੇ ਕੌਂਸਲ ਕਨੈਕਟ ਵਰਗੇ ਸਿਸਟਮਾਂ ਦੇ ਪੂਰਵਜਾਂ ਵਿੱਚੋਂ ਇੱਕ ਮੰਨਦਾ ਹਾਂ ਕਿਉਂਕਿ ਉਹ ਸਾਰੇ ਇੱਕੋ ਪੈਟਰਨ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਨ:

• ਹਰੇਕ ਨੋਡ 'ਤੇ ਇੱਕ ਪ੍ਰੌਕਸੀ ਚਲਾਓ।
• ਕਲਾਇੰਟ ਪ੍ਰੌਕਸੀ ਨਾਲ ਜੁੜਦੇ ਹਨ।
• ਜਦੋਂ ਬੈਕਐਂਡ ਬਦਲਦਾ ਹੈ ਤਾਂ ਕੰਟਰੋਲ ਪਲੇਨ ਪ੍ਰੌਕਸੀ ਸੰਰਚਨਾ ਨੂੰ ਅੱਪਡੇਟ ਕਰਦਾ ਹੈ।
• … ਲਾਭ!

ਆਧੁਨਿਕ ਸੇਵਾ ਜਾਲ ਲਾਗੂ ਕਰਨਾ

ਜੇਕਰ ਅੱਜ ਸਾਨੂੰ ਇੱਕ ਸਮਾਨ ਗਰਿੱਡ ਲਾਗੂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਅਸੀਂ ਸਮਾਨ ਸਿਧਾਂਤਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹਾਂ। ਉਦਾਹਰਨ ਲਈ, ਸਪੇਸ ਵਿੱਚ ਪਤਿਆਂ ਲਈ ਸੇਵਾ ਦੇ ਨਾਮ ਮੈਪ ਕਰਕੇ ਇੱਕ ਅੰਦਰੂਨੀ DNS ਜ਼ੋਨ ਸੈਟ ਅਪ ਕਰੋ 127.0.0.0/8. ਫਿਰ ਹਰੇਕ ਕਲੱਸਟਰ ਨੋਡ 'ਤੇ HAProxy ਚਲਾਓ, ਹਰੇਕ ਸੇਵਾ ਪਤੇ 'ਤੇ ਕਨੈਕਸ਼ਨ ਸਵੀਕਾਰ ਕਰਦੇ ਹੋਏ (ਉਸ ਸਬਨੈੱਟ 'ਤੇ 127.0.0.0/8) ਅਤੇ ਲੋਡ ਨੂੰ ਢੁਕਵੇਂ ਬੈਕਐਂਡਾਂ 'ਤੇ ਰੀਡਾਇਰੈਕਟ/ਸੰਤੁਲਨ ਕਰਨਾ। HAProxy ਸੰਰਚਨਾ ਦਾ ਪ੍ਰਬੰਧਨ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ confd, ਤੁਹਾਨੂੰ etcd ਜਾਂ Consul ਵਿੱਚ ਬੈਕਐਂਡ ਜਾਣਕਾਰੀ ਸਟੋਰ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਅਤੇ ਲੋੜ ਪੈਣ 'ਤੇ ਆਪਣੇ ਆਪ ਅੱਪਡੇਟ ਕੀਤੀ ਸੰਰਚਨਾ ਨੂੰ HAProxy ਵਿੱਚ ਧੱਕਦਾ ਹੈ।

ਇਸਤੀਓ ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ! ਪਰ ਕੁਝ ਅੰਤਰਾਂ ਦੇ ਨਾਲ:

• ਵਰਤਦਾ ਹੈ ਦੂਤ ਪ੍ਰੌਕਸੀ HAProxy ਦੀ ਬਜਾਏ.
• etcd ਜਾਂ Consul ਦੀ ਬਜਾਏ Kubernetes API ਰਾਹੀਂ ਬੈਕਐਂਡ ਕੌਂਫਿਗਰੇਸ਼ਨ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਦਾ ਹੈ।
• ਸੇਵਾਵਾਂ ਨੂੰ 127.0.0.0/8 ਦੀ ਬਜਾਏ ਅੰਦਰੂਨੀ ਸਬਨੈੱਟ (Kubernetes ClusterIP ਐਡਰੈੱਸ) 'ਤੇ ਪਤੇ ਨਿਰਧਾਰਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।
• ਕਲਾਇੰਟ ਅਤੇ ਸਰਵਰਾਂ ਵਿਚਕਾਰ ਆਪਸੀ TLS ਪ੍ਰਮਾਣੀਕਰਨ ਜੋੜਨ ਲਈ ਇੱਕ ਵਾਧੂ ਭਾਗ (ਸੀਟਾਡੇਲ) ਹੈ।
• ਨਵੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ ਜਿਵੇਂ ਕਿ ਸਰਕਟ ਤੋੜਨਾ, ਵੰਡਿਆ ਟਰੇਸਿੰਗ, ਕੈਨਰੀ ਤੈਨਾਤੀ, ਆਦਿ।

ਆਓ ਕੁਝ ਅੰਤਰਾਂ 'ਤੇ ਇੱਕ ਝਾਤ ਮਾਰੀਏ।

ਦੂਤ ਪ੍ਰੌਕਸੀ

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

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

ਪਰ ਰਾਜਦੂਤ ਵਜੋਂ ਵੀ ਕੰਮ ਕਰਨ ਦੇ ਯੋਗ ਹੈ ਡਾਟਾ ਪਲੇਨ (ਡਾਟਾ ਜਹਾਜ਼) ਸੇਵਾ ਜਾਲ ਲਈ. ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਹੁਣ ਇਸ ਸੇਵਾ ਜਾਲ ਲਈ, ਦੂਤ ਨੂੰ ਸੰਰਚਿਤ ਕੀਤਾ ਗਿਆ ਹੈ ਕੰਟਰੋਲ ਜਹਾਜ਼ (ਨਿਯੰਤਰਣ ਜਹਾਜ਼).

ਕੰਟਰੋਲ ਜਹਾਜ਼

ਕੰਟਰੋਲ ਪਲੇਨ ਵਿੱਚ, ਇਸਟੀਓ ਕੁਬਰਨੇਟਸ API 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਇਹ confd ਦੀ ਵਰਤੋਂ ਕਰਨ ਤੋਂ ਬਹੁਤ ਵੱਖਰਾ ਨਹੀਂ ਹੈ, ਜੋ ਕਿ ਡਾਟਾਸਟੋਰ ਵਿੱਚ ਕੁੰਜੀਆਂ ਦਾ ਸੈੱਟ ਦੇਖਣ ਲਈ etcd ਜਾਂ Consul 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। Istio Kubernetes API ਦੁਆਰਾ Kubernetes ਸਰੋਤਾਂ ਦੇ ਇੱਕ ਸਮੂਹ ਦੁਆਰਾ ਵੇਖਦਾ ਹੈ।

ਇਸ ਦੇ ਵਿਚਕਾਰ ਅਤੇ ਫਿਰ: ਮੈਨੂੰ ਨਿੱਜੀ ਤੌਰ 'ਤੇ ਇਹ ਲਾਭਦਾਇਕ ਲੱਗਿਆ Kubernetes API ਦਾ ਵੇਰਵਾਜੋ ਪੜ੍ਹਦਾ ਹੈ:

ਕੁਬਰਨੇਟਸ API ਸਰਵਰ ਇੱਕ "ਮੂਰਖ ਸਰਵਰ" ਹੈ ਜੋ ਸਟੋਰੇਜ, ਸੰਸਕਰਣ, ਪ੍ਰਮਾਣਿਕਤਾ, ਅੱਪਡੇਟਿੰਗ, ਅਤੇ API ਸਰੋਤ ਅਰਥ ਵਿਗਿਆਨ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ।

Istio ਕੁਬਰਨੇਟਸ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ; ਅਤੇ ਜੇਕਰ ਤੁਸੀਂ ਇਸਨੂੰ Kubernetes ਤੋਂ ਬਾਹਰ ਵਰਤਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ Kubernetes API ਸਰਵਰ (ਅਤੇ etcd ਸਹਾਇਕ ਸੇਵਾ) ਦੀ ਇੱਕ ਉਦਾਹਰਣ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਸੇਵਾ ਪਤੇ

Istio ClusterIP ਪਤਿਆਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਜੋ ਕੁਬਰਨੇਟਸ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ, ਇਸਲਈ ਇਸਟੀਓ ਸੇਵਾਵਾਂ ਨੂੰ ਅੰਦਰੂਨੀ ਪਤਾ ਮਿਲਦਾ ਹੈ (ਸੀਮਾ ਵਿੱਚ ਨਹੀਂ 127.0.0.0/8).

Istio ਤੋਂ ਬਿਨਾਂ Kubernetes ਕਲੱਸਟਰ ਵਿੱਚ ਇੱਕ ਖਾਸ ਸੇਵਾ ਲਈ ਇੱਕ ClusterIP ਪਤੇ ਤੇ ਆਵਾਜਾਈ ਨੂੰ kube-proxy ਦੁਆਰਾ ਰੋਕਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਪ੍ਰੌਕਸੀ ਦੇ ਪਿਛਲੇ ਸਿਰੇ ਤੇ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਤਕਨੀਕੀ ਵੇਰਵਿਆਂ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹੋ, ਤਾਂ kube-proxy iptables ਨਿਯਮ (ਜਾਂ IPVS ਲੋਡ ਬੈਲੈਂਸਰ, ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਇਹ ਕਿਵੇਂ ਕੌਂਫਿਗਰ ਕੀਤਾ ਗਿਆ ਹੈ) ਨੂੰ ਕਲੱਸਟਰਆਈਪੀ ਪਤੇ 'ਤੇ ਜਾਣ ਵਾਲੇ ਕਨੈਕਸ਼ਨਾਂ ਦੇ ਮੰਜ਼ਿਲ IP ਪਤਿਆਂ ਨੂੰ ਮੁੜ ਲਿਖਣ ਲਈ ਸੈੱਟ ਕਰਦਾ ਹੈ।

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

ਜਦੋਂ Kubernetes DNS ਨਾਲ ਏਕੀਕ੍ਰਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸਾਡਾ ਕੋਡ ਸੇਵਾ ਦੇ ਨਾਮ ਨਾਲ ਜੁੜ ਸਕਦਾ ਹੈ, ਅਤੇ ਹਰ ਚੀਜ਼ "ਬਸ ਕੰਮ ਕਰਦੀ ਹੈ"। ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿਚ, ਸਾਡਾ ਕੋਡ ਸਵਾਲਾਂ ਨੂੰ ਜਾਰੀ ਕਰਦਾ ਹੈ ਜਿਵੇਂ ਕਿ http://api/v1/users/4242ਫਿਰ api ਲਈ ਬੇਨਤੀ ਨੂੰ ਹੱਲ ਕਰੋ 10.97.105.48, iptables ਨਿਯਮ 10.97.105.48 ਤੋਂ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਰੋਕਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਸਥਾਨਕ ਦੂਤ ਪ੍ਰੌਕਸੀ ਵੱਲ ਰੀਡਾਇਰੈਕਟ ਕਰਦਾ ਹੈ, ਜੋ ਕਿ ਬੇਨਤੀ ਨੂੰ ਅਸਲ API ਬੈਕਐਂਡ ਨੂੰ ਅੱਗੇ ਭੇਜ ਦੇਵੇਗਾ। ਵਾਹ!

ਵਾਧੂ ਫਰਿਲਸ

Istio mTLS (ਮਿਊਚਲ TLS) ਰਾਹੀਂ ਐਂਡ-ਟੂ-ਐਂਡ ਐਨਕ੍ਰਿਪਸ਼ਨ ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਵੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਕੰਪੋਨੈਂਟ ਕਹਿੰਦੇ ਹਨ ਕਿਲੇ.

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

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

ਵਿਕਸਤ ਕਰੋ ਜਾਂ ਖਰੀਦੋ

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

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

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

ਕੀ ਚੁਣਨਾ ਹੈ: Istio, Linkerd ਜਾਂ Consul Connect?

ਹੁਣ ਤੱਕ ਅਸੀਂ ਸਿਰਫ਼ Istio ਬਾਰੇ ਹੀ ਗੱਲ ਕੀਤੀ ਹੈ, ਪਰ ਇਹ ਸਿਰਫ਼ ਸੇਵਾ ਜਾਲ ਨਹੀਂ ਹੈ। ਪ੍ਰਸਿੱਧ ਵਿਕਲਪ ਹੈ ਲਿੰਕਰਡ, ਪਰ ਹੋਰ ਵੀ ਹੈ ਕੌਂਸਲ ਕਨੈਕਟ.

ਕੀ ਚੁਣਨਾ ਹੈ?

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

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

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

ਸਰੋਤ: www.habr.com