Градивни елементи на разпределени приложения. Първи подход

В последния Статия ние анализирахме теоретичните основи на реактивната архитектура. Време е да поговорим за потоците от данни, начините за внедряване на реактивни системи 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 съобщения от 1MB са по-добри от едно съобщение от 1GB.

В клъстера 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 манипулатора. Дори на етапа на разпределение на задачите възниква въпросът за справедливостта на разпределението и препълването на манипулатори. Round-robin разпределението ще отговаря за справедливостта и за да избегнем ситуация на препълване на манипулатори, ще въведем ограничение prefetch_limit. В преходни режими prefetch_limit няма да позволи на един манипулатор да получава всички задачи.

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

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

Да приемем, че по време на обработката на три задачи е възникнала сложна повреда: манипулаторът 1, след получаване на задачата, се е сринал, без да има време да докладва нещо на точката за обмен. В този случай точката за обмен ще прехвърли заданието към друг манипулатор след изтичане на времето за изчакване на ack. По някаква причина манипулатор 3 изостави задачата и изпрати нак, в резултат на което задачата също премина към друг манипулатор, който я изпълни успешно.

Предварително резюме

Ние разбихме основните градивни елементи на разпределените системи и придобихме основно разбиране за тяхното използване в Erlang/Elixir.

Чрез комбиниране на основни шаблони могат да бъдат изградени сложни парадигми за решаване на възникващи проблеми.

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

Край на втората част.

Фото Мариус Кристенсен
Илюстрациите са предоставени с любезното съдействие на websequencediagrams.com

Източник: www.habr.com