NDC ਲੰਡਨ ਕਾਨਫਰੰਸ. ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਆਫ਼ਤ ਨੂੰ ਰੋਕਣਾ। ਭਾਗ 1

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

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

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

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

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

ਸ਼ੁਰੂਆਤੀ ਡਿਜ਼ਾਈਨ ਬਹੁਤ ਵਧੀਆ ਲੱਗ ਰਿਹਾ ਸੀ ਅਤੇ ਇਸ ਵਿੱਚ ਇੱਕ ਉੱਚ-ਪੱਧਰੀ ਸਾਈਟ bell.com ਅਤੇ ਵਿਅਕਤੀਗਤ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਕਈ ਉਪ-ਡੋਮੇਨ ਸ਼ਾਮਲ ਸਨ: catalog.bell.com, accounts.bell.com, orders.bell.com, ਉਤਪਾਦ ਖੋਜ search.bell। com. ਹਰੇਕ ਸਬਡੋਮੇਨ ਨੇ ASP.Net 1.0 ਫਰੇਮਵਰਕ ਅਤੇ ਇਸਦੇ ਆਪਣੇ ਡੇਟਾਬੇਸ ਦੀ ਵਰਤੋਂ ਕੀਤੀ, ਅਤੇ ਉਹਨਾਂ ਸਾਰਿਆਂ ਨੇ ਸਿਸਟਮ ਬੈਕਐਂਡ ਨਾਲ ਗੱਲ ਕੀਤੀ। ਹਾਲਾਂਕਿ, ਸਾਰੇ ਆਦੇਸ਼ਾਂ ਨੂੰ ਇੱਕ ਵਿਸ਼ਾਲ ਮੇਨਫ੍ਰੇਮ ਦੇ ਅੰਦਰ ਸੰਸਾਧਿਤ ਅਤੇ ਲਾਗੂ ਕੀਤਾ ਜਾਣਾ ਜਾਰੀ ਰਿਹਾ, ਜਿਸ ਵਿੱਚ ਸਾਰਾ ਕੂੜਾ ਰਹਿ ਗਿਆ, ਪਰ ਫਰੰਟ ਐਂਡ ਵਿਅਕਤੀਗਤ ਐਪਲੀਕੇਸ਼ਨਾਂ ਅਤੇ ਵੱਖਰੇ ਡੇਟਾਬੇਸ ਦੇ ਨਾਲ ਵੱਖਰੀਆਂ ਵੈਬਸਾਈਟਾਂ ਸਨ।

ਇਸ ਲਈ ਸਿਸਟਮ ਦਾ ਡਿਜ਼ਾਇਨ ਤਰਕਸੰਗਤ ਅਤੇ ਤਰਕਪੂਰਨ ਲੱਗ ਰਿਹਾ ਸੀ, ਪਰ ਅਸਲ ਸਿਸਟਮ ਅਗਲੀ ਸਲਾਈਡ ਵਿੱਚ ਦਿਖਾਇਆ ਗਿਆ ਸੀ।

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

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

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

ਮੌਜੂਦਾ ਐਪਲੀਕੇਸ਼ਨ 15 ਸਾਲਾਂ ਤੋਂ ਉਤਪਾਦਨ ਵਿੱਚ ਸੀ, ਜੋ ਕਿ ASP.Net-ਅਧਾਰਿਤ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਇੱਕ ਰਿਕਾਰਡ ਹੈ। ਸੇਵਾ ਨੇ ਪੂਰੀ ਦੁਨੀਆ ਤੋਂ ਆਰਡਰ ਸਵੀਕਾਰ ਕੀਤੇ, ਅਤੇ ਇਸ ਸਿੰਗਲ ਐਪਲੀਕੇਸ਼ਨ ਤੋਂ ਸਾਲਾਨਾ ਆਮਦਨ ਇੱਕ ਬਿਲੀਅਨ ਡਾਲਰ ਤੱਕ ਪਹੁੰਚ ਗਈ। ਮੁਨਾਫੇ ਦਾ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਹਿੱਸਾ bell.com ਵੈੱਬਸਾਈਟ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਸੀ। ਬਲੈਕ ਫਰਾਈਡੇ 'ਤੇ, ਸਾਈਟ ਦੁਆਰਾ ਦਿੱਤੇ ਗਏ ਆਰਡਰਾਂ ਦੀ ਗਿਣਤੀ ਕਈ ਮਿਲੀਅਨ ਤੱਕ ਪਹੁੰਚ ਗਈ। ਹਾਲਾਂਕਿ, ਮੌਜੂਦਾ ਆਰਕੀਟੈਕਚਰ ਨੇ ਕਿਸੇ ਵੀ ਵਿਕਾਸ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੱਤੀ, ਕਿਉਂਕਿ ਸਿਸਟਮ ਤੱਤਾਂ ਦੇ ਕਠੋਰ ਆਪਸੀ ਕਨੈਕਸ਼ਨਾਂ ਨੇ ਅਮਲੀ ਤੌਰ 'ਤੇ ਸੇਵਾ ਵਿੱਚ ਕੋਈ ਬਦਲਾਅ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੱਤੀ।

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

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

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

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

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

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

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

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

ਅਸੀਂ ਕੁਝ ਗਣਿਤ ਕੀਤਾ. ਹਰੇਕ API ਕਾਲ ਵਿੱਚ 150 ms ਤੋਂ ਵੱਧ ਦਾ SLA ਅਤੇ 99,9% ਅਪਟਾਈਮ ਸੀ। ਇੱਕ ਬੇਨਤੀ ਕਾਰਨ 200 ਵੱਖ-ਵੱਖ ਕਾਲਾਂ ਹੋਈਆਂ, ਅਤੇ ਸਭ ਤੋਂ ਵਧੀਆ ਸਥਿਤੀ ਵਿੱਚ, ਪੰਨਾ 200 x 150 ms = 30 ਸਕਿੰਟਾਂ ਵਿੱਚ ਦਿਖਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ, ਇਹ ਕੋਈ ਚੰਗਾ ਨਹੀਂ ਸੀ. 99,9% ਅਪਟਾਈਮ ਨੂੰ 200 ਨਾਲ ਗੁਣਾ ਕਰਕੇ, ਸਾਨੂੰ 0% ਉਪਲਬਧਤਾ ਮਿਲੀ। ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਇਹ ਆਰਕੀਟੈਕਚਰ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਅਸਫਲਤਾ ਲਈ ਤਬਾਹ ਹੋ ਗਿਆ ਸੀ.

ਅਸੀਂ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਪੁੱਛਿਆ ਕਿ ਉਹ 18 ਮਹੀਨਿਆਂ ਦੇ ਕੰਮ ਤੋਂ ਬਾਅਦ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਪਛਾਣਨ ਵਿੱਚ ਕਿਵੇਂ ਅਸਫਲ ਰਹੇ? ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਉਹਨਾਂ ਨੇ ਸਿਰਫ ਉਹਨਾਂ ਦੁਆਰਾ ਚਲਾਏ ਗਏ ਕੋਡ ਲਈ SLA ਦੀ ਗਿਣਤੀ ਕੀਤੀ, ਪਰ ਜੇਕਰ ਉਹਨਾਂ ਦੀ ਸੇਵਾ ਨੂੰ ਕਿਸੇ ਹੋਰ ਸੇਵਾ ਨੂੰ ਬੁਲਾਇਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਨੇ ਉਸ ਸਮੇਂ ਨੂੰ ਉਹਨਾਂ ਦੇ SLA ਵਿੱਚ ਨਹੀਂ ਗਿਣਿਆ। ਹਰ ਚੀਜ਼ ਜੋ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਦੇ ਅੰਦਰ ਸ਼ੁਰੂ ਕੀਤੀ ਗਈ ਸੀ, 150 ms ਦੇ ਮੁੱਲ ਦੀ ਪਾਲਣਾ ਕਰਦੀ ਹੈ, ਪਰ ਹੋਰ ਸੇਵਾ ਪ੍ਰਕਿਰਿਆਵਾਂ ਤੱਕ ਪਹੁੰਚ ਨੇ ਕੁੱਲ ਦੇਰੀ ਨੂੰ ਕਈ ਗੁਣਾ ਵਧਾ ਦਿੱਤਾ ਹੈ। ਪਹਿਲਾ ਸਬਕ ਇਹ ਸੀ: "ਕੀ ਤੁਸੀਂ ਆਪਣੇ SLA ਦੇ ਨਿਯੰਤਰਣ ਵਿੱਚ ਹੋ, ਜਾਂ SLA ਤੁਹਾਡੇ ਨਿਯੰਤਰਣ ਵਿੱਚ ਹੈ?" ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਇਹ ਬਾਅਦ ਵਾਲਾ ਸੀ.

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

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

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

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

ਹੇਠਾਂ ਦਿੱਤੀ ਤਸਵੀਰ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਕਿਵੇਂ MS ਇੱਕ ਮੋਨੋਲਿਥ ਤੋਂ ਮਾਈਕ੍ਰੋਸਰਵਿਸਿਜ਼ ਵਿੱਚ ਜਾਣ ਦੀ ਸਿਫ਼ਾਰਸ਼ ਕਰਦਾ ਹੈ - ਬਸ ਹਰੇਕ ਮੁੱਖ ਸੇਵਾਵਾਂ ਨੂੰ ਵੱਖਰੇ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਵਿੱਚ ਵੰਡਣਾ। ਇਹ ਇਸ ਸਕੀਮ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੇ ਦੌਰਾਨ ਸੀ ਕਿ ਬੈੱਲ ਨੇ ਇੱਕ ਗਲਤੀ ਕੀਤੀ ਸੀ.

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

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

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

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

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

ਇਸ ਸਕੀਮ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਇਹ ਹੈ ਕਿ ਤਬਦੀਲੀ ਦੇ ਇਹਨਾਂ ਖੇਤਰਾਂ ਦੀਆਂ ਸੀਮਾਵਾਂ ਨਾ ਸਿਰਫ਼ ਵਪਾਰਕ ਤਰਕ ਦੇ ਪੱਧਰ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀਆਂ ਹਨ, ਸਗੋਂ ਡੇਟਾਬੇਸ ਤੱਕ ਵੀ ਫੈਲਦੀਆਂ ਹਨ।

ਆਓ ਦੇਖੀਏ ਕਿ ਸੇਵਾ ਹੋਣ ਦਾ ਕੀ ਅਰਥ ਹੈ। ਇੱਕ ਸੇਵਾ ਪਰਿਭਾਸ਼ਾ ਦੇ 6 ਵਿਸ਼ੇਸ਼ ਗੁਣ ਹਨ - ਇਹ ਸਾਫਟਵੇਅਰ ਹੈ ਜੋ:

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

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

ਆਉ ਹੁਣ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਦੀ ਪਰਿਭਾਸ਼ਾ ਨੂੰ ਵੇਖੀਏ:

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

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

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

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

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

ਇਸ ਲਈ ਅਸੀਂ ਬੈੱਲ ਕੰਪਿਊਟਰਜ਼ ਦੇ ਮੁੰਡਿਆਂ ਨੂੰ ਕਿਹਾ, “ਅਸੀਂ ਤੁਹਾਡੇ ਦੁਆਰਾ ਪੈਦਾ ਕੀਤੀ ਕਿਸੇ ਵੀ ਗੜਬੜ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰ ਸਕਦੇ ਕਿਉਂਕਿ ਤੁਹਾਡੇ ਕੋਲ ਅਜਿਹਾ ਕਰਨ ਲਈ ਪੈਸੇ ਨਹੀਂ ਹਨ, ਪਰ ਅਸੀਂ ਇਸ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ ਸਿਰਫ਼ ਇੱਕ ਸੇਵਾ ਨੂੰ ਠੀਕ ਕਰਾਂਗੇ। ਸਮਝ।" ਇਸ ਬਿੰਦੂ 'ਤੇ, ਮੈਂ ਤੁਹਾਨੂੰ ਇਹ ਦੱਸ ਕੇ ਸ਼ੁਰੂ ਕਰਾਂਗਾ ਕਿ ਅਸੀਂ ਸਾਡੀ ਇਕਲੌਤੀ ਸੇਵਾ ਨੂੰ ਕਿਵੇਂ ਫਿਕਸ ਕੀਤਾ ਹੈ ਤਾਂ ਜੋ ਇਹ ਸਾਢੇ 9 ਮਿੰਟਾਂ ਤੋਂ ਵੱਧ ਤੇਜ਼ੀ ਨਾਲ ਬੇਨਤੀਆਂ ਦਾ ਜਵਾਬ ਦੇਵੇ।

22:30 ਮਿੰਟ

ਜਲਦੀ ਹੀ ਜਾਰੀ ਰੱਖਿਆ ਜਾਵੇਗਾ...

ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਵਿਗਿਆਪਨ

ਸਾਡੇ ਨਾਲ ਰਹਿਣ ਲਈ ਤੁਹਾਡਾ ਧੰਨਵਾਦ। ਕੀ ਤੁਹਾਨੂੰ ਸਾਡੇ ਲੇਖ ਪਸੰਦ ਹਨ? ਹੋਰ ਦਿਲਚਸਪ ਸਮੱਗਰੀ ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਹੋ? ਆਰਡਰ ਦੇ ਕੇ ਜਾਂ ਦੋਸਤਾਂ ਨੂੰ ਸਿਫਾਰਸ਼ ਕਰਕੇ ਸਾਡਾ ਸਮਰਥਨ ਕਰੋ, $4.99 ਤੋਂ ਡਿਵੈਲਪਰਾਂ ਲਈ ਕਲਾਉਡ VPS, ਪ੍ਰਵੇਸ਼-ਪੱਧਰ ਦੇ ਸਰਵਰਾਂ ਦਾ ਇੱਕ ਵਿਲੱਖਣ ਐਨਾਲਾਗ, ਜਿਸਦੀ ਖੋਜ ਸਾਡੇ ਦੁਆਰਾ ਤੁਹਾਡੇ ਲਈ ਕੀਤੀ ਗਈ ਸੀ: VPS (KVM) E5-2697 v3 (6 ਕੋਰ) 10GB DDR4 480GB SSD 1Gbps ਤੋਂ $19 ਜਾਂ ਸਰਵਰ ਨੂੰ ਕਿਵੇਂ ਸਾਂਝਾ ਕਰਨਾ ਹੈ ਬਾਰੇ ਪੂਰੀ ਸੱਚਾਈ? (RAID1 ਅਤੇ RAID10 ਦੇ ਨਾਲ ਉਪਲਬਧ, 24 ਕੋਰ ਤੱਕ ਅਤੇ 40GB DDR4 ਤੱਕ)।

ਡੈਲ R730xd ਐਮਸਟਰਡਮ ਵਿੱਚ ਈਕੁਇਨਿਕਸ ਟੀਅਰ IV ਡੇਟਾ ਸੈਂਟਰ ਵਿੱਚ 2 ਗੁਣਾ ਸਸਤਾ? ਇੱਥੇ ਹੀ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ਟੀਵੀ $199 ਤੋਂ ਨੀਦਰਲੈਂਡ ਵਿੱਚ! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 ਤੋਂ! ਬਾਰੇ ਪੜ੍ਹੋ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਕਾਰਪੋਰੇਸ਼ਨ ਕਿਵੇਂ ਬਣਾਇਆ ਜਾਵੇ ਡੇਲ R730xd E5-2650 v4 ਸਰਵਰਾਂ ਦੀ ਵਰਤੋਂ ਨਾਲ ਕਲਾਸ 9000 ਯੂਰੋ ਦੀ ਕੀਮਤ ਦੇ ਇੱਕ ਪੈਸੇ ਲਈ?

ਸਰੋਤ: www.habr.com