ਮੋਨੋਲਿਥ ਤੋਂ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਵਿੱਚ ਤਬਦੀਲੀ: ਇਤਿਹਾਸ ਅਤੇ ਅਭਿਆਸ

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

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

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

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

ਸਮੱਗਰੀ

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

ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਮੌਜੂਦਾ ਹੱਲ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ

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

ਪਿਛਲੇ ਹੱਲ ਦੇ ਨੁਕਸਾਨ

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

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

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

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

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

ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਤੋਂ ਉਮੀਦਾਂ

ਤਿਆਰ ਹੋਣ 'ਤੇ ਭਾਗਾਂ ਦਾ ਮੁੱਦਾ। ਘੋਲ ਨੂੰ ਕੰਪੋਜ਼ ਕਰਕੇ ਅਤੇ ਵੱਖ-ਵੱਖ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਵੱਖ ਕਰਕੇ ਤਿਆਰ ਹੋਣ 'ਤੇ ਭਾਗਾਂ ਦੀ ਸਪੁਰਦਗੀ।

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

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

ਤੈਨਾਤੀ ਲਚਕਤਾ। ਅਸੀਂ ਸੇਵਾਵਾਂ ਨੂੰ ਉਸ ਤਰੀਕੇ ਨਾਲ ਜੋੜਨਾ ਚਾਹੁੰਦੇ ਹਾਂ ਜਿਸ ਤਰ੍ਹਾਂ ਸਾਨੂੰ ਇਸਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਨਾ ਕਿ ਜਿਸ ਤਰੀਕੇ ਨਾਲ ਕੋਡ ਇਸਨੂੰ ਮਜਬੂਰ ਕਰਦਾ ਹੈ।

ਨਵੀਆਂ ਤਕਨੀਕਾਂ ਦੀ ਵਰਤੋਂ. ਇਹ ਕਿਸੇ ਵੀ ਪ੍ਰੋਗਰਾਮਰ ਲਈ ਦਿਲਚਸਪ ਹੈ.

ਪਰਿਵਰਤਨ ਸਮੱਸਿਆਵਾਂ

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

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

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

ਤੀਜੀ ਸਮੱਸਿਆ - ਲੋੜੀਂਦੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਘਾਟ। ਵਾਸਤਵ ਵਿੱਚ, ਅਸੀਂ ਸਰਵਰਾਂ ਲਈ ਸਰੋਤ ਕੋਡ ਨੂੰ ਮੈਨੂਅਲੀ ਕਾਪੀ ਕਰ ਰਹੇ ਸੀ।

ਮੋਨੋਲਿਥ ਤੋਂ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਤੱਕ ਕਿਵੇਂ ਜਾਣਾ ਹੈ

ਮਾਈਕਰੋ ਸੇਵਾਵਾਂ ਦਾ ਪ੍ਰਬੰਧ ਕਰਨਾ

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

ਅਸੀਂ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਨੂੰ ਅਲੱਗ ਕਰਨ ਲਈ ਕਿਹੜੇ ਤਰੀਕੇ ਵਰਤਦੇ ਹਾਂ?

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

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

ਹੋਸਟ ਦੇ ਨਾਲ ਅਸੈਂਬਲੀ ਪ੍ਰੋਗਰਾਮ ਕਲਾਸ ਵਿੱਚ ਕੋਡ ਦੀ ਸਿਰਫ਼ ਇੱਕ ਲਾਈਨ ਹੈ। ਅਸੀਂ ਇੱਕ ਸਹਾਇਕ ਕਲਾਸ ਵਿੱਚ ਟੌਪਸ਼ੇਲਫ ਨਾਲ ਕੰਮ ਨੂੰ ਛੁਪਾਇਆ।

namespace RBA.Services.Accounts.Host
{
   internal class Program
   {
      private static void Main(string[] args)
      {
        HostRunner<Accounts>.Run("RBA.Services.Accounts.Host");

       }
    }
}

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

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

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

ਜੇ ਤੁਸੀਂ UI ਹਿੱਸੇ ਦੇ ਕੋਡ ਤੋਂ ਇੱਕ ਅਸਲੀ ਉਦਾਹਰਨ ਦੇਖਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਇਸ ਹੱਲ ਵਿੱਚ ਜ਼ਿਆਦਾਤਰ ਅਸਲ ਵਪਾਰਕ ਤਰਕ ਸ਼ਾਮਲ ਹਨ ਜੋ ਹੋਰ ਪ੍ਰਕਿਰਿਆਵਾਂ ਵਿੱਚ ਉਪਯੋਗੀ ਹਨ, ਨਾ ਕਿ ਸਿਰਫ਼ UI ਫਾਰਮ ਬਣਾਉਣ ਲਈ।

ਅਸਲ UI ਤਰਕ ਸਿਰਫ ਆਖਰੀ ਦੋ ਲਾਈਨਾਂ ਵਿੱਚ ਹੈ। ਅਸੀਂ ਇਸਨੂੰ ਸਰਵਰ 'ਤੇ ਟ੍ਰਾਂਸਫਰ ਕੀਤਾ ਹੈ ਤਾਂ ਜੋ ਇਸਨੂੰ ਦੁਬਾਰਾ ਵਰਤਿਆ ਜਾ ਸਕੇ, ਜਿਸ ਨਾਲ UI ਨੂੰ ਘਟਾਇਆ ਜਾ ਸਕੇ ਅਤੇ ਸਹੀ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਪ੍ਰਾਪਤ ਕੀਤਾ ਜਾ ਸਕੇ।

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

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

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

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

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

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

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

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

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

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

ਇੱਕ ਸਫਲ ਪਾਇਲਟ ਦੇ ਨਾਲ, ਅਸੀਂ ਸਮਝਦੇ ਹਾਂ ਕਿ ਨਵੀਂ ਸੰਰਚਨਾ ਅਸਲ ਵਿੱਚ ਕੰਮ ਕਰਨ ਯੋਗ ਹੈ, ਅਸੀਂ ਸਮੀਕਰਨ ਤੋਂ ਪੁਰਾਣੇ ਮੋਨੋਲਿਥ ਨੂੰ ਹਟਾ ਸਕਦੇ ਹਾਂ ਅਤੇ ਪੁਰਾਣੇ ਹੱਲ ਦੀ ਥਾਂ 'ਤੇ ਨਵੀਂ ਸੰਰਚਨਾ ਛੱਡ ਸਕਦੇ ਹਾਂ।

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

ਡਾਟਾਬੇਸ ਨਾਲ ਕੰਮ ਕਰਨਾ

ਡੇਟਾਬੇਸ ਨੂੰ ਸਰੋਤ ਕੋਡ ਨਾਲੋਂ ਵੀ ਭੈੜਾ ਵੰਡਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਸ ਵਿੱਚ ਨਾ ਸਿਰਫ ਮੌਜੂਦਾ ਸਕੀਮਾ ਹੈ, ਬਲਕਿ ਇਤਿਹਾਸਕ ਡੇਟਾ ਵੀ ਸ਼ਾਮਲ ਹੈ।

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

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

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

ਅਸੀਂ ਡਾਟਾਬੇਸ ਵਿਭਾਗੀਕਰਨ ਦੇ ਦੋ ਗਲੋਬਲ ਤਰੀਕਿਆਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਹੈ: ਮੌਜੂਦਾ ਟੇਬਲਾਂ ਨੂੰ ਵੰਡਣਾ ਅਤੇ ਪ੍ਰੋਸੈਸਿੰਗ ਨਾਲ ਵੰਡਣਾ।

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

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

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

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

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

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

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

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

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

ਇਸ ਸਕੀਮ ਦੇ ਕੰਮ ਕਰਨ ਲਈ, ਸਾਨੂੰ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਇੱਕ ਤਬਦੀਲੀ ਦੀ ਮਿਆਦ ਦੀ ਲੋੜ ਪਵੇਗੀ।

ਫਿਰ ਦੋ ਸੰਭਵ ਤਰੀਕੇ ਹਨ.

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

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

ਦੋਵੇਂ ਤਰੀਕੇ ਕੰਮ ਕਰਦੇ ਹਨ, ਸਥਿਤੀ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ ਚੁਣੋ।

ਜਦੋਂ ਅਸੀਂ ਇਹ ਯਕੀਨੀ ਹੋ ਜਾਂਦੇ ਹਾਂ ਕਿ ਸਭ ਕੁਝ ਕੰਮ ਕਰਦਾ ਹੈ, ਤਾਂ ਮੋਨੋਲਿਥ ਦਾ ਉਹ ਹਿੱਸਾ ਜੋ ਪੁਰਾਣੇ ਡੇਟਾਬੇਸ ਢਾਂਚੇ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ ਨੂੰ ਅਸਮਰੱਥ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਆਖਰੀ ਕਦਮ ਹੈ ਪੁਰਾਣੇ ਡਾਟਾ ਢਾਂਚੇ ਨੂੰ ਹਟਾਉਣਾ।

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

ਸਰੋਤ ਕੋਡ ਨਾਲ ਕੰਮ ਕਰਨਾ

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

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

ਅਸੀਂ ਖੁਸ਼ਕਿਸਮਤ ਸੀ ਕਿ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਲਾਇਬ੍ਰੇਰੀਆਂ ਸਨ ਜੋ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਵਰਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਸਨ।

ਕਈ ਵਾਰ ਅਜਿਹੀ ਸਥਿਤੀ ਪੈਦਾ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਕੁਝ ਆਮ ਵਸਤੂਆਂ ਅਸਲ ਵਿੱਚ ਇਸ ਪਰਤ ਨਾਲ ਸਬੰਧਤ ਨਹੀਂ ਸਨ, ਪਰ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਲਾਇਬ੍ਰੇਰੀਆਂ ਸਨ। ਇਹ ਨਾਮ ਬਦਲ ਕੇ ਹੱਲ ਕੀਤਾ ਗਿਆ ਸੀ।

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

ਅਸੀਂ ਕੋਡ ਵੰਡਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਲਈ ਕਈ ਨਿਯਮ ਤਿਆਰ ਕੀਤੇ ਹਨ।

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

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

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

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

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

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

ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ

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

ਵਾਤਾਵਰਣ ਵਿੱਚ ਦਸਤੀ ਇੰਸਟਾਲੇਸ਼ਨ

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

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

ਵੱਖਰਾ ਲਾਗਿੰਗ

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

ਫਾਈਲਬੀਟ ਨਾਲ ਅਸੀਂ ਆਪਣੇ ਲੌਗ ਇਕੱਠੇ ਕਰਨ ਦੇ ਯੋਗ ਹਾਂ ਸਰਵਰ, ਫਿਰ ਉਹਨਾਂ ਨੂੰ ਬਦਲੋ, UI ਵਿੱਚ ਪੁੱਛਗਿੱਛਾਂ ਬਣਾਉਣ ਲਈ ਕਿਬਾਨਾ ਦੀ ਵਰਤੋਂ ਕਰੋ, ਅਤੇ ਦੇਖੋ ਕਿ ਸੇਵਾਵਾਂ ਵਿਚਕਾਰ ਕਾਲ ਕਿਵੇਂ ਰੂਟ ਕੀਤੀ ਗਈ ਸੀ। ਟਰੇਸ ਆਈਡੀ ਇਸ ਲਈ ਬਹੁਤ ਮਦਦਗਾਰ ਹਨ।

ਸਬੰਧਿਤ ਸੇਵਾਵਾਂ ਦੀ ਜਾਂਚ ਅਤੇ ਡੀਬੱਗਿੰਗ

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

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

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

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

ਅਸੀਂ ਕੀ ਪ੍ਰਾਪਤ ਕੀਤਾ ਹੈ?

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

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

ਅਸੀਂ ਤੈਨਾਤੀ ਪੈਟਰਨ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰ ਸਕਦੇ ਹਾਂ। ਜੇਕਰ ਲੋੜ ਹੋਵੇ, ਤਾਂ ਤੁਸੀਂ ਬਾਕੀ ਦੇ ਹੱਲ ਤੋਂ ਵੱਖ-ਵੱਖ ਸੇਵਾਵਾਂ ਦੇ ਸਮੂਹਾਂ ਦੀ ਚੋਣ ਕਰ ਸਕਦੇ ਹੋ।

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

ਸੰਖੇਪ

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

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

  PS ਇੱਕ ਹੋਰ ਭਾਵਨਾਤਮਕ ਕਹਾਣੀ (ਅਤੇ ਜਿਵੇਂ ਕਿ ਤੁਹਾਡੇ ਲਈ ਨਿੱਜੀ ਤੌਰ 'ਤੇ) - ਅਨੁਸਾਰ ਲਿੰਕ ਨੂੰ.
  ਇੱਥੇ ਰਿਪੋਰਟ ਦਾ ਪੂਰਾ ਸੰਸਕਰਣ ਹੈ.

ਸਰੋਤ: www.habr.com