ਡੋਡੋ ਆਈਐਸ ਆਰਕੀਟੈਕਚਰ ਦਾ ਇਤਿਹਾਸ: ਬੈਕ ਆਫਿਸ ਪਾਥ

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

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

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

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

1. ਡੋਡੋ IS (2011-2015) ਵਿੱਚ ਸ਼ੁਰੂਆਤੀ ਮੋਨੋਲਿਥ। (ਤਰੱਕੀ ਹੋ ਰਹੀ ਹੈ...)
2. ਬੈਕਆਫਿਸ ਮਾਰਗ: ਵੱਖਰੇ ਬੇਸ ਅਤੇ ਬੱਸ। (ਤੁਸੀਂ ਇੱਥੇ ਹੋ)
3. ਕਲਾਇੰਟ ਦੇ ਹਿੱਸੇ ਦਾ ਮਾਰਗ: ਅਧਾਰ ਦੇ ਉੱਪਰ ਦਾ ਨਕਾਬ (2016-2017)। (ਤਰੱਕੀ ਹੋ ਰਹੀ ਹੈ...)
4. ਅਸਲੀ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਦਾ ਇਤਿਹਾਸ। (2018-2019)। (ਤਰੱਕੀ ਹੋ ਰਹੀ ਹੈ...)
5. ਮੋਨੋਲਿਥ ਦੀ ਪੂਰੀ ਕਟਾਈ ਅਤੇ ਆਰਕੀਟੈਕਚਰ ਦੀ ਸਥਿਰਤਾ. (ਤਰੱਕੀ ਹੋ ਰਹੀ ਹੈ...)

ਜੇ ਤੁਸੀਂ ਹੋਰ ਕੁਝ ਸਿੱਖਣ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਟਿੱਪਣੀਆਂ ਵਿੱਚ ਲਿਖੋ.

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

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

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

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

2020 ਤੱਕ, ਇਹ ਥੋੜਾ ਹੋਰ ਗੁੰਝਲਦਾਰ ਹੋ ਗਿਆ ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਬਣ ਗਿਆ:

ਇਹ ਵਿਕਾਸ ਕਿਵੇਂ ਹੋਇਆ? ਸਿਸਟਮ ਦੇ ਵੱਖ-ਵੱਖ ਹਿੱਸਿਆਂ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ? ਕੀ ਆਰਕੀਟੈਕਚਰਲ ਫੈਸਲੇ ਲਏ ਗਏ ਸਨ ਅਤੇ ਕਿਉਂ? ਆਓ ਲੇਖਾਂ ਦੀ ਇਸ ਲੜੀ ਵਿੱਚ ਪਤਾ ਕਰੀਏ.

2016 ਦੀਆਂ ਪਹਿਲੀਆਂ ਸਮੱਸਿਆਵਾਂ: ਸੇਵਾਵਾਂ ਨੂੰ ਮੋਨੋਲਿਥ ਕਿਉਂ ਛੱਡਣਾ ਚਾਹੀਦਾ ਹੈ?

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

ਇੱਕ ਸਿੰਗਲ MySql ਡੇਟਾਬੇਸ ਜਿਸ ਵਿੱਚ ਡੋਡੋ IS ਵਿੱਚ ਉਸ ਸਮੇਂ ਮੌਜੂਦ ਸਾਰੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੇ ਆਪਣੇ ਰਿਕਾਰਡ ਲਿਖੇ ਸਨ। ਨਤੀਜੇ ਸਨ:

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

ਸਮੱਸਿਆ ਖੁਦ ਮੋਨੋਲਿਥ ਦੀ ਮੌਜੂਦਗੀ ਸੀ. ਨਤੀਜੇ ਸਨ:

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

ਬੇਸ ਅਤੇ ਮੋਨੋਲਿਥ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਦਾ ਕਈ ਵਾਰ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਹੈ, ਉਦਾਹਰਨ ਲਈ, 2018 ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਕਰੈਸ਼ਾਂ ਦੇ ਸੰਦਰਭ ਵਿੱਚ (Munch ਵਰਗੇ ਬਣੋ, ਜਾਂ ਤਕਨੀਕੀ ਕਰਜ਼ੇ ਬਾਰੇ ਕੁਝ ਸ਼ਬਦ, ਜਿਸ ਦਿਨ ਡੋਡੋ ਆਈ.ਐਸ. ਅਸਿੰਕ੍ਰੋਨਸ ਸਕ੍ਰਿਪਟ и ਫੀਨਿਕਸ ਪਰਿਵਾਰ ਦੇ ਡੋਡੋ ਪੰਛੀ ਦੀ ਕਹਾਣੀ। ਡੋਡੋ IS ਦਾ ਮਹਾਨ ਪਤਨ), ਇਸ ਲਈ ਮੈਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਨਹੀਂ ਰਹਾਂਗਾ। ਮੈਨੂੰ ਸਿਰਫ਼ ਇਹ ਕਹਿਣ ਦਿਓ ਕਿ ਅਸੀਂ ਸੇਵਾਵਾਂ ਦਾ ਵਿਕਾਸ ਕਰਦੇ ਸਮੇਂ ਵਧੇਰੇ ਲਚਕਤਾ ਦੇਣਾ ਚਾਹੁੰਦੇ ਸੀ। ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਉਹਨਾਂ ਨਾਲ ਸਬੰਧਤ ਹੈ ਜੋ ਪੂਰੇ ਸਿਸਟਮ ਵਿੱਚ ਸਭ ਤੋਂ ਵੱਧ ਲੋਡ ਅਤੇ ਰੂਟ ਸਨ - Auth ਅਤੇ Tracker.

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

ਚੈਪਟਰ ਨੈਵੀਗੇਸ਼ਨ

1. ਮੋਨੋਲਿਥ 2016 ਦੀ ਸਕੀਮ
2. ਅਸੀਂ ਮੋਨੋਲੀਥ ਨੂੰ ਅਨਲੋਡ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹਾਂ: ਪ੍ਰਮਾਣ ਅਤੇ ਟਰੈਕਰ ਦਾ ਵੱਖ ਹੋਣਾ
   
3. Auth ਕੀ ਕਰਦਾ ਹੈ?
4. ਲੋਡ ਕਿੱਥੋਂ ਆਉਂਦੇ ਹਨ?
5. ਪ੍ਰਮਾਣੀਕਰਨ ਨੂੰ ਅਨਲੋਡ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ
6. ਟਰੈਕਰ ਕੀ ਕਰਦਾ ਹੈ?
7. ਲੋਡ ਕਿੱਥੋਂ ਆਉਂਦੇ ਹਨ?
8. ਟਰੈਕਰ ਨੂੰ ਅਨਲੋਡ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ

ਮੋਨੋਲਿਥ 2016 ਦੀ ਸਕੀਮ

ਇੱਥੇ 2016 ਡੋਡੋ ਆਈਐਸ ਮੋਨੋਲਿਥ ਦੇ ਮੁੱਖ ਬਲਾਕ ਹਨ, ਅਤੇ ਹੇਠਾਂ ਉਹਨਾਂ ਦੇ ਮੁੱਖ ਕਾਰਜਾਂ ਦਾ ਇੱਕ ਟੁੱਟਣਾ ਹੈ।

ਡਿਲਿਵਰੀ ਕੈਸ਼ ਡੈਸਕ. ਕੋਰੀਅਰਾਂ ਲਈ ਲੇਖਾ-ਜੋਖਾ, ਕੋਰੀਅਰਾਂ ਨੂੰ ਆਦੇਸ਼ ਜਾਰੀ ਕਰਨਾ।
ਸੰਪਰਕ ਕੇਂਦਰ. ਆਪਰੇਟਰ ਦੁਆਰਾ ਆਰਡਰ ਸਵੀਕਾਰ ਕਰਨਾ।
ਸਾਈਟ. ਸਾਡੀਆਂ ਵੈੱਬਸਾਈਟਾਂ (dodopizza.ru, dodopizza.co.uk, dodopizza.by, ਆਦਿ)।
ਅਥ. ਬੈਕਆਫਿਸ ਲਈ ਅਧਿਕਾਰ ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਸੇਵਾ।
ਟਰੈਕਰ. ਰਸੋਈ ਆਰਡਰ ਟਰੈਕਰ. ਆਰਡਰ ਤਿਆਰ ਕਰਨ ਵੇਲੇ ਤਿਆਰੀ ਸਥਿਤੀਆਂ ਨੂੰ ਚਿੰਨ੍ਹਿਤ ਕਰਨ ਲਈ ਸੇਵਾ।
ਰੈਸਟੋਰੈਂਟ ਕੈਸ਼ ਡੈਸਕ. ਇੱਕ ਰੈਸਟੋਰੈਂਟ ਵਿੱਚ ਆਰਡਰ ਲੈਣਾ, ਕੈਸ਼ੀਅਰ ਇੰਟਰਫੇਸ।
ਨਿਰਯਾਤ. ਲੇਖਾਕਾਰੀ ਲਈ 1C ਵਿੱਚ ਰਿਪੋਰਟਾਂ ਅੱਪਲੋਡ ਕੀਤੀਆਂ ਜਾ ਰਹੀਆਂ ਹਨ।
ਚੇਤਾਵਨੀਆਂ ਅਤੇ ਚਲਾਨ. ਰਸੋਈ ਵਿੱਚ ਵੌਇਸ ਕਮਾਂਡਾਂ (ਉਦਾਹਰਨ ਲਈ, “ਨਵਾਂ ਪੀਜ਼ਾ ਆ ਗਿਆ ਹੈ”) + ਕੋਰੀਅਰਾਂ ਲਈ ਇਨਵੌਇਸਾਂ ਦੀ ਛਪਾਈ।
ਸ਼ਿਫਟ ਮੈਨੇਜਰ. ਸ਼ਿਫਟ ਮੈਨੇਜਰ ਦੇ ਕੰਮ ਲਈ ਇੰਟਰਫੇਸ: ਆਦੇਸ਼ਾਂ ਦੀ ਸੂਚੀ, ਉਤਪਾਦਕਤਾ ਚਾਰਟ, ਕਰਮਚਾਰੀਆਂ ਨੂੰ ਸ਼ਿਫਟਾਂ ਵਿੱਚ ਲਿਆਉਣਾ।
ਦਫਤਰ ਪ੍ਰਮੁਖ. ਫ੍ਰੈਂਚਾਈਜ਼ੀ ਅਤੇ ਪ੍ਰਬੰਧਕਾਂ ਦੇ ਕੰਮ ਲਈ ਇੰਟਰਫੇਸ: ਕਰਮਚਾਰੀਆਂ ਦੀ ਰਿਸੈਪਸ਼ਨ, ਪੀਜ਼ੇਰੀਆ ਦੇ ਕੰਮ 'ਤੇ ਰਿਪੋਰਟਾਂ.
ਰੈਸਟੋਰੈਂਟ ਬੋਰਡ. ਪੀਜ਼ੇਰੀਆ ਵਿੱਚ ਟੀਵੀ 'ਤੇ ਮੀਨੂ ਦਿਖਾ ਰਿਹਾ ਹੈ।
ਐਡਮਿਨ. ਕਿਸੇ ਖਾਸ ਪੀਜ਼ੇਰੀਆ ਲਈ ਸੈਟਿੰਗਾਂ: ਮੀਨੂ, ਕੀਮਤਾਂ, ਲੇਖਾਕਾਰੀ, ਪ੍ਰਚਾਰ ਕੋਡ, ਪ੍ਰੋਮੋਸ਼ਨ, ਸਾਈਟ ਲਈ ਬੈਨਰ, ਆਦਿ।
ਕਰਮਚਾਰੀ ਦਾ ਨਿੱਜੀ ਖਾਤਾ. ਕਰਮਚਾਰੀ ਕੰਮ ਦੇ ਕਾਰਜਕ੍ਰਮ, ਕਰਮਚਾਰੀਆਂ ਬਾਰੇ ਜਾਣਕਾਰੀ.
ਰਸੋਈ ਪ੍ਰੇਰਣਾ ਬੋਰਡ. ਇੱਕ ਵੱਖਰੀ ਸਕ੍ਰੀਨ ਜੋ ਕਿ ਰਸੋਈ ਵਿੱਚ ਲਟਕਦੀ ਹੈ ਅਤੇ ਪੀਜ਼ਾ ਬਣਾਉਣ ਵਾਲਿਆਂ ਦੀ ਗਤੀ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ।
ਸੰਚਾਰ. ਐਸਐਮਐਸ ਅਤੇ ਈਮੇਲ ਭੇਜ ਰਿਹਾ ਹੈ।
ਫਾਈਲ ਸਟੋਰੇਜ. ਸਥਿਰ ਫਾਈਲਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਅਤੇ ਜਾਰੀ ਕਰਨ ਲਈ ਆਪਣੀ ਸੇਵਾ।

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

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

ਮੁੱਖ ਸੇਵਾਵਾਂ ਜੋ ਫਿਰ ਡੇਟਾਬੇਸ ਤੋਂ ਦੂਜਿਆਂ ਨਾਲੋਂ ਵੱਧ ਲਿਖੀਆਂ ਅਤੇ ਪੜ੍ਹਦੀਆਂ ਹਨ:

1. ਪ੍ਰਮਾਣ। ਬੈਕਆਫਿਸ ਲਈ ਅਧਿਕਾਰ ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਸੇਵਾ।
2. ਟਰੈਕਰ. ਰਸੋਈ ਆਰਡਰ ਟਰੈਕਰ. ਆਰਡਰ ਤਿਆਰ ਕਰਨ ਵੇਲੇ ਤਿਆਰੀ ਸਥਿਤੀਆਂ ਨੂੰ ਚਿੰਨ੍ਹਿਤ ਕਰਨ ਲਈ ਸੇਵਾ।

Auth ਕੀ ਕਰਦਾ ਹੈ?

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

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

ਲੋਡ ਕਿੱਥੋਂ ਆਉਂਦੇ ਹਨ?

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

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

ਪ੍ਰਮਾਣੀਕਰਨ ਨੂੰ ਅਨਲੋਡ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ

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

ਸੀ.ਏ.ਐੱਸ. ਕੰਮ ਦਾ ਪ੍ਰਵਾਹ ਸ਼ੁਰੂ ਵਿੱਚ ਇਸ ਤਰ੍ਹਾਂ ਸੀ:

ਮੈਂ ਥੋੜਾ ਜਿਹਾ ਦੱਸਣਾ ਚਾਹਾਂਗਾ ਕਿ ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ:

1. ਇੱਕ ਬਾਹਰੀ ਬੇਨਤੀ ਬੈਕਐਂਡ 'ਤੇ ਆਉਂਦੀ ਹੈ (ਉੱਥੇ Asp.Net MVC), ਇਸਦੇ ਨਾਲ ਇੱਕ ਸੈਸ਼ਨ ਕੂਕੀ ਲਿਆਉਂਦੀ ਹੈ, ਜਿਸਦੀ ਵਰਤੋਂ Redis(1) ਤੋਂ ਸੈਸ਼ਨ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇਸ ਵਿੱਚ ਜਾਂ ਤਾਂ ਐਕਸੈਸ ਬਾਰੇ ਜਾਣਕਾਰੀ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਫਿਰ ਕੰਟਰੋਲਰ ਤੱਕ ਪਹੁੰਚ ਖੁੱਲ੍ਹੀ ਹੁੰਦੀ ਹੈ (3,4), ਜਾਂ ਨਹੀਂ।
2. ਜੇਕਰ ਕੋਈ ਪਹੁੰਚ ਨਹੀਂ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਅਧਿਕਾਰ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚੋਂ ਲੰਘਣ ਦੀ ਲੋੜ ਹੈ। ਇੱਥੇ, ਸਰਲਤਾ ਲਈ, ਇਹ ਉਸੇ ਗੁਣ ਵਿੱਚ ਮਾਰਗ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਦਿਖਾਇਆ ਗਿਆ ਹੈ, ਹਾਲਾਂਕਿ ਇਹ ਲੌਗਇਨ ਪੰਨੇ ਲਈ ਇੱਕ ਤਬਦੀਲੀ ਹੈ। ਇੱਕ ਸਕਾਰਾਤਮਕ ਦ੍ਰਿਸ਼ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਅਸੀਂ ਇੱਕ ਸਹੀ ਢੰਗ ਨਾਲ ਭਰਿਆ ਸੈਸ਼ਨ ਪ੍ਰਾਪਤ ਕਰਾਂਗੇ ਅਤੇ ਬੈਕਆਫਿਸ ਕੰਟਰੋਲਰ 'ਤੇ ਜਾਵਾਂਗੇ।
3. ਜੇਕਰ ਡੇਟਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਉਪਭੋਗਤਾ ਡੇਟਾਬੇਸ ਵਿੱਚ ਪ੍ਰਸੰਗਿਕਤਾ ਲਈ ਇਸਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ. ਕੀ ਉਸਦੀ ਭੂਮਿਕਾ ਬਦਲ ਗਈ ਹੈ, ਕੀ ਉਸਨੂੰ ਹੁਣ ਪੇਜ 'ਤੇ ਨਹੀਂ ਆਉਣ ਦਿੱਤਾ ਜਾਣਾ ਚਾਹੀਦਾ? ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਸੈਸ਼ਨ (1) ਪ੍ਰਾਪਤ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਤੁਹਾਨੂੰ ਸਿੱਧੇ ਡੇਟਾਬੇਸ ਵਿੱਚ ਜਾਣ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਤਰਕ ਲੇਅਰ (2) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਉਪਭੋਗਤਾ ਦੀ ਪਹੁੰਚ ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ. ਅੱਗੇ, ਜਾਂ ਤਾਂ ਲੌਗਇਨ ਪੰਨੇ 'ਤੇ ਜਾਓ ਜਾਂ ਕੰਟਰੋਲਰ 'ਤੇ ਜਾਓ। ਇਹ ਇੱਕ ਸਧਾਰਨ ਪ੍ਰਣਾਲੀ ਹੈ, ਪਰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਮਿਆਰੀ ਨਹੀਂ ਹੈ।
4. ਜੇਕਰ ਸਾਰੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਪੂਰੀਆਂ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਤਾਂ ਅਸੀਂ ਨਿਯੰਤਰਕਾਂ ਅਤੇ ਵਿਧੀਆਂ ਵਿੱਚ ਤਰਕ ਵਿੱਚ ਅੱਗੇ ਛੱਡ ਦਿੰਦੇ ਹਾਂ।

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

ਬਣ ਗਿਆ। ਉਨ੍ਹਾਂ ਨੇ ਇਹੀ ਕੀਤਾ:

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

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

ਵਿਛੋੜੇ ਨੂੰ ਇੰਨਾ ਸਮਾਂ ਕਿਉਂ ਲੱਗਾ?
ਰਸਤੇ ਵਿੱਚ ਬਹੁਤ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਸਨ ਜਿਨ੍ਹਾਂ ਨੇ ਸਾਨੂੰ ਹੌਲੀ ਕਰ ਦਿੱਤਾ:

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

ਇੱਕ ਪੀਜ਼ੇਰੀਆ ਵਿੱਚ ਇੱਕ ਡਿਵਾਈਸ ਨੂੰ ਰਜਿਸਟਰ ਕਰਨ ਲਈ ਸਕੀਮ:

ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਡਿਵਾਈਸਾਂ ਸੇਵਾ ਨੂੰ ਵੱਖ ਕਰਨ ਤੋਂ ਬਾਅਦ ਆਮ ਆਰਕੀਟੈਕਚਰ:

ਟਿੱਪਣੀ. 2020 ਲਈ, ਅਸੀਂ Auth ਦੇ ਇੱਕ ਨਵੇਂ ਸੰਸਕਰਣ 'ਤੇ ਕੰਮ ਕਰ ਰਹੇ ਹਾਂ, ਜੋ OAuth 2.0 ਪ੍ਰਮਾਣੀਕਰਨ ਮਿਆਰ 'ਤੇ ਆਧਾਰਿਤ ਹੈ। ਇਹ ਮਿਆਰ ਕਾਫ਼ੀ ਗੁੰਝਲਦਾਰ ਹੈ, ਪਰ ਇੱਕ ਸਿਰੇ ਤੋਂ ਅੰਤ ਪ੍ਰਮਾਣੀਕਰਨ ਸੇਵਾ ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਲਈ ਉਪਯੋਗੀ ਹੈ। ਲੇਖ ਵਿੱਚ "ਅਧਿਕਾਰ ਦੀ ਸੂਖਮਤਾ: OAuth 2.0 ਤਕਨਾਲੋਜੀ ਦੀ ਸੰਖੇਪ ਜਾਣਕਾਰੀ» ਅਸੀਂ ਅਲੈਕਸੀ ਚੇਰਨਯੇਵ ਨੇ ਮਿਆਰੀ ਬਾਰੇ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਸਧਾਰਨ ਅਤੇ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਗੱਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਤਾਂ ਜੋ ਤੁਸੀਂ ਇਸ ਦਾ ਅਧਿਐਨ ਕਰਨ ਵਿੱਚ ਸਮਾਂ ਬਚਾਓ।

ਟਰੈਕਰ ਕੀ ਕਰਦਾ ਹੈ?

ਹੁਣ ਲੋਡ ਕੀਤੀਆਂ ਸੇਵਾਵਾਂ ਦੇ ਦੂਜੇ ਬਾਰੇ. ਟਰੈਕਰ ਦੋਹਰੀ ਭੂਮਿਕਾ ਨਿਭਾਉਂਦਾ ਹੈ:

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

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

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

ਰਾਸਕਟਕਾ ਟ੍ਰੈਕਰ ਸਟੇਸ਼ਨ 'ਤੇ ਟੈਬਲੇਟ ਸਕ੍ਰੀਨ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ।

ਲੋਡ ਕਿੱਥੋਂ ਆਉਂਦੇ ਹਨ?

ਹਰੇਕ ਪੀਜ਼ੇਰੀਆ ਵਿੱਚ ਇੱਕ ਟਰੈਕਰ ਦੇ ਨਾਲ ਲਗਭਗ ਪੰਜ ਗੋਲੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। 2016 ਵਿੱਚ ਸਾਡੇ ਕੋਲ 100 ਤੋਂ ਵੱਧ ਪਿਜ਼ੇਰੀਆ ਸਨ (ਅਤੇ ਹੁਣ 600 ਤੋਂ ਵੱਧ ਹਨ)। ਹਰ ਇੱਕ ਟੈਬਲੇਟ ਹਰ 10 ਸਕਿੰਟਾਂ ਵਿੱਚ ਬੈਕਐਂਡ ਨੂੰ ਬੇਨਤੀ ਕਰਦੀ ਹੈ ਅਤੇ ਆਰਡਰ ਟੇਬਲ (ਕਲਾਇੰਟ ਅਤੇ ਪਤੇ ਨਾਲ ਲਿੰਕ), ਆਰਡਰ ਰਚਨਾ (ਉਤਪਾਦ ਦੇ ਨਾਲ ਲਿੰਕ ਅਤੇ ਮਾਤਰਾ ਦੇ ਸੰਕੇਤ), ਅਤੇ ਪ੍ਰੇਰਣਾ ਸਾਰਣੀ (ਇਹ ਟਰੈਕ ਕਰਦਾ ਹੈ) ਤੋਂ ਡੇਟਾ ਇਕੱਠਾ ਕਰਦਾ ਹੈ ਦਬਾਉਣ ਦਾ ਸਮਾਂ). ਜਦੋਂ ਇੱਕ ਪੀਜ਼ਾ ਮੇਕਰ ਟਰੈਕਰ 'ਤੇ ਕਿਸੇ ਉਤਪਾਦ 'ਤੇ ਕਲਿੱਕ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹਨਾਂ ਸਾਰੀਆਂ ਟੇਬਲਾਂ ਵਿੱਚ ਰਿਕਾਰਡ ਅੱਪਡੇਟ ਹੋ ਜਾਂਦੇ ਹਨ। ਆਰਡਰ ਟੇਬਲ ਆਮ ਹੈ; ਇਸ ਵਿੱਚ ਇੱਕੋ ਸਮੇਂ ਇੱਕ ਆਰਡਰ ਸਵੀਕਾਰ ਕਰਨ ਵੇਲੇ ਸੰਮਿਲਨ, ਸਿਸਟਮ ਦੇ ਦੂਜੇ ਹਿੱਸਿਆਂ ਤੋਂ ਅੱਪਡੇਟ, ਅਤੇ ਬਹੁਤ ਸਾਰੀਆਂ ਰੀਡਿੰਗਾਂ ਸ਼ਾਮਲ ਹੁੰਦੀਆਂ ਹਨ, ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਟੀਵੀ 'ਤੇ ਜੋ ਇੱਕ ਪੀਜ਼ੇਰੀਆ ਵਿੱਚ ਲਟਕਦਾ ਹੈ ਅਤੇ ਗਾਹਕਾਂ ਨੂੰ ਤਿਆਰ ਕੀਤੇ ਆਰਡਰ ਦਿਖਾਉਂਦਾ ਹੈ।

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

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

ਸੀ.ਏ.ਐੱਸ. ਸ਼ੁਰੂ ਵਿੱਚ ਆਰਕੀਟੈਕਚਰ ਇਸ ਤਰ੍ਹਾਂ ਸੀ:

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

ਟਰੈਕਰ ਨੂੰ ਅਨਲੋਡ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ

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

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

ਆਰਡਰ ਸਥਿਤੀ ਤਬਦੀਲੀ ਸਕੀਮ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ:

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

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

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

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

ਪਥ-ਦਰ-ਕਦਮ ਆਰਡਰ ਕਰੋ
ਆਰਡਰ ਮਾਰਗ ਆਰਡਰ ਸਰੋਤ ਸੇਵਾਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। ਇੱਥੇ ਰੈਸਟੋਰੈਂਟ ਕੈਸ਼ੀਅਰ ਹੈ:

1. ਚੈੱਕਆਉਟ 'ਤੇ ਆਰਡਰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਤਿਆਰ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਟਰੈਕਰ ਨੂੰ ਭੇਜਣ ਦਾ ਸਮਾਂ ਆ ਗਿਆ ਹੈ। ਘਟਨਾ ਜਿਸ ਲਈ ਟਰੈਕਰ ਦੀ ਗਾਹਕੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਸੁੱਟ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ।
2. ਟਰੈਕਰ, ਇੱਕ ਆਰਡਰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਇਸਨੂੰ ਆਪਣੇ ਖੁਦ ਦੇ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਕਰਦਾ ਹੈ, "ਟਰੈਕਰ ਦੁਆਰਾ ਸਵੀਕਾਰ ਕੀਤਾ ਆਰਡਰ" ਇਵੈਂਟ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ RMQ ਨੂੰ ਭੇਜਦਾ ਹੈ।
3. ਕਈ ਹੈਂਡਲਰ ਪਹਿਲਾਂ ਹੀ ਕਸਟਮ ਇਵੈਂਟ ਬੱਸ ਦੇ ਗਾਹਕ ਬਣੇ ਹੋਏ ਹਨ। ਸਾਡੇ ਲਈ, ਮੋਨੋਲੀਥਿਕ ਡੇਟਾਬੇਸ ਨਾਲ ਸਮਕਾਲੀਕਰਨ ਮਹੱਤਵਪੂਰਨ ਹੈ।
4. ਹੈਂਡਲਰ ਇਵੈਂਟ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਇਸ ਤੋਂ ਉਹ ਡੇਟਾ ਚੁਣਦਾ ਹੈ ਜੋ ਇਸਦੇ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਇਹ ਆਰਡਰ ਸਥਿਤੀ ਹੈ "ਟਰੈਕਰ ਦੁਆਰਾ ਸਵੀਕਾਰ ਕੀਤੀ ਗਈ" ਅਤੇ ਮੁੱਖ ਡੇਟਾਬੇਸ ਵਿੱਚ ਇਸਦੀ ਆਰਡਰ ਇਕਾਈ ਨੂੰ ਅਪਡੇਟ ਕਰਦਾ ਹੈ।

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

ਹੋਰ ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ ਉਹਨਾਂ ਨੂੰ ਆਪਣੇ ਲਈ ਵਰਤਣ ਲਈ ਟ੍ਰੈਕਰ ਤੋਂ ਆਰਡਰ ਈਵੈਂਟਾਂ ਦੀ ਗਾਹਕੀ ਲੈ ਸਕਦੀਆਂ ਹਨ।

ਜੇ ਕੁਝ ਸਮੇਂ ਬਾਅਦ ਇੱਕ ਆਰਡਰ ਉਤਪਾਦਨ ਵਿੱਚ ਲਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਸਦੀ ਸਥਿਤੀ ਪਹਿਲਾਂ ਇਸਦੇ ਡੇਟਾਬੇਸ (ਟਰੈਕਰ ਡੇਟਾਬੇਸ) ਵਿੱਚ ਬਦਲ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਫਿਰ "OrderInWork" ਇਵੈਂਟ ਤੁਰੰਤ ਤਿਆਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ RMQ ਵਿੱਚ ਵੀ ਜਾਂਦਾ ਹੈ, ਜਿੱਥੋਂ ਇਸਨੂੰ ਇੱਕ ਮੋਨੋਲਿਥਿਕ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸਮਕਾਲੀ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਹੋਰ ਸੇਵਾਵਾਂ ਨੂੰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਇਸ ਮਾਰਗ 'ਤੇ ਕਈ ਤਰ੍ਹਾਂ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹੋ ਸਕਦੀਆਂ ਹਨ; ਉਨ੍ਹਾਂ ਬਾਰੇ ਹੋਰ ਵੇਰਵੇ Zhenya Peshkov ਦੀ ਰਿਪੋਰਟ ਵਿੱਚ ਮਿਲ ਸਕਦੇ ਹਨ ਟਰੈਕਰ ਵਿੱਚ ਇਵਚੁਅਲ ਇਕਸਾਰਤਾ ਦੇ ਲਾਗੂਕਰਨ ਵੇਰਵਿਆਂ ਬਾਰੇ.

ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਟਰੈਕਰ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਤੋਂ ਬਾਅਦ ਅੰਤਿਮ ਆਰਕੀਟੈਕਚਰ

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

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

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

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

ਤੁਸੀਂ ਅਗਲੇ ਲੇਖ ਵਿਚ ਡੋਡੋ ਆਈਐਸ ਦੇ ਕਿਹੜੇ ਹਿੱਸੇ ਬਾਰੇ ਜਾਣਨਾ ਚਾਹੋਗੇ?

• 24,1%ਡੋਡੋ IS (2011-2015)14 ਵਿੱਚ ਅਰਲੀ ਮੋਨੋਲਿਥ

• 24,1%ਪਹਿਲੀਆਂ ਸਮੱਸਿਆਵਾਂ ਅਤੇ ਉਹਨਾਂ ਦੇ ਹੱਲ (2015-2016)14

• 20,7%ਕਲਾਇੰਟ ਹਿੱਸੇ ਦਾ ਮਾਰਗ: ਅਧਾਰ ਦੇ ਉੱਪਰ ਦਾ ਨਕਾਬ (2016-2017)12

• 36,2%ਅਸਲੀ ਮਾਈਕ੍ਰੋਸਰਵਿਸਿਜ਼ ਦਾ ਇਤਿਹਾਸ (2018-2019)21

• 44,8%ਮੋਨੋਲਿਥ ਦੀ ਪੂਰੀ ਕਟਾਈ ਅਤੇ ਆਰਕੀਟੈਕਚਰ ਦੀ ਸਥਿਰਤਾ 26

• 29,3%ਸਿਸਟਮ ਦੇ ਵਿਕਾਸ ਲਈ ਹੋਰ ਯੋਜਨਾਵਾਂ ਬਾਰੇ 17

• 19,0%ਮੈਂ ਡੋਡੋ IS11 ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਜਾਣਨਾ ਚਾਹੁੰਦਾ/ਚਾਹੁੰਦੀ

58 ਉਪਭੋਗਤਾਵਾਂ ਨੇ ਵੋਟ ਕੀਤਾ। 6 ਉਪਭੋਗਤਾ ਬਚੇ ਹੋਏ ਹਨ।

ਸਰੋਤ: www.habr.com