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

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

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

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

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

ਸੇਵਾ ਜਾਲ ਪਹੁੰਚ

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

ਹੱਲ

ਇਸ ਪਹੁੰਚ ਦੇ ਪਹਿਲਾਂ ਹੀ ਕਈ ਅਮਲ ਹਨ: ਆਈਸਟੀਓ и linkerd2. ਉਹ ਬਾਕਸ ਤੋਂ ਬਾਹਰ ਬਹੁਤ ਸਾਰੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ. ਪਰ ਉਸੇ ਸਮੇਂ, ਸਰੋਤਾਂ 'ਤੇ ਇੱਕ ਵੱਡਾ ਓਵਰਹੈੱਡ ਆਉਂਦਾ ਹੈ. ਇਸ ਤੋਂ ਇਲਾਵਾ, ਜਿੰਨਾ ਵੱਡਾ ਕਲੱਸਟਰ ਜਿਸ ਵਿੱਚ ਅਜਿਹੀ ਪ੍ਰਣਾਲੀ ਕੰਮ ਕਰਦੀ ਹੈ, ਨਵੇਂ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨੂੰ ਕਾਇਮ ਰੱਖਣ ਲਈ ਵਧੇਰੇ ਸਰੋਤਾਂ ਦੀ ਲੋੜ ਹੋਵੇਗੀ। ਅਵੀਟੋ ਵਿਖੇ, ਅਸੀਂ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰਾਂ ਦਾ ਸੰਚਾਲਨ ਕਰਦੇ ਹਾਂ ਜਿਸ ਵਿੱਚ ਹਜ਼ਾਰਾਂ ਸੇਵਾ ਉਦਾਹਰਨਾਂ ਹਨ (ਅਤੇ ਉਹਨਾਂ ਦੀ ਗਿਣਤੀ ਤੇਜ਼ੀ ਨਾਲ ਵਧਦੀ ਜਾ ਰਹੀ ਹੈ)। ਇਸਦੇ ਮੌਜੂਦਾ ਲਾਗੂਕਰਨ ਵਿੱਚ, Istio ਪ੍ਰਤੀ ਸੇਵਾ ਮੌਕੇ ~ 300Mb RAM ਦੀ ਖਪਤ ਕਰਦਾ ਹੈ। ਸੰਭਾਵਨਾਵਾਂ ਦੀ ਵੱਡੀ ਗਿਣਤੀ ਦੇ ਕਾਰਨ, ਪਾਰਦਰਸ਼ੀ ਸੰਤੁਲਨ ਸੇਵਾਵਾਂ ਦੇ ਸਮੁੱਚੇ ਜਵਾਬ ਸਮੇਂ (10ms ਤੱਕ) ਨੂੰ ਵੀ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ।

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

ਨਤੀਜੇ ਵਜੋਂ, ਅਸੀਂ ਆਪਣੇ ਫੈਸਲੇ 'ਤੇ ਆਏ:  ਨੇਤਰਮੇਸ਼.

ਨੇਤਰਮੇਸ਼

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

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

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

ਉਤਪਾਦਕਤਾ

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

ਆਓ ਦੇਖੀਏ ਕਿ ਸਾਨੂੰ ਕੀ ਨਤੀਜੇ ਮਿਲੇ ਹਨ।

ਰੈਮ

ਨੇਤਰਮੇਸ਼ ਬਿਨਾਂ ਟ੍ਰੈਫਿਕ ਦੇ ~ 10Mb ਅਤੇ ਪ੍ਰਤੀ ਉਦਾਹਰਨ 50 RPS ਤੱਕ ਦੇ ਲੋਡ ਦੇ ਨਾਲ ਵੱਧ ਤੋਂ ਵੱਧ 10000Mb ਦੀ ਖਪਤ ਕਰਦਾ ਹੈ।

Istio ਦੂਤ ਪ੍ਰੌਕਸੀ ਸਾਡੇ ਕਲੱਸਟਰਾਂ ਵਿੱਚ ਹਜ਼ਾਰਾਂ ਉਦਾਹਰਨਾਂ ਦੇ ਨਾਲ ਹਮੇਸ਼ਾ ~300Mb ਦੀ ਖਪਤ ਕਰਦੀ ਹੈ। ਇਹ ਇਸਨੂੰ ਪੂਰੇ ਕਲੱਸਟਰ ਤੱਕ ਸਕੇਲ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦਾ ਹੈ।

ਨੇਤਰਮੇਸ਼ ਨਾਲ ਸਾਨੂੰ ਮੈਮੋਰੀ ਦੀ ਖਪਤ ਵਿੱਚ ~ 10x ਦੀ ਕਮੀ ਮਿਲੀ ਹੈ।

CPU

CPU ਵਰਤੋਂ ਲੋਡ ਅਧੀਨ ਮੁਕਾਬਲਤਨ ਬਰਾਬਰ ਹੈ। ਇਹ ਸਾਈਡਕਾਰ ਨੂੰ ਪ੍ਰਤੀ ਯੂਨਿਟ ਸਮੇਂ ਦੀਆਂ ਬੇਨਤੀਆਂ ਦੀ ਗਿਣਤੀ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਸਿਖਰ 'ਤੇ ਪ੍ਰਤੀ ਸਕਿੰਟ 3000 ਬੇਨਤੀਆਂ ਦੇ ਮੁੱਲ:

ਇੱਕ ਹੋਰ ਮਹੱਤਵਪੂਰਨ ਨੁਕਤਾ ਹੈ: ਨੇਤਰਮੇਸ਼ - ਇੱਕ ਨਿਯੰਤਰਣ ਪਲੇਨ ਤੋਂ ਬਿਨਾਂ ਅਤੇ ਲੋਡ ਤੋਂ ਬਿਨਾਂ ਇੱਕ ਹੱਲ CPU ਸਮੇਂ ਦੀ ਖਪਤ ਨਹੀਂ ਕਰਦਾ. Istio ਦੇ ਨਾਲ, ਸਾਈਡਕਾਰ ਹਮੇਸ਼ਾ ਸਰਵਿਸ ਐਂਡਪੁਆਇੰਟਸ ਨੂੰ ਅਪਡੇਟ ਕਰਦੇ ਹਨ। ਨਤੀਜੇ ਵਜੋਂ, ਅਸੀਂ ਇਸ ਤਸਵੀਰ ਨੂੰ ਲੋਡ ਕੀਤੇ ਬਿਨਾਂ ਦੇਖ ਸਕਦੇ ਹਾਂ:

ਅਸੀਂ ਸੇਵਾਵਾਂ ਵਿਚਕਾਰ ਸੰਚਾਰ ਲਈ HTTP/1 ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ। ਦੂਤ ਦੁਆਰਾ ਪ੍ਰੌਕਸੀ ਕਰਨ ਵੇਲੇ Istio ਲਈ ਜਵਾਬ ਸਮੇਂ ਵਿੱਚ ਵਾਧਾ 5-10ms ਤੱਕ ਸੀ, ਜੋ ਕਿ ਉਹਨਾਂ ਸੇਵਾਵਾਂ ਲਈ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੈ ਜੋ ਇੱਕ ਮਿਲੀਸਕਿੰਟ ਵਿੱਚ ਜਵਾਬ ਦੇਣ ਲਈ ਤਿਆਰ ਹਨ। ਨੇਤਰਮੇਸ਼ ਦੇ ਨਾਲ ਇਸ ਵਾਰ 0.5-2ms ਤੱਕ ਘੱਟ ਗਿਆ ਹੈ.

ਸਕੇਲੇਬਿਲਟੀ

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

ਸੇਵਾ ਖੋਜ

ਨੇਤਰਮੇਸ਼ ਸੇਵਾ ਖੋਜ ਲਈ ਕੋਈ ਵਾਧੂ ਵਿਧੀ ਨਹੀਂ ਜੋੜਦਾ ਹੈ। ਸਾਰੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਨੇਟਰਾ ਸਾਈਡਕਾਰ ਦੁਆਰਾ ਪਾਰਦਰਸ਼ੀ ਢੰਗ ਨਾਲ ਪ੍ਰੌਕਸੀ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਨੇਟਰਾਮੇਸ਼ HTTP/1 ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰੋਟੋਕੋਲ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਇਸਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਲਈ, ਪੋਰਟਾਂ ਦੀ ਇੱਕ ਸੰਰਚਨਾਯੋਗ ਸੂਚੀ ਵਰਤੀ ਜਾਂਦੀ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ, ਸਿਸਟਮ ਦੀਆਂ ਕਈ ਪੋਰਟਾਂ ਹੁੰਦੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਰਾਹੀਂ HTTP ਸੰਚਾਰ ਹੁੰਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ ਸੇਵਾਵਾਂ ਅਤੇ ਬਾਹਰੀ ਬੇਨਤੀਆਂ ਵਿਚਕਾਰ ਆਪਸੀ ਤਾਲਮੇਲ ਲਈ 80, 8890, 8080 ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸੈੱਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ NETRA_HTTP_PORTS.

ਜੇਕਰ ਤੁਸੀਂ ਕੁਬਰਨੇਟਸ ਨੂੰ ਆਰਕੈਸਟਰੇਟਰ ਦੇ ਤੌਰ 'ਤੇ ਵਰਤਦੇ ਹੋ ਅਤੇ ਸੇਵਾਵਾਂ ਦੇ ਵਿਚਕਾਰ ਅੰਤਰ-ਕਲੱਸਟਰ ਸੰਚਾਰ ਲਈ ਇਸਦੀ ਸੇਵਾ ਇਕਾਈ ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ, ਤਾਂ ਵਿਧੀ ਬਿਲਕੁਲ ਉਹੀ ਰਹਿੰਦੀ ਹੈ। ਪਹਿਲਾਂ, ਮਾਈਕ੍ਰੋਸਰਵਿਸ kube-dns ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਸੇਵਾ IP ਪਤਾ ਪ੍ਰਾਪਤ ਕਰਦੀ ਹੈ ਅਤੇ ਇਸ ਨਾਲ ਇੱਕ ਨਵਾਂ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹਦੀ ਹੈ। ਇਹ ਕਨੈਕਸ਼ਨ ਪਹਿਲਾਂ ਸਥਾਨਕ ਨੇਟਰਾ-ਸਾਈਡਕਾਰ ਨਾਲ ਸਥਾਪਿਤ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਸਾਰੇ TCP ਪੈਕੇਟ ਸ਼ੁਰੂ ਵਿੱਚ ਨੇਟਰਾ 'ਤੇ ਪਹੁੰਚਦੇ ਹਨ। ਅੱਗੇ, ਨੇਟਰਾ-ਸਾਈਡਕਾਰ ਅਸਲ ਮੰਜ਼ਿਲ ਨਾਲ ਇੱਕ ਸਬੰਧ ਸਥਾਪਤ ਕਰਦਾ ਹੈ। ਨੋਡ 'ਤੇ ਪੌਡ ਆਈਪੀ 'ਤੇ NAT ਬਿਲਕੁਲ ਉਸੇ ਤਰ੍ਹਾਂ ਰਹਿੰਦਾ ਹੈ ਜਿਵੇਂ ਨੇਟਰਾ ਤੋਂ ਬਿਨਾਂ।

ਵੰਡਿਆ ਟਰੇਸਿੰਗ ਅਤੇ ਸੰਦਰਭ ਫਾਰਵਰਡਿੰਗ

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

ਪਰ ਇੱਕ ਸਮੱਸਿਆ ਹੈ. ਜਦੋਂ ਤੱਕ ਸੇਵਾਵਾਂ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਉਬੇਰ ਸਿਰਲੇਖ ਤਿਆਰ ਨਹੀਂ ਕਰਦੀਆਂ ਅਤੇ ਭੇਜਦੀਆਂ ਹਨ, ਅਸੀਂ ਸਿਸਟਮ ਵਿੱਚ ਕਨੈਕਟ ਕੀਤੇ ਟਰੇਸਿੰਗ ਸਪੈਨ ਨਹੀਂ ਦੇਖਾਂਗੇ। ਅਤੇ ਇਹ ਉਹ ਹੈ ਜੋ ਸਾਨੂੰ ਸਮੱਸਿਆਵਾਂ ਦੇ ਕਾਰਨ ਨੂੰ ਜਲਦੀ ਲੱਭਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ. ਇੱਥੇ ਫਿਰ ਨੇਤਰਮੇਸ਼ ਕੋਲ ਇੱਕ ਹੱਲ ਹੈ. ਪ੍ਰੌਕਸੀਆਂ HTTP ਸਿਰਲੇਖਾਂ ਨੂੰ ਪੜ੍ਹਦੀਆਂ ਹਨ ਅਤੇ, ਜੇਕਰ ਉਹਨਾਂ ਵਿੱਚ uber ਟਰੇਸ ਆਈਡੀ ਨਹੀਂ ਹੈ, ਤਾਂ ਇੱਕ ਜਨਰੇਟ ਕਰੋ। ਨੇਤਰਮੇਸ਼ ਇੱਕ ਸਾਈਡਕਾਰ ਵਿੱਚ ਇਨਕਮਿੰਗ ਅਤੇ ਆਊਟਗੋਇੰਗ ਬੇਨਤੀਆਂ ਬਾਰੇ ਜਾਣਕਾਰੀ ਵੀ ਸਟੋਰ ਕਰਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਲੋੜੀਂਦੇ ਆਊਟਗੋਇੰਗ ਬੇਨਤੀ ਸਿਰਲੇਖਾਂ ਨਾਲ ਭਰਪੂਰ ਕਰਕੇ ਉਹਨਾਂ ਨਾਲ ਮੇਲ ਕਰਦਾ ਹੈ। ਸੇਵਾਵਾਂ ਵਿੱਚ ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਸਿਰਲੇਖ ਭੇਜਣ ਦੀ ਲੋੜ ਹੈ X-Request-Id, ਜਿਸ ਨੂੰ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸੰਰਚਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ NETRA_HTTP_REQUEST_ID_HEADER_NAME. ਨੇਤਰਮੇਸ਼ ਵਿੱਚ ਸੰਦਰਭ ਦੇ ਆਕਾਰ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਨ ਲਈ, ਤੁਸੀਂ ਹੇਠਾਂ ਦਿੱਤੇ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ ਸੈਟ ਕਰ ਸਕਦੇ ਹੋ: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (ਉਹ ਸਮਾਂ ਜਿਸ ਲਈ ਸੰਦਰਭ ਸਟੋਰ ਕੀਤਾ ਜਾਵੇਗਾ) ਅਤੇ NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (ਪ੍ਰਸੰਗ ਸਾਫ਼ ਕਰਨ ਦੀ ਬਾਰੰਬਾਰਤਾ)।

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

ਬੇਨਤੀ ਸਰੋਤ ਦਾ ਪਤਾ ਲਗਾਉਣਾ

ਇਹ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ ਕਿ ਬੇਨਤੀ ਕਿੱਥੋਂ ਆਈ ਹੈ, ਤੁਸੀਂ ਸਰੋਤ ਦੇ ਨਾਲ ਆਪਣੇ ਆਪ ਸਿਰਲੇਖ ਜੋੜਨ ਦੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ। ਇੱਕ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ ਦੀ ਵਰਤੋਂ ਕਰਨਾ NETRA_HTTP_X_SOURCE_HEADER_NAME ਤੁਸੀਂ ਇੱਕ ਸਿਰਲੇਖ ਦਾ ਨਾਮ ਨਿਰਧਾਰਤ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਆਟੋਮੈਟਿਕਲੀ ਸਥਾਪਿਤ ਹੋ ਜਾਵੇਗਾ। ਵਰਤ ਕੇ NETRA_HTTP_X_SOURCE_VALUE ਤੁਸੀਂ ਉਹ ਮੁੱਲ ਸੈੱਟ ਕਰ ਸਕਦੇ ਹੋ ਜਿਸ 'ਤੇ X-ਸਰੋਤ ਸਿਰਲੇਖ ਨੂੰ ਸਾਰੀਆਂ ਆਊਟਗੋਇੰਗ ਬੇਨਤੀਆਂ ਲਈ ਸੈੱਟ ਕੀਤਾ ਜਾਵੇਗਾ।

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

ਟ੍ਰੈਫਿਕ ਰੂਟਿੰਗ ਅਤੇ ਨੇਤਰਮੇਸ਼ ਅੰਦਰੂਨੀ

ਨੇਤਰਮੇਸ਼ ਵਿੱਚ ਦੋ ਮੁੱਖ ਭਾਗ ਹੁੰਦੇ ਹਨ। ਪਹਿਲਾ, netra-init, ਟ੍ਰੈਫਿਕ ਨੂੰ ਰੋਕਣ ਲਈ ਨੈੱਟਵਰਕ ਨਿਯਮ ਸੈੱਟ ਕਰਦਾ ਹੈ। ਉਹ ਵਰਤਦਾ ਹੈ iptables ਰੀਡਾਇਰੈਕਟ ਨਿਯਮ ਸਾਈਡਕਾਰ 'ਤੇ ਆਵਾਜਾਈ ਦੇ ਸਾਰੇ ਜਾਂ ਹਿੱਸੇ ਨੂੰ ਰੋਕਣ ਲਈ, ਜੋ ਕਿ ਨੇਤਰਮੇਸ਼ ਦਾ ਦੂਜਾ ਮੁੱਖ ਹਿੱਸਾ ਹੈ। ਤੁਸੀਂ ਕੌਂਫਿਗਰ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਇਨਕਮਿੰਗ ਅਤੇ ਆਊਟਗੋਇੰਗ TCP ਸੈਸ਼ਨਾਂ ਲਈ ਕਿਹੜੀਆਂ ਪੋਰਟਾਂ ਨੂੰ ਰੋਕਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.

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

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

ਇੱਕ ਨਿਰਭਰਤਾ ਗ੍ਰਾਫ਼ ਬਣਾਉਣਾ

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

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

ਨੇਤਰਮੇਸ਼ ਦੀ ਵਰਤੋਂ ਕਿਵੇਂ ਕਰੀਏ

ਕਿਸੇ ਵੀ ਆਰਕੈਸਟਰੇਟਰ ਨੂੰ ਚਲਾਉਣ ਵਾਲੀ ਕਿਸੇ ਵੀ ਸੇਵਾ ਵਿੱਚ ਨੇਤਰਾ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਜੋੜਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਤੁਸੀਂ ਇੱਕ ਉਦਾਹਰਣ ਦੇਖ ਸਕਦੇ ਹੋ ਇੱਥੇ.

ਇਸ ਸਮੇਂ, ਨੇਤਰਾ ਕੋਲ ਸੇਵਾਵਾਂ ਲਈ ਸਾਈਡਕਾਰਸ ਨੂੰ ਆਪਣੇ ਆਪ ਲਾਗੂ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਨਹੀਂ ਹੈ, ਪਰ ਲਾਗੂ ਕਰਨ ਲਈ ਯੋਜਨਾਵਾਂ ਹਨ.

ਨੇਤਰਮੇਸ਼ ਦਾ ਭਵਿੱਖ

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

ਭਵਿੱਖ ਵਿੱਚ, ਨੇਤਰਮੇਸ਼ HTTP ਤੋਂ ਇਲਾਵਾ ਹੋਰ ਐਪਲੀਕੇਸ਼ਨ ਲੇਅਰ ਪ੍ਰੋਟੋਕੋਲ ਦਾ ਸਮਰਥਨ ਕਰੇਗਾ। L7 ਰੂਟਿੰਗ ਨੇੜਲੇ ਭਵਿੱਖ ਵਿੱਚ ਉਪਲਬਧ ਹੋਵੇਗੀ।

ਜੇਕਰ ਤੁਹਾਨੂੰ ਅਜਿਹੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਤਾਂ ਨੇਤਰਮੇਸ਼ ਦੀ ਵਰਤੋਂ ਕਰੋ ਅਤੇ ਸਵਾਲਾਂ ਅਤੇ ਸੁਝਾਵਾਂ ਦੇ ਨਾਲ ਸਾਨੂੰ ਲਿਖੋ।

ਸਰੋਤ: www.habr.com