ਇੱਕ ਆਰਕੀਟੈਕਚਰਲ ਸ਼ੈਲੀ ਦੀ ਚੋਣ ਕਰਨਾ (ਭਾਗ 2)

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

ਜਾਣ ਪਛਾਣ

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

В ਪਿਛਲੀ ਵਾਰ ਅਸੀਂ ਮੋਨੋਲਿਥ ਨਾਲ ਨਜਿੱਠਿਆ ਅਤੇ ਇਸ ਸਿੱਟੇ 'ਤੇ ਪਹੁੰਚੇ ਕਿ ਮੋਨੋਲਿਥ ਦੀਆਂ ਕਈ ਸਮੱਸਿਆਵਾਂ ਹਨ: ਆਕਾਰ, ਕਨੈਕਟੀਵਿਟੀ, ਡਿਪਲਾਇਮੈਂਟ, ਸਕੇਲੇਬਿਲਟੀ, ਭਰੋਸੇਯੋਗਤਾ ਅਤੇ ਕਠੋਰਤਾ।

ਇਸ ਵਾਰ ਮੈਂ ਮੈਡਿਊਲ/ਲਾਇਬ੍ਰੇਰੀਆਂ (ਕੰਪੋਨੈਂਟ-ਅਧਾਰਿਤ ਆਰਕੀਟੈਕਚਰ) ਜਾਂ ਸੇਵਾਵਾਂ (ਸੇਵਾ-ਅਧਾਰਿਤ ਆਰਕੀਟੈਕਚਰ) ਦੇ ਇੱਕ ਸੈੱਟ ਦੇ ਰੂਪ ਵਿੱਚ ਇੱਕ ਸਿਸਟਮ ਨੂੰ ਸੰਗਠਿਤ ਕਰਨ ਦੀਆਂ ਸੰਭਾਵਨਾਵਾਂ ਬਾਰੇ ਗੱਲ ਕਰਨ ਦਾ ਪ੍ਰਸਤਾਵ ਕਰਦਾ ਹਾਂ।

ਕੰਪੋਨੈਂਟ-ਅਧਾਰਿਤ ਆਰਕੀਟੈਕਚਰ

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

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

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

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

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

ਸੇਵਾ-ਅਧਾਰਿਤ ਆਰਕੀਟੈਕਚਰ

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

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

ਪਰ ਸਭ ਕੁਝ ਇੰਨਾ ਨਿਰਵਿਘਨ ਨਹੀਂ ਹੈ: SOA ਨਵੀਆਂ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਰਿਮੋਟ ਕਾਲਾਂ ਸਥਾਨਕ ਕਾਲਾਂ ਨਾਲੋਂ ਵਧੇਰੇ ਮਹਿੰਗੀਆਂ ਹਨ, ਅਤੇ ਭਾਗਾਂ ਵਿਚਕਾਰ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਨੂੰ ਮੁੜ ਵੰਡਣਾ ਕਾਫ਼ੀ ਮਹਿੰਗਾ ਹੋ ਗਿਆ ਹੈ।

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

ਸੇਵਾ-ਮੁਖੀ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਆਰਕੀਟੈਕਚਰਲ ਕਮਿਊਨਿਟੀ ਅਤੇ ਵਿਕਰੇਤਾਵਾਂ ਦੁਆਰਾ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਮਰਥਨ ਪ੍ਰਾਪਤ ਹੈ। ਇਹ ਬਹੁਤ ਸਾਰੇ ਕੋਰਸਾਂ ਅਤੇ ਪ੍ਰਮਾਣੀਕਰਣਾਂ, ਚੰਗੀ ਤਰ੍ਹਾਂ ਵਿਕਸਤ ਪੈਟਰਨ ਦੀ ਮੌਜੂਦਗੀ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਬਾਅਦ ਵਾਲੇ ਵਿੱਚ, ਉਦਾਹਰਨ ਲਈ, ਮਸ਼ਹੂਰ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਸਰਵਿਸ ਬੱਸ (ESB = ਐਂਟਰਪ੍ਰਾਈਜ਼ ਸਰਵਿਸ ਬੱਸ) ਸ਼ਾਮਲ ਹੈ। ਇਸਦੇ ਨਾਲ ਹੀ, ESB ਵਿਕਰੇਤਾਵਾਂ ਤੋਂ ਇੱਕ ਸਮਾਨ ਹੈ; ਇਹ ਜ਼ਰੂਰੀ ਨਹੀਂ ਹੈ ਕਿ ਇਹ SOA ਵਿੱਚ ਵਰਤਿਆ ਜਾਵੇ।

ਸੇਵਾ-ਮੁਖੀ ਆਰਕੀਟੈਕਚਰ ਦੀ ਪ੍ਰਸਿੱਧੀ 2008 ਦੇ ਆਸ-ਪਾਸ ਸਿਖਰ 'ਤੇ ਪਹੁੰਚ ਗਈ, ਜਿਸ ਤੋਂ ਬਾਅਦ ਇਹ ਘਟਣਾ ਸ਼ੁਰੂ ਹੋ ਗਿਆ, ਜੋ ਮਾਈਕ੍ਰੋਸਰਵਿਸਿਜ਼ (~2015) ਦੇ ਆਗਮਨ ਤੋਂ ਬਾਅਦ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਹੋਰ ਨਾਟਕੀ ਬਣ ਗਿਆ।

ਸਿੱਟਾ

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

ਸਰੋਤ: www.habr.com