04 ਦਸੰ 2025·8 ਮਿੰਟ
ਬਟਲਰ ਲੈਂਪਸਨ ਅਤੇ Xerox PARC: ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਸਿਸਟਮ ਲਈ ਸਬਕ
Butler Lampson ਦੇ Xerox PARC ਵਿਚਲੇ ਵਿਚਾਰਾਂ ਲਈ ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਮਾਰਗਦਰਸ਼ਨ—ਨੈਟਵਰਕਿੰਗ, OS ਰਚਨਾ, ਨਾਂਕਰਨ, ਕੈਸ਼ਿੰਗ, ਅਤੇ RPC—ਅਤੇ ਇਹ ਕਿਉਂ ਅਜੇ ਵੀ ਵੱਡੇ ਪੱਧਰ ਦੇ ਸਿਸਟਮਾਂ ਨੂੰ ਰੂਪ ਦੇ ਰਹੇ ਹਨ।
Butler Lampson ਦੇ Xerox PARC ਵਿਚਲੇ ਵਿਚਾਰਾਂ ਲਈ ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਮਾਰਗਦਰਸ਼ਨ—ਨੈਟਵਰਕਿੰਗ, OS ਰਚਨਾ, ਨਾਂਕਰਨ, ਕੈਸ਼ਿੰਗ, ਅਤੇ RPC—ਅਤੇ ਇਹ ਕਿਉਂ ਅਜੇ ਵੀ ਵੱਡੇ ਪੱਧਰ ਦੇ ਸਿਸਟਮਾਂ ਨੂੰ ਰੂਪ ਦੇ ਰਹੇ ਹਨ।
ਬਟਲਰ ਲੈਂਪਸਨ ਪਿਛਲੇ ਅੱਧ-ਸਦੀ ਦੇ ਸਭ ਤੋਂ ਪ੍ਰਭਾਵਸ਼ালী ਕੰਪਿਊਟਰ ਸਿਸਟਮ ਡਿਜ਼ਾਇਨਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਸੀ। 1970s ਅਤੇ 80s ਵਿੱਚ Xerox PARC 'ਚ, ਉਸਨੇ ਇਹ ਨਿਰਧਾਰਤ ਕੀਤਾ ਕਿ ਨੈੱਟਵਰਕਡ ਕੰਪਿਊਟਰਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਮਸ਼ੀਨਾਂ ਵਜੋਂ ਨਹੀਂ, ਬਲਕਿ ਇੱਕ ਸਾਂਝੇ ਵਾਤਾਵਰਣ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਦੇਖਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਿੱਥੇ ਪ੍ਰੋਗਰਾਮ, ਫਾਇਲਾਂ, ਪ੍ਰਿੰਟਰ ਅਤੇ ਲੋਕ ਵਿਸ਼ਵਾਸਯੋਗ ਤਰੀਕੇ ਨਾਲ ਇੰਟਰੈਕਟ ਕਰ ਸਕਦੇ ਹਨ।
ਲੈਂਪਸਨ ਦੇ ਕੰਮ ਦੀ ਦਿਰਘਕਾਲੀਅਤ ਦਾ ਕਾਰਨ ਇਹ ਹੈ ਕਿ ਉਹ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ 'ਤੇ ਧਿਆਨ ਦਿੰਦਾ ਸੀ: ਐਸਟੇਬਲ ਇੰਟਰਫੇਸ ਜੋ ਸਕੇਲ ਹੁੰਦੇ ਹਨ, ਰਚਨਾ ਜੋ ਜੋੜਦੀ ਹੈ, ਅਤੇ ਐਸੇ ਸਿਸਟਮ ਜੋ ਅਸਲ-ਦੁਨੀਆ ਦੇ ਫੇਲਿਉਰ ਨੂੰ ਸਧਾਰਨ ਜ਼ਰੂਰਤ ਮੰਨਦੇ ਹਨ ਨਾ ਕਿ ਇੱਕ ਅਪਵਾਦ।
“ਸਕੇਲ” ਸਿਰਫ ਵੱਡੇ ਡੇਟਾ ਸੈਂਟਰ ਦੀ ਗੱਲ ਨਹੀਂ। ਇਹ ਉਹ ਹੈ ਜੋ ਹੁੰਦ ਹੈ ਜਦੋਂ ਤੁਹਾਡੇ ਸਿਸਟਮ ਕੋਲ ਬਹੁਤ ਸਾਰੇ ਉਪਭੋਗੀ, ਕਈ ਮਸ਼ੀਨ, ਅਤੇ ਅਸਲ-ਦੁਨੀਆ ਦੀ ਗੜਬੜ ਹੁੰਦੀ ਹੈ। ਸੋਚੋ: ਇੱਕ ਦਫ਼ਤਰ ਜਿੱਥੇ ਸੈਂਕੜੇ ਲੈਪਟਾਪ ਅਤੇ ਸਰਵਿਸਾਂ ਲੋਗਇਨ ਅਤੇ ਫਾਇਲਾਂ ਸਾਂਝਾ ਕਰਦੇ ਹਨ; ਇੱਕ ਉਤਪਾਦ ਜੋ ਇੱਕ ਵਾਰ ਵਿੱਚ ਹਜ਼ਾਰਾਂ ਗਾਹਕਾਂ ਵੱਲੋਂ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ; ਜਾਂ ਇੱਕ ਕੰਪਨੀ ਐਪ ਜੋ ਇੱਕ ਸਰਵਰ ਡਾਊਨ ਹੋਣ, ਨੈੱਟਵਰਕ ਲਿੰਕ ਧੀਮਾ ਹੋਣ ਜਾਂ ਅਪਡੇਟ ਅਸ਼ੁੱਧ ਤਰੀਕੇ ਨਾਲ ਰੋਲ ਆਉਟ ਹੋਣ 'ਤੇ ਵੀ ਕੰਮ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।
ਉਸ ਬਿੰਦੂ 'ਤੇ, ਮੁਸ਼ਕਲੀਆਂ ਬਦਲ ਜਾਂਦੀਆਂ ਹਨ। ਤੁਸੀਂ ਸਵਾਲ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹੋ “ਕੀ ਇਹ ਮੇਰੇ ਕੰਪਿਊਟਰ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ?” ਅਤੇ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹੋ:\n\n- ਇਕ ਹਿੱਸਾ ਮਿਡ-ਰਿਕਵੇਸਟ ਵਿੱਚ ਫੇਲ ਹੋਣ 'ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ?\n- ਜਦੋਂ ਨਾਮ ਅਤੇ ਸਥਿਤੀਆਂ ਬਦਲ ਰਹੀਆਂ ਹਨ ਤਾਂ ਤੁਸੀਂ ਸਹੀ ਸਰਵਿਸ ਜਾਂ ਸਰੋਤ ਕਿਵੇਂ ਲੱਭਦੇ ਹੋ?\n- ਤੁਸੀਂ ਪ੍ਰਦਰਸ਼ਨ ਉੱਚਾ ਕਿਵੇਂ ਰੱਖਦੇ ਹੋ ਬਿਨਾਂ ਥੱਲੇ ਜਾਂ ਗਲਤ ਡਾਟਾ ਦੇਵੀਫ਼ਤ ਕੀਤਾ ਬਿਨਾਂ?
ਇਹ ਕਿਸੇ ਵੀ ਟ੍ਰਿਵੀਆਲ ਜਾਂ ਨੋਸਟਾਲਜੀਆ ਦਾ ਦੌਰਾ ਨਹੀਂ ਹੈ। ਲੈਂਪਸਨ ਦਾ ਕੰਮ ਇਸ ਲਈ ਲਾਭਦਾਇਕ ਹੈ ਕਿਉਂਕਿ ਉਸਨੇ ਉਹ ਡਿਜ਼ਾਇਨ ਵਿਚਾਰ ਉਤਪੰਨ ਕੀਤੇ ਜੋ ਟਿਕੇ ਰਹੇ: ਸਾਫ਼ ਇੰਟਰਫੇਸ, ਸਾਦੇ ਬਿਲਡਿੰਗ ਬਲਾਕ, ਅਤੇ ਫੇਲਿਉਰ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖ ਕੇ ਬਣੇ ਸਿਸਟਮ।
ਅਸੀਂ ਉਹ ਧਾਰਣਾਵਾਂ ਉਪਰ ਧਿਆਨ ਦੇਵਾਂਗੇ ਜੋ ਆਧੁਨਿਕ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮਾਂ ਅਤੇ ਵੰਡਿਤ ਕੰਪਿਊਟਿੰਗ ਵਿਚ ਅੱਗੇ ਆਈਆਂ—ਨੈੱਟਵਰਕਿੰਗ, RPC, ਨਾਂਕਰਨ, ਕੈਸ਼ਿੰਗ, ਅਤੇ ਪ੍ਰਯੋਗਿਕ ਸੁਰੱਖਿਆ—ਤਾਂ ਜੋ ਤੁਸੀਂ ਅਜੋਕ਼ੇ ਆਰਕੀਟੈਕਚਰਾਂ ਵਿੱਚ ਇਹ ਪੈਟਰਨ ਪਛਾਣ ਸਕੋ ਅਤੇ ਆਪਣੇ ਸਰਵਿਸਾਂ 'ਤੇ ਇਹ ਸਬਕ ਲਾਗੂ ਕਰ ਸਕੋ।
ਇੱਕ ਦਫ਼ਤਰ ਦੀ ਸੋਚੋ ਜਿੱਥੇ ਹਰ ਵਿਅਕਤੀ ਦੇ ਡੈਸਕ 'ਤੇ ਇੱਕ ਸ਼ਕਤੀਸ਼ਾਲੀ ਨਿੱਜੀ ਕੰਪਿਊਟਰ ਹੈ, ਜੋ ਸਾਂਝੇ ਸਰਵਿਸਾਂ ਨਾਲ ਜੁੜਿਆ ਹੋਇਆ ਹੈ ਜਿਸ ਨਾਲ ਪੂਰੇ ਵਰਕਪਲੇਸ ਨੂੰ ਇੱਕ ਸਤਤ ਸਿਸਟਮ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ। ਇਸੇ PARC ਦੀ ਸੋਚ ਸੀ: ਸਿਰਫ “ਇੱਕ ਕੰਪਿਊਟਰ” ਨਹੀਂ, ਪਰ ਇੱਕ ਨੈੱਟਵਰਕਡ ਵਾਤਾਵਰਣ ਜਿੱਥੇ ਕੰਪਿਊਟਿੰਗ, ਦਸਤਾਵੇਜ਼ ਅਤੇ ਸੰਚਾਰ ਲੋਕਾਂ ਅਤੇ ਮਸ਼ੀਨਾਂ ਵਿਚਕਾਰ ਆਸਾਨੀ ਨਾਲ ਬਹਿੰਦੇ ਰਹਿੰਦੇ ਹਨ।
PARC ਦਾ ਉਦੇਸ਼ ਨਿੱਜੀ ਕੰਪਿਊਟਿੰਗ ਨੂੰ ਰੋਜ਼ਾਨਾ ਕੰਮ ਲਈ ਪ੍ਰਯੋਗਿਕ ਬਣਾਉਣਾ ਸੀ—ਲਿਖਣਾ, ਡਿਜ਼ਾਇਨ ਕਰਨਾ, ਫਾਇਲਾਂ ਸਾਂਝਾ ਕਰਨਾ, ਡਰਾਫਟ ਪ੍ਰਿੰਟ ਕਰਨਾ, ਅਤੇ ਸਹਿਯੋਗ ਕਰਨਾ—ਬਿਨਾਂ ਕਿਸੇ ਮੇਨਫ੍ਰੇਮ ਆਪਰੇਟਰ ਜਾਂ ਖਾਸ ਰਿਵਾਜਾਂ ਦੀ ਲੋੜ ਦੇ। ਲਕਸ਼ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਡਿਵਾਈਸ ਨਹੀਂ ਸੀ; ਇਹ ਇਕ ਐਸਾ ਕੰਮਕਾਜੀ ਸੈੱਟਅਪ ਸੀ ਜਿਸ 'ਚ ਤੁਸੀਂ ਸਾਰਾ ਦਿਨ ਜੀ ਸਕੋ।
Alto “ਨਿੱਜੀ” ਹਿੱਸਾ ਸੀ: ਇੰਟਰਐਕਟਿਵ ਕੰਮ ਲਈ ਡਿਜ਼ਾਇਨ ਕੀਤਾ ਗਿਆ ਇੱਕ ਕੰਪਿਊਟਰ। Ethernet “ਵਰਕਪਲੇਸ” ਹਿੱਸਾ ਸੀ: ਇੱਕ ਤੇਜ਼ ਲੋਕਲ ਨੈੱਟਵਰਕ ਜਿਸ ਨੇ Altos ਨੂੰ ਇਕ ਦੂਜੇ ਅਤੇ ਸਾਂਝੇ ਸਰੋਤਾਂ ਨਾਲ ਗੱਲ ਕਰਨ ਦਿੱਤੀ।
ਉਹ ਸਾਂਝੇ ਸਰੋਤ ਜ਼ਰੂਰੀ ਸਨ, ਸਿਰਫ ਮੌਜੂਦگي ਨਹੀਂ:\n\n- ਸਾਂਝੇ ਪ੍ਰਿੰਟਰ ਉੱਚ-ਗੁਣਵੱਤਾ ਆਉਟਪੁੱਟ ਨੂੰ ਵਰਕਫਲੋ ਦਾ ਆਮ ਹਿੱਸਾ ਬਣਾਉਂਦੇ ਸਨ।\n- ਫਾਇਲ ਸਰਵਰ ਸਟੋਰੇਜ ਅਤੇ ਸਾਂਝਾ ਕਰਨ ਨੂੰ ਇੱਕ ਸਰਵਿਸ ਬਣਾਉਂਦੇ ਸਨ, ਸਰਵਰਾਂ ਦੀ ਥਾਂ ਨਹੀਂ।
ਇਹ ਜੋੜ ਸਿੱਧਾ ਇਕ ਨਵਾਂ ਮਾਨਸਿਕ ਮਾਡਲ ਪੈਦਾ ਕਰਦਾ ਸੀ: ਤੁਹਾਡਾ ਕੰਪਿਊਟਰ ਆਪਣੇ ਆਪ ਵਿੱਚ ਸ਼ਕਤੀਸ਼ਾਲੀ ਹੈ, ਪਰ ਜਦੋਂ ਇਹ ਨਿਰਭਰਤਾ ਨਾਲ ਨੈੱਟਵਰਕ ਸਰਵਿਸਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦਾ ਹੈ ਤਾਂ ਇਹ ਨਾਭੀਕ ਤੌਰ 'ਤੇ ਜ਼ਿਆਦਾ ਲਾਭਦਾਇਕ ਬਣ ਜਾਂਦਾ ਹੈ।
PARC ਸਿਰਫ ਪ੍ਰੋਟੋਟਾਈਪ ਜਾਂ ਅਲੱਗ ਡੈਮੋ ਤੇ ਨਹੀਂ ਰੁਕਿਆ। ਉਹਨਾਂ ਨੇ ਪੂਰੇ ਸਿਸਟਮ—ਹਾਰਡਵੇਅਰ, ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ, ਨੈੱਟਵਰਕਿੰਗ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ—ਨੂੰ ਜੋੜਿਆ ਅਤੇ ਫਿਰ ਲੋਕਾਂ ਦੇ ਅਸਲ ਕੰਮ ਕਰਨ ਦੇ ਤਰੀਕੇ ਤੋਂ ਸਿਖਿਆ ਲਿਆ।
ਉਹ ਫੀਡਬੈਕ ਲੂਪ ਉਹਨਾਂ ਮੁਸ਼ਕਲਾਂ ਨੂੰ ਪ੍ਰਗਟ ਕਰਦਾ ਜੋ ਸਿਰਫ ਪ੍ਰਯੋਗ ਵਿੱਚ ਹੀ ਸਾਹਮਣੇ ਆਉਂਦੀਆਂ ਹਨ: ਚੀਜ਼ਾਂ ਨੂੰ ਨਾਮ ਦੇਣਾ, ਓਵਰਲੋਡ ਦਾ ਸਹਿਣ, ਫੇਲਿਉਰ ਨਾਲ ਨਜਿੱਠਣਾ, ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਪੂਰਵਨਿਯਤ ਰੱਖਣਾ, ਅਤੇ ਸਾਂਝੇ ਸਰੋਤਾਂ ਨੂੰ ਦੂਰ ਦੇ ਨਹੀਂ ਬਲਕਿ “ਨਜ਼ਦੀਕੀ” ਮਹਿਸੂਸ ਕਰਵਾਉਣਾ।
ਬਹੁਤ ਸਾਰੇ PARC ਸਿਸਟਮ ਇੱਕ ਪਛਾਣਯੋਗ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਦਰਸਾਉਂਦੇ ਹਨ: ਸਾਦੇ ਪ੍ਰਿਮਿਟਿਵ ਅਤੇ ਮਜ਼ਬੂਤ ਇੰਜੀਨੀਅਰਿੰਗ ਅਨੁਸ਼ਾਸਨ। ਇੰਟਰਫੇਸਾਂ ਨੂੰ ਛੋਟਾ ਅਤੇ ਸਮਝਣਯੋਗ ਰੱਖੋ, ਐਸੇ ਸਰਵਿਸ ਬਣਾਓ ਜੋ ਮਿਲ ਕੇ ਕੰਮ ਕਰਨ ਯੋਗ ਹੋਣ, ਅਤੇ ਖ਼ਿਆਲਾਂ ਨੂੰ ਅਸਲ ਡਿਪਲੌਇਮੈਂਟ ਵਿੱਚ ਟੈਸਟ ਕਰੋ। ਉਹ ਅੰਦਾਜ਼ ਇੱਕ ਵੱਡਾ ਕਾਰਨ ਹੈ ਕਿ ਇਹ ਸਬਕ ਆਜ ਦੀ ਟੀਮਾਂ ਨੂੰ ਵੀ ਲਾਗੂ ਹੁੰਦੇ ਹਨ।
Xerox Alto ਸਿਰਫ “ਡੈਸਕ 'ਤੇ ਇੱਕ ਕੰਪਿਊਟਰ” ਨਹੀਂ ਸੀ। ਇਹ ਇੱਕ ਮੋੜ ਸੀ ਕਿਉਂਕਿ ਇਸ ਨੇ ਤਿੰਨ ਵਿਚਾਰਾਂ ਨੂੰ ਇੱਕ ਰੋਜ਼ਾਨਾ ਅਨੁਭਵ ਵਿੱਚ ਜੋੜਿਆ: ਇੱਕ ਨਿੱਜੀ ਮਸ਼ੀਨ, ਉੱਚ-ਗੁਣਵੱਤਾ ਗ੍ਰਾਫਿਕਲ ਇੰਟਰਫੇਸ, ਅਤੇ ਇੱਕ ਤੇਜ਼ ਲੋਕਲ ਨੈੱਟਵਰਕ ਜੋ ਤੁਹਾਨੂੰ ਸਾਂਝੇ ਸਰੋਤਾਂ ਨਾਲ ਜੋੜਦਾ ਸੀ।
ਇਸ ਜੋੜ ਨੇ ਖ਼ਾਮੋਸ਼ੀ ਨਾਲ ਉਮੀਦਾਂ ਨੂੰ ਬਦਲ ਦਿੱਤਾ। ਤੁਹਾਡਾ ਕੰਪਿਊਟਰ ਤੁਹਾਡਾ ਲੱਗਦਾ ਸੀ—ਤੁਰੰਤ, ਇੰਟਰਐਕਟਿਵ, ਅਤੇ ਹਮੇਸ਼ਾਂ ਉਪਲਬਧ—ਫਿਰ ਵੀ ਇਹ ਵੱਡੇ ਸਿਸਟਮ ਵਿੱਚ ਇੱਕ ਦਰਵਾਜ਼ਾ ਵਰਗਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਸੀ: ਸਾਂਝੇ ਫਾਇਲ ਸਰਵਰ, ਪ੍ਰਿੰਟਰ, ਅਤੇ ਸਹਿਯੋਗੀ ਟੂਲ। ਇਹੀ ਕਲਾਇੰਟ/ਸਰਵਰ ਮਨੋਭਾਵ ਦੀ ਬੀਜ ਸੀ।
Alto-ਸਟਾਈਲ ਸਿਸਟਮਾਂ ਤੋਂ ਪਹਿਲਾਂ, ਕੰਪਿਊਟਿੰਗ ਅਕਸਰ ਮਸ਼ੀਨ 'ਤੇ ਜਾਣਾ ਜਾਂ ਟਰਮੀਨਲ ਦੇ ਰਾਹੀਂ ਹੁੰਦਾ ਸੀ। Alto ਨੇ ਇਸ ਨੂੰ ਉਲਟ ਕੀਤਾ: “ਕਲਾਇੰਟ” ਵਰਤੋਂਕਾਰ ਦੇ ਨਾਲ ਰਹਿੰਦਾ ਸੀ, ਅਤੇ ਨੈੱਟਵਰਕ ਸ਼ਕਤੀਸ਼ਾਲੀ ਸਾਂਝੀਆਂ ਖੁਬੀਆਂ ਨੂੰ ਨਜ਼ਦੀਕੀ ਮਹਿਸੂਸ ਕਰਵਾ ਦਿੰਦਾ ਸੀ।
ਅਮਲ ਵਿੱਚ, “ਕਲਾਇੰਟ/ਸਰਵਰ” ਇੱਕ ਡਾਇਗ੍ਰਾਮ ਨਹੀਂ ਸੀ—ਇਹ ਇੱਕ ਵਰਕਫਲੋ ਸੀ। ਕੁਝ ਕੰਮ ਲੋਕਲ ਹੋਂਦੇ ਸਨ ਕਿਉਂਕਿ ਉਹ ਤੁਰੰਤ ਫੀਡਬੈਕ ਚਾਹੁੰਦੇ ਸਨ: ਟੈਕਸਟ ਸੰਪਾਦਨ, ਡਰਾਇੰਗ, ਖਿੜਕੀਆਂ ਨਾਲ ਇੰਟਰਐਕਸ਼ਨ। ਹੋਰ ਕੰਮ ਰਿਮੋਟ ਹੁੰਦਾ ਸੀ ਕਿਉਂਕਿ ਉਹ ਸਾਂਝੇ ਹੋਣ ਦੇ ਨੈਚਰਲ ਸਨ ਜਾਂ ਹਰ ਡੈਸਕ 'ਤੇ ਨਕਲ ਕਰਨ ਲਈ ਮਹਿੰਗੇ ਸਨ: ਪ੍ਰਮਾਣਿਕ ਦਸਤਾਵੇਜ਼ ਸੰਭਾਲਣਾ, ਪ੍ਰਿੰਟਰਾਂ ਦਾ ਪਰਬੰਧ, ਅਕਸੇਸ ਕੋਆਰਡੀਨੇਸ਼ਨ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ, ਸਾਂਝੇ ਸਰਵਿਸ ਚਲਾਉਣਾ।
ਜੇ ਤੁਸੀਂ “Alto” ਨੂੰ “ਲੈਪਟਾਪ” ਅਤੇ “ਫਾਇਲ/ਪ੍ਰਿੰਟ ਸਰਵਰ” ਨੂੰ “ਕਲਾਉਡ ਸਰਵਿਸਜ਼” ਨਾਲ ਬਦਲੋ, ਤਾਂ ਮਨੋ-ਮਾਡਲ ਜਾਣਾਂ-ਪਛਾਣ ਦਾ ਹੋਵੇਗਾ। ਤੁਹਾਡੀ ਡਿਵਾਈਸ ਅਜੇ ਵੀ ਕਲਾਇੰਟ ਹੈ: ਇਹ UI ਰੈਂਡਰ ਕਰਦੀ, ਡੇਟਾ ਕੈਸ਼ ਕਰਦੀ, ਅਤੇ ਘੱਟ-ਲੈਟੰਸੀ ਇੰਟਰੈਕਸ਼ਨਾਂ ਨੂੰ ਹੇਂਡਲ ਕਰਦੀ। ਕਲਾਉਡ ਫਿਰ ਵੀ ਸਰਵਰ ਪੱਖ ਹੈ: ਇਹ ਸਾਂਝੀ ਸਥਿਤੀ, ਸਹਿਯੋਗ, ਕੇਂਦਰੀ ਨੀਤੀ, ਅਤੇ ਲਚਕੀਲਾ ਕੰਪਿਊਟ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।
ਸਬਕ ਇਹ ਹੈ ਕਿ ਚੰਗੇ ਸਿਸਟਮ ਇਸ ਵੰਡ ਨੂੰ ਗਲ-ਵਿਰੋਧ ਨਹੀਂ ਕਰਦੇ। ਉਪਭੋਗੀ ਲੋਕਲ ਪ੍ਰਤੀਕ੍ਰਿਆ ਤੇ ਆਫਲਾਈਨ ਧੈਰਜ ਚਾਹੁੰਦੇ ਹਨ, ਜਦਕਿ ਸੰਸਥਾਵਾਂ ਸਾਂਝੀ ਸੱਚਾਈ ਅਤੇ ਕੋਆਰਡੀਨੇਟ ਕੀਤੇ ਅਧਿਕਾਰ ਚਾਹੁੰਦੀਆਂ ਹਨ।
ਇਹ ਵੰਡ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਅਤੇ ਸਿਸਟਮ ਡਿਜ਼ਾਇਨਰਾਂ ਲਈ ਲਗਾਤਾਰ ਤਣਾਅ ਪੈਦਾ ਕਰਦੀ ਹੈ:\n\n- ਲੋਕਲ ਤੌਰ 'ਤੇ ਪ੍ਰਤੀਕ੍ਰਿਆਸ਼ੀਲਤਾ: UI ਨੈੱਟਵਰਕ 'ਤੇ ਇੰਤਜ਼ਾਰ ਨਹੀਂ ਕਰ ਸਕਦੀ।\n- ਨੈੱਟਵਰਕ ਉੱਤੇ ਸੰਗਤਤਾ: ਸਾਂਝੀਆਂ ਫਾਇਲਾਂ, ਪਛਾਣਾਂ, ਅਤੇ ਅਨੁਮਤੀਆਂ ਨੇ ਤਾਂ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਜਦੋਂ ਬਹੁਤ ਸਾਰੇ ਕਲਾਇੰਟ ਇੱਕਠੇ ਕਾਰਵਾਈ ਕਰ ਰਹੇ ਹੋਣ ਤਾਂ ਵੀ ਉਹ ਪੇਸ਼ਗੋਈਯੋਗ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਨ।
PARC-ਯੁੱਗ ਦਾ ਕੰਮ ਇਸ ਤਣਾਅ ਨੂੰ ਜਲਦੀ ਦਿੱਸਾਊ ਬਣਾਉਂਦਾ ਸੀ। ਜਦੋਂ ਤੁਸੀਂ ਮੰਨ ਲੈਂਦੇ ਹੋ ਕਿ ਨੈੱਟਵਰਕ ਕੰਪਿਊਟਰ ਦਾ ਹਿੱਸਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇੰਟਰਫੇਸ, ਕੈਸ਼ਿੰਗ, ਅਤੇ ਫੇਲਿਉਰ ਵਿਹਾਰ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਡਿਜ਼ਾਇਨ ਕਰਨ ਲਈ ਮਜ਼ਬੂਰ ਹੋ ਜਾਂਦੇ ਹੋ ਕਿ “ਲੋਕਲ” ਅਤੇ “ਰਿਮੋਟ” ਇੱਕ ਸਿਸਟਮ ਵਾਂਗ ਮਹਿਸੂਸ ਹੋਣ—ਬਿਨਾਂ ਇਹ ਦਾਬਾ ਕਰਨ ਦੇ ਕਿ ਉਹ ਇਕੋ ਜਿਹੇ ਹਨ।
Ethernet ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਅਣਡਿੱਠਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ “ਸਿਰਫ ਨੈੱਟਵਰਕਿੰਗ” ਵਾਂਗ ਲੱਗਦਾ ਹੈ। PARC 'ਤੇ, ਇਹ ਉਹ ਪ੍ਰਾਗਟਿਕ ਤਬਦੀਲੀ ਸੀ ਜਿਸ ਨੇ ਇੱਕ ਕਮਰੇ ਦੀਆਂ ਨਿੱਜੀ ਮਸ਼ੀਨਾਂ ਨੂੰ ਇੱਕ ਸਾਂਝੇ ਸਿਸਟਮ ਵਾਂਗ ਵਰਤਣਯੋਗ ਬਣਾ ਦਿੱਤਾ।
Ethernet ਤੋਂ ਪਹਿਲਾਂ, ਕੰਪਿਊਟਰਾਂ ਨੂੰ ਜੁੜਨ ਲਈ ਮਹਿੰਗੇ, ਵਿਸ਼ੇਸ਼ ਲਿੰਕ ਦੀ ਲੋੜ ਹੁੰਦੀ ਸੀ। Ethernet ਨੇ ਆਰਥਿਕਤਾ ਬਦਲੀ: ਇੱਕ ਤੁਲਨਾਤਮਕ ਰੂਪ ਵਿੱਚ ਸਸਤਾ, ਸਾਂਝਾ ਮੀਡਿਯਮ ਜਿਸ 'ਤੇ ਕਈ ਮਸ਼ੀਨਾਂ ਨਾਲ ਜੁੜਿਆ ਜਾ ਸਕਦਾ ਸੀ।
ਇਸ ਨੇ ਡਿਫਾਲਟ ਧਾਰਣਾ ਨੂੰ ਬਦਲ ਦਿੱਤਾ: “ਇੱਕ ਵੱਡਾ ਕੰਪਿਊਟਰ” ਤੋਂ “ਕਈ ਛੋਟੇ ਕੰਪਿਊਟਰ ਸਹਿਯੋਗੀ” ਵੱਲ। ਸਹਿਯੋਗ ਹੁਣ ਹੀਰੋਇਕ ਢਾਂਚਿਆਂ ਦੀ ਲੋੜ ਨਹੀਂ ਕਰਦਾ ਸੀ।
ਇੱਕੋ ਤਰ੍ਹਾਂ, Ethernet ਦੀ ਸਾਂਝੀ ਸੁਭਾ ਨੇ ਨਵੇਂ ਕਿਸਮ ਦੇ ਸਿਸਟਮ ਡਿਜ਼ਾਇਨ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕੀਤਾ: ਸਰਵਿਸਾਂ ਵੱਖ-ਵੱਖ ਮਸ਼ੀਨਾਂ 'ਤੇ ਰਹਿ ਸਕਦੀਆਂ ਸਨ, ਪ੍ਰਿੰਟਰ ਅਤੇ ਫਾਇਲ ਸਰਵਰ ਨੈੱਟਵਰਕ-ਅਟੈਚਡ ਹੋ ਸਕਦੇ ਸਨ, ਅਤੇ ਟੀਮਜੇ ਤੇਜ਼ੀ ਨਾਲ ਇਟਰੇਟ ਕਰ ਸਕਦੀਆਂ ਸਨ ਕਿਉਂਕਿ ਕਨੈਕਟੀਵਿਟੀ ਰיבהੜੀ ਨਹੀਂ ਸੀ।
ਅੱਜ ਅਸੀਂ ਨੈੱਟਵਰਕ ਨੂੰ ਉਸ ਤਰੀਕੇ ਨਾਲ ਮੰਨਦੇ ਹਾਂ ਜਿਸ ਤਰੀਕੇ ਨਾਲ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਮੈਮੋਰੀ ਜਾਂ ਸਟੋਰੇਜ ਨੂੰ ਮੰਨਦਾ ਹੈ: ਇਹ ਇੱਕ ਐਡ-ਆਨ ਨਹੀਂ, ਇਹ ਪਲੇਟਫਾਰਮ ਦਾ ਹਿੱਸਾ ਹੈ। ਤੁਹਾਡੀ ਐਪ ਦਾ “ਲੋਕਲ” ਵਿਹਾਰ ਅਕਸਰ ਰਿਮੋਟ ਕਾਲਾਂ, ਰਿਮੋਟ ਡੇਟਾ, ਰਿਮੋਟ ਆਈਡੈਂਟੀਟੀ, ਅਤੇ ਰਿਮੋਟ ਕਨਫਿਗਰੇਸ਼ਨ 'ਤੇ ਨਿਰਭਰ ਹੋਦਾ ਹੈ।
ਜਿਵੇਂ ਹੀ ਤੁਸੀਂ ਇਹ ਸਵੀਕਾਰ ਕਰ ਲੈਂਦੇ ਹੋ, ਤੁਸੀਂ ਹੋਰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਡਿਜ਼ਾਇਨ ਕਰਨਾ ਛੱਡ ਦਿੰਦੇ ਹੋ ਜਿਵੇਂ ਕਿ ਨੈੱਟਵਰਕ ਨਰਮਤਾ ਨਾਲ ਰਾਹ ਦੱਸ ਕੇ ਬਾਹਰ ਰਹੇਗਾ।
ਇੱਕ ਸਾਂਝਾ ਨੈੱਟਵਰਕ ਦਾ ਮਤਲਬ ਮੁਕਾਬਲਾ ਹੈ। ਪੈਕਟ ਦੇਰੀ ਹੁੰਦੇ ਹਨ, ਡ੍ਰਾਪ ਹੁੰਦੇ ਹਨ ਜਾਂ ਰੀਓਰਡਰ ਹੋ ਜਾਂਦੇ ਹਨ। ਪੀਅਰ ਰੀਬੂਟ ਕਰਦੇ ਹਨ। ਸਵਿੱਚ ਭਰ ਜਾਂਦੇ ਹਨ। ਇੱਥੇ ਤੱਕ ਕਿ ਜਦੋਂ ਕੁਝ “ਟੁਟਿਆ” ਵੀ ਨਹੀਂ ਹੁੰਦਾ, ਸਿਸਟਮ ਟੁਟਿਆ ਹੋਇਆ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ।
ਇਸ ਲਈ ਸਹੀ ਰਵੱਈਆ ਇਹ ਹੈ ਕਿ ਅਸਮੁੱਚੇ ਹਾਲਾਤਾਂ ਵਿੱਚ ਆਮ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਬਣਾਓ:\n\n- ਜਲਦੀ ਮਾਪੋ: ਲਾਗ, ਬੁਨਿਆਦੀ ਮੈਟ੍ਰਿਕਸ, ਅਤੇ ਰਿਕਵੇਸਟ ਟ੍ਰੇਸਿੰਗ ਤਾਂ ਜੋ ਤੁਸੀਂ ਵੇਖ ਸਕੋ ਸਮਾਂ ਕਿੱਥੇ ਜਾਂਦਾ ਹੈ।\n- ਡਿਫਾਲਟ ਤੌਰ 'ਤੇ ਟਾਈਮਆਉਟਸ ਵਰਤੋ, ਨਾ ਕਿ ਆਖ਼ਰੀ ਮਿੰਟ ਦਾ ਪੈਚ।\n- retries ਨੂੰ ਸੋਚ-ਸਮਝ ਕੇ ਡਿਜ਼ਾਇਨ ਕਰੋ (ਬੈਕਆਫ ਅਤੇ ਸੀਮਾਵਾਂ ਨਾਲ) ਤਾਂ ਜੋ ਰਿਕਵਰੀ ਨੇ ਮੁਸੀਬਤ ਨੂੰ ਵਧਾਇਆ ਨਾ ਜਾਵੇ।
Ethernet ਨੇ ਵੰਡਿਤ ਕੰਪਿਊਟਿੰਗ ਨੂੰ ਸੰਭਵ ਬਣਾਇਆ; ਇਸ ਨੇ ਉਹ ਅਨੁਸ਼ਾਸਨ ਵੀ ਲਿਆਉਂਦਾ ਜੋ ਵੰਡਿਤ ਕੰਪਿਊਟਿੰਗ ਮੰਗਦਾ ਹੈ।
PARC 'ਤੇ, “ਸਰਵਿਸ” ਸਾਦਾ ਸ਼ਬਦਾਂ ਵਿੱਚ ਇੱਕ ਕੰਪਿਊਟਰ ਪ੍ਰੋਗਰਾਮ ਸੀ ਜੋ ਨੈੱਟਵਰਕ 'ਤੇ ਦੂਜਿਆਂ ਲਈ ਇੱਕ ਕੰਮ ਕਰਦਾ ਸੀ।
ਫਾਇਲ ਸਰਵਿਸ ਦਸਤਾਵੇਜ਼ ਸਟੋਰ ਅਤੇ ਵਾਪਸ ਕਰਦੀ। ਪ੍ਰਿੰਟ ਸਰਵਿਸ ਇੱਕ ਦਸਤਾਵੇਜ਼ ਲੈਂਦੀ ਅਤੇ ਕਾਗਜ਼ ਉਤਪਾਦ ਕਰਦੀ। ਡਾਇਰੈਕਟਰੀ (ਜਾਂ ਨਾਂਕਰਨ) ਸਰਵਿਸ ਤੁਹਾਨੂੰ ਸਹੀ ਫਾਇਲ ਸਰਵਰ, ਪ੍ਰਿੰਟਰ, ਜਾਂ ਵਿਅਕਤੀ ਲੱਭਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਬਿਨਾਂ ਮਸ਼ੀਨ ਦੇ ਵੇਰਵੇ ਯਾਦ ਕਰਨ ਦੀ ਲੋੜ ਦੇ। ਹਰ ਸਰਵਿਸ ਦਾ ਇੱਕ ਸਪਸ਼ਟ ਮਕਸਦ, ਪਰਿਭਾਸ਼ਿਤ ਇੰਟਰਫੇਸ, ਅਤੇ ਉਪਭੋਗਤਾ (ਲੋਕ ਜਾਂ ਹੋਰ ਪ੍ਰੋਗਰਾਮ) ਹੁੰਦੇ ਸਨ ਜੋ ਉਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਸਨ।
ਇੱਕ ਵੱਡੇ ਸਿਸਟਮ ਨੂੰ ਛੋਟੇ ਸਰਵਿਸਾਂ ਵਿੱਚ ਤੋੜਨਾ ਤਬਦੀਲੀ ਨੂੰ ਸੁਰੱਖਿਅਤ ਅਤੇ ਤੇਜ਼ ਬਣਾਂਦਾ ਹੈ। ਜੇ ਪ੍ਰਿੰਟਿੰਗ ਸਿਸਟਮ ਨੂੰ ਨਵੀਆਂ ਖੂਬੀਆਂ ਦੀ ਲੋੜ ਹੋਵੇ, ਤਾਂ ਇਹ ਫਾਇਲ ਸਟੋਰੇਜ ਨੂੰ ਦੁਬਾਰਾ ਡਿਜ਼ਾਇਨ ਕੀਤੇ ਬਿਨਾਂ ਵਿਕਸਤ ਹੋ ਸਕਦਾ ਹੈ। ਬਾਰਡਰੀਆਂ ਉਤੇਰੀ ਜਾਂਵਦੀਆਂ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਸਪਸ਼ਟ ਕਰਦੀਆਂ ਹਨ: “ਇੱਥੇ ਫਾਇਲਾਂ ਰਹਿੰਦੀਆਂ ਹਨ” ਬਨਾਮ “ਇੱਥੇ ਪ੍ਰਿੰਟਿੰਗ ਹੁੰਦੀ ਹੈ”।
ਇਸ ਦੇ ਨਾਲ ਨਾਲ, ਸਰਵਿਸਾਂ ਇੰਟਰਫੇਸ ਪਹਿਲਾਂ ਤਿਆਰ ਕਰਨ ਦੀ ਆਦਤ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦੀਆਂ ਹਨ। ਜਦੋਂ ਤੁਹਾਡਾ ਪ੍ਰੋਗਰਾਮ ਕਿਸੇ ਹੋਰ ਮਸ਼ੀਨ ਨਾਲ ਗੱਲ ਕਰਨਾ ਹੋਵੇ, ਤਾਂ ਤੁਸੀਂ ਇਨਪੁੱਟ, ਆਉਟਪੁੱਟ, ਅਤੇ ਐਰਰ—ਉਹ ਵਿਸਥਾਰ ਜੋ ਅਕਸਰ ਮੋਨੋਲੀਥ ਦੇ ਅੰਦਰ ਅਸਪਸ਼ਟ ਰਹਿ ਜਾਂਦੇ ਹਨ—ਨਿਰਧਾਰਤ ਕਰੋ।
ਜ਼ਿਆਦਾ ਸਰਵਿਸਾਂ ਦਾ ਮਤਲਬ ਹੋਰ ਨੈੱਟਵਰਕ ਬੇਨਤੀਆਂ ਹਨ। ਇਸ ਨਾਲ ਲੈਟੰਸੀ ਵੱਧ ਸਕਦੀ ਹੈ, ਲੋਡ ਵਧ ਸਕਦੀ ਹੈ, ਅਤੇ ਨਵੇਂ ਫੇਲਿਉਰ ਮੋਡ ਬਣ ਸਕਦੇ ਹਨ: ਫਾਇਲ ਸਰਵਿਸ ਚਲਦੀ ਹੋ ਸਕਦੀ ਹੈ ਪਰ ਪ੍ਰਿੰਟ ਸਰਵਿਸ ਡਾਊਨ, ਜਾਂ ਡਾਇਰੈਕਟਰੀ ਸਰਵਿਸ ਧੀਮੀ।
ਇੱਕ ਮੋਨੋਲੀਥ “ਇੱਕ ਵਾਰ ਟੁੱਟਦਾ” ਹੈ; ਵੰਡਿਤ ਸਰਵਿਸਾਂ ਅੰਸ਼ਿਕ, ਉਲਝਣ ਭਰੇ ਤਰੀਕੇ ਨਾਲ ਫੇਲ ਹੁੰਦੀਆਂ ਹਨ। ਠੀਕ ਟਿਕਾ ਇਹ ਨਹੀਂ ਕਿ ਸਰਵਿਸਾਂ ਨੂੰ ਟਾਲਿਆ ਜਾਵੇ—ਇਹ ਹੈ ਕਿ ਤਜਜੀਤਾ ਨਾਲ ਅੰਸ਼ਿਕ ਫੇਲਿਉਰ ਦੀ ਯੋਜਨਾ ਬਣਾਈ ਜਾਵੇ।
ਅੱਜ ਕਈ ਕਲਾਉਡ ਐਪ ਅੰਦਰੂਨੀ ਸਰਵਿਸਾਂ ਵਜੋਂ ਚਲਦੇ ਹਨ: ਯੂਜ਼ਰ ਅਕਾਉਂਟ, ਬਿਲਿੰਗ, ਸਰਚ, ਨੋਟੀਫਿਕੇਸ਼ਨ। PARC ਦਾ ਸਬਕ ਅਜੇ ਵੀ ਲਾਗੂ ਹੁੰਦਾ ਹੈ: ਸਪਲਿਟ ਕਰੋ ਤਾਂ ਕਿ ਸਪੱਸ਼ਟਤਾ ਅਤੇ ਸੁਤੰਤਰ ਵਿਕਾਸ ਹੋ ਸਕੇ—ਪਰ ਦਿਨ-ਪਹਿਲੇ ਹੀ ਨੈੱਟਵਰਕ ਦੇਰ ਅਤੇ ਅੰਸ਼ਿਕ ਆਉਟੇਜ ਲਈ ਯੋਜਨਾ ਬਣਾਓ।
ਵਾਹਿਕ ਰਾਹਦੇਸ਼ ਲਈ, ਟੀਮਾਂ ਅਕਸਰ ਸਰਵਿਸ ਬਾਰਡਰੀ ਨੂੰ ਬੇਸਿਕ ਟਾਈਮਆਉਟ, retries, ਅਤੇ ਸਾਫ਼ ਐਰਰ ਮੈਸੇਜਜ਼ ਨਾਲ ਜੋੜਦੀਆਂ ਹਨ (ਵੇਖੋ /blog/failure-is-normal)।
Remote Procedure Call (RPC) ਇੱਕ ਸਧਾਰਨ ਵਿਚਾਰ ਹੈ ਜਿਸ ਦਾ ਵੱਡਾ ਲਾਭ ਹੈ: ਦੂਜੇ ਮਸ਼ੀਨ 'ਤੇ ਫੰਕਸ਼ਨ ਨੂੰ ਉਸੇ ਤਰ੍ਹਾਂ ਕਾਲ ਕਰਨਾ ਜਿਵੇਂ ਇਹ ਲੋਕਲ ਹੋਵੇ। ਹੱਥ ਨਾਲ ਬੇਨਤੀ ਪੈਕੇਜ ਕਰਕੇ, ਨੈੱਟਵਰਕ 'ਤੇ ਭੇਜ ਕੇ, ਅਤੇ ਜਵਾਬ ਨੂੰ ਅਨਪੈਕ ਕਰਨ ਦੀ ਥਾਂ, RPC ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਆਖਦਾ ਹੈ “ਚਲਾਓ getUser(42)” ਅਤੇ ਸਿਸਟਮ ਪਿਛੋਕੜ ਵਿੱਚ ਮੈਸੇਜ ਪੈਸਿੰਗ ਨੂੰ ਸੰਭਾਲ ਲੈਂਦਾ ਹੈ।
ਇਹ “ਲੋਕਲ ਮਹਿਸੂਸ ਕਰਵਾਉਣਾ” ਲਕਸ਼ PARC ਦੇ ਵੰਡਿਤ ਕੰਪਿਊਟਿੰਗ ਕੰਮ ਦਾ ਕੇਂਦਰ ਸੀ—ਅਤੇ ਅੱਜ ਵੀ ਟੀਮਾਂ ਇਹੀ ਚਾਹੁੰਦੀਆਂ ਹਨ: ਸਪਸ਼ਟ ਇੰਟਰਫੇਸ, ਪੇਸ਼ਗੋਈਯੋਗ ਵਿਹਾਰ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਨੂੰ ਘੱਟ ਹਿੱਸੇ ਦਿਖਾਉਣਾ।
ਖ਼ਤਰਾ ਇਹ ਹੈ ਕਿ RPC ਬਹੁਤ ਜ਼ਿਆਦਾ ਇੱਕ ਆਮ ਫੰਕਸ਼ਨ ਕਾਲ ਵਾਂਗ ਲੱਗ ਸਕਦਾ ਹੈ। ਇੱਕ ਲੋਕਲ ਕਾਲ ਜਾਂ ਤਾਂ ਚੱਲਦਾ ਹੈ ਜਾਂ ਇਹ ਤੁਹਾਡੇ ਪ੍ਰੋਸੈਸ ਨੂੰ ਕਰੈਸ਼ ਕਰ ਦਿੰਦਾ ਹੈ; ਇੱਕ ਨੈੱਟਵਰਕ ਕਾਲ ਧੀਮਾ ਹੋ ਸਕਦਾ ਹੈ, ਗਾਇਬ ਹੋ ਸਕਦਾ ਹੈ, ਅੰਸ਼ਿਕ ਤਰੀਕੇ ਨਾਲ ਮੁਕੰਮਲ ਹੋ ਸਕਦਾ ਹੈ, ਜਾਂ ਸਫਲ ਹੋ ਸਕਦਾ ਹੈ ਬਿਨਾਂ ਤੁਹਾਡੇ ਨੂੰ ਸੰਦੇਸ਼ ਦਿੱਤੇ। ਚੰਗੇ RPC ਡਿਜ਼ਾਇਨ ਉਨ੍ਹਾਂ ਗੁਣਾਂ ਨੂੰ ਬੇਨਤੀ ਕਰਦੇ ਹਨ:\n\n- ਨਾਂਕਰਨ / ਸਰਵਿਸ ਖੋਜ: ਕਾਲ ਕਰਨ ਵਾਲੇ ਨੂੰ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕਿਹੜੀ ਮਸ਼ੀਨ ਜਾਂ ਸਰਵਿਸ ਇੰਸਟੈਂਸ ਕਾਲ ਨੂੰ ਹੈਂਡਲ ਕਰੇਗੀ। ਬਿਨਾਂ ਨਾਂਕਰਨ ਦੇ, RPC ਸਿਰਫ “ਪੈਕੇਟ ਭੇਜੋ ਅਤੇ ਆਸ਼ਾ ਕਰੋ” ਹੀ ਬਣ ਜਾਂਦਾ ਹੈ।\n- ਵਰਜ਼ਨਿੰਗ: ਕਲਾਇੰਟ ਅਤੇ ਸਰਵਰ ਵਿਕਸਤ ਹੁੰਦੇ ਹਨ। RPC ਇੰਟਰਫੇਸ ਨੂੰ ਖੇਤਰਾਂ ਜਾਂ ਮੈਥਡਾਂ ਨੂੰ ਇਨਕ੍ਰੀਮੈਂਟਲੀ ਜੋੜਨ ਦਾ ਤਰੀਕਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਕਿ ਪੁਰਾਣੇ ਕਲਾਇੰਟ ਟੁੱਟਣ ਨਾ ਜਾਣ।\n- ਟਾਈਮਆਉਟਸ: ਸਦਾ ਲਈ ਉਡੀਕਣਾ ਸ਼ਾਇਦ ਸਹੀ ਨੀ ਹੈ। ਟਾਈਮਆਉਟ “ਅਣਜਾਣ” ਨੂੰ ਕਾਰਵਾਈਯੋਗ ਨਤੀਜੇ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।\n- ਐਰਰ ਹੈਂਡਲਿੰਗ: RPC ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਐਰਰ ਮਾਡਲ ਚਾਹੀਦਾ ਹੈ (ਟ੍ਰਾਂਸਪੋਰਟ ਐਰਰ, ਸਰਵਰ ਐਰਰ, ਅਧਿਕਾਰ ਅਸਫਲਤਾ) ਤਾਂ ਜੋ ਕਾਲ ਕਰਨ ਵਾਲੇ ਨਿਰਣਾ ਲੈ ਸਕਣ ਕਿ ਕੀ retry ਕਰਨਾ ਹੈ, ਕੀ ਯੂਜ਼ਰ ਨੂੰ ਦਿਖਾਉਣਾ ਹੈ, ਅਤੇ ਕੀ ਅਲਾਰਮ ਕਰਨਾ ਹੈ।
ਟਾਈਮਆਉਟਸ ਅਤੇ ਡ੍ਰਾਪ ਕੀਤੀਆਂ ਪ੍ਰਤਿਕ੍ਰਿਆਵਾਂ retries ਲਾਜ਼ਮੀ ਬਣਾਈਆਂ ਹਨ। ਇਸੀ ਲਈ idempotency ਮਹੱਤਵਪੂਰਨ ਹੈ: ਇੱਕ ਓਪਰੇਸ਼ਨ idempotent ਹੈ ਜੇ ਇਕ ਵਾਰੀ ਜਾਂ ਕਈ ਵਾਰੀ ਕਰਨ ਨਾਲ ਇੱਕੋ ਪ੍ਰਭਾਵ ਹੁੰਦਾ ਹੈ।
ਸਧਾਰਨ ਉਦਾਹਰਨ: chargeCreditCard(orderId, amount) ਮੂਲ ਤੌਰ 'ਤੇ idempotent ਨਹੀਂ ਹੁੰਦੀ—ਟਾਈਮਆਉਟ ਤੋਂ ਬਾਅਦ retry ਕਰਨ ਨਾਲ ਦੋ ਵਾਰੀ ਚਾਰਜ ਹੋ ਸਕਦਾ ਹੈ। ਇੱਕ ਸੁਰੱਖਿਅਤ ਡਿਜ਼ਾਇਨ chargeCreditCard(orderId) ਹੋ ਸਕਦਾ ਹੈ ਜਿੱਥੇ orderId ਚਾਰਜ ਨੂੰ ਵਿਲੱਖਣ ਪਛਾਣਦਾ ਹੈ, ਅਤੇ ਸਰਵਰ ਦੁਹਰਾਵਾਂ ਨੂੰ “ਪਹਿਲਾਂ ਹੀ ਹੋ ਚੁੱਕਿਆ” ਵਜੋਂ ਨਿਭਾਉਂਦਾ ਹੈ। ਇਸ ਤਰੀਕੇ ਨਾਲ retry ਸੁਰੱਖਿਅਤ ਬਣ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਸਰਵਰ ਡਿਡੁਪਲੀਕੇਸ਼ਨ ਕਰ ਸਕਦਾ ਹੈ।
ਆਧੁਨਿਕ APIs RPC ਮਨੋਭਾਵ ਦੇ ਸਿੱਧੇ ਉਤਰਾਧਿਕਾਰੀ ਹਨ। gRPC “ਰਿਮੋਟ ਮੈਥਡ ਕਾਲ” ਮਾਡਲ ਨੂੰ ਟਾਈਪ ਕੀਤੀਆਂ ਇੰਟਰਫੇਸਾਂ ਅਤੇ ਟਾਈਪਡ ਮੈਸੇਜ ਨਾਲ ਸਪੱਸ਼ਟ ਬਣਾਉਂਦਾ ਹੈ। REST ਅਕਸਰ ਮੈਥਡ-ਵਿਰੋਧੀ ਦੀ ਥਾਂ ਰਿਸੋਰਸ-ਕੇਂਦਰਤ ਨਜ਼ਰੀਆ ਰੱਖਦਾ ਹੈ, ਪਰ ਲਕਸ਼ ਇੱਕੋ ਹੈ: ਸਰਵਿਸਾਂ ਦੇ ਬੀਚ ਗੱਲ-ਬਾਤ ਨੂੰ ਮਿਆਰੀਕ੍ਰਿਤ ਕਰੋ, ठੀਕ ਬੰਧਨ define ਕਰੋ, ਅਤੇ ਫੇਲਿਉਰ ਨੂੰ ਮੈਨੇਜ ਕਰੋ।
ਜਿਹੇ ਭੀ ਅੰਦਾਜ਼ ਹੋਵੇ, PARC ਦਾ ਸਬਕ ਕਾਇਮ ਹੈ: ਨੈੱਟਵਰਕ ਇੱਕ ਟੂਲ ਹੈ, ਇੱਕ ਵਿਸਥਾਰ ਯੋਗ ਤਫ਼ਸੀਲ ਨਹੀਂ। ਚੰਗਾ RPC ਵੰਡਨ ਨੂੰ ਸੁਵਿਧਾਜਨਕ ਬਣਾਉਂਦਾ—ਬਿਨਾਂ ਇਹ ਦਿਖਾਏ ਕਿ ਇਹ ਮੁਫ਼ਤ ਹੈ।
ਇੱਕ ਵੰਡਿਤ ਸਿਸਟਮ ਤਦ ਹੀ “ਵੰਡਿਤ” ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕੁਝ ਟੁੱਟਦਾ ਹੈ। ਬਹੁਤੇ ਦਿਨ, ਇਹ ਇਸ ਲਈ ਟੁੱਟਿਆ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਕੁਝ ਲੱਭਿਆ ਨਹੀਂ ਜਾਂਦਾ।
ਨਾਂਕਰਨ ਮੁਸ਼ਕਲ ਹੈ ਕਿਉਂਕਿ ਅਸਲ ਦੁਨੀਆ ਸਥਿਰ ਨਹੀਂ ਰਹਿੰਦੀ: ਮਸ਼ੀਨਾਂ ਬਦਲੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਸਰਵਿਸਾਂ ਨਵੇਂ ਹੋਸਟਾਂ 'ਤੇ ਸਪਟਧਾਰਤ ਹੁੰਦੀਆਂ ਹਨ, ਨੈੱਟਵਰਕ ਨੰਬਰਿੰਗ ਪਰਿਵਰਤਿਤ ਹੋ ਸਕਦੀ ਹੈ, ਅਤੇ ਲੋਕ ਫਿਰ ਵੀ “ਫਾਇਲ ਸਰਵਰ” ਜਾਂ “LaserWriter 'ਤੇ ਪ੍ਰਿੰਟ” ਵਰਗੇ ਸਥਿਰ ਅਤੇ ਯਾਦਗਾਰ ਮਾਰਗਾਂ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹਨ। ਜੇ ਨਾਮ ਤੁਸੀਂ ਟਾਈਪ ਕਰਦੇ ਹੋ ਉਹੀ ਸਥਿਤੀ ਵੀ ਹੋਵੇ, ਹਰ ਤਬਦੀਲੀ ਉਪਭੋਗਤਾ-ਦਿੱਖ ਵਾਲੀ ਰੁਕਾਵਟ ਬਣ ਜਾਂਦੀ ਹੈ।
PARC ਯੁੱਗ ਤੋਂ ਇੱਕ ਮੁੱਖ ਵਿਚਾਰ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਜੋ ਚਾਹੁੰਦੇ ਹੋ ਅਤੇ ਉਹ ਇਸ ਵੇਲੇ ਕਿੱਥੇ ਰਹਿੰਦਾ ਹੈ ਨੂੰ ਵੱਖਰਾ ਕਰੋ। ਇੱਕ ਨਾਂ ਸਥਿਰ ਅਤੇ ਅਰਥਪੂਰਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ; ਇੱਕ ਲੋਕੇਸ਼ਨ ਇੱਕ ਕਾਰਜਨੁਸ਼ੀ ਦਫਤਰ ਜੋ ਬਦਲ ਸਕਦਾ ਹੈ।
ਜਦੋਂ ਇਹ ਦੋਹਾਂ ਇੱਕਠੇ ਹੋ ਜਾਂਦੇ ਹਨ, ਤੁਸੀਂ ਨਾਜੁਕ ਸਿਸਟਮ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ: শরਟਕੱਟ, ਹਾਰਡ-ਕੋਡ ਕੀਤੇ IP, ਅਤੇ ਕਾਂਫਿਗਿ੍ਰੇਸ਼ਨ ਡ੍ਰਿਫਟ।
ਡਾਇਰੈਕਟਰੀ ਸਰਵਿਸਾਂ ਸਵਾਲ “X ਹੁਣ ਕਿੱਥੇ ਹੈ?” ਦਾ ਜਵਾਬ ਦੇਂਦੀਆਂ ਹਨ ਨਾਂ ਨੂੰ ਲੋਕੇਸ਼ਨਾਂ ਨਾਲ ਮੈਪ ਕਰਕੇ (ਅਕਸਰ ਕਿਸਮ, ਮਾਲਕ ਜਾਂ ਐਕਸੈਸ ਨਿਯਮਾਂ ਵਰਗਾ ਮੈਟਾਡੇਟਾ ਵੀ)। ਸਭ ਤੋਂ ਵਧੀਆ ਡਾਇਰੈਕਟਰੀਜ਼ ਸਿਰਫ ਲੁੱਕਅੱਪ ਸਟੋਰ ਨਹੀਂ ਕਰਦੀਆਂ—ਉਹ ਕਿਵੇਂ ਇੱਕ ਸੰਸਥਾ ਕੰਮ ਕਰਦੀ ਹੈ ਇਹ ਵੀ ਐਨਕੋਡ ਕਰਦੀਆਂ ਹਨ।
ਚੰਗੇ ਨਾਂਕਰਨ ਅਤੇ ਡਾਇਰੈਕਟਰੀ ਡਿਜ਼ਾਇਨ ਆਮ ਤੌਰ 'ਤੇ ਕੁਝ ਪ੍ਰਭਾਵਸ਼ੀਲ ਗੁਣ ਰੱਖਦੇ ਹਨ:\n\n- ਸਥਿਰਤਾ: ਨਾਮ ਹਾਰਡਵੇਅਰ ਰੀਫ੍ਰੈਸ਼ ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਨੂੰ ਬਰਦਾਸ਼ਤ ਕਰਨ।\n- ਡੇਲੀਗੇਸ਼ਨ: ਟੀਮਾਂ ਆਪਣੀਆਂ ਸਬ-ਟ੍ਰੀਜ਼ ਨੂੰ ਕੇਂਦਰੀ ਬਾਟਲਨੇਕ ਦੇ ਬਿਨਾਂ ਪ੍ਰਬੰਧ ਕਰ ਸਕਣ।\n- ਕੈਸ਼ਿੰਗ: ਗਾਹਕ ਜਵਾਬਾਂ ਰੱਖਦੇ ਹਨ ਤਾਂ ਜੋ ਲਗਾਤਾਰ ਰਾਊਂਡ-ਟ੍ਰਿਪ ਨਾ ਹੋਵੇ।\n- ਅਪਡੇਟਸ ਅਤੇ ਤਾਜ਼ਗੀ: ਤਬਦੀਲੀਆਂ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਫੈਲਦੀਆਂ ਹਨ, ਕੈਸ਼ਾਂ ਸਾਨੂੰ ਕਿੰਨਾ ਸਮਾਂ ਪੁਰਾਣਾ ਜ਼ਰੂਰ ਮਨਣਾ ਚਾਹੀਦਾ ਹੈ ਇਸ ਲਈ ਸਪਸ਼ਟ ਨਿਯਮ ਹਨ।
DNS ਕਲਾਸਿਕ ਉਦਾਹਰਨ ਹੈ: ਇੱਕ ਮਨੁੱਖ-ਮਿਤ੍ਰ ਨਾਮ ਇੱਕ ਬਦਲਦੇ IP ਸਮੂਹ ਨੂੰ ਮੈਪ ਕਰਦਾ ਹੈ, ਕੈਸ਼ਿੰਗ TTLs ਨਾਲ ਨਿਯੰਤਰਿਤ ਹੁੰਦੀ ਹੈ।
ਕੰਪਨੀਆਂ ਦੇ ਅੰਦਰ, ਸਰਵਿਸ ਖੋਜ ਪ੍ਰਣਾਲੀਆਂ (ਜਿਵੇਂ “service-a.prod” ਦੇ ਪਿੱਛੇ) ਇੱਕੋ ਰੂਪ ਨੂੰ ਦੁਹਰਾਉਂਦੀਆਂ ਹਨ: ਸਥਿਰ ਸੇਵਾ ਨਾਮ, ਬਦਲਦੇ ਇੰਸਟੈਂਸ, ਅਤੇ ਕੈਸ਼ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਅਪਡੇਟ ਰਫਤਾਰ ਵਿਚ ਲਗਾਤਾਰ ਤਣਾਅ।
ਸਬਕ ਸਧਾਰਣ ਹੈ: ਜੇ ਤੁਸੀਂ ਸਿਸਟਮ ਨੂੰ ਸਕੇਲ ਤੇ ਚਾਹੁੰਦੇ ਹੋ—ਅਤੇ ਇਹ ਸਮਝਣਯੋਗ ਰਹਿਣਾ ਚਾਹੁੰਦੇ ਹੋ—ਤਾਂ ਨਾਂਕਰਨ ਨੂੰ ਪਹਿਲੀ-ਕਲਾਸ ਡਿਜ਼ਾਇਨ ਸਮੱਸਿਆ ਵਜੋਂ ਲ treatੋ, ਨਾ ਕਿ ਪਿੱਛੋਂ ਸੋਚਣ ਵਾਲੀ ਚੀਜ਼ ਵਜੋਂ।
ਕੈਸ਼ਿੰਗ ਇੱਕ ਸਧਾਰਨ ਆਈਡੀਆ ਹੈ: ਕੁਝ ਜਿਸਨੂੰ ਤੁਸੀਂ ਪਹਿਲਾਂ ਲਿਆ ਸੀ ਉਸਦੀ ਨੇੜੇ ਨਕਲ ਰੱਖੋ ਤਾਂ ਜੋ ਅਗਲੀ ਬੇਨਤੀ ਤੇਜ਼ ਹੋ ਜਾਵੇ। ਹਰ ਵਾਰੀ ਨੈੱਟਵਰਕ ਨੂੰ ਪਾਰ ਕਰਨ ਜਾਂ ਧੀਮੀ ਡਿਸਕ/ਬਿਜ਼ੀ ਸਰਵਰ ਨੂੰ ਹਿੱਟ ਕਰਨ ਦੇ ਬਜਾਏ, ਤੁਸੀਂ ਲੋਕਲ ਕਾਪੀ ਨੂੰ ਦੁਬਾਰਾ ਵਰਤਦੇ ਹੋ।
PARC 'ਚ ਇਹ ਇਸ ਲਈ ਮਹੱਤਵਪੂਰਨ ਸੀ ਕਿਉਂਕਿ ਨੈੱਟਵਰਕਡ ਵਰਕਸਟੇਸ਼ਨ ਅਤੇ ਸਾਂਝੇ ਸਰਵਿਸਾਂ ਨੇ “ਸਰਵਰ ਨੂੰ ਦੁਬਾਰਾ ਪੁੱਛੋ” ਨੂੰ ਮਹਿੰਗੀ ਆਦਤ ਬਣਾਇਆ। ਕੈਸ਼ਿੰਗ ਨੇ ਰਿਮੋਟ ਸਰੋਤਾਂ ਨੂੰ ਅਕਸਰ ਤੇਜ਼ ਮਹਿਸੂਸ ਕਰਵਾਇਆ—ਜ਼ਿਆਦਾਤਰ ਸਮਾਂ।
ਫੇਸਲਾ ਇਹ ਹੈ ਕਿ ਤਾਜ਼ਗੀ। ਇੱਕ ਕੈਸ਼ ਗਲਤ ਹੋ ਸਕਦੀ ਹੈ।
ਕਲਿਆਪਣ ਕਰੋ ਕਿ ਇੱਕ ਸਾਂਝਾ ਦਸਤਾਵੇਜ਼ ਸਰਵਰ 'ਤੇ ਸਟੋਰ ਹੈ। ਤੁਹਾਡੀ ਵਰਕਸਟੇਸ਼ਨ ਫਾਇਲ ਨੂੰ ਕੈਸ਼ ਕਰਦੀ ਹੈ ਤਾਂ ਜੋ ਇਹ ਤੁਰੰਤ ਖੁਲੇ। ਇੱਕ ਸਾਥੀ ਉਹੀ ਦਸਤਾਵੇਜ਼ ਸੰਪਾਦਨ ਕਰਦਾ ਅਤੇ ਨਵਾਂ ਵਰਜ਼ਨ ਸੇਵ ਕਰਦਾ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਕੈਸ਼ ਧਿਆਨ ਨਾ ਦੇਵੇ, ਤਾਂ ਤੁਸੀਂ ਪੁਰਾਣੀ ਸਮੱਗਰੀ ਦੇਖਦੇ ਰਹੋਗੇ—ਜਾਂ ਹੋਰ ਭਿਆਨਕ, ਪੁਰਾਣੀ ਕਾਪੀ ਨੂੰ ਸੰਪਾਦਨ ਕਰਕੇ ਨਵੀਂ ਕਾਰਵਾਈ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰ ਸਕਦੇ ਹੋ।
ਇਸ ਲਈ ਹਰ ਕੈਸ਼ ਡਿਜ਼ਾਇਨ ਇੱਕ ਟਰੇਡਆਫ ਦੇ ਵਿਚਕਾਰ ਹੈ:\n\n- ਪਰਫਾਰਮੈਂਸ: ਘੱਟ ਨੈੱਟਵਰਕ ਯਾਤਰਾ, ਤੇਜ਼ ਜਵਾਬ\n- ਕਨਸਿਸਟੈਂਸੀ: ਸਟੇਲ ਡੇਟਾ ਅਤੇ ਹੈਰਾਨ ਕਰਨ ਵਾਲੇ ਵਿਹਾਰ ਤੋਂ ਬਚਣਾ
ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਇਸ ਟਰੇਡਆਫ ਨੂੰ ਕੁਝ ਵਿਆਪਕ ਔਜ਼ਾਰਾਂ ਨਾਲ ਦਬਾਉਂਦੀਆਂ ਹਨ:\n\n- TTLs (time-to-live): ਕੈਸ਼ ਕੀਤਾ ਡੇਟਾ ਇੱਕ ਨਿਰਧਾਰਤ ਸਮੇਂ ਤੋਂ ਬਾਅਦ ਮਿਆਦ ਨੂੰ ਪੂਰਾ ਕਰ ਲੈਂਦਾ ਹੈ, ਫਿਰ ਤਾਜ਼ਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।\n- ਇਨਵੈਲਿਡੇਸ਼ਨ: ਜਦੋਂ ਡੇਟਾ ਬਦਲਦਾ ਹੈ, ਸਿਸਟਮ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ ਕਿ ਕੈਸ਼ਾਂ ਨੂੰ ਨਿਕਲ ਦਿਤਾ ਜਾਵੇ ਜਾਂ ਅਪਡੇਟ ਕੀਤਾ ਜਾਵੇ।\n- ਲੀਜ਼: ਇੱਕ ਕੈਸ਼ ਨੂੰ ਇੱਕ ਛੋਟੀ ਦਿੱਤੀ ਹੋਈ ਅਵਧੀ ਲਈ “ਵੈਧ” ਰੱਖਣ ਦੀ ਆਗਿਆ ਮਿਲਦੀ ਹੈ; ਉਸ ਤੋਂ ਬਾਅਦ ਇਸ ਨੂੰ ਨਵੀਨੀਕਰਨ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।
ਆਧੁਨਿਕ ਸਿਸਟਮ ਉਹੀ ਪੈਟਰਨ ਹਰ ਜਗ੍ਹਾ ਵਰਤਦੇ ਹਨ: CDNs ਵੈੱਬ ਸਮੱਗਰੀ ਨੂੰ ਯੂਜ਼ਰਾਂ ਦੇ ਨੇੜੇ ਕੈਸ਼ ਕਰਦੇ ਹਨ, ਬ੍ਰਾਊਜ਼ਰ ਅਤੇ ਮੋਬਾਈਲ ਐਪ ਐਸੈਟਸ ਅਤੇ API ਜਵਾਬ ਕੈਸ਼ ਕਰਦੇ ਹਨ, ਅਤੇ ਡੇਟਾਬੇਸ ਕ캐ਸ਼ ਲੇਅਰ (ਜਿਵੇਂ Redis ਜਾਂ Memcached) ਪ੍ਰਾਇਮਰੀ ਸਟੋਰ 'ਤੇ ਲੋਡ ਘਟਾਉਂਦੇ ਹਨ।
ਜੋ ਸਬਕ ਅਜੇ ਵੀ ਲਾਗੂ ਹੁੰਦਾ ਹੈ: ਕੈਸ਼ਿੰਗ ਅਕਸਰ ਸਭ ਤੋਂ ਸਸਤਾ ਪ੍ਰਦਰਸ਼ਨ ਜਿੱਤ ਹੈ—ਪਰ ਸਿਰਫ ਜੇ ਤੁਸੀਂ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਇਹ ਲਿਖਦੇ ਹੋ ਕਿ “ਕਿੰਨਾ ਤਾਜ਼ਾ ਕਾਫ਼ੀ ਹੈ” ਤੁਹਾਡੇ ਉਤਪਾਦ ਲਈ।
ਸਕੇਲ 'ਤੇ ਸੁਰੱਖਿਆ ਸਿਰਫ “ਤੁਸੀਂ ਕੌਣ ਹੋ?” ਨਹੀਂ—ਇਹ ਵੀ ਹੈ “ਤੁਸੀਂ ਇਸ ਖਾਸ ਸਰੋਤ ਨਾਲ ਹੁਣ ਕੀ ਕਰ ਸਕਦੇ ਹੋ?” Lampson ਅਤੇ Xerox PARC ਪਰੰਪਰਾ ਨੇ ਇਸ ਲਈ ਇੱਕ ਬਹੁਤ ਪ੍ਰਯੋਗਿਕ ਵਿਚਾਰ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕੀਤਾ: capabilities।
ਇੱਕ capability ਇੱਕ ਅਣ-ਫਰਜੀ ਟੋਕਨ ਹੁੰਦਾ ਹੈ ਜੋ ਕਿਸੇ ਚੀਜ਼—ਜਿਵੇਂ ਫਾਇਲ, ਪ੍ਰਿੰਟਰ, ਮੇਲਬਾਕਸ ਜਾਂ ਸਰਵਿਸ ਕਾਰਵਾਈ—ਤਕ ਪਹੁੰਚ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਉਹ ਟੋਕਨ ਰੱਖਦੇ ਹੋ, ਤੁਹਾਨੂੰ ਆਗਿਆ ਹੈ; ਜੇ ਨਹੀਂ, ਤਾਂ ਨਹੀਂ।
ਕੰਮ ਦੀ ਕੁੰਜੀ ਹੈ ਅਣ-ਫਰਜੀ: ਸਿਸਟਮ ਇਸਨੂੰ ਅਜਿਹਾ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਇੱਕ ਮਾਨਤਾ-ਨਵੀਨ ਟੋਕਨ ਨਕਲ ਕਰਕੇ ਬਣਾਉਣਾ ਸੰਭਵ ਨਾ ਹੋਵੇ।
ਇਸ ਨੂੰ ਇੱਕ ਹੋਟਲ ਦੀ ਕੀ-ਕਾਰਡ ਵਾਂਗ ਸੋਚੋ ਜੋ ਕੇਵਲ ਤੁਹਰੇ ਕਮਰੇ ਨੂੰ (ਅਤੇ ਸਿਰਫ਼ ਤੁਹਾਡੇ ਰਹਿਣ ਸਮੇਂ) ਖੋਲ੍ਹਦੀ ਹੈ—ਕਿਸੇ ਲਿਖਤੀ ਨੋਟ ਵਾਂਗ ਨਹੀਂ ਜੋ ਕਹਿੰਦੇ “ਮੈਂ ਅੰਦਰ ਆ ਸਕਦਾ ਹਾਂ”।
ਬਹੁਤ ਸਾਰੇ ਸਿਸਟਮ ਪਛਾਣ-ਆਧਾਰਤ ਸੁਰੱਖਿਆ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ: ਤੁਸੀਂ ਇੱਕ ਉਪਭੋਗੀ ਵਜੋਂ ਪ੍ਰਮਾਣਿਕ ਹੋ, ਅਤੇ ਫਿਰ ਹਰ ਪਹੁੰਚ ਨੂੰ ਇੱਕ ACL (Access Control List) ਦੇ ਖ਼ਿਲਾਫ਼ ਚੈੱਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ—ਏਕ ਸੂਚੀ ਜੋ ਸਰੋਤ 'ਤੇ ਦੱਸਦੀ ਹੈ ਕਿ ਕਿਸ ਉਪਭੋਗੀ/ਗਰੁੱਪ ਨੂੰ ਕੀ ਕਰਨ ਦੀ ਆਗਿਆ ਹੈ।
ACL ਮਾਨਸਿਕ ਤੌਰ 'ਤੇ ਸਮਝ ਆਉਂਦੇ ਹਨ, ਪਰ ਵੰਡਿਤ ਸਿਸਟਮਾਂ ਵਿੱਚ ਇਹ ਬੇਸੋਲ ਹੋ ਸਕਦੇ ਹਨ:\n\n- ਹਰ ਸਰਵਿਸ ਨੂੰ ਤੁਹਾਡੀ ਪਛਾਣ ਨੂੰ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਜਾਣਨਾ ਹੀ ਪੈਂਦਾ ਹੈ।\n- ਹਰ ਸਰੋਤ ਨੂੰ ਪਰਮਿਸ਼ਨਾਂ ਦੀ ਸੂਚੀ ਸੰਭਾਲਣ ਅਤੇ ਨਵੀਨਿਕਰਨ ਕਰਨੀ ਪੈਂਦੀ ਹੈ।\n- ਅਧਿਕਾਰ ਦੇਣ (“ਇਸ ਨੌਕਰੀ ਨੂੰ 10 ਮਿੰਟ ਲਈ ਇੱਕ ਫਾਇਲ ਪੜ੍ਹਨ ਦਿਓ”) ਅਕਸਰ ਖਾਸ-ਕੇਸ ਲਾਜ਼ਮੀ ਲਾਜ਼ਮੀਤਾ ਬਣ ਜਾਂਦੀ ਹੈ।
Capabilities ਮੁੱਲ-ਮੰਤਲ ਨੂੰ ਉਲਟ ਦਿੰਦੇ ਹਨ। ਕੇਂਦਰੀ ਪ੍ਰाधिकਰਣ ਨੂੰ ਨਿਰੰਤਰ ਪੁੱਛਣ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਇੱਕ ਟੋਕਨ ਪੇਸ਼ ਕਰਦੇ ਹੋ ਜੋ ਪਹਿਲਾਂ ਹੀ ਅਧਿਕਾਰ ਨੂੰ ਐਨਕੋਡ ਕਰਦਾ ਹੈ।
ਵੰਡਿਤ ਸਿਸਟਮ ਮੁਕਤ ਤੌਰ 'ਤੇ ਮਸ਼ੀਨ-ਚੁੱਕਾਂ ਨੂੰ ਕੰਮ ਭੇਜਦੇ ਹਨ: ਫਰੰਟਐਂਡ ਇੱਕ ਬੈਕਐਂਡ ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ; ਇੱਕ ਸ਼ਡਿਊਲਰ ਕੰਮ ਨੂੰ ਇੱਕ ਵਰਕਰ ਨੂੰ ਦੇਂਦਾ ਹੈ; ਇੱਕ ਸਰਵਿਸ ਦੂਜੇ ਸਰਵਿਸ ਨੂੰ ਟ੍ਰਿਗਰ ਕਰਦੀ ਹੈ। ਹਰ ਹੌਪ ਨੂੰ ਇੱਕ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਕੁਝ ਹੀ ਅਧਿਕਾਰ ਲਿਜਾਣੀ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ।
Capabilities ਇਸਨੂੰ ਕੁਦਰਤੀ ਬਣਾਉਂਦੀਆਂ ਹਨ: ਤੁਸੀਂ ਇੱਕ ਬੇਨਤੀ ਨਾਲ ਟੋਕਨ ਪਾਸ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੀ ਮਸ਼ੀਨ ਇਸਨੂੰ ਵੈਰੀਫਾਈ ਕਰ ਸਕਦੀ ਹੈ ਬਿਨਾਂ ਹਰ ਵਾਰੀ ਵਿਸ਼ਵਾਸ ਨਵਾਂ ਬਣਾਉਂਦੇ।
ਇਹ ਚੰਗੇ ਤਰੀਕੇ ਨਾਲ ਕੀਤਾ ਗਿਆ ਤਾਂ, ਇਹ ਅਗੰਭੀ ਅਧਿਕਾਰ ਦੀ ਘੱਟੀ ਅਤੇ ਘਟਿਆ ਪ੍ਰਭਾਵ ਦਾਇਰਾ ਘਟਾਉਂਦਾ ਹੈ ਜਦੋਂ ਕੁਝ ਗਲਤ ਹੁੰਦਾ ਹੈ।
Capabilities ਅੱਜ ਇਹਨਾਂ ਰੂਪਾਂ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ:\n\n- ਸਾਈਨ ਕੀਤੇ ਟੋਕਨ (ਉਦਾਹਰਨ ਲਈ JWTs) ਜੋ ਸਬੂਤ ਦਿੰਦੇ ਹਨ ਕਿ ਇੱਕ ਬੇਨਤੀ ਵਿਚ ਖਾਸ ਦਾਅਵੇ ਹਨ।\n- ਸਕੋਪਡ ਪ੍ਰਮਾਣਪੱਤਰ (OAuth ਐਕਸੈਸ ਟੋਕਨ, ਕਲਾਉਡ “ਸੈਸ਼ਨ ਟੋਕਨ”) ਜੋ ਮਿਆਦ ਰੱਖਦੇ ਅਤੇ ਕਾਰਵਾਈਆਂ ਸੀਮਿਤ ਕਰਦੇ ਹਨ।\n- ਛੋਟੇ-ਅਧਿਕਾਰ ਸਰਵਿਸ identities (workload identity, service accounts) ਜਿੱਥੇ ਕ੍ਰੈਡੈਂਸ਼ਲਜ਼ ਨਿਰਧਾਰਤ ਤੌਰ 'ਤੇ ਸੰਕੋਚਿਤ ਹੁੰਦੇ ਹਨ।\n\nਸਬਕ ਸਧਾਰਣ ਹੈ: ਡੇਲੀਗੇਸ਼ਨ, ਸਕੋਪ, ਅਤੇ ਮਿਆਦ ਦੇ ਆਧਾਰ 'ਤੇ ਅਧਿਕਾਰ ਡਿਜ਼ਾਇਨ ਕਰੋ—ਕੇਵਲ ਲੰਬੇ ਸਮੇਂ ਵਾਲੀ ਪਛਾਣ 'ਤੇ ਨਹੀਂ।
ਵੰਡਿਤ ਸਿਸਟਮ ਇੱਕ ਸਾਫ਼ “ਟੁੱਟ” ਹੋਣ ਦੇ ਤਰੀਕੇ ਨਾਲ ਨਹੀਂ ਟੁੱਟਦੇ। ਉਹ ਗੁੰਝਲਦਾਰ, ਅੰਸ਼ਿਕ ਤਰੀਕੇ ਨਾਲ ਫੇਲ ਹੁੰਦੇ ਹਨ: ਇੱਕ ਮਸ਼ੀਨ ਮਿਡ-ਟਾਸਕ 'ਤੇ ਕਰੈਸ਼ ਹੋ ਸਕਦੀ ਹੈ, ਇੱਕ ਸਵਿੱਚ ਰੀਬੂਟ ਹੋ ਸਕਦਾ ਹੈ, ਨੈੱਟਵਰਕ ਲਿੰਕ ਪੈਕਟ ਗੁਆ ਸਕਦੀ ਹੈ, ਜਾਂ ਇੱਕ ਪਾਵਰ ਇਵੈਂਟ ਇੱਕ ਰੈਕ ਨੂੰ ਲੈ ਕੇ ਚਲਾ ਸਕਦਾ ਹੈ ਪਰ ਬਾਕੀ ਨੂੰ ਨਹੀਂ।
ਉਪਭੋਗਤਾ ਦੇ ਨਜ਼ਰੀਏ ਤੋਂ, ਸਰਵਿਸ “ਅੱਪ” ਹੈ, ਫਿਰ ਵੀ ਇੱਕ ਟੁਕੜਾ ਇਸਲਈ ਅਪਹੁੰਚਯੋਗ ਹੋ ਸਕਦਾ ਹੈ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਫੇਲਿਉਰ ਮਾਡਲ ਸਪੱਸ਼ਟ ਹੈ:\n\n- ਪ੍ਰਣਾਲੀ ਦੇ ਪ੍ਰੋਸੈਸ ਕਰੈਸ਼ ਹੋ ਸਕਦੇ ਹਨ ਅਤੇ in-memory ਸਟੇਟ ਗਵਾ ਸਕਦੇ ਹਨ।\n- ਮਸ਼ੀਨ ਬਿਨਾਂ ਚੇਤਾਵਨੀ ਦੇ ਰੀਬੂਟ ਹੋ ਸਕਦੀ ਹੈ।\n- ਨੈੱਟਵਰਕ ਵੰਡ (two groups can't talk), ਧੀਰਾ ਹੋਣਾ, ਜਾਂ ਸੁਨੇਹਿਆਂ ਦਾ ਅਨੁਕ੍ਰਮ ਠੀਕ ਨਾ ਰਹਿਣਾ ਆਮ ਹੈ।\n- ਸਮਾਂ ਅਣਨਿਸ਼ਚਿਤ ਹੈ: ਇੱਕ ਬੇਨਤੀ ਧੀਮੀ ਹੋ ਸਕਦੀ ਹੈ ਨਾ ਕਿ ਗੁਆਈ ਹੋਈ।
ਇਹ ਸਵੀਕਾਰ ਕਰ ਲੈਣ 'ਤੇ, ਤੁਸੀਂ ਐਰਰਾਂ ਨੂੰ “ਐਡਜ ਕੇਸ” ਸਮਝ ਕੇ ਨਹੀਂ ਤਬਦੀਲ ਕਰਦੇ—ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਸਧਾਰਨ ਕੰਟਰੋਲ ਫਲੋ ਵਜੋਂ ਸਵੀਕਾਰ ਕਰਦੇ ਹੋ।
ਜ਼ਿਆਦਾਤਰ ਸਿਸਟਮ ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਹਲ-ਕਿੱਤੇ ਉਪਾਇਆ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ।
ਟਾਈਮਆਉਟਸ ਕਾਲ ਕਰਨ ਵਾਲਿਆਂ ਨੂੰ ਹਮੇਸ਼ਾਂ ਲਈ ਉਡੀਕਣ ਤੋਂ ਰੋਕਦੇ ਹਨ। ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਟਾਈਮਆਉਟਸ ਨੂੰ ਅਸਲੀ ਲੇਟੰਸੀ ਡੇਟਾ ਅਧਾਰ 'ਤੇ ਚੁਣੋ, ਫਿਕਸ ਅੰਦਾਜ਼ੇ 'ਤੇ ਨਹੀਂ।
Retries ਟਰਾਂਜ਼ੀਐਂਟ ਫੋਲਟਸ ਤੋਂ ਬਚ ਦੇ ਸਕਦੇ ਹਨ, ਪਰ ਓਹਨਾਂ ਨੇ ਆਉਟੇਜ ਦੌਰਾਨ ਲੋਡ ਨੂੰ ਵੀ ਵਧਾ ਸਕਦਾ ਹੈ। ਇਸੀ ਲਈ exponential backoff (ਹਰ retry ਨਾਲ ਥੋੜ੍ਹਾ ਹੋਰ ਉਡੀਕ) ਅਤੇ jitter (ਬੇਤੁਕਾ ਵਿਵਰਨ) ਮਹੱਤਵਪੂਰਨ ਹਨ: ਇਹ synchronized retry storms ਨੂੰ ਰੋਕਦੇ ਹਨ।
Failover (ਸਟੈਂਡਬਾਈ ਇੰਸਟੈਂਸ ਜਾਂ ਰੈਪਲਿਕਾ ਤੇ ਸਵਿੱਚ) ਉਸ ਵੇਲੇ ਮਦਦ ਕਰਦਾ ਹੈ ਜਦੋਂ ਕੋਈ ਕੰਪੋਨੈਂਟ ਅਸਲ ਵਿੱਚ ਡਾਊਨ ਹੋਵੇ, ਪਰ ਇਹ ਤਦ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਬਾਕੀ ਸਿਸਟਮ ਫੇਲਿਉਰ ਨੂੰ ਸੁਰੱਖਿਅਤ ਅਤੇ ਤੇਜ਼ ਪਛਾਣ ਸਕੇ।
ਜੇ ਤੁਸੀਂ ਇੱਕ ਬੇਨਤੀ retry ਕਰਦੇ ਹੋ, ਤਾਂ ਇਹ ਸੰਭਵ ਹੈ ਕਿ ਤੁਸੀਂ ਉਸਨੂੰ ਕਈ ਵਾਰੀ ਚਲਾਵੋਗੇ। ਇਹ ਅਟ-ਲੀਸਟ-ਵਨ ਡਿਲਿਵਰੀ ਹੈ: ਸਿਸਟਮ ਕੰਮ ਨਹੀਂ ਛੱਡਦਾ ਪਰ ਡੁਪਲੀਕੇਟ ਹੋ ਸਕਦੇ ਹਨ।
ਏਗਜ਼ੈਕਟਲੀ-ਵਨ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕਾਰਵਾਈ ਇੱਕ ਵਾਰੀ ਹੀ ਹੋਵੇ, ਕੋਈ ਡੁਪਲੀਕੇਟ ਨਹੀਂ। ਇਹ ਵਾਅਦਾ ਨੈੱਟਵਰਕ ਵੰਡ 'ਤੇ ਔਖਾ ਹੈ।
ਕਈ ਟੀਮਾਂ ਇਸਦੀ ਥਾਂ idempotent ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਡਿਜ਼ਾਇਨ ਕਰਦੀਆਂ ਹਨ (ਦੁਹਰਾਉਣ ਲਈ ਸੁਰੱਖਿਅਤ), ਤਾਂ ਕਿ ਅਟ-ਲੀਸਟ-ਵਨ ਕਬੂਲਯੋਗ ਬਣ ਜਾਂਦਾ ਹੈ।
ਸਭ ਤੋਂ ਭਰੋਸੇਯੋਗ ਟੀਮਾਂ ਸਕ੍ਰੂਟਨੀ ਕਰਕੇ ਅੰਡੋ-ਇੰਜੈਕਟ ਫੇਲਿਉਰ ਕਰਦੀਆਂ ਹਨ (ਸਟੇਜਿੰਗ ਵਿੱਚ ਅਤੇ ਕਦੇ-ਕਦੇ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ) ਅਤੇ ਦੇਖਦੀਆਂ ਹਨ ਕਿ ਕੀ ਹੁੰਦਾ ਹੈ: ਇੰਸਟੈਂਸਾਂ ਨੂੰ ਕਿਲ ਕਰੋ, ਨੈੱਟਵਰਕ ਪਥਾਂ ਨੂੰ ਬਲਾਕ ਕਰੋ, ਡੀਪੀਡੈਂਸੀਜ਼ ਨੂੰ ਧੀਮਾ ਕਰੋ, ਅਤੇ ਅਲਾਰਮ, retries, ਅਤੇ ਉਪਭੋਗਤਾ ਪ੍ਰਭਾਵ ਦੀ ਜਾਂਚ ਕਰੋ।
ਆਊਟੇਜ ਨੂੰ ਇੱਕ ਅਨੁਭਵ ਸਮਝੋ ਜੋ ਤੁਹਾਡੇ ਡਿਜ਼ਾਇਨ ਨੂੰ ਸੁਧਾਰਦਾ ਹੈ, ਨਾ ਕਿ ਕੋਈ ਅਚਾਨਕ ਘਟਨਾ ਜੋ “ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ”।
ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਕਤੇਰੀ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਦੇ ਹਨ: ਹਰ ਨਵੀਂ ਖਾਸੀਅਤ ਉਹਨਾਂ ਤਰੀਕਿਆਂ ਦੀ ਗਿਣਤੀ ਵਧਾਉਂਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਨਾਲ ਚੀਜ਼ਾਂ ਆਪਸ ਵਿੱਚ ਇੰਟਰੈੱਕਟ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਇਥੇ ਬਗਸ ਛੁਪਦੇ ਹਨ।
Lampson ਦਾ ਵਿਚਾਰ—ਜੇਹੜਾ Xerox PARC 'ਚ ਬਣਿਆ—OS ਸਟ੍ਰੱਕਚਰ ਨੂੰ ਇੱਕ ਸਕੇਲਿੰਗ ਰਣਨੀਤੀ ਵਜੋਂ ਵੇਖਦਾ ਹੈ। ਜੇ ਕੋਰ ਗੜਬੜੀਲਾ ਹੈ, ਤਾਂ ਉੱਪਰ ਬਣਿਆ ਹਰ ਚੀਜ਼ ਉਸ ਗੜਬੜ ਨੂੰ ਵਾਰਸਾ ਕਰ ਲੈਂਦੀ ਹੈ।
PARC-ਯੁੱਗ ਦਾ ਮੁੜ-ਦਹਰਾਉਣ ਵਾਲਾ ਸਬਕ ਹੈ ਕਿ kernel (ਜਾਂ “ਟ੍ਰੱਸਟਡ ਕੋਰ”) ਨੂੰ ਸੰਕੁਚਿਤ ਅਤੇ ਸਧਾਰਨ, ਰਚਣਯੋਗ ਪ੍ਰਿਮਿਟਿਵ ਨਾਲ ਰੱਖੋ। ਕਈ ਵਿਸ਼ੇਸ਼ ਕੇਸ ਨਾ ਪਕਾਸ਼ਿਤ ਕਰਕੇ, ਕੁਝ ਮਕੈਨਿਕਜ਼ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਜੋ ਸੌਖੇ ਨਾਲ ਸਮਝਾਏ ਜਾ ਸਕਣ ਅਤੇ ਗਲਤ ਵਰਤੋਂ ਮੁਸ਼ਕਲ ਹੋਏ।
ਸਪਸ਼ਟ ਇੰਟਰਫੇਸ ਉਸੇ ਪ੍ਰਮਾਣ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਹਨ ਜਿਵੇਂ ਮਕੈਨਿਕਜ਼। ਜਦੋਂ ਬਾਰਡਰੀਆਂ ਸਪਸ਼ਟ ਹੁੰਦੀਆਂ ਹਨ—ਕਿ ਇੱਕ ਕੰਪੋਨੈਂਟ ਕੀ ਵਾਅਦਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਕੀ ਮੰਨ ਸਕਦਾ ਹੈ—ਤਾਂ ਤੁਸੀਂ ਇੰਪਲਿਮੈਂਟੇਸ਼ਨਾਂ ਨੂੰ ਬਦਲ ਸਕਦੇ ਹੋ, ਹਿੱਸਿਆਂ ਨੂੰ ਅਲੱਗ ਟੈਸਟ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਗੈਰ-ਇਰਾਦਿ ਜੋੜ ਨੂੰ ਰੋਕ ਸਕਦੇ ਹੋ।
ਅਲੱਗਾਵ ਦਾਇਰਾ ਘਟਾਉਂਦੀ ਹੈ। ਚਾਹੇ ਇਹ ਮੇਮੋਰੀ ਸੁਰੱਖਿਆ ਹੋਵੇ, ਪ੍ਰੋਸੈਸ ਵੱਖ ਕਰਨਾ, ਜਾਂ ਸੰਸਾਧਨਾਂ ਤੱਕ ਘੱਟ-ਅਧਿਕਾਰ, ਅਲੱਗਾਵ “ਕੋਈ ਵੀ ਜਗ੍ਹਾ ਦੀ ਬਗ ਸਾਰੀਆ ਨੂੰ ਤਬਾਹ ਕਰ ਦੇਵੇगी” ਨੂੰ “ਇੱਕ ਬਗ ਸੰਕੁਚਿਤ ਰਹਿੰਦੀ ਹੈ” ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਇਹ ਸੋਚ capability-ਨੁਮਾ ਡਿਜ਼ਾਇਨਾਂ ਵੱਲ ਵੀ ਧੱਕਦੀ ਹੈ: ਕੋਡ ਨੂੰ ਕੇਵਲ ਉਹ ਅਧਿਕਾਰ ਦਿਓ ਜੋ ਇਸਨੂੰ ਚਾਹੀਦੇ ਹਨ, ਅਤੇ ਪਹੁੰਚ ਨੂੰ ਸਪਸ਼ਟ ਬਣਾਓ ਇਮਪਲਾਈਡ ਨਾ ਰੱਖੋ।
ਵਾਹਿਕਤਾ ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਵੀ दिखਦੀ ਹੈ: ਆਮ ਆਪਰੇਸ਼ਨਾਂ ਲਈ ਫਾਸਟ ਪਾਥ ਬਣਾਓ, ਅਤੇ ਉਹ ਓਹਲੇਓਵਰਹੈੱਡ ਤੋਂ ਬਚੋ ਜੋ ਤੁਹਾਨੂੰ ਸੁਰੱਖਿਆ ਜਾਂ ਸਪਸ਼ਟਤਾ ਨਹੀਂ ਦਿੰਦਾ।
ਲਕਸ਼ ਮਾਇਕ੍ਰੋ-ਓਪਟੀਮਾਈਜ਼ ਨਾ ਕਰਨਾ ਹੈ—ਲਕਸ਼ ਹੈ ਆਮ ਮਾਮਲੇ ਨੂੰ ਤੁਰੰਤ ਮਹਿਸੂਸ ਕਰਵਾਉਣਾ ਜਦੋਂ ਕਿ ਸਹੀਪਣ ਬਰਕਰਾਰ ਰੱਖਣਾ।
ਤੁਸੀਂ ਇਹੇ ਵਿਚਾਰ ਕਿਸੇ ਵੀ ਆਧੁਨਿਕ ਕਰਨਲ, ਭਾਸ਼ਾ ਰਨਟਾਈਮ, ਅਤੇ ਕੰਟੇਨਰਾਈਜ਼ਡ ਪਲੇਟਫਾਰਮਾਂ 'ਚ ਦੇਖ ਸਕਦੇ ਹੋ: ਇੱਕ ਛੋਟਾ ਟਰੱਸਟਡ ਬੇਸ, ਵਧੀਆ تعريف ਕੀਤੀਆਂ APIs, ਅਤੇ ਅਲੱਗਾਵ ਵਾਲੇ ਬਾਰਡਰ (ਪ੍ਰੋਸੈਸ, ਸੈਂਡਬਾਕਸ, ਨੇਮਸਪੇਸ) ਜੋ ਟੀਮਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਦਿੰਦੇ ਹਨ ਬਿਨਾਂ ਸਾਂਝੀ ਫੇਲਿਉਰ ਮੋਡ।
ਡਿਟੇਲ ਬਦਲੇ; ਡਿਜ਼ਾਇਨ ਅਦਤਾਂ ਅਜੇ ਵੀ ਫਾਇਦੇਦਾਇਕ ਹਨ।
PARC ਦੀ ਵੱਡੀ ਜਿੱਤ ਇੱਕ ਇਕੱਲੀ ਖੋਜ ਨਹੀਂ ਸੀ—ਇਹ ਇੱਕ ਸੁਗਠਿਤ ਤਰੀਕਾ ਸੀ ਜੋ ਨੈੱਟਵਰਕਡ ਸਿਸਟਮ ਲੋਕ ਅੰਮੋਲ ਤਰੀਕੇ ਨਾਲ ਵਰਤ ਸਕਣ। ਨਾਮ ਬਦਲੇ, ਪਰ ਮੁੱਖ ਸਮੱਸਿਆਵਾਂ (ਲੇਟੰਸੀ, ਫੇਲਿਉਰ, ਭਰੋਸਾ, ਮਾਲਕੀ) ਨਹੀਂ ਬਦਲੀਆਂ।
ਇੱਕ ਤੇਜ਼ “ਮਾਨਸਿਕ ਡਿਕਸ਼ਨਰੀ” ਡਿਜ਼ਾਇਨਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰਨ وقت ਮਦਦ ਕਰਦਾ ਹੈ:\n\n- RPC → APIs (REST/gRPC/GraphQL): ਤਾਰ ਛੁਪਾਓ, ਪਰ ਟਾਈਮਆਉਟਸ, retries, ਅਤੇ idempotency ਸਪਸ਼ਟ ਰੱਖੋ।\n- ਨਾਂਕਰਨ & ਡਾਇਰੈਕਟਰੀਜ਼ → DNS + ਸਰਵਿਸ ਖੋਜ: “ਇਹ ਕਿੱਥੇ ਹੈ?” ਇੱਕ ਪਹਿਲੀ-ਕਲਾਸ ਚਿੰਤਾ ਹੈ, ਨਾ ਕਿ ਬਾਅਦ ਦੀ।\n- ਕੈਸ਼ਿੰਗ → CDNs + ਲੋਕਲ ਕੈਸ਼ + ਐਜ ਸਟੋਰੇਜ: ਤੇਜ਼ੀ ਆਸਾਨ ਹੈ; ਸਹੀਪਣ ਔਖਾ ਹੈ।\n- ਕੈਪੇਬਿਲਿਟੀਜ਼ → ਟੋਕਨ/ਕੀ/ਸਕੋਪ (OAuth ਸਕੋਪ, macaroons, ਸਾਈਨ ਕੀਤੀਆਂ URLs): ਨਿਰਧਾਰਤ ਅਧਿਕਾਰ ਦਿਓ, ਨਾਂ ਕਿ ਬੇਹਦ ਪਹੁੰਚ।\n- ਸਰਵਿਸਾਂ, ਮੋਨੋਲੀਥ ਨਹੀਂ → ਸਪਸ਼ਟ 컨ਟਰੈਕਟਾਂ ਨਾਲ ਮੋਡਿਊਲਰ ਸਿਸਟਮ: ਵੰਡ ਫਾਇਦੇਦਾਇਕ ਹੈ ਜਦੋਂ ਮਾਲਕੀ ਅਤੇ ਇੰਟਰਫੇਸ ਕਿਰਿਸਪ ਹੋਣ।
ਇਸਨੂੰ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਇੱਕ ਸਿਸਟਮ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨ ਵੇਲੇ ਵਰਤੋ:\n\n1. ਸੇਵਾ ਬਾਰਡਰੀਜ਼ ਅਤੇ ਮਾਲਕ ਕੌਣ ਹਨ? ਜੇ ਇੱਕ ਕੰਪੋਨੈਂਟ ਦਾ ਕੋਈ ਜ਼ਿੰਮੇਵਾਰ ਟੀਮ ਨਹੀਂ ਹੈ, ਉਹ ਰੁੱਕ ਜਾਂਦਾ ਹੈ।\n2. ਕਲਾਇੰਟ ਸਰਵਿਸ ਨੂੰ ਕਿਵੇਂ ਲੱਭਦੇ ਹਨ? ਡਿਸਕਵਰੀ, ਵਰਜ਼ਨਿੰਗ, ਅਤੇ ਰੋਲਆਉਟ ਰਣਨੀਤੀਆਂ ਪਹਿਲੇ ਹੀ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ।\n3. ਫੇਲਿਉਰ ਯੋਜਨਾ ਕੀ ਹੈ? ਟਾਈਮਆਉਟ, retries, ਸਰਕਿਟ ਬ੍ਰੇਕਰ, ਅਤੇ “ਘਟਿਆ ਮੋਡ” ਕੀ ਲੱਗਦਾ ਹੈ ਇਹ ਫੈਸਲਾ ਕਰੋ।\n4. ਸਟੇਟ ਕਿੱਥੇ ਹੈ, ਅਤੇ ਇਹ ਕਿਵੇਂ ਰੱਖੀ ਜਾਂਦੀ ਹੈ? ਪ੍ਰਮਾਣਿਕ ਸੋਰਸ, ਰੈਪਲਿਕੇਸ਼ਨ ਨੀਤੀਆਂ, ਅਤੇ ਬੈਕਅਪ/ਰੀਸਟੋਰ ਨਿਰਧਾਰ ਕਰੋ।\n5. ਅਸੀਂ ਕਿੱਥੇ ਕੈਸ਼ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਕੀ ਪੁਰਾਣਾ ਹੋ ਸਕਦਾ ਹੈ? ਹਰ ਡੇਟਾ ਲਈ ਸਪਸ਼ਟ ਬੋਲ ਚਾਲੀ ਭਾਸ਼ਾ ਵਿੱਚ consistency ਉਮੀਦਾਂ ਲਿਖੋ।\n6. ਪ੍ਰਿੰਸੀਪਲ ਮਾਡਲ ਕੀ ਹੈ? ਘੱਟ-ਅਧਿਕਾਰ ਟੋਕਨ ਅਤੇ ਛੋਟੀ-ਅਵਧੀ ਕ੍ਰੈਡੈਂਸ਼ਲ ਦੀ ਪਸੰਦ ਕਰੋ।\n7. ਅਸੀਂ ਇਸਨੂੰ ਕਿਵੇਂ ਨਿਰੀਖਣ ਕਰਾਂਗੇ? ਲਾਗ, ਮੈਟ੍ਰਿਕਸ, ਟਰੇਸ, ਅਤੇ ਯੂਜ਼ਰ ਅਨੁਭਵ ਨਾਲ ਜੁੜੇ ਸਪਸ਼ਟ SLOs।
ਇੱਕ ਆਧੁਨਿਕ ਤਰਕ ਇਹ ਹੈ ਕਿ ਟੀਮਾਂ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਵੰਡਿਤ ਆਰਕੀਟੈਕਚਰ ਪਰੋਟੋਟਾਈਪ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਟੂਲ ਜਿਵੇਂ Koder.ai (ਇੱਕ vibe-coding ਪਲੇਟਫਾਰਮ ਜੋ ਚੈਟ ਤੋਂ ਵੈੱਬ, ਬੈਕਐਂਡ, ਅਤੇ ਮੋਬਾਈਲ ਐਪ ਬਣਾਉਂਦਾ ਹੈ) “ਪਹਿਲਾ ਕੰਮ ਕਰਨ ਵਾਲਾ ਸਿਸਟਮ” ਫੇਜ਼ ਤੇਜ਼ ਕਰ ਸਕਦੇ ਹਨ—React ਫਰੰਟਐਂਡ, Go + PostgreSQL ਬੈਕਐਂਡ, ਅਤੇ Flutter ਫਾਰ ਮੋਬਾਈਲ—ਅਤੇ ਫਿਰ ਤੁਸੀਂ ਸਰੋਤ ਕੋਡ ਨਿਰਯਾਤ ਕਰਕੇ ਇਸਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਕੋਡਬੇਸ ਵਾਂਗ ਵਿਕਸਤ ਕਰ ਸਕਦੇ ਹੋ।
Lampson-ਯੁੱਗ ਦਾ ਸਬਕ ਫਿਰ ਵੀ ਲਾਗੂ ਹੁੰਦਾ ਹੈ: ਤੇਜ਼ੀ ਸਿਰਫ਼ ਤਦ ਹੀ ਜਿੱਤ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇੰਟਰਫੇਸ ਸਪਸ਼ਟ ਰੱਖੋ, ਫੇਲਿਉਰ ਵਿਹਾਰ ਸਪਸ਼ਟ (ਟਾਈਮਆਉਟ, retries, idempotency) ਰੱਖੋ, ਅਤੇ ਨਾਂਕਰਨ, ਕੈਸ਼ਿੰਗ, ਅਤੇ ਪਰਮਿਸ਼ਨਾਂ ਨੂੰ ਪਹਿਲੀ-ਕਲਾਸ ਡਿਜ਼ਾਇਨ ਦੇ ਰੂਪ ਵਿੱਚ ਟREATED ਕਰੋ।
ਨਕਲ ਕਰੋ: ਅਨੁਸ਼ਾਸਨ—ਸਾਦੇ ਇੰਟਰਫੇਸ, ਸਪਸ਼ਟ 컨ਟਰੈਕਟ, ਅਤੇ ਅੰਸ਼ਿਕ ਆਊਟੇਜ ਲਈ ਡਿਜ਼ਾਇਨ।\nਅਨੁਕਰਣ ਕਰੋ: ਮਕੈਨਿਜ਼ਮ—ਆਜ ਤੁਸੀਂ managed discovery, API ਗੇਟਵੇਜ਼, ਅਤੇ ਕਲਾਉਡ IAM ਵਰਤੋਂਗੇ—ਨਿੱਜੀ ਡਾਇਰੈਕਟਰੀਜ਼ ਜਾਂ ਹੱਥ-ਲਿਖੀ auth ਨਹੀਂ।\nਟਾਲੋ: ਓਵਰ-ਸੈਂਟਰਲਾਈਜੇਸ਼ਨ (ਇੱਕ “ਗੌਡ ਸਰਵਿਸ” ਤੇ ਸਭ ਨਿਰਭਰ) ਅਤੇ ਅਸਪਸ਼ਟ ਮਾਲਕੀ (ਕੋਈ ਜਵਾਬਦੇਹ ਨਹੀ) ਨੂੰ।
ਟੂਲਸ ਬਦਲਦੇ ਰਹਿਣਗੇ—ਨਵੇਂ ਰਨਟਾਈਮ, ਨਵੇਂ ਕਲਾਉਡ, ਨਵੇਂ ਪ੍ਰੋਟੋਕੋਲ—ਪਰ ਰੋਕਟ-ਬੰਧਨ ਰਹਿੰਦੇ ਹਨ: ਨੈੱਟਵਰਕ ਫੇਲ ਹੁੰਦਾ ਹੈ, ਲੈਟੰਸੀ ਮੌਜੂਦ ਹੈ, ਅਤੇ ਸਿਸਟਮ ਉਹੀ ਸਕੇਲ ਕਰਦੇ ਹਨ ਜਦੋਂ ਮਨੁੱਖ ਉਹਨਾਂ ਨੂੰ ਚਲਾ ਸਕਦੇ ਹਨ।
ਇਸ ਸੰਦਰਭ ਵਿੱਚ, “ਸਕੇਲ” ਦਾ ਮਤਲਬ ਹੈ ਅਨੇਕ ਵਰਤੋਂਕਾਰ, ਅਨੇਕ ਮਸ਼ੀਨ ਅਤੇ ਅਸਲ-ਦੁਨੀਆ ਦੀ ਗੜਬੜ ਦੇ ਨਾਲ ਸਿਸਟਮ ਚਲਾਉਣਾ। ਮੁਸ਼ਕਲਾਂ ਉਹਨਾਂ ਵੇਲਿਆਂ ਸਾਹਮਣੇ ਆਉਂਦੀਆਂ ਹਨ ਜਦੋਂ ਬੇਨਤੀ ਕਈ ਸਰਵਿਸਾਂ ਵਿੱਚ ਵੰਡ ਜਾਂਦੀ ਹੈ ਅਤੇ ਫੇਲਿਉਰ ਅੰਸ਼ਿਕ ਹੁੰਦੇ ਹਨ: ਕੁਝ ਚੀਜ਼ਾਂ ਕੰਮ ਕਰਦੀਆਂ ਹਨ, ਦੂਜੀਆਂ ਟਾਈਮਆਉਟ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਸਿਸਟਮ ਨੂੰ ਫਿਰ ਵੀ ਪੂਰਬ-ਤਰ੍ਹਾਂ ਵਰਤਣਯੋਗ ਰਹਿਣਾ ਹੋਂਦਾ ਹੈ।
PARC ਨੇ ਇੱਕ ਪੂਰਾ ਨੈੱਟਵਰਕڈ ਵਰਕਪਲੇਸ ਬਣਾਇਆ: Alto ਵਰਗੇ ਪर्सਨਲ ਕੰਪਿਊਟਰ Ethernet ਨਾਲ ਜੁੜੇ ਜੋ ਫਾਇਲ ਅਤੇ ਪ੍ਰਿੰਟ ਸਰਵਰ ਵਰਗੀਆਂ ਸਾਂਝੀ ਸਰਵਿਸਾਂ ਨੂੰ ਐਕਸੈਸ ਕਰਦੇ ਸਨ। ਮੁੱਖ ਸਬਕ ਇਹ ਹੈ ਕਿ ਅਸਲ-ਪ੍ਰਯੋਗ ਤੋਂ ਹੀ ਅਸਲ ਸਿਸਟਮ ਸਮੱਸਿਆਵਾਂ ਸਿਖਣ ਨੂੰ ਮਿਲਦੀਆਂ ਹਨ—ਨਾਂਕਰਨ, ਓਵਰਲੋਡ, ਕੈਸ਼ਿੰਗ, ਫੇਲਿਉਰ ਅਤੇ ਸੁਰੱਖਿਆ ਅਨਿਵਾਰਯ ਹੋ ਜਾਂਦੇ ਹਨ।
ਇਸ ਨੇ ਇੱਕ ਵਰਤੋਂਯੋਗ ਵੰਡ ਕੀਤਾ: ਲੇਟੰਸੀ-ਸੰਵੇਦਨਸ਼ੀਲ ਇੰਟਰੈਕਸ਼ਨ ਲੋਕਲ ਤੌਰ 'ਤੇ ਕਰੋ (UI, ਐਡਿਟਿੰਗ, ਰੈਂਡਰਿੰਗ), ਅਤੇ ਸਾਂਝੀ ਜਾਂ ਅਥਾਰਟੀਟੇਟਿਵ ਸਟੇਟ ਸਰਵਿਸਾਂ 'ਤੇ ਰੱਖੋ (ਫਾਇਲਾਂ, ਆਈਡੈਂਟਿਟੀ, ਸਹਿਯੋਗ, ਨੀਤੀ)। ਡਿਜ਼ਾਇਨ ਦਾ ਲਕਸ਼ ਹੈ ਤੇਜ਼ ਲੋਕਲ ਪ੍ਰਤੀਕ੍ਰਿਆ ਅਤੇ ਅਕਵਲੇਨਟ ਗਲੋਬਲ ਵਿਹਾਰ ਜਦੋਂ ਨੈੱਟਵਰਕ ਸਲੋ ਜਾਂ ਅਣਵਿਸ਼ਵਸਨੀਯ ਹੋਵੇ।
ਕਿਉਂਕਿ ਨੈੱਟਵਰਕ ਇੱਕ ਪਹਿਲੀ-ਸ਼੍ਰੇਣੀ ਨਿਰਭਰਤਾ ਬਣ ਜਾਂਦਾ ਹੈ, ਨਾ ਕਿ ਪਿੱਛੇ ਦੀ ਚੀਜ਼। ਜਦੋਂ ਬਹੁਤ ਸਾਰੀਆਂ ਮਸ਼ੀਨਾਂ ਇੱਕ ਸਾਂਝੇ ਮੀਡਿਯਮ ਤੇ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਸਰਵਿਸਾਂ ਬਾਰੰਬਾਰ ਗੱਲ ਕਰਦੀਆਂ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਇਹ ਮੰਨ ਕੇ ਚਲਦੇ ਹੋ ਕਿ:
ਪਦਾਰਥਿਕ ਨੀਤੀਆਂ: ਜਲਦੀ ਮੈਟਰਿੰਗ ਸ਼ੁਰੂ ਕਰੋ, ਡਿਫਾਲਟ ਤੌਰ 'ਤੇ ਟਾਈਮਆਉਟਸ ਵਰਤੋ, ਅਤੇ ਬੈਕਆਫ ਨਾਲ ਸਾਵਧਾਨੀ ਨਾਲ retries ਕਰੋ ਤਾਂ ਜੋ ਫੇਲਿਉਰ ਹੋਰ ਭਿਆਨਕ ਨਾ ਬਣ ਜਾਣ।
ਸਰਵਿਸਾਂ ਵੰਡੇ ਤੌਰ 'ਤੇ ਸਪਸ਼ਟਤਾ ਅਤੇ ਸੁਤੰਤਰ ਤਰੱਕੀ ਲਈ ਮਦਦ ਕਰਦੀਆਂ ਹਨ: ਹਰ ਸਰਵਿਸ ਦਾ ਇੱਕ ਧਿਆਨ-ਕੇਂਦਰਤ ਮਕਸਦ ਅਤੇ ਪਰਿਭਾਸ਼ਿਤ ਇੰਟਰਫੇਸ ਹੁੰਦਾ ਹੈ। ਯਹ ਲਾਭ ਹੈ ਕਿ ਛੋਟੇ-ਇਕਾਈਆਂ ਨੂੰ ਅਲੱਗ ਤਰੀਕੇ ਨਾਲ ਤਬਦੀਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਲਾਗਤ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਹੋਰ ਨੈੱਟਵਰਕ ਕਾਲਾਂ ਅਤੇ ਅੰਸ਼ਿਕ ਫੇਲਿਉਰ ਮੋਡ ਲਿਆਉਂਦੇ ਹੋ—ਇਸ ਲਈ ਡਿਸਪਲਿਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ (ਟਾਈਮਆਉਟਸ, retries, ਅਤੇ ਉਪਭੋਗਤਾ-ਪਰੇਖਣ ਯੋਗ ਐਰਰ)।
RPC ਦੂਰ-ਦਰਾਜ਼ ਤੇ ਕਾਰਜ ਚਲਾਉਣ ਨੂੰ ਲੋਕਲ ਕਾਲ ਵਾਂਗ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦਾ ਹੈ। ਪਰ ਚੰਗਾ RPC ਓਹੀ ਹੁੰਦਾ ਹੈ ਜੋ ਨੈੱਟਵਰਕ ਹਕੀਕਤਾਂ ਨੂੰ ਸਪਸ਼ਟ ਕਰੇ। ਪ੍ਰਾਇਕਟਿਕ ਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ ਚਾਹੀਦਾ ਹੈ:
ਬਿਨਾਂ ਇਹਨਾਂ ਦੇ, RPC ਇੱਕ ਨਾਜੁਕ “ਲੋਕਲ ਲੱਗਦਾ ਹੈ, ਇਸ ਲਈ ਮੈਂ ਭੁੱਲ ਗਿਆ ਕਿ ਇਹ ਰਿਮੋਟ ਹੈ” ਡਿਜ਼ਾਇਨ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹੈ।
ਕਿਉਂਕਿ ਟਾਈਮਆਉਟਸ ਅਤੇ ਗੁੰਮ ਹੋਏ ਪ੍ਰਤਿਕ੍ਰਿਆ ਤੋਂ retries ਲਾਜ਼ਮੀ ਬਣ ਜਾਂਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਕੰਮ ਨਕਲ ਹੋ ਸਕਦਾ ਹੈ। ਤੁਸੀਂ ਕਾਰਵਾਈਆਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਉ ਸਕਦੇ ਹੋ:
orderId) ਦੇ ਆਲੇ-ਦੁਆਲੇ ਡਿਜ਼ਾਈਨ ਕਰਕੇਇਹ ਖਾਸ ਤੌਰ 'ਤੇ ਭੁਗਤਾਨ, ਪ੍ਰੋਵੀਜ਼ਨਿੰਗ ਜਾਂ ਨੋਟੀਫਿਕੇਸ਼ਨ ਜਿਹੇ ਕਿਰਿਆਵਾਂ ਲਈ ਅਤਿ-ਮਹੱਤਵਪੂਰਨ ਹੈ।
ਜੇ ਇੱਕ ਨਾਮ ਸਥਿਤੀ (ਲੋਕੇਸ਼ਨ) ਵੀ ਹੋਵੇ (ਔਖੇ-ਕੋਡੇ IP/ਹੋਸਟ), ਤਾਂ ਮਾਈਗਰੇਸ਼ਨ ਅਤੇ ਫੇਲਿਉਰ ਉਪਭੋਗਤਾ-ਦਿਖਾਈ ਬੰਦ ਹੋ ਸਕਦੇ ਹਨ। ਸਤਿ-ਟਿਕੇ ਨਾਮ ਨੂੰ ਤਬਦੀਲ ਹੁੰਦੇ ਲੋਕੇਸ਼ਨਾਂ ਤੋਂ ਵੱਖਰਾ ਰੱਖੋ—ਇਸ ਲਈ ਡਾਇਰੈਕਟਰੀ ਜਾਂ ਡਿਸਕਵਰੀ ਸਿਸਟਮ ਪੁੱਛ ਸਕਦਾ ਹੈ “X ਹੁਣ ਕਿੱਥੇ ਹੈ?” ਅਤੇ ਕਲਾਈਂਟਾਂ ਸਪਸ਼ਟ ਤਾਜ਼ਗੀ ਨਿਯਮਾਂ ਨਾਲ ਜਵਾਬਾਂ ਨੂੰ ਕੈਸ਼ ਕਰ ਸਕਦੇ ਹਨ (ਜਿਵੇਂ TTL)।
ਕੈਸ਼ਿੰਗ ਅਕਸਰ ਸਭ ਤੋਂ ਸਸਤਾ ਪ੍ਰਦਰਸ਼ਨ ਨਫ਼ਾ ਹੈ, ਪਰ ਇਹ ਸਟੇਲਨੈਸ ਦਾ ਖ਼ਤਰਾ ਲਿਆਉਂਦਾ ਹੈ। ਆਮ ਨਿਯੰਤਰਣ ਸ਼ਾਮਲ ਹਨ:
ਕੁੰਜੀ ਇਹ ਹੈ ਕਿ ਹਰ ਡੇਟਾ ਟੁਕੜੇ ਲਈ “ਪਰਯਾਪਤ ਤਾਜ਼ਗੀ” ਦਾ ਸਪਸ਼ਟ ਲਿਖਤੀ ਨਿਰਧਾਰਨ ਕਰੋ ਤਾਂ ਜੋ ਸਹੀਪਣ ਦੁਰਘਟਨਾਤਮਕ ਨਾ ਬਣੇ।
ਇੱਕ capability ਇੱਕ ਅਣ-ਫਰਜੀ ਟੋਕਨ ਹੁੰਦੀ ਹੈ ਜੋ ਕਿਸੇ ਸਰੋਤ ਜਾਂ ਕਾਰਵਾਈ ਲਈ ਨਿਰਧਾਰਤ ਅਧਿਕਾਰ ਦਿੰਦੀ ਹੈ। ਪਛਾਣ+ACL ਚੈੱਕਸ ਦੀ ਥਾਂ, capabilities multi-hop ਸਿਸਟਮਾਂ ਵਿੱਚ ਡੇਲੀਗੇਸ਼ਨ ਅਤੇ ਘੱਟ ਅਧਿਕਾਰ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੀਆਂ ਹਨ:
ਆਧੁਨਿਕ ਸਮਾਨਤਾਵਾਂ ਵਿੱਚ ਇਹ OAuth ਟੋਕਨ, ਸਕੋਪਡ ਕਲਾਉਡ ਕ੍ਰੈਡੈਂਸ਼ਲ, ਅਤੇ ਸਾਈਨ ਕੀਤੀਆਂ URLs/JWT-ਸਮਾਨ ਟੋਕਨ ਆਦਿ ਦੇ ਰੂਪ ਵਿੱਚ ਵੇਖਣ ਨੂੰ ਮਿਲਦੇ ਹਨ (ਸਾਵਧਾਨ ਹੋ ਕੇ)।