Градивни елементи на разпределени приложения. Второ приближение

Съобщение

Колеги, в средата на лятото планирам да пусна още една серия от статии за проектирането на системи за масово обслужване: „Експериментът VTrade“ - опит да се напише рамка за системи за търговия. Поредицата ще разгледа теорията и практиката за изграждане на борса, търг и магазин. В края на статията ви каня да гласувате за темите, които ви интересуват най-много.

Това е последната статия от поредицата за разпределени реактивни приложения в Erlang/Elixir. IN първа статия можете да намерите теоретичните основи на реактивната архитектура. Втора статия илюстрира основните модели и механизми за конструиране на такива системи.

Днес ще повдигнем въпроси за развитието на кодовата база и проектите като цяло.

Организация на услугите

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

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

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

коментар: Ние не разглеждаме въпроса за последователното съхранение и репликацията на данни. Да приемем, че тези проблеми са решени по-рано и системата вече има надежден и мащабируем слой за съхранение, а манипулаторите имат механизми за взаимодействие с него.

Формалното описание на потребителската услуга стана по-сложно. От гледна точка на програмист промените са минимални поради използването на съобщения. За да удовлетворим първото изискване, трябва да конфигурираме балансиране в точката за обмен на req-resp.

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

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

В резултат на това декомпозицията на проблема показа, че за да отговорим на изискванията, трябва да стартираме 5 екземпляра на услугата на различни възли и да създадем допълнителен субект - pub-sub контролер, отговорен за абонамента.
За да стартирате 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 XNUMX пъти: XNUMX XNUMX пъти на всеки сървър, според броя на абонатите на него. Не много ефективна схема, нали?
За да подобрим ситуацията, нека въведем прокси, което има същото име като точката за обмен. Глобалният регистратор на имена трябва да може да върне най-близкия процес по име, това е важно.

Нека стартираме този прокси на сървърите на слоя за достъп и всички наши процеси, обслужващи API на websocket, ще се абонират за него, а не за оригиналната точка за обмен pub-sub в ядрото. Проксито се абонира за ядрото само в случай на уникален абонамент и репликира входящото съобщение на всички свои абонати.
В резултат на това ще бъдат изпратени 5 съобщения между ядрото и сървърите за достъп, вместо 50000 XNUMX.

Маршрутизиране и балансиране

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