JSON-RPC? ਛਲ REST ਲਵੋ

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

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

RPC ਕੀ ਹੈ ਇਸ ਬਾਰੇ ਸਪੱਸ਼ਟ ਹੋਣ ਲਈ, ਮੈਂ ਮਿਆਰ 'ਤੇ ਵਿਚਾਰ ਕਰਨ ਦਾ ਪ੍ਰਸਤਾਵ ਦਿੰਦਾ ਹਾਂ JSON-RPC 2.0. REST ਨਾਲ ਕੋਈ ਸਪੱਸ਼ਟਤਾ ਨਹੀਂ ਹੈ। ਅਤੇ ਇਹ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ। ਸਭ ਕੁਝ ਜੋ ਤੁਹਾਨੂੰ REST ਬਾਰੇ ਜਾਣਨ ਦੀ ਲੋੜ ਹੈ - ਇਹ ਵੱਖਰਾ ਨਹੀਂ ਹੈ HTTP ਨੂੰ.

RPC ਬੇਨਤੀਆਂ ਤੇਜ਼ ਅਤੇ ਵਧੇਰੇ ਕੁਸ਼ਲ ਹਨ ਕਿਉਂਕਿ ਉਹ ਤੁਹਾਨੂੰ ਬੈਚ ਬੇਨਤੀਆਂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀਆਂ ਹਨ।

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

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

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

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

ਉਸੇ ਦ੍ਰਿਸ਼ ਦੇ ਤਹਿਤ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਗਤੀਵਿਧੀ ਚੈਨਲਾਂ ਨੂੰ ਹਰੇ ਰੰਗ ਵਿੱਚ ਚਿੰਨ੍ਹਿਤ ਕੀਤਾ ਗਿਆ ਹੈ। ਧਿਆਨ ਦਿਓ ਕਿ RPC ਹੁਣ ਕਿਵੇਂ ਵਿਹਾਰ ਕਰਦਾ ਹੈ। ਬੇਨਤੀ ਬੈਲੇਂਸਰ ਤੋਂ ਬੈਕਐਂਡ ਤੱਕ ਸਿਰਫ ਇੱਕ ਲੱਤ 'ਤੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ। ਜਦੋਂ ਕਿ REST ਅਜੇ ਵੀ ਪਹਿਲੀ ਬੇਨਤੀ ਵਿੱਚ ਗੁਆਚ ਜਾਂਦਾ ਹੈ, ਇਹ ਪੂਰੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਗੁੰਮ ਹੋਏ ਸਮੇਂ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ।

ਸਕਰਿਪਟ ਵਿੱਚ ਸੰਸ਼ੋਧਨ ਲਈ ਦੋ ਬੇਨਤੀਆਂ ਨਹੀਂ, ਪਰ, ਕਹੋ, ਪੰਜ ਜਾਂ ਦਸ... ਅਤੇ ਇਸ ਸਵਾਲ ਦਾ ਜਵਾਬ "ਹੁਣ ਕੌਣ ਜਿੱਤਦਾ ਹੈ?" ਅਸਪਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ।

ਮੈਂ ਸਮੱਸਿਆ ਨੂੰ ਹੋਰ ਵੀ ਵਿਆਪਕ ਰੂਪ ਵਿੱਚ ਦੇਖਣ ਦਾ ਪ੍ਰਸਤਾਵ ਕਰਦਾ ਹਾਂ। ਚਿੱਤਰ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਚੈਨਲਾਂ ਦੀ ਵਰਤੋਂ ਕਿਵੇਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਪਰ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਚੈਨਲਾਂ ਤੱਕ ਸੀਮਿਤ ਨਹੀਂ ਹੈ। ਇੱਕ ਉੱਚ-ਲੋਡ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦਾ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਹਿੱਸਾ ਕੈਚ ਹੈ। ਆਓ ਹੁਣ ਕੁਝ ਕਿਸਮ ਦੀ ਉਪਭੋਗਤਾ ਕਲਾਤਮਕਤਾ ਪ੍ਰਾਪਤ ਕਰੀਏ. ਬਾਰ ਬਾਰ. ਆਓ 32 ਵਾਰ ਕਹੀਏ।

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

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

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

ਆਓ ਹੁਣ ਗਿਣੀਏ ਕਿ REST ਅਤੇ RPC ਨੇ ਵਿਚਾਰ ਅਧੀਨ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ ਕਿੰਨੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ "ਜਨਮ ਦਿੱਤਾ"?

ਬੇਨਤੀਆਂ
ਇਨਬਾਕਸ
ਬੈਕਐਂਡ ਨੂੰ
DBMS ਨੂੰ
ਸਾਫਟ ਕੈਸ਼ ਤੱਕ (ਰੇਡਿਸ)
TOTAL

ਆਰਾਮ
1 / 32 *
1
1
0
3 / 35

ਸੀ.ਪੀ.ਆਰ.
32
32
1
31
96

[*] ਸਭ ਤੋਂ ਵਧੀਆ ਸਥਿਤੀ ਵਿੱਚ (ਜੇ ਸਥਾਨਕ ਕੈਸ਼ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ) 1 ਬੇਨਤੀ (ਇੱਕ!), ਸਭ ਤੋਂ ਮਾੜੇ ਕੇਸ ਵਿੱਚ 32 ਆਉਣ ਵਾਲੀਆਂ ਬੇਨਤੀਆਂ।

ਪਹਿਲੀ ਸਕੀਮ ਦੇ ਮੁਕਾਬਲੇ, ਫਰਕ ਸ਼ਾਨਦਾਰ ਹੈ. ਹੁਣ REST ਦਾ ਲਾਭ ਸਪੱਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ। ਪਰ ਮੈਂ ਉੱਥੇ ਨਾ ਰੁਕਣ ਦਾ ਸੁਝਾਅ ਦਿੰਦਾ ਹਾਂ। ਵਿਕਸਤ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ ਇੱਕ CDN ਸ਼ਾਮਲ ਹੈ। ਅਕਸਰ ਇਹ DDoS ਅਤੇ DoS ਹਮਲਿਆਂ ਦਾ ਮੁਕਾਬਲਾ ਕਰਨ ਦੇ ਮੁੱਦੇ ਨੂੰ ਵੀ ਹੱਲ ਕਰਦਾ ਹੈ। ਸਾਨੂੰ ਪ੍ਰਾਪਤ:

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

ਕੀ ਇੱਥੇ ਖਤਮ ਹੋਣਾ ਸੰਭਵ ਹੈ? ਅਤੇ ਦੁਬਾਰਾ, ਨਹੀਂ. HTTP ਵਿਧੀਆਂ, ਜਿਵੇਂ ਕਿ ਉੱਪਰ ਦੱਸਿਆ ਗਿਆ ਹੈ, ਦਾ ਆਪਣਾ "ਜਾਦੂ" ਹੈ। ਅਤੇ ਇਹ ਬਿਨਾਂ ਕਾਰਨ ਨਹੀਂ ਹੈ ਕਿ GET ਵਿਧੀ ਇੰਟਰਨੈਟ 'ਤੇ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਵਰਤੀ ਜਾਂਦੀ ਹੈ। ਨੋਟ ਕਰੋ ਕਿ ਇਹ ਵਿਧੀ ਸਮੱਗਰੀ ਦੇ ਇੱਕ ਹਿੱਸੇ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਦੇ ਯੋਗ ਹੈ, ਉਹਨਾਂ ਸ਼ਰਤਾਂ ਨੂੰ ਸੈੱਟ ਕਰਨ ਦੇ ਯੋਗ ਹੈ ਜੋ ਤੁਹਾਡੇ ਕੋਡ ਵਿੱਚ ਨਿਯੰਤਰਣ ਨੂੰ ਟ੍ਰਾਂਸਫਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਤੱਤ ਵਿਆਖਿਆ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਹੀ. ਇਹ ਸਭ ਤੁਹਾਨੂੰ ਲਚਕਦਾਰ, ਪ੍ਰਬੰਧਨਯੋਗ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਬਣਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਜੋ ਬੇਨਤੀਆਂ ਦੇ ਅਸਲ ਵਿੱਚ ਵੱਡੇ ਪ੍ਰਵਾਹ ਨੂੰ ਸੰਭਾਲ ਸਕਦੇ ਹਨ। ਪਰ RPC ਵਿੱਚ ਇਸ ਵਿਧੀ ਨੂੰ ਅਣਡਿੱਠ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

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

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

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

RPC ਬੇਨਤੀਆਂ ਵਧੇਰੇ ਭਰੋਸੇਮੰਦ ਹੁੰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਉਹ ਇੱਕ ਸਿੰਗਲ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਦੇ ਅੰਦਰ ਬੈਚ ਬੇਨਤੀਆਂ ਨੂੰ ਲਾਗੂ ਕਰ ਸਕਦੀਆਂ ਹਨ

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

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

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

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

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

ਠੀਕ ਹੈ, ਆਓ ਕਲਪਨਾ ਕਰੀਏ ਕਿ ਅਸੀਂ ਆਪਣੇ ਆਪ ਨੂੰ (!) ਖਿੱਚਿਆ ਹੈ ਅਤੇ ਵਿਕਲਪ ਦੁਆਰਾ ਸੋਚਿਆ ਹੈ ਜਦੋਂ ਬੇਨਤੀ ਨੂੰ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਸਫਲਤਾਪੂਰਵਕ ਪੂਰਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ. ਅਤੇ ਅਸੀਂ ਕੁਝ ਸਮੇਂ ਦੇ ਅੰਤਰਾਲ ਤੋਂ ਬਾਅਦ ਬਾਕੀ ਨੂੰ ਦੁਬਾਰਾ ਪੂਰਾ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਾਂਗੇ (ਕਿਹੜਾ? ਕੀ ਫਰੰਟ ਫੈਸਲਾ ਕਰਦਾ ਹੈ?)। ਪਰ ਲਾਟਰੀ ਉਹੀ ਰਹੀ। SMS ਭੇਜਣ ਦੀ ਬੇਨਤੀ ਦੇ ਦੁਬਾਰਾ ਅਸਫਲ ਹੋਣ ਦੀ 50/50 ਸੰਭਾਵਨਾ ਹੈ।

ਸਹਿਮਤ ਹੋਵੋ, ਗਾਹਕ ਪੱਖ ਤੋਂ, ਸੇਵਾ ਓਨੀ ਭਰੋਸੇਮੰਦ ਨਹੀਂ ਜਾਪਦੀ ਜਿੰਨੀ ਅਸੀਂ ਚਾਹੁੰਦੇ ਹਾਂ... REST ਬਾਰੇ ਕੀ?

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

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

ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਦੇਖ ਸਕਦੇ ਹਾਂ, JSON-RPC ਦੀ ਭਰੋਸੇਯੋਗਤਾ ਨੂੰ ਓਵਰਰੇਟ ਕੀਤਾ ਗਿਆ ਹੈ. ਦਰਅਸਲ, ਡੇਟਾਬੇਸ ਵਿੱਚ ਇਕਸਾਰਤਾ ਨੂੰ ਸੰਗਠਿਤ ਕਰਨਾ ਸੌਖਾ ਹੈ. ਪਰ ਕੁਰਬਾਨੀ, ਇਸ ਮਾਮਲੇ ਵਿੱਚ, ਸਮੁੱਚੇ ਤੌਰ 'ਤੇ ਸਿਸਟਮ ਦੀ ਭਰੋਸੇਯੋਗਤਾ ਹੋਵੇਗੀ.

ਸਿੱਟਾ ਕਾਫ਼ੀ ਹੱਦ ਤੱਕ ਪਿਛਲੇ ਇੱਕ ਦੇ ਸਮਾਨ ਹੈ. ਜਦੋਂ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਸਧਾਰਨ ਹੁੰਦਾ ਹੈ, ਤਾਂ JSON-RPC ਦੀ ਸਪੱਸ਼ਟਤਾ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਇੱਕ ਪਲੱਸ ਹੈ. ਜੇ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਉੱਚ ਲੋਡ ਦੇ ਨਾਲ ਉੱਚ ਉਪਲਬਧਤਾ ਸ਼ਾਮਲ ਹੈ, ਤਾਂ REST ਇੱਕ ਵਧੇਰੇ ਸਹੀ, ਹਾਲਾਂਕਿ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ, ਹੱਲ ਵਰਗਾ ਲੱਗਦਾ ਹੈ.

REST ਤੱਕ ਦਾਖਲਾ ਸੀਮਾ ਘੱਟ ਹੈ

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

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

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

ਪਰ RPC ਬਾਰੇ - ਤੁਸੀਂ ਕਰ ਸਕਦੇ ਹੋ। ਇਸ ਦੇ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਲੈਣ ਲਈ ਇਹ ਕਾਫੀ ਹੈ। ਇਸ ਲਈ ਤੁਹਾਨੂੰ ਲੋੜ ਹੈ ਮੂਰਖ JSON-RPC? ਜਾਂ ਕੀ ਇਹ ਅਜੇ ਵੀ ਛਲ REST ਹੈ? ਤੁਸੀਂ ਫੈਸਲਾ ਕਰੋ.

ਮੈਨੂੰ ਪੂਰੀ ਉਮੀਦ ਹੈ ਕਿ ਮੈਂ ਤੁਹਾਡਾ ਸਮਾਂ ਬਰਬਾਦ ਨਹੀਂ ਕੀਤਾ ਹੈ।

ਸਰੋਤ: www.habr.com