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

Соопштение

Колеги, во средината на летото планирам да објавам уште една серија написи за дизајнот на системите за редици: „Експериментот VTrade“ - обид да се напише рамка за трговски системи. Серијата ќе ја испита теоријата и практиката на градење размена, аукција и продавница. На крајот од статијата, ве повикувам да гласате за темите кои најмногу ве интересираат.

Ова е последната статија од серијата за дистрибуирани реактивни апликации во Erlang/Elixir. ВО првата статија можете да ги најдете теоретските основи на реактивната архитектура. Втора статија ги илустрира основните обрасци и механизми за конструирање на вакви системи.

Денес ќе покренеме прашања за развој на базата на кодови и проекти воопшто.

Организација на услуги

Во реалниот живот, кога развивате услуга, честопати треба да комбинирате неколку модели на интеракција во еден контролер. На пример, услугата за корисници, која го решава проблемот со управувањето со корисничките профили на проектот, мора да одговори на барањата req-resp и да известува за ажурирања на профилот преку pub-sub. Овој случај е прилично едноставен: зад пораките има еден контролер кој ја имплементира логиката на услугата и објавува ажурирања.

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

1. сега услугата треба да обработува барања на 5 кластерски јазли,
2. да може да извршува задачи за обработка на заднина,
3. и исто така да може динамички да управува со списоците на претплати за ажурирања на профилот.

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

Официјалниот опис на услугата за корисници стана покомплициран. Од гледна точка на програмер, промените се минимални поради употребата на пораки. За да го задоволиме првото барање, треба да го конфигурираме балансирањето во точката за размена на req-resp.

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

Точката 3 бара екстензија на шаблонот pub-sub. И за имплементација, по креирањето на пунктот за размена на паб-подредени, дополнително треба да го стартуваме контролорот на оваа точка во рамките на нашата услуга. Така, како да ја преместуваме логиката за обработка на претплати и отпишувања од слојот за пораки во имплементација на корисниците.

Како резултат на тоа, распаѓањето на проблемот покажа дека за да ги исполниме барањата, треба да лансираме 5 примероци на услугата на различни јазли и да создадеме дополнителен ентитет - контролер на паб-под, одговорен за претплатата.
За да извршите 5 ракувачи, не треба да го менувате сервисниот код. Единственото дополнително дејство е поставувањето правила за балансирање на местото на размена, за што ќе зборуваме малку подоцна.
Исто така, постои дополнителна сложеност: контролерот за pub-sub и прилагодениот распоредувач на задачи мора да работат во една копија. Повторно, услугата за пораки, како основна, мора да обезбеди механизам за избор на лидер.

Избор на лидер

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

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

По стартувањето и поврзувањето со точката за размена, сите услуги добиваат системска порака #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}. Ако LeaderPid се совпаѓа со pid тековниот процес, тој е назначен за лидер, а листата Servers ги вклучува сите јазли и нивните параметри.
Во моментот кога ќе се појави нов и ќе се исклучи работниот јазол на кластерот, добиваат сите контролори на услуги #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} и #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} соодветно.

На овој начин, сите компоненти се свесни за сите промени, а кластерот е загарантиран да има еден лидер во секое време.

Медијатори

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

Класичен пример за оптимизација на pub-sub е дистрибуирана апликација со деловно јадро што генерира настани за ажурирање, како што се промени во цените на пазарот, и слој за пристап - N сервери кои обезбедуваат веб-сокет API за веб-клиенти.
Ако одлучите директно, тогаш услугата за клиенти изгледа вака:

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

Да замислиме дека имаме 50000 претплатници на темата „вести“. Претплатниците се распределуваат рамномерно на 5 сервери. Како резултат на тоа, секое ажурирање, кое пристигнува до местото на размена, ќе се реплицира 50000 пати: 10000 пати на секој сервер, според бројот на претплатници на него. Не е многу ефикасна шема, нели?
За да ја подобриме ситуацијата, да воведеме прокси што го има истото име како точката за размена. Глобалниот регистратор на имиња мора да може да го врати најблискиот процес по име, ова е важно.

Ајде да го лансираме овој прокси на серверите на слојот за пристап и сите наши процеси кои го опслужуваат websocket api ќе се претплатат на него, а не на оригиналната точка за размена на pub-sub во кернелот. Прокси се претплати на јадрото само во случај на единствена претплата и ја реплицира дојдовната порака на сите свои претплатници.
Како резултат на тоа, 5 пораки ќе бидат испратени помеѓу кернелот и серверите за пристап, наместо 50000.

Рутирање и балансирање

Req-Resp

Во тековната имплементација на пораки, постојат 7 стратегии за дистрибуција на барања:

• default. Барањето се испраќа до сите контролори.
• round-robin. Барањата се набројуваат и циклично се дистрибуираат помеѓу контролорите.
• consensus. Контролорите кои служат на услугата се поделени на водачи и робови. Барањата се испраќаат само до лидерот.
• consensus & round-robin. Групата има лидер, но барањата се дистрибуираат меѓу сите членови.
• sticky. Функцијата за хаш се пресметува и се доделува на одреден управувач. Последователните барања со овој потпис одат кај истиот управувач.
• sticky-fun. При иницијализирање на точката за размена, функцијата за пресметување на хаш за sticky балансирање.
• fun. Слично на sticky-fun, само вие можете дополнително да го пренасочите, одбиете или претходно да го обработите.

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

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

• Ознака за поврзување. Ви овозможува да разберете преку која врска дошле настаните. Се користи кога процес на контролер се поврзува на иста точка за размена, но со различни клучеви за рутирање.
• Ознака за услуга. Ви овозможува да комбинирате ракувачи во групи за една услуга и да ги проширите можностите за рутирање и балансирање. За шемата req-resp, рутирањето е линеарно. Испраќаме барање до местото за размена, а потоа го пренесува на сервисот. Но, ако треба да ги поделиме управувачите во логички групи, тогаш разделувањето се врши со помош на ознаки. Кога одредувате ознака, барањето ќе биде испратено до одредена група на контролори.
• Ознака за барање. Ви овозможува да разликувате одговори. Бидејќи нашиот систем е асинхрон, за да ги обработиме одговорите на услугата, треба да можеме да наведеме RequestTag кога испраќаме барање. Од него ќе можеме да го разбереме одговорот на кое барање дојде до нас.

Паб-под

За pub-sub сè е малку поедноставно. Имаме точка за размена на која се објавуваат пораките. Точката за размена дистрибуира пораки меѓу претплатниците кои се претплатиле на клучевите за рутирање што им се потребни (можеме да кажеме дека ова е аналогно на темите).

Приспособливост и толеранција на грешки

Приспособливоста на системот како целина зависи од степенот на приспособливост на слоевите и компонентите на системот:

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

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

Резервација

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

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

Перформанси

Ајде да се обидеме барем грубо да ги споредиме перформансите на rabbitmq и нашите сопствени пораки.
најдов официјални резултати rabbitmq тестирање од тимот на openstack.

Во став 6.14.1.2.1.2.2. Оригиналниот документ го прикажува резултатот од RPC CAST:

Нема да правиме никакви дополнителни поставки на кернелот на ОС или erlang VM однапред. Услови за тестирање:

• erl избира: +A1 +sbtu.
• Тестот во рамките на еден erlang јазол се извршува на лаптоп со стар i7 во мобилна верзија.
• Кластер тестовите се вршат на сервери со 10G мрежа.
• Кодот работи во докер контејнери. Мрежа во NAT режим.

Тест код:

req_resp_bench(_) ->
  W = perftest:comprehensive(10000,
    fun() ->
      messaging:request(?EXCHANGE, default, ping, self()),
      receive
        #'$msg'{message = pong} -> ok
      after 5000 ->
        throw(timeout)
      end
    end
  ),
  true = lists:any(fun(E) -> E >= 30000 end, W),
  ok.

Сценарио 1: Тестот се извршува на лаптоп со стара i7 мобилна верзија. Тестот, пораките и услугата се извршуваат на еден јазол во еден Docker контејнер:

Sequential 10000 cycles in ~0 seconds (26987 cycles/s)
Sequential 20000 cycles in ~1 seconds (26915 cycles/s)
Sequential 100000 cycles in ~4 seconds (26957 cycles/s)
Parallel 2 100000 cycles in ~2 seconds (44240 cycles/s)
Parallel 4 100000 cycles in ~2 seconds (53459 cycles/s)
Parallel 10 100000 cycles in ~2 seconds (52283 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (49317 cycles/s)

Сценарио 2: 3 јазли кои работат на различни машини под докер (NAT).

Sequential 10000 cycles in ~1 seconds (8684 cycles/s)
Sequential 20000 cycles in ~2 seconds (8424 cycles/s)
Sequential 100000 cycles in ~12 seconds (8655 cycles/s)
Parallel 2 100000 cycles in ~7 seconds (15160 cycles/s)
Parallel 4 100000 cycles in ~5 seconds (19133 cycles/s)
Parallel 10 100000 cycles in ~4 seconds (24399 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (34517 cycles/s)

Во сите случаи, искористеноста на процесорот не надминува 250%

Резултатите од

Се надевам дека овој циклус нема да изгледа како депонија и моето искуство ќе биде од вистинска корист и за истражувачите на дистрибуирани системи и за практичарите кои се на самиот почеток на градење дистрибуирани архитектури за нивните деловни системи и со интерес го гледаат Erlang/Elixir , но имајте сомнежи дали вреди...

Фото @chuttersnap

Само регистрирани корисници можат да учествуваат во анкетата. Најави се, вие сте добредојдени.

Кои теми треба да ги опфатам подетално како дел од серијата VTrade Experiment?

• Теорија: пазари, нарачки и нивно време: DAY, GTD, GTC, IOC, FOK, MOO, MOC, LOO, LOC

• Книга на нарачки. Теорија и практика на спроведување на книга со групирања

• Визуелизација на тргувањето: крлежи, шипки, резолуции. Како да складирате и како да лепите

• Задна канцеларија. Планирање и развој. Следење на вработените и истрага на инциденти

• API. Ајде да откриеме кои интерфејси се потребни и како да ги имплементираме

• Складирање информации: PostgreSQL, Timescale, Tarantool во трговските системи

• Реактивност во трговските системи

• Друго. Ќе напишам во коментарите

Гласаа 6 корисници. 4 корисници се воздржаа.

Извор: www.habr.com