Градежни блокови на дистрибуирани апликации. Првиот пристап

Во последниот Член Ги испитавме теоретските основи на реактивната архитектура. Време е да зборуваме за тековите на податоци, начините за имплементација на реактивни Erlang/Elixir системи и обрасците за пораки во нив:

• Барање-одговор
• Барање-распарчен одговор
• Одговор со барање
• Објави-претплати се
• Превртено Објави-претплати се
• Дистрибуција на задачи

SOA, MSA и пораки

SOA, MSA се системски архитектури кои ги дефинираат правилата за градење системи, додека пораките обезбедуваат примитиви за нивна имплементација.

Не сакам да ја промовирам оваа или онаа системска архитектура. Јас сум за користење на најефикасните и најкорисните практики за одреден проект и бизнис. Без оглед на парадигмата што ќе ја избереме, подобро е да креираме системски блокови со поглед на Unix-way: компоненти со минимална поврзаност, одговорни за поединечни ентитети. API методите ги извршуваат наједноставните можни дејства со ентитетите.

Пораки е, како што сугерира името, брокер за пораки. Неговата главна цел е да прима и испраќа пораки. Тој е одговорен за интерфејсите за испраќање информации, формирање на логички канали за пренос на информации во системот, рутирање и балансирање, како и справување со грешки на ниво на системот.
Пораката што ја развиваме не се обидува да се натпреварува или да го замени rabbitmq. Неговите главни карактеристики:

• Дистрибуција.
  Разменските точки може да се креираат на сите јазли на кластерот, што е можно поблиску до кодот што ги користи.
• Едноставност.
  Фокусирајте се на минимизирање на кодот на котвата и леснотијата на користење.
• Подобри перформанси.
  Не се обидуваме да ја повториме функционалноста на rabbitmq, туку да го истакнеме само архитектонскиот и транспортниот слој, што го вклопуваме во OTP што е можно поедноставно, минимизирајќи ги трошоците.
• Флексибилност.
  Секоја услуга може да комбинира многу шаблони за размена.
• Отпорност по дизајн.
• Приспособливост.
  Пораки расте со апликацијата. Како што се зголемува оптоварувањето, можете да ги преместите точките за размена на поединечни машини.

Забелешка Во однос на организацијата на кодот, мета-проектите се добро прилагодени за сложени системи Erlang/Elixir. Целиот код на проектот се наоѓа во едно складиште - чадор проект. Во исто време, микросервисите се максимално изолирани и вршат едноставни операции кои се одговорни за посебен ентитет. Со овој пристап, лесно е да се одржува API на целиот систем, лесно е да се направат промени, погодно е да се пишуваат тестови за единица и интеграција.

Компонентите на системот комуницираат директно или преку брокер. Од перспектива на пораки, секоја услуга има неколку животни фази:

• Иницијализација на услугата.
  Во оваа фаза, процесот и зависностите што ја извршуваат услугата се конфигурираат и стартуваат.
• Создавање точка за размена.
  Услугата може да користи статичка точка за размена наведена во конфигурацијата на јазолот или да креира динамички точки за размена.
• Регистрација на услуга.
  За да може услугата да ги опслужува барањата, таа мора да биде регистрирана во местото за размена.
• Нормално функционирање.
  Услугата произведува корисна работа.
• Исклучи.
  Можни се 2 типа на исклучување: нормално и итно. За време на нормална работа, услугата се исклучува од местото за размена и запира. Во итни ситуации, пораките извршуваат една од скриптите за фајлвер.

Изгледа доста комплицирано, но кодот не е толку страшен. Примери за кодови со коментари ќе бидат дадени во анализата на шаблоните малку подоцна.

Размена

Точката за размена е процес на испраќање пораки што ја имплементира логиката на интеракција со компонентите во шаблонот за пораки. Во сите примери претставени подолу, компонентите комуницираат преку точки за размена, чија комбинација формира пораки.

Шеми за размена на пораки (ЕП)

На глобално ниво, шемите на размена може да се поделат на двонасочни и еднонасочни. Првите имплицираат одговор на дојдовната порака, вторите не. Класичен пример за двонасочна шема во архитектурата клиент-сервер е моделот Барање-одговор. Да го погледнеме шаблонот и неговите модификации.

Барање-одговор или RPC

RPC се користи кога треба да добиеме одговор од друг процес. Овој процес може да се извршува на истиот јазол или да се наоѓа на различен континент. Подолу е дијаграм на интеракцијата помеѓу клиентот и серверот преку пораки.

Бидејќи пораките се целосно асинхрони, за клиентот размената е поделена во 2 фази:

1. испраќање на барање

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

   размена ‒ единствено име на местото за размена
   ResponseMatchingTag ‒ локална ознака за обработка на одговорот. На пример, во случај на испраќање на неколку идентични барања кои припаѓаат на различни корисници.
   Дефиниција на барање - тело за барање
   HandlerProcess ‒ PID на управувачот. Овој процес ќе добие одговор од серверот.

2. Обработка на одговорот

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

   ResponsePayload - одговор на серверот.

За серверот, процесот исто така се состои од 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 пораки од 1 MB се подобри од една порака од 1 GB.

Во кластерот Erlang, добиваме дополнителна придобивка - намалување на оптоварувањето на точката за размена и мрежата, бидејќи одговорите веднаш се испраќаат до примачот, заобиколувајќи ја точката за размена.

Одговор со барање

Ова е прилично ретка модификација на шаблонот 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).

размена - име на местото за размена,
Клучни - клуч за насочување
порака - носивост

Превртено Објави-претплати се

Со проширување на pub-sub, можете да добиете шема погодна за сеча. Множеството на извори и потрошувачи може да биде сосема поинакво. Сликата покажува случај со еден потрошувач и повеќе извори.

Шема на дистрибуција на задачи

Речиси секој проект вклучува задачи за одложена обработка, како што се генерирање извештаи, доставување известувања и преземање податоци од системи од трети страни. Пропусната моќ на системот што ги извршува овие задачи може лесно да се намали со додавање ракувачи. Сè што ни останува е да формираме кластер на процесори и рамномерно да ги распределиме задачите меѓу нив.

Ајде да ги погледнеме ситуациите што се појавуваат користејќи го примерот на 3 ракувачи. Дури и во фазата на распределба на задачите, се поставува прашањето за правичноста на распределбата и прелевањето на ракувачите. Дистрибуцијата на кружен пат ќе биде одговорна за правичноста, а за да се избегне ситуација на прелевање на ракувачи, ќе воведеме ограничување prefetch_limit. Во минливи услови prefetch_limit ќе спречи еден управувач да ги прима сите задачи.

Пораки управува со редици и приоритет на обработка. Процесорите добиваат задачи како што пристигнуваат. Задачата може да заврши успешно или да не успее:

• messaging:ack(Tack) - повикан ако пораката е успешно обработена
• messaging:nack(Tack) - повикани во сите итни ситуации. Штом ќе се врати задачата, пораките ќе ги пренесат на друг управувач.

Да претпоставиме дека се случил комплексен неуспех при обработката на три задачи: процесорот 1, откако ја примил задачата, паднал без да има време да пријави нешто до точката за размена. Во овој случај, точката за размена ќе ја префрли задачата на друг управувач откако ќе истече времето за акумулирање. Поради некоја причина, управувачот 3 ја напушти задачата и испрати нак; како резултат на тоа, задачата беше префрлена и на друг управувач кој успешно ја заврши.

Прелиминарно резиме

Ги опфативме основните градежни блокови на дистрибуираните системи и стекнавме основно разбирање за нивната употреба во Erlang/Elixir.

Со комбинирање на основните обрасци, можете да изградите сложени парадигми за да ги решите новите проблеми.

Во последниот дел од серијата, ќе ги разгледаме општите прашања за организирање услуги, рутирање и балансирање, а исто така ќе зборуваме за практичната страна на приспособливоста и толеранцијата на грешки на системите.

Крај на вториот дел.

Фото Мариус Кристенсен
Илустрации подготвени со помош на websequencediagrams.com

Извор: www.habr.com