د توزیع شوي غوښتنلیکونو د جوړولو بلاکونه. لومړی لاره

په اخر کې مقالې موږ د عکس العمل جوړښت نظریاتي بنسټونه وڅیړل. دا وخت دی چې د ډیټا جریانونو په اړه وغږیږو ، د عکس العمل ایرلانګ / ایلکسیر سیسټمونو پلي کولو لارې او په دوی کې د پیغام رسولو نمونې:

• غوښتنه - ځواب
• د غوښتنې ځواب
• د غوښتنې سره ځواب
• خپور کړئ - ګډون وکړئ
• برعکس خپرول - ګډون
• د دندو ویش

SOA، MSA او پیغام رسول

SOA، MSA د سیسټم جوړښتونه دي چې د سیسټمونو جوړولو لپاره مقررات تعریفوي، پداسې حال کې چې پیغام رسول د دوی د پلي کولو لپاره ابتدايي چمتو کوي.

زه نه غواړم دا یا هغه سیسټم جوړښت ته وده ورکړم. زه د یوې ځانګړې پروژې او سوداګرۍ لپاره د خورا اغیزمنو او ګټورو کړنو کارولو لپاره یم. هر هغه تمثیل چې موږ یې غوره کوو، دا غوره ده چې د یونکس لارې په نظر کې نیولو سره د سیسټم بلاکونه جوړ کړئ: اجزا چې لږترلږه ارتباط لري، د انفرادي ادارو لپاره مسؤل دي. د API میتودونه د ادارو سره ترټولو ساده ممکنه کړنې ترسره کوي.

پیغام ورکول، لکه څنګه چې نوم وړاندیز کوي، د پیغام بروکر دی. د دې اصلي موخه د پیغامونو ترلاسه کول او لیږل دي. دا د معلوماتو لیږلو لپاره د انٹرفیسونو مسؤل دی ، په سیسټم کې دننه د معلوماتو لیږدولو لپاره د منطقي چینلونو رامینځته کول ، روټینګ او انډول کول ، او همدارنګه د سیسټم په کچه د غلطیو اداره کول.
هغه پیغامونه چې موږ یې وده کوو د rabbitmq سره سیالي یا بدلولو هڅه نه کوي. اصلي ځانګړتیاوې یې:

• ویش.
  د تبادلې نقطې په ټولو کلستر نوډونو کې رامینځته کیدی شي ، څومره چې ممکنه وي هغه کوډ ته نږدې چې دوی یې کاروي.
• سادگي.
  د بویلر پلیټ کوډ کمولو او د کارولو اسانتیا باندې تمرکز وکړئ.
• غوره فعالیت.
  موږ هڅه نه کوو چې د rabbitmq فعالیت تکرار کړو، مګر یوازې د معمارۍ او ټرانسپورټ پرت روښانه کوو، کوم چې موږ د امکان تر حده په OTP کې فټ کوو، لګښتونه کموي.
• انعطاف پذیري.
  هر خدمت کولی شي د تبادلې ډیری نمونې سره یوځای کړي.
• د ډیزاین له مخې مقاومت.
• د توزیع وړتیا.
  د غوښتنلیک سره پیغامونه وده کوي. لکه څنګه چې بار زیاتیږي، تاسو کولی شئ د تبادلې نقطې انفرادي ماشینونو ته انتقال کړئ.

تبصره د کوډ تنظیم په شرایطو کې، میټا پروژې د پیچلي ایرلنګ / ایلیکسیر سیسټمونو لپاره مناسب دي. د پروژې ټول کوډ په یوه ذخیره کې موقعیت لري - د چترۍ پروژه. په ورته وخت کې، کوچني خدمتونه په اعظمي توګه جلا شوي او ساده عملیات ترسره کوي چې د جلا ادارې لپاره مسؤل دي. د دې طریقې سره، د ټول سیسټم API ساتل اسانه دي، د بدلونونو لپاره اسانه ده، د واحد او ادغام ازموینې لیکلو لپاره اسانه ده.

د سیسټم برخې مستقیم یا د بروکر له لارې اړیکه لري. د پیغام رسولو له نظره، هر خدمت د ژوند څو مرحلې لري:

• د خدمت پیل کول.
  پدې مرحله کې، د خدماتو اجرا کولو پروسه او د هغې انحصارونه ترتیب او پیل شوي.
• د تبادلې نقطه رامینځته کول.
  خدمت کولی شي د نوډ ترتیب کې مشخص شوي جامد تبادلې نقطه وکاروي ، یا په متحرک ډول د تبادلې نقطې رامینځته کړي.
• د خدماتو ثبت کول.
  د غوښتنو د خدمت کولو لپاره د خدماتو لپاره، دا باید د تبادلې په نقطه کې ثبت شي.
• نورمال فعالیت.
  خدمت ګټور کار تولیدوي.
• ‍‍‍بندول.
  دوه ډوله تړل ممکن دي: نورمال او اضطراري. د نورمال عملیاتو په جریان کې ، خدمت د تبادلې نقطې څخه قطع کیږي او ودریږي. په بیړني حالتونو کې، پیغام رسول د ناکامۍ سکریپټونو څخه یو اجرا کوي.

دا خورا پیچلي ښکاري، مګر کوډ دومره ډارونکی ندی. د نظرونو سره د کوډ مثالونه به لږ وروسته د ټیمپلیټونو په تحلیل کې ورکړل شي.

د تبادلې

د تبادلې نقطه د پیغام رسولو پروسه ده چې د پیغام رسولو ټیمپلیټ کې د اجزاو سره د متقابل عمل منطق پلي کوي. په ټولو مثالونو کې چې لاندې وړاندې شوي، اجزا د تبادلې نقطو له لارې تعامل کوي، د کوم ترکیب چې پیغامونه جوړوي.

د پیغام تبادلې نمونې (MEPs)

په نړیواله کچه، د تبادلې نمونې په دوه اړخیزه او یو طرفه ویشل کیدی شي. پخوانی د راتلونکی پیغام په ځواب کې معنی لري، وروستی یې نه کوي. د پیرودونکي - سرور جوړښت کې د دوه اړخیزه نمونې کلاسیک مثال د غوښتنې ځواب نمونه ده. راځئ چې نمونه او د هغې تعدیلات وګورو.

د غوښتنې ځواب یا RPC

RPC کارول کیږي کله چې موږ اړتیا لرو د بلې پروسې څخه ځواب ترلاسه کړو. دا پروسه ممکن په ورته نوډ کې روانه وي یا په بل براعظم کې موقعیت ولري. لاندې د پیغام رسولو له لارې د پیرودونکي او سرور ترمینځ د متقابل عمل ډیاګرام دی.

څرنګه چې پیغام رسول په بشپړه توګه غیر متمرکز دی، د پیرودونکي لپاره تبادله په 2 مرحلو ویشل شوې ده:

1. غوښتنه وسپاري

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

   په بدل کې - د تبادلې نقطه ځانګړی نوم
   د غبرګون میچینګ ټګ - د ځواب پروسس کولو لپاره محلي لیبل. د مثال په توګه، د مختلفو کاروونکو پورې اړوند څو ورته غوښتنې لیږلو په صورت کې.
   د غوښتنې تعریف - د بدن غوښتنه
   هینډلر پروسس - د سمبالونکي PID. دا پروسه به د سرور څخه ځواب ترلاسه کړي.

2. د ځواب پروسس کول

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

   د ځواب پېلوډ - د سرور ځواب.

د سرور لپاره، پروسه هم د 2 مرحلو څخه جوړه ده:

1. د تبادلې نقطه پیل کول
2. د ترلاسه شویو غوښتنو پروسس کول

راځئ چې دا کينډۍ د کوډ سره روښانه کړو. راځئ چې ووایو موږ یو ساده خدمت پلي کولو ته اړتیا لرو چې یو دقیق وخت میتود چمتو کوي.

د سرور کوډ

راځئ چې په api.hrl کې د خدماتو API تعریف کړو:

%% =====================================================
%%  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 MB 1 پیغامونه د 1 GB یو پیغام څخه غوره دي.

په ایرلنګ کلستر کې، موږ اضافي ګټه ترلاسه کوو - د تبادلې نقطه او شبکه کې د بار کمول، ځکه چې ځوابونه سمدلاسه ترلاسه کونکي ته لیږل کیږي، د تبادلې نقطه تیریږي.

د غوښتنې سره ځواب

دا د ډیالوګ سیسټمونو جوړولو لپاره د RPC نمونې خورا نادر تعدیل دی.

خپرول - ګډون (د معلوماتو د ویشلو ونې)

د پیښو لخوا پرمخ وړل شوي سیسټمونه د معلوماتو چمتو کولو سره سم مرصفوونکو ته وړاندې کوي. په دې توګه، سیسټمونه د پل یا پول ماډل په پرتله د فشار ماډل ته ډیر زیان رسوي. دا ب featureه تاسو ته اجازه درکوي په دوامداره توګه د معلوماتو غوښتنه کولو او انتظار کولو سره د سرچینو ضایع کیدو مخه ونیسئ.
ارقام د یوې ځانګړې موضوع لپاره ګډون کونکو پیرودونکو ته د پیغام توزیع کولو پروسه ښیې.

د دې نمونې کارولو کلاسیک مثالونه د دولت ویش دی: د کمپیوټر لوبو کې د لوبې نړۍ، د تبادلې په اړه د بازار ډاټا، د معلوماتو فیډونو کې ګټور معلومات.

راځئ چې د پیرودونکي کوډ وګورو:

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 ، د دندې ترلاسه کولو وروسته ، پرته له دې چې د تبادلې نقطې ته د راپور ورکولو لپاره وخت ولري سقوط شو. په دې حالت کې، د تبادلې نقطه به د اکیک وخت پای ته رسیدو وروسته بل هینډلر ته دنده لیږدوي. د ځینو دلیلونو لپاره، هینډلر 3 دنده پریښوده او نیک واستول؛ په پایله کې، دنده هم بل هینډلر ته لیږدول شوې وه چې په بریالیتوب سره یې بشپړه کړه.

لومړنی لنډیز

موږ د توزیع شوي سیسټمونو لومړني ودانیز بلاکونه پوښلي او په ایرلنګ/ایلکسیر کې د دوی کارولو لومړني پوهه ترلاسه کړې.

د بنسټیزو نمونو په یوځای کولو سره، تاسو کولی شئ د راڅرګندېدونکو ستونزو د حل لپاره پیچلي تمثیلونه جوړ کړئ.

د لړۍ په وروستۍ برخه کې، موږ به د خدماتو تنظیم کولو، روټینګ او انډول کولو عمومي مسلو ته وګورو، او همدارنګه د سیسټمونو د توزیع کولو او د غلطۍ زغم د عملي اړخ په اړه وغږیږو.

د دویمې برخې پای.

انځور ماریس کریسټینسن
انځورونه د websequencediagrams.com په کارولو سره چمتو شوي

سرچینه: www.habr.com