ਡੋਡੋ IS ਦਾ ਆਰਕੀਟੈਕਚਰਲ ਹਿਸਟਰੀ: ਐਨ ਅਰਲੀ ਮੋਨੋਲਿਥ

ਜਾਂ ਮੋਨੋਲੀਥ ਵਾਲੀ ਹਰ ਨਾਖੁਸ਼ ਕੰਪਨੀ ਆਪਣੇ ਤਰੀਕੇ ਨਾਲ ਨਾਖੁਸ਼ ਹੈ.

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

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

ਲੇਖਾਂ ਦੀ ਲੜੀ "ਡੋਡੋ ਆਈਐਸ ਕੀ ਹੈ?" ਬਾਰੇ ਦੱਸੇਗਾ:

1. ਡੋਡੋ IS (2011-2015) ਵਿੱਚ ਸ਼ੁਰੂਆਤੀ ਮੋਨੋਲਿਥ। (ਤੁਸੀਂ ਇੱਥੇ ਹੋ)

2. ਬੈਕਆਫਿਸ ਮਾਰਗ: ਵੱਖਰੇ ਬੇਸ ਅਤੇ ਬੱਸ.

3. ਕਲਾਇੰਟ ਦੇ ਹਿੱਸੇ ਦਾ ਮਾਰਗ: ਅਧਾਰ ਦੇ ਉੱਪਰ ਦਾ ਨਕਾਬ (2016-2017)। (ਤਰੱਕੀ ਹੋ ਰਹੀ ਹੈ...)

4. ਅਸਲੀ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਦਾ ਇਤਿਹਾਸ। (2018-2019)। (ਤਰੱਕੀ ਹੋ ਰਹੀ ਹੈ...)

5. ਮੋਨੋਲਿਥ ਦੀ ਪੂਰੀ ਕਟਾਈ ਅਤੇ ਆਰਕੀਟੈਕਚਰ ਦੀ ਸਥਿਰਤਾ. (ਤਰੱਕੀ ਹੋ ਰਹੀ ਹੈ...)

ਮੁੱਢਲਾ ਆਰਕੀਟੈਕਚਰ

2011 ਵਿੱਚ, ਡੋਡੋ IS ਆਰਕੀਟੈਕਚਰ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਸੀ:

ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ ਪਹਿਲਾ ਮੋਡੀਊਲ ਆਰਡਰ ਸਵੀਕ੍ਰਿਤੀ ਹੈ। ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆ ਇਸ ਤਰ੍ਹਾਂ ਸੀ:

• ਇੱਕ ਗਾਹਕ ਪੀਜ਼ੇਰੀਆ ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ;

• ਮੈਨੇਜਰ ਫ਼ੋਨ ਚੁੱਕਦਾ ਹੈ;

• ਫ਼ੋਨ 'ਤੇ ਆਰਡਰ ਲੈਂਦਾ ਹੈ;

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

ਸੂਚਨਾ ਸਿਸਟਮ ਇੰਟਰਫੇਸ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ ...

ਅਕਤੂਬਰ 2011 ਤੋਂ ਪਹਿਲਾ ਸੰਸਕਰਣ:

ਜਨਵਰੀ 2012 ਵਿੱਚ ਥੋੜ੍ਹਾ ਸੁਧਾਰ ਹੋਇਆ

ਜਾਣਕਾਰੀ ਪ੍ਰਣਾਲੀ ਡੋਡੋ ਪੀਜ਼ਾ ਡਿਲਿਵਰੀ ਪੀਜ਼ਾ ਰੈਸਟੋਰੈਂਟ

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

ਉਹਨਾਂ ਦੇ ਪਹਿਲੇ ਫੈਸਲੇ ਨੇ ਤਕਨਾਲੋਜੀ ਸਟੈਕ ਦੀ ਭਵਿੱਖ ਦੀ ਕਿਸਮਤ ਨੂੰ ਨਿਰਧਾਰਤ ਕੀਤਾ:

• ASP.NET MVC, C# ਭਾਸ਼ਾ 'ਤੇ ਬੈਕਐਂਡ। ਡਿਵੈਲਪਰ ਡਾਟਨੇਟਰ ਸਨ; ਇਹ ਸਟੈਕ ਉਹਨਾਂ ਲਈ ਜਾਣੂ ਅਤੇ ਸੁਹਾਵਣਾ ਸੀ।

• Bootstrap ਅਤੇ JQuery 'ਤੇ ਫਰੰਟਐਂਡ: ਕਸਟਮ ਸਟਾਈਲ ਅਤੇ ਸਕ੍ਰਿਪਟਾਂ 'ਤੇ ਆਧਾਰਿਤ ਯੂਜ਼ਰ ਇੰਟਰਫੇਸ। 

• MySQL ਡੇਟਾਬੇਸ: ਕੋਈ ਲਾਇਸੈਂਸ ਦੀ ਲਾਗਤ ਨਹੀਂ, ਵਰਤੋਂ ਵਿੱਚ ਆਸਾਨ।

• ਵਿੰਡੋਜ਼ ਸਰਵਰ 'ਤੇ ਸਰਵਰ, ਕਿਉਂਕਿ .NET ਤਦ ਸਿਰਫ ਵਿੰਡੋਜ਼ 'ਤੇ ਹੋ ਸਕਦਾ ਹੈ (ਅਸੀਂ ਮੋਨੋ ਬਾਰੇ ਚਰਚਾ ਨਹੀਂ ਕਰਾਂਗੇ)।

ਸਰੀਰਕ ਤੌਰ 'ਤੇ, ਇਹ ਸਭ "ਹੋਸਟਰ ਦੇ ਡੈਸਕ" ਵਿੱਚ ਪ੍ਰਗਟ ਕੀਤਾ ਗਿਆ ਸੀ। 

ਆਰਡਰ ਸਵੀਕ੍ਰਿਤੀ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਆਰਕੀਟੈਕਚਰ

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

ਲਵੋ, ਇਹ ਹੈ.

Asp.Net MVC ਰੇਜ਼ਰ ਹੈ, ਜੋ ਕਿ ਕਿਸੇ ਫਾਰਮ ਜਾਂ ਕਲਾਇੰਟ ਤੋਂ ਬੇਨਤੀ ਕਰਨ 'ਤੇ, ਸਰਵਰ 'ਤੇ ਰੈਂਡਰਿੰਗ ਦੇ ਨਾਲ ਇੱਕ HTML ਪੇਜ ਤਿਆਰ ਕਰਦਾ ਹੈ। ਕਲਾਇੰਟ 'ਤੇ, CSS ਅਤੇ JS ਸਕ੍ਰਿਪਟਾਂ ਪਹਿਲਾਂ ਹੀ ਜਾਣਕਾਰੀ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦੀਆਂ ਹਨ ਅਤੇ, ਜੇ ਲੋੜ ਹੋਵੇ, JQuery ਦੁਆਰਾ AJAX ਬੇਨਤੀਆਂ ਨੂੰ ਪੂਰਾ ਕਰਦੀਆਂ ਹਨ।

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

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

• ReceivingOrdersService ਨੇ ਆਰਡਰ ਦੀ ਸਮੱਗਰੀ ਨੂੰ ਪ੍ਰਾਪਤ ਕੀਤਾ ਅਤੇ ਉਸ ਦੀ ਗਣਨਾ ਕੀਤੀ।

• ਅਤੇ SmsService ਨੇ SMS ਭੇਜਣ ਲਈ API ਸੇਵਾਵਾਂ ਨੂੰ ਕਾਲ ਕਰਕੇ SMS ਭੇਜਿਆ ਹੈ।

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

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

ਇਹ ਸਭ ਇਸ ਮਾਡਲ ਦੁਆਰਾ ਦਰਸਾਇਆ ਜਾ ਸਕਦਾ ਹੈ:

ਆਰਡਰ ਦਾ ਤਰੀਕਾ

ਆਉ ਅਜਿਹੇ ਆਰਡਰ ਨੂੰ ਬਣਾਉਣ ਲਈ ਇੱਕ ਸਰਲ ਸ਼ੁਰੂਆਤੀ ਤਰੀਕੇ 'ਤੇ ਵਿਚਾਰ ਕਰੀਏ.

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

• ਗਾਹਕ ਕੀਮਤਾਂ ਦੇ ਨਾਲ ਇੱਕ ਸਥਿਰ ਵੈੱਬਸਾਈਟ 'ਤੇ ਜਾਂਦਾ ਹੈ, ਉਤਪਾਦ ਚੁਣਦਾ ਹੈ ਅਤੇ ਵੈੱਬਸਾਈਟ 'ਤੇ ਦਰਸਾਏ ਨੰਬਰ 'ਤੇ ਕਾਲ ਕਰਦਾ ਹੈ।

• ਗਾਹਕ ਉਹਨਾਂ ਉਤਪਾਦਾਂ ਦਾ ਨਾਮ ਦਿੰਦਾ ਹੈ ਜੋ ਉਹ ਆਰਡਰ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ।

• ਆਪਣਾ ਪਤਾ ਅਤੇ ਨਾਮ ਦਿੰਦਾ ਹੈ।

• ਆਪਰੇਟਰ ਆਰਡਰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ।

• ਆਰਡਰ ਸਵੀਕਾਰ ਕੀਤੇ ਆਰਡਰ ਇੰਟਰਫੇਸ ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਿਤ ਹੁੰਦਾ ਹੈ।

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

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

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

ਅੱਗੇ, ਗਾਹਕ ਦਾ ਪਤਾ ਅਤੇ ਨਾਮ ਦਰਜ ਕਰੋ। 

ਜਦੋਂ ਤੁਸੀਂ "ਆਰਡਰ ਬਣਾਓ" 'ਤੇ ਕਲਿੱਕ ਕਰਦੇ ਹੋ:

• ਅਸੀਂ OrderController.SaveOrder() ਨੂੰ ਬੇਨਤੀ ਭੇਜਦੇ ਹਾਂ।

• ਅਸੀਂ ਸੈਸ਼ਨ ਤੋਂ ਕਾਰਟ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ, ਸਾਨੂੰ ਲੋੜੀਂਦੀ ਮਾਤਰਾ ਵਿੱਚ ਉਤਪਾਦ ਹਨ.

• ਅਸੀਂ ਕਲਾਇੰਟ ਬਾਰੇ ਜਾਣਕਾਰੀ ਦੇ ਨਾਲ ਕਾਰਟ ਨੂੰ ਪੂਰਕ ਕਰਦੇ ਹਾਂ ਅਤੇ ਇਸਨੂੰ RecevingOrderService ਕਲਾਸ ਦੇ AddOrder ਵਿਧੀ ਵਿੱਚ ਪਾਸ ਕਰਦੇ ਹਾਂ, ਜਿੱਥੇ ਇਸਨੂੰ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। 

• ਡੇਟਾਬੇਸ ਵਿੱਚ ਆਰਡਰ ਦੇ ਨਾਲ ਟੇਬਲ, ਆਰਡਰ ਦੀ ਸਮੱਗਰੀ, ਕਲਾਇੰਟ, ਅਤੇ ਉਹ ਸਾਰੇ ਜੁੜੇ ਹੋਏ ਹਨ।

• ਆਰਡਰ ਡਿਸਪਲੇਅ ਇੰਟਰਫੇਸ ਜਾਂਦਾ ਹੈ ਅਤੇ ਨਵੀਨਤਮ ਆਰਡਰ ਕੱਢਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦਾ ਹੈ।

ਨਵੇਂ ਮੋਡੀਊਲ

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

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

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

ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ, ਮੋਡੀਊਲ ਨੂੰ ਖੇਤਰ ਦੇ ਤੌਰ 'ਤੇ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਸੀ (ਇਹ ਵਿਚਾਰ ਵੀ ਇਸ ਵਿੱਚ ਰਿਹਾ asp.net ਕੋਰ). ਫਰੰਟਐਂਡ, ਮਾਡਲਾਂ ਦੇ ਨਾਲ-ਨਾਲ ਉਹਨਾਂ ਦੀਆਂ ਆਪਣੀਆਂ ਕੰਟਰੋਲਰ ਕਲਾਸਾਂ ਲਈ ਵੱਖਰੀਆਂ ਫਾਈਲਾਂ ਸਨ. ਨਤੀਜੇ ਵਜੋਂ, ਸਿਸਟਮ ਨੂੰ ਅਜਿਹੇ ਤੋਂ ਬਦਲ ਦਿੱਤਾ ਗਿਆ ਸੀ ...

...ਇਸ ਲਈ:

ਕੁਝ ਮੋਡੀਊਲ ਵੱਖਰੀਆਂ ਸਾਈਟਾਂ (ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਪ੍ਰੋਜੈਕਟ) ਦੁਆਰਾ ਲਾਗੂ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰੀ ਕਾਰਜਸ਼ੀਲਤਾ ਦੇ ਕਾਰਨ ਅਤੇ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਕੁਝ ਵੱਖਰੇ, ਵਧੇਰੇ ਕੇਂਦਰਿਤ ਵਿਕਾਸ ਦੇ ਕਾਰਨ। ਇਹ:

• ਸਾਈਟ - ਪਹਿਲਾ ਵਰਜਨ ਵੈੱਬਸਾਈਟ dodopizza.ru.

• ਨਿਰਯਾਤ: 1C ਲਈ ਡੋਡੋ ਆਈਐਸ ਤੋਂ ਰਿਪੋਰਟਾਂ ਨੂੰ ਡਾਊਨਲੋਡ ਕਰਨਾ। 

• ਨਿੱਜੀ - ਕਰਮਚਾਰੀ ਦਾ ਨਿੱਜੀ ਖਾਤਾ। ਇਹ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਵਿਕਸਤ ਕੀਤਾ ਗਿਆ ਸੀ ਅਤੇ ਇਸਦਾ ਆਪਣਾ ਪ੍ਰਵੇਸ਼ ਬਿੰਦੂ ਅਤੇ ਵੱਖਰਾ ਡਿਜ਼ਾਈਨ ਹੈ।

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

ਬਾਕੀ ਬਚੇ ਬਲਾਕ ਬੈਕਆਫਿਸ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਸਥਿਤ ਸਨ। 

ਨਾਵਾਂ ਦੀ ਵਿਆਖਿਆ:

• ਕੈਸ਼ੀਅਰ - ਰੈਸਟੋਰੈਂਟ ਕੈਸ਼ ਰਜਿਸਟਰ।

• ShiftManager - "Shift Manager" ਰੋਲ ਲਈ ਇੰਟਰਫੇਸ: ਪਿਜ਼ੇਰੀਆ ਦੀ ਵਿਕਰੀ 'ਤੇ ਸੰਚਾਲਨ ਅੰਕੜੇ, ਉਤਪਾਦਾਂ ਨੂੰ ਸਟਾਪ ਸੂਚੀ ਵਿੱਚ ਰੱਖਣ ਦੀ ਯੋਗਤਾ, ਇੱਕ ਆਰਡਰ ਬਦਲਣਾ।

• OfficeManager - "Pizzeria Manager" ਅਤੇ "Franchisee" ਰੋਲ ਲਈ ਇੰਟਰਫੇਸ। ਇੱਥੇ ਤੁਸੀਂ ਇੱਕ ਪੀਜ਼ੇਰੀਆ ਸਥਾਪਤ ਕਰਨ, ਇਸਦੇ ਬੋਨਸ ਪ੍ਰੋਮੋਸ਼ਨ, ਕਰਮਚਾਰੀਆਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਅਤੇ ਉਹਨਾਂ ਨਾਲ ਕੰਮ ਕਰਨ, ਅਤੇ ਰਿਪੋਰਟਾਂ ਲਈ ਫੰਕਸ਼ਨ ਲੱਭ ਸਕਦੇ ਹੋ।

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

ਉਹਨਾਂ ਨੇ ਇੱਕ ਆਮ ਸੇਵਾ ਪਰਤ, Dodo.Core ਡੋਮੇਨ ਕਲਾਸਾਂ ਦਾ ਇੱਕ ਸਾਂਝਾ ਬਲਾਕ, ਅਤੇ ਇੱਕ ਸਾਂਝਾ ਅਧਾਰ ਵਰਤਿਆ। ਕਦੇ-ਕਦੇ ਉਹ ਅਜੇ ਵੀ ਇੱਕ ਦੂਜੇ ਤੱਕ ਪੈਸਿਆਂ ਰਾਹੀਂ ਅਗਵਾਈ ਕਰ ਸਕਦੇ ਸਨ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਵਿਅਕਤੀਗਤ ਸਾਈਟਾਂ, ਜਿਵੇਂ ਕਿ dodopizza.ru ਜਾਂ personal.dodopizza.ru, ਨੇ ਵੀ ਆਮ ਸੇਵਾਵਾਂ ਤੱਕ ਪਹੁੰਚ ਕੀਤੀ ਹੈ।

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

ਸਿਸਟਮ ਵਿੱਚ ਬਣਾਏ ਗਏ ਮਾਡਿਊਲਾਂ ਦੇ ਪੈਮਾਨੇ ਦੀ ਬਿਹਤਰ ਸਮਝ ਲਈ, ਇੱਥੇ ਵਿਕਾਸ ਯੋਜਨਾਵਾਂ ਦੇ ਨਾਲ 2012 ਦਾ ਇੱਕ ਚਿੱਤਰ ਹੈ:

2015 ਤੱਕ, ਸਭ ਕੁਝ ਟਰੈਕ 'ਤੇ ਸੀ ਅਤੇ ਹੋਰ ਵੀ ਉਤਪਾਦਨ ਵਿੱਚ ਸੀ।

• ਆਰਡਰ ਸਵੀਕ੍ਰਿਤੀ ਸੰਪਰਕ ਕੇਂਦਰ ਦੇ ਇੱਕ ਵੱਖਰੇ ਬਲਾਕ ਵਿੱਚ ਵਧ ਗਈ ਹੈ, ਜਿੱਥੇ ਓਪਰੇਟਰ ਦੁਆਰਾ ਆਰਡਰ ਸਵੀਕਾਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

• ਮੀਨੂ ਅਤੇ ਜਾਣਕਾਰੀ ਵਾਲੀਆਂ ਜਨਤਕ ਸਕ੍ਰੀਨਾਂ ਪਿਜ਼ੇਰੀਆ ਵਿੱਚ ਦਿਖਾਈ ਦਿੱਤੀਆਂ ਹਨ।

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

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

ਸਮਾਨਾਂਤਰ ਵਿੱਚ, 2012 ਤੋਂ 2015 ਤੱਕ, 10 ਤੋਂ ਵੱਧ ਡਿਵੈਲਪਰ ਪ੍ਰਗਟ ਹੋਏ, 35 ਪਿਜ਼ੇਰੀਆ ਖੋਲ੍ਹੇ ਗਏ, ਸਿਸਟਮ ਨੂੰ ਰੋਮਾਨੀਆ ਵਿੱਚ ਤਾਇਨਾਤ ਕੀਤਾ ਗਿਆ ਅਤੇ ਸੰਯੁਕਤ ਰਾਜ ਅਮਰੀਕਾ ਵਿੱਚ ਪੁਆਇੰਟ ਖੋਲ੍ਹਣ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ। ਡਿਵੈਲਪਰ ਹੁਣ ਸਾਰੇ ਕੰਮਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਸਨ, ਪਰ ਟੀਮਾਂ ਵਿੱਚ ਵੰਡੇ ਗਏ ਸਨ। ਹਰੇਕ ਸਿਸਟਮ ਦੇ ਆਪਣੇ ਹਿੱਸੇ ਵਿੱਚ ਵਿਸ਼ੇਸ਼ ਹੈ। 

ਸਮੱਸਿਆਵਾਂ

ਆਰਕੀਟੈਕਚਰ ਦੇ ਕਾਰਨ (ਪਰ ਨਾ ਸਿਰਫ) ਸਮੇਤ.

ਅਧਾਰ ਵਿੱਚ ਹਫੜਾ-ਦਫੜੀ

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

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

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

ਟੇਬਲ ਵਿੱਚ ਡੇਟਾ ਹਮੇਸ਼ਾ ਸਭ ਤੋਂ ਢੁਕਵੇਂ ਰੂਪ ਵਿੱਚ ਨਹੀਂ ਸੀ. ਕਿਤੇ ਡੀਨੋਰਮਲਾਈਜੇਸ਼ਨ ਕਰਨਾ ਜ਼ਰੂਰੀ ਸੀ। ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਪ੍ਰਾਪਤ ਕੀਤੇ ਗਏ ਕੁਝ ਡੇਟਾ ਇੱਕ XML ਢਾਂਚੇ ਦੇ ਰੂਪ ਵਿੱਚ ਇੱਕ ਕਾਲਮ ਵਿੱਚ ਸਨ, ਜਿਸ ਨਾਲ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸਮਾਂ ਵਧਿਆ, ਲੰਮੀ ਪੁੱਛਗਿੱਛ ਅਤੇ ਗੁੰਝਲਦਾਰ ਵਿਕਾਸ ਹੋਇਆ।

ਉਹੀ ਟੇਬਲ ਬਹੁਤ ਦੇ ਅਧੀਨ ਸਨ ਵਿਭਿੰਨ ਬੇਨਤੀਆਂ. ਪ੍ਰਸਿੱਧ ਟੇਬਲ, ਜਿਵੇਂ ਕਿ ਉੱਪਰ ਦੱਸੇ ਸਾਰਣੀ, ਖਾਸ ਤੌਰ 'ਤੇ ਪ੍ਰਭਾਵਿਤ ਹੋਏ ਸਨ ਦੇ ਹੁਕਮ ਜਾਂ ਟੇਬਲ pizzeria. ਉਹ ਰਸੋਈ ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਵਿੱਚ ਕਾਰਜਸ਼ੀਲ ਇੰਟਰਫੇਸ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਨ ਲਈ ਵਰਤੇ ਗਏ ਸਨ। ਸਾਈਟ ਨੇ ਉਨ੍ਹਾਂ ਨਾਲ ਵੀ ਸੰਪਰਕ ਕੀਤਾ (dodopizza.ru), ਜਿੱਥੇ ਬਹੁਤ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਅਚਾਨਕ ਕਿਸੇ ਵੀ ਸਮੇਂ ਆ ਸਕਦੀਆਂ ਹਨ। 

ਡਾਟਾ ਇਕੱਠਾ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ ਅਤੇ ਬੇਸ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਬਹੁਤ ਸਾਰੀਆਂ ਗਣਨਾਵਾਂ ਉੱਡਣ 'ਤੇ ਹੋਈਆਂ। ਇਸ ਨਾਲ ਬੇਲੋੜੀਆਂ ਗਣਨਾਵਾਂ ਅਤੇ ਵਾਧੂ ਲੋਡ ਪੈਦਾ ਹੋਏ। 

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

ਕੋਡ ਵਿੱਚ ਏਕਤਾ ਅਤੇ ਉਲਝਣ

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

ਸੇਵਾਵਾਂ (ਇੱਕ ਮੋਨੋਲੀਥਿਕ ਵੱਡੇ ਪ੍ਰੋਜੈਕਟ ਦੇ ਅੰਦਰ ਕਲਾਸਾਂ) ਇੱਕ ਦੂਜੇ ਨੂੰ ਕਾਲ ਕਰ ਸਕਦੀਆਂ ਹਨ ਤਾਂ ਜੋ ਉਹਨਾਂ ਦੇ ਡੇਟਾ ਨੂੰ ਅਮੀਰ ਬਣਾਇਆ ਜਾ ਸਕੇ।

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

ਤਰਕ ਜਾਂ ਤਾਂ ਨਿਯੰਤਰਕ ਜਾਂ ਸੇਵਾ ਕਲਾਸਾਂ ਵਿੱਚ ਸੀ। 

ਇਹ ਮਾਮੂਲੀ ਸਮੱਸਿਆਵਾਂ ਵਾਂਗ ਜਾਪਦੇ ਹਨ, ਪਰ ਇਹਨਾਂ ਨੇ ਵਿਕਾਸ ਨੂੰ ਬਹੁਤ ਹੌਲੀ ਕਰ ਦਿੱਤਾ ਹੈ ਅਤੇ ਗੁਣਵੱਤਾ ਘਟਾ ਦਿੱਤੀ ਹੈ, ਜਿਸ ਨਾਲ ਅਸਥਿਰਤਾ ਅਤੇ ਬੱਗ ਪੈਦਾ ਹੁੰਦੇ ਹਨ। 

ਵੱਡੇ ਵਿਕਾਸ ਦੀ ਗੁੰਝਲਤਾ

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

ਸਿਸਟਮ ਦੇ ਕੁਝ ਹਿੱਸੇ ਡੇਟਾਬੇਸ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹਨ ਜੋ ਇਸਦੇ ਲਈ ਵਧੇਰੇ ਅਨੁਕੂਲ ਹਨ. ਉਦਾਹਰਨ ਲਈ, ਬਾਅਦ ਵਿੱਚ ਸਾਡੇ ਕੋਲ ਇੱਕ ਆਰਡਰ ਕਾਰਟ ਸਟੋਰ ਕਰਨ ਲਈ Redis ਤੋਂ CosmosDB ਵਿੱਚ ਸਵਿਚ ਕਰਨ ਦੀ ਇੱਕ ਉਦਾਹਰਣ ਸੀ। 

ਉਹਨਾਂ ਦੇ ਖੇਤਰ ਵਿੱਚ ਕੰਮ ਕਰ ਰਹੀਆਂ ਟੀਮਾਂ ਅਤੇ ਡਿਵੈਲਪਰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਵਿਕਾਸ ਅਤੇ ਰੋਲਆਊਟ ਦੇ ਰੂਪ ਵਿੱਚ, ਆਪਣੀਆਂ ਸੇਵਾਵਾਂ ਲਈ ਵਧੇਰੇ ਸੁਤੰਤਰਤਾ ਚਾਹੁੰਦੇ ਸਨ। ਵਿਲੀਨਤਾ ਦੌਰਾਨ ਟਕਰਾਅ, ਰੀਲੀਜ਼ ਦੌਰਾਨ ਸਮੱਸਿਆਵਾਂ। ਜੇ 5 ਡਿਵੈਲਪਰਾਂ ਲਈ ਇਹ ਸਮੱਸਿਆ ਮਾਮੂਲੀ ਹੈ, ਤਾਂ 10 ਦੇ ਨਾਲ, ਅਤੇ ਇਸ ਤੋਂ ਵੀ ਵੱਧ ਯੋਜਨਾਬੱਧ ਵਿਕਾਸ ਦੇ ਨਾਲ, ਸਭ ਕੁਝ ਹੋਰ ਗੰਭੀਰ ਹੋ ਜਾਵੇਗਾ. ਅਤੇ ਜੋ ਆਉਣਾ ਸੀ ਉਹ ਸੀ ਇੱਕ ਮੋਬਾਈਲ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਵਿਕਾਸ (ਇਹ 2017 ਵਿੱਚ ਸ਼ੁਰੂ ਹੋਇਆ ਸੀ, ਅਤੇ 2018 ਵਿੱਚ ਸੀ. ਵੱਡੀ ਗਿਰਾਵਟ). 

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

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

ਬਲੌਗ ਪਾਵਰ ਆਫ਼ ਮਾਈਂਡ ਰੈਸਟੋਰੈਂਟਾਂ ਵਿੱਚ ਕੈਸ਼ ਰਜਿਸਟਰ ਕਿਵੇਂ ਪਾਉਂਦਾ ਹੈ

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

ਬਲੌਗ ਵਿੱਚ "ਮਨ ਦੀ ਸ਼ਕਤੀ"ਇੱਥੇ ਇੱਕ ਵਿਜੇਟ ਸੀ ਜੋ ਪੂਰੇ ਨੈਟਵਰਕ ਲਈ ਸਾਲ ਲਈ ਮਾਲੀਆ ਡੇਟਾ ਦਰਸਾਉਂਦਾ ਸੀ। ਵਿਜੇਟ ਨੇ ਜਨਤਕ ਡੋਡੋ API ਤੱਕ ਪਹੁੰਚ ਕੀਤੀ, ਜੋ ਇਹ ਡੇਟਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਇਹ ਅੰਕੜੇ ਹੁਣ 'ਤੇ ਉਪਲਬਧ ਹਨ http://dodopizzastory.com/. ਵਿਜੇਟ ਹਰ ਪੰਨੇ 'ਤੇ ਦਿਖਾਇਆ ਗਿਆ ਸੀ ਅਤੇ ਹਰ 20 ਸਕਿੰਟਾਂ 'ਤੇ ਟਾਈਮਰ 'ਤੇ ਬੇਨਤੀਆਂ ਕੀਤੀਆਂ ਗਈਆਂ ਸਨ। ਬੇਨਤੀ api.dodopizza.ru 'ਤੇ ਗਈ ਅਤੇ ਪੁੱਛਿਆ:

• ਨੈੱਟਵਰਕ ਵਿੱਚ pizzerias ਦੀ ਗਿਣਤੀ;

• ਸਾਲ ਦੀ ਸ਼ੁਰੂਆਤ ਤੋਂ ਕੁੱਲ ਨੈੱਟਵਰਕ ਮਾਲੀਆ;

• ਅੱਜ ਦੀ ਆਮਦਨ।

ਮਾਲੀਆ ਅੰਕੜਿਆਂ ਲਈ ਇੱਕ ਬੇਨਤੀ ਸਿੱਧੇ ਡੇਟਾਬੇਸ ਵਿੱਚ ਗਈ ਅਤੇ ਆਦੇਸ਼ਾਂ 'ਤੇ ਡੇਟਾ ਦੀ ਬੇਨਤੀ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ, ਫਲਾਈ 'ਤੇ ਸਿੱਧੇ ਡੇਟਾ ਨੂੰ ਇਕੱਠਾ ਕਰੋ ਅਤੇ ਰਕਮ ਜਾਰੀ ਕਰੋ। 

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

ਚਿੱਤਰ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਸੀ:

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

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

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

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

ਤੇਜ਼ੀ ਨਾਲ ਵਪਾਰ ਵਿਕਾਸ

ਇਹ "ਤੁਰੰਤ ਚੰਗੀ ਤਰ੍ਹਾਂ" ਕਿਉਂ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਸੀ? ਸਿਰਫ਼ ਹੇਠਾਂ ਦਿੱਤੇ ਗ੍ਰਾਫ਼ਾਂ ਨੂੰ ਦੇਖੋ।

2014-2015 ਵਿੱਚ ਵੀ ਰੋਮਾਨੀਆ ਵਿੱਚ ਇੱਕ ਓਪਨਿੰਗ ਸੀ ਅਤੇ ਅਮਰੀਕਾ ਵਿੱਚ ਇੱਕ ਓਪਨਿੰਗ ਤਿਆਰ ਕੀਤੀ ਜਾ ਰਹੀ ਸੀ।

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

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

ਤੇਜ਼ ਹੱਲ ਜਿਨ੍ਹਾਂ ਨੇ ਮਦਦ ਕੀਤੀ

ਸਮੱਸਿਆਵਾਂ ਦੇ ਹੱਲ ਦੀ ਲੋੜ ਹੈ। ਰਵਾਇਤੀ ਤੌਰ 'ਤੇ, ਹੱਲਾਂ ਨੂੰ 2 ਸਮੂਹਾਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾ ਸਕਦਾ ਹੈ:

• ਤੇਜ਼ ਲੋਕ ਜੋ ਅੱਗ ਨੂੰ ਬੁਝਾਉਂਦੇ ਹਨ ਅਤੇ ਸਾਨੂੰ ਸੁਰੱਖਿਆ ਦਾ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਅੰਤਰ ਦਿੰਦੇ ਹਨ ਅਤੇ ਸਾਨੂੰ ਬਦਲਣ ਲਈ ਸਮਾਂ ਖਰੀਦਦੇ ਹਨ।

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

ਤੇਜ਼ ਤਬਦੀਲੀਆਂ ਦੀ ਖੁਸ਼ਕ ਸੂਚੀ ਇਹ ਹੈ:

ਬੇਸ ਮਾਸਟਰ ਨੂੰ ਸਕੇਲ ਕਰੋ

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

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

ਪੜ੍ਹਨ ਲਈ ਡਾਟਾਬੇਸ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ

ਅਸੀਂ ਬੇਸ ਲਈ ਦੋ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਬਣਾਈਆਂ:

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

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

ਕੋਡ ਵਿੱਚ ਕੈਸ਼

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

ਬੈਕਐਂਡ ਲਈ ਕਈ ਸਰਵਰ

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

ਨਤੀਜੇ ਵਜੋਂ, ਆਰਕੀਟੈਕਚਰ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਬਣ ਗਿਆ ...

...ਪਰ ਕੁਝ ਤਣਾਅ ਦੂਰ ਹੋ ਗਿਆ ਸੀ।

ਅਤੇ ਫਿਰ ਲੋਡ ਕੀਤੇ ਭਾਗਾਂ ਨੂੰ ਦੁਬਾਰਾ ਕਰਨਾ ਜ਼ਰੂਰੀ ਸੀ, ਜੋ ਅਸੀਂ ਲਿਆ ਹੈ. ਇਸ ਬਾਰੇ ਅਗਲੇ ਭਾਗ ਵਿੱਚ ਗੱਲ ਕਰਾਂਗੇ।

ਸਰੋਤ: www.habr.com