ਵੰਡੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੇ ਬਿਲਡਿੰਗ ਬਲਾਕ। ਪਹਿਲੀ ਪਹੁੰਚ

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

• ਬੇਨਤੀ-ਜਵਾਬ
• ਬੇਨਤੀ-ਚੰਕਡ ਜਵਾਬ
• ਬੇਨਤੀ ਦੇ ਨਾਲ ਜਵਾਬ
• ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ-ਸਬਸਕ੍ਰਾਈਬ ਕਰੋ
• ਉਲਟਾ ਪ੍ਰਕਾਸ਼ਿਤ ਗਾਹਕ ਬਣੋ
• ਕਾਰਜ ਵੰਡ

SOA, MSA ਅਤੇ ਮੈਸੇਜਿੰਗ

SOA, MSA ਸਿਸਟਮ ਆਰਕੀਟੈਕਚਰ ਹਨ ਜੋ ਸਿਸਟਮ ਬਣਾਉਣ ਲਈ ਨਿਯਮਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹਨ, ਜਦੋਂ ਕਿ ਮੈਸੇਜਿੰਗ ਉਹਨਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਮੁੱਢਲੇ ਤੱਤ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ।

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

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

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

ਟਿੱਪਣੀ. ਕੋਡ ਸੰਗਠਨ ਦੇ ਰੂਪ ਵਿੱਚ, ਮੈਟਾ-ਪ੍ਰੋਜੈਕਟ ਗੁੰਝਲਦਾਰ Erlang/Elixir ਸਿਸਟਮਾਂ ਲਈ ਚੰਗੀ ਤਰ੍ਹਾਂ ਅਨੁਕੂਲ ਹਨ। ਸਾਰੇ ਪ੍ਰੋਜੈਕਟ ਕੋਡ ਇੱਕ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਹਨ - ਇੱਕ ਛਤਰੀ ਪ੍ਰੋਜੈਕਟ। ਇਸ ਦੇ ਨਾਲ ਹੀ, ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਨੂੰ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਅਲੱਗ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਸਧਾਰਨ ਓਪਰੇਸ਼ਨ ਕਰਦੇ ਹਨ ਜੋ ਇੱਕ ਵੱਖਰੀ ਹਸਤੀ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੁੰਦੇ ਹਨ। ਇਸ ਪਹੁੰਚ ਨਾਲ, ਪੂਰੇ ਸਿਸਟਮ ਦੇ API ਨੂੰ ਬਣਾਈ ਰੱਖਣਾ ਆਸਾਨ ਹੈ, ਬਦਲਾਅ ਕਰਨਾ ਆਸਾਨ ਹੈ, ਯੂਨਿਟ ਅਤੇ ਏਕੀਕਰਣ ਟੈਸਟਾਂ ਨੂੰ ਲਿਖਣਾ ਸੁਵਿਧਾਜਨਕ ਹੈ।

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

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

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

ਐਕਸਚੇਜ਼

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

ਸੁਨੇਹਾ ਐਕਸਚੇਂਜ ਪੈਟਰਨ (MEPs)

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

ਬੇਨਤੀ-ਜਵਾਬ ਜਾਂ RPC

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

ਕਿਉਂਕਿ ਮੈਸੇਜਿੰਗ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਸਿੰਕ੍ਰੋਨਸ ਹੈ, ਕਲਾਇੰਟ ਲਈ ਐਕਸਚੇਂਜ ਨੂੰ 2 ਪੜਾਵਾਂ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਹੈ:

1. ਬੇਨਤੀ ਜਮ੍ਹਾਂ ਕਰੋ

   messaging:request(Exchange, ResponseMatchingTag, RequestDefinition, HandlerProcess).

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

2. ਜਵਾਬ ਪ੍ਰਕਿਰਿਆ

   handle_info(#'$msg'{exchange = EXCHANGE, tag = ResponseMatchingTag,message = ResponsePayload}, State)

   ਜਵਾਬ ਪੇਲੋਡ - ਸਰਵਰ ਜਵਾਬ.

ਸਰਵਰ ਲਈ, ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ 2 ਪੜਾਅ ਵੀ ਸ਼ਾਮਲ ਹਨ:

1. ਐਕਸਚੇਂਜ ਪੁਆਇੰਟ ਦੀ ਸ਼ੁਰੂਆਤ
2. ਆਉਣ ਵਾਲੀਆਂ ਬੇਨਤੀਆਂ 'ਤੇ ਕਾਰਵਾਈ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ

ਆਉ ਇਸ ਟੈਂਪਲੇਟ ਨੂੰ ਕੋਡ ਨਾਲ ਦਰਸਾਉ। ਮੰਨ ਲਓ ਕਿ ਸਾਨੂੰ ਇੱਕ ਸਧਾਰਨ ਸੇਵਾ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਜੋ ਇੱਕ ਸਿੰਗਲ ਸਹੀ ਸਮਾਂ ਵਿਧੀ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ।

ਸਰਵਰ ਕੋਡ

ਆਉ ਸਰਵਿਸ API ਪਰਿਭਾਸ਼ਾ ਨੂੰ api.hrl ਵਿੱਚ ਭੇਜੀਏ:

%% =====================================================
%%  entities
%% =====================================================
-record(time, {
  unixtime :: non_neg_integer(),
  datetime :: binary()
}).

-record(time_error, {
  code :: non_neg_integer(),
  error :: term()
}).

%% =====================================================
%%  methods
%% =====================================================
-record(time_req, {
  opts :: term()
}).
-record(time_resp, {
  result :: #time{} | #time_error{}
}).

ਸਰਵਿਸ ਕੰਟਰੋਲਰ ਨੂੰ time_controller.erl ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ

%% В примере показан только значимый код. Вставив его в шаблон gen_server можно получить рабочий сервис.

%% инициализация gen_server
init(Args) ->
  %% подключение к точке обмена
  messaging:monitor_exchange(req_resp, ?EXCHANGE, default, self())
  {ok, #{}}.

%% обработка события потери связи с точкой обмена. Это же событие приходит, если точка обмена еще не запустилась.
handle_info(#exchange_die{exchange = ?EXCHANGE}, State) ->
  erlang:send(self(), monitor_exchange),
  {noreply, State};

%% обработка API
handle_info(#time_req{opts = _Opts}, State) ->
  messaging:response_once(Client, #time_resp{
result = #time{ unixtime = time_utils:unixtime(now()), datetime = time_utils:iso8601_fmt(now())}
  });
  {noreply, State};

%% завершение работы gen_server
terminate(_Reason, _State) ->
  messaging:demonitor_exchange(req_resp, ?EXCHANGE, default, self()),
  ok.

ਕਲਾਇੰਟ ਕੋਡ

ਕਿਸੇ ਸੇਵਾ ਨੂੰ ਬੇਨਤੀ ਭੇਜਣ ਲਈ, ਤੁਸੀਂ ਕਲਾਇੰਟ 'ਤੇ ਕਿਤੇ ਵੀ ਮੈਸੇਜਿੰਗ ਬੇਨਤੀ API ਨੂੰ ਕਾਲ ਕਰ ਸਕਦੇ ਹੋ:

case messaging:request(?EXCHANGE, tag, #time_req{opts = #{}}, self()) of
    ok -> ok;
    _ -> %% repeat or fail logic
end

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

handle_info(#'$msg'{exchange = ?EXCHANGE, tag = tag, message = #time_resp{result = #time{unixtime = Utime}}}, State) ->
  ?debugVal(Utime),
  {noreply, State};

handle_info(#'$msg'{exchange = ?EXCHANGE, tag = tag, message = #time_resp{result = #time_error{code = ErrorCode}}}, State) ->
  ?debugVal({error, ErrorCode}),
  {noreply, State};

ਬੇਨਤੀ-ਚੰਕਡ ਜਵਾਬ

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

ਇੱਥੇ ਅਜਿਹੇ ਮਾਮਲਿਆਂ ਦੀਆਂ ਕੁਝ ਉਦਾਹਰਣਾਂ ਹਨ:

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

ਮੈਂ ਅਜਿਹੇ ਜਵਾਬਾਂ ਨੂੰ ਲੋਕੋਮੋਟਿਵ ਕਹਿੰਦਾ ਹਾਂ। ਕਿਸੇ ਵੀ ਹਾਲਤ ਵਿੱਚ, 1024 1MB ਸੁਨੇਹੇ ਇੱਕ ਸਿੰਗਲ 1GB ਸੁਨੇਹੇ ਨਾਲੋਂ ਬਿਹਤਰ ਹਨ।

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

ਬੇਨਤੀ ਦੇ ਨਾਲ ਜਵਾਬ

ਇਹ ਸੰਵਾਦ ਪ੍ਰਣਾਲੀਆਂ ਨੂੰ ਬਣਾਉਣ ਲਈ RPC ਪੈਟਰਨ ਦੀ ਇੱਕ ਬਹੁਤ ਹੀ ਦੁਰਲੱਭ ਸੋਧ ਹੈ।

ਪਬਲਿਸ਼-ਸਬਸਕ੍ਰਾਈਬ ਕਰੋ (ਡਾਟਾ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਟ੍ਰੀ)

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

ਇਸ ਪੈਟਰਨ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀਆਂ ਕਲਾਸਿਕ ਉਦਾਹਰਣਾਂ ਰਾਜ ਦੀ ਵੰਡ ਹਨ: ਕੰਪਿਊਟਰ ਗੇਮਾਂ ਵਿੱਚ ਖੇਡ ਸੰਸਾਰ, ਐਕਸਚੇਂਜਾਂ 'ਤੇ ਮਾਰਕੀਟ ਡੇਟਾ, ਡੇਟਾ ਫੀਡ ਵਿੱਚ ਉਪਯੋਗੀ ਜਾਣਕਾਰੀ।

ਗਾਹਕ ਕੋਡ 'ਤੇ ਗੌਰ ਕਰੋ:

init(_Args) ->
  %% подписываемся на обменник, ключ = key
  messaging:subscribe(?SUBSCRIPTION, key, tag, self()),
  {ok, #{}}.

handle_info(#exchange_die{exchange = ?SUBSCRIPTION}, State) ->
  %% если точка обмена недоступна, то пытаемся переподключиться
  messaging:subscribe(?SUBSCRIPTION, key, tag, self()),
  {noreply, State};

%% обрабатываем пришедшие сообщения
handle_info(#'$msg'{exchange = ?SUBSCRIPTION, message = Msg}, State) ->
  ?debugVal(Msg),
  {noreply, State};

%% при остановке потребителя - отключаемся от точки обмена
terminate(_Reason, _State) ->
  messaging:unsubscribe(?SUBSCRIPTION, key, tag, self()),
  ok.

ਸਰੋਤ ਕਿਸੇ ਵੀ ਸੁਵਿਧਾਜਨਕ ਜਗ੍ਹਾ 'ਤੇ ਸੰਦੇਸ਼ ਦੇ ਪ੍ਰਕਾਸ਼ਿਤ ਫੰਕਸ਼ਨ ਨੂੰ ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ:

messaging:publish_message(Exchange, Key, Message).

ਐਕਸਚੇਜ਼ - ਐਕਸਚੇਂਜ ਪੁਆਇੰਟ ਦਾ ਨਾਮ,
ਕੁੰਜੀ - ਰੂਟਿੰਗ ਕੁੰਜੀ
ਸੁਨੇਹਾ - ਪੇਲੋਡ

ਉਲਟਾ ਪ੍ਰਕਾਸ਼ਿਤ ਗਾਹਕ ਬਣੋ

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

ਕਾਰਜ ਵੰਡ ਪੈਟਰਨ

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

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

ਮੈਸੇਜਿੰਗ ਕਤਾਰਾਂ ਅਤੇ ਪ੍ਰੋਸੈਸਿੰਗ ਤਰਜੀਹ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦੀ ਹੈ। ਪ੍ਰੋਸੈਸਰ ਆਉਂਦੇ ਹੀ ਕੰਮ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ। ਕੰਮ ਸਫਲਤਾਪੂਰਵਕ ਪੂਰਾ ਜਾਂ ਅਸਫਲ ਹੋ ਸਕਦਾ ਹੈ:

• messaging:ack(Tack) - ਸੁਨੇਹੇ ਦੀ ਸਫਲ ਪ੍ਰਕਿਰਿਆ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਬੁਲਾਇਆ ਜਾਂਦਾ ਹੈ
• messaging:nack(Tack) - ਸਾਰੀਆਂ ਐਮਰਜੈਂਸੀ ਸਥਿਤੀਆਂ ਵਿੱਚ ਬੁਲਾਇਆ ਜਾਂਦਾ ਹੈ। ਟਾਸਕ ਵਾਪਸ ਆਉਣ ਤੋਂ ਬਾਅਦ, ਮੈਸੇਜਿੰਗ ਇਸਨੂੰ ਕਿਸੇ ਹੋਰ ਹੈਂਡਲਰ ਨੂੰ ਭੇਜ ਦੇਵੇਗੀ।

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

ਸ਼ੁਰੂਆਤੀ ਸਾਰ

ਅਸੀਂ ਵਿਤਰਿਤ ਪ੍ਰਣਾਲੀਆਂ ਦੇ ਬੁਨਿਆਦੀ ਬਿਲਡਿੰਗ ਬਲਾਕਾਂ ਨੂੰ ਤੋੜ ਦਿੱਤਾ ਹੈ ਅਤੇ Erlang/Elixir ਵਿੱਚ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਬਾਰੇ ਇੱਕ ਬੁਨਿਆਦੀ ਸਮਝ ਪ੍ਰਾਪਤ ਕੀਤੀ ਹੈ।

ਬੁਨਿਆਦੀ ਟੈਂਪਲੇਟਾਂ ਨੂੰ ਜੋੜ ਕੇ, ਉਭਰ ਰਹੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਗੁੰਝਲਦਾਰ ਪੈਰਾਡਾਈਮ ਬਣਾਏ ਜਾ ਸਕਦੇ ਹਨ।

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

ਦੂਜੇ ਭਾਗ ਦਾ ਅੰਤ.

ਫੋਟੋਗ੍ਰਾਫੀ ਮਾਰੀਅਸ ਕ੍ਰਿਸਟਨਸਨ
websequencediagrams.com ਦੇ ਸ਼ਿਸ਼ਟਾਚਾਰ ਦੇ ਚਿੱਤਰ

ਸਰੋਤ: www.habr.com