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

У последњих Чланак анализирали смо теоријске основе реактивне архитектуре. Време је да разговарамо о токовима података, начинима имплементације реактивних Ерланг/Еликир система и обрасцима слања порука у њима:

• Захтев-одговор
• Рекуест-Цункед Респонсе
• Одговор са захтевом
• објави-претплати се
• Инвертед Публисх Субсцрибе
• Дистрибуција задатака

СОА, МСА и размена порука

СОА, МСА су системске архитектуре које дефинишу правила за изградњу система, док размена порука обезбеђује примитиве за њихову имплементацију.

Не желим да пропагирам ову или ону архитектуру система. Ја сам за примену најефикаснијих и најкориснијих пракси за одређени пројекат и посао. Коју год парадигму да изаберемо, боље је креирати системске блокове са оком на Уник-пут: компоненте са минималном конективношћу, одговорне за појединачне ентитете. АПИ методе обављају најједноставније радње са ентитетима.

Размена порука - као што име говори - посредник порука. Његова главна сврха је примање и слање порука. Одговоран је за интерфејсе за слање информација, формирање логичких канала за пренос информација унутар система, рутирање и балансирање, као и руковање кваровима на нивоу система.
Развијене поруке не покушавају да се такмиче са или замене раббитмк. Његове главне карактеристике:

• Дистрибуција.
  Тачке размене се могу креирати на свим чворовима кластера, што ближе коду који их користи.
• Једноставност.
  Фокусирајте се на минимизирање стандардног кода и једноставност коришћења.
• Боље перформансе.
  Не покушавамо да поновимо функционалност раббитмк-а, већ бирамо само архитектонски и транспортни слој, који што једноставније уклапамо у ОТП, минимизирајући трошкове.
• Флексибилност.
  Свака услуга може комбиновати много шаблона за размену.
• Отпорност по дизајну.
• Прилагодљивост.
  Размена порука расте са апликацијом. Како се оптерећење повећава, можете да преместите тачке размене на одвојене машине.

Напомена. У смислу организације кода, мета-пројекти су веома погодни за сложене Ерланг/Еликир системе. Сав код пројекта је у једном спремишту - кровном пројекту. Истовремено, микросервисе су изоловане што је више могуће и обављају једноставне операције које су одговорне за посебан ентитет. Са овим приступом, лако је одржавати АПИ целог система, лако је уносити измене, згодно је писати тестове јединица и интеграције.

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

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

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

Размене

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

Обрасци размене порука (МЕП)

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

Захтев-одговор или РПЦ

РПЦ се користи када треба да добијемо одговор од другог процеса. Овај процес се може покренути на истом хосту или на другом континенту. Испод је дијаграм интеракције између клијента и сервера кроз размену порука.

Пошто је размена порука потпуно асинхрона, размена за клијента је подељена у 2 фазе:

1. шаље захтев

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

   размена ‒ јединствени назив тачке размене
   РеспонсеМатцхингТаг ‒ локална ознака за обраду одговора. На пример, у случају слања неколико идентичних захтева који припадају различитим корисницима.
   Дефиниција захтева ‒ тело захтева
   ХандлерПроцесс ‒ ПИД руковаоца. Овај процес ће добити одговор од сервера.

2. Обрада одговора

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

   РеспонсеПаилоад - одговор сервера.

За сервер, процес се такође састоји од 2 фазе:

1. Иницијализација тачке размене
2. Обрада долазних захтева

Илуструјмо овај шаблон кодом. Рецимо да треба да имплементирамо једноставну услугу која обезбеђује један метод тачног времена.

Серверски код

Хајде да преместимо дефиницију АПИ-ја услуге на апи.хрл:

%% =====================================================
%%  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{}
}).

Дефинишите контролер услуге у тиме_цонтроллер.ерл

%% В примере показан только значимый код. Вставив его в шаблон 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.

Шифра клијента

Да бисте послали захтев услузи, можете да позовете АПИ захтева за размену порука било где на клијенту:

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

У дистрибуираном систему, конфигурација компоненти може бити веома различита, а у време захтева, порука можда још није почела или сервисни контролер неће бити спреман да услужи захтев. Због тога морамо да проверимо одговор на размену порука и да решимо случај грешке.
Након успешног слања клијенту, сервис ће добити одговор или грешку.
Хајде да обрадимо оба случаја у хандле_инфо:

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 МБ су боље од једне поруке од 1 ГБ.

У кластеру Ерланг добијамо додатну корист - смањење оптерећења на тачки размене и мрежи, пошто се одговори одмах шаљу примаоцу, заобилазећи тачку размене.

Одговор са захтевом

Ово је прилично ретка модификација РПЦ обрасца за изградњу конверзацијских система.

Објави-претплати се (стабло дистрибуције података)

Системи вођени догађајима испоручују податке потрошачима чим буду спремни. Према томе, системи су склонији пусх моделу него моделу повлачења или анкетирања. Ова функција вам омогућава да не трошите ресурсе сталним тражењем и чекањем података.
Слика приказује процес дистрибуције поруке потрошачима који су претплаћени на одређену тему.

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

Узмите у обзир претплатнички код:

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 руковаоца. Чак иу фази расподеле задатака поставља се питање праведности расподеле и преливања руковалаца. Кружна дистрибуција ће бити одговорна за правичност, а како бисмо избегли ситуацију преливања руковалаца, увешћемо ограничење префетцх_лимит. У прелазним режимима префетцх_лимит неће дозволити да један руковалац прими све задатке.

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

• messaging:ack(Tack) ‒ позива се у случају успешне обраде поруке
• messaging:nack(Tack) ‒ позивати у свим ванредним ситуацијама. Након што се задатак врати, порука ће га проследити другом руковаоцу.

Претпоставимо да је током обраде три задатка дошло до сложеног квара: руковалац 1 је, након што је примио задатак, пао а да није имао времена да било шта пријави тачки размене. У овом случају, тачка размене ће пренети посао другом руковаоцу након што истекне временско ограничење потврде. Руковалац 3 је из неког разлога напустио задатак и послао нацк, као резултат тога, задатак је такође прешао на другог руковаоца који га је успешно завршио.

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

Разбили смо основне грађевне блокове дистрибуираних система и стекли основно разумевање њихове употребе у Ерланг/Еликир-у.

Комбиновањем основних шаблона могу се изградити сложене парадигме за решавање нових проблема.

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

Крај другог дела.

Фотографија Мариус Цхристенсен
Илустрације љубазношћу вебсекуенцедиаграмс.цом

Извор: ввв.хабр.цом